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.

12 Sep

WordPress Security Plugins Provide Little to No Protection Against Recently Discovered Persistent XSS Vulnerability

In the past few months we have done several one off tests of WordPress security plugins to see if they could prevent exploitation of a vulnerability in a plugin. We tested an extraordinary claim by Wordfence that their plugin could prevent persistent cross-site scripting (XSS) and found that it failed both with a vulnerability that required authentication and one that didn’t. We also tested the iThemes Security security plugin against an arbitrary file upload vulnerability that we have found was being exploited in another plugin by one that plugin’s developers and it also failed to prevent exploitation.

That these plugins failed to prevent these vulnerabilities from being exploited wasn’t all that surprising considering the poor state of the security community overall and in particular the one surrounding WordPress. Whether it is security companies making up threats, not understanding the difference between vulnerabilities, or spreading false information about WordPress installations being vulnerable due to not understanding how WordPress handles security updates, it is clear that there isn’t a good understanding of security by the people and companies in the security community.

To get a better understanding of how security plugins impact the threat of plugin vulnerabilities we thought it would be useful to start testing a wider set of them against real world vulnerabilities to see how much protection they provide.

For the inaugural edition, we tested out a persistent cross-site scripting (XSS) vulnerability that existed in the plugin WP-Piwik prior to 1.0.11. The vulnerability highlights a number of the problems we see surrounding vulnerabilities in WordPress plugins these days. In reviewing one of the outside data sources we use to help detect vulnerabilities being targeted by hackers we found an indication that there was hacker interest in the plugin back in January. In looking over the plugin we found that anyone could change the plugin’s settings (you didn’t need to be logged in to do that) and that could be exploited to run malicious JavaScript code on to the frontend pages of the website. A similar vulnerability in another plugin was exploited on a large scale to serve malware on websites in February of last year, so unlike a lot of vulnerabilities that are not of much concern, this one was.

Once we had found the vulnerability we quickly notified the developer of the details of the issue, suggested they may want to request to have the plugin automatically updated after being fixed, and let them know that if they needed any help in dealing with it, to get back to us. Two weeks went by without any response or the vulnerability being fixed. At that point we disclosed the vulnerability, added it to the data that comes with our service’s companion plugin (so that even those that don’t use the service would get alerted), and notified the Plugin Directory of the issue.

A short time later the plugin was removed from the Plugin Directory, which protected those not already using the plugin from being exposed to the issue. Those already using the plugin were left in the dark since WordPress continues to refuse to alert them in such a situation.

Two days later the plugin returned the Plugin Directory with a new version, 1.0.10, that was supposed to fixed the vulnerability, but didn’t. Plugins returning to the Plugin Directory without actually being fixed is continuing problem. After noticing that we contacted the developer again to notify the vulnerability still existed and to provide suggestions on properly fixing the vulnerability. We got a response from them a short time later. Two days later the vulnerability was fixed with version 1.0.11.

Seeing as the vulnerability could have been being exploited for months before it was fixed a security plugin that protected against it before them would have provided some real value.

Testing Procedure

For each of the tested plugin we set up a fresh install of WordPress 4.6.1, installed the last vulnerable version of WP-Piwik, 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 on the vulnerability with one change. To simulate what a hacker might do, we set it so that the a JavaScript file from another website would be loaded on the website’s page. In a real exploitation that would then server up malicious code. We did it with this format:

<script src=”https://www.example.com/script.js”></script>

We used a real domain that we control instead of example.com for the testing.

The 11 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 two of the plugins tested, NinjaFirewall (WP Edition) and Wordfence, prevented the vulnerability from being exploited with the original code. But we were able to easily bypass the protection in those two 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).

For NinjaFirewall (WP Edition) we bypassed the protection first by removing the “</script>” tag from the malicious code, that didn’t impact the malicious code running due to a closing “</script>” existing after the location it is placed when using the WordPress template.

For Wordfence simply changing the beginning of it from “<script” to “<\script” allowed the protection to be bypassed. That had no impacted on the code ultimately served up to users unlike the bypass for NinjaFirewall (WP Edition). After noticing that we realized the same type of bypass could be used on NinjaFirewall (WP Edition), by replacing “</script>” with “</\script”>.

It is interesting to note that one of the two plugin that provide any protection is also tied for 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, instead what matters is what security features are included, in this case a firewall.

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: Prevented exploitation, but bypass around protection was easily found.

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 the others were 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 like this 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.
22 Aug

Wordfence Doesn’t Bother to Look Into Basic Details of Vulnerable Plugins While Claiming to Protect Against Their Vulnerabilities

When it comes to improving the security of WordPress plugins we think that one of things that is needed is a better quality information on the issue. If decisions are being made based on low quality information, then the issues that need to be focused are unlikely to get the focus they need. One of the problems with getting such information that is that much of the information out there comes from security companies, who in many cases know little more than the public. The average person is unlikely to know that because it is easy to sound like you know what you are talking about, without actually having much of a clue what you are talking about.

One good example of this is the WordPress security company Wordfence, that, at best, is not very knowledgable of security. From falsely claiming that brute force attacks are happening against WordPress admin passwords (while promoting that they will protect agains these non-existent attacks), confusing advisories on vulnerabilities with evidence of exploits occurring, and what will be relevant with the rest of this post, claiming that vulnerabilities in plugins have been fixed without checking if that was actually the case.

That brings us to a recent post of theirs, which we thought was worth discussing as we can use it to highlight an area where WordPress can improve its handling of security vulnerabilities, one in which Wordfence seems oblivious of. The post looks at attacks against WordPress themes and plugins by one IP address. This kind of posting doesn’t seem to be one that is of much value, since hackers can fairly easily get access to other IP addresses, so focusing on protecting based on IP restrictions has limited value.

If there was value in the actual IP address, then letting people know what it is would seem advisable. Wordfence didn’t do that, explaining  “We’re not sharing the full IP and in general we will mask the addresses of attacking IP’s in case those servers contain vulnerabilities. We don’t want to create new targets for attack.”. It doesn’t make much sense to us and based on Wordfence track record it seems to be more about making people reliant on them, then their stated purpose. Someone posted a comment questioning that stance and whether Wordfence is really looking out for the community. Instead of Wordfence defending their position they simple didn’t allow the comment to appear:

What is important is protecting against exploitation of vulnerabilities mentioned, since if the you are protected against them it doesn’t matter what IP address is trying to exploit them. Wordfence claims that “If you’re a WordPress user, the free version of Wordfence will protect you against the exploits we’re seeing from this IP.”, which gets back to the reliance on them. Considering that in our recent testing we found that their claim to protect against stored XSS attacks was not true against real world vulnerabilities, relying them to protect you seems like a risky proposition.

What makes their claim to be able to protect against these vulnerabilities seem more questionable is that they don’t seem to have look to closely at them. In the post they wrote this (emphasis ours)

If you’re a theme or plugin developer and your theme or plugin is listed above, we recommend you put some effort into ensuring that all your customers have already upgraded to your newest theme, assuming you’ve fixed your vulnerability.

To fully protect against the vulnerability you would want to check over the code to make sure, for example, that if there are multiple ways to exploit that you protect against each. If they had checked over them they would have seen a pretty serious problem with WordPress’ handling of vulnerable plugins, which is something that we been trying to get improved for years.

Relevant to that is a comment on the post by someone from Wordfence that states:

These are the plugin ‘slugs’ that uniquely identify the plugin in the repository. So you’d have to use wordpress.org/plugins/[insert slug here]/ if the plugin is in the repository. Otherwise, it’s a proprietary plugin.

It is true that proprietary plugins would not be in the Plugin Directory, but a plugin that is in the repository will not necessarily be in the Plugin Directory, since they can be removed from it for a number of reasons. Take for example one the plugins Wordfence states in the post is being targeted, Plugin: Newsletter, which they listed by it slug “plugin-newsletter”. If you got to https://wordpress.org/plugins/plugin-newsletter/ you will see the plugin doesn’t exist. But you can find it in the underlying Subversion repository for the Plugin Directory at http://plugins.svn.wordpress.org/plugin-newsletter/ and you can see the log of changes made to it in the repository at https://plugins.trac.wordpress.org/log/plugin-newsletter.

So what happened to it? We don’t know why it was removed happened since WordPress doesn’t provide any public indication as to why they have removed a particular plugin, but it could have been due to the arbitrary file viewing vulnerability that exist in the current version of the plugin. Seeing as once the Plugin Directory is notified of a security vulnerability in a plugin they will remove it pending a fix, unless the vulnerability is very minor.

If you look over the details of that vulnerability, you will see that it was disclosed in May of 2012. It not much of leap to believe that the developer of the plugin is never going to release an update to fix the vulnerability considering it has now been over four years since it was disclosed. So updating the plugin won’t fix this, since there isn’t any update, so users of this plugin, or other plugins that don’t get fixed, are left vulnerable. That seems to us to be a pretty serious problem and yet it something that Wordfence completely ignores in their post. If you are actually interested in putting the WordPress community first instead of trying to make everyone reliant on your company, then a suggesting a solution for that that doesn’t require using your products or services should be a priority.

There are a couple of solutions to this that quickly come to mind. One that we have been pushing for over four years, is for WordPress to notify in WordPress admin area when plugins in use have been removed from the Plugin Directory and provide an at least general reason why that was done. While they said they were working on this shortly after we suggested it, as of a couple months ago they were claiming they couldn’t warn about vulnerable plugins since it would put websites at risk.

Another other option would be for the Plugin Directory to release a new version with a fix for the vulnerability when the plugin developer does not, which they sometimes do if the vulnerability “severe” enough. What constitutes a “severe” vulnerability is not clear as with recent vulnerability that already has been exploited they have not fixed the plugin and did not even want to have an honest discussion on the issue of the handling of unfixed vulnerabilities.