Security Blog
The latest news and insights from Google on security and safety on the Internet
Security Reward Programs: Year in Review, Year in Preview
January 30, 2015
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!
An Update to End-To-End
December 16, 2014
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.
Reject the Unexpected - Content Security Policy in Gmail
December 16, 2014
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.
Are you a robot? Introducing “No CAPTCHA reCAPTCHA”
December 3, 2014
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.
Ready, aim, fire: an open-source tool to test web security scanners
November 18, 2014
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
Behind enemy lines in our war against account hijackers
November 6, 2014
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
click to see full-size infographic
Introducing nogotofail—a network traffic security testing tool
November 4, 2014
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
Learning statistics with privacy, aided by the flip of a coin
October 30, 2014
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
Strengthening 2-Step Verification with Security Key
October 21, 2014
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
This POODLE bites: exploiting the SSL 3.0 fallback
October 14, 2014
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.]
Labels
#sharethemicincyber
#supplychain #security #opensource
android
android security
android tr
app security
big data
biometrics
blackhat
C++
chrome
chrome enterprise
chrome security
connected devices
CTF
diversity
encryption
federated learning
fuzzing
Gboard
google play
google play protect
hacking
interoperability
iot security
kubernetes
linux kernel
memory safety
Open Source
pha family highlights
pixel
privacy
private compute core
Rowhammer
rust
Security
security rewards program
sigstore
spyware
supply chain
targeted spyware
tensor
Titan M2
VDP
vulnerabilities
workshop
Archive
2024
May
Apr
Mar
Feb
Jan
2023
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2022
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2021
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2020
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2019
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2018
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2017
Dec
Nov
Oct
Sep
Jul
Jun
May
Apr
Mar
Feb
Jan
2016
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2015
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2014
Dec
Nov
Oct
Sep
Aug
Jul
Jun
Apr
Mar
Feb
Jan
2013
Dec
Nov
Oct
Aug
Jun
May
Apr
Mar
Feb
Jan
2012
Dec
Sep
Aug
Jun
May
Apr
Mar
Feb
Jan
2011
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
2010
Nov
Oct
Sep
Aug
Jul
May
Apr
Mar
2009
Nov
Oct
Aug
Jul
Jun
Mar
2008
Dec
Nov
Oct
Aug
Jul
May
Feb
2007
Nov
Oct
Sep
Jul
Jun
May
Feed
Follow @google
Follow
Give us feedback in our
Product Forums
.