06 Feb

If You Used Our Service You Would Already Know About the Security Vulnerability That Has Been in Contact Form DB

Back in 2012, years before we started this service we noticed a couple of big problems with how security issues in WordPress plugins were being handled. The first one was that there were many vulnerabilities that existed in the current versions of plugins that had been publicly disclosed, but the plugin remained available in the Plugin Directory. The second was that when a vulnerability in a plugin was reported to the Plugin Directory the plugin was removed from it, protecting any websites not already using the plugin from the vulnerability, but websites already using it were not given any notice of the vulnerability, leaving them vulnerable.

In the present the first problem would likely still largely exist if wasn’t for us making sure that developers and the Plugin Directory are notified when unfixed vulnerabilities are disclosed. The second problem still exists despite it being indicated years ago that a solution would be forth coming, a more recent explanation of why that hasn’t happened doesn’t make sense.

The second problem has recently been a topic of discussion in relation to what has happened to the plugin Contact Form DB, which wordpress.org had recently reported as having 500,000+ active installs. Several weeks ago a persistent cross-site scripting (XSS) vulnerability that existed in the plugin was disclosed. Shortly after that the plugin was removed from the Plugin Directory. At this time the plugin remains out of it, due to the Plugin Directory insisting on further security improvements. While that is the case people have been wondering where it went and then discussing the fact that the current handling of this type of situation leaves people left with no information when something like this happens.

Considering that we suggested letting people have at least a general idea of what is going on years ago, we obviously think giving everyone information on what is going on is a good idea. In the meantime if you are using our service you would already know what is going on, something that would seem to be useful to someone like one of the commenters there, whose comment in part reads:

That would also enable existing users to know that there was a vulnerability and choose to disable or knowingly risk it. As it is now, my agency has hundreds of sites using this plugin and we had no idea there was an issue with it.

One of the ways we keep track of vulnerabilities in WordPress plugins is to monitor the WordPress Support Forums, something we started doing after belated becoming aware of a plugin with intentionally malicious code shortly after we started the service. Through that we became aware of the vulnerability on January 13 and added it to our data on the same day.

Another thing we do as part our service, which others providing vulnerability data on WordPress plugins don’t do, is that we test out each vulnerability, so when the developer released a new version, 2.10.29, that was supposed to fix this, we tested it out. We found that it didn’t fix it, we then updated our data so our customers would know that they were still vulnerable. We also notified the developer of the issue and where in the code the vulnerability still remained (as well as a suggestion for a better fix). A newer version has been submitted to the Plugin Directory that does resolve this, but it currently isn’t available through the normal update mechanism.

For vulnerabilities that haven’t been fixed we are always available to work with our customers to make a determination as to what to do in the meantime. Maybe it is something you can safely ignore, maybe it is something that disabling, but not removing won’t resolve, or maybe we can provide with a workaround (as we could have in this situation).

Other Providers Still Don’t List This Vulnerability

So what if you are relying on another provider of vulnerability data in plugins? You wouldn’t know about this vulnerability. If you get your vulnerability data from another plugin or service it likely uses data from the WPScan Vulnerability Database (the use of their data is not always disclosed) and the vulnerability still isn’t listed in that. That is also true for the plugin CWIS Antivirus Scanner, which uses its own data.

At this point the people behind those could have known about the vulnerability even without doing the extensive monitoring we do, to provide our customers with the best data, as we listed it in our latest monthly post on what was new with the service along with the rest of the vulnerabilities we added last month. That’s a reminder of the lower quality of the data you are going to get if you get your plugin vulnerability data from someone other than us.

08 Dec

CWIS Antivirus Scanner Can Also Leave You Unaware That You Are Still Vulnerable To Plugin Vulnerabilities

Yesterday we discussed a couple of recent instances where WordPress plugins were reported to have vulnerabilities that were fixed by discovered and those vulnerabilities were added to WPScan Vulnerability Database with the vulnerabilities listed as be fixed. But in both cases when we actually tested out the vulnerabilities as part of our adding them to our own vulnerability data, we found that the vulnerabilities had not actually been fixed. Those instances were a reminder of the need to actual check if vulnerabilities have actually been fixed (those two instances are by no means the only times that has happened) and reminder that isn’t something that happens with data included in the WPScan Vulnerability Database, which is used in a number of services and plugins. It turns out they were not the only ones that incorrectly listed one of the vulnerabilities as being fixed.

Last month we looked at a new source of vulnerability data in WordPress plugins, the plugin CWIS Antivirus Scanner, and found that they were including false reports of vulnerabilities in plugins in their data. Just as we came across it the first time, through our monitoring for updates to plugins that might be related to a security fix, a more recent update for the plugin popped up with that and one of the new listings was:

2016-11-22 * Check Email [version = 0.3] XSS : http://www.exploitalert.com/view-details.html?id=25359

As we mentioned in the previous post while the vulnerability in the Check Email plugin was listed as being fixed in the version after 0.3, 0.5, it was until two more releases (and our helping the developer) that it was actually fixed in 0.5.2. If they had tested out the vulnerability the would have also noticed it hadn’t been fixed, but clearly they didn’t. So if you use the CWIS Antivirus Scanner to warn you about plugin vulnerabilities you will need to test out any vulnerabilities in the plugins you use to make sure they are actually fixed, otherwise might still be vulnerable (or you could use our service, since we actually do that testing in the first place).

That same release of CWIS Antivirus Scanner also continued with the adding of vulnerabilities that don’t actually exist. Two of the other entries were as follows:

2016-11-22 * MailChimp [version = 4.0.7] CSRF/XSS : http://www.exploitalert.com/view-details.html?id=25361

2016-11-22 * Easy Facebook Like Box [version = 4.3.0] CSRF/XSS : http://www.exploitalert.com/view-details.html?id=25351

In the case of both vulnerabilities just a quick glance by someone knowledgeable about vulnerabilities in WordPress plugins would likely been enough to think that they were false, since the proof of concept for exploiting them seemed to show that the protection against the vulnerability actually existed. When we tested out each of them we found the protection was properly functioning, so neither of the claimed vulnerabilities actually existed.

Including the false report of a vulnerability in the Easy Facebook Like plugin is more problematic, as CWIS Antivirus Scanner lists it as being the current version of the plugin. The plugin has 90,000+ active installs according to wordpress.org, so that is lot of webmasters that could be mislead to think their website is currently insecure. MailChimp for WordPress has 600,000+ active installs , so even though they are not listing the current as being vulnerable, a lot of people could think there website had a vulnerability in the past, which it didn’t.

21 Nov

CWIS Antivirus Scanner Plugin Spreading False Reports of Vulnerabilities In WordPress Plugins

One of the things we state about our service is that we provide our customers with the best data on vulnerabilities in WordPress plugins. To show an example what difference that makes let look at a recently created plugin that also provides data on plugin vulnerabilities.

The plugin is named CWIS Antivirus Scanner, which we became aware of it severals day ago due to our monitoring of updates made to plugins that might be related to a security fix (so that we can include more vulnerabilities that are not otherwise disclosed in our data). An update to that plugin showed up in that. Just by looking over the vulnerabilities added in that update we could already see the data provided was of poor quality. One of the vulnerabilities listed was a claimed cross-site request forgery (CSRF)/cross-site scripting (XSS) vulnerability in the plugin Newsletter, which, according to wordpress.org, has 200,000+ active installs.

As we discussed over a month ago when the report of this claimed vulnerability was released the supposed cross-site request forgery issue that would have lead to this vulnerability didn’t actually exist. It looks as though the discoverer had not understood what was going on, as there proof of concept to exploit this actually included the protection against that type of vulnerability.

Looking through the other claimed vulnerabilities we had put out posts that detailed how they were false we found that the plugin also includes false vulnerabilities for WP Job Manager (80,000+ active installs) and Robo Gallery (20,000+ active installs). Including false vulnerabilities is on its own problematic, since we have seen people become convinced that their websites was were hacked through vulnerabilities that didn’t exist (leaving the actual vulnerability unaddressed and leading to in some instances, the website being hacked again) and because developers of plugins have their time wasted having to explain multiple times that the plugin did not have the vulnerability.

The larger issue though is that including these false reports indicates that the developers of this plugin are not thoroughly reviewing vulnerability reports before adding them. Beyond the issue of false reports, that is a problem because we frequently find that vulnerabilities have not been fixed despite the report stating they have been. Since hackers usually would not check if you are using a certain version of a plugin before trying to exploit, so if the unfixed vulnerability is something hackers would target then being told that it has been fixed isn’t going to protect you. So to fully protect yourself you would need to review vulnerabilities in the plugins you use when using a data source that doesn’t do that. The other option is to use our data, because as far as we are aware we are the only ones that actually review each vulnerability before adding it to our data set (we are usually are eventually successful in getting those unfixed vulnerabilities fixed, so even if you don’t use the service you are not left vulnerable forever in those instances).

We did one other quick of their vulnerability data, which showed a bigger issue with their data. While we provide our full data set to paying customers, we are not leaving the wider community out in the cold. In the companion plugin for the service we provide data for vulnerabilities in plugins we see hacker trying to exploit, so even if you are not using the service yet you will get warned if you are using vulnerable version of those. Of the 18 vulnerabilities we added in the last month, the CWIS Antivirus Scanner included none of them. Making this more problematic is 16 of those vulnerabilities exist in the most recently available version of the plugin, so even if you keep your plugins up to date you would be vulnerable.

One more thing we thought worth noting, since we always find it to be red flag as to trustworthiness of a plugin’s developer, is if they review their own plugin. That is the case with this plugin, were the developer titled their review “Excellent!” and the body of the review is “Just installed and scanned my website’s database and files, and it works!”. Also, why is the Plugin Directory even allowing people to review their own plugins, as it obviously isn’t going to provide an accurate assessment of the plugin?