wordpress post.php blank page: ’sploit!
July 29, 2008 on 8:38 am | In tech stoof | No Commentsin the past week or so, there have been a rash of wordpress ’sploits. i’m writing this up in the interest of saving ’sploitees some recovery time and headaches. i believe all of the exploited blogs were running downrev versions (2.6 is current as of this writing) at the time of exploit.
symptoms include:
- posts go blank or are truncated to random, short-ish lengths (4-5 sentences)
- edit.php returns a blank page on save
- post.php returns a blank page on save/publish
- preview.php returns a blank page
- plugins.php returns a blank page
- theme editor returns a blank page
in this particular sploit, the hackers were able to open a shell through PHP, and use it to find directories on the filesystem which were writable by the (unprivileged) webserver user. they uploaded a set of scripts that attempted to append each valid blog post with pharmaceutical spam, with a keyword of the hackers’ choosing. had everything worked, this would go unnoticed by end users. everything didn’t work.
to find out if this is the case for you, add the following to your wp-config.php:
define(’WP_DEBUG’,true);
if you then load your blog and get a PHP warning/notice about undefined variables, etc, it should barf out the filename of a rogue PHP script, likely to be outside the top-level directory of your blog.
to recover, one would optimally restore from a pre-hack SQL dump. if that isn’t possible or too much data would be lost, perform the following steps:
- back up your database. even if it’s hacked:
$ mysqldump –opt -Q -u user -p -h mysql.hostname dbname > wordpress-yyyymmdd.sql - upgrade to the current wordpress though as of this writing there are still upgrade issues with 2.6. 2.5.1 should suffice.
- back up the wp_options table: (wp_settings i think in earlier WP versions)
$ mysqldump –opt -Q -u user -p -h mysql.hostname dbname wp_options > wp_options.hacked.yyyymmdd.sql - copy the table dump:
$ cp wp_options.hacked.yyyymmdd.sql wp_options.fixed.yyyymmdd.sql - edit the copy in your favorite text editor. you’re looking for the line like:(103,0,’active_plugins’,'a:3:{i:0;s:23:\”../../../video/buzz.php\”;i:1;s:19:\”akismet/akismet.php\”;i:2;s:14:\”lr2Spam.03.php\”;}’,'yes’)in this case, the first entry between brackets is the rogue script. remove it:
(103,0,’active_plugins’,'a:3:{i:1;s:19:\”akismet/akismet.php\”;i:2;s:14:\”lr2Spam.03.php\”;}’,'yes’)
- import the corrected table:
$ mysql -u user -p -h mysql.hostname dbname < wp_options.fixed.yyyymmdd.sql - remove the rogue scripts and/or make them unreadable.
- test test test. removing the call to the rogue script fixed us up. i hope it fixes yours, too.
No Comments yet »
RSS feed for comments on this post. TrackBack URI
Leave a comment
You must be logged in to post a comment.
Powered by WordPress with Pool theme design by Borja Fernandez.
Entries and comments feeds.
Valid XHTML and CSS. ^Top^