Sometime yesterday morning I logged into my TextDrive account to make some more changes to my blog template and noticed two odd folders in my blog root directory called rh4m4.t35.com and www.kolortavil.org. I believe that the folders were empty, but nevertheless, it was clear that someone had broken into my site.
I deleted the suspicious folders and quickly reviewed the changes I’d made the day before and realized that the culprit was probably wp-super-cache, a new WordPress plugin that I’d installed the night before. I went ahead and disabled and then deleted the plugin (taking care to delete the supercache folder in /wp-content/cache/) and notified Joyent customer support (transcript and notes here) and Donncha Caoimh, the developer. I also twittered about the incident.
Sometime later I saw that Stephanie Sullivan had replied to me letting me know that Tiffany Brown was having a similar experience (though with greater consequence) and a report in the WordPress forums. Both Kristie Wells from Joyent and Donncha got back to me, the former confirming my suspicion that it was some kind of PHP Injection vulnerability and the latter asking for additional information.
This morning I found Chris Heilmann’s post on the subject confirming my concerns:
…Checking the folders created I found the same two injection attempts Tiffany mentioned. The caching allowed code injected as txt urls via “i” or “s” parameters to be executed.
In my case I found that half my server was mirrored into the supercache folder in the plugin’s cache folder. Not good.
I was happy to see that my etc folder and other more interesting bits were not reached yet before I deactivated the plugin. Right now I am playing grepmaster to see if there are some injections left. My action: deactived and deleted all caching plugins and their cache folders (best via SSH as FTP is a PITA with so many files).
I’ve now been in touch with Barry from Automattic and have followed up with Donncha, who have both been very patient and helpful in parsing through my logs trying to replicate the vulnerability.
The most likely culprit is an unquoted ABSPATH in v0.1 of the plugin. According to Donncha, “The ABSPATH part of the WPCACHEHOME definition could possibly have expanded when it was being written to the file. Unfortunately it wasn’t quoted so that may have done strange things to other variables like $cache_path. Barry says that the problem, though annoying, is just a bug and was likely just a misdirected attack on potentially vulnerably Drupal sites and that it won’t do more than create some benign directories in a WordPress install. Fortunately v0.3 of the plugin seems to have resolved the problem; meanwhile you can download or checkout the latest development version that corrects the ABSPATH issue.
I’ve written up my experience so far and let others know to watch out for irregularities if they choose to install the wp-super-cache plugin. I’m actually going to give the latest version another go and will report any problems here should I experience any.
While I’m at it, I’d like to point out the important role that Twitter and personal blogs played in tracking this down; and that Joyent support, Barry from Automattic and Donncha himself all played supportive roles in resolving this issue.
Factory Joe 
I have to concur, Donncha has been very interested and helpful about this. I talked to the security experts at work about the attacks and they are very common these days. The best prevention is to turn off any passthru, exec or other shell extensions and disallow file loading from http.
There’s a remotely exploitable security hole that allows the installation of a shellbot and the best Barry can say is “just a bug” and “misdirected attack on potentially vulnerably Drupal sites”.
Way to ignore and redirect what seems clearly like a real problem with a WordPress plugin that was targetted itself.
If you make a claim like “probably misdirected attack on Drupal” you should provide an in depth analysis that shows exactly why a script to exploit a Drupal vulnerability is in fact accidentally exploiting this wordpress vulnerability.
Hello Chris,
The vulnerability, you mentioned still exisits, even in the newest version 0.5.1.
I had seen similiar deeply nested folders in my root directory about 20 days ago. Since than, I’m checking all my template files and plugins, but couldn’t find anything unusual.
Today, I checked WordPress Super Cache, as it was the only plugin that was unleft and found the cause behind the vulnerability.
After digging further, I came across your post, which confirmed the issue.
DG…
http://www.ditii.com/
Chris,
I’ve noticed similiar activites on my site about 20 days back, and since then, I was busy checking all my template/plugin files, but couldn’t find any unusual thing therein.
Yesterday, I was zeored on to WordPress Super Cache, as that was the only plugin left unchecked. Later on, further digging confirmed my doubt and also came across your post.
I’ve written to donnacha on his email as well in your WordPress support forum thread about the vulnerability still exisiting in the latest version.
DG…
Does this bug still a problem?
The Version: 0.9.4.3 is now on, but I think I had a vulnerabily over this plugin…
I’m not sure, but I got an Exploit via … nothing to worry to much.
In windows Eset anti-virus marked my site as dangerous.
(thou it could be some javascript I put there, somewhere I think, with the wp-super-cache let someone in)
The Iframes where into de WP Core.. not in my template, so it was a real pain in the ass to now what the heck it was.
Now I put in my site the SECRET_KEY with a well password.. But, i activated again the wp-super-cache.. lets see what happends