Brute Force Attacks via XML-RPC Rise Sharply

There has been a sudden increase in brute force attacks, mainly on WordPress sites. It is across all hosts and server packages. The newest attack vector seems to involve a function in XML-RPC, which is turned on by default in WordPress. Discover what’s going on and how to protect your site.

What is a Brute Force Attack?

It’s a direct assault on your site login.

Attackers us rapid fire algorithm machines to try thousands of user/password combos a minute to break into your site.

What is XML-RPC?

The RPC part stands for Remote Procedure Call. Basically, it sends a request to a server for data.

The XML part is a type of encryption.

How is XML-RPC Used?

Lots of plugins use XML-RPC as a way to send data from outside the site, such as:

• admin access to the site via mobile
• social share button counters
• delivery of images to photo galleries from 3^rd party platforms
• delivery of podcast files from 3^rd party platforms

Trackback and Pingback Spam

WordPress also has an intra notification system that allows a site owner to know when another site links to them. Both sites would need to have this notification system turned on. And it uses XML-RPC.

Unfortunately, spammers started using it too, as a way to get a link onto a site that would have otherwise blocked their comments.

Then hackers started using it too, as an break-in entry point.

And this is why we can’t have nice things. And why advise that you turn this feature off. (See how to do that a little later in the post.)

XML-RPC and DDoS Attacks

In early 2014, huge botnets started using vulnerabilities in XML-RPC to break into sites and then add those server resources to their botnet.

With the equivalent strength of thousands of computers, they would gang up on a server or server farm in order to cripple it.

There are various reasons for them doing this, primarily being to mask a hack attack.

And no, they don’t have better things to do. There are billions of dollars to be made from the emails and other personal data they gather. It sells for big money on the black market.

Read Disable XML-RPC in WordPress to Prevent DDoS Attack which details the steps you need to take to turn off XML-RPC, the caveats of doing that, and my most recommended method.

New Amplified Attack Vector

By mid 2014 a super scary attack tactic became available. One hacker could use one computer, or one server, and amplify the effect of it so that it behaved like, and had the power of, hundreds of computers.

In October 2015, Sucuri reports that this type of amplification tactic is now being used in Brute Force attacks.

Basically, instead of trying to make 500 password break attempts one after another in serial fashion, they can now make 500 attempts at once.

Blocking Brute Force Attacks

Most brute force plugins block the IP address of the hacker after a certain number of attempts and lock them out for a specified time.

I use Login Lockdown. It’s a super light-weight plugin that works great for just brute force protection. Note that I use it in combination with other hard-coded security measures. So, don’t get into a “this plugin is better than that one” argument about it. You have to look at the whole security setup to say anything really meaningful about what works best.

The typical settings are to block the IP for an hour after 3 unsuccessful attempts.

Well, if an attacker can try 500 user/password combos in one attempt, then they get 1500 attempts before being blocked.

That’s not good.

Chewing Up System Resources

Here’s the other problem, and it’s a big one.

Every time a login attempt is made, a call is made to the database to see if those login credentials are correct.

If they aren’t, then it uses more system resource to report that fault.

If thousands of attempts are made, significant server resources are chewed up.

This could get you in hot water with your host.

They are not going to let you hog system resources like CPU and memory. And they’ll limit your site until the threat passes.

A host limiting your site means that it is down, and no one can access it.

That’s bad for viewers. But in a way, it also protects your site against the attack too.

If you go over your limits often enough, the host can terminate your account.

Chewing Up Even More System Resources

If you have a security plugin that is set to notify you every time there is a failed login attempt, then you’re asking it to use even more resources to send you that message.

If you’re site is under attack, you may want to know that.

But you don’t want to get 1500 individual emails to tell you.

At the very least, set it to send a summary email.

Don’t use a security plugin that chews up more system resources than it’s worth.

Get a Decent Host

Ask your host if they have a DDoS mitigation service.

It’s not cheap. And crap hosts won’t have it.

Even most boutique hosts can’t afford it. But, they do have more control over who they allow onto their servers. And they do tend to have better country blocking and such.

If the whole server is coming under attack, automated DDoS mitigation should curtail it enough to keep the server from crashing. That keeps sites up.

The problem is, all incoming traffic is bottle necked while it goes through a bot/human test. That will slow things down a bit, sometimes a lot. But slow is better than down, right?

Get a Firewall

If your site lives in the equivalent of a gated community, there will be far less attempts by hacker thugs trying to break down the front door of the login.

That’s what an external, or Web Application Firewall service does for your site.

It’s like a gated community. It kicks hacker bots to the curb before they ever get anywhere near your login.

And they don’t chew up any system resources doing it. Zero. Nada.

My favorite free firewall service is CloudFlare.

It’s primary function is as a CDN, and it improves site speed dramatically. But, it also offers some bot protection, even in the free version.

And the paid version stops bot attacks butt cold. It has an I’m Under Attack setting that works wonders.

There are other firewall services like the one from Sucuri too.

But, for a firewall to be most effective, it’s best to get it the minute after you set up your website. The second best time is immediately after you migrate to a new host (due to the new IP address). Otherwise, bots may have already found your hosts IP address, and they’ll just run end around the firewall.

Even behind a firewall, the MX record for email going through your host will be lit up like a Christmas Tree.

Read Get Your Email Off Your Hosting for multiple reasons why I strongly recommend you use a paid email service like GApps or Rackspace or such.

Firewall plugins are not the same as a 3rd party firewall services

Not. At. All.

They are going to chew up system resources because an instance of WordPress has to be opened for them to take effect.

And, they still have to make database requests because they have to check which IPs are currently being blocked.

Update Your Plugins

Right now! And keep them updated!!

For all of 2015 we have seen boat loads of plugins with a variety of XML-RPC vulnerabilities.

Update WordPress

Even the WordPress core had a serious vulnerability this year.

Your best line of defense is to keep everything updated. The overwhelming majority of successful hacks come from a lack of updates and super weak login credentials.

Move the Login Page

I’ve read several case studies on whether moving the login page has any real effect on deterring a brute force attack.

Some say yes, some say no. And most don’t detail enough of the test conditions to gain my confidence in how the study was conducted.

Here’s what I know from my own experience.

Moving the login page will temporarily impede bots from finding it. What they can’t find, they can’t attack.

But, bots will eventually find it. So, it gets to be another cat-and-mouse game you play with the bots.

However, even a temporary reprieve could keep your site from suffering overages at the host.

2 Step Authentication and White Listing IPs

2-step auth is always a good idea on every account and every device you own, including your cell phone.

But, if you have a VA, webmaster, or others who frequently need access to your site, it’s just not going to work well for you.

Same for denying access to the login page from all IPs except those listed.

This works perfectly if you, and all others who need access regularly, are always at the same IP addresses listed.

Check Your Site For Attacks

You don’t need a plugin to tell you if your site is under attack.

If you have access to AWStats on your host (available in most all hosts with cPanel), then you can check hits anytime you like.

Look for a section about half way down labeled Pages-URL (Top 25).

Then look for your wp-login.php or wp-admin-admin-ajax.php hits. There will be a lot of them. But, if see a ratio like 20,000 hits on them, and 200 hits on other pages, then bots are out of control on your site.

At the top of the AWStats page, you can choose which month to view. It may be a good idea for you to look at previous months so you can get an average.

XML-RPC and the new REST API

There are some dazzling features coming to WordPress in the next year via inclusion of the REST API into the WordPress core.

Unfortunately, some of them will rely on XML-RPC.

I’ll be keeping my eye on this topic very closely as it develops, and I’ll keep you in the loop.

Need Help with Site Security?

I do deep security and performance site audits where we find all manner of things out of whack that you simply can’t see from within WordPress.

Listen to what my site audit clients have to say about what we found and fixed that saved their bacon in more ways than one.