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:

Not a fan: .@wordfence's fear-based marketing: articles to scare up subscriptions not inform https://t.co/8cSWCKkFdq pic.twitter.com/tUMG3LEaqb

— Ansel Taft (@anseltaft) August 3, 2016

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.