Brute Force Attack

When a WordPress Security Plugin Gets Praised for Creating a Problem

When it comes to the poor state of security information surrounding WordPress one of problems we see is security companies making up threats and then claiming that their product or services can fix them. One example of that we have discussed in the past is the widely peddled falsehood that there are a lot of brute force attacks against WordPress admin password. What is actually happening looks to be mainly dictionary attacks, which involves a hacker trying to log in using common passwords. The simple solution to prevent these from being successful is to use a strong password, something that WordPress is already good at helping you accomplish.

One of the problems with not addressing the real issue here, is that a solution not designed for the actual threat can actually cause more problems. For example, if you limit the number of failed logins attempts that can be made to try prevent a brute force attack (since that would involve trying every possible password), not only can it cause problems getting back in to the website if you have trouble remembering your password, but it can make it easy for someone to lock you out of your own website depending on how the lockout is handled (a form of a denial of service (DOS) attack).

That brings us to another problem when it comes to WordPress security information, which is that public often is providing reviews and recommendations that lead others in the wrong direction security wise. Take a review for the security plugin BulletProof Security we came across while working on another post. The review is title “Saved My Site”, but what it actually describes is the plugin creating a problem:

Got slammed by hackers who discovered my username. I was locked out of my admin area due to multiple attempts at login which I did not do.
I deleted the plugin, then I created a couple of new strangely spelled admin usernames names and long passwords, reinstalled the plugin and I am good to go.

The WordPress username is not intended to be secret, so someone discovering it shouldn’t be an issue. The issue here is that a plugin is locking the person out due to actions they didn’t take, which had obvious negative consequence. At the same time it wouldn’t necessarily protect against a dictionary attack if the hacker simple slowed their login attempts to below where it would be stopped by such a plugin.

Considering that the plugin is named BulletProof Security and it has overwhelmingly received 5 star reviews (and an average 4.7 stars), you might be surprised to hear the plugin is far from bulletproof. In testing over at our Plugin Vulnerabilities service it has failed to provide any protection against exploitation of four real vulnerabilities that existed in other plugins. Unfortunately highly positive reviews for a plugin that fails to provide the protection it promises is not limited to this plugin, but is a widespread issue.

Here Are What Malicious WordPress Login Attempts Actually Look Like

Recently we discussed how the WordPress security company Wordfence continues to spread the falsehood that there are a lot brute force attacks on WordPress admin passwords (and then promotes that their plugin is the solution to the problem). An actual brute force attack would involve billions or more attempts and Wordfence’s data showed only millions attempts a day over 100,000s of websites, so 10s of attempts per website. What they actual look to be seeing are dictionary attacks, which involve an attacker trying to log in with common passwords.

The distinction is important because to protect against those all you need to do is use a strong password and you don’t need to install any plugins or continually monitor for failed login attempts (as lot of people are doing due to being mislead about what is going on). We also have have found that people will sometimes get very concerned that they have been hacked when warned by plugins that brute force attacks are going on, but when we explain to them what is actually going on that concern is cleared up because they are already using a strong password.

We thought it would be helpful to show what a couple of these dictionary attacks look like and to see how WordPress’ password strength indicator would rate the passwords tried.

The main portion of our website is powered by Drupal (this blog is powered by WordPress), despite that, we regularly have attempts to login to the main portion of our website as if it was running WordPress through attempts sent to https://www.whitefirdesign.com/wp-login.php. The fact that is happening is reminder that much of the malicious attempts against websites are incredibly crude and that the success rate of hacking attempts is incredibly small. We have been logging login attempts though that for some time and here a couple of recent sets that shows what kind of login attempts are actually going on.

For password strength, we tested it through this blog, running WordPress 4.7, so the relevant domain name was being used to calculate the rating.

The first involves 21 attempts from a Tunisian IP address, where username “admin” was used alongside the following passwords (the password strength is listed in parenthesis):

admin (Very weak)
demo (Very weak)
admin123 (Very weak)
123456 (Very weak)
123456789 (Very weak)
123 (Very weak)
1234 (Very weak)
12345 (Very weak)
1234567 (Very weak)
12345678 (Very weak)
123456789 (Very weak)
admin1234 (Very weak)
admin123456 (Very weak)
pass123 (Very weak)
root (Very weak)
321321 (Very weak)
123123 (Very weak)
112233 (Very weak)
102030 (Very weak)
password (Very weak)
pass (Very weak)

The second involved 52 attempts from IP address in China. Along side the username “admin” the following passwords were tried:

admin (Very weak)
admin000 (Very weak)
admin123 (Very weak)
admin000 (Very weak)
admin888 (Very weak)
admin@ (Very weak)
123admin (Very weak)
www_whitefirdesign_com (Weak)
www.whitefirdesign.com (Weak)
whitefirdesign.com (Very weak)
whitefirdesign (Very weak)
www-whitefirdesign-com (Weak)
wwwwhitefirdesigncom (Weak)
adminadmin (Very weak)
123456 (Very weak)
adminpassword (Very weak)
12345 (Very weak)
12345678 (Very weak)
qwerty (Very weak)
1234567890 (Very weak)
1234 (Very weak)
baseball (Very weak)
dragon (Very weak)
football (Very weak)
1234567 (Very weak)
monkey (Very weak)
letmein (Very weak)
abc123 (Very weak)
111111 (Very weak)
mustang (Very weak)
access (Very weak)
shadow (Very weak)
master (Very weak)
michael (Very weak)
superman (Very weak)
696969 (Very weak)
123123 (Very weak)
batman (Very weak)
trustno1 (Very weak)

After those they tried logging in with the username “whitefirdesign” and the following passwords:

whitefirdesign (Very weak)
whitefirdesign000 (Very weak)
whitefirdesign123 (Very weak)
whitefirdesign000 (Very weak)
whitefirdesign888 (Very weak)
whitefirdesign@ (Very weak)
123whitefirdesign (Very weak)
www_whitefirdesign_com (Weak)
www.whitefirdesign.com (Weak)
whitefirdesign.com (Very weak)
whitefirdesign (Very weak)
www-whitefirdesign-com (Weak)
wwwwhitefirdesigncom (Weak)

Of the 73 passwords tried (including those used multiple times), 65 of the them were rated as “Very Weak” by WordPress’ password strength indicator and the other 8 were rated as “Weak” (all of the “Weak” ones used some variation of the domain name in them). So WordPress password strength indicator looks to be doing a good job of helping people to pick strong passwords that would not be guessed in a dictionary attack.

Using a Common Password Doesn’t Welcome a Brute Force Attack

When it comes to WordPress security, a frequently falsehood we see out there is that there are a lot attempts to brute force WordPress admin passwords. As we discussed before looking at the supposed evidence of this provide by security companies actually shows they are not happening.

In pointing out instances where the security industry is peddling this falsehood to get the public to use their products or provide them something of value we have repeatedly receive complaints that we are the ones in the wrong about this. For example, on a post how the developer of the plugin Anti-Malware Security and Brute-Force Firewall was using the claim to get people to register and provide them donations we received a comment that reads in part:

Your insistence that “brute force” means a full scale attack of tens of thousands of attempts is completely lost in the wind. You are probably the only person in the universe adhering to that definition.

and

Trying to get an entire industry to adhere to your definition of “brute force” is like urinating into the wind. At one end of the scale, you get wet and look silly. At the other end of the scale, you sound tyrannical.

It is rather strange comment as we are using the standard definition, which we had no hand in creating, so we really don’t know where the idea that we are the only ones using it could come from.

It isn’t hard to see that we are not along in that, if you go to the entry for brute force attack on the WikiPedia you will find that it states:

The attacker systematically checks all possible passwords and passphrases until the correct one is found.

And it also makes clear that dictionary attacks, which are actually happening against WordPress websites (and are best prevented differently then brute force attacks), are different:

When password guessing, this method is very fast when used to check all short passwords, but for longer passwords other methods such as the dictionary attack are used because a brute-force search takes too long.

If someone doesn’t want to believe that either, how about one of the security companies that we previously mentioned as misleading people, iThemes security:

The brute force attack process is often referred to as exhaustive search. An attacker will systematically check unlimited passwords until the correct one is found.

The post where that is mentioned though is good example of the mess that people run into when looking for security information these days. The post is titled “Brute Force Attacks: What They Are & How to Prevent Them”, but much of much of incorrectly conflates real password related threats with brute force attacks, which are not actually happening. Like so much of the bad information we see on security, it looks to just be a means to promote their security product, where providing accurate information isn’t important.

Under the heading of “Ways to Prevent Brute Force Attacks” one of their tips is:

Make a habit of using a different password for every site you use.

While using different passwords at every site will prevent a breach of password information on one website (particularly one not storing passwords in a secure manner) from allowing an attacker access to your account at other websites it has nothing to do with preventing a brute force attack.

Stranger is this portion:

Top 7 Passwords of 2016

123456

password

12345678

qwerty

12345

123456789

football

If you have one of these passwords, you are welcoming brute force attacks. You should change your password ASAP.

An attacker isn’t going to know ahead time what your password is when doing a brute force attack (otherwise they wouldn’t be doing it), so using a weak password isn’t going to welcome them to do a brute force attack. More importantly using a common password opens you up to a dictionary attack, which involves tries common passwords, being successful. A brute force attack would eventually be successful no matter the whether you used a common password, since as they said earlier in the post, “systematically check unlimited passwords until the correct one is found”.

Wordfence Continues To Peddle False Claim of Brute Force Attacks To Push Plugin That Doesn’t Protect Against Real Threat

When it comes to improving security of websites one of the problems we see is that real issues do not receive the attention they should, while other issues, that are of little to no concern, do get attention. Often times it is security companies that play an important role in this happening, when they should be helping to push against this.

When it comes the security of WordPress websites one of the big problems that exists is that vulnerabilities in plugins that are being exploited do not always get fixed in a timely manner or in some cases ever. A recent example of that comes with an arbitrary file upload vulnerability that exist in the most recent version in the plugin Delete All Comments. Through that vulnerability a hacker could upload files of their choosing and then do almost anything they want with the website. The security company NinTechNet spotted the vulnerability while cleaning up a website was hacked through it on November 20. They notified the developer, but received no response from them (one possible explanation for the vulnerability being in the plugin is that it was actually intentional put in the plugin, though it could just as easily be unintentional).

NinTechNet then notified the Plugin Directory and the plugin was removed from that. That prevents anyone not using the plugin already from installing and making themselves vulnerable, but what happens for the 30,000+ websites that already were using it according to wordpress.org? Nothing. The people running those websites are left unaware that their website is open to be exploited. Amazingly this isn’t because no one had brought up this issue. We raised it back in March of 2012. Shortly after that we proposed on the Ideas section of the WordPress website that people be alerted people when their websites are using plugins that have been removed from the Plugin Directory and providing at least general reason why it was removed. Shortly afterwords it was marked as “Good idea! We’re working on it” and it was stated that it was being worked on. By six months ago the same person said:

We cannot provide this service at this time.

IF an exploit exists and we publicize that fact without a patch, we put you MORE at risk.

Strangely the idea is still marked as “Good idea! We’re working on it”, which keeps it from being listed on prominently on front page of Ideas section (where it would be tied for the second most popular idea that hasn’t been greenlit and where more people would see that the issue is being left unaddressed).

There is another option, the Plugin Directory can put out a fixed version when the developers doesn’t do that, but they rarely do that, don’t seem to have provided any sort of public criteria on when they would do that, and someone on the WordPress side even deleted a comment we made in regards to the issue at one point.

In the meantime if you install the companion plugin for our Plugin Vulnerabilities service you get warned in situation like this as we include information on vulnerabilities that looked to be being exploited to the free data included with that (last week we also added data on vulnerabilities that look to being exploited in the current version of a plugin with 40,000+ installs and another with 20,000+ active installs).

If these got more public attention we have hard time believing that WordPress would continue to leave people vulnerable, but that is the situation we and everyone else is dealing with until such time.

If you are thinking that a security plugin would protect against this type of thing, think again. We tested the ability of 15 security plugins to prevent exploitation of the vulnerability in Delete All Comments last week and found that none of them stopped it.

One of those plugins that didn’t stop it was Wordfence, a plugin with 1+ million active installs, which is describe on the its main page on the Plugin Directory thusly:

Secure your website with Wordfence. Powered by the constantly updated Threat Defense Feed, our Web Application Firewall stops you from getting hacked.

That unqualified claim is that it stops from you getting hacked is clearly false as not only that test against the vulnerability in Delete All Comments shows. In three other tests we have done, in either Wordfence provided no protection or the protection was easily bypassed. It is also worth noting that from everything we have seen Wordfence’s Threat Defense Feed misses many plugin vulnerabilities.

So how do you get over 1 million installations of plugin that doesn’t actually do what it claims to do. Well what appears to be an important role in that is that Wordfence simply makes up threats and then claims to protect against them.

Brute Force Attacks Are Not Happening

Take for instance last Friday when they put out a post “Huge Increase in Brute Force Attacks in December and What to Do“, which claimed:

At Wordfence we constantly monitor the WordPress attack landscape in real-time. Three weeks ago, on November 24th, we started seeing a rise in brute force attacks. As a reminder, a brute force attack is one that tries to guess your username and password to sign into your WordPress website.

Of course they have the solution for this:

If you install the free version of Wordfence, you are automatically protected against brute force attacks. It’s that simple. We also automatically block the worst offenders completely, and we share some information below on who those are.

There is just one problem with all of that, brute force attacks against WordPress admin logins are not actually happening. Back when we originally discussed the fact that security companies are falsely telling people brute force attacks are happening in August we used as an example from Wordfence in January, so Wordfence has been using this falsehood to push their product for some time.

We wrote in that post:

To understand how you can tell that these brute force attacks are not happening, it helps to start by looking at what a brute force attack involves. A brute force attack does not refer to just any malicious login attempt, it involves trying to login by trying all possible passwords until the correct one is found, hence the “brute force” portion of the name. To give you an idea how many login attempts that would take, let’s use the example of a password made up of numbers and letters (upper case and lower case), but no special characters. Below are the number of possible passwords with passwords of various lengths:

6 characters long: Over 56 billion possible combinations (or exactly 56,800,235,584)

8 characters long: Over 218 trillion possible combinations (218,340,105,584,896)

10 characters long: Over 839 quadrillion possible combinations (839,299,365,868,340,224)

12 characters long: Over 3 sextillion possible combinations (3,226,266,762,397,899,821,056)

The chart of login attempts in Wordfence post from last week show only millions of login attempts per day:

It would take a long time for that to get to the amount needed for a brute force attack, but wait, those are not against one website, those are across hundreds of thousands of websites:

So we are talking about an average of 10s of attempts per website, which is never going to amount to a brute force attack.

So what is actually going on? Well based on the number of attempts and by looking at what username/password combinations were used in actual malicious login attempts it looks like most of these are actually dictionary attacks. A dictionary attack involves trying to log in using common passwords.

Knowing what type of attack is important because how you prevent them and the level concern you should have is very different for different types. With what is actually happening, dictionary attacks, all you need to protect yourself is to use a strong password, otherwise you can simply ignore this.

That might explain why Wordfence is misleading people, if they told people the truth they wouldn’t be a need for them to install their plugin (and then possibly sign up for Wordfence’s paid service). The other possibility, which seems just as likely based on what else we have seen, is Wordfence simply doesn’t have a good understanding of security. That could also explain why they don’t understand why it is inappropriate to make an unqualified claim that their plugin “stops you from getting hacked” when that would that would be able to truly stop any hack is next to impossible.

If you look at the comments on Wordfence’s recent post you can see they have successfully mislead a lot of people into believing their false claim, which makes it even harder to get people to focus on real issues and that means more websites are going to get hacked that should not have.

Anti-Malware Security and Brute-Force Firewall Plugin Uses Non-Existent Brute Force Attacks To Get Registrations and Donations

When it comes to WordPress security, one thing we can’t emphasis enough is that people putting out security products and services for it don’t seem to have a good grasp of security. One of the most glaring examples of this is how often the falsehood that there are lots of brute force attacks against WordPress admin passwords happening, despite the evidence presented that they are happening actually showing the exact opposite.

Recently, while doing testing on how WordPress security plugins did in protecting against real world plugin vulnerabilities (short version, they haven’t done well in the testing so far) for our Plugin Vulnerabilities service we ran across the plugin Anti-Malware Security and Brute-Force Firewall. The plugin is one of the most popular security plugins, with 100,000+ active installs according to wordpress.org.

On the Firewalls Options page you will find that they have an option for Brute-force Protection:

anti-malware-security-and-brute-force-firewall-brute-force-protection

So they are using a non-existent threat to try to get people to register and donate. On top of that, the protection seems to involving modify a core file, which isn’t a very good idea.

Sucuri Doesn’t Have A Clue What Brute Forcing Actually Refers To

One of the problems we see when it comes to people making better choices on web security is that it easy for security companies that don’t have a clue what they are talking about to present themselves as having expertise they don’t have. For example, they can throw around technical terms that they clearly don’t understand, but that the public understandably doesn’t understand either, and it makes them sound like they actually know about security, when they don’t.

One example we keep seeing involves the term brute force attack, which refers to trying all possible password combination in attempt to login in to an account. It isn’t some obscure or exotic term, it has a Wikipedia page, but that doesn’t stop people from using it when actually referring to other types of password attacks.

Often times dictionary attacks, which involve trying to log in with a set of common passwords (things like “password”), are incorrectly identified as having been brute force attacks. The distinction isn’t just semantics, how you protect against those types of attacks is very different, so anybody dealing with web security that involves either of those, absolutely should know the difference. And again the term has a Wikipedia page, so it wouldn’t be hard to know what it is.

That brings us to the security company, Sucuri, which we have seen being quite a bad security company in many ways over the years. That clearly hasn’t changed. In a recent post describe how they did an experiment that was supposed to test how long it would take for successful brute force attacks of SSH logins:

A few weeks ago we ran an experiment to see how long it would take for some IPv4-only and IPv6-only servers to be compromised via SSH brute force attacks.

As they explain in the second paragraph of the post, their experiment involved them setting the password to “password”:

We configured five cloud servers on Linode and Digital Ocean with the root password set to “password.” The idea was to see how long it would take before the servers were hacked.

To anyone who actually know what brute force attacks and dictionary attacks are, its obvious that they don’t actually know what they are talking about since that would be a password to test for dictionary attacks, not brute force attacks, but the public is unlikely to, especially as security companies keep referring to dictionary attacks as having been brute force attacks.

If you are interested in actual security, Sucuri’s lack of basic security knowledge, would be a good reason to look elsewhere.