Bety.php Hack. Part 2. Black Hats in Action.

This is the second article about the hacker attack against osCommerce-powered sites. In the first part, you can find the description of the attack along with detection and clean-up instructions. Now I want to show you what exactly hackers did and how they managed to poison Google search results.

The main goal is to demystify hackers and encourage webmasters to explore their own sites. The more you know about hackers, the better you’ll be at protecting your site against their attacks.

This post is based on the files and access logs of three compromised sites that I received from a webmaster who contacted me a couple of weeks ago.

Quick facts

1. The attack uses unpatched vulnerability in osCommerce 2.2 that allows an attacker to upload arbitrary files to compromised servers using a security hole in file_manager.php.
2. Only one of the three sites actually uses osCommerse (site-1).The rest two sites had been hacked using access gained via the hacked site-1.

Chronicle of the attack

In logs of site-1, I found several POST requests to “/admin/file_manager.php/login.php?a=1&action=save” (on December 9, 10, 16, 17, 18) from several different IPs. Right after those attacks I saw POST requests to newly created files called fly.php (the file that is used in the disclosed exploit — it executes arbitrary PHP code passed as a POST parameter) and flop.php. Apperantly those files provided full access to the site (to directories with write permission). One of such attacks created a file called mm.php (it provides a simple interface to upload files from a local computer to server).

December 21, 2009

12:13 – Hacker with IP 84.52.73.161 uses mm.php to upload an sh1.php file to the /images directory. sh1.php is a web shell. It equips hackers with a sophisticated graphical interface that provides almost full access to compromised sites. It allows hackers to browse directories, create and modify files, execute arbitrary PHP code, work with databases etc.

12:14 – 12:28 – the hacker uses the web shell to explore internals of the site-1.

12:14 – he discovers site-2 under the same account

12:23 – he discovers site-3 under the same account and decides to start the malware campaign there. He uploads sh1.php and bety.php there.

21:05 – The hacker submitted three site-3/bety.php?q=keywords pages to page2rss.com (Page2Rss helps monitor web sites that do not publish feeds).

21:06 – The hacker clicks on the created links on page2rss.com and visits site-3 to check that everything works as intended.

Links on page2rss.com are “nofollowed” but maybe this service somehow pings Google about new feeds, which makes the discovery faster?

21:31 – Googlebot comes to site-3 directly to bety.php pages and starts to index them. Apparently hackers somehow submitted a big batch of bety.php URLs to Google since it’s clear that it didn’t use site-wide discovery (didn’t follow links found in just indexed bety pages).

22:50 – Googlebot finishes indexing bety.php pages. 1976 malicious pages have been indexed.

The indexed pages become immediately available in search results. The first visitor from Google Search comes at 21:47. It is just in 16 minute after Google first discovered the bety pages and started indexing them and in 5 minutes after that visited page had been indexed. And at that time the initial indexing was still underway with more than an hour to go. 10 web surfers had visited the bety pages by the time googlebot left the site.

Some stats on visits from Google:

42 visits on December 21.
129 visits by December 31.

But wait, it’s just the beginning.

Bety on site-2

December 22

08:18 – The hacker with IP 84.52.73.161 returns to site-1 and works with it for about 6(!) hours using the sh1.php web shell. This time he wants to start the “bety” campaigns on site-1 and site-2.

08:22 – he uploads sh1.php and bety.php to site-2.

08:51 – the hacker has someone open the site-2/bety.php?q=so-you-think-you-can-dance-phone-number page using Microsoft Translator service.

09:32 – Googlebot comes to site-2 and starts to index the bety.php pages.

09:58 – first visitor clickes on the bety search result. As you can see, the indexed pages become searchable almost immediately.

10:36 – The first batch of 1592 bety.php pages is indexed. By this time 25 more visitors came to site-2 bety pages via Google search results.

18:38 – One of the bety links somehow makes it to twitter. The same minute Googlebot follows this link.

21:39 – Googlebot visits site-2 again and starts to index another batch of 5150 bety pages. This session lasts till 03:24 – of the next day (almost 6 hours).

Then Googlebot regularly visits site-2 and by the end of month it has indexed 8415 bety pages. As a result, there had been 1353 visits of malicious bety pages from Google search results on December 22, 1878 visits on December 23, and 5734 visits by the end of December.

Bety on Site-1

When Google picked up bety pages on site-2, the attacker switched back to site-1 and triggered the bety campaign there.

December 22, 2009

10:53 – a spammy comment with 438 links to site-1/bety.php?q=keywords pages has been published on my.mail.ru. 11:02 – Someone clickes on those links and opens a couple of bety pages.

12:35 – Googlebot comes to site-1 and starts to index the bety.php pages. It indexes 4887 malicious pages by 16:44.

12:59 – the first visitor from Google search.

466 – visits from Google search results on December 22.
1500 – visits from Goolge on December 23.
3136 – visits from Google by the end of December.

Sumarry

During the last 10 days of December, 2009, this hacker managed to drive 9019 visits from Google to malicious bety pages. (Google was the only source of traffic for those pages.) 7768 times the script that redirects visitors to malicious sites was loaded by web surfers from 4781 unique IPs. Quite impressive, given it only took a few hours of the hacker’s time.

The secret of bety.php

OK. So what does this bety.php do an how it manages to provide Google with so many different variants of pages that it considers worthwhile to show on first pages of search results?

Bety.php handles two types of request q and red.

Red requests

bety.php?red=keywords requests are used to retrieve the content of lname.php, which is a redirect script, like this:

window.location = "hxxp://basicallyantispyware .net/hitin .php?land=20&affid=33220";

Every 20 minutes, bety.php updates the content of the lname.php file pulling the domain name of the currently active malicious site from
hxxp://92.48.127.76/domain.php?password=d0cd05bf619266a045dfb4a016753a39

To hide the malicious redirect from search engines, red request handler checks IP addresses of visitors and doesn’t return anything if detects requests from known IP-ranges used by search engine crawlers.

Q requests

q requests return web pages specially crafted for Google.

When bety.php is opened for the first time, it creates a special directory called .cache (in new version .pages). It is the place where the bety script stores generated web pages.

When processing bety.php?q=keywords requests, the script checks if there is a pages called keywords.html in the cache directory. If it is, this page will be displayed. E.g. for /bety.php?q=2010-nfl-mock-draft request it checks for file .cache/2010-nfl-mock-draft.html.

If the cached file is missing (and initially there are no cached files at all) it is generated on the fly. Here is the structure of the generated files:

1. Keywords go to the title tag. (dashes replaced with spaces)
2. Background and text colors are random value (to make all pages look a bit different)
3. Capitalized keywords go to the h3 tag at the top of the page.
4. Below goes the current date (as a hint that the content is fresh)
5. Then there is a bullet-list of up to four links:
   1. The first is a link to .cache/map.html – (every generated web pages is added here)
   2. The next three items link to bety.php?q=keywords1, bety.php?q=keywords2, bety.php?q=keywords3, where keywordsN are top keywords returned by Google’s AJAX requests that are normally used for keywords suggestions in Google’s search forms.
6. Malicious redirect script<script src=”?red=keywords”></script>
7. 50 random descriptions from top 100 Google’s search results for keywords.
8. In new versions, they also add a buggy link to “hxxp://www.megaupload .com/ ?d=YQ3C29N6“
9. And finally, for tracking purpose, each bety page contains a script of a hit.ua counter. So you can check how successful this particular malware campaign is: http://c.hit.ua/hit?i=25418

Pretty straight forward, isn’t it? Those pages contain many relevant keywords and while they are fresh (first couple of days) Google temporarily boosts their ranking. And for multi-keywords searches this is enough to make it to the first page of results.

What is not clear to me is

1. How hackers submit thousands of new pages to Google so that it immediately (well, almost) starts to index them?
2. How does Google permit this many (thousands) automated requests from compromised servers? In the logs, is see periods of more that an hour of consecutive requests at a rate of about 25 requests/second (and each time both “search” and “complete” services are requested). When I try to automate (sorry Google) searches from my home computer with comparable request rate (sometimes I need to analyze large volumes of search results for my researches), my IP inevitably gets block within a few minutes.
3. If Google readily indexes thousands (on just one site) of junk pages every day, what is the share of such junk in its main index? More than 90% 50%? ;-)

What do you think?

To webmasters

Hackers are always on the look out for vulnerable websites that they can use for their malicious activities. As a site owner or webmaster you should be ready to deal with hacker attacks.

1. If you use third-party scripts on your site, make sure they are secured. Find instructions on how to harden default installations. Then regularly check for security advisories (e.g. in Secunia). And always upgrade whenever security patches are available.
2. Monitor your server for changes (new files and directories). This can help you detect suspicious unauthorized activity early on. The sooner you detect the problem and clean up your site, the less the damage (think dropped search engine ranking, malware warnings, etc.) BTW, can anyone suggest tools suitable for file system monitoring on shared hosting plans?
3. Although Google Analytics and similar statistics scripts may provide you with almost everything you need to know about your site, don’t forget about raw access logs. Hackers don’t add your tracking code in their files and requests to them will only be reflected in access logs (tools like Webalizer work with raw logs so they can also help if requests to illicit files are popular enough to make it to Webalizer reports.) Pay special attention to POST requests – they may help you identify security holes.
4. Google Webmaster Tools can also help reveal illicit content, reporting top searches and search keywords for your whole site, not limiting to pages that contain your tracking code. Irrelevant keywords in GWT reports is a strong sign of security problems.

Any comments?

Related posts:

• Bety.php – osCommerce Hack. Part 1
• Black Hat SEO for Virus Dissemination
• Rogue blogs redirect search traffic to bogus AV sites. Part 1.
• Rogue blogs redirect search traffic to bogus AV sites. Part 2.
• Stats Anomaly Reveals Website Security Issues