Fake virus scan running in Google Chrome

After a few seconds on the page the following occurred:

• Result page successfully hijacked and a faux Windows Explorer interface loaded.
• A fake virus scan ran in the look-alike Explorer window, conveniently uncovering trojans and other malware.
• Alerts, dialogs and phony windows displayed in an attempt to execute a little social engineering.

After attempting to interact with the document the following occurred:

• A potentially threatening program file download initiated if you clicked on anything in the page.
• Additional warning dialog and pop-up window displayed on attempting to unload the page (e.g. hit the back button).
• Intermittently, the Google Chrome 3.0 back-button and tab [x] icon stopped functioning as expected.

The last point was of particular interest at first, as it is not like modern browsers to allow websites to modify browser functionality. But after some additional research, it was clear the hijack was more complex than a page titled with search engine optimization in mind. This article will study the hijacking in some technical detail, discuss the black hat SEO likely used to get the rogue application listed on Google and how the app was able modify the expected functionality of browser controls in Chrome 3.0.

The bait and switch

How does activating a seemingly innocuous (and tasty) link from Google land someone on a potentially dangerous page? 302. HTTP 302 that is.

After locating the offending link on Google, I used a client-side proxy to trap the HTTP headers for a play-by-play review:

GET http://woodstockfolkmusic.com/bftwe/tiijy/carne.php HTTP/1.1
HTTP/1.1 302 Found
GET http://goodstats1.net/in.cgi?2 HTTP/1.1
HTTP/1.1 302 Found
GET http://sunstats1.net/in.cgi?default HTTP/1.1
HTTP/1.1 302 Found
GET http://sunstats1.net/redirect3/ HTTP/1.1
HTTP/1.1 302 Found
GET http://bookletantcars.cn/?pid=283s01&sid=2a15a0 HTTP/1.1
HTTP/1.1 302 Found
GET http://wwwantispyware10.com/scan1/?pid=283s1&engine=%3D3W59jDuNTIuMTUxLjE1MyZ0aW1lPTEyNTE2NYcMOAkN HTTP/1.1
HTTP/1.1 200 OK

Stepping through the sequence we can see the initial GET request followed by a 302 redirect response. Several redirects later and the browser successfully arrives at destination malware, beef stew long forgotten.

Black hat inside

The next thing I tried was to analyze the source of the PHP file cataloged by Google, which was not difficult for two reasons:

1. Directory listing was enabled on the web server, and
2. Navigating directly to the PHP file caused the page to load without redirect.

The PHP file was stowed away on woodstockfolkmusic.com (which appears to be a legitimate folk music site based out of Illinois) along with some 300 similar PHP files, covering a range of topics from Alba to Wisconsin. The files found contained mostly deprecated HTML markup (remember the <marquee> tag anyone?) and no PHP script or META tags. The files were stuffed with hundreds of keywords, a form of spamdexing I thought was no longer practiced. Nevertheless the result still appeared on Google, possibly with a little help from cloaking.

Engage the cloaking device

Curious as to why the PHP files (with no PHP script or META tags, mind you) would redirect links coming from Google, but not when loaded directly, I again pulled up a client-side proxy for closer investigation. Below are the results of several slightly modified HTTP requests for the file initially requested by Google. Each request contains a modified Referer request-header field.

First request
Hacked the Referer field to point to the Google domain.

GET http://woodstockfolkmusic.com/bftwe/tiijy/carne.php HTTP/1.1
Host: www.google.com
Proxy-Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.27 Safari/532.0 Paros/3.2.13
Referer: http://www.google.com/
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

First response
Hijack successful; browser redirected to bogus antivirus page.

HTTP/1.1 200 OK
Date: Sun, 18 Oct 2009 22:33:31 GMT
Server: Apache
X-Powered-By: PHP/5.2.8
Connection: close
Content-Type: text/html

Second request
Hacked the Referer field to a domain other than Google.

GET http://woodstockfolkmusic.com/bftwe/tiijy/carne.php HTTP/1.1
Host: woodstockfolkmusic.com
Proxy-Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.27 Safari/532.0 Paros/3.2.13
Referer: http://www.habdas.org/
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

Second response
No hijack; browser sent directly to indexed page.

HTTP/1.1 200 OK
Date: Sun, 18 Oct 2009 22:31:36 GMT
Server: Apache/2.0.63 (Unix) mod_ssl/2.0.63 OpenSSL/0.9.8e-fips-rhel5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 PHP/5.2.6
X-Powered-By: PHP/5.2.6
Content-Type: text/html

Additional testing
Additional testing revealed page redirection would occur only when the Referer field was included in the HTTP request header, and only when the field value contained certain phrases. Two phrases found to trigger the hijack include “google” and “yahoo” (case insensitive) while other likely phrases such as “bing”, “msn”, “aol” and “ask” did not.

Note: I am I not currently aware if Yahoo is susceptible this particular brand of page hijacking. If you’ve seen it on Yahoo or know of any examples, please comment and let us know.

Testing for the presence of phrases “Googlebot”, “googlebot” or “google” and “bot” (separated) all resulted in the 302 redirects, which leaves some of the following possibilities:

• The 302 redirect (likely of the .htaccess kind found in the Antivirus 2009 approach) was turned on after the page was indexed.
• The web crawler that originally accessed the page did not pass the phrases “google” or “yahoo” in the Referer [sic] field in the HTTP request header.

Monitoring over a several day period landed the browser on some of the following domains, each with their own similar virus scan or some derivation:

• wwwantispyware10.com
• topantimalwarescan7.com
• top-antispyware-scan8.com
• computer-protection11.com
• webprosecurity.com
• guardpconline.com

The Chrome 3.0 Browser Button Issue

The Chrome button issues are happening on and off. Some of the changes in behavior I have witnessed using Chrome v3.0.195.27 (Win):

• Browser unable to navigate backwards in history;
• Navigation backwards in history only after several tries; and
• Tab hangs and cannot be closed, and Windows clocks, until the pop-up notification window is closed.

Example user agent string sent from a web browser during an HTTP request:
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.0.249.89 Safari/532.5

The above example, for instance, provides information such as browser and browser version, user locale (language), OS, system architecture and the layout engine used. When authoring documents for the Web, information from the user agent string can be valuable in determining how best to mark-up documents.

Getting the information is easy.

Collecting user agent strings

Two methods for accessing the user agent string include:

1. From the HTTP request header’s User-Agent field; and
2. Using DOM and JavaScript.

Reading from the User-Agent field

A benefit of using the HTTP header to gather data is simplicity of design.

HTTP request header showing the User-Agent field (in bold):

GET / HTTP/1.1
Host: livehttpheaders.mozdev.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.0.249.89 Safari/532.5
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

Using the HTTP header the user agent is transmitted directly to the HTTP server on page request, making it possible for servers to output the user agent string to a log file for later analysis. The user agent string alone provides enough information to implement on websites valuable browser support strategies such as graded browser support.

User agent retrieval using DOM and JavaScript

Using DOM and JavaScript, on the other hand, add additional development complexity, but provide more detailed and valuable analytic data, in addition to the user agent string alone. Tools like Urchin (now Google Analytics) utilize JavaScript and the DOM to gather analytic data about visitors.

Bookmark the following link to create a bookmarklet that will retrieve the user agent from a browser: javascript:alert(navigator.userAgent).

Regardless of the collection approach used, methods for extracting data from the string remain similar.

Data extraction methods

Once the user agent string(s) are collected, data extraction may take place. Two methods for reading and extracting information from the user agent string include brute force and pattern recognition:

• Under the brute force approach the user agent string is compared programmatically to a database of known strings. Though it offers a relatively simple implementation, the brute force approach can be difficult to maintain and becomes increasingly inefficient as comparison data sets grow larger.
• Thanks to RFC 2616 and preceding RFCs, and de facto standards for formatting user agent strings, another method known as pattern recognition is possible. Using pattern recognition the user agent string is broken into its component pieces and heuristics applied to gather information. Though more complex to implement than the brute force approach, pattern recognition does not suffer from the same problems in efficiency and maintainability in the long-run.

Due to its drawbacks in the application of extracting data form user agent strings, the brute force approach will not be discussed further in this article.

Pattern recognition on the user agent string

Check out Identify User Agent by string format recognition for an example of user agent pattern recognition. Though a little outdated, the article provides additional depth, in addition to some useful programming techniques and lax copyright restrictions.

User agent spoofing

Impersonating browsers and mobile devices is simple with Firefox. Just download User Agent Switcher plug-in and put it to the test at useragentstring.com. See Web Development and Debugging Tools for a list of tools useful for front end development.

Tools for Firefox

Build for standards.

Firebug > *

• Firebug integrates with Firefox to put a wealth of development tools at your fingertips while you browse.
• HTML Validator is a Mozilla extension that adds HTML validation inside Firefox and Mozilla.
• Web Developer adds a menu and a toolbar with various web developer tools.
• IE Tab, an extension from Taiwan, embeds Internet Explorer in a Mozilla/Firefox tab.
• ColorZilla provides Advanced Eyedropper, Color Picker, Palette Viewer and other colorful goodies for your Firefox.
• YSlow analyzes web pages and tells you why they’re slow.
• HttpFox monitors and analyzes all incoming and outgoing HTTP traffic between the browser and the web servers.
• MultiFirefox is a small launcher utility that allows you to run multiple versions of Firefox side-by-side.
• User Agent Switcher to spoof user agent strings for browser support testing.
• Google Toolbar to visualize Page Rank.

Tools for Internet Explorer

Ensure application compatibility.

• Internet Explorer Developer Toolbar provides a variety of tools for quickly creating, understanding, and troubleshooting Web pages. It also allows for the inspection of the MSIE-specific CSS passed in through the use of Conditional Comments.
• A look-alike is just that, not the real thing. Here are the Internet Explorer Application Compatibility VPC Images, made available by Microsoft for use in testing browser compatibility with MSIE.

Other tools

Polish it to a bright shine.

• Selenium IDE for automated testing, helping unlock the potential for test-driven development in the UI layer.
• Paros is a simplistic proxy tool that allows you to trap raw HTTP request and response headers for analysis and testing.