May 19, 2010

My Wordpress blog got injected - again!

Elad Sharf Security Researcher

At the beginning of the week and last week the WPSecurityLock Web site published alerts on prominent Wordpress injections. These injections redirect the visitor to a scareware site which falsely claims to have found an infection, i.e. a Rogue AV Web site. Here is a video that shows what exactly is going on from the user's perspective when accessing a compromised Web site with this attack:

The injection attacks are still ongoing. Dancho Danchev reported a domain which is related to this attack at the end of last month. The domain kdjkfjskdfjlskdjf.com is directly related to the ongoing attacks and still appears on injected sites. Another set of domains is losotrana.com, holasionweb.com, indesignstudioinfo.com and zettapetta.com.

Checking the number of hits with our ThreatSeeker ™ network over this past weekend revealed more than 23,000 infected pages with this kind of attack, and it's still growing. The malicious code is injected by the attackers into PHP files on the server. Typically an infected PHP file will start with this line of code at the top of it: eval(base64_decode( . Below is a screenshot showing how an infected page looks on an injected server:

If you're running a Wordpress installation it's highly recommended to check every PHP file for a possible injection.

The injected code is encoded with Base64. Once you decode the content you get this output:

The code above isn't very complex. First it makes sure some functions that it needs exist; if not, it creates them. The malicious code starts with ob_start that points to the mrobh function. This means that any output from the Web page will be buffered first (i.e. not rendered yet). In case the page is encoded with GZIP, the script tries to decode the page using its inbuilt GZIP decompression function gzdecode. Now that it's sure that the buffered content is clear, there is an attempt to match on a closing body tag </body>. If there's a match then the script (which resides encoded in the gml function) will be injected just before the </body> tag. If there's no </body> tag then the script will be injected at the end of the page. The gml function holds the injected script, decoded in Base64, but before delivering the script the function checks whether either Google or Yahoo search crawlers are visiting the page. If either of these two visit the page, the script will not be delivered. The reason why the attackers do this is simple: they don't want the search engines to pick up on their malicious activities.

The injected scripts lead to Web sites with a very low reputation that bring all sorts of mayhem: pharmaceutical spam, fake software shops, exploit sites, Zeus C&C sites, and last but not least, fake passports/fake documents sites. Yes, you can order yourself a fake passport or driving license in case you just happen to need one,  but I can't promise this won't get you in trouble: 

Many thanks for the help and fast cooperation of WPSecurityLock!

About Forcepoint

Forcepoint is the leading user and data protection cybersecurity company, entrusted to safeguard organizations while driving digital transformation and growth. Our solutions adapt in real-time to how people interact with data, providing secure access while enabling employees to create value.