WordPress Brute Force attack spring 2013

For those who are running a WordPress site today at May 2013, you should know about this on-going BruteForce attack against many WordPress sites around the world.
http://www.bbc.co.uk/news/technology-22152296

Here at University of Bergen, we are also working on to protect our multisite WordPress installation.

How is this “attack” performed?

There is a so-called “botnet”, where around 90 000 computers are involved.

These “attacks” are made in a way that a computer taken by a cracker, in the botnet, is sending a POST request to a WordPress site to wp-login.php, where a suggested username and password is sent. If the username and password is correct, the user is logged in. Then the attackers have access to your WordPress site. Most of the posted username is “admin”.

We installed something to our server called ‘fail2ban”, which is a python script that runs as a daemon, and will implement Iptables (firewall) rules on the fly, after parsing the access-log.

This worked for us, because we realized that the “botnet” bruteforce attack was using the same “user-agent” string in all wp-login.php attempts.

Now, I see the potential danger of telling the “secret” of this attack, but let me just give you some data from the last number of entries in our Apache httpd log: access_log since 19th of May:

48514 "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"
5696 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0"
2494 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0"

Here I have counted the numbers of user-agents in our httpd-log files.

As you can see, the attack is mainly based on one type of user-agent, the one which has 48514 entries. Clearly it is reasonable to block these clients that have this agent.

Our block solution is made that if a client has a suggested user-agent as shown above "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0", and that client is trying to perform more than 3 wp-login.php call in a certain time, it is blocked out for 12 hours in our case. If the client is performing a similar attempt within an hour, the bantime is expanded.

Our fail2ban jail.conf file has this section:


[apache-wp-login]
enabled = true
port = http,https
filter = apache-wp-login
action = iptables-multiport[name=APACHE-WP, port="http,https", protocol=tcp]
logpath = /var/log/httpd/access_log
maxretry = 3
findtime = 3600
bantime = 43200


So, then we decided to make a script that could test which useragents are involved in making a lot of POST to wp-login.php, and then compare them to “our” clients, the “friendly” ones.

From that we could make a simple failregex in fail2ban filter.d/apache-wp-login.conf:

[Definition]
failregex = ^<HOST> -.*] "POST /wp-login.php .* "Mozilla/5.0 [(]Windows NT 6.1; rv:19.0[)] Gecko/20100101 Firefox/19.0"$
            ^<HOST> -.*] "POST /wp-login.php .* "Mozilla/5.0 [(]Windows NT 6.1; WOW64; rv:18.0[)] Gecko/20100101 Firefox/18.0"$
ignoreregex =

This useragent string is taken from the apache log file (access_log). Our idea is that if you hav 5000 or more log in attempts from the same useragent, this useragent could be banned.

In order to see that our bann was successfull we counted the number of entries in iptable:

service iptables status | grep DROP | wc -l

We see the potential that the people responsible for this attack easily could implement a random useragent in the POST for each login attempt to wp-login.php.
So far, it looks like they still use the same useragent for all POST against wp-login.php.

Our next approach:
If user-agents change rapid and POST to wp-login.php still happens in a big scale, we will concider a two-step user validation for our WordPress installation.