This past weekend one compromised Web site in particular caught my attention. Based on my analysis, the site was compromised because it was running an old version of WordPress (3.2.1) that is vulnerable to publicly available exploits  . The Web site injection is only somewhat interesting. What is more interesting is the redirection chain and resulting exploit site, which might be a new or updated Exploit Kit to watch out for.
Our research indicates that whoever is behind the injection has infected other sites. From our analysis the number of infections is growing steadily (100+).
The site was injected with the following code segment:
The above code is a simple substitution cipher algorithm that applies a basic obfuscation technique, which when deobfuscated produces the following code:
The code above instructs the Web browser to write an iframe to the document of the Web page:
Once the iframe is written to the Web page, the code forces a connection to the malicious site, which downloads content to the user’s machine (all without the user’s permission or knowledge). The malicious Web site serves a page that we assume includes the Incognito Exploit Kit, because one of Incognito’s characteristics is that it uses showthread.php as the Web page filename to serve user exploits. We are still not positive if this is Incognito 2.0 or a completely unknown exploit kit. Most kits, much like Incognito, test the user’s browser and/or OS type and version and serve the user various exploits, e.g. PDF exploits, or browser specific bugs. But this Exploit Kit appears to serve only the below Java exploit:
New or Updated Exploit Kit?
The Java exploit being served is CVE-2011-3544 (Oracle Java Applet Rhino Script Engine Remote Code Execution), which most Exploit Kits adopted in December 2011 because it is cross-platform and exploits a design flaw. Normally, kits use a variety of exploits, but as can be seen in the screen shot below, regardless of what OS or browser we used for testing, this Exploit Kit attempted to exploit ONLY our Java Runtime Environment (JRE). It did not attempt any other exploit.
Exploit and Dropped Malware
An attacker can bypass the Rhino scripting engine protection by generating an error object, which runs in elevated privileges and executes code that disables the Security Manager. Once the Security Manager is disabled, the attacker can execute code with full permissions.
If the user isn’t patched and is therefore vulnerable to CVE-2011-3544 (see patch details here), two Java files (VirusTotal links  ) drop Tdss (Virus Total link  = 9/43). The Tdss rootkit is one of the stealthiest rootkits in the wild. Its goal is to acquire total control of infected PCs and use them as zombies for its botnet.
Prevalence of Injection Campaign
Since we started tracking this infection this past weekend, we have discovered that this is an infection campaign. The WebsenseR ThreatSeekerR Network has found 100+ compromised Web sites, all with similar infection characteristics. The compromised Web sites all share these traits:
- Running WordPr ess 3.2 .1
- Force a drive by download via iframe to the same malicious set of domains hosting a PHP Web page in the form of: [subdomain].osa.pl/showthread.php?t=.*
- Attempt exploitation using CVE-2011-3544
- If exploitation is successful, installation of the Tdss rootkit on the user’s machine
Here is an example listing of sites that have been infected:
The number of Web pages running the vulnerable, targeted version of Word Press 3.2.1 is in the hundreds of thousands. It is unknown at this time how the attackers are choosing which sites to infect.
What To Do If You Are Running WordPress 3.2.1
If you’re running WordPress 3.2.1, we recommend that:
- You upgrade to the latest stable version of WordPress.
- Check the source code of all your Web pages to see if you’ve been infected (see the code above). If you have been infected, be sure to upgrade WordPress while simultaneously removing the injected code so that your Web pages aren’t simply being reinfected after being cleaned.
Notifying Compromised Web site owners
As a matter of practice, we attempt to notify certain sites of their infection. First we use the email address that appears in the “Contact Us” section of the site, and then we use the email address in the whois registration database. If those attempts are unsuccessful, we attempt to notify a site owner through their facebook page (we have had very good success with this technique). Our recommendation when attempting to take down malicious URLs is to follow the best practices described in a document published by StopBadWare.org (found here).
Websense customers are protected from these threats by ACETM, our Advanced Classification Engine.
Stephan Chenette – Principal Security Researcher
Leave a reply