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

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

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.

Helping webmasters with hacked sites

Posted by Oliver Barrett, Search Quality Team

(Cross-posted from the Webmaster Central Blog)

Having your website hacked can be a frustrating experience and we want to do everything we can to help webmasters get their sites cleaned up and prevent compromises from happening again. With this post we wanted to outline two common types of attacks as well as provide clean-up steps and additional resources that webmasters may find helpful.

To best serve our users it’s important that the pages that we link to in our search results are safe to visit. Unfortunately, malicious third-parties may take advantage of legitimate webmasters by hacking their sites to manipulate search engine results or distribute malicious content and spam. We will alert users and webmasters alike by labeling sites we’ve detected as hacked by displaying a “This site may be compromised” warning in our search results:



We want to give webmasters the necessary information to help them clean up their sites as quickly as possible. If you’ve verified your site in Webmaster Tools we’ll also send you a message when we’ve identified your site has been hacked, and when possible give you example URLs.

Occasionally, your site may become compromised to facilitate the distribution of malware. When we recognize that, we’ll identify the site in our search results with a label of “This site may harm your computer” and browsers such as Chrome may display a warning when users attempt to visit. In some cases, we may share more specific information in the Malware section of Webmaster Tools. We also have specific tips for preventing and removing malware from your site in our Help Center.

Two common ways malicious third-parties may compromise your site are the following:

Injected Content

Hackers may attempt to influence search engines by injecting links leading to sites they own. These links are often hidden to make it difficult for a webmaster to detect this has occurred. The site may also be compromised in such a way that the content is only displayed when the site is visited by search engine crawlers.



Example of injected pharmaceutical content

If we’re able to detect this, we’ll send a message to your Webmaster Tools account with useful details. If you suspect your site has been compromised in this way, you can check the content your site returns to Google by using the Fetch as Google tool. A few good places to look for the source of such behavior of such a compromise are .php files, template files and CMS plugins.

Redirecting Users

Hackers might also try to redirect users to spammy or malicious sites. They may do it to all users or target specific users, such as those coming from search engines or those on mobile devices. If you’re able to access your site when visiting it directly but you experience unexpected redirects when coming from a search engine, it’s very likely your site has been compromised in this manner.

One of the ways hackers accomplish this is by modifying server configuration files (such as Apache’s .htaccess) to serve different content to different users, so it’s a good idea to check your server configuration files for any such modifications.



This malicious behavior can also be accomplished by injecting JavaScript into the source code of your site. The JavaScript may be designed to hide its purpose so it may help to look for terms like “eval”, “decode”, and “escape”.

Cleanup and Prevention

If your site has been compromised, it’s important to not only clean up the changes made to your site but to also address the vulnerability that allowed the compromise to occur. We have instructions for cleaning your site and preventing compromises while your hosting provider and our Malware and Hacked sites forum are great resources if you need more specific advice.

Once you’ve cleaned up your site you should submit a reconsideration request that if successful will remove the warning label in our search results.

As always, if you have any questions or feedback, please tell us in the Webmaster Help Forum.

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

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

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

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

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.