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.