15 Feb

A Doubly Bad Way to Check if Your WordPress Website Uses Plugins With Known Vulnerabilities

One of the many problems with the security industry is the use of ineffective solutions to tackle various tasks when much more effective solutions are readily available. While some of the usage of those less effective solutions may be necessary due the particulars of a situation, it seems that most usage is due to people providing security products and services despite not having a great grasp of security and the ability to make more money using those less effective solutions (at the expense of the customer getting a bad result). The way that leads to more money can come from getting sales for a product a service over others by making them sound more impressive than the more effective solution, which we will get to an example of in a bit, or by promoting the less effective solution as being a cheaper, but equally effective solution, when it really isn’t even close to being as effective.

When it comes to checking if a WordPress website is using plugins that contain known vulnerabilities the method used for our service is very effective. When we come across a report of a vulnerability (or in many cases become aware of one without a report having been released) in a plugin, we test things out to make sure that the vulnerability has existed and determine which versions of the plugin are impacted. We then add that info to our data set that can then be accessed through an API by the companion plugin for our service.

The companion plugin collects information on the plugins that are installed on the website along with the versions numbers of those plugins. That information is then sent to our website and any vulnerabilities that are in the current version or in other versions can be returned and then displayed or emailed by the companion plugin. That means that in seconds a check can be done and it can be easily repeated over and over (you can have the check done as often as every hour).

Live Testing

As example of a less effective solution that we would imagine sounds more impressive than that, take the Detectify service that we mentioned back in September, which was promoted with the following:

Detectify is a web security service that simulates automated hacker attacks on your website, detecting critical security issues before real hackers do.

While that may sound impressive, in reality it seems like really ineffective way to check for known vulnerabilities in WordPress plugins. Many WordPress plugin vulnerabilities being disclosed involve an action being taken by an Administrator, so to test for those things the service would need to have full access to the website, introducing additional security risk. Plenty of vulnerabilities have a persistent impact, so it seems like you wouldn’t want to have them tested for on a live website. For example, the other day we detailed an authenticated arbitrary file deletion vulnerability. To test that out, the service would have try to delete a file, so either the service is going to be delete a file intended to be on the website or it will need the ability to create a new file to delete.

Doing that testing on the website is going to take a lot more time then what is done with our service and it doesn’t look like that service is designed for continuous checking.

Another limitation of that service is that it has a fairly limited number of WordPress vulnerabilities it checks for, in fact it looks like we have more vulnerabilities in our data set than they check for in all types of software.

Making all that worse, if you are only interested in checking a WordPress website then that the service is going to cost you a lot more than ours. If you want to scan for things that require authentification the price is 10 and half times more than our service (and six times as much without authenticated checking).

WPScan and Burp WP

Recently we came across someone suggesting another route for checking a WordPress website for known plugin vulnerabilities, which lead to us writing this post:

I recently came across Burp WP, a WordPress scanning plugin for Burp Suite. It’s similar to WPScan, and uses the WPScan Vulnerability Database as its source of vulnerabilities. If you already use Burp for vulnerability scanning, then it’s nice to be able to include Burp WP to deep-dive into a WordPress site, without having to run WPScan separately.  I’ll be installing it on Monday to give it a test shortly after updating my sites to WordPress 4.9.3.

Neither of those tools will actually do a deep-dive into a WordPress website, since they work from the outside. That is one the two reasons they are bad for checking the plugins for known vulnerabilities.

One way those types of tools can check what plugins are in use is to look for references to them in frontend pages on the website. That approach is going to miss a lot of plugins since many don’t have anything that shows up there. The other would be to request the readme.txt files for each plugin (or some other file or maybe a directory) to see what ones are installed. So either you are likely to be missing a lot of plugins or you are going to making 100s or 1,000s of requests (depending on how many plugins there are in the data set of known vulnerabilities). In some cases one of those approaches could get you the version number of the plugin, but it won’t always, so you are not always going to be sure without further checking if the vulnerability impacts the version being used. Like the other solution, continuous checking is going to be difficult.

The second problem is the data source that is being checked against with those tools, the WPScan Vulnerability Database. That data source has one big positive, its data is accessible for free, but it also has a lot of negatives. Seeing as tools like that are promoted as being used by security professionals, you would expect that a lot times they are being used in instances where fees are being charged that would allow for using higher quality data than what is available for free.

You can look back at our past posts discussing the negatives aspects of that data, but to give you a quick idea let’s give you two recent example of the issues that we have found.

Just a couple of days ago in the context of a false claim that you won’t miss out vulnerabilities if you rely on WPScan Vulnerability Database, we noted a couple of recent examples of it missing vulnerabilities it really shouldn’t have. One of them was a vulnerability that was disclosed in early January, which had been being exploited before it was fixed. The other was a vulnerability we disclosed in late November that likely is being exploited and that has yet to be fixed. Those both seem like the kinds of vulnerabilities you would want to know about, but if you relying on that data source you wouldn’t (those are far from the only ones).

A very recent example involves a vulnerability disclosed in the plugin Bookly Lite less than a week ago. Here is the WPScan Vulnerability Database entry for that:

The problem with that is that not only was the vulnerability not fixed in version 14.5, it wasn’t even fixed as of the when that entry was added and last updated.

Before that vulnerability was even in that data set we had already tested out the vulnerability, determined the vulnerable versions, determined that it hadn’t been fixed, added it to our data set, and contacted the developer to let them know it wasn’t fixed. We have yet to hear back from them, but earlier today the vulnerability was fixed (though in a less than ideal way).

So with that data source you really need to double check to see if the vulnerabilities have been fixed since the data isn’t reliable in that regard, which with our service we have already done for you.