Google Online Security Blog: 2010

Quick update on our vulnerability reward program

11 November 2010

Posted by Matt Moore, Michal Zalewski, Adam Mein, Chris Evans; Google Security Teamweb vulnerability reward programclarifiedoriginal postclarification

Rewarding web application security research

1 November 2010

Posted by Chris Evans, Neel Mehta, Adam Mein, Matt Moore, and Michal Zalewski; Google Security Teamlaunched a well-received vulnerability reward programHall of Fameour credits pageQ) What applications are in scope?

*.google.com

*.youtube.com

*.blogger.com

*.orkut.com

UPDATE: We also recommend reading our additional thoughts about these guidelines to help clarify what types of applications and bugs are eligible for this program.

Q) What classes of bug are in scope?
A) It's difficult to provide a definitive list of vulnerabilities that will be rewarded; however, any serious bug which directly affects the confidentiality or integrity of user data may be in scope. We anticipate most rewards will be in bug categories such as:

XSS
XSRF / CSRF
XSSI (cross-site script inclusion)
Bypassing authorization controls (e.g. User A can access User B's private data)
Server side code execution or command injection

Out of concern for the availability of our services to all users, we ask you to refrain from using automated testing tools.

These categories of bugs are definitively excluded:

attacks against Google’s corporate infrastructure
social engineering and physical attacks
denial of service bugs
non-web application vulnerabilities, including vulnerabilities in client applications
SEO blackhat techniques
vulnerabilities in Google-branded websites hosted by third parties
bugs in technologies recently acquired by Google

Q) How far should I go to demonstrate a vulnerability?
A) Please, only ever target your own account or a test account. Never attempt to access anyone else's data. Do not engage in any activity that bombards Google services with large numbers of requests or large volumes of data.

Q) I've found a vulnerability — how do I report it?
A) Contact details are listed here. Please only use the email address given for actual vulnerabilities in Google products. Non-security bugs and queries about problems with your account should should instead be directed to the Google Help Centers.

Q) What reward might I get?
A) The base reward for qualifying bugs is $500. If the rewards panel finds a particular bug to be severe or unusually clever, rewards of up to $3,133.7 may be issued. The panel may also decide a single report actually constitutes multiple bugs requiring reward, or that multiple reports constitute only a single reward.

We understand that some researchers aren’t interested in the money, so we’d also like to give you the option to donate your reward to charity. If you do, we'll match it — subject to our discretion.

Regardless of whether you're rewarded monetarily or not, all vulnerability reporters who interact with us in a respectful, productive manner will be credited on a new vulnerability reporter page. If we file a bug internally, you'll be credited.

Superstar performers will continue to be acknowledged under the "We Thank You" section of this page.

Q) How do I find out if my bug qualified for a reward?
A) You will receive a comment to this effect in an emailed response from the Google Security Team.

Q) What if someone else also found the same bug?
A) Only the first report of a given issue that we had not yet identified is eligible. In the event of a duplicate submission, only the earliest received report is considered.

Q) Will bugs disclosed without giving Google developers an opportunity to fix them first still qualify?
A) We believe handling vulnerabilities responsibly is a two-way street. It's our job to fix serious bugs within a reasonable time frame, and we in turn request advance, private notice of any issues that are uncovered. Vulnerabilities that are disclosed to any party other than Google, except for the purposes of resolving the vulnerability (for example, an issue affecting multiple vendors), will usually not qualify. This includes both full public disclosure and limited private release.

Q) Do I still qualify if I disclose the problem publicly once fixed?
A) Yes, absolutely! We encourage open collaboration. We will also make sure to credit you on our new vulnerability reporter page.

Q) Who determines whether a given bug is eligible?
A) Several members of the Google Security Team including Chris Evans, Neel Mehta, Adam Mein, Matt Moore, and Michal Zalewski.

Q) Are you going to list my name on a public web page?
A) Only if you want us to. If selected as the recipient of a reward, and you accept, we will need your contact details in order to pay you. However, at your discretion, you can choose not to be listed on any credit page.

Q) No doubt you wanted to make some legal points?
A) Sure. We encourage broad participation. However, we are unable to issue rewards to individuals who are on sanctions lists, or who are in countries (e.g. Cuba, Iran, North Korea, Sudan and Syria) on sanctions lists. This program is also not open to minors. You are responsible for any tax implications depending on your country of residency and citizenship. There may be additional restrictions on your ability to enter depending upon your local law.

This is not a competition, but rather an experimental and discretionary rewards program. You should understand that we can cancel the program at any time, and the decision as to whether or not to pay a reward has to be entirely at our discretion.

Of course, your testing must not violate any law, or disrupt or compromise any data that is not your own.

Thank you for helping us to make Google's products more secure. We look forward to issuing our first reward in this new program.

This Internet is Your Internet: Digital Citizenship from California to Washtenaw County

21 October 2010

Posted by Adrienne St. Aubin, Public Policy AnalystNational Cyber Security Awareness MonthWashtenaw Cyber Citizenship Coalitionstaysafeonline.orgstopthinkconnect.orgonguardonline.gov

Protecting your data in the cloud

15 October 2010

Posted by Priya Nayak, Consumer Operations, Google Accounts“Mugged in London” phishing scamNational Cyber Security Awareness monthStay one step ahead of the bad guys

Password re-use: You sign up for an account on a third-party site with your Google username and password. If that site is hacked and your sign-in information is discovered, the hijacker has easy access to your Google Account.
Malware: You use a computer with infected software that is designed to steal your passwords as you type (“keylogging”) or grab them from your browser’s cache data.
Phishing: You respond to a website, email, or phone call that claims to come from a legitimate organization and asks for your username and password.
Brute force: You use a password that’s easy to guess, like your first or last name plus your birth date (“Laura1968”), or you provide an answer to a secret question that’s common and therefore easy to guess, like “pizza” for “What is your favorite food?”

As you can see, hijackers have many tactics for stealing your password, and it’s important to be aware of all of them.

Take control of your account security across the web

Online accounts that share passwords are like a line of dominoes: When one falls, it doesn’t take much for the others to fall, too. This is why you should choose unique passwords for important accounts like Gmail (your Google Account), your bank, commerce sites, and social networking sites. We’re also working on technology that adds another layer of protection beyond your password to make your Google Account significantly more secure.

Choosing a unique password is not enough to secure your Google Account against every possible threat. That’s why we’ve created an easy-to-use checklist to help you secure your computer, browser, Gmail, and Google Account. We encourage you to go through the entire checklist, but want to highlight these tips:

Never re-use passwords for your important accounts like online banking, email, social networking, and commerce.
Change your password periodically, and be sure to do so for important accounts whenever you suspect one of them may have been at risk. Don’t just change your password by a few letters or numbers (“Aquarius5” to “Aquarius6”); change the combination of letters and numbers to something unique each time.
Never respond to messages, non-Google websites, or phone calls asking for your Google username or password; a legitimate organization will not ask you for this type of information. Report these messages to us so we can take action. If you responded and can no longer access your account, visit our account recovery page.

We hope you’ll take action to ensure your security across the web, not just on Google. Run regular virus scans, don’t re-use your passwords, and keep your software and account recovery information up to date. These simple yet powerful steps can make a difference when it really counts.

Phishing URLs and XML Notifications

14 October 2010

Posted by Nav Jagpal, Security teamSafe Browsing Alerts for Network AdministratorsXML Schemahere

Safe Browsing Alerts for Network Administrators

28 September 2010

Posted by Nav Jagpal and Ke Wang, Security Teamattempt to notifyWebmaster Tools featureGoogle Safe Browsing Alerts for Network AdministratorsAutonomous Systemsafebrowsingalerts.googlelabs.com

Moving security beyond passwords

20 September 2010

Posted by Travis McCoy, Product Manager, Google Security Team

Entering your username and password on a standard website gives you access to everything from your email and bank accounts to your favorite social networking site. Your passwords possess a lot of power, so it's critical to keep them from falling into the wrong hands. Unfortunately, we often find that passwords are the weakest link in the security chain. Keeping track of many passwords is a pain, and unfortunately accounts are regularly compromised when passwords are too weak, are reused across websites, or when people are tricked into sharing their password with someone untrustworthy. These are difficult industry problems to solve, and when re-thinking the traditional username/password design, we wanted to do more.

As we explained today on our Google Enterprise Blog, we've developed an option to add two-step verification to Google Apps accounts. When signing in, Google will send a verification code to your phone, or let you generate one yourself using an application on your Android, BlackBerry or iPhone device. Entering this code, in addition to a normal password, gives us a strong indication that the person signing in is actually you. This new feature significantly improves the security of your Google Account, as it requires not only something you know: your username and password, but also something that only you should have: your phone. Even if someone has stolen your password, they'll need more than that to access your account.

blog serieshttp://www.staysafeonline.org/

Stay safe while browsing

16 September 2010

Posted by Panayiotis Mavrommatis and Niels Provos, Security Team
We are constantly working on detecting sites that are compromised or are deliberately set up to infect your machine while browsing the web. We provide warnings on our search results and to browsers such as Firefox and Chrome. A lot of the warnings take people by surprise — they can trigger on your favorite news site, a blog you read daily, or another site you would never consider to be involved in malicious activities.

In fact, it’s very important to heed these warnings because they show up for sites that are under attack. We are very confident with the results of our scanners that create these warnings, and we work with webmasters to show where attack code was injected. As soon as we think the site has been cleaned up, we lift the warning.

This week in particular, a lot of web users have become vulnerable. A number of live public exploits were attacking the latest versions of some very popular browser plug-ins. Our automated detection systems encounter these attacks every day, e.g. exploits against PDF (CVE-2010-2883), Quicktime (CVE-2010-1818) and Flash (CVE-2010-2884).

We found it interesting that we discovered the PDF exploit on the same page as a more “traditional” fake anti-virus page, in which users are prompted to install an executable file. So, even if you run into a fake anti-virus page and ignore it, we suggest you run a thorough anti-virus scan on your machine.

We and others have observed that once a vulnerability has been exploited and announced, it does not take long for it to be abused widely on the web. For example, the stack overflow vulnerability in PDF was announced on September 7th, 2010, and the Metasploit project made an exploit module available only one day later. Our systems found the vulnerability abused across multiple exploit sites on September 13th.

Here’s a few suggestions for protecting yourself against web attacks:

Keep your OS, browser, and browser plugins up-to-date.
Run anti-virus software, and keep this up-to-date, too.
Disable or uninstall any software or browser plug-ins you don’t use — this reduces your vulnerability surface.
If you receive a PDF attachment in Gmail, select “View” to view it in Gmail instead of downloading it.

Vulnerability trends: how are companies really doing?

30 August 2010

Posted by Adam Mein, Google Security Teamissued a correctionterminology mix-up

Vendors disclose their vulnerabilities in inconsistent formats, using different severity classifications. This makes the process of measuring the number of total vulnerabilities assigned to a given vendor much more difficult.

Assessing the severity, scope, and nature of a bug sometimes requires intimate knowledge of a product or technology, and this can lead to errors and misinterpretation.

Keeping the fix status updated for thousands of entries is no small task, and we’ve consistently seen long-fixed errors marked as unfixed in a number of databases.

Not all compilers of vulnerability databases perform their own independent verification of bugs they find reported from other sources. As a result, errors in one source can be replicated to others.

Rebooting Responsible Disclosure: a focus on protecting end users

20 July 2010

Posted by Chris Evans, Eric Grosse, Neel Mehta, Matt Moore, Tavis Ormandy, Julien Tinnes, Michal Zalewski; Google Security Team 2001 post by Bruce Schneier

0-day attacks that rely on vulnerabilities known to the vendor for a long while.

Situations where it became clear that a vulnerability was being actively exploited in the wild, subsequent to the bug being fixed or disclosed.

Chromium severity guidelinesMozilla severity ratings

Placing a disclosure deadline on any serious vulnerability they report, consistent with complexity of the fix. (For example, a design error needs more time to address than a simple memory corruption bug).

Responding to a missed disclosure deadline or refusal to address the problem by publishing an analysis of the vulnerability, along with any suggested workarounds.

Setting an aggressive disclosure deadline where there exists evidence that blackhats already have knowledge of a given bug.

Update September 10, 2010: We'd like to clarify a few of the points above about how we approach the issue of vulnerability disclosure. While we believe vendors have an obligation to be responsive, the 60 day period before public notification about critical bugs is not intended to be a punishment for unresponsive vendors. We understand that not all bugs can be fixed in 60 days, although many can and should be. Rather, we thought of 60 days when considering how large the window of exposure for a critical vulnerability should be permitted to grow before users are best served by hearing enough details to make a decision about implementing possible mitigations, such as disabling a service, restricting access, setting a killbit, or contacting the vendor for more information. In most cases, we don't feel it's in people's best interest to be kept in the dark about critical vulnerabilities affecting their software for any longer period.
Update May 12, 2021: February 2015, Google's responsible discloure policy was adjusted to 90 days. View our current policy here.

Extending SSL to Google search

21 May 2010

Posted by Murali Viswanathan, Product Managerdefault settinghttps://www.google.comOfficial Google Blog

Do Know Evil: web application vulnerabilities

4 May 2010

Posted by Bruce Leban, Software EngineerUPDATE July 13: We have changed the name of the codelab application to Gruyere. The codelab is now located at http://google-gruyere.appspot.com.Google Code UniversityGoogle Labshttp://google-gruyere.appspot.comGoogle Code University

The Rise of Fake Anti-Virus

14 April 2010

Posted by Niels Provos, Security Team

The Nocebo Effect on the Web: An Analysis of Fake AV distributionWorkshop on Large-Scale Exploits and Emergent Threats

trusted companies

The chilling effects of malware

30 March 2010

Posted by Neel Mehta, Security Teamdiscussedsuspicious account activity alerts

Phishing phree

30 March 2010

Posted by Colin Whittaker, Anti-Phishing Team phishingSafeBrowsing APIpaper17th Annual Network and Distributed System Security SymposiumWhat we look for

Our system analyzes a number of webpage features to help make a verdict about whether a site is a phishing site. Starting with a page’s URL, we look to see if there is anything unusual about the host, such as whether the hostname is unusually long or whether the URL uses an IP address to specify the host. We also look to see if the URL contains any phrases like “banking” or “login” that might indicate that the page is trying to steal information.

We don’t just look at the URL, though. After all, a perfectly legitimate site could certainly use words like “banking” or “login.” We collect a snapshot of the page’s content to examine it closely for phishing behavior. For example, we check to see if the page has a password field or whether most of the links point to a common phishing target, as both of these characteristics can be a sign of phishing. Additionally, we pick out some of the most characteristic terms that show up on a page (as defined by their TF-IDF scores), and look for terms like “password” or “PIN number,” which also may indicate that the page is intended for phishing.

We also check the page’s hosting information to find out which networks host the page and where the page’s servers are located geographically. If a site purporting to be an American bank runs its servers in a different country and is hosted on a local residential ISP’s network, we have a strong signal that the site is bad.

Finally, we check the page’s PageRank to see if the page is popular or not, and we check the spam reputation of the page’s domain. We discovered in our research findings that almost all phishing pages are found on domains that almost exclusively send spam. You can observe this trend in the CCDF graph of the spam reputation scores for phishing pages as compared to the graph of other, non-phishing pages.

How we learn to recognize phishing pages
We use a sample of the data that our system generates to train the classifier that lies at the core of our automatic system using a machine learning algorithm. Coming up with good labels (phishing/not phishing) for this data is tricky because we can’t label each of the millions of pages ourselves. Instead, we use our published phishing page list, largely generated by our classifier, to assign labels for the training data.

You might be wondering if this system is going to lead to situations where the classifier makes a mistake, puts that mistake on our list, and then uses the list to learn to make more mistakes. Fortunately, the chain doesn’t make it that far. Our classifier only makes a relatively small number of mistakes, which we can correct manually when you report them to us. Our learning algorithms can handle a few temporary errors in the training labels, and the overall learning process remains stable.

How well does this work?

Of the millions of webpages that our scanners analyze for phishing, we successfully identify 9 out of 10 phishing pages. Our classification system only incorrectly flags a non-phishing site as a phishing site about 1 in 10,000 times, which is significantly better than similar systems. In our experience, these “false positive” sites are usually built to distribute spam or may be involved with other suspicious activity. While phishers are constantly changing their strategies, we find that they do not change them enough to reliably escape our system. Our experiments showed that our classification system remained effective for over a month without retraining.

If you are a webmaster and would like more information about how to keep your site from looking like a phishing site, please check out our post on the Webmaster Central Blog. If you find that your site has been added to our phishing page list ("Reported Web Forgery!") by mistake, please report the error to us.

Detecting suspicious account activity

24 March 2010

Gmail BlogPosted by Pavni Diwanji, Engineering Directorremote sign out and information about recent account activity

IP addressGmail privacy policy

keeping your information secureGoogle Online Security Blog

Meet skipfish, our automated web security scanner

19 March 2010

Posted by Michal ZalewskiratproxyBrowser Security Handbookimprove the security of third-party browsersskipfish

High speed: written in pure C, with highly optimized HTTP handling and a minimal CPU footprint, the tool easily achieves 2000 requests per second with responsive targets.

Ease of use: the tool features heuristics to support a variety of quirky web frameworks and mixed-technology sites, with automatic learning capabilities, on-the-fly wordlist creation, and form autocompletion.

Cutting-edge security logic: we incorporated high quality, low false positive, differential security checks capable of spotting a range of subtle flaws, including blind injection vectors.

ratproxyskipfishthis pageavailable here

Federal Support for Federated Login

3 March 2010

Posted by Eric Sachs, Senior Product Manager, Google Securitydiscussed the progressOpenIDcreation of a pilot initiativeOpen Identity Exchange (OIX)today namedready to accept

Security Blog