WordPress Admin Attack

October 24, 2013 — 2 Comments

Back in February of 2012, I first wrote about a WordPress attack that was aimed at Mage-style websites. A few months ago, it looked like it returned in an evolved form. However, this time the attacks weren’t limited to mage sites. Random WordPress sites were being targeted at nearly every hosting company I heard of. Worst yet was that the attackers’ user agent wasn’t ‘Bing bot’ anymore. This time they masqueraded as regular user browsers such as Mozilla. No, this attack was different, further reaching across the Internet, and far more effective. I’d like to share with you what I saw and the solutions I’ve found.

Background of the Attack

This WordPress attack is directed at the WordPress login page. Numerous bots will slam the wp-admin URL with ‘POST’ requests. Whether they are actually trying to brute force their way in by actually submitting real data is hard to say. However, that wouldn’t actually matter for my purposes. I would see entire servers brought to their knees, unable to serve up any other web pages, due to the extreme CPU load caused by these WP admin area login requests.

It didn’t even require a large amount of bots. With only a few extra ‘visitors’, ’these requests would cripple the CPU. This is because WordPress admin pages still have to query the database, usually can’t be cached, and it consumes a considerable amount of CPU. A few extra requests targeted just at that login page are quite effective.

Even if you have brute force detection firewalls such as CSF or APF, they don’t track ‘POST’ requests and are no help here. Preventing the attack also wasn’t as quick as reusing the Bing-bot protection from before. They had changed their user agent to regular home browsers. Instead of pretending to be search engines, they used regular ones like this. Here are a couple samples from my own Apache domlogs:

At my company, it took about three days to fully identify this trend as a mass attack and few days more to implement a solid, deployable solution.

Identifying the Attack

This WordPress attack can be identified very easily. You’ll notice an extremely high CPU load on the server, the output of a ‘top’ command shows that that dozens or hundreds of Apache processes are to blame. Another thing to look for is a lack of reported traffic rise to coincide with the numerous additional Apache processes. The traffic hasn’t spiked up suddenly like you would expect from a normal DOS attack.

The basics to look for:

  1. High CPU load from Apache
  2. No extreme traffic spike

At this point, due to how common these attacks were, I would jump straight to checking for the WordPress attack. Meeting the above two criteria was suspect enough for me.

Parse the logs for quick identification

You can easily confirm this kind of attack by parsing the domlogs. I recommend that you shut down the Apache service first. If suspect this attack to be happening, then the following command could take a long time to run unless you’ve stopped Apache.

That will parse the domlogs for all domains, looking for ‘wp-login.php’, while ignoring the ftp logs. It then grabs just the first column (the IP address of the visitor), and finds out how many hits there are.

Here is an example output from one such attack:

No legitimate user should be trying to hit the login page that many times.

Protecting the WordPress admin page

As I mentioned before, you can’t simply block the IP addresses in the firewall. The attack is normally from hundreds of different IP address. Blocking a few will stop the problem for a short while, but in a few hours you’ll have issues again.

The best method is to protect that admin page directly. There is a simple solution: an ‘htpasswd’ password prompt. Here’s how:

Generate the htpasswd file, placing it in a centralized location:

When it prompts you for the password, literally type the word ‘password’. Now configure Apache to load the password prompt to anyone hitting a wp-login.php page, anywhere on the server. Edit your Apache include file:

And add the following section:

Save it and restart Apache. That’s it! The CPU drain of the attack has now been undermined.

Explanation of the Implementation

Anyone that tries to access the login page is prompted with a login popup. It tells them the user name and password on the screen. The credentials literally are:

  • User Name: human
  • Password: password

Legitimate human visitors will be able to read that; a bot will not. This kind of implementation has successfully stopped the CPU usage of the attack on all the affected servers I’ve encountered. There are a few benefits to this:

  1. It’s safe. This will not affect the main site itself. Regular site visitors will never notice any changes. It only affect the admin login. Bots should never need access to the admin page (not even Googlebot); humans only.
  2. It’s less intrusive. The credentials are given on screen. The user enters them once, and can choose to have their browser save it for the future. They’ll never see it again.
  3. Failed logins can be blocked by CSF. The is the biggest one of them all. Obviously, blocking connections at the firewall is much better. This will allow you to do that once again. While CSF may not protect against failed ‘POST’ logins, it will protect against failed htpasswd logins. Bots that can’t authenticate will get auto-blocked now.

Other Implementations

I’ve seen some implementations that had Apache also protect the ‘wp-admin’ folder by using the “LocationMatch” directive. This is a mistake; don’t do it! There are many WordPress plugins out there, albeit poorly coded ones, that directly call things from the wp-admin folder. If you protect the entire ‘wp-admin’ folder, your regular site visitors will see a password prompt when visiting the main site.

Notes

If you had CloudFlare, you would never even experience this problem. See their blog post here. I’m a big fan of CloudFlare and will regularly recommend it to people. This is only one more reason why they are awesome!

Jacob "Boom Shadow" Tirey

Posts Twitter

A linux web hosting administrator, a professional production sound man, and a renegade cop without nothing left to lose.... Ok, that last part is made up. In all seriousness, my passion in life is to help people; whether that be with help running their sites or with their productions. The name 'Boom Shadow' was given to me by a great group of filmmakers called Star Wipe Films. back in 2005 and has been with me since. I hope my site is helpful to you, and if there's something you need, drop me a line!
  • Andrei G

    Hi,

    How can we set that this httpd.conf rule will not apply to a certain domain? My situatios is: I have a site where users use wordpress to log into their account, a lot of users don’t know what is this popup and are contacting me regarding this.

    Thanks.

  • Barry

    Hello Jacob,

    I think my server + wp sites are having the problem you describe in this or your bingbot article. I have a question is there a way to check which wp site is getting the most admin attacks?

    In my case i see for today

    1 103.12.211.176
    1 146.0.73.133
    1 180.76.6.44
    1 180.76.6.58
    1 198.1.74.27
    1 31.193.133.4
    1 5.39.219.25
    2 123.138.68.172
    3 146.0.74.204
    3 146.0.74.208
    4 146.0.73.15
    7 195.162.69.58
    189 195.3.144.84
    328 175.44.52.247

    But yesterday i only copied the last one and i read:
    15231 54.200.33.155

    That’s 15000+ attacks, right? I like to know which of wordpress is getting the most attack.

    Thanks in advance,
    Barry