People, Please Patch WordPress!

December 6, 2013 - By Chris Larsen

First, forgive me as I indulge in a bit of nostalgia...

A little over five years ago, the WebPulse malware/threat research team decided to start doing an internal blog at Blue Coat, since a lot of "Bluecoaters" didn't really know what we did. (A year or so after that, we launched the public version, since even fewer outsiders knew about what we did...)

Anyway, the very first internal blog post dealt with a hacked web site (belonging to the government of Ghana) which was hosting links to, among other things, some shady pharmaceutical sites.


These days, of course, the WebPulse team focuses primarily on malware, not spam/scam activity. And this is reflected in our most recent posts on Search Engine Poisoning (SEP) activity.

However, the good old Viagra-SEP networks haven't gone away, and we flag them as we come across them in our malware research.


Yesterday, I ran across an interesting case, involving a network that used hacked WordPress sites to host its SEP link-farm pages. One of the hacked sites ( belongs to a Canadian internet services company:

screenshot of main site


Unfortunately, in the background, their site was serving pages like this:

screenshot of sample SEP page


There were a lot of these pages. From the links at the bottom of the page, you can see that it's claiming to have at least 1,477 such pages. (In fact, when I tried various numbers for the "rxitem", I determined that the number of pages was somewhere between ten thousand and ten billion -- as dozens of pages I tested between "1" and "10001" resolved, but page "9999999999" did not.)


Fortunately, these pages were not something a typical visitor to the site would ever see. And even someone arriving here after clicking on a poisoned link in some search engine results would not see the page, unless they had Javascript turned off in their browser, as I did, since otherwise they'd immediately be redirected to a site like this:

screenshot of sample pharma site


There are several other active pharma sites in this network, one of which is somewhat ironic, since the starting point of the investigation was a Canadian ISP:

screenshot of another pharma site

Ah, yes, the good old "Canadian Pharmacy" spam/scam sites! As I said at the beginning, that brings back a lot of memories...


The security team at turned out to be very sharp. They responded quickly to get this removed, and shared some of the details behind the hack, and the steps they took to remediate it. (And, they very kindly gave permission to share some of that, as the purpose of this post is not to "point the finger" at, but to illustrate how even a well-run site can fall victim to hacks focusing on WordPress, which seems to have a lot of weak links -- at least, judging by the amount of compromised sites we see in our logs each day.)


The intrusion took place a week earlier (11/27), when someone uploaded a PHP file manager script ("one of those semi-encrypted (eval(gzdecode() kinda things") into the /wp-content/uploads directory via a hole in the "wp_mailinglist" plugin. From there, the attackers could upload anywhere the "nobody" user was allowed to write. They dropped an index.php script into the /wp-content/ directory that remote-loaded code with eval(open(url)) whenever the "rxitem" parameter was given to it.

(This way, the attackers didn't need to literally load 10,000 or more junk pages onto the server -- that's the sort of thing that gets noticed! -- they could simply generate the pages as needed.)

Interestingly, the wp_mailinglist plugin wasn't even something the site was actively using -- it had been added by a developer who'd never gotten around to finishing that feature...


For remediation (and on-going maintenance), the team suggests the following steps:

- Remove/disable unused plugins. [Ideally, people with responsibility for web site security will review all plugins their site uses, from a risk/benefit perspective: knowing that each such plugin increases the "attack surface" of the site, is the benefit it provides worth the additional risk?]

- Modify your apache config to not allow the PHP engine to run on any files within the wp-content/uploads tree, so even if someone can upload arbitrary files in there, they won't be easily executable.

- Remove write permissions on the wp-content tree.  It's convenient to allow WordPress to be able to self-update plugins, but not at the cost of having the whole directory tree forced to be writable by the server.

- Disable allow_url_fopen and allow_url_include in php.ini -- why is that defaulted to allowed?

- Finally, upgrade WordPress and all plugins to their latest versions!


Excellent advice, and a lesson to all of us! (Now, if you'll excuse me, I've got to go find out if we've got any sites running WordPress in our infrastructure, and send whomever is managing them a copy of this blog post...)