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 