Google Online Security Blog: 2007

Help us fill in the gaps!

November 29, 2007

Posted by Ian FetteWe've been targeting malware for over a year and a half, and these efforts are paying off. We are now able to display warnings in search results when a site is known to be malicious, which can help you avoid drive-by downloads and other computer compromises. We are already distributing this data through the Safe Browsing API, and we are working on bringing this protection to more users by integrating with more Google products. While these are great steps, we need your help going forward!
Currently, we know of hundreds of thousands of websites that attempt to infect people's computers with malware. Unfortunately, we also know that there are more malware sites out there. This is where we need your help in filling in the gaps. If you come across a site that is hosting malware, we now have an easy way for you to let us know about it. If you come across a site that is hosting malware, please fill out this short form. Help us keep the internet safe, and report sites that distribute malware.

Auditing open source software

October 8, 2007

Written by Chris Evans, Security Team

JDK. In May 2007, I released details on an interesting bug in the ICC profile parser in Sun's JDK. The bug is particularly interesting because it could be exploited by an evil image. Most previous JDK bugs involve a user having to run a whole evil applet. The key parts of code which demonstrate the bug are as follows:

TagOffset = SpGetUInt32 (&Ptr); if (ProfileSize < TagOffset) return SpStatBadProfileDir; ... TagSize = SpGetUInt32 (&Ptr); if (ProfileSize < TagOffset + TagSize) return SpStatBadProfileDir; ... Ptr = (KpInt32_t *) malloc ((unsigned int)numBytes+HEADER);

Both TagSize and TagOffset are untrusted unsigned 32-bit values pulled out of images being parsed. They are added together, causing a classic integer overflow condition and the bypass of the size check. A subsequent additional integer overflow in the allocation of a buffer leads to a heap-based buffer overflow.

gunzip. In September 2006, my colleague Tavis Ormandy reported some interesting vulnerabilities in the gunzip decompressor. They were triggered when an evil compressed archive is decompressed. A lot of programs will automatically pass compressed data through gunzip, making it an interesting attack. The key parts of the code which demonstrate one of the bugs are as follows:

ush count[17], weight[17], start[18], *p; ... for (i = 0; i < (unsigned)nchar; i++) count[bitlen[i]]++;

Here, the stack-based array "count" is indexed by values in the "bitlen" array. These values are under the control of data in the incoming untrusted compressed data, and were not checked for being within the bounds of the "count" array. This led to corruption of data on the stack.

libtiff. In August 2006, Tavis reported a range of security vulnerabilities in the libtiff image parsing library. A lot of image manipulation programs and services will be using libtiff if they handle TIFF format files. So, an evil TIFF file could compromise a lot of desktops or even servers. The key parts of the code which demonstrate one of the bugs are as follows:

if (sp->cinfo.d.image_width != segment_width || sp->cinfo.d.image_height != segment_height) { TIFFWarningExt(tif->tif_clientdata, module, "Improper JPEG strip/tile size, expected %dx%d, got %dx%d",

Here, a TIFF file containing a JPEG image is being processed. In this case, both the TIFF header and the embedded JPEG image contain their own copies of the width and height of the image in pixels. This check above notices when these values differ, issues a warning, and continues. The destination buffer for the pixels is allocated based on the TIFF header values, and it is filled based on the JPEG values. This leads to a buffer overflow if a malicious image file contains a JPEG with larger dimensions than those in the TIFF header. Presumably the intent here was to support broken files where the embedded JPEG had smaller dimensions than those in the TIFF header. However, the consequences of larger dimensions that those in the TIFF header had not been considered.

Information flow tracing and software testing

September 17, 2007

Posted by Will Drewry, Security TeamSrinath's LemonoriginallyWOOT'07paperFlayerdynamic analysis frameworkdownloadcontributionsfeedback

Automating web application security testing

July 16, 2007

Posted by Srinath Anantharaju, Security TeamStored XSSReflected XSS

Injection in regular HTML body - angled brackets not filtered or escaped

<b>Your query '<script>evil_script()</script>' returned xxx results</b>

Injection inside tag attributes - double quote not filtered or escaped

<form ...
<input name="q" value="blah"><script>evil_script()</script>">
</form>

Injection inside URL attributes - non-http(s) URL

<img src="javascript:evil_script()">...</img>

In JavaScript context - single quote not filtered or escaped

<script>
var msg = 'blah'; evil_script(); //';
// do something with msg variable
</script>

Update:

The reason behind the "We're sorry..." message

July 9, 2007

Posted by Niels Provos, Anti-Malware TeamCAPTCHAsorrysorryACM WORM 2006Search Worms [PDF]Santyfirst post

Phishers and Malware authors beware!

June 18, 2007

Posted by Brian Rakowski and Garrett Casto, Anti-Phishing and Anti-Malware TeamsSafe Browsing APIThe API is still experimental, but we hope it will be useful to ISPs, web-hosting companies, and anyone building a site or an application that publishes or transmits user-generated links. Sign up for a key and let us know how we can make the API better. We fully expect to iterate on the design and improve the data behind the API, and we'll be paying close attention to your feedback as we do that. We look forward to hearing your thoughts.

Thwarting a large-scale phishing attack

June 11, 2007

Posted by Colin Whittaker, Anti-Phishing Team
In addition to targeting malware, we're interested in combating phishing, a social engineering attack where criminals attempt to lure unsuspecting web surfers into logging into a fake website that looks like a real website, such as eBay, E-gold or an online bank. Following a successful attack, phishers can steal money out of the victims' accounts or take their identities. To protect our users against phishing, we publish a blacklist of known phishing sites. This blacklist is the basis for the anti-phishing features in the latest versions of Firefox and Google Desktop. Although blacklists are necessarily a step behind as phishers move their phishing pages around, blacklists have proved to be reasonably effective.Not all phishing attacks target sites with obvious financial value. Beginning in mid-March, we detected a five-fold increase in overall phishing page views. It turned out that the phishing pages generating 95% of the new phishing traffic targeted MySpace, the popular social networking site. While a MySpace account does not have any intrinsic monetary value, phishers had come up with ways to monetize this attack. We observed hijacked accounts being used to spread bulletin board spam for some advertising revenue. According to this interview with a phisher, phishers also logged in to the email accounts of the profile owners to harvest financial account information. In any case, phishing MySpace became profitable enough (more than phishing more traditional targets) that many of the active phishers began targeting it.Interestingly, the attack vector for this new attack appeared to be MySpace itself, rather than the usual email spam. To observe the phishers' actions, we fed them the login information for a dummy MySpace account. We saw that when phishers compromised a MySpace account, they added links to their phishing page on the stolen profile, which would in turn result in additional users getting compromised. Using a quirk of the CSS supported in MySpace profiles, the phishers injected these links invisibly as see-through images covering compromised profiles. Clicking anywhere on an infected profile, including on links that appeared normal, redirected the user to a phishing page. Here's a sample of some CSS code injected into the "About Me" section of an affected profile:
<a style="text-decoration:none;position:
absolute;top:1px;left:1px;" href="http://myspacev.net"><img
style="border-width:0px;width:1200px; height:650px;"
src="http://x.myspace.com/images/clear.gif"></a></style> "Why won't it let any of my friends look at my pictures?" regarding our warnings on these phishing pages, suggesting that even an explicit warning was not enough to protect many users. The effectiveness of the attack and the increasing sophistication of the phishing pages, some of which were hosted botnetsThings you can do to help end phishing and Internet fraud

Learn to recognize and avoid phishing. The Anti-Phishing Working Group has a good list of recommendations.

Update your software regularly and run an anti-virus program. If a cyber-criminal gains control of your computer through a virus or a software security flaw, he doesn't need to resort to phishing to steal your information.

Use different passwords on different sites and change them periodically. Phishers routinely try to log in to high-value targets, like online banking sites, with the passwords they steal for lower-value sites, like webmail and social networking services.

Web Server Software and Malware

June 5, 2007

Web server software across the Internet.

Web server software distribution across the Internet.

Netcraft web server surveyWeb server software across servers distributing malware.

Web server software distribution across malicious servers.
Distribution of web server software by country.

Web server distribution by country

Malicious web server distribution by country

The figure on the left shows the distribution of all Apache, IIS, and nginx webservers by country. Apache has the largest share, even though there is noticeable variation between countries. The figure on the right shows the distribution, by country, of webserver software of servers either distributing malware or hosting browser exploits. It is very interesting to see that in China and South Korea, a malicious server is much more likely to be running IIS than Apache.

We suspect that the causes for IIS featuring more prominently in these countries could be due to a combination of factors: first, automatic updates have not been enabled due to software piracy (piracy statistics from NationMaster, and BSA), and second, some security patches are not available for pirated copies of Microsoft operating systems. For instance the patch for a commonly seen ADODB.Stream exploit is not available to pirated copies of Windows operating systems.

Overall, we see a mix of results. In Germany, for instance, Apache is more likely to be serving malware than Microsoft IIS, compared to the overall distributions of these servers. In Asia, we see the reverse, which is part of the cause of Microsoft IIS having a disproportionately high representation at 49% of malware servers. In summary, our analysis demonstrates how important it is to keep web servers patched to the latest patch level.

On virtualisation

May 29, 2007

Posted by Tavis Ormandy, Security TeamPanayiotis' and Niels' postpaperCanSecWestbitblt routines
Reduce the attack surface
Treat virtual machines as services that can be compromised
Keep software up to date

Introducing Google's online security efforts

May 21, 2007

Posted by Panayiotis Mavrommatis and Niels Provos, Anti-Malware TeamOnline security is an important topic for Google, our users, and anyone who uses the Internet. The related issues are complex and dynamic and we've been looking for a way to foster discussion on the topic and keep users informed. Thus, we've started this blog where we hope to periodically provide updates on recent trends, interesting findings, and efforts related to online security. Among the issues we'll tackle is malware, which is the subject of our inaugural post.

MalwarepluginsmalwareGoogle'smalwaresearch resultsGoogle Desktop Search0.1%paperbillionsmalwaremalwaremalware

Location of compromised web sites.

Location of malware distribution servers. These are servers that are used by malware authors to distribute their payload. Very often the compromised sites are modified to include content from these servers. The color coding works as follows: Green means that we did not find anything unsual in that country, yellow means low activity, orange medium activity and red high activity.

Guidelines on safe browsing
First and foremost, enable automatic updates for your operating system as well your browsers, browser plugins and other applications you are using. Automatic updates ensure that your computer receives the latest security patches as they are published. We also recommend that you run an anti-virus engine that checks network traffic and files on your computer for known malware and abnormal behavior. If you want to be really sure that your system does not become permanently compromised, you might even want to run your browser in a virtual machine, which you can revert to a clean snapshot after every browsing session.

Webmasters can learn more about cleaning, and most importantly, keeping their sites secure at StopBadware.org's Tips for Cleaning and Securing a Website.

Security Blog