xmlrpc.php attack on WordPress 3.8

I guess the solution is either to install a plugin that disables XMLRPC or else to block access to it in .htaccess.

This functionality should NOT be turned on by default.

Since blocking xmlrpc.php in my .htaccess file I have identified two web hosting providers as being the main sources for these probing attacks. They are Ecatel Ltd. in the Netherlands and Hetzner Online AG in Germany. Discussions on forums indicate these services do not properly investigate abuse complaints and may possibly be friendly to hackers and spammers.

If you know how to update your firewalls or block IP address ranges in your .htaccess files you can get their IP info here:

Hetzner Online AG
https://bgp.he.net/AS24940#_prefixes

Ecatel Ltd.
https://bgp.he.net/AS29073#_prefixes

You may not have to block everything. Just disable access to the xmlrpc.php script with this code in .htaccess (only know how to do this for Apache — sorry):

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

Then wait a few hours or a day. Then look at your Apache error log file. Filter for xmlrpc.php. You should see the IP addresses coming out of Ecatel and Hetzner so you can identify the right blocks to deny access to.

Legitimate browser traffic does not come from Web hosting services excpet for the rare proxy script and most of those won’t be looking for ways to exploit WordPress.

Also you may want to allow your own Website’s IP address for the xmlrpc.php fule as i think Worpress occasionally checks it.

The exploit has been fixed, however it doesn’t matter WHAT file it is, if someone hammers on your site, it’s probably going down (a normal attack point is wp-login.php, but servers and firewalls have been improved to block it).

Sucks that those IPs are hitting you ?? I use a firewall on my server with IP blocks to detect that kind of behavior and stop them. Of course sometimes I’ve blocked myself…

You should use the following command on linux box from blocking the ip address.
iptables -A INPUT -s 198.154.62.21 -j DROP

above commands will only work on linux boxes.

I use iptables but I don’t block individual IP addresses. That is too inefficient. I look up their AS records and block at that level.

I’m having the same problem right now. And it’s those same Ecatel bastards in the Netherlands over and over hitting xmlrpc.php.

Don’t totally understand the fix though. Are you saying block all access to xmlrpc? Wouldn’t that cause other problems? Did adding that “Deny All” in htaccess actually solve the problem? Seems like this is common enough that WP should have addressed some how.

Why would you have to wait hours or a day to see if it worked? Shouldn’t the churn quit quickly?

Also, blocking the IPs doesn’t seem to do much because they change all the time… even inside the Netherlands.

Did adding that “Deny All” in htaccess actually solve the problem?

No – it doesn’t work. ??

WordPress fixed the vulnerability so that XMLRPC.PHP cannot be used in post 3.5.1 installations. But the compromised Websites and scripts don’t know in advance if any given Website is still vulnerable so they will continue to probe.

By denying access to the script you prevent other sites from activating it. That means you won’t get any trackbacks or pings. But they will still try to get to it.

If you look at your error log reports every day you’ll be able to cull the IP addresses that are looking for XMLRPC.PHP and you can decide whether to block them (or their AS records, which look like aaa.bbb.ccc.ddd/nn).

You can also use the RENAME WP-LOGIN plugin to stop the brute force dictionary attacks from trying to figure out your admin credentials. By culling IP addresses from your error log files you’ll be able to block more compromised Web servers.

Of course, as you block more servers some people will no longer be able to send email directly from their servers to you. But I have seen significant improvements in Website performance as my block lists have grown.

Well, I tried the .htaccess method it and it seems to have worked wonders. Site is much, much faster now. Worked almost instantly.

Is there any downside to this?

Keep an eye on your access logs. I was still getting serious traffic for xmlrpc.php – even after I added the .htaccess fix. The only thing that has stopped it has been to block by IP.

Interesting… I’ll keep my eye on it. Guess I could make some automated script to block any IP that hits more than X times. But those IPs change quickly.

So… anyone know if WP is looking into this? Seems like a serious enough problem that a patch is merited.

It’s not really a WordPress issue. I have Websites without WordPress that are being probed for these and other scripts. The problem is endemic and worldwide. Blocking ranges of IP addresses assigned to Web hosting providers will probably be the only effective way to stop this.

That, of course, kills Trackbacks except between trusted, whitelisted Websites.

Well, ~24 hours later we are still blazing fast. Its like night and day. The site has never been this fast. I’m hoping it lasts!

ESMI – do you know the command to check to see what (if anything) is hitting XMLRPC? I’m not great on the command line but I can follow orders.

I’ll check it out in a day or two but so far the .htaccess only solution is a miracle.

do you know the command to check to see what (if anything) is hitting XMLRPC?

I’m using raw access logs to monitor the situation.

I’m getting nowhere trying to block from htaccess or within Wordfence (when I can get to the site). I’ve tried:

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

…with no luck. I’m also manually adding a deny from and the offending IP addresses, but that isn’t working either. Sometimes it seemed to have stopped them, but then I see the same IP addresses attacking again.

I have one site that is being attacked on a regular basis… usually monthly but this time it I noticed it last night, thought I fixed it, and now I’ve been trying for hours to stop the attacks from probably a dozen or more IP addresses.