Posted:
Securing modern web applications can be a daunting task—doubly so if they are built (quickly) with diverse languages and technology stacks. That’s why we run a multi-faceted product security program, which helps our engineers build and deploy secure software at every stage of the development lifecycle. As part of this effort, we have developed an internal web application security scanning tool, codenamed Inquisition (as no bug expects it!).

The scanner is built entirely on Google technologies like Chrome and Google Cloud Platform, with support for the latest HTML5 features, a low false positive rate and ease of use in mind. We have discussed some of the technology behind this tool in a talk at the Google Testing Automation Conference 2013.

While working on this tool, we found we needed a synthetic testbed to both test our current capabilities and set goals for what we need to catch next. Today we’re announcing the open-source release of Firing Range, the results of our work (with some help from researchers at the Politecnico di Milano) in producing a test ground for automated scanners.

Firing Range is a Java application built on Google App Engine and contains a wide range of XSS and, to a lesser degree, other web vulnerabilities. Code is available on github.com/google/firing-range, while a deployed version is at public-firing-range.appspot.com.

How is it different from the many vulnerable test applications already available? Most of them have focused on creating realistic-looking testbeds for human testers; we think that with automation in mind it is more productive, instead, to try to exhaustively enumerate the contexts and the attack vectors that an application might exhibit. Our testbed doesn’t try to emulate a real application, nor exercise the crawling capabilities of a scanner: it’s a collection of unique bug patterns drawn from vulnerabilities that we have seen in the wild, aimed at verifying the detection capabilities of security tools.

We have used Firing Range both as a continuous testing aid and as a driver for our development, defining as many bug types as possible, including some that we cannot detect (yet!).

We hope that others will find it helpful in evaluating the detection capabilities of their own automated tools, and we certainly welcome any contributions and feedbacks from the broader security research community.

Posted by Claudio Criscione, Security Engineer

Posted:
A recent poll in the U.S. showed that more people are concerned about being hacked than having their house robbed. That’s why we continue to work hard to keep Google accounts secure. Our defenses keep most bad actors out, and we’ve reduced hijackings by more than 99% over the last few years.

We monitor many potential threats, from mass hijackings (typically used to send lots of spam) to state-sponsored attacks (highly targeted, often with political motivations).

This week, we’re releasing a study of another kind of threat we’ve dubbed “manual hijacking,” in which professional attackers spend considerable time exploiting a single victim’s account, often causing financial losses. Even though they’re rare—9 incidents per million users per day—they’re often severe, and studying this type of hijacker has helped us improve our defenses against all types of hijacking.

Manual hijackers often get into accounts through phishing: sending deceptive messages meant to trick you into handing over your username, password, and other personal info. For this study, we analyzed several sources of phishing messages and websites, observing both how hijackers operate and what sensitive information they seek out once they gain control of an account. Here are some of our findings:

  • Simple but dangerous: Most of us think we’re too smart to fall for phishing, but our research found some fake websites worked a whopping 45% of the time. On average, people visiting the fake pages submitted their info 14% of the time, and even the most obviously fake sites still managed to deceive 3% of people. Considering that an attacker can send out millions of messages, these success rates are nothing to sneeze at.
  • Quick and thorough: Around 20% of hijacked accounts are accessed within 30 minutes of a hacker obtaining the login info. Once they’ve broken into an account they want to exploit, hijackers spend more than 20 minutes inside, often changing the password to lock out the true owner, searching for other account details (like your bank, or social media accounts), and scamming new victims.
  • Personalized and targeted: Hijackers then send phishing emails from the victim’s account to everyone in his or her address book. Since your friends and family think the email comes from you, these emails can be very effective. People in the contact list of hijacked accounts are 36 times more likely to be hijacked themselves. 
  • Learning fast: Hijackers quickly change their tactics to adapt to new security measures. For example, after we started asking people to answer questions (like “which city do you login from most often?”) when logging in from a suspicious location or device, hijackers almost immediately started phishing for the answers.

We’ve used the findings from this study, along with our ongoing research efforts, to improve the many account security systems we have in place. But we can use your help too.

  • Stay vigilant: Gmail blocks the vast majority of spam and phishing emails, but be wary of messages asking for login information or other personal data. Never reply to these messages; instead, report them to us. When in doubt, visit websites directly (not through a link in an email) to review or update account information.
  • Get your account back fast: If your account is ever at risk, it’s important that we have a way to get in touch with you and confirm your ownership. That’s why we strongly recommend you provide a backup phone number or a secondary email address (but make sure that email account uses a strong password and is kept up to date so it’s not released due to inactivity).
  • 2-step verification: Our free 2-step verification service provides an extra layer of security against all types of account hijacking. In addition to your password, you’ll use your phone to prove you’re really you. We also recently added an option to log in with a physical USB device.

Take a few minutes and visit the Secure Your Account page, where you can make sure we’ve got backup contact info for you and confirm that your other security settings are up to date.

Posted by Elie Bursztein, Anti-Abuse Research Lead



Posted:
Google is committed to increasing the use of TLS/SSL in all applications and services. But “HTTPS everywhere” is not enough; it also needs to be used correctly. Most platforms and devices have secure defaults, but some applications and libraries override the defaults for the worse, and in some instances we’ve seen platforms make mistakes as well. As applications get more complex, connect to more services, and use more third party libraries, it becomes easier to introduce these types of mistakes.

The Android Security Team has built a tool, called nogotofail, that provides an easy way to confirm that the devices or applications you are using are safe against known TLS/SSL vulnerabilities and misconfigurations. Nogotofail works for Android, iOS, Linux, Windows, Chrome OS, OSX, in fact any device you use to connect to the Internet. There’s an easy-to-use client to configure the settings and get notifications on Android and Linux, as well as the attack engine itself which can be deployed as a router, VPN server, or proxy.

We’ve been using this tool ourselves for some time and have worked with many developers to improve the security of their apps. But we want the use of TLS/SSL to advance as quickly as possible. Today, we’re releasing it as an open source project, so anyone can test their applications, contribute new features, provide support for more platforms, and help improve the security of the Internet.

Posted by Chad Brubaker, Android Security Engineer

Posted:
Cross-posted on the Research Blog and the Chromium Blog

At Google, we are constantly trying to improve the techniques we use to protect our users' security and privacy. One such project, RAPPOR (Randomized Aggregatable Privacy-Preserving Ordinal Response), provides a new state-of-the-art, privacy-preserving way to learn software statistics that we can use to better safeguard our users’ security, find bugs, and improve the overall user experience.

Building on the concept of randomized response, RAPPOR enables learning statistics about the behavior of users’ software while guaranteeing client privacy. The guarantees of differential privacy, which are widely accepted as being the strongest form of privacy, have almost never been used in practice despite intense research in academia. RAPPOR introduces a practical method to achieve those guarantees.

To understand RAPPOR, consider the following example. Let’s say you wanted to count how many of your online friends were dogs, while respecting the maxim that, on the Internet, nobody should know you’re a dog. To do this, you could ask each friend to answer the question “Are you a dog?” in the following way. Each friend should flip a coin in secret, and answer the question truthfully if the coin came up heads; but, if the coin came up tails, that friend should always say “Yes” regardless. Then you could get a good estimate of the true count from the greater-than-half fraction of your friends that answered “Yes”. However, you still wouldn’t know which of your friends was a dog: each answer “Yes” would most likely be due to that friend’s coin flip coming up tails.

RAPPOR builds on the above concept, allowing software to send reports that are effectively indistinguishable from the results of random coin flips and are free of any unique identifiers. However, by aggregating the reports we can learn the common statistics that are shared by many users. We’re currently testing the use of RAPPOR in Chrome, to learn statistics about how unwanted software is hijacking users’ settings.

We believe that RAPPOR has the potential to be applied for a number of different purposes, so we're making it freely available for all to use. We'll continue development of RAPPOR as a standalone open-source project so that anybody can inspect test its reporting and analysis mechanisms, and help develop the technology. We’ve written up the technical details of RAPPOR in a report that will be published next week at the ACM Conference on Computer and Communications Security.

We’re encouraged by the feedback we’ve received so far from academics and other stakeholders, and we’re looking forward to additional comments from the community. We hope that everybody interested in preserving user privacy will review the technology and share their feedback at rappor-discuss@googlegroups.com.

Posted by Úlfar Erlingsson, Tech Lead Manager, Security Research

Posted:
Screen Shot 2014-09-28 at 11.15.24 PM.png
2-Step Verification offers a strong extra layer of protection for Google Accounts. Once enabled, you’re asked for a verification code from your phone in addition to your password, to prove that it’s really you signing in from an unfamiliar device. Hackers usually work from afar, so this second factor makes it much harder for a hacker who has your password to access your account, since they don’t have your phone.

Today we’re adding even stronger protection for particularly security-sensitive individuals. Security Key is a physical USB second factor that only works after verifying the login site is truly a Google website, not a fake site pretending to be Google. Rather than typing a code, just insert Security Key into your computer’s USB port and tap it when prompted in Chrome. When you sign into your Google Account using Chrome and Security Key, you can be sure that the cryptographic signature cannot be phished.

Security Key and Chrome incorporate the open Universal 2nd Factor (U2F) protocol from the FIDO Alliance, so other websites with account login systems can get FIDO U2F working in Chrome today. It’s our hope that other browsers will add FIDO U2F support, too. As more sites and browsers come onboard, security-sensitive users can carry a single Security Key that works everywhere FIDO U2F is supported.

Security Key works with Google Accounts at no charge, but you’ll need to buy a compatible USB device directly from a U2F participating vendor. If you think Security Key may be right for you, we invite you to learn more.

Posted by Nishit Shah, Product Manager, Google Security

Posted:
Today we are publishing details of a vulnerability in the design of SSL version 3.0. This vulnerability allows the plaintext of secure connections to be calculated by a network attacker. I discovered this issue in collaboration with Thai Duong and Krzysztof Kotowicz (also Googlers).

SSL 3.0 is nearly 18 years old, but support for it remains widespread. Most importantly, nearly all browsers support it and, in order to work around bugs in HTTPS servers, browsers will retry failed connections with older protocol versions, including SSL 3.0. Because a network attacker can cause connection failures, they can trigger the use of SSL 3.0 and then exploit this issue.

Disabling SSL 3.0 support, or CBC-mode ciphers with SSL 3.0, is sufficient to mitigate this issue, but presents significant compatibility problems, even today. Therefore our recommended response is to support TLS_FALLBACK_SCSV. This is a mechanism that solves the problems caused by retrying failed connections and thus prevents attackers from inducing browsers to use SSL 3.0. It also prevents downgrades from TLS 1.2 to 1.1 or 1.0 and so may help prevent future attacks.

Google Chrome and our servers have supported TLS_FALLBACK_SCSV since February and thus we have good evidence that it can be used without compatibility problems. Additionally, Google Chrome will begin testing changes today that disable the fallback to SSL 3.0. This change will break some sites and those sites will need to be updated quickly.

In the coming months, we hope to remove support for SSL 3.0 completely from our client products.

Thank you to all the people who helped review and discuss responses to this issue.

Posted by Bodo Möller, Google Security Team

[Updated Oct 15 to note that SSL 3.0 is nearly 18 years old, not nearly 15 years old.]

Posted:
It’s been a year since we launched our Patch Reward program, a novel effort designed to recognize and reward proactive contributions to the security of key open-source projects that make the Internet tick. Our goal is to provide financial incentives for improvements that go beyond merely fixing a known security bug.

We started with a modest scope and reward amounts, but have gradually expanded the program over the past few months. We’ve seen some great work so far—and to help guide future submissions, we wanted to share some of our favorites:
  • Addition of Curve25519 and several other primitives in OpenSSH to strengthen its cryptographic foundations and improve performance.
  • A set of patches to reduce the likelihood of ASLR info leaks in Linux to make certain types of memory corruption bugs more difficult to exploit.
  • And, of course, the recent attack-surface-reducing function prefix patch in bash that helped mitigate a flurry of “Shellshock”-related bugs.

We hope that this list inspires even more contributions in the year to come. Of course, before participating, be sure to read the rules page. When done, simply send your nominations to security-patches@google.com. And keep up the great work!

Posted by Michal Zalewski, Google Security Team

Posted:
Security and privacy are top priorities for Google. We’ve invested a lot in making our products secure, including strong SSL encryption by default for Search, Gmail and Drive. We’re working to further extend encryption across all our services, ensuring that your connection to Google is private.

For some time, we’ve offered network administrators the ability to require the use of SafeSearch by their users, which filters out explicit content from search results; this is especially important for schools. However, using this functionality has meant that searches were sent over an unencrypted connection to Google. Unfortunately, this has been the target of abuse by other groups looking to snoop on people’s searches, so we will be removing it as of early December.

Going forward, organizations can require SafeSearch on their networks while at the same time ensuring that their users’ connections to Google remain encrypted. (This is in addition to existing functionality that allows SafeSearch to be set on individual browsers and to be enabled by policy on managed devices like Chromebooks.) Network administrators can read more about how to enable this new feature here.

Posted by Brian Fitzpatrick, Engineering Director

Posted:
Cross-posted on the Chromium Blog

We work hard to keep you safe online. In Chrome, for instance, we warn users against malware and phishing and offer rewards for finding security bugs. Due in part to our collaboration with the research community, we’ve squashed more than 700 Chrome security bugs and have rewarded more than $1.25 million through our bug reward program. But as Chrome has become more secure, it’s gotten even harder to find and exploit security bugs.

This is a good problem to have! In recognition of the extra effort it takes to uncover vulnerabilities in Chrome, we’re increasing our reward levels. We’re also making some changes to be more transparent with researchers reporting a bug.

First, we’re increasing our usual reward pricing range to $500-$15,000 per bug, up from a previous published maximum of $5,000. This is accompanied with a clear breakdown of likely reward amounts by bug type. As always, we reserve the right to reward above these levels for particularly great reports. (For example, last month we awarded $30,000 for a very impressive report.)

Second, we’ll pay at the higher end of the range when researchers can provide an exploit to demonstrate a specific attack path against our users. Researchers now have an option to submit the vulnerability first and follow up with an exploit later. We believe that this a win-win situation for security and researchers: we get to patch bugs earlier and our contributors get to lay claim to the bugs sooner, lowering the chances of submitting a duplicate report.

Third, Chrome reward recipients will be listed in the Google Hall of Fame, so you’ve got something to print out and hang on the fridge.

As a special treat, we’re going to back-pay valid submissions from July 1, 2014 at the increased reward levels we’re announcing today. Good times.

We’ve also answered some new FAQs on our rules page, including questions about our new Trusted Researcher program and a bit about our philosophy and alternative markets for zero-day bugs.

Happy bug hunting!

Posted by Tim Willis, Hacker Philanthropist, Chrome Security Team

Posted:
Cross-posted on the Open Source Blog

A recent Pew study found that 86% of people surveyed had taken steps to protect their security online. This is great—more security is always good. However, if people are indeed working to protect themselves, why are we still seeing incidents, breaches, and confusion? In many cases these problems recur because the technology that allows people to secure their communications, content and online activity is too hard to use. 

In other words, the tools for the job exist. But while many of these tools work technically, they don’t always work in ways that users expect. They introduce extra steps or are simply confusing and cumbersome. (“Is this a software bug, or am I doing something wrong?”) However elegant and intelligent the underlying technology (and much of it is truly miraculous), the results are in: if people can’t use it easily, many of them won’t. 

We believe that people shouldn’t have to make a trade-off between security and ease of use. This is why we’re happy to support Simply Secure, a new organization dedicated to improving the usability and safety of open-source tools that help people secure their online lives. 

Over the coming months, Simply Secure will be collaborating with open-source developers, designers, researchers, and others to take what’s there—groundbreaking work from efforts like Open Whisper Systems, The Guardian Project, Off-the-Record Messaging, and more—and work to make them easier to understand and use. 

We’re excited for a future where people won’t have to choose between ease and security, and where tools that allow people to secure their communications, content, and online activity are as easy as choosing to use them.

Posted by Meredith Whittaker, Open Source Research Lead and Ben Laurie, Senior Staff Security Engineer