WordPress XMLRPC.PHP Vulnerability Affects Shared Hosting Sites

WordPress XMLRPC.PHP Vulnerability Affects Shared Hosting Sites

What do you need to do to bring down a WordPress website on a shared hosting service? Hit its xmlrpc.php file about 25 times simultaneously, it seems.

In the past month, I have learned more about WordPress security than I ever cared to.  It began with an email titled “TOS/CPU” from my Web host, HostGator. Apparently, a small group of IP addresses primarily belonging to the OVH Web hosting company had been flooding my WordPress xmlrpc.php file, causing abnormally high CPU usage. As a result, my account was temporarily disabled pending resolution of the issue.

During this ordeal, I learned that WordPress has essentially become like the Windows of the early 2000s; so many websites run WordPress that it has become one of the preferred targets for hackers. Although the creators of WordPress release a constant flow of security updates, still more holes are being found. I also learned that a denial of service attack from just one IP address is more than enough to bring a website down — at least temporarily — when it’s on a shared hosting plan. If you think your shared hosting service has enough resources to deal with a clumsy denial of service attack from just a handful of zombie servers, you’d better think again.

XMLRPC.PHP WordPress Vulnerability

If you’ve seen a post online beginning with “The Importance of Clickbank Marketing Software,” you’ve been looking at a hacked website — and it’s one of many. To date, at least 310,000 WordPress websites have been hacked and forced to display this post.

WordPress XMLRPC Clickbank Marketing Hack

Hundreds of thousands of WordPress websites have been hacked to display Clickbank spam.

You might think that your website isn’t vulnerable to an xmlrpc.php attack if you’re running the latest version of WordPress or have XMLRPC disabled. However, neither of these is enough to protect you. I disable XMLRPC functionality on my WordPress websites by default, because I never use it. The hacked website was fully updated, had no secret email address for remote posting and used a long, complex administrator password that couldn’t be guessed via brute force login attempts. In spite of these precautions, one of my websites was hacked and forced to display this post.

The Aftermath of XMLRPC.PHP Hacking

It would be bad enough if I could have simply deleted the spam post about Clickbank and been done with this situation, but the hacker was able to do far more than that. Around the same time, I noticed on my HostGator cPanel that automatic backups were no longer being done for my account because the number of files had ballooned to well over 100,000. It turned out that somehow, through the xmlrpc.php vulnerability in WordPress, the attacker had managed to send tens of thousands of spam emails from my server. Each one resulted in a bounce-back message. Even after I cleaned up the mess, it took HostGator several days to resume automatic backups.

Even then, the issue still wasn’t resolved. The fact that one of my websites was successfully hacked seems to have put it on a list of targets for botnet zombies, and every day my log file is inflated by thousands of lines from different IP addresses attempting to access my xmlrpc.php file and getting 403 or 404 errors. Each time this happens, the website displays a full error page, which is about 800 KB in size. At times, this has been enough of a load for an attack from just one IP address to slow the website down or cause HostGator to temporarily disable it due to high CPU usage. Think a denial of service attack needs to be distributed across many IPs to bring down your shared server? Think again — and every time I ban one IP address, a different one appears on my log.

Securing XMLRPC.PHP With Plugins

I did a bit of research and determined that the Bad Behavior WordPress plugin might help to secure my website from xmlrpc.php attacks. Sadly, it only made the problem worse; although it blocked any access attempts from blacklisted IP addresses, the attack was primarily coming from IPs that weren’t blacklisted. It also prevented many mobile phone users — including people on Android phones — from reaching my website. However, Bad Behavior didn’t prevent any attempts to access xmlrpc.php. I then tried the WordFence firewall, which was extremely configurable and feature-rich. Unfortunately, speed tests revealed that WordFence had made my website slower for all users because its PHP script took several seconds to load.

Securing XMLRPC.PHP With .Htaccess

HostGator, to their credit, has been extremely responsive throughout this ordeal. Their support department has never taken more than 12 hours to respond to my messages. Their staff has been friendly and have never tried to punt the issue back to me as “not our problem” as many shared hosting services might. However, I don’t really think of their latest solution as a true resolution for the issue. They’ve added the following to my .htaccess file:

htaccess block xmlrpc

Simple .htaccess modification to block xmlrpc.php attacks

In theory, this should prevent any further successful attempts to hack the website because the server prevents all users — myself included — from hitting the WordPress xmlrpc.php file. However, anyone who attempts to access the file still gets a full 403 error page, and the 800 KB error page — when accessed about 25 times simultaneously from just one IP address — is enough of a load that HostGator has still needed to temporarily suspend my account due to high CPU usage while they worked on another solution. HostGator also tried modifying xmlrpc.php to make it a zero-byte file, but I still received the dreaded “TOS/CPU” message a few days later.

Deleting XMLRPC.PHP

When this ordeal began, I searched for information about an xmlrpc.php vulnerability in WordPress that might allow someone to force spam content to appear on a website. I wasn’t able to find anything, which leads me to believe that Automattic is not yet aware of the vulnerability. To keep this from happening to your website, I think it would be very wise to consider deleting or renaming xmlrpc.php until more information is received. Don’t assume that will be enough to keep your website safe from a denial of service attack, though. As my experience has shown, a denial of service attack from just one IP address can be sufficient to bring a shared server down.

OVH Ignores Hacked Servers

If you have a website on OVH Hosting, you should seriously consider looking for another hosting provider. From this ordeal, I’ve learned that their network is rife with hacked servers located around the world. These servers have become zombies that can attack any website at a moment’s notice. To date, here is the full list of botnet IP addresses that I’ve been forced to ban:

  • 188.138.33.41 | DE-INTERGENIA
  • 42.118.184.225 | FPTDYNAMICIP.NET
  • 221.0.94.78 | UNICOM-SD
  • 94.102.52.51 | NL-ECATEL
  • 198.100.146.228 | OVH-ARIN-2
  • 198.27.66.217 | OVH-ARIN-4
  • 198.27.66.218 | OVH-ARIN-4
  • 198.27.66.219 | OVH-ARIN-4
  • 198.27.66.220 | OVH-ARIN-4
  • 198.27.66.221 | OVH-ARIN-4
  • 198.27.66.222 | OVH-ARIN-4
  • 198.27.66.223 | OVH-ARIN-4
  • 142.4.211.189 | OVH-ARIN-3
  • 176.31.100.222 | OVH SAS
  • 188.165.230.24 | OVH SAS

Notice a certain name appearing more frequently than the others? It turns out that a significant number of OVH servers — both shared and dedicated — have been hacked and are operating as a botnet. I’ve contacted the OVH Hosting abuse email address twice, providing them a list of IP addresses and a copy of my server logs. I’ve received no response. If you’re an OVH customer, consider yourself warned.

What Can You Do?

As I mentioned above, I believe that the best way to prevent your WordPress website from being hacked through a vulnerability in xmlrpc.php is to delete or rename the file. However, that will do nothing to prevent denial of service attacks if your website becomes a target. I’ve suggested to HostGator that a firewall rule would most likely stop any attempts to access my xmlrpc.php file before they can create a load on the server, but to date they haven’t done this. I expect to see another “TOS/CPU” message in the near future, as deleting the file or creating an .htaccess rule does little to reduce the server load these attacks cause. At present, that leaves me without a real resolution to this issue. What should I do? What would you do?



Comments are closed.