Google Online Security Blog

Introducing nogotofail—a network traffic security testing tool

November 4, 2014

HTTPS everywhere
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

Learning statistics with privacy, aided by the flip of a coin

October 30, 2014

Cross-posted on the Research Blog and the Chromium Blog
protect our users' security and privacyrandomized responsedifferential privacystrongest form of privacyintense research in academiaon the Internet, nobody should know you’re a dogunwanted softwarehijackingopen-source projectreportACM Conference on Computer and Communications Securityfeedbackrappor-discuss@googlegroups.comPosted by Úlfar Erlingsson, Tech Lead Manager, Security Research

Strengthening 2-Step Verification with Security Key

October 21, 2014

2-Step VerificationSecurity Key

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.learn morePosted by Nishit Shah, Product Manager, Google Security

This POODLE bites: exploiting the SSL 3.0 fallback

October 14, 2014

detailsTLS_FALLBACK_SCSVPosted 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.]

News from the land of patch rewards

October 9, 2014

launchedPatch Reward
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:

Incorporation of a variety of web security checks directly into Django to help users develop safer web applications.

A support for seccomp-bpf sandboxing in BIND to minimize the impact of remote code execution bugs.

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

An update to SafeSearch options for network administrators

October 2, 2014

strong SSL encryption
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

Fewer bugs, mo’ money

September 30, 2014

Cross-posted on the Chromium Blog
bug reward programsecure
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

Security for the people

September 18, 2014

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

Cleaning up after password dumps

September 10, 2014

We found that less than 2% of the username and password combinations might have worked, and our automated anti-hijacking systems would have blocked many of those login attempts. We’ve protected the affected accounts and have required those users to reset their passwords.
It’s important to note that in this case and in others, the leaked usernames and passwords were not the result of a breach of Google systems. Often, these credentials are obtained through a combination of other sources.
For instance, if you reuse the same username and password across websites, and one of those websites gets hacked, your credentials could be used to log into the others. Or attackers can use malware or phishing schemes to capture login credentials.

We’re constantly working to keep your accounts secure from phishing, malware and spam. For instance, if we see unusual account activity, we’ll stop sign-in attempts from unfamiliar locations and devices. You can review this activity and confirm whether or not you actually took the action.

A few final tips: Make sure you’re using a strong password unique to Google. Update your recovery options so we can reach you by phone or email if you get locked out of your account. And consider 2-step verification, which adds an extra layer of security to your account. You can visit g.co/accountcheckup where you’ll see a list of many of the security controls at your disposal.

Posted by Borbala Benko, Elie Bursztein, Tadek Pietraszek and Mark Risher, Google Spam & Abuse Team

Gradually sunsetting SHA-1

September 5, 2014

Cross-posted on the Chromium Blog
since at least 2005Collision attacks against SHA-1 are too affordableBaseline Requirements for SSLNISTthe MD5 hash algorithmfrom leading vendorsscrambling for updates
Chrome 39 (Branch point 26 September 2014)

Sites with end-entity (“leaf”) certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.

The current visual display for “secure, but with minor errors” is a lock with a yellow triangle, and is used to highlight other deprecated and insecure practices, such as passive mixed content.

Chrome 40 (Branch point 7 November 2014; Stable after holiday season)

Sites with end-entity certificates that expire between 1 June 2016 to 31 December 2016 (inclusive), and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.

Sites with end-entity certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “neutral, lacking security”.

The current visual display for “neutral, lacking security” is a blank page icon, and is used in other situations, such as HTTP.

Chrome 41 (Branch point in Q1 2015)

Sites with end-entity certificates that expire between 1 January 2016 and 31 December 2016 (inclusive), and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.

Sites with end-entity certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “affirmatively insecure”. Subresources from such domain will be treated as “active mixed content”.

The current visual display for “affirmatively insecure” is a lock with a red X, and a red strike-through text treatment in the URL scheme.

Note: SHA-1-based signatures for trusted root certificates are not a problem because TLS clients trust them by their identity, rather than by the signature of their hash.

Posted by Chris Palmer, Secure Socket Lover and Ryan Sleevi, Transport Layer Securer

Security Blog