Google Data » Jay

Security rewards at Google: Two MEEELLION Dollars Later

Jay — Mon, 12 Aug 2013 19:55:00 +0000

Posted by Chris Evans and Adam Mein, Masters of Coin

One of Google’s core security principles is to engage the community, to better protect our users and build relationships with security researchers. We had this principle in mind as we launched our Chromium and Google Web Vulnerability Reward Programs. We didn’t know what to expect, but in the three years since launch, we’ve rewarded (and fixed!) more than 2,000 security bug reports and also received recognition for setting leading standards for response time.

The collective creativity of the wider security community has surpassed all expectations, and their expertise has helped make Chrome even safer for hundreds of millions of users around the world. Today we’re delighted to announce we’ve now paid out in excess of $2,000,000 (USD) across Google’s security reward initiatives. Broken down, this total includes more than $1,000,000 (USD) for the Chromium VRP / Pwnium rewards, and in excess of $1,000,000 (USD) for the Google Web VRP rewards.

Today, the Chromium program is raising reward levels significantly. In a nutshell, bugs previously rewarded at the $1,000 level will now be considered for reward at up to $5,000. In many cases, this will be a 5x increase in reward level! We’ll issue higher rewards for bugs we believe present a more significant threat to user safety, and when the researcher provides an accurate analysis of exploitability and severity. We will continue to pay previously announced bonuses on top, such as those for providing a patch or finding an issue in a critical piece of open source software.

Interested Chromium researchers should familiarize themselves with our documentation on how to report a security bug well and how we determine higher reward eligibility.

These Chromium reward level increases follow on from similar increases under the Google Web program. With all these new levels, we’re excited to march towards new milestones and a more secure web.

Transparency Report: Making the web a safer place

Jay — Tue, 25 Jun 2013 15:08:00 +0000

Posted by Lucas Ballard, Software Engineer

[Cross-posted from the Official Google Blog]

Two of the biggest threats online are malicious software (known as malware) that can take control of your computer, and phishing scams that try to trick you into sharing passwords or other private information.

So in 2006 we started a Safe Browsing program to find and flag suspect websites. This means that when you are surfing the web, we can now warn you when a site is unsafe. We're currently flagging up to 10,000 sites a day—and because we share this technology with other browsers there are about 1 billion users we can help keep safe.

But we're always looking for new ways to protect users' security. So today we're launching a new section on our Transparency Report that will shed more light on the sources of malware and phishing attacks. You can now learn how many people see Safe Browsing warnings each week, where malicious sites are hosted around the world, how quickly websites become reinfected after their owners clean malware from their sites, and other tidbits we’ve surfaced.

Sharing this information also aligns well with our Transparency Report, which already gives information about government requests for user data, government requests to remove content, and current disruptions to our services.

To learn more, explore the new Safe Browsing information on this page. Webmasters and network administrators can find recommendations for dealing with malware infections, including resources like Google Webmaster Tools and Safe Browsing Alerts for Network Administrators.

Iranian phishing on the rise as elections approach

Jay — Wed, 12 Jun 2013 22:00:00 +0000

Posted by Eric Grosse, VP Security Engineering

[Update June 13: This post is available in Farsi on the Google Persian Blog.]

For almost three weeks, we have detected and disrupted multiple email-based phishing campaigns aimed at compromising the accounts owned by tens of thousands of Iranian users. These campaigns, which originate from within Iran, represent a significant jump in the overall volume of phishing activity in the region. The timing and targeting of the campaigns suggest that the attacks are politically motivated in connection with the Iranian presidential election on Friday.

Our Chrome browser previously helped detect what appears to be the same group using SSL certificates to conduct attacks that targeted users within Iran. In this case, the phishing technique we detected is more routine: users receive an email containing a link to a web page that purports to provide a way to perform account maintenance. If the user clicks the link, they see a fake Google sign-in page that will steal their username and password.

Protecting our users’ accounts is one of our top priorities, so we notify targets of state-sponsored attacks and other suspicious activity, and we take other appropriate actions to limit the impact of these attacks on our users. Especially if you are in Iran, we encourage you to take extra steps to protect your account. Watching out for phishing, using a modern browser like Chrome and enabling 2-step verification can make you significantly more secure against these and many other types of attacks. Also, before typing your Google password, always verify that the URL in the address bar of your browser begins with https://accounts.google.com/. If the website's address does not match this text, please don’t enter your Google password.

Increased rewards for Google’s Web Vulnerability Reward Program

Jay — Thu, 06 Jun 2013 22:38:00 +0000

Posted by Adam Mein and Michal Zalewski, Security Team

Our vulnerability reward programs have been very successful in helping us fix more bugs and better protect our users, while also strengthening our relationships with security researchers. Since introducing our reward program for web properties in November 2010, we’ve received over 1,500 qualifying vulnerability reports that span across Google’s services, as well as software written by companies we have acquired. We’ve paid $828,000 to more than 250 individuals, some of whom have doubled their total by donating their rewards to charity. For example, one of our bug finders decided to support a school project in East Africa.

In recognition of the difficulty involved in finding bugs in our most critical applications, we’re once again rolling out updated rules and significant reward increases for another group of bug categories:

Cross-site scripting (XSS) bugs on https://accounts.google.com now receive a reward of $7,500 (previously $3,133.7). Rewards for XSS bugs in other highly sensitive services such as Gmail and Google Wallet have been bumped up to $5,000 (previously $1,337), with normal Google properties increasing to $3,133.70 (previously $500).
The top reward for significant authentication bypasses / information leaks is now $7,500 (previously $5,000).

As always, happy bug hunting! If you do find a security problem, please let us know.

Disclosure timeline for vulnerabilities under active attack

Jay — Wed, 29 May 2013 21:45:00 +0000

Posted by Chris Evans and Drew Hintz, Security Engineers

We recently discovered that attackers are actively targeting a previously unknown and unpatched vulnerability in software belonging to another company. This isn’t an isolated incident -- on a semi-regular basis, Google security researchers uncover real-world exploitation of publicly unknown (“zero-day”) vulnerabilities. We always report these cases to the affected vendor immediately, and we work closely with them to drive the issue to resolution. Over the years, we’ve reported dozens of actively exploited zero-day vulnerabilities to affected vendors, including XML parsing vulnerabilities, universal cross-site scripting bugs, and targeted web application attacks.

Often, we find that zero-day vulnerabilities are used to target a limited subset of people. In many cases, this targeting actually makes the attack more serious than a broader attack, and more urgent to resolve quickly. Political activists are frequent targets, and the consequences of being compromised can have real safety implications in parts of the world.

Our standing recommendation is that companies should fix critical vulnerabilities within 60 days -- or, if a fix is not possible, they should notify the public about the risk and offer workarounds. We encourage researchers to publish their findings if reported issues will take longer to patch. Based on our experience, however, we believe that more urgent action -- within 7 days -- is appropriate for critical vulnerabilities under active exploitation. The reason for this special designation is that each day an actively exploited vulnerability remains undisclosed to the public and unpatched, more computers will be compromised.

Seven days is an aggressive timeline and may be too short for some vendors to update their products, but it should be enough time to publish advice about possible mitigations, such as temporarily disabling a service, restricting access, or contacting the vendor for more information. As a result, after 7 days have elapsed without a patch or advisory, we will support researchers making details available so that users can take steps to protect themselves. By holding ourselves to the same standard, we hope to improve both the state of web security and the coordination of vulnerability management.

Changes to our SSL Certificates

Jay — Thu, 23 May 2013 15:00:00 +0000

Posted by Stephen McHenry, Director of Information Security Engineering

Protecting the security and privacy of our users is one of our most important tasks at Google, which is why we utilize encryption on almost all connections made to Google.

This encryption needs to be updated at times to make it even stronger, so this year our SSL services will undergo a series of certificate upgrades—specifically, all of our SSL certificates will be upgraded to 2048-bit keys by the end of 2013. We will begin switching to the new 2048-bit certificates on August 1st, to ensure adequate time for a careful rollout before the end of the year. We’re also going to change the root certificate that signs all of our SSL certificates because it has a 1024-bit key.

Most client software won’t have any problems with either of these changes, but we know that some configurations will require some extra steps to avoid complications. This is more often true of client software embedded in devices such as certain types of phones, printers, set-top boxes, gaming consoles, and cameras.

For a smooth upgrade, client software that makes SSL connections to Google (e.g. HTTPS) must:

Perform normal validation of the certificate chain;
Include a properly extensive set of root certificates contained. We have an example set which should be sufficient for connecting to Google in our FAQ. (Note: the contents of this list may change over time, so clients should have a way to update themselves as changes occur);
Support Subject Alternative Names (SANs).

Also, clients should support the Server Name Indication (SNI) extension because clients may need to make an extra API call to set the hostname on an SSL connection. Any client unsure about SNI support can be tested against https://googlemail.com—this URL should only validate if you are sending SNI.

On the flip side, here are some examples of improper validation practices that could very well lead to the inability of client software to connect to Google using SSL after the upgrade:

Matching the leaf certificate exactly (e.g. by hashing it)
Matching any other certificate (e.g. Root or Intermediate signing certificate) exactly
Hard-coding the expected Root certificate, especially in firmware. This is sometimes done based on assumptions like the following:

The Root Certificate of our chain will not change on short notice.
Google will always use Thawte as its Root CA.
Google will always use Equifax as its Root CA.
Google will always use one of a small number of Root CAs.
The certificate will always contain exactly the expected hostname in the Common Name field and therefore clients do not need to worry about SANs.
The certificate will always contain exactly the expected hostname in a SAN and therefore clients don't need to worry about wildcards.

Any software that contains these improper validation practices should be changed. More detailed information can be found in this document, and you can also check out our FAQ if you have specific questions.

The results are in: Hardcode, the secure coding contest for App Engine

Jay — Fri, 10 May 2013 15:00:00 +0000

Posted by Eduardo Vela Nava, Security Team

This January, Google and SyScan announced a secure coding competition open to students from all over the world. While Google’s Summer of Code and Code-in encourage students to contribute to open source projects, Hardcode was a call for students who wanted to showcase their skills both in software development and security. Given the scope of today’s online threats, we think it’s incredibly important to practice secure coding habits early on. Hundreds of students from 25 countries and across five continents signed up to receive updates and information about the competition, and over 100 teams participated.

During the preliminary online round, teams built applications on Google App Engine that were judged for both functionality and security. Five teams were then selected to participate in the final round at the SyScan 2013 security conference in Singapore, where they had to do the following: fix security bugs from the preliminary round, collaborate to develop an API standard to allow their applications to interoperate, implement the API, and finally, try to hack each other’s applications. To add to the challenge, many of the students balanced the competition with all of their school commitments.

We’re extremely impressed with the caliber of the contestants’ work. Everyone had a lot of fun, and we think these students have a bright future ahead of them. We are pleased to announce the final results of the 2013 Hardcode Competition:

1st Place: Team 0xC0DEBA5E
Vienna University of Technology, Austria (SGD $20,000)
Daniel Marth (http://proggen.org/)
Lukas Pfeifhofer (https://www.devlabs.pro/)
Benedikt Wedenik

2nd Place: Team Gridlock
Loyola School, Jamshedpur, India (SGD $15,000)
Aviral Dasgupta (http://www.aviraldg.com/)

3rd Place: Team CeciliaSec
University of California, Santa Barbara, California, USA (SGD $10,000)
Nathan Crandall
Dane Pitkin
Justin Rushing

Runner-up: Team AppDaptor
The Hong Kong Polytechnic University, Hong Kong (SGD $5,000)
Lau Chun Wai (http://www.cwlau.com/)

Runner-up: Team DesiCoders
Birla Institute of Technology & Science, Pilani, India (SGD $5,000)
Yash Agarwal
Vishesh Singhal (http://visheshsinghal.blogspot.com)

Honorable Mention: Team Saviors of Middle Earth (withdrew due to school commitments)
Walt Whitman High School, Maryland, USA
Wes Kendrick
Marc Rosen (https://github.com/maz)
William Zhang

A big congratulations to this very talented group of students!

New warnings about potentially malicious binaries

Jay — Wed, 17 Apr 2013 16:02:00 +0000

Posted by Moheeb Abu Rajab, Security Team

If you use Chrome, you shouldn’t have to work hard to know what Chrome extensions you have installed and enabled. That’s why last December we announced that Chrome (version 25 and beyond) would disable silent extension installation by default. In addition to protecting users from unauthorized installations, these measures resulted in noticeable performance improvements in Chrome and improved user experience.

To further safeguard you while browsing the web, we recently added new measures to protect you and your computer. These measures will identify software that violates Chrome’s standard mechanisms for deploying extensions, flagging such binaries as malware. Within a week, you will start seeing Safe Browsing malicious download warnings when attempting to download malware identified by this criteria.

This kind of malware commonly tries to get around silent installation blockers by misusing Chrome’s central management settings that are intended be used to configure instances of Chrome internally within an organization. In doing so, the installed extensions are enabled by default and cannot be uninstalled or disabled by the user from within Chrome. Other variants include binaries that directly manipulate Chrome preferences in order to silently install and enable extensions bundled with these binaries. Our recent measures expand our capabilities to detect and block these types of malware.

Application developers should adhere to Chrome’s standard mechanisms for extension installation, which include the Chrome Web Store, inline installation, and the other deployment options described in the extensions development documentation.

Google Public DNS Now Supports DNSSEC Validation

Jay — Tue, 19 Mar 2013 15:30:00 +0000

Posted by Yunhong Gu, Team Lead, Google Public DNS

We launched Google Public DNS three years ago to help make the Internet faster and more secure. Today, we are taking a major step towards this security goal: we now fully support DNSSEC (Domain Name System Security Extensions) validation on our Google Public DNS resolvers. Previously, we accepted and forwarded DNSSEC-formatted messages but did not perform validation. With this new security feature, we can better protect people from DNS-based attacks and make DNS more secure overall by identifying and rejecting invalid responses from DNSSEC-protected domains.

DNS translates human-readable domain names into IP addresses so that they are accessible by computers. Despite its critical role in Internet applications, the lack of security protection for DNS up to this point meant that a significantly large portion of today’s Internet attacks target the name resolution process, attempting to return the IP addresses of malicious websites to DNS queries. Probably the most common DNS attack is DNS cache poisoning, which tries to “pollute” the cache of DNS resolvers (such as Google Public DNS or those provided by most ISPs) by injecting spoofed responses to upstream DNS queries.

To counter cache poisoning attacks, resolvers must be able to verify the authenticity of the response. DNSSEC solves the problem by authenticating DNS responses using digital signatures and public key cryptography. Each DNS zone maintains a set of private/public key pairs, and for each DNS record, a unique digital signature is generated and encrypted using the private key. The corresponding public key is then authenticated via a chain of trust by keys of upper-level zones. DNSSEC effectively prevents response tampering because in practice, signatures are almost impossible to forge without access to private keys. Also, the resolvers will reject responses without correct signatures.

DNSSEC is a critical step towards securing the Internet. By validating data origin and data integrity, DNSSEC complements other Internet security mechanisms, such as SSL. It is worth noting that although we have used web access in the examples above, DNS infrastructure is widely used in many other Internet applications, including email.

Currently Google Public DNS is serving more than 130 billion DNS queries on average (peaking at 150 billion) from more than 70 million unique IP addresses each day. However, only 7% of queries from the client side are DNSSEC-enabled (about 3% requesting validation and 4% requesting DNSSEC data but no validation) and about 1% of DNS responses from the name server side are signed. Overall, DNSSEC is still at an early stage and we hope that our support will help expedite its deployment.

Effective deployment of DNSSEC requires action from both DNS resolvers and authoritative name servers. Resolvers, especially those of ISPs and other public resolvers, need to start validating DNS responses. Meanwhile, domain owners have to sign their domains. Today, about 1/3 of top-level domains have been signed, but most second-level domains remain unsigned. We encourage all involved parties to push DNSSEC deployment and further protect Internet users from DNS-based network intrusions.

For more information about Google Public DNS, please visit: https://developers.google.com/speed/public-dns. In particular, more details about our DNSSEC support can be found in the FAQ and Security pages. Additionally, general specifications of the DNSSEC standard can be found in RFCs 4033, 4034, 4035, and 5155.

Update March 21: We've been listening to your questions and would like to clarify that validation is not yet enabled for non-DNSSEC aware clients. As a first step, we launched DNSSEC validation as an opt-in feature and will only perform validation if clients explicitly request it. We're going to work to minimize the impact of any DNSSEC misconfigurations that could cause connection breakages before we enable validation by default for all clients that have not explicitly opted out.

Update May 6: We've enabled DNSSEC validation by default. That means all clients are now protected and responses to all queries will be validated unless clients explicitly opt out.

Calling student coders: Hardcode, the secure coding contest for App Engine

Jay — Thu, 10 Jan 2013 19:17:00 +0000

Posted by Parisa Tabriz, Security Team

Protecting user security and privacy is a huge responsibility, and software security is a big part of it. Learning about new ways to “break” applications is important, but learning preventative skills to use when “building” software, like secure design and coding practices, is just as critical. To help promote secure development habits, Google is once again partnering with the organizers of SyScan to host Hardcode, a secure coding contest on the Google App Engine platform.

Participation will be open to teams of up to 5 full-time students (undergraduate or high school, additional restrictions may apply). Contestants will be asked to develop open source applications that meet a set of functional and security requirements. The contest will consist of two rounds: a qualifying round over the Internet, with broad participation from any team of students, and a final round, to be held during SyScan on April 23-25 in Singapore.

During the qualifying round, teams will be tasked with building an application and describing its security design. A panel of judges will assess all submitted applications and select the top five to compete in the final round.

At SyScan, the five finalist teams will be asked to develop a set of additional features and fix any security flaws identified in their qualifying submission. After two more days of hacking, a panel of judges will rank the projects and select a grand prize winning team that will receive $20,000 Singapore dollars. The 2nd-5th place finalist teams will receive $15,000, $10,000, $5,000, and $5,000 Singapore dollars, respectively.

Hardcode begins on Friday, January 18th. Full contest details will be be announced via our mailing list, so subscribe there for more information!

Enhancing digital certificate security

Jay — Thu, 03 Jan 2013 18:01:00 +0000

Posted by Adam Langley, Software Engineer

Late on December 24, Chrome detected and blocked an unauthorized digital certificate for the "*.google.com" domain. We investigated immediately and found the certificate was issued by an intermediate certificate authority (CA) linking back to TURKTRUST, a Turkish certificate authority. Intermediate CA certificates carry the full authority of the CA, so anyone who has one can use it to create a certificate for any website they wish to impersonate.

In response, we updated Chrome’s certificate revocation metadata on December 25 to block that intermediate CA, and then alerted TURKTRUST and other browser vendors. TURKTRUST told us that based on our information, they discovered that, in August 2011, they had mistakenly issued two intermediate CA certificates to organizations that should have instead received regular SSL certificates. On December 26, we pushed another Chrome metadata update to block the second mistaken CA certificate and informed the other browser vendors.

Our actions addressed the immediate problem for our users. Given the severity of the situation, we will update Chrome again in January to no longer indicate Extended Validation status for certificates issued by TURKTRUST, though connections to TURKTRUST-validated HTTPS servers may continue to be allowed.

Since our priority is the security and privacy of our users, we may also decide to take additional action after further discussion and careful consideration.

Adding OAuth 2.0 support for IMAP/SMTP and XMPP to enhance auth security

Jay — Mon, 17 Sep 2012 18:49:00 +0000

Posted by Ryan Troll, Application Security Team

(Cross-posted from the Google Developers Blog)

Our users and developers take password security seriously and so do we. Passwords alone have weaknesses we all know about, so we’re working over the long term to support additional mechanisms to help protect user information. Over a year ago, we announced a recommendation that OAuth 2.0 become the standard authentication mechanism for our APIs so you can make the safest apps using Google platforms. You can use OAuth 2.0 to build clients and websites that securely access account data and work with our advanced security features, such as 2-step verification. But our commitment to OAuth 2.0 is not limited to web APIs. Today we’re going a step further by adding OAuth 2.0 support for IMAP/SMTP and XMPP. Developers using these protocols can now move to OAuth 2.0, and users will experience the benefits of more secure OAuth 2.0 clients.

When clients use OAuth 2.0, they never ask users for passwords. Users have tighter control over what data clients have access to, and clients never see a user's password, making it much harder for a password to be stolen. If a user has their laptop stolen, or has any reason to believe that a client has been compromised, they can revoke the client’s access without impacting anything else that has access to their data.

We are also announcing the deprecation of older authentication mechanisms. If you’re using these you should move to the new OAuth 2.0 APIs.

We are deprecating XOAUTH for IMAP/SMTP, as it uses OAuth 1.0a, which was previously deprecated. Gmail will continue to support XOAUTH until OAuth 1.0a is shut down, at which time support will be discontinued.
We are also deprecating X-GOOGLE-TOKEN and SASL PLAIN for XMPP, as they either accept passwords or rely on the previously deprecated ClientLogin. These mechanisms will continue to be supported until ClientLogin is shut down, at which time support for both will be discontinued.

Our team has been working hard since we announced our support of OAuth in 2008 to make it easy for you to create applications that use more secure mechanisms than passwords to protect user information. Check out the Google Developers Blog for examples, including the OAuth 2.0 Playground and Service Accounts, or see Using OAuth 2.0 to Access Google APIs.

Content hosting for the modern web

Jay — Wed, 29 Aug 2012 16:45:00 +0000

Posted by Michal Zalewski, Security Team

Our applications host a variety of web content on behalf of our users, and over the years we learned that even something as simple as serving a profile image can be surprisingly fraught with pitfalls. Today, we wanted to share some of our findings about content hosting, along with the approaches we developed to mitigate the risks.

Historically, all browsers and browser plugins were designed simply to excel at displaying several common types of web content, and to be tolerant of any mistakes made by website owners. In the days of static HTML and simple web applications, giving the owner of the domain authoritative control over how the content is displayed wasn’t of any importance.

It wasn’t until the mid-2000s that we started to notice a problem: a clever attacker could manipulate the browser into interpreting seemingly harmless images or text documents as HTML, Java, or Flash—thus gaining the ability to execute malicious scripts in the security context of the application displaying these documents (essentially, a cross-site scripting flaw). For all the increasingly sensitive web applications, this was very bad news.

During the past few years, modern browsers began to improve. For example, the browser vendors limited the amount of second-guessing performed on text documents, certain types of images, and unknown MIME types. However, there are many standards-enshrined design decisions—such as ignoring MIME information on any content loaded through <object> , <embed> , or <applet> —that are much more difficult to fix; these practices may lead to vulnerabilities similar to the GIFAR bug.

Google’s security team played an active role in investigating and remediating many content sniffing vulnerabilities during this period. In fact, many of the enforcement proposals were first prototyped in Chrome. Even still, the overall progress is slow; for every resolved problem, researchers discover a previously unknown flaw in another browser mechanism. Two recent examples are the Byte Order Mark (BOM) vulnerability reported to us by Masato Kinugawa, or the MHTML attacks that we have seen happening in the wild.

For a while, we focused on content sanitization as a possible workaround - but in many cases, we found it to be insufficient. For example, Aleksandr Dobkin managed to construct a purely alphanumeric Flash applet, and in our internal work the Google security team created images that can be forced to include a particular plaintext string in their body, after being scrubbed and recoded in a deterministic way.

In the end, we reacted to this raft of content hosting problems by placing some of the high-risk content in separate, isolated web origins—most commonly *.googleusercontent.com. There, the “sandboxed” files pose virtually no threat to the applications themselves, or to google.com authentication cookies. For public content, that’s all we need: we may use random or user-specific subdomains, depending on the degree of isolation required between unrelated documents, but otherwise the solution just works.

The situation gets more interesting for non-public documents, however. Copying users’ normal authentication cookies to the “sandbox” domain would defeat the purpose. The natural alternative is to move the secret token used to confer access rights from the Cookie header to a value embedded in the URL, and make the token unique to every document instead of keeping it global.

While this solution eliminates many of the significant design flaws associated with HTTP cookies, it trades one imperfect authentication mechanism for another. In particular, it’s important to note there are more ways to accidentally leak a capability-bearing URL than there are to accidentally leak cookies; the most notable risk is disclosure through the Referer header for any document format capable of including external subresources or of linking to external sites.

In our applications, we take a risk-based approach. Generally speaking, we tend to use three strategies:

In higher risk situations (e.g. documents with elevated risk of URL disclosure), we may couple the URL token scheme with short-lived, document-specific cookies issued for specific subdomains of googleusercontent.com. This mechanism, known within Google as FileComp, relies on a range of attack mitigation strategies that are too disruptive for Google applications at large, but work well in this highly constrained use case.

In cases where the risk of leaks is limited but responsive access controls are preferable (e.g., embedded images), we may issue URLs bound to a specific user, or ones that expire quickly.

In low-risk scenarios, where usability requirements necessitate a more balanced approach, we may opt for globally valid, longer-lived URLs.

Of course, the research into the security of web browsers continues, and the landscape of web applications is evolving rapidly. We are constantly tweaking our solutions to protect Google users even better, and even the solutions described here may change. Our commitment to making the Internet a safer place, however, will never waver.

Safe Browsing – Protecting Web Users for 5 Years and Counting

Jay — Tue, 19 Jun 2012 15:00:00 +0000

Posted by Niels Provos, Security Team

It’s been five years since we officially announced malware and phishing protection via our Safe Browsing effort. The goal of Safe Browsing is still the same today as it was five years ago: to protect people from malicious content on the Internet. Today, this protection extends not only to Google’s search results and ads, but also to popular web browsers such as Chrome, Firefox and Safari.

To achieve comprehensive and timely detection of new threats, the Safe Browsing team at Google has labored continuously to adapt to rising challenges and to build an infrastructure that automatically detects harmful content around the globe.

For a quick sense of the scale of our effort:

We protect 600 million users through built-in protection for Chrome, Firefox, and Safari, where we show several million warnings every day to Internet users. You may have seen our telltale red warnings pop up — when you do, please don’t go to sites we've flagged for malware or phishing. Our free and public Safe Browsing API allows other organizations to keep their users safe by using the data we’ve compiled.
We find about 9,500 new malicious websites every day. These are either innocent websites that have been compromised by malware authors, or others that are built specifically for malware distribution or phishing. While we flag many sites daily, we strive for high quality and have had only a handful of false positives.
Approximately 12-14 million Google Search queries per day show our warning to caution users from going to sites that are currently compromised. Once a site has been cleaned up, the warning is lifted.
We provide malware warnings for about 300 thousand downloads per day through our download protection service for Chrome.
We send thousands of notifications daily to webmasters. Signing up with Webmaster Tools helps us communicate directly with webmasters when we find something on their site, and our ongoing partnership with StopBadware.org helps webmasters who can't sign up or need additional help.
We also send thousands of notifications daily to Internet Service Providers (ISPs) & CERTs to help them keep their networks clean. Network administrators can sign up to receive frequent alerts.

By protecting Internet users, webmasters, ISPs, and Google over the years, we've built up a steadily more sophisticated understanding of web-based malware and phishing. These aren’t completely solvable problems because threats continue to evolve, but our technologies and processes do, too.

From here we’ll try to hit a few highlights from our journey.

Phishing

Many phishers go right for the money, and that pattern is reflected in the continued heavy targeting of online commerce sites like eBay & PayPal. Even though we’re still seeing some of the same techniques we first saw 5+ years ago, since they unfortunately still catch victims, phishing attacks are also getting more creative and sophisticated. As they evolve, we improve our system to catch more and newer attacks (Chart 1). Modern attacks are:

Faster - Many phishing webpages (URLs) remain online for less than an hour in an attempt to avoid detection.
More diverse - Targeted “spear phishing” attacks have become increasingly common. Additionally, phishing attacks are now targeting companies, banks, and merchants globally (Chart 2).
Used to distribute malware - Phishing sites commonly use the look and feel of popular sites and social networks to trick users into installing malware. For example, these rogue sites may ask to install a binary or browser extension to enable certain fake content.

(Chart 1)

(Chart 2)

Malware

Safe Browsing identifies two main categories of websites that may harm visitors:

Legitimate websites that are compromised in large numbers so they can deliver or redirect to malware (Chart 3).
Attack websites that are specifically built to distribute malware are used in increasing numbers (Chart 4).

When a legitimate website is compromised, it’s usually modified to include content from an attack site or to redirect to an attack site. These attack sites will often deliver "Drive by downloads" to visitors. A drive by download exploits a vulnerability in the browser to execute a malicious program on a user's computer without their knowledge.

Drive by downloads install and run a variety of malicious programs, such as:

Spyware to gather information like your banking credentials.
Malware that uses your computer to send spam.

(Chart 3)

Attack sites are purposely built for distributing malware and try to avoid detection by services such as Safe Browsing. To do so, they adopt several techniques, such as rapidly changing their location through free web hosting, dynamic DNS records, and automated generation of new domain names (Chart 4).

(Chart 4)

As companies have designed browsers and plugins to be more secure over time, malware purveyors have also employed social engineering, where the malware author tries to deceive the user into installing malicious software without the need for any software vulnerabilities. A good example is a “Fake Anti-Virus” alert that masquerades as a legitimate security warning, but it actually infects computers with malware.

While we see socially engineered attacks still trailing behind drive by downloads in frequency, this is a fast-growing category likely due to improved browser security.

How can you help prevent malware and phishing?

Our system is designed to protect users at high volumes (Chart 5), yet here are a few things that you can do to help:

Don't ignore our warnings. Legitimate sites are commonly modified to contain malware or phishing threats until the webmaster has cleaned their site. Malware is often designed to not be seen, so you won't know if your computer becomes infected. It’s best to wait for the warning to be removed before potentially exposing your machine to a harmful infection.
Help us find bad sites. Chrome users can select the check box on the red warning page. The data sent to us helps us find bad sites more quickly and helps protect other users.
Register your website with Google Webmaster Tools. Doing so helps us inform you quickly if we find suspicious code on your website at any point.

(Chart 5)

Looking Forward

The threat landscape changes rapidly. Our adversaries are highly motivated by making money from unsuspecting victims, and at great cost to everyone involved.

Our tangible impact in making the web more secure and our ability to directly protect users from harm has been a great source of motivation for everyone on the Safe Browsing team. We are also happy that our free data feed has become the de facto base of comparison for academic research in this space.

As we look forward, Google continues to invest heavily in the Safe Browsing team, enabling us to counter newer forms of abuse. In particular, our team supplied the technology underpinning these recent efforts:

Instantaneous phishing detection and download protection within the Chrome browser
Chrome extension malware scanning
Android application protection

For their strong efforts over the years, I thank Panayiotis Mavrommatis, Brian Ryner, Lucas Ballard, Moheeb Abu Rajab, Fabrice Jaubert, Nav Jagpal, Ian Fette, along with the whole Safe Browsing Team.

Microsoft XML vulnerability under active exploitation

Jay — Tue, 12 Jun 2012 19:53:00 +0000

Posted by Andrew Lyons, Security Engineer

Today Microsoft issued a Security Advisory describing a vulnerability in the Microsoft XML component. We discovered this vulnerability—which is leveraged via an uninitialized variable—being actively exploited in the wild for targeted attacks, and we reported it to Microsoft on May 30th. Over the past two weeks, Microsoft has been responsive to the issue and has been working with us. These attacks are being distributed both via malicious web pages intended for Internet Explorer users and through Office documents. Users running Windows XP up to and including Windows 7 are known to be vulnerable.

As part of the advisory, Microsoft suggests installing a Fix it solution that will prevent the exploitation of this vulnerability. We strongly recommend Internet Explorer and Microsoft Office users immediately install the Fix it while Microsoft develops and publishes a final fix as part of a future advisory.

Security warnings for suspected state-sponsored attacks

Jay — Tue, 05 Jun 2012 19:04:00 +0000

Posted by Eric Grosse, VP Security Engineering

We are constantly on the lookout for malicious activity on our systems, in particular attempts by third parties to log into users’ accounts unauthorized. When we have specific intelligence—either directly from users or from our own monitoring efforts—we show clear warning signs and put in place extra roadblocks to thwart these bad actors.

Today, we’re taking that a step further for a subset of our users, who we believe may be the target of state-sponsored attacks. You can see what this new warning looks like here:

If you see this warning it does not necessarily mean that your account has been hijacked. It just means that we believe you may be a target, of phishing or malware for example, and that you should take immediate steps to secure your account. Here are some things you should do immediately: create a unique password that has a good mix of capital and lowercase letters, as well punctuation marks and numbers; enable 2-step verification as additional security; and update your browser, operating system, plugins, and document editors. Attackers often send links to fake sign-in pages to try to steal your password, so be careful about where you sign in to Google and look for https://accounts.google.com/ in your browser bar. These warnings are not being shown because Google’s internal systems have been compromised or because of a particular attack.

You might ask how we know this activity is state-sponsored. We can’t go into the details without giving away information that would be helpful to these bad actors, but our detailed analysis—as well as victim reports—strongly suggest the involvement of states or groups that are state-sponsored.

We believe it is our duty to be proactive in notifying users about attacks or potential attacks so that they can take action to protect their information. And we will continue to update these notifications based on the latest information.

Notifying users affected by the DNSChanger malware

Jay — Tue, 22 May 2012 19:00:00 +0000

Posted by Damian Menscher, Security Engineer

Starting today we’re undertaking an effort to notify roughly half a million people whose computers or home routers are infected with a well-publicized form of malware known as DNSChanger. After successfully alerting a million users last summer to a different type of malware, we’ve replicated this method and have started showing warnings via a special message that will appear at the top of the Google search results page for users with affected devices.

The Domain Name System (DNS) translates familiar web address names like google.com into a numerical address that computers use to send traffic to the right place. The DNSChanger malware modifies DNS settings to use malicious servers that point users to fake sites and other harmful locations. DNSChanger attempts to modify the settings on home routers as well, meaning other computers and mobile devices may also be affected.

Since the FBI and Estonian law enforcement arrested a group of people and transferred control of the rogue DNS servers to the Internet Systems Consortium in November 2011, various ISPs and other groups have attempted to alert victims. However, many of these campaigns have had limited success because they could not target the affected users, or did not appear in the user’s preferred language (only half the affected users speak English as their primary language). At the current disinfection rate hundreds of thousands of devices will still be infected when the court order expires on July 9th and the replacement DNS servers are shut down. At that time, any remaining infected machines may experience slowdowns or completely lose Internet access.

Our goal with this notification is to raise awareness of DNSChanger among affected users. We believe directly messaging affected users on a trusted site and in their preferred language will produce the best possible results. While we expect to notify over 500,000 users within a week, we realize we won’t reach every affected user. Some ISPs have been taking their own actions, a few of which will prevent our warning from being displayed on affected devices. We also can’t guarantee that our recommendations will always clean infected devices completely, so some users may need to seek additional help. These conditions aside, if more devices are cleaned and steps are taken to better secure the machines against further abuse, the notification effort will be well worth it.

Spurring more vulnerability research through increased rewards

Jay — Mon, 23 Apr 2012 18:30:00 +0000

Posted by Adam Mein and Michal Zalewski, Security Team

We recently marked the anniversary of our Vulnerability Reward Program, possibly the first permanent program of its kind for web properties. This collaboration with the security research community has far surpassed our expectations: we have received over 780 qualifying vulnerability reports that span across the hundreds of Google-developed services, as well as the software written by fifty or so companies that we have acquired. In just over a year, the program paid out around $460,000 to roughly 200 individuals. We’re confident beyond any doubt the program has made Google users safer.

Today, to celebrate the success of this effort and to underscore our commitment to security, we are rolling out updated rules for our program — including new reward amounts for critical bugs:

$20,000 for qualifying vulnerabilities that the reward panel determines will allow code execution on our production systems.

$10,000 for SQL injection and equivalent vulnerabilities; and for certain types of information disclosure, authentication, and authorization bypass bugs.

Up to $3,133.7 for many types of XSS, XSRF, and other high-impact flaws in highly sensitive applications.

To help focus the research on bringing the greatest benefit to our users, the new rules offer reduced rewards for vulnerabilities discovered in non-integrated acquisitions and for lower risk issues. For example, while every flaw deserves appropriate attention, we are likely to issue a higher reward for a cross-site scripting vulnerability in Google Wallet than one in Google Art Project, where the potential risk to user data is significantly smaller.

Happy hunting - and if you find a security problem, please let us know!

An improved Google Authenticator app to celebrate millions of 2-step verification users

Jay — Fri, 30 Mar 2012 15:56:00 +0000

Posted by Sara "Scout" Sinclair, Associate Product Manager, Google Security Team

Since we first made 2-step verification available to all Google users in February of 2011, millions of people around the world have chosen to use this extra layer of security to protect their Google Accounts. Thousands more are signing up every day. And recently, we updated the feature’s companion smartphone app, Google Authenticator, for Android users.

2-step verification works by requiring users to enter a verification code when signing in using a computer they haven’t previously marked as “trusted.” Many users choose to receive their codes via SMS or voice call, but smartphone users also have the option to generate codes on their phone by installing the Google Authenticator app — an option that is particularly useful while traveling, or where cellular coverage is unreliable. You can use Google Authenticator to generate a valid code even when your phone isn’t connected to a cellular or data network.

We want 2-step verification to be simple to use, and therefore we are working continually to make it easier for users to sign up, manage their settings, and maintain easy access to their verification codes at any time and from anywhere. Our updated Google Authenticator app has an improved look-and-feel, as well as fundamental upgrades to the back-end security and infrastructure that necessitated the migration to a new app. Future improvements, however, will use the familiar Android update procedure.

Current Google Authenticator users will be prompted to upgrade to the new version when they launch the app. We’ve worked hard to make the upgrade process as smooth as possible, but if you have questions please refer to the Help Center article for more information. And, if you aren’t already a 2-step verification user, we encourage you to give it a try.

Celebrating one year of web vulnerability research

Jay — Thu, 09 Feb 2012 17:00:00 +0000

Posted by Adam Mein, Technical Program Manager, Google Security Team

In November 2010, we introduced a different kind of vulnerability reward program that encourages people to find and report security bugs in Google’s web applications. By all available measures, the program has been a big success. Before we embark further, we wanted to pause and share a few things that we’ve learned from the experience.

“Bug bounty” programs open up vulnerability research to wider participation.

On the morning of our announcement of the program last November, several of us guessed how many valid reports we might see during the first week. Thanks to an already successful Chromium reward program and a healthy stream of regular contributions to our general security submissions queue, most estimates settled around 10 or so. At the end of the first week, we ended up with 43 bug reports. Over the course of the program, we’ve seen more than 1100 legitimate issues (ranging from low severity to higher) reported by over 200 individuals, with 730 of those bugs qualifying for a reward. Roughly half of the bugs that received a reward were discovered in software written by approximately 50 companies that Google acquired; the rest were distributed across applications developed by Google (several hundred new ones each year). Significantly, the vast majority of our initial bug reporters had never filed bugs with us before we started offering monetary rewards.

Developing quality bug reports pays off... for everyone.

A well-run vulnerability reward program attracts high quality reports, and we’ve seen a whole lot of them. To date we’ve paid out over $410,000 for web app vulnerabilities to directly support researchers and their efforts. Thanks to the generosity of these bug reporters, we have also donated $19,000 to charities of their choice. It’s not all about money, though. Google has gotten better and stronger as a result of this work. We get more bug reports, which means we get more bug fixes, which means a safer experience for our users.

Bug bounties — the more, the merrier!

We benefited from looking at examples of other types of vulnerability reward programs when designing our own. Similarly, in the months following our reward program kick-off, we saw other companies developing reward programs and starting to focus more on web properties. Over time, these programs can help companies build better relationships with the security research community. As the model replicates, the opportunity to improve the overall security of the web broadens.

And with that, we turn toward the year ahead. We’re looking forward to new reports and ongoing relationships with the researchers who are helping make Google products more secure.

Android and Security

Jay — Thu, 02 Feb 2012 20:29:00 +0000

Posted by Adrian Ludwig, Android Security Engineer

We frequently get asked about how we defend Android users from malware and other threats. As the Android platform continues its tremendous growth, people wonder how we can maintain a trustworthy experience with Android Market while preserving the openness that remains a hallmark of our overall approach. We’ve been working on lots of defenses, and they have already made a real and measurable difference for our users’ security. Read more about how we defend against malware in Android Market on the Google Mobile Blog here.

Landing another blow against email phishing

Jay — Mon, 30 Jan 2012 05:00:00 +0000

(Cross-posted from the Gmail Blog)

Posted by Adam Dawes, Product Manager

Email phishing, in which someone tries to trick you into revealing personal information by sending fake emails that look legitimate, remains one of the biggest online threats. One of the most popular methods that scammers employ is something called domain spoofing. With this technique, someone sends a message that seems legitimate when you look at the “From” line even though it’s actually a fake. Email phishing is costing regular people and companies millions of dollars each year, if not more, and in response, Google and other companies have been talking about how we can move beyond the solutions we’ve developed individually over the years to make a real difference for the whole email industry.

Industry groups come and go, and it’s not always easy to tell at the beginning which ones are actually going to generate good solutions. When the right contributors come together to solve real problems, though, real things happen. That’s why we’re particularly optimistic about today’s announcement of DMARC.org, a passionate collection of companies focused on significantly cutting down on email phishing and other malicious mail.

Building upon the work of previous mail authentication standards like SPF and DKIM, DMARC is responding to domain spoofing and other phishing methods by creating a standard protocol by which we’ll be able to measure and enforce the authenticity of emails. With DMARC, large email senders can ensure that the email they send is being recognized by mail providers like Gmail as legitimate, as well as set policies so that mail providers can reject messages that try to spoof the senders’ addresses.

We’ve been active in the leadership of the DMARC group for almost two years, and now that Gmail and several other large mail senders and providers — namely Facebook, LinkedIn, and PayPal — are actively using the DMARC specification, the road is paved for more members of the email ecosystem to start getting a handle on phishing. Our recent data indicates that roughly 15% of non-spam messages in Gmail are already coming from domains protected by DMARC, which means Gmail users like you don’t need to worry about spoofed messages from these senders. The phishing potential plummets when the system just works, and that’s what DMARC provides.

If you’re a large email sender and you want to try out the DMARC specification, you can learn more at the DMARC website. Even if you’re not ready to take on the challenge of authenticating all your outbound mail just yet, there’s no reason to not sign up to start receiving reports of mail that fraudulently claims to originate from your address. With further adoption of DMARC, we can all look forward to a more trustworthy overall experience with email.

Tech tips that are Good to Know

Jay — Tue, 17 Jan 2012 06:37:00 +0000

Posted by Alma Whitten, Director of Privacy, Product and Engineering

(Cross-posted from the Official Google Blog)

Does this person sound familiar? He can’t be bothered to type a password into his phone every time he wants to play a game of Angry Birds. When he does need a password, maybe for his email or bank website, he chooses one that’s easy to remember like his sister’s name—and he uses the same one for each website he visits. For him, cookies come from the bakery, IP addresses are the locations of Intellectual Property and a correct Google search result is basically magic.

Most of us know someone like this. Technology can be confusing, and the industry often fails to explain clearly enough why digital literacy matters. So today in the U.S. we’re kicking off Good to Know, our biggest-ever consumer education campaign focused on making the web a safer, more comfortable place. Our ad campaign, which we introduced in the U.K. and Germany last fall, offers privacy and security tips: Use 2-step verification! Remember to lock your computer when you step away! Make sure your connection to a website is secure! It also explains some of the building blocks of the web like cookies and IP addresses. Keep an eye out for the ads in newspapers and magazines, online and in New York and Washington, D.C. subway stations.

The campaign and Good to Know website build on our commitment to keeping people safe online. We’ve created resources like privacy videos, the Google Security Center, the Family Safety Center and Teach Parents Tech to help you develop strong privacy and security habits. We design for privacy, building tools like Google Dashboard, Me on the Web, the Ads Preferences Manager and Google+ Circles—with more on the way.

We encourage you to take a few minutes to check out the Good to Know site, watch some of the videos, and be on the lookout for ads in your favorite newspaper or website. We hope you’ll learn something new about how to protect yourself online—tips that are always good to know!

Update 1/17: Updated to include more background on Good to Know.

Expanding Safe Browsing Alerts to include malware distribution domains

Jay — Thu, 01 Dec 2011 19:05:00 +0000

Posted by Nav Jagpal, Security Team

For the past year, we’ve been sending notifications to network administrators registered through the Safe Browsing Alerts for Network Administrators service when our automated tools find phishing URLs or compromised sites that lead to malware on their networks. These notifications provide administrators with important information to help them improve the security of their networks.

Today we’re adding distribution domains to the set of information we share. These are domains that are responsible for launching exploits and serving malware. Unlike compromised sites, which are often run by innocent webmasters, distribution domains are set up with the primary purpose of serving malicious content.

If you’re a network administrator and haven’t yet registered your AS, you can do so here.

Reminder: Safe Browsing version 1 API turning down December 1

Jay — Tue, 22 Nov 2011 20:46:00 +0000

Posted by Brian Ryner, Security Team

In May we announced that we are ending support for the Safe Browsing protocol version 1 on December 1 in order to focus our resources on the new version 2 API and the lookup service. These new APIs provide simpler and more efficient access to the same data, and they use significantly less bandwidth. If you haven't yet migrated off of the version 1 API, we encourage you to do so as soon as possible. Our earlier post contains links to documentation for the new protocol version and other resources to help you make the transition smoothly.

After December 1, we will remove all data from the version 1 API list to ensure that any remaining clients do not have false positives in their database. After January 1, 2012, we will turn off the version 1 service completely, and all requests will return a 404 error.

Thanks for your cooperation, and enjoy using the next generation of Safe Browsing.

Protecting data for the long term with forward secrecy

Jay — Tue, 22 Nov 2011 18:35:00 +0000

Posted by Adam Langley, Security Team

Last year we introduced HTTPS by default for Gmail and encrypted search. We’re pleased to see that other major communications sites are following suit and deploying HTTPS in one form or another. We are now pushing forward by enabling forward secrecy by default.

Most major sites supporting HTTPS operate in a non-forward secret fashion, which runs the risk of retrospective decryption. In other words, an encrypted, unreadable email could be recorded while being delivered to your computer today. In ten years time, when computers are much faster, an adversary could break the server private key and retrospectively decrypt today’s email traffic.

Forward secrecy requires that the private keys for a connection are not kept in persistent storage. An adversary that breaks a single key will no longer be able to decrypt months’ worth of connections; in fact, not even the server operator will be able to retroactively decrypt HTTPS sessions.

Forward secret HTTPS is now live for Gmail and many other Google HTTPS services(*), like SSL Search, Docs and Google+. We have also released the work that we did on the open source OpenSSL library that made this possible. You can check whether you have forward secret connections in Chrome by clicking on the green padlock in the address bar of HTTPS sites. Google’s forward secret connections will have a key exchange mechanism of ECDHE_RSA.

We would very much like to see forward secrecy become the norm and hope that our deployment serves as a demonstration of the practicality of that vision.

(* Chrome, Firefox (all platforms) and Internet Explorer (Vista or later) support forward secrecy using elliptic curve Diffie-Hellman. Initially, only Chrome and Firefox will use it by default with Google services because IE doesn’t support the combination of ECDHE and RC4. We hope to support IE in the future.)

Gmail account security in Iran

Jay — Fri, 09 Sep 2011 00:49:00 +0000

Posted by Eric Grosse, VP Security Engineering

We learned last week that the compromise of a Dutch company involved with verifying the authenticity of websites could have put the Internet communications of many Iranians at risk, including their Gmail. While Google’s internal systems were not compromised, we are directly contacting possibly affected users and providing similar information below because our top priority is to protect the privacy and security of our users.

While users of the Chrome browser were protected from this threat, we advise all users in Iran to take concrete steps to secure their accounts:

Change your password. You may have already been asked to change your password when you signed in to your Google Account. If not, you can change it here.
Verify your account recovery options. Secondary email addresses, phone numbers, and other information can help you regain access to your account if you lose your password. Check to be sure your recovery options are correct and up to date here.
Check the websites and applications that are allowed to access your account, and revoke any that are unfamiliar here.
Check your Gmail settings for suspicious forwarding addresses or delegated accounts.
Pay careful attention to warnings that appear in your web browser and don’t click past them.

For more ways to secure your account, you can visit http://www.google.com/help/security. If you believe your account has been compromised, you can start the recovery process here.

Four Years of Web Malware

Jay — Wed, 17 Aug 2011 22:41:00 +0000

Posted by Lucas Ballard and Niels Provos, Google Security Team

Google’s Safe Browsing initiative has been protecting users from web pages that install malware for over five years now. Each day we show around 3 million malware warnings to over four hundred million users whose browsers implement the Safe Browsing API. Like other service providers, we are engaged in an arms race with malware distributors. Over time, we have adapted our original system to incorporate new detection algorithms that allow us to keep pace. We recently completed an analysis of four years of data that explores the evasive techniques that malware distributors employ. We compiled the results in a technical report, entitled “Trends in Circumventing Web-Malware Detection.”

Below are a few of the research highlights, but we recommend reviewing the full report for details on our methodology and measurements. The analysis covers approximately 160 million web pages hosted on approximately 8 million sites.

Social Engineering
Social engineering is a malware distribution mechanism that relies on tricking a user into installing malware. Typically, the malware is disguised as an anti-virus product or browser plugin. Social engineering has increased in frequency significantly and is still rising. However, it’s important to keep this growth in perspective — sites that rely on social engineering comprise only 2% of all sites that distribute malware.

Number of sites distributing Social Engineering Malware and Exploits over time

Drive-by Download Exploit Trends
Far more common than social engineering, malicious pages install malware after exploiting a vulnerability in the browser or a plugin. This type of infection is often called a drive-by download. Our analysis of which vulnerabilities are actively being exploited over time shows that adversaries quickly switch to new and more reliable exploits to help avoid detection. The graph below shows the ratio of exploits targeting a vulnerability in one CVE to all exploits over time. Most vulnerabilities are exploited only for a short period of time until new vulnerabilities become available. A prominent exception is the MDAC vulnerability which is present in most exploit kits.

Prevalence of exploits targeting specific CVEs over time

Increase in IP Cloaking
Malware distributors are increasingly relying upon ‘cloaking’ as a technique to evade detection. The concept behind cloaking is simple: serve benign content to detection systems, but serve malicious content to normal web page visitors. Over the years, we have seen more malicious sites engaging in IP cloaking. To bypass the cloaking defense, we run our scanners in different ways to mimic regular user traffic.

Number of sites practicing IP Cloaking over time

New Detection Capabilities
Our report analyzed four years of data to uncover trends in malware distribution on the web, and it demonstrates the ongoing tension between malware distributors and malware detectors. To help protect Internet users, even those who don’t use Google, we have updated the Safe Browsing infrastructure over the years to incorporate many state-of-the-art malware detection technologies. We hope the findings outlined in this report will help other researchers in this area and raise awareness of some of the current challenges.

Fuzzing at scale

Jay — Fri, 12 Aug 2011 21:59:00 +0000

Posted by Chris Evans, Matt Moore and Tavis Ormandy, Google Security Team

One of the exciting things about working on security at Google is that you have a lot of compute horsepower available if you need it. This is very useful if you’re looking to fuzz something, and especially if you’re going to use modern fuzzing techniques.

Using these techniques and large amounts of compute power, we’ve found hundreds of bugs in our own code, including Chrome components such as WebKit and the PDF viewer. We recently decided to apply the same techniques to fuzz Adobe’s Flash Player, which we include with Chrome in partnership with Adobe.

A good overview of some modern techniques can be read in this presentation. For the purposes of fuzzing Flash, we mainly relied on “corpus distillation”. This is a technique whereby you locate a large number of sample files for the format at hand (SWF in this case). You then see which areas of code are reached by each of the sample files. Finally, you run an algorithm to generate a minimal set of sample files that achieves the code coverage of the full set. This calculated set of files is a great basis for fuzzing: a manageable number of files that exercise lots of unusual code paths.

What does corpus distillation look like at Google scale? Turns out we have a large index of the web, so we cranked through 20 terabytes of SWF file downloads followed by 1 week of run time on 2,000 CPU cores to calculate the minimal set of about 20,000 files. Finally, those same 2,000 cores plus 3 more weeks of runtime were put to good work mutating the files in the minimal set (bitflipping, etc.) and generating crash cases. These crash cases included an interesting range of vulnerability categories, including buffer overflows, integer overflows, use-after-frees and object type confusions.

The initial run of the ongoing effort resulted in about 400 unique crash signatures, which were logged as 106 individual security bugs following Adobe's initial triage. As these bugs were resolved, many were identified as duplicates that weren't caught during the initial triage. A unique crash signature does not always indicate a unique bug. Since Adobe has access to symbols and sources, they were able to group similar crashes to perform root cause analysis reducing the actual number of changes to the code. No analysis was performed to determine how many of the identified crashes were actually exploitable. However, each crash was treated as though it were potentially exploitable and addressed by Adobe. In the final analysis, the Flash Player update Adobe shipped earlier this week contained about 80 code changes to fix these bugs.

Commandeering massive resource to improve security is rewarding on its own, but the real highlight of this exercise has been Adobe’s response. The Flash patch earlier this week fixes these bugs and incorporates UIPI protections for the Flash Player sandbox in Chrome which Justin Schuh contributed assistance on developing. Fixing so many issues in such a short time frame shows a real commitment to security from Adobe, for which we are grateful.

2-step verification: stay safe around the world in 40 languages

Jay — Thu, 28 Jul 2011 16:08:00 +0000

Posted by Nishit Shah, Product Manager, Google Security

(Cross-posted from the Official Google Blog)

Earlier this year, we introduced a security feature called 2-step verification that helps protect your Google Account from threats like password compromise and identity theft. By entering a one-time verification code from your phone after you type your password, you can make it much tougher for an unauthorized person to gain access to your account.

People have told us how much they like the feature, which is why we're thrilled to offer 2-step verification in 40 languages and in more than 150 countries. There’s never been a better time to set it up: Examples in the news of password theft and data breaches constantly remind us to stay on our toes and take advantage of tools to properly secure our valuable online information. Email, social networking and other online accounts still get compromised today, but 2-step verification cuts those risks significantly.

We recommend investing some time in keeping your information safe by watching our 2-step verification video to learn how to quickly increase your Google Account’s resistance to common problems like reused passwords and malware and phishing scams. Wherever you are in the world, sign up for 2-step verification and help keep yourself one step ahead of the bad guys.

To learn more about online safety tips and resources, visit our ongoing security blog series, and review a couple of simple tips and tricks for online security. Also, watch our video about five easy ways to help you stay safe and secure as you browse.

Update on 12/1/11: We recently made 2-step verification available for users in even more places, including Iran, Japan, Liberia, Myanmar (Burma), Sudan and Syria. This enhanced security feature for Google Accounts is now available in more than 175 countries.

Introducing DOM Snitch, our passive in-the-browser reconnaissance tool

Jay — Tue, 21 Jun 2011 18:46:00 +0000

Posted by Radoslav Vasilev, Security Test Engineer

(Cross-posted from the Google Testing Blog)

Every day modern web applications are becoming increasingly sophisticated, and as their complexity grows so does their attack surface. Previously we introduced open source tools such as Skipfish and Ratproxy to assist developers in understanding and securing these applications.

As existing tools focus mostly on testingserver-side code, today we are happy to introduce DOM Snitch — an experimental* Chrome extension that enables developers and testers to identify insecure practices commonly found in client-side code. To do this, we have adopted several approaches to intercepting JavaScript calls to key and potentially dangerous browser infrastructure such as document.write or HTMLElement.innerHTML (among others). Once a JavaScript call has been intercepted, DOM Snitch records the document URL and a complete stack trace that will help assess if the intercepted call can lead to cross-site scripting, mixed content, insecure modifications to the same-origin policy for DOM access, or other client-side issues.

Here are the benefits of DOM Snitch:

Real-time: Developers can observe DOM modifications as they happen inside the browser without the need to step through JavaScript code with a debugger or pause the execution of their application.
Easy to use: With built-in security heuristics and nested views, both advanced and less experienced developers and testers can quickly spot areas of the application being tested that need more attention.
Easier collaboration: Enables developers to easily export and share captured DOM modifications while troubleshooting an issue with their peers.

DOM Snitch is intended for use by developers, testers, and security researchers alike. Click here to download DOM Snitch. To read the documentation, please visit this page.

*Developers and testers should be aware that DOM Snitch is currently experimental. We do not guarantee that it will work flawlessly for all web applications. More details on known issues can be found here or in the project’s issues tracker.

Protecting users from malware hosted on bulk subdomain services

Jay — Fri, 17 Jun 2011 15:19:00 +0000

Posted by Oliver Fisher, Google Anti-Malware Team

Over the past few months, Google’s systems have detected a number of bulk subdomain providers becoming targets of abuse by malware distributors. Bulk subdomain providers register a domain name, like example.com, and then sell subdomains of this domain name, like subdomain.example.com. Subdomains are often registered by the thousands at one time and are used to distribute malware and fake anti-virus products on the web. In some cases our malware scanners have found more than 50,000 malware domains from a single bulk provider.

Google’s automated malware scanning systems detect sites that distribute malware. To help protect users we recently modified those systems to identify bulk subdomain services which are being abused. In some severe cases our systems may now flag the whole bulk domain.

We offer many services to webmasters to help them fight abuse, such as:

Webmaster Tools lets webmasters find examples of URLs under their domains that may be distributing malware.
Google Safe Browsing Alerts for Network Administrators allows owners of Autonomous Systems to get notifications for hosts that are involved in malware delivery.

If you are the owner of a website that is hosted in a bulk subdomain service, please consider contacting your bulk subdomain provider if Google SafeBrowsing shows a warning for your site. The top-level bulk subdomain may be a target of abuse. Bulk subdomain service providers may use Google’s tools to help identify and disable abusive subdomains and accounts.

Website Security for Webmasters

Jay — Thu, 05 May 2011 19:33:00 +0000

Posted by Gary Illyes, Webmaster Trends Analyst

(Cross-posted from the Webmaster Central Blog)

Users are taught to protect themselves from malicious programs by installing sophisticated antivirus software, but they often also entrust their private information to various websites. As a result, webmasters have a dual task to protect both their website itself and the user data that they receive.

Over the years companies and webmasters have learned—often the hard way—that web application security is not a joke; we’ve seen user passwords leaked due to SQL injection attacks, cookies stolen with XSS, and websites taken over by hackers due to negligent input validation.

Today we’ll show you some examples of how a web application can be exploited so you can learn from them; for this we’ll use Gruyere, an intentionally vulnerable application we use for security training internally, and that we introduced here last year. Do not probe others’ websites for vulnerabilities without permission as it may be perceived as hacking; but you’re welcome—nay, encouraged—to run tests on Gruyere.

Client state manipulation - What will happen if I alter the URL?

Let’s say you have an image hosting site and you’re using a PHP script to display the images users have uploaded:

http://www.example.com/showimage.php?imgloc=/garyillyes/kitten.jpg

So what will the application do if I alter the URL to something like this and userpasswords.txt is an actual file?

http://www.example.com/showimage.php?imgloc=/../../userpasswords.txt

Will I get the content of userpasswords.txt?

Another example of client state manipulation is when form fields are not validated. For instance, let’s say you have this form:

It seems that the username of the submitter is stored in a hidden input field. Well, that’s great! Does that mean that if I change the value of that field to another username, I can submit the form as that user? It may very well happen; the user input is apparently not authenticated with, for example, a token which can be verified on the server.
Imagine the situation if that form were part of your shopping cart and I modified the price of a $1000 item to $1, and then placed the order.

Protecting your application against this kind of attack is not easy; take a look at the third part of Gruyere to learn a few tips about how to defend your app.

Cross-site scripting (XSS) - User input can’t be trusted

A simple, harmless URL:
http://google-gruyere.appspot.com/611788451095/%3Cscript%3Ealert('0wn3d')%3C/script%3E
But is it truly harmless? If I decode the percent-encoded characters, I get:

Gruyere, just like many sites with custom error pages, is designed to include the path component in the HTML page. This can introduce security bugs, like XSS, as it introduces user input directly into the rendered HTML page of the web application. You might say, “It’s just an alert box, so what?” The thing is, if I can inject an alert box, I can most likely inject something else, too, and maybe steal your cookies which I could use to sign in to your site as you.

Another example is when the stored user input isn’t sanitized. Let’s say I write a comment on your blog; the comment is simple:

Click here to see a kitten

If other users click on my innocent link, I have their cookies:

You can learn how to find XSS vulnerabilities in your own web app and how to fix them in the second part of Gruyere; or, if you’re an advanced developer, take a look at the automatic escaping features in template systems we blogged about previously on this blog.

Cross-site request forgery (XSRF) - Should I trust requests from evil.com?

Oops, a broken picture. It can’t be dangerous--it’s broken, after all--which means that the URL of the image returns a 404 or it’s just malformed. Is that true in all of the cases?

No, it’s not! You can specify any URL as an image source, regardless of its content type. It can be an HTML page, a JavaScript file, or some other potentially malicious resource. In this case the image source was a simple page’s URL:

That page will only work if I’m logged in and I have some cookies set. Since I was actually logged in to the application, when the browser tried to fetch the image by accessing the image source URL, it also deleted my first snippet. This doesn’t sound particularly dangerous, but if I’m a bit familiar with the app, I could also invoke a URL which deletes a user’s profile or lets admins grant permissions for other users.

To protect your app against XSRF you should not allow state changing actions to be called via GET; the POST method was invented for this kind of state-changing request. This change alone may have mitigated the above attack, but usually it's not enough and you need to include an unpredictable value in all state changing requests to prevent XSRF. Please head to Gruyere if you want to learn more about XSRF.

Cross-site script inclusion (XSSI) - All your script are belong to us

Many sites today can dynamically update a page's content via asynchronous JavaScript requests that return JSON data. Sometimes, JSON can contain sensitive data, and if the correct precautions are not in place, it may be possible for an attacker to steal this sensitive information.

Let’s imagine the following scenario: I have created a standard HTML page and send you the link; since you trust me, you visit the link I sent you. The page contains only a few lines:

Since you’re signed in to Gruyere and you have a private snippet, you’ll see an alert box on my page informing you about the contents of your snippet. As always, if I managed to fire up an alert box, I can do whatever else I want; in this case it was a simple snippet, but it could have been your biggest secret, too.

It’s not too hard to defend your app against XSSI, but it still requires careful thinking. You can use tokens as explained in the XSRF section, set your script to answer only POST requests, or simply start the JSON response with ‘\n’ to make sure the script is not executable.

SQL Injection - Still think user input is safe?

What will happen if I try to sign in to your app with a username like

JohnDoe’; DROP TABLE members;--

While this specific example won’t expose user data, it can cause great headaches because it has the potential to completely remove the SQL table where your app stores information about members.

Generally, you can protect your app from SQL injection with proactive thinking and input validation. First, are you sure the SQL user needs to have permission to execute “DROP TABLE members”? Wouldn’t it be enough to grant only SELECT rights? By setting the SQL user’s permissions carefully, you can avoid painful experiences and lots of troubles. You might also want to configure error reporting in such way that the database and its tables’ names aren’t exposed in the case of a failed query.
Second, as we learned in the XSS case, never trust user input: what looks like a login form to you, looks like a potential doorway to an attacker. Always sanitize and quotesafe the input that will be stored in a database, and whenever possible make use of statements generally referred to as prepared or parametrized statements available in most database programming interfaces.

Knowing how web applications can be exploited is the first step in understanding how to defend them. In light of this, we encourage you to take the Gruyere course, take other web security courses from the Google Code University and check out skipfish if you're looking for an automated web application security testing tool. If you have more questions please post them in our Webmaster Help Forum.

Improving SSL certificate security

Jay — Fri, 01 Apr 2011 16:05:00 +0000

Posted by Ben Laurie, Google Security Team

In the wake of the recent Comodo fraud incident, there has been a great deal of speculation about how to improve the public key infrastructure, on which the security of the Internet rests. Unfortunately, this isn’t a problem that will be fixed overnight. Luckily, however, experts have long known about these issues and have been devising solutions for some time.

Given the current interest it seems like a good time to talk about two projects in which Google is engaged.

The first is the Google Certificate Catalog. Google’s web crawlers scan the web on a regular basis in order to provide our search and other services. In the process, we also keep a record of all the SSL certificates we see. The Google Certificate Catalog is a database of all of those certificates, published in DNS. So, for example, if you wanted to see what we think of https://www.google.com/’s certificate, you could do this:

$ openssl s_client -connect www.google.com:443 < /dev/null | openssl x509 -outform DER | openssl sha1
depth=1 /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
verify error:num=20:unable to get local issuer certificate
verify return:0
DONE
405062e5befde4af97e9382af16cc87c8fb7c4e2
$ dig +short 405062e5befde4af97e9382af16cc87c8fb7c4e2.certs.googlednstest.com TXT
"14867 15062 74"

In other words: take the SHA-1 hash of the certificate, represent it as a hexadecimal number, then look up a TXT record with that name in the certs.googlednstest.com domain. What you get back is a set of three numbers. The first number is the day that Google’s crawlers first saw that certificate, the second is the most recent day, and the third is the number of days we saw it in between.

In order for the hash of a certificate to appear in our database, it must satisfy some criteria:

It must be correctly signed (either by a CA or self-signed).
It must have the correct domain name — that is, one that matches the one we used to retrieve the certificate.

The basic idea is that if a certificate doesn’t appear in our database, despite being correctly signed by a well-known CA and having a matching domain name, then there may be something suspicious about that certificate. This endeavor owes much to the excellent Perspectives project, but it is a somewhat different approach.

Accessing the data manually is rather difficult and painful, so we’re thinking about how to add opt-in support to the Chrome browser. We hope other browsers will in time consider acting similarly.

The second initiative to discuss is the DANE Working Group at the IETF. DANE stands for DNS-based Authentication of Named Entities. In short, the idea is to allow domain operators to publish information about SSL certificates used on their hosts. It should be possible, using DANE DNS records, to specify particular certificates which are valid, or CAs that are allowed to sign certificates for those hosts. So, once more, if a certificate is seen that isn’t consistent with the DANE records, it should be treated with suspicion. Related to the DANE effort is the individually contributed CAA record, which predates the DANE WG and provides similar functionality.

One could rightly point out that both of these efforts rely on DNS, which is not secure. Luckily we’ve been working on that problem for even longer than this one, and a reasonable answer is DNSSEC, which enables publishing DNS records that are cryptographically protected against forgery and modification.

It will be some time before DNSSEC is deployed widely enough for DANE to be broadly useful, since DANE requires every domain to be able to use DNSSEC. However, work is on the way to use DNSSEC for the Certificate Catalog well before the entire DNSSEC infrastructure is ready. If we publish a key for the domain in which we publish the catalog, clients can simply incorporate this key as an interim measure until DNSSEC is properly deployed.

Improving the public key infrastructure of the web is a big task and one that’s going to require the cooperation of many parties to be widely effective. We hope these projects will help point us in the right direction.

Chrome warns users of out-of-date browser plugins

Jay — Thu, 31 Mar 2011 18:04:00 +0000

Posted by Panayiotis Mavrommatis and Noé Lutz, Google Security Team

The new version of Google Chrome is not only speedier and simpler but it also improves user security by automatically disabling out-of-date, vulnerable browser plugins.

As browsers get better at auto-updating, out-of-date plugins are becoming the weakest link against malware attacks. Thousands of web sites are compromised every week, turning those sites into malware distribution vectors by actively exploiting out-of-date plugins that run in the browser. Simply visiting one of these sites is usually enough to get your computer infected.

Keeping all of your plugins up-to-date with the latest security fixes can be a hassle, so a while ago we started using our 20% time to develop a solution. The initial implementation was a Chrome extension called “SecBrowsing,” which kept track of the latest plugin versions and encouraged users to update accordingly. The extension helped us gather valuable knowledge about plugins, and we started working with the Chrome team to build the feature right inside the browser.

With the latest version of Chrome, users will be automatically warned about any out-of-date plugins. If you run into a page that requires a plugin that’s not current, it won’t run by default. Instead, you’ll see a message that will help you get the latest, most secure version of the plugin. An example of this message is below, and you can read more about the feature at the Chromium blog.

MHTML vulnerability under active exploitation

Jay — Fri, 11 Mar 2011 22:13:00 +0000

Posted by Chris Evans, Robert Swiecki, Michal Zalewski, and Billy Rios, Google Security Team

We’ve noticed some highly targeted and apparently politically motivated attacks against our users. We believe activists may have been a specific target. We’ve also seen attacks against users of another popular social site. All these attacks abuse a publicly-disclosed MHTML vulnerability for which an exploit was publicly posted in January 2011. Users browsing with the Internet Explorer browser are affected.

For now, we recommend concerned users and corporations seriously consider deploying Microsoft’s temporary Fixit to block this attack until an official patch is available.

To help protect users of our services, we have deployed various server-side defenses to make the MHTML vulnerability harder to exploit. That said, these are not tenable long-term solutions, and we can’t guarantee them to be 100% reliable or comprehensive. We’re working with Microsoft to develop a comprehensive solution for this issue.

The abuse of this vulnerability is also interesting because it represents a new quality in the exploitation of web-level vulnerabilities. To date, similar attacks focused on directly compromising users' systems, as opposed to leveraging vulnerabilities to interact with web
services.

Advanced sign-in security for your Google account

Jay — Thu, 10 Feb 2011 20:02:00 +0000

Posted by Nishit Shah, Product Manager, Google Security

(Cross-posted from the Official Google Blog)

Has anyone you know ever lost control of an email account and inadvertently sent spam—or worse—to their friends and family? There are plenty of examples (like the classic "Mugged in London" scam) that demonstrate why it's important to take steps to help secure your activities online. Your Gmail account, your photos, your private documents—if you reuse the same password on multiple sites and one of those sites gets hacked, or your password is conned out of you directly through a phishing scam, it can be used to access some of your most closely-held information.

Most of us are used to entrusting our information to a password, but we know that some of you are looking for something stronger. As we announced to our Google Apps customers a few months ago, we've developed an advanced opt-in security feature called 2-step verification that makes your Google Account significantly more secure by helping to verify that you're the real owner of your account. Now it's time to offer the same advanced protection to all of our users.

2-step verification requires two independent factors for authentication, much like you might see on your banking website: your password, plus a code obtained using your phone. Over the next few days, you'll see a new link on your Account Settings page that looks like this:

Take your time to carefully set up 2-step verification—we expect it may take up to 15 minutes to enroll. A user-friendly set-up wizard will guide you through the process, including setting up a backup phone and creating backup codes in case you lose access to your primary phone. Once you enable 2-step verification, you'll see an extra page that prompts you for a code when you sign in to your account. After entering your password, Google will call you with the code, send you an SMS message or give you the choice to generate the code for yourself using a mobile application on your Android, BlackBerry or iPhone device. The choice is up to you. When you enter this code after correctly submitting your password we'll have a pretty good idea that the person signing in is actually you.

It's an extra step, but it's one that significantly improves the security of your Google Account because it requires the powerful combination of both something you know—your username and password—and something that only you should have—your phone. A hacker would need access to both of these factors to gain access to your account. If you like, you can always choose a "Remember verification for this computer for 30 days" option, and you won't need to re-enter a code for another 30 days. You can also set up one-time application-specific passwords to sign in to your account from non-browser based applications that are designed to only ask for a password, and cannot prompt for the code.

To learn more about 2-step verification and get started, visit our Help Center. And for more about staying safe online, see our ongoing security blog series or visit http://www.staysafeonline.org/. Be safe!

Advanced sign-in security for your Google account

Jay — Thu, 10 Feb 2011 20:02:00 +0000

Quick update on our vulnerability reward program

Jay — Fri, 12 Nov 2010 00:10:00 +0000

Posted by Matt Moore, Michal Zalewski, Adam Mein, Chris Evans; Google Security Team

About a week and a half ago we launched a new web vulnerability reward program, and the response has been fantastic. We've received many high quality reports from across the globe. Our bug review committee has been working hard, and we’re pleased to say that so far we plan to award over $20,000 to various talented researchers. We'll update our 'Hall of Fame' page with relevant details over the next few days.

Based on what we've received over the past week, we've clarified a few things about the program — in particular, the types of issues and Google services that are in scope for a reward. The review committee has been somewhat generous this first week, and we’ve granted a number of awards for bugs of low severity, or that wouldn’t normally fall under the conditions we originally described. Please be sure to review our original post and clarification thoroughly before reporting a potential issue to us.

Quick update on our vulnerability reward program

Jay — Fri, 12 Nov 2010 00:10:00 +0000

Rewarding web application security research

Jay — Mon, 01 Nov 2010 19:30:00 +0000

Posted by Chris Evans, Neel Mehta, Adam Mein, Matt Moore, and Michal Zalewski; Google Security Team

Back in January of this year, the Chromium open source project launched a well-received vulnerability reward program. In the months since launch, researchers reporting a wide range of great bugs have received rewards — a small summary of which can be found in the Hall of Fame. We've seen a sustained increase in the number of high quality reports from researchers, and their combined efforts are contributing to a more secure Chromium browser for millions of users.

Today, we are announcing an experimental new vulnerability reward program that applies to Google web properties. We already enjoy working with an array of researchers to improve Google security, and some individuals who have provided high caliber reports are listed on our credits page. As well as enabling us to thank regular contributors in a new way, we hope our new program will attract new researchers and the types of reports that help make our users safer.

In the spirit of the original Chromium blog post, we have some information about the new program in a question and answer format below:

Q) What applications are in scope?
A) Any Google web properties which display or manage highly sensitive authenticated user data or accounts may be in scope. Some examples could include:

*.google.com
*.youtube.com
*.blogger.com
*.orkut.com

For now, Google's client applications (e.g. Android, Picasa, Google Desktop, etc) are not in scope. We may expand the program in the future.

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.

Rewarding web application security research

Jay — Mon, 01 Nov 2010 19:30:00 +0000

*.google.com
*.youtube.com
*.blogger.com
*.orkut.com

For now, Google's client applications (e.g. Android, Picasa, Google Desktop, etc) are not in scope. We may expand the program in the future.

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

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

Jay — Thu, 21 Oct 2010 18:33:00 +0000

Posted by Adrienne St. Aubin, Public Policy Analyst

In the physical world, basic safety measures are second-nature to almost everyone (look both ways, stop drop and roll!). In the digital world, however, many of us expect security to be handled on our behalf by experts, or come in a single-box solution. Together, we must reset those expectations.

The Internet is the biggest neighborhood in the world. Security-related initiatives in the technology sector and government play an important role in making the Internet safer, but efforts from Silicon Valley and Washington, D.C. alone are not enough. Much of the important work that needs to be done must happen closer to home—wherever that may be.

As part of National Cyber Security Awareness Month I recently traveled from California to Washtenaw County, MI to speak to group of local community leaders, educators, business owners, law enforcement officials and residents who recently formed the Washtenaw Cyber Citizenship Coalition. They are working to create a digitally aware, knowledgeable and more secure community by providing residents with the tools and resources to be good digital citizens. No one in the room self-identified as a “cyber security expert,” but the information sharing that’s happening in Washtenaw County is the kind of holistic effort that can enable everyone to use the Internet more safely and benefit from the great opportunities that it provides.

The Washtenaw Cyber Citizenship Coalition is channeling the community’s efforts through volunteer workgroups in areas such as public/private partnerships, awareness, education and law enforcement. Their strategy is to “share the wheel" whenever possible, instead of recreating it. They’ve collected tips and resources for kids, parents, businesses, educators and crime victims so that citizens can find and access these materials with ease.

If you are interested in raising awareness in your own community, staysafeonline.org, stopthinkconnect.org and onguardonline.gov are examples of sites that offer such materials for public use.

Protecting your data in the cloud

Jay — Fri, 15 Oct 2010 16:38:00 +0000

Posted by Priya Nayak, Consumer Operations, Google Accounts

Like many people, you probably store a lot of important information in your Google Account. I personally check my Gmail account every day (sometimes several times a day) and rely on having access to my mail and contacts wherever I go. Aside from Gmail, my Google Account is tied to lots of other services that help me manage my life and interests: photos, documents, blogs, calendars, and more. That is to say, my Google Account is very valuable to me.

Unfortunately, a Google Account is also valuable in the eyes of spammers and other people looking to do harm. It’s not so much about your specific account, but rather the fact that your friends and family see your Google Account as trustworthy. A perfect example is the “Mugged in London” phishing scam that aims to trick your contacts into wiring money — ostensibly to help you out. If your account is compromised and used to send these messages, your well-meaning friends may find themselves out a chunk of change. If you have sensitive information in your account, it may also be at risk of improper access.

As part of National Cyber Security Awareness month, we want to let you know what you can do to better protect your Google Account.

Stay one step ahead of the bad guys

Account hijackers prey on the bad habits of the average Internet user. Understanding common hijacking techniques and using better security practices will help you stay one step ahead of them.

The most common ways hijackers can get access to your Google password are:

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.

Protecting your data in the cloud

Jay — Fri, 15 Oct 2010 16:38:00 +0000

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?”

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.

Moving security beyond passwords

Jay — Mon, 20 Sep 2010 09:14:00 +0000

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.

Building the technology and infrastructure to support this kind of feature has taken careful thought. We wanted to develop a security feature that would be easy to use and not get in your way. Along those lines, we're offering a variety of sign in options, along with the ability to indicate when you're using a computer you trust and don't want to be asked for a verification code from that machine in the future. Making this service available to millions of users at no cost took a great deal of coordination across Google’s specialized infrastructure, from building a scalable SMS and voice call system to developing open source mobile applications for your smart phone. The result is a feature we hope you'll find simple to manage and that makes it easy to better protect your account.

We look forward to gathering feedback about this feature and making it available to all of our users in the coming months.

If you'd like to learn more about about staying safe online, see our ongoing security blog series or visit http://www.staysafeonline.org/.

Moving security beyond passwords

Jay — Mon, 20 Sep 2010 09:14:00 +0000

Vulnerability trends: how are companies really doing?

Jay — Mon, 30 Aug 2010 23:17:00 +0000

Posted by Adam Mein, Google Security Team

Quite a few security companies and organizations produce vulnerability databases, cataloguing bugs and reporting trends across the industry based on the data they compile. There is value in this exercise; specifically, getting a look at examples across a range of companies and industries gives us information about the most common types of threats, as well as how they are distributed.

Unfortunately, the data behind these reports is commonly inaccurate or outdated to some degree. The truth is that maintaining an accurate and reliable database of this type of information is a significant challenge. We most recently saw this reality play out last week after the appearance of the IBM X-Force® 2010 Mid-Year Trend and Risk Report. We questioned a number of surprising findings concerning Google’s vulnerability rate and response record, and after discussions with IBM, we discovered a number of errors that had important implications for the report’s conclusions. IBM worked together with us and promptly issued a correction to address the inaccuracies.

Google maintains a Product Security Response Team that prioritizes bug reports and coordinates their handling across relevant engineering groups. Unsurprisingly, particular attention is paid to high-risk and critical vulnerabilities. For this reason, we were confused by a claim that 33% of critical and high-risk bugs uncovered in our services in the first half of 2010 were left unpatched. We learned after investigating that the 33% figure referred to a single unpatched vulnerability out of a total of three — and importantly, the one item that was considered unpatched was only mistakenly considered a security vulnerability due to a terminology mix-up. As a result, the true unpatched rate for these high-risk bugs is 0 out of 2, or 0%.

How do these types of errors occur? Maintainers of vulnerability databases have a number of factors working against them:

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.

To make these databases more useful for the industry and less likely to spread misinformation, we feel there must be more frequent collaboration between vendors and compilers. As a first step, database compilers should reach out to vendors they plan to cover in order to devise a sustainable solution for both parties that will allow for a more consistent flow of information. Another big improvement would be increased transparency on the part of the compilers — for example, the inclusion of more hard data, the methodology behind the data gathering, and caveat language acknowledging the limitations of the presented data. We hope to see these common research practices employed more broadly to increase the quality and usefulness of vulnerability trend reports.

Rebooting Responsible Disclosure: a focus on protecting end users

Jay — Tue, 20 Jul 2010 21:07:00 +0000

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

Vulnerability disclosure policies have become a hot topic in recent years. Security researchers generally practice “responsible disclosure”, which involves privately notifying affected software vendors of vulnerabilities. The vendors then typically address the vulnerability at some later date, and the researcher reveals full details publicly at or after this time.

A competing philosophy, "full disclosure", involves the researcher making full details of a vulnerability available to everybody simultaneously, giving no preferential treatment to any single party.

The argument for responsible disclosure goes briefly thus: by giving the vendor the chance to patch the vulnerability before details are public, end users of the affected software are not put at undue risk, and are safer. Conversely, the argument for full disclosure proceeds: because a given bug may be under active exploitation, full disclosure enables immediate preventative action, and pressures vendors for fast fixes. Speedy fixes, in turn, make users safer by reducing the number of vulnerabilities available to attackers at any given time.

Note that there's no particular consensus on which disclosure policy is safer for users. Although responsible disclosure is more common, we recommend this 2001 post by Bruce Schneier as background reading on some of the advantages and disadvantages of both approaches.

So, is the current take on responsible disclosure working to best protect end users in 2010? Not in all cases, no. The emotionally loaded name suggests that it is the most responsible way to conduct vulnerability research - but if we define being responsible as doing whatever it best takes to make end users safer, we will find a disconnect. We’ve seen an increase in vendors invoking the principles of “responsible” disclosure to delay fixing vulnerabilities indefinitely, sometimes for years; in that timeframe, these flaws are often rediscovered and used by rogue parties using the same tools and methodologies used by ethical researchers. The important implication of referring to this process as "responsible" is that researchers who do not comply are seen as behaving improperly. However, the inverse situation is often true: it can be irresponsible to permit a flaw to remain live for such an extended period of time.

Skilled attackers are using 0-day vulnerabilities in the wild, and there are increasing instances of:

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.

Accordingly, we believe that responsible disclosure is a two-way street. Vendors, as well as researchers, must act responsibly. Serious bugs should be fixed within a reasonable timescale. Whilst every bug is unique, we would suggest that 60 days is a reasonable upper bound for a genuinely critical issue in widely deployed software. This time scale is only meant to apply to critical issues. Some bugs are mischaracterized as “critical", but we look to established guidelines to help make these important distinctions — e.g. Chromium severity guidelines and Mozilla severity ratings.

As software engineers, we understand the pain of trying to fix, test and release a product rapidly; this especially applies to widely-deployed and complicated client software. Recognizing this, we put a lot of effort into keeping our release processes agile so that security fixes can be pushed out to users as quickly as possible.

A lot of talented security researchers work at Google. These researchers discover many vulnerabilities in products from vendors across the board, and they share a detailed analysis of their findings with vendors to help them get started on patch development. We will be supportive of the following practices by our researchers:

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.

We of course expect to be held to the same standards ourselves. We recognize that we’ve handled bug reports in the past where we’ve been unable to meet reasonable publication deadlines -- due to unexpected dependencies, code complexity, or even simple mix-ups. In other instances, we’ve simply disagreed with a researcher on the scope or severity of a bug. In all these above cases, we’ve been happy for publication to proceed, and grateful for the heads-up.

We would invite other researchers to join us in using the proposed disclosure deadlines to drive faster security response efforts. Creating pressure towards more reasonably-timed fixes will result in smaller windows of opportunity for blackhats to abuse vulnerabilities. In our opinion, this small tweak to the rules of engagement will result in greater overall safety for users of the Internet.

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.

Extending SSL to Google search

Jay — Fri, 21 May 2010 19:32:00 +0000

Posted by Murali Viswanathan, Product Manager

Google understands the potential risks of browsing the web on an unsecured network, particularly when information is sent over the wire unencrypted — as it is for most major websites today. That’s why we offered SSL support for Gmail back when we launched the product in 2004. Most other webmail providers don’t provide this feature even today. We’ve since added SSL support for Calendar, Docs, Sites, and several other products. Additionally, early this year we made SSL the default setting for all Gmail users.

As we work to provide more support for SSL across our products, today we’re introducing the ability to search with Google over SSL. We still have some testing to do, but you can try out the new encrypted version of Google search at https://www.google.com and read more about it on the Official Google Blog.

Do Know Evil: web application vulnerabilities

Jay — Tue, 04 May 2010 15:19:00 +0000

Posted by Bruce Leban, Software Engineer

UPDATE July 13: We have changed the name of the codelab application to Gruyere. The codelab is now located at http://google-gruyere.appspot.com.

We want Google employees to have a firm understanding of the threats our services face, as well as how to help protect against those threats. We work toward these goals in a variety of ways, including security training for new engineers, technical presentations about security, and other types of documentation. We also use codelabs — interactive programming tutorials that walk participants through specific programming tasks.

One codelab in particular teaches developers about common types of web application vulnerabilities. In the spirit of the thinking that "it takes a hacker to catch a hacker," the codelab also demonstrates how an attacker could exploit such vulnerabilities.

We're releasing this codelab, entitled "Web Application Exploits and Defenses," today in coordination with Google Code University and Google Labs to help software developers better recognize, fix, and avoid similar flaws in their own applications. The codelab is built around Gruyere, a small yet full-featured microblogging application designed to contain lots of security bugs. The vulnerabilities covered by the lab include cross-site scripting (XSS), cross-site request forgery (XSRF) and cross-site script inclusion (XSSI), as well as client-state manipulation, path traversal and AJAX and configuration vulnerabilities. It also shows how simple bugs can lead to information disclosure, denial-of-service and remote code execution.

The maxim, "given enough eyeballs, all bugs are shallow" is only true if the eyeballs know what to look for. To that end, the security bugs in Gruyere are real bugs — just like those in many other applications. The Gruyere source code is published under a Creative Commons license and is available for use in whitebox hacking exercises or in computer science classes covering security, software engineering or general software development.

To get started, visit http://google-gruyere.appspot.com. An instructor's guide for using the codelab is now available on Google Code University.

The Rise of Fake Anti-Virus

Jay — Wed, 14 Apr 2010 15:55:00 +0000

Posted by Niels Provos, Security Team
For years, we have detected malicious content on the web and helped protect users from it. Vulnerabilities in web browsers and popular plugins have resulted in an increased number of users whose systems can be compromised by attacks known as drive-by downloads. Such attacks do not require any user interaction, and they allow the adversary to execute code on a user’s computer without their knowledge. However, even without any vulnerabilities present, clever social engineering attacks can cause an unsuspecting user to unwittingly install malicious code supplied by an attacker on their computer.

One increasingly prevalent threat is the spread of Fake Anti-Virus (Fake AV) products. This malicious software takes advantage of users’ fear that their computer is vulnerable, as well as their desire to take the proper corrective action. Visiting a malicious or compromised web site — or sometimes even viewing a malicious ad — can produce a screen looking something like the following:

At Google, we have been working to help protect users against Fake AV threats on the web since we first discovered them in March 2007. In addition to protections like adding warnings to browsers and search results, we’re also actively engaged in malware research. We conducted an in-depth analysis of the prevalence of Fake AV over the course of the last 13 months, and the research paper containing our findings, “The Nocebo Effect on the Web: An Analysis of Fake AV distribution” is going to be presented at the Workshop on Large-Scale Exploits and Emergent Threats (LEET) in San Jose, CA on April 27th. While we do not want to spoil any surprises, here are a few previews. Our analysis of 240 million web pages over the 13 months of our study uncovered over 11,000 domains involved in Fake AV distribution — or, roughly 15% of the malware domains we detected on the web during that period.

Also, over the last year, the lifespan of domains distributing Fake AV attacks has decreased significantly:

In the meantime, we recommend only running antivirus and antispyware products from trusted companies. Be sure to use the latest versions of this software, and if the scan detects any suspicious programs or applications, remove them immediately.

The chilling effects of malware

Jay — Tue, 30 Mar 2010 21:05:00 +0000

Posted by Neel Mehta, Security Team

In January, we discussed a set of highly sophisticated cyber attacks that originated in China and targeted many corporations around the world. We believe that malware is a general threat to the Internet, but it is especially harmful when it is used to suppress opinions of dissent. In that case, the attacks involved surveillance of email accounts belonging to Chinese human rights activists. Perhaps unsurprisingly, these are not the only examples of malicious software being used for political ends. We have gathered information about a separate cyber threat that was less sophisticated but that nonetheless was employed against another community.

This particular malware broadly targeted Vietnamese computer users around the world. The malware infected the computers of potentially tens of thousands of users who downloaded Vietnamese keyboard language software and possibly other legitimate software that was altered to infect users. While the malware itself was not especially sophisticated, it has nonetheless been used for damaging purposes. These infected machines have been used both to spy on their owners as well as participate in distributed denial of service (DDoS) attacks against blogs containing messages of political dissent. Specifically, these attacks have tried to squelch opposition to bauxite mining efforts in Vietnam, an important and emotionally charged issue in the country.

Since some anti-virus vendors have already introduced signatures to help detect this specific malware, we recommend the following actions, particularly if you believe that you may have been exposed to the malware: run regular anti-virus as well as anti-spyware scans from trusted vendors, and be sure to install all web browser and operating system updates to ensure you’re using only the latest versions. New technology like our suspicious account activity alerts in Gmail should also help detect surveillance efforts. At a larger scale, we feel the international community needs to take cybersecurity seriously to help keep free opinion flowing.

Federal Support for Federated Login

Jay — Wed, 03 Mar 2010 13:36:00 +0000

Posted by Eric Sachs, Senior Product Manager, Google Security

Last November, we discussed the progress that account login systems operating via standards-based identity technologies like OpenID have achieved across the web. As more websites seek to interact with one another to provide a richer experience for users, we're seeing even more interest in finding a secure way to enable that kind of information sharing while avoiding the hassle for users of creating new accounts and passwords.

Excitement for technology like OpenID is not limited to the private sector. President Obama's open government memorandum last year spurred the creation of a pilot initiative in September to enable U.S. citizens to more easily sign in to government-run websites. Google joined a number of other companies to explore ways to answer that call.

Now, several months later, some interesting things are taking shape. The Open Identity Exchange (OIX), a new organization and certification body focused on online identity management, today named Google among the first identity providers to be approved by the U.S. Government as meeting federal standards for identity assurance. This means that Google's identity, security, and privacy specifications have been certified so that a user can register and log in at U.S. government websites using their Google account login credentials. The National Institute of Health (NIH) is the first government website ready to accept such credentials, and we look forward to seeing other websites open up to certified identity providers so that users will have an easier and more secure time interacting with these resources.

Our hope is that the work of the OIX and other groups will continue to grow and help facilitate more open government participation, as well as improve security on the Internet by reducing password use across websites.

Protecting Users and Ads from Malware

Jay — Fri, 16 Oct 2009 21:05:00 +0000

Posted by Eric Davis, Head of Anti-Malvertising

As part of Cyber Security Awareness Month, we're highlighting cyber security tips and features to help ensure you're taking the necessary steps to protect your computer, website, and personal information. For general cyber security tips, check out our online security educational series or visit http://www.staysafeonline.org/.

At Google, we always aim to provide users with useful, relevant information. Readers of this blog know that we also work hard to detect malicious content on the web and protect users from harm. But did you know that we strive for the same level of relevance, and work equally as hard to protect users, in our online advertising business?

The mainstream media has recently picked up on the topic of malvertising (malware-infected advertising). Google's Anti-Malvertising Team works hard in this area and would like to take this time to share some important safety tips. We work closely with the Anti-Malware Team to identify trends and improve automated detection systems. We also educate users, develop policies and act as a liaison between the online security and online advertising communities.

Whether you're a web publisher who accepts ads on your website, or a home user who enjoys browsing the wide variety of advertising-supported content available on the web, we expect the resources below will help protect you from malvertising.

What is "Malvertising?"
"Malvertising" = malware + advertising. Haven't heard of it? The terminology may be new, but we can all understand the concept. Although malware distributors have attempted to spread malware through online ads for years, ever-improving prevention and detection methods have made it unlikely for most Internet users to have encountered a "bad ad" firsthand. However, it's important to make sure that you (and your computer) are properly prepared in case you encounter any source of malware on the web — whether it is an infected ad, a hacked site, a dangerous link, or someone who is pretending to be someone they're not.

Anti-Malvertising.com
We created Anti-Malvertising.com earlier this year as a resource for all members of the online ecosystem. Anti-Malvertising.com contains tips designed for publishers, ad operations teams, and Internet users to help protect their websites, networks, and computers.

Tips for Web Publishers: Know Who You're Working With, Perform Comprehensive QA, & Have a Plan in Place
Anti-Malvertising.com includes a custom search engine to help individual ad networks, publishers, and ad operations teams conduct quick background checks on prospective advertisers. It indexes a variety of independent, third party sites that track possible attempts to distribute malware through advertising. It is intended to be used as one of the steps in a publisher's background check process.

In some recent cases, infected ads that had already been caught and publicized by security researchers have remained active within some advertising systems. Anti-Malvertising.com's malvertising research engine makes it easier for the online advertising and security communities to share information and collaborate to help protect users from emerging threats.

For more detailed guidance on the following tips, visit http://www.anti-malvertising.com/tips-for-publishers

Pay close attention to all agencies and advertisers with whom you work.
Perform due diligence by thoroughly checking prospective partners' references and credentials.
Perform comprehensive QA on all ad creatives.
Protect your own computer and website from infection.
Be aware that various ad networks and exchanges may have significantly different standards for the prevention and detection of malware. No automatic detection system, however robust, can substitute for your own vigilance. However, we strongly advise against exposing your site to harm by using networks or exchanges without strong anti-malware security measures in place.
Ensure your Ad Operations team has an incident response plan in place (for guidance, visit http://www.anti-malvertising.com/tips-for-ad-operations).

Tips for Users: Protect Your Computer, Update Regularly, and Avoid Getting Tricked

Make sure your browser, operating system, software and plugins are all updated regularly (enable auto-updates when possible).
Be aware that malware can be disguised as antivirus/antispyware software in order to trick people into buying or downloading it. Fake (and harmful) software of this kind is known in the web security community as "rogue security software." How to avoid getting tricked? Always research a company's reputation before downloading its software or visiting its website, and be wary of unexpected warnings from products you haven't installed yourself. You can view a list of some legitimate free security scans at http://www.staysafeonline.org/content/free-security-check-ups.
Exercise caution whenever you're prompted to download an email attachment, follow an instant message link, install a plug-in, or download an unfamiliar piece of software.

Protecting the Free Availability of Online Content
In addition to providing visibility to advertisers, revenue to publishers, and information to users, the online advertising business model also enables anyone with an Internet connection to access an entire world of content for free. By increasing our vigilance as a community, we can help to keep online ads safe and preserve the wide access to information that advertising enables.

Password strength and account recovery options

Jay — Wed, 15 Jul 2009 18:54:00 +0000

Posted by Macduff Hughes, Engineering Director

There's been some discussion today about the security of online accounts, so we wanted to share our perspective. These are topics that we take very seriously because we know how important they are to our users. We run our own business on Google Apps, and we're highly invested in providing a high level of security in our products. While we can't discuss individual user or customer cases, we thought we'd try to clear up any confusion by taking some time to explain how account recovery works with various types of Google accounts and by revisiting some tips on how users can help keep their account data secure.

One of the more common requests for assistance that we receive from regular Gmail users is to help them regain access to their accounts after they have misplaced or forgotten their password. We know that it can be frustrating when you can't access your account, and we've worked hard to come up with a system designed to help our users regain access to their accounts as smoothly as possible while taking appropriate precautions to protect their account security. When you select a password as you create an account, we recommend that you also choose a security question and provide a secondary email address. Recently, we also added a field where you can input a mobile phone number to assist with later account recovery. We regularly provide tips about how you can choose good passwords and security questions, and we also share our best ideas for what to do when you can't access your account. It's important to keep your password, security question, and secondary email address up to date. It's not enough to just tell us your email address to try to change your password. The security question helps us identify you, but if you want to initiate a password reset, we'll only send that information to the secondary address or the mobile phone number you provide.

We handle password recovery differently for our Google Apps customers. There is no password recovery process for individual Google Apps users. Instead, users must communicate directly with their domain administrator to initiate password changes on their individual accounts. Earlier this year we added new password security tools for Google Apps that allow administrators to set password length requirements and view password strength indicators to identify sufficiently long passwords that may still not be strong enough. For businesses that desire additional authentication security, since 2006 we have supported SAML Single Sign On, a protocol that allows organizations to use two factor authentication solutions such as certificates, smartcards, biometrics, one time password devices, and other stronger tokens.

If you're a regular Gmail user and you haven't updated your account information in a while, we recommend you do so by visiting your Google Account settings page now.

HTTPS security for web applications

Jay — Tue, 16 Jun 2009 20:06:00 +0000

Posted by Alma Whitten, Software Engineer, Security & Privacy Teams

A group of privacy and security experts sent a letter today urging Google to strengthen its leadership role in web application security, and we wanted to offer some of our thoughts on the subject.

We've long advocated for — and demonstrated — a focus on strong security in web applications. We run our own business on Google Apps, and we strive to provide a high level of security to our users. We currently let people access a number of our applications — including Gmail, Google Docs, and Google Calendar, among others — via HTTPS, a protocol that establishes a secure connection between your browser and our servers.

Let's take a closer look at how this works in the case of Gmail. We know that tens of millions of Gmail users rely on it to manage their lives every day, and we have offered HTTPS access as an option in Gmail from the day we launched. If you choose to use HTTPS in Gmail, our systems are designed to maintain it throughout the email session — not just at login — so everything you do can be passed through a more secure connection. Last summer we made it even easier by letting Gmail users opt in to always use HTTPS every time they log in (no need to type or bookmark the "https").

Free, always-on HTTPS is pretty unusual in the email business, particularly for a free email service, but we see it as an another way to make the web safer and more useful. It's something we'd like to see all major webmail services provide.

In fact, we're currently looking into whether it would make sense to turn on HTTPS as the default for all Gmail users.

We know HTTPS is a good experience for many power users who've already turned it on as their default setting. And in this case, the additional cost of offering HTTPS isn't holding us back. But we want to more completely understand the impact on people's experience, analyze the data, and make sure there are no negative effects. Ideally we'd like this to be on by default for all connections, and we're investigating the trade-offs, since there are some downsides to HTTPS — in some cases it makes certain actions slower.

We're planning a trial in which we'll move small samples of different types of Gmail users to HTTPS to see what their experience is, and whether it affects the performance of their email. Does it load fast enough? Is it responsive enough? Are there particular regions, or networks, or computer setups that do particularly poorly on HTTPS?

Unless there are negative effects on the user experience or it's otherwise impractical, we intend to turn on HTTPS by default more broadly, hopefully for all Gmail users. We're also considering how to make this work best for other apps including Google Docs and Google Calendar (we offer free HTTPS for those apps as well).

Stay tuned, but we wanted to share our thinking on this, and to let you know we're always looking at ways to make the web more secure and more useful.

Update @ 1:00pm: We've had some more time to go through the report. There's a factual inaccuracy we wanted to point out: a cookie from Docs or Calendar doesn't give access to a Gmail session. The master authentication cookie is always sent over HTTPS — whether or not the user specified HTTPS-only for their Gmail account. But we can all agree on the benefits of HTTPS, and we're glad that the report recognizes our leadership role in this area. As the report itself points out, "Users of Microsoft Hotmail, Yahoo Mail, Facebook and MySpace are also vulnerable to [data theft and account hijacking]. Worst of all — these firms do not offer their customers any form of protection. Google at least offers its tech savvy customers a strong degree of protection from snooping attacks." We take security very seriously, and we're proud of our record of providing security for free web apps.

Update on June 26th: We've sent a response to the signatories of the letter. You can read it here.