Tag: Wordfence

In the last day there have been quite a few security journalists writing articles claiming that 1.5 million pages on WordPress websites have been defaced due to a vulnerability that existed in WordPress 4.7.0 and 4.7.1. In looking over those articles we have found that in some cases the claim isn’t actually sourced at all and what appears be the original source for the figure in the others, which came from a security company, isn’t reliable at all and that the journalists ignored a huge red flag that should have warned them that the claimed figure and the source of should not have been relied on.

First let’s look at a couple of the articles with unsourced claims. The Inquirer’s article is titled “WordPress hacking spree sees 1.5 million web pages defaced“; nowhere in the article is a citation for that claim provided. The closest the article gets is this:

According to a report on the BBC, there are millions of pages that have already been defaced thanks to the vulnerability.

In that BBC article the claim is not sourced either:

One estimate suggests more than 1.5 million pages on blogs have been defaced.

In ITworld’s article “Recent WordPress vulnerability used to deface 1.5 million pages” you get a source, but no explanation as to how the number was calculated, which seems like important information to provide:

Since then the number of defaced pages has grown to over 1.5 million and there are 20 different attack signatures, according to statistics from Feedjit, the company behind the Wordfence security plug-in for WordPress. The number of unique affected websites is estimated at around 40,000, as a site can have multiple defaced pages.

Also worth noting here is that there is an estimate of the number of websites impacted, which seems to be the more relevant number to be the headline number, assuming either was accurate. We don’t think there is much question as to why they went with the pages number, with the current state of security journalism click-baitness is more important than providing high quality reporting.

The Bleeping Computer’s article, “Attacks on WordPress Sites Intensify as Hackers Deface Over 1.5 Million Pages” cites nearly identical numbers as to the number of pages and websites:

Attacks on WordPress sites using a vulnerability in the REST API, patched in WordPress version 4.7.2, have intensified over the past two days, as attackers have now defaced over 1.5 million pages, spread across 39,000 unique domains.

It also looks like they are citing Wordfence for their number of web pages defaced as well:

The number grew to over 100,000 pages the next day, but according to a report from fellow web security firm WordFence, these numbers have skyrocketed today to over 1.5 million pages, as there are now 20 hacking groups involved in a defacement turf war.

When you look at Wordfence’s post the claim of 1.5 million pages is based on Google’s estimate of how many pages contain certain “hacked by” phrases:

On the far right we also include the number of defaced pages for each campaign, according to this morning’s Google results.

Are those reliable? The answer seems to be no. Here is how a BBC article from 2012, “Are search engine result figures accurate?“, starts out:

Enter the name Tim Harford into Google and you get 835,000 results.

Or 325,000, or 285,000… I got these widely differing results on computers within metres of each other in the same office at the same time.

So using those as headline number and not disclosing that it is the source (along with a disclaimer as to the questionable accuracy) seems quite inappropriate. It gets worse though, because in Wordfence’s post they take this misleading number and stretch in even further. In their chart they labeled the 1.5 million page estimate as being the number of “Hacked Sites”, not web pages:

That seems like the sort of thing that should have warned journalists away from that, but security journalists don’t seem to care much for accuracy.

The 39,000 unique domains or around 40,000 websites figure also looks to come from the same chart. The problem that appears to be a measure of websites where Wordfence saw an attempt to exploit this on, not the number of websites hacked:

Considering that any WordPress websites running 4.7.1 when 4.7.2 was released would have been automatically updated to 4.7.2 and protected against the exploit long before the attacks started, unless the automatic updates feature wasn’t working on the website (which we don’t see being the case with many websites) or it was disabled (which people sometimes foolishly do), the number of attacks that could have been successful was probably a small portion of the 39,000 attacked.

Unfortunately what has happened here with these inaccurate claims of the size of exploitation are all too common these days due to the poor state of security companies and security journalists.

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.

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.