When it comes to improving web security, whether it relates to WordPress or not, a big impediment we see to that happening is that it is very easy for inaccurate information to be spread. Oftentimes it is done by security companies, that either don’t know what they are talking about or who find that inaccurate information is useful for marketing their products.
A recent example of this relates to something we discussed back in September. Back then we came across a page that had a list of vulnerable plugins and it was suggested that you check over the list to see if you were using any. What the list seemed to be more of at the time was an attempt by the company behind it to promote their security plugin, Security Ninja. We say that because at the time the list was almost, if no entirely, just the free vulnerability data we include with the companion plugin for our service, which it would be much easy for people check for by installing the plugin instead of reading through a list.
One of the things that made it rather obvious that our data was the source of the list was that for each vulnerability they listed the impacted versions of the plugin, which they referred to minimum and maximum affected versions. That data appears to be something that only we generate, so unless they were also doing that themselves, we must have been the source.
Knowing what versions are impacted can very helpful when dealing with a hacked website, as many vulnerabilities only impact a limited number of versions (in a couple cases last year vulnerabilities that were widely exploited only impacted a single version of the plugin). With other data sources they will usually say that a vulnerability impacts a certain version and all versions below that, which could lead someone cleaning up a hacked website with out of date plugins to think that there was a vulnerability that didn’t exist on the website and cause them to miss the actual source (possibly leading to the website getting hacked again).
We recently came across the page again and found that there had now been vulnerabilities added to the list that didn’t come from our data. For those we expected the minimum and maximum vulnerable versions would not be listed, since they wouldn’t be available for those. But to our surprise there were versions listed. The problem, they are the wrong versions.
Take for example a file deletion vulnerability we discovered in the plugin Post Grid, which impact versions 2.0.6 through 2.0.12 of the plugin. The vulnerability is listed on the page, but a little differently, it listed as being an unauthenticated arbitrary file deletion, which likely indicates their knowledge of it came from the WPScan Vulnerability Database as that is how the vulnerability is listed in their data. On the page the minimum version is listed as 2.0.12 and the maximum version is listed as 2.0.13. That clearly isn’t right and doesn’t match WPScan’s data either, since they list the vulnerability as impacting versions “<= 2.0.12” and being “fixed in version 2.0.13”.
So what is going on? The answer seems to be that either they don’t know what they are doing at all or they don’t care; they are listing as the minimum version the last version that was listed vulnerable and as the maximum version the version that was listed as being the one that included a fix for the vulnerability. As another example of this, take a look at the listing for a unauthenticated change passwords vulnerability Ultimate Member, which look to come from WPScan’s data. They list the minimum version as being 1.3.75 and the maximum version as being 1.3.76, whereas WPScan’s data lists it as impacting versions “<= 1.3.75” and being “fixed in version 1.3.76”.
So if you were using their data you would think that versions that are not impacted are and versions that are impacted are not, which is a bad thing.
Even if they were using the data on which versions were impacted from other sources correctly there is another problem, we often find that vulnerabilities have not actually been fixed despite the belief by the plugin’s developer and the discoverer of the vulnerability (and even in some cases, the Plugin Directory). Since we actual test each vulnerability out, we can provide accurate information on which versions are vulnerable and let you know if you are using a vulnerable version.
At beginning of this post we mentioned how easy it is for inaccurate information to spread, in this case the page allows you to tweet out the message “Check if you are risking your site by using hacked & dangerous #wordpress #plugins.”. If you do a search on Twitter for the beginning of that message you can see that has happened quite a few times.