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 we’ll 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 its name indicates that the vulnerability has been 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 of 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).

Leave a Reply

Your email address will not be published. Required fields are marked *