WordPress xmlrpc.php - Brute Force Attacks

What was supposed to be a quiet Saturday morning quickly turned into a couple of hours trying to mitigate an increasing strain on a  WordPress based site. After getting around 800 post requests per minute to the WordPress xmlrpc.php file, resources for the site in question was getting sparse.

Examining the Apache access log didn’t reveal much as Apache doesn’t log post requests per default as shown below.

www.domain.tld 79.169.116.109 - - [16/Aug/2014:10:54:17 +0200] "POST /xmlrpc.php HTTP/1.1" 200 405 "-" "-"

Obviously having Apache logging all input data will get ugly fast, so I figured the best approach would be to edit the xmlrpc.php script to log all post data to a file for closer inspection.

Examining the payload below showed it contained a xml encoded call to the wp_getUsersBlogs( $args ) function.

<?xml version="1.0" encoding="iso-8859-1"?>
<methodCall>
  <methodName>wp.getUsersBlogs</methodName>
  <params>
   <param><value>admin</value></param>
   <param><value>hihje863</value></param>
  </params>
</methodCall>

wp_getUsersBlogs takes two parameters, a username and a password and tries to authenticate the user. If the login attempt is successful the function will return an array containing the values ‘isAdmin’- ‘url’- ‘blogid’- ‘blogName’ – ‘xmlrpc’. In short, this will tell the attacker that the account was successfully compromised.

I thought a good solution to mitigate the attack would be to deny access to the xmlrpc.php file with a .htaccess directive as shown below, but alas the attacker did not care much about my response codes.

<Files xmlrpc.php>
        Order Deny,Allow
        Deny from all
</Files>

To put an end to the suffering, I decided to log every request to this particular xmlrpc.php file for a period of 20 minutes. After removing dupes and friendly bots from the list, I was left with a collection just short of 1500 IP addresses. Feeding those IP’s to the firewall quickly convinced the attacker to move on to the next target and subsequently let me get back to the bloodthirsty world of Joe Abercrombie.

I’ve later done a bit of googling on the subject, and I’m now aware that these brute force attacks on xmlrpc.php are well known. Anyhow, if you have no need for the XMLRPC server implementation then you might want to consider disabling XML-RPC altogether.

If you’re managing your own server though, then Fail2ban would be an excellent tool for killing off these kinds of brute force attacks.