Posted by Stephan Somogyi, Product Manager, Security and Privacy

[Cross-posted on the Google Analytics Blog]

If you run a web site, you may already be familiar with Google Webmaster Tools and how it lets you know if Safe Browsing finds something problematic on your site. For example, we’ll notify you if your site is delivering malware, which is usually a sign that it’s been hacked. We’re extending our Safe Browsing protections to automatically display notifications to all Google Analytics users via familiar Google Analytics Notifications.

Google Safe Browsing has been protecting people across the Internet for over eight years and we're always looking for ways to extend that protection even further. Notifications like these help webmasters like you act quickly to respond to any issues. Fast response helps keep your site—and your visitors—safe.

Posted by Tim Willis, Hacker Philanthropist, Chrome Security Team

[Cross-posted from the Chromium Blog]

Around this time each year we announce the rules, details and maximum cash amounts we’re putting up for our Pwnium competition. For the last few years we put a huge pile of cash on the table (last year it was e million) and gave researchers one day during CanSecWest to present their exploits. We’ve received some great entries over the years, but it’s time for something bigger.

Starting today, Pwnium will change its scope significantly, from a single-day competition held once a year at a security conference to a year round, worldwide opportunity for security researchers.

For those who are interested in what this means for the Pwnium rewards pool, we crunched the numbers and the results are in: it now goes all the way up to $∞ million*.

We’re making this change for a few reasons:

• Removing barriers to entry: At Pwnium competitions, a security researcher would need to have a bug chain in March, pre-register, have a physical presence at the competition location and hopefully get a good timeslot. Under the new scheme, security researchers can submit their bugs year-round through the Chrome Vulnerability Reward Program (VRP) whenever they find them. 
• Removing the incentive for bug hoarding: If a security researcher was to discover a Pwnium-quality bug chain today, it’s highly likely that they would wait until the contest to report it to get a cash reward. This is a bad scenario for all parties. It’s bad for us because the bug doesn’t get fixed immediately and our users are left at risk. It’s bad for them as they run the real risk of a bug collision. By allowing security researchers to submit bugs all year-round, collisions are significantly less likely and security researchers aren’t duplicating their efforts on the same bugs.
• Our researchers want this: On top of all of these reasons, we asked our handful of participants if they wanted an option to report all year. They did, so we’re delivering.

Logistically, we’ll be adding Pwnium-style bug chains on Chrome OS to the Chrome VRP. This will increase our top reward to $50,000, which will be on offer all year-round. Check out our FAQ for more information.

Happy hunting!

*Our lawyercats wouldn’t let me say “never-ending” or “infinity million” without adding that “this is an experimental and discretionary rewards program and Google may cancel or modify the program at any time.” Check out the reward eligibility requirements on the Chrome VRP page.

Posted by Lucas Ballard, Software Engineer

SafeBrowsing helps keep you safe online and includes protection against unwanted software that makes undesirable changes to your computer or interferes with your online experience.

We recently expanded our efforts in Chrome, Search, and ads to keep you even safer from sites where these nefarious downloads are available.

• Chrome: Now, in addition to showing warnings before you download unwanted software, Chrome will show you a new warning, like the one below, before you visit a site that encourages downloads of unwanted software.

• Search: Google Search now incorporates signals that identify such deceptive sites. This change reduces the chances you’ll visit these sites via our search results.
• Ads: We recently began to disable Google ads that lead to sites with unwanted software.

If you’re a site owner, we recommend that you register your site with Google Webmaster Tools. This will help you stay informed when we find something on your site that leads people to download unwanted software, and will provide you with helpful tips to resolve such issues. 

We’re constantly working to keep people safe across the web. Read more about Safe Browsing technology and our work to protect users here.

Posted by Rob Mann, Security Engineering Manager

[Cross-posted from the Google Cloud Platform Blog]

Deploying a new build is a thrill, but every release should be scanned for security vulnerabilities. And while web application security scanners have existed for years, they’re not always well-suited for Google App Engine developers. They’re often difficult to set up, prone to over-reporting issues (false positives)—which can be time-consuming to filter and triage—and built for security professionals, not developers.

Today, we’re releasing Google Cloud Security Scanner in beta. If you’re using App Engine, you can easily scan your application for two very common vulnerabilities: cross-site scripting (XSS) and mixed content.

While designing Cloud Security Scanner we had three goals:

1. Make the tool easy to set up and use
2. Detect the most common issues App Engine developers face with minimal false positives
3. Support scanning rich, JavaScript-heavy web applications

To try it for yourself, select Compute > App Engine > Security scans in the Google Developers Console to run your first scan, or learn more here.

So How Does It Work?

Crawling and testing modern HTML5, JavaScript-heavy applications with rich multi-step user interfaces is considerably more challenging than scanning a basic HTML page. There are two general approaches to this problem:

1. Parse the HTML and emulate a browser. This is fast, however, it comes at the cost of missing site actions that require a full DOM or complex JavaScript operations.
2. Use a real browser. This approach avoids the parser coverage gap and most closely simulates the site experience. However, it can be slow due to event firing, dynamic execution, and time needed for the DOM to settle.

Cloud Security Scanner addresses the weaknesses of both approaches by using a multi-stage pipeline. First, the scanner makes a high speed pass, crawling, and parsing the HTML. It then executes a slow and thorough full-page render to find the more complex sections of your site.

While faster than a real browser crawl, this process is still too slow. So we scale horizontally. Using Google Compute Engine, we dynamically create a botnet of hundreds of virtual Chrome workers to scan your site. Don’t worry, each scan is limited to 20 requests per second or lower.

Then we attack your site (again, don’t worry)! When testing for XSS, we use a completely benign payload that relies on Chrome DevTools to execute the debugger. Once the debugger fires, we know we have JavaScript code execution, so false positives are (almost) non-existent. While this approach comes at the cost of missing some bugs due to application specifics, we think that most developers will appreciate a low effort, low noise experience when checking for security issues—we know Google developers do!

As with all dynamic vulnerability scanners, a clean scan does not necessarily mean you’re security bug free. We still recommend a manual security review by your friendly web app security professional.

Ready to get started? Learn more here. Cloud Security Scanner is currently in beta with many more features to come, and we’d love to hear your feedback. Simply click the “Feedback” button directly within the tool.

Posted by Chris Evans and Ben Hawkes, Project Zero; Heather Adkins, Matt Moore and Michal Zalewski, Google Security; Gerhard Eschelbeck, Vice President, Google Security

Cross-posted from the Project Zero blog

Disclosure deadlines have long been an industry standard practice. They improve end-user security by getting security patches to users faster. As noted in CERT’s 45-day disclosure policy, they also “balance the need of the public to be informed of security vulnerabilities with vendors' need for time to respond effectively”. Yahoo!’s 90-day policy notes that “Time is of the essence when we discover these types of issues: the more quickly we address the risks, the less harm an attack can cause”. ZDI’s 120-day policy notes that releasing vulnerability details can “enable the defensive community to protect the user”.

Deadlines also acknowledge an uncomfortable fact that is alluded to by some of the above policies: the offensive security community invests considerably more into vulnerability research than the defensive community. Therefore, when we find a vulnerability in a high profile target, it is often already known by advanced and stealthy actors.

Project Zero has adhered to a 90-day disclosure deadline. Now we are applying this approach for the rest of Google as well. We notify vendors of vulnerabilities immediately, with details shared in public with the defensive community after 90 days, or sooner if the vendor releases a fix. We’ve chosen a middle-of-the-road deadline timeline and feel it’s reasonably calibrated for the current state of the industry.

To see how things are going, we crunched some data on Project Zero’s disclosures to date. For example, the Adobe Flash team probably has the largest install base and number of build combinations of any of the products we’ve researched so far. To date, they have fixed 37 Project Zero vulnerabilities (or 100%) within the 90-day deadline. More generally, of 154 Project Zero bugs fixed so far, 85% were fixed within 90 days. Restrict this to the 73 issues filed and fixed after Oct 1st, 2014, and 95% were fixed within 90 days. Furthermore, recent well-discussed deadline misses were typically fixed very quickly after 90 days. Looking ahead, we’re not going to have any deadline misses for at least the rest of February.

Deadlines appear to be working to improve patch times and end user security—especially when enforced consistently.

We’ve studied the above data and taken on board some great debate and external feedback around some of the corner cases for disclosure deadlines. We have improved the policy in the following ways:

• Weekends and holidays. If a deadline is due to expire on a weekend or US public holiday, the deadline will be moved to the next normal work day. 
• Grace period. We now have a 14-day grace period. If a 90-day deadline will expire but a vendor lets us know before the deadline that a patch is scheduled for release on a specific day within 14 days following the deadline, the public disclosure will be delayed until the availability of the patch. Public disclosure of an unpatched issue now only occurs if a deadline will be significantly missed (2 weeks+). 
• Assignment of CVEs. CVEs are an industry standard for uniquely identifying vulnerabilities. To avoid confusion, it’s important that the first public mention of a vulnerability should include a CVE. For vulnerabilities that go past deadline, we’ll ensure that a CVE has been pre-assigned. 

As always, we reserve the right to bring deadlines forwards or backwards based on extreme circumstances. We remain committed to treating all vendors strictly equally. Google expects to be held to the same standard; in fact, Project Zero has bugs in the pipeline for Google products (Chrome and Android) and these are subject to the same deadline policy.

Putting everything together, we believe the policy updates are still strongly in line with our desire to improve industry response times to security bugs, but will result in softer landings for bugs marginally over deadline. Finally, we’d like to call on all researchers to adopt disclosure deadlines in some form, and feel free to use our policy verbatim if you find our data and reasoning compelling. We’re excited by the early results that disclosure deadlines are delivering—and with the help of the broader community, we can achieve even more.

Posted by Eduardo Vela Nava, Security Engineer 

Since 2010, our Security Reward Programs have been a cornerstone of our relationship with the security research community. These programs have been successful because of two core beliefs:

• Security researchers should be rewarded for helping us protect Google's users. 
• Researchers help us understand how to make Google safer by discovering, disclosing, and helping fix vulnerabilities at a scale that’s difficult to replicate by any other means.

We’re grateful for the terrific work these researchers do to help keep users safe. And so, we wanted to take a look back at 2014 to celebrate their contributions to Google, and in turn, our contributions back to them.

Looking back on 2014

Our Security Reward Programs continue to grow at a rapid clip. We’ve now paid more than $4,000,000 in rewards to security researchers since 2010 across all of our reward programs, and we’re looking forward to more great years to come.

In 2014:

• We paid researchers more than $1,500,000.
• Our largest single reward was $150,000. The researcher then joined us for an internship.
• We rewarded more than 200 different researchers. 
• We rewarded more than 500 bugs. For Chrome, more than half of all rewarded reports for 2014 were in developer and beta versions. We were able to squash bugs before they could reach our main user population. 

The top three contributors to the VRP program in 2014 during a recent visit to Google Zurich: Adrian (Romania), Tomasz (Poland / UK), Nikolai (Ukraine)

What’s new for 2015

We are announcing two additions to our programs today.

First, researchers' efforts through these programs, combined with our own internal security work, make it increasingly difficult to find bugs. Of course, that's good news, but it can also be discouraging when researchers invest their time and struggle to find issues. With this in mind, today we're rolling out a new, experimental program: Vulnerability Research Grants. These are up-front awards that we will provide to researchers before they ever submit a bug.

Here’s how the program works:

• We'll publish different types of vulnerabilities, products and services for which we want to support research beyond our normal vulnerability rewards. 
• We'll award grants immediately before research begins, with no strings attached. Researchers then pursue the research they applied for, as usual.
• There will be various tiers of grants, with a maximum of $3,133.70 USD.
• On top of the grant, researchers are still eligible for regular rewards for the bugs they discover. 

To learn more about the current grants, and review your eligibility, have a look at our rules page.

Second, also starting today, all mobile applications officially developed by Google on Google Play and iTunes will now be within the scope of the Vulnerability Reward Program.

We’re looking forward to continuing our close partnership with the security community and rewarding them for their time and efforts in 2015!

Posted by Stephan Somogyi, Product Manager, Security and Privacy

In June, we announced and launched End-To-End, a tool for those who need even more security for their communications than what we already provide. Today, we’re launching an updated version of our extension — still in alpha — that includes a number of changes:

• We’re migrating End-To-End to GitHub. We’ve always believed strongly that End-To-End must be an open source project, and we think that using GitHub will allow us to work together even better with the community.
• We’ve included several contributions from Yahoo Inc. Alex Stamos, Yahoo’s Chief Security Officer, announced at BlackHat 2014 in August that his team would be participating in our End-To-End project; we’re very happy to release the first fruits of this collaboration.
• We’ve added more documentation. The project wiki now contains additional information about End-To-End, both for developers as well as security researchers interested in understanding better how we think about End-To-End’s security model. 

We’re very thankful to all those who submitted bugs against the first alpha release. Two of those bugs earned a financial reward through our Vulnerability Rewards Program. One area where we didn’t receive many bug reports was in End-To-End’s new crypto library. On the contrary: we heard from several other projects who want to use our library, and we’re looking forward to working with them. 

One thing hasn’t changed for this release: we aren’t yet making End-To-End available in the Chrome Web Store. We don’t feel it’s as usable as it needs to be. Indeed, those looking through the source code will see references to our key server, and it should come as no surprise that we’re working on one. Key distribution and management is one of the hardest usability problems with cryptography-related products, and we won’t release End-To-End in non-alpha form until we have a solution we’re content with.

We’re excited to continue working on these challenging and rewarding problems, and we look forward to delivering a more fully fledged End-to-End next year.

Posted by Danesh Irani, Software Engineer, Gmail Security

(Cross-posted from the Gmail Blog)

We know that the safety and reliability of your Gmail is super important to you, which is why we’re always working on security improvements like serving images through secure proxy servers, and requiring HTTPS. Today, Gmail on the desktop is becoming more secure with support for Content Security Policy (CSP). CSP helps provide a layer of defense against a common class of security vulnerabilities known as cross-site scripting (XSS).

There are many great extensions for Gmail. Unfortunately, there are also some extensions that behave badly, loading code which interferes with your Gmail session, or which compromises your email’s security. Gmail’s CSP helps protect you, by making it more difficult to load unsafe code into Gmail.

Most popular (and well-behaved) extensions have already been updated to work with the CSP standard, but if you happen to have any trouble with an extension, try installing its latest version from your browser’s web store (for example, the Chrome Web Store for Chrome users).

CSP is just another example of how Gmail can help make your email experience safer. For advice and tools that help keep you safe across the web, you can always visit the Google Security Center.

This post was updated on December 18th to add a description of the XSS defense benefit of CSP, and to more precisely define the interaction with extensions.

Posted by Vinay Shet, Product Manager, reCAPTCHA

reCAPTCHA protects the websites you love from spam and abuse. So, when you go online—say, for some last-minute holiday shopping—you won't be competing with robots and abusive scripts to access sites. For years, we’ve prompted users to confirm they aren’t robots by asking them to read distorted text and type it into a box, like this:

But, we figured it would be easier to just directly ask our users whether or not they are robots—so, we did! We’ve begun rolling out a new API that radically simplifies the reCAPTCHA experience. We’re calling it the “No CAPTCHA reCAPTCHA” and this is how it looks:

On websites using this new API, a significant number of users will be able to securely and easily verify they’re human without actually having to solve a CAPTCHA. Instead, with just a single click, they’ll confirm they are not a robot.

A brief history of CAPTCHAs 

While the new reCAPTCHA API may sound simple, there is a high degree of sophistication behind that modest checkbox. CAPTCHAs have long relied on the inability of robots to solve distorted text. However, our research recently showed that today’s Artificial Intelligence technology can solve even the most difficult variant of distorted text at 99.8% accuracy. Thus distorted text, on its own, is no longer a dependable test.

To counter this, last year we developed an Advanced Risk Analysis backend for reCAPTCHA that actively considers a user’s entire engagement with the CAPTCHA—before, during, and after—to determine whether that user is a human. This enables us to rely less on typing distorted text and, in turn, offer a better experience for users.  We talked about this in our Valentine’s Day post earlier this year.

The new API is the next step in this steady evolution. Now, humans can just check the box and in most cases, they’re through the challenge.

Are you sure you’re not a robot?

However, CAPTCHAs aren't going away just yet. In cases when the risk analysis engine can't confidently predict whether a user is a human or an abusive agent, it will prompt a CAPTCHA to elicit more cues, increasing the number of security checkpoints to confirm the user is valid.

Making reCAPTCHAs mobile-friendly

This new API also lets us experiment with new types of challenges that are easier for us humans to use, particularly on mobile devices. In the example below, you can see a CAPTCHA based on a classic Computer Vision problem of image labeling. In this version of the CAPTCHA challenge, you’re asked to select all of the images that correspond with the clue. It's much easier to tap photos of cats or turkeys than to tediously type a line of distorted text on your phone.

Adopting the new API on your site

As more websites adopt the new API, more people will see "No CAPTCHA reCAPTCHAs".  Early adopters, like Snapchat, WordPress, Humble Bundle, and several others are already seeing great results with this new API. For example, in the last week, more than 60% of WordPress’ traffic and more than 80% of Humble Bundle’s traffic on reCAPTCHA encountered the No CAPTCHA experience—users got to these sites faster. To adopt the new reCAPTCHA for your website, visit our site to learn more.

Humans, we'll continue our work to keep the Internet safe and easy to use. Abusive bots and scripts, it’ll only get worse—sorry we’re (still) not sorry.

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