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.

Wordfence Spreads Falsehood on Database Prefix Security Hardening to Push Their Plugin

In the past we have written about how the WordPress focused security company Wordfence is making up threats in an effort to promote their plugin (and therefore their paid service). We have received pushback on that, some of which can be summed in that even if Wordfence isn’t telling the truth, their plugin might provide protection against what is really going on. Or as one of the comments reads less gracefully:

To the layperson, they don’t give a crap if it’s a dictionary attack or a brute force attack. An attack is an attack is an attack. If they happen to have some passwords in that dictionary and wordfence does stop it, is there not value in that?

That might be a reasonable argument if Wordfence was just telling people to use their plugin in addition to taking other steps. Ignoring the fact that their plugin has actually introduced additional vulnerabilities on websites due to the vulnerabilities that have existed in it, taking an extra step shouldn’t hurt the websites security, so it wouldn’t be that big of an issue.

The problem with that is that Wordfence intent in making these claims is pretty clearly to promote their plugin instead of actually promoting better security. A recent post of theirs shows this, as they make the claim that a common security hardening step of WordPress provides no protection and then quickly turn to promoting their plugin as an alternative. The truth though is they are wrong about this, probably because of their lack of security knowledge, which would be a good reason for them not to be handing out this type advice in the first place (or using it to promote their plugin).

No Protection

In the post on December 28 blog post, titled “WordPress Table Prefix: Changing It Does Nothing to Improve Security“, Wordfence claims (emphasis theirs):

Changing your WordPress table prefix is risky to implement and it does absolutely nothing to enhance your site security.

A little later they state this (emphasis theirs):

An idea became popular a few years ago that went something like this: If an attacker has access to your database via SQL injection, you can prevent them from accessing your data by renaming your tables to some unique prefix.

What Wordfence seems to have missed entirely is that a SQL injection isn’t the only way an attacker can get access to a database, which we will come back to in a bit.

Past their details that are supposed to back their claim up you get to real reason for the post, to promote their plugin:

Changing the WordPress Database Table Prefix is ‘Security Theater’

Changing the WordPress table prefix is what we refer to in the industry as ‘security theater’. In other words, it is busy-work that makes you feel more secure but does nothing to make you more secure. It only adds risk and complexity.

We have another cool sounding phrase that describes this: ‘Security through obscurity’. What this means is that you’re trying to secure yourself by making things harder for an attacker to find. In the security industry this is widely accepted as a pointless exercise.

Things that do actually make you more secure against attacks are a WordPress Firewall, like the one included free with Wordfence. This actually blocks SQL injection attacks before an attacker can gain access to your database.

The Wordfence firewall includes rules to block SQL injection attacks. It even includes a sophisticated SQL parsing engine that understands SQL the same way a database does. When we see incoming SQL, we intelligently parse it to determine if the intent is malicious or not. If it’s a SQL injection attack, we block it. If we detect it’s a site user or administrator doing something safe like posting a blog post, we allow it through.

(The claim made there that “Security through obscurity” “is widely accepted as a pointless exercise” in the “security industry” is not actually true, as a quick look through the results a Internet search for the term would show, but as usual it looks like Wordfence doesn’t know what they are talking about.)

Wordfence’s Firewall is a Defective Hammer

There is common saying, of which one variation is “I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.” The problem with that is not everything is a nail. Even when something is a nail, if your hammer is defective, it won’t necessarily be able to hammer the nail. Wordfence pretty clearly sees their firewall as a hammer and ignores the fact that it is often not effective.

We have done six tests of Wordfence’s plugin against real vulnerabilities in other plugins over at our Plugin Vulnerabilities service (four of them done as part of testing multiple security plugins). The results for their plugin and therefore its firewall haven’t been good. In four of them no protection was provided. In the other two the protection was easily bypassed. It turns out that Wordfence is actually aware to at least to a certain of the limitations of their firewall, but instead of being realistic about it, they spin the issue, apparently hoping (so far correctly) that they can get away with that.

Wordfence’s plugin isn’t an outlier, as in the four tests that involved multiple security plugins only one of them provide non-bypassable protection in one test and that came the tradeoff that Editor-level and below users wouldn’t be able to upload media. The obvious take away from that testing is that security plugins don’t provide much protection. Another take away we have had from that testing that is relevant here.

In a test of a vulnerability that allowed a file included with an attackers request to be uploaded to the website, we found that Wordfence prevented exploitation in our basic test. That was due to Wordfence seeing that a file being sent with the request had a PHP extension. That was easily bypassed though because one of the other items sent with the request was the name you wanted the file being uploaded to be saved as. So for example, you could upload the file as “malicious.txt” instead “malicious.php” and then specify the file be named “malicious.php” when saved to the file system. Wordfence wouldn’t stop the request without the PHP extension, but the file would still have a PHP extension after being uploaded on the website due to the name specified. Our take away from that is that vulnerabilities don’t always play nicely with assumptions made by security products.

Updating the Database

Recently for our Plugin Vulnerabilities service we were reviewing a report of a SQL injection vulnerability in the plugin ZX_CSV Upload, which allows “simple upload & update data from CSV to DB plugins”. The report noted that you had to be logged in as an Administrator to exploit. Seeing as an Administrator can normally do almost anything, they would normally have the ability to do the equivalent of SQL injection. So there wouldn’t really be a security vulnerability there unless this could be used to do something malicious using cross-site request forgery (CSRF). CSRF involves causing someone to take an action they didn’t intend. When we went to look to see if that was the case with this plugin we noticed a more obvious issues, the intended functionality of the plugin was susceptible to CSRF.

In practical terms this vulnerability could be used to update the database to add a new Administrator user controlled by an attacker, if they could get a logged in Administrator to access a page they control.

In our post on the issue we noted:

You would need to know what the prefix for the database is, so changing that would actually come in to play with a vulnerability (which it rarely does despite the big deal made about changing it in various security plugins and tutorials).

That post was put out on December 19, so if Wordfence was following sources putting out good information they could have avoided their false claim changing the database prefix “does absolutely nothing to enhance your site security”.

Making this even worse in our testing Wordfence’s plugin (and therefore firewall) doesn’t protect against exploitation of this vulnerability, while changing the prefix actually could.

It is worth noting that this plugin only had 10+ installs, so any exploitation of it is unlikely, but another vulnerability could open a similar possibility on a wider scale. Wordfence assumed incorrectly that the only time that the prefix comes in to play is with SQL injection, which this vulnerability makes clear isn’t the case.

Guessing the Prefix

If the database prefix hasn’t been changed the only limitation to exploiting it on a website using the plugin would be getting a logged in Administrator to access a page you control, which isn’t necessarily easy (at this point we don’t see any evidence of any wide scale attempt to exploit vulnerabilities that require getting that to happen, so you would only likely to be at risk in a targeted attack). But what if the prefix had been changed, you would need to make enough requests to guess the right one as well. So how many possibilities would there be?

MySQL database table names (and therefore the prefix) permit the following characters “0-9”, “a-z” , “A-Z”, “$”, “_”.  Depending on the operating system the table name will or won’t be case sensitive. For our purposes then let’s assume that the prefix is all lower case and the dollar sign isn’t used.

If you only letters are used you have the following number of combinations depending on prefix length:

  • 1 character prefix: 26 combinations
  • 2: 676
  • 3: 17,576
  • 4: 456,976
  • 5: 11,881,376
  • 6: 308,915,776
  • 7: 8,031,810,176

If you also include numbers you have the following number of combinations:

  • 1 character prefix: 36 combinations
  • 2: 1,296
  • 3: 46,656
  • 4: 1,679,616
  • 5: 60,466,176
  • 6: 2,176,782,336
  • 7: 78,364,164,096

The chances that you could cause the logged in Administrator’s web browser make enough completed requests to be successful in guessing the right prefix seems would depend on the prefix length. Maybe it could work with a short one, but once you are talking about the possibility of billions requests per table you are updating, the websites likely couldn’t handle the load if the computer and the network between them could before the user closed the web page causing the request to be sent.

So how long does a WordPress security plugin make it when changing it? The iThemes Security plugin, which has 800,000+ active installs according to wordpress.org, created one for us that was 7 characters and included numbers when we tried it features to change it, “ej952ng”.

Layered Security

Based on that, changing the database prefix has the possibility of being useful additional security step for a website at risk of targeted hacking as part of a layered approach to security (whether emphasizing that that type of action while even security companies, including Wordfence, are failing to do more basic security measures is its own issue).

So does Wordfence not believe in layered security? Actually they do, but when it involves it is a chance to push their plugin with a made up claim:

On some sites it’s a disaster if they’re compromised. The data theft can never be undone even if they recover from a hack. They want to employ every measure they can to be secure – and in our industry that’s a standard approach: We refer to it as a layered approach to security.

On others sites, it’s just a case of restoring from backups if you get hacked and moving on.

That is why we offer options like these that are configurable.

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.

Wordfence and Security Concern Trolling

When it comes to the security of WordPress websites one of the impediments to improving it is that security industry likes to make up threats and then claim they will protect against them, which makes it harder to get people to focus on things that would actually improve security of their websites.

One example of this that was fairly popular for a while was to claim that WordPress listing what version of WordPress was in use in the HTML code of the website was a security risk and that they had a solution. It didn’t really make any sense for a number of reasons.

First, if the developers of software were really doing something that intentionally puts you at risk, the solution seems like it should be to use different software not try to undo them putting you at risk.

Second, hackers usually wouldn’t bother checking if a website was running WordPress, much less what version was in use, before trying to exploit a vulnerability. So if you were using an outdated version of WordPress with a vulnerability that could be exploited (we haven’t have seen a vulnerability in WordPress be the cause of a large scale hacking for maybe a decade at this point), no matter how hard you tried to hide the version it wouldn’t impact whether the vulnerability would get exploited. The real way to prevent the exploitation would be to keep WordPress up to date.

Third, if a hacker wanted to know what version of WordPress was in use, then hiding the listing of version number wasn’t actual effective at the time as they could simply check for changes in JavaScript or CSS files to determine the version in use. That wasn’t a secret, but either the people promoting this either never bothered to a search to see it had been pointed out or they ignored it.

A Strong Password Is The Real Solution

The latest example of this type of thing involves a new feature introduced in WordPress 4.7, which was release earlier this month. The REST API added in this version provides “machine-readable external access to your WordPress site with a clear, standards-driven interface”.

Cue that being claimed to be a security issue, in particular the user portion of it, which the plugin Wordfence Security, used on 1+ million websites according to wordpress.org, started blocking access to shortly after. In a discussion on that the WordPress.org Tech Guy, who we have had a bit of interaction in dealing with WordPress on vulnerabilities in WordPress plugins, he responded to it this way:

Why do people still think this a real issue? Your Twitter username is exposed to everybody. Is that a real problem?

What really happened here is that WordFence added code to break the API. Simple as that. Usernames are not private information, in any sane system. Use good passwords. Then it doesn’t make any difference what your username is.

My username on my site is “otto”. Best of luck to ya.

That all sounds reasonable and he expanded on that in a follow-up response.

Here is part of the response from Wordfence:

Security is all we do. The WordPress.org core team and contributors have a different focus and a different world-view. Many of our team spend all day fixing hacked WordPress sites and working directly with traumatized customers who are incredibly stressed because their business has stalled and their data has been stolen.

We don’t arbitrarily implement features. Our design decisions are based on thousands of hours of human experience working with hacked sites, looking at attack data and understanding the wide variety of our customer’s needs.

While they claim they don’t “arbitrarily implement features” and “decisions are based on thousands of hours of human experience working with hacked sites”, no where in their response do they even make a claim that the feature would likely lead to websites being hacked. There is a good reason for that, it wouldn’t.

In the post announcing the feature they do give a reason for doing it, but it is even worse than none:

This can be exploited by bots that are launching brute-force password guessing attacks on WordPress websites. They can use this API to list the usernames of anyone who has published a post on a WordPress site. The list of users displayed via this API almost always includes a user with admin level access.

Despite Wordfence repeatedly pushing the idea that brute force attacks against WordPress admin passwords are happening (and that their plugin is the solution), they simply are not happening. At best Wordfence doesn’t understand what is actually going, which are dictionary attacks, not brute force attacks. Those involve a hacker trying to log in using common password and there is a really simple way to protect against them, use a strong password. It doesn’t matter if someone has your username, those attacks will fail as long as you use a strong password. If Wordfence told the truth about what is happening it would also remove a reason to use their plugin, which might also explain why they keeping pushing that falsehood.

WordPress does a good job on helping people to use a strong password. When setting up WordPress it will pre-populate a strong password for you:

Let’s say you decide to use a weak password instead. Not only will the password strength indicator tell you it is “Very weak”, but you will need to check a box to “Confirm use of weak password”:

About the only other thing they could do in terms of make sure a strong password is used is making its usage mandatory, which has some downsides.

Wordfence Lack of Concern For a Real Source of Hacked Websites

Going back to Wordfence’s explanation for creating an issue where there isn’t one, it read in part:

Security is all we do. The WordPress.org core team and contributors have a different focus and a different world-view. Many of our team spend all day fixing hacked WordPress sites and working directly with traumatized customers who are incredibly stressed because their business has stalled and their data has been stolen.

At the same time it turns out they are actually okay with people using their plugin being hacked. Before we get to that let’s look at how their plugin is described on the Plugin Directory:

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

and

Wordfence Security is 100% free and open source. We also offer a Premium API key that gives you Premium Support, Country Blocking, Scheduled Scans, Password Auditing and we even check if your website IP address is being used to Spamvertize.

So it is free and will stop you from being hacked right? Well not always.

On November 20 the security company NinTechNet, makers of the security plugin NinjaFirewall, were cleaning up a hacked website and discovered that the source of the hacking was a arbitrary file upload vulnerability in the plugin Delete All Comments, which recently had 30,000+ active installs according to wordpress.org. They contacted the developer and didn’t receive a response, they later notified the Plugin Directory and it was removed. On December 10, they disclosed the issue publicly.

On December 11 it was added to a public database of WordPress vulnerabilities, the WPScan Vulnerability Database. On December 12 it was added to the free data that comes with the companion plugin for our Plugin Vulnerabilities service.

Also on December 12 we saw the first interest in the plugin by hackers with the data we monitor for Plugin Vulnerabilities service, which probably also indicates that widespread exploitation would have begun then as well.

On December 16 we did a test to see if security plugin could prevent exploitation of these over at our Plugin Vulnerabilities service. Seeing as the vulnerability had not been fixed (and still hasn’t), so keeping your plugins up to date would not protect you, this is situation where a security plugin could provide some. Unfortunately none of the 15 plugins we tested prevented the vulnerability from being exploited.

One of the plugins tested was Wordfence, so here is a situation where websites are being hacked, the plugin didn’t stop it from happening and you have people that are going to be, to use Wordfence phrasing, “traumatized customers who are incredibly stressed because their business has stalled and their data has been stolen”.

Only on December 16 did Wordfence take any action on this:

We developed a firewall rule for that exploit and released it into production on December 16th, the moment we heard about it from our users.

And only because their users notified them. And it turns out that was only because of us:

In the case of the vulnerability above, we heard about it because you were making some noise about it. Our users alerted us.

That is quite a poor response, when you consider that simply monitoring one of two publicly available sources of information of vulnerabilities could have lead to a response days sooner, instead of relying on their users to do it for their work for them. But at least people using the plugin are safe now, right? Wrong.

Instead only websites using their paid service will get protected for a month:

The rule is now in production for Wordfence Premium. It will only be available in the free Threat Defense Feed 30 days after release, so around Jan 15th.

So everyone else will be open to being hacked for a month, with a vulnerability that Wordfence knows is already being exploited, since that was how it was discovered.

While leaving people using their plugin vulnerable to be exploited is bad for them, it could actually pay off for Wordfence since they also do hack cleanups.

Even the people with the paid service are getting poor service, as Wordfence wasn’t proactive in protecting them, instead relying on users to let them know of the issue, after the exploitation looks to have taken off. What is particularly striking about that is they market their paid service very differently. In promoting the Real-Time Threat Defense Feed that is part of that, they say:

Wordfence protects over 1 million WordPress websites, giving us unmatched access to information about how hackers compromise sites

The unmatched access could actually be outmatched by simply monitoring public sources. It isn’t just this vulnerability, through our Plugin Vulnerabilities service we repeatedly found apparent zero-day vulnerabilities, which are vulnerabilities being exploited before the developer is aware of them, in WordPress plugins and every indication is that Wordfence was not aware of them (that also makes you wonder about their claim that they have “thousands of hours of human experience working with hacked sites, looking at attack data”). In some cases it looks like hackers were exploiting those vulnerabilities for more than a year before we had started monitoring the data that helped us to identify them and take further action.

Wordfence Should Stop Misleading The Public

If Wordfence wants to leave people relying on their plugin vulnerable like they have with the vulnerability in Delete All Comments, they have a right to do that, but they should be honest with people about what is going on and not say things like that they put the community first, when the actually put profits before them.

It would also be good if they stop making up threats as well.

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

  1. 123456
  2. password
  3. 12345678
  4. qwerty
  5. 12345
  6. 123456789
  7. 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.

The New WordPress Plugin Directory Gives Prominent Placement to False Claims About Plugins

If you visit a page on the WordPress Plugin Directory currently there is a message asking you to “Test out the new Plugin Directory and let us know what you think.”. The new Plugin Directory still seems to be a work in progress, for example, until very recently if you did a search for our plugin “Plugin Vulnerabilities” by its name it wouldn’t show up on the first page of results (the rest of the results didn’t look relevant either). What looks to be a more permanent change with new version is that reviews of plugins will be featured prominently on the main page for each plugin. That could be useful, but also allows for inaccurate or outright false information to receive prominent placement.

Reviews do not always provide useful information, for example with security plugins what we see is that there are a lot of claims made about the supposed security that they provide that don’t appear to be based on actual evidence. It looks like the testing we have done over at our Plugin Vulnerabilities service is just about the only time anyone has actually tested to see if they provide any protection against real world threats. The results of that has been that most of them provide no protection against any of the vulnerabilities tested and the ones that provided any protection were almost always easily bypassable (that may be in why providers focus so much on making up threats and then claiming they protect against them).

While inaccurate positive reviews are problematic, something else we looked at recently over at blog for the Plugin Vulnerabilities has the potential be much troubling when giving such prominently placement, baseless claims that plugins contain exploits that lead to website being hacked. With both plugins we discussed not only was there no evidence provided to support the claim, but when we looked over the plugins we didn’t find code that even look to have the possibility of allowing the claimed exploit.

Unfortunately in the new Plugin Directory both plugins currently have those claims prominently on the main page for the plugin:

In both cases we left replies mentioning that we didn’t find anything that looks like it could have allowed this, so adding a mention that there are replies to the review might improve this bad situation to some extent.

WordPress Doesn’t Want You To Know That WordCamp Sponsor SiteLock Takes Advantage of People

When it comes to the web security company SiteLock taking advantage of people, their web hosting partners have long been critical component of that. More recently there has been a new partner helping them to present a public face very different than the company that people end up dealing with if they have the misfortune of signing up for their services. That would be WordPress, which has allowed SiteLock to participate and sponsor WordPress’ WordCamp conferences.

It isn’t a situation where the people involved in running the WordCamps are not aware of the what SiteLock does. We contacted them back in September asking for a comment for a post we were preparing raising our concerns about the situation. We didn’t receive a response, but we received quite a bit of traffic to a post included in the message to them, shortly after we sent the message, so they seem to have reviewed it. SiteLock’s involvement has continued since then, which indicates to us that the WordPress folks can’t justify what they are doing, but will continue doing it anyway.

Fast forward to last week when in our monitoring of what SiteLock is up to we can across a post on the website for this weeks WordCamp US praising SiteLock. Wanting to let people know the reality of SiteLock we posted the following comment on the post:

It is rather unfortunate that you are promoting SiteLock in this way, as this company is quite bad at what they do and take advantage of so many people.

For example, a couple of months ago we were brought to fix a WordPress website after their cleanup left it broken, http://www.whitefirdesign.com/blog/2016/09/14/godaddy-and-sitelock-make-a-mess-of-a-hack-cleanup-and-drop-the-ball-on-security-as-well/. While fixing it we found that there were a couple of much larger issues, they had left the hacker with access to the website and didn’t detect that one of their web hosting partners, who had gotten the website’s owner to hire SiteLock in the first place, had a serious security issue that was leading to website being hacked.

Around the same time we found that they were spreading false information about vulnerabilities in WordPress to their customer, http://www.whitefirdesign.com/blog/2016/09/06/sitelock-spreading-false-information-about-wordpress-security-to-their-customers-through-their-platform-scan-for-wordpress/.

If you do a search for “sitelock scam” you will see a more of what SiteLock is really doing.

One thing we mentioned we think is important emphasis, is that SiteLock was (and maybe still is) claiming that customer’s website running older version of WordPress have vulnerabilities that they don’t. This was due to SiteLock not having a basic understanding of how WordPress handles security, which they should considering that is very important when properly cleaning up hacked websites and protecting them against future hacks, both of which are services they offer (some explanation to this might be that for one of their main protection services they don’t actually provide the service themselves, while claiming to). It is against that backdrop that one part of the WordCamp post sticks out:

With 2017 just around the corner, SiteLock hopes to continue their strong support for WordPress and WordCamps and make 2017 the best year yet!

Maybe it is just us, but it doesn’t seem that spreading false claims of vulnerabilities in WordPress based website shows support for WordPress, strong or otherwise.

We left that comment on Tuesday afternoon, by the next morning the existing comments (not just ours) on the post were gone and the ability to comment was removed. By comparison the previous post and next one still are open for comments and include comments. Again the WordPress folks would rather sweep under the rug the reality of what SiteLock is up to while being involved with WordCamps than deal with the situation.

What makes this all the more troubling is at the same time WordPress is helping to promote a very bad security company, they are intentionally not warning people when they are using insecure plugins, which could lead websites to be hacked and then those websites might wind up being taken advantage of by a bad security company like SiteLock.

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.

WordPress Giving Legitimacy to SiteLock By Allowing Them to Sponsor and Attend WordCamps

As we have continued to hear more troubling stories from the public about the web security SiteLock’s business practices and seen the damage they can cause, we have been very troubled that other organizations would provide them with legitimacy by getting involved with them.

One set of organizations is the various web hosts that had partnered with them. We recently found that the CEO of the parent company of many of those web hosting partners is also the owner of SiteLock, so it isn’t surprising that those web hosts wouldn’t have a problem with what is going on since their CEO is in on it. It would seem the others are getting paid handsomely to help them out.

Due to SiteLock discovering a couple of vulnerabilities in WordPress plugins some time ago, we had started following their blog for Plugin Vulnerabilities service. While no more vulnerabilities were disclosed on the blog, we did start noticing that they were sponsoring and attending quite a few of the official conferences for WordPress, WordCamps (and oddly giving presentations unrelated to security, including Creating a Digital Download Business – What to Sell, How to Sell It and Shortcuts to Success. and Contact Forms are Boring – 5 Creative Ways to Use Forms in WordPress.). That seems like a really bad idea, considering that imprimatur of WordPress is then connected with this company, provided them legitimacy they shouldn’t have.

There is also the issue that money that SiteLock makes taking advantage of people funding these WordCamps, which seems to be reasonable to consider as a moral and ethical issue.

It also doesn’t seem to be great idea to have a company that has shown that they lack a basic understanding of how WordPress responds to security isues, leading them falsely claim that WordPress website contain critical vulnerabilities, involved with WordPress events.

Just in the next couples of weeks SiteLock is sponsoring WordCamps in Pittsburgh, Raleigh (with a presentation also not security related, Using Curated Content in WordPress—Why and How), and Dallas. They are also a sponsor of the WordCamp for the whole US in December.

We would like be able to give you WordPress and WordCamp’s side of the story as to why they have are involved with SiteLock, but it has been a week since we contacted them with the following email asking for comment and we haven’t received any response:

We are writing a post about the fact that the security company SiteLock is being allowed to sponsor and attend numerous WordCamps despite be well known for taking advantage of its customers.

We first became aware of their practices after we had written a number of posts about other issues we had noticed involving them and then we started getting contacted by people who had been take advantage of by them, http://www.whitefirdesign.com/blog/2016/05/03/it-looks-like-sitelock-is-scamming-people/. There are a litany of complaints that can be see if you do a search on Google for something like “SiteLock scam”, including this page with numerous complaints https://sitelock.pissedconsumer.com/. While some of the complaints seem to be unfair to them, there is a pretty clear pattern of actions that seem quite problematic, to say the least.

We would like to include in our post any comment you might have as to why they are allowed to sponsor and attend WordCamps in light of that, so that the public has a better understanding of why WordCamps would get involved with such a company and take money that has been made by taking advantage of people. We would also like to include in our post any comment you might have as to any restrictions you place on what kinds of companies can sponsor and attend WordCamps.

If they were not aware of SiteLock’s reputation before, it seems that could have at least indicated that and that they reviewing things, but the lack of response points to them being aware of what SiteLock does and being okay with being involved with them.

If would like to let them know how you feel about that you can contact the central organization for WordCamp’s here. You also might want to contact ones happening locally that SiteLock is involved in, to see if they are aware of what one their sponsors is up to.

Hosting Recommendation Too

This isn’t the only Sitelock connection with WordPress. As we discussed in a recent post, one of the owners of Sitelock is also the CEO of a major web hosting provide, Endurance International Group. Endurance has many brand names they provide web hosting under, one of those being Bluehost. Bluehost has come up repeatedly in complaints about Sitelock. Bluehost is also one of the web hosts listed on the Hosting page on wordpress.org:

wordpress-bluehost-hosting-recommendation

That page has a top level menu link of the website, so we would assume that brings in a lot of business to them.