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.

07 Dec

WPScan Vulnerability Database’s Data Can Leave You Unaware That You Are Still Vulnerable

Recently we looked at two instances where the WPScan Vulnerability Database only included some of sets of vulnerable plugins that we had disclosed, leaving those relying on their data unaware that they were using plugins with known vulnerabilities in the current versions. One set of vulnerabilities were easily exploitable and the other set involved plugins that it looked like hackers were already targeting, so the omissions were pretty serious. We still don’t understand how that happened, seeing as it is much easier for the WPScan Vulnerability Database to add new vulnerabilities than it for us since they don’t review the vulnerabilities before adding them. Their lack of reviewing vulnerabilities causes its own issues, as we found in two cases where they were claiming that vulnerabilities were fixed when they were not. If it were not for us, those vulnerabilities would still be in the plugins at this point, which is a reminder of the critical role we play in the security of WordPress ecosystem.

Bad Report = Bad Fix

Recently a report of a vulnerability in the very popular NextGEN Gallery plugin, which has 1+ million active installs according to wordpress.org, was released. We continue to be unsure of what vulnerability the report was actually trying to refer to since in only a few sentences it seems to be referring to an authenticated local file inclusion (LFI), authenticated arbitrary file viewing, or authenticated remote code execution (RCE) vulnerability. The WPScan Vulnerability Database list the vulnerability as being an authenticated local file inclusion vulnerability:

But in our testing we couldn’t find where that or an authenticated arbitrary file viewing vulnerability would have existed in the relevant code. Whether either of those vulnerabilities existed it seems to us that the vulnerability definitely existed, the authenticated remote code execution vulnerability, was the most serious, since it would allow you to do the equivalent of both other vulnerabilities.

In the version that reporter of the vulnerability and the WPScan Vulnerability Database reported it to be fixed, it wasn’t. The developer had made a change in that version that would have been relevant for either a local file inclusion or arbitrary file viewing vulnerability (though the code that already existed had same impact on the possibility of an arbitrary file viewing vulnerability). After we notified the developer, a change was made to try fix the actual vulnerability, but the first attempt included a security check that was easily bypassed. After notifying them of that and suggesting a more secure way to accomplish that, the vulnerability was finally fixed in version 2.1.60.

Fixed and Fixed Again

The second vulnerability also involves a bit of confusion. While the report of a vulnerability in the Check Email plugin labels the vulnerability as a cross-site scripting (XSS) vulnerability, parts of the report claimed the issue was caused by a cross-site request forgery (CSRF) issue. In version 0.5 of the plugin, protection against CSRF was put in place for the sending of test emails, but this protection didn’t do anything for the XSS issue because that can occur without any attempt to send a test email. After noticing the issue we contacted the developer and after one additional release, 0.5.1, that didn’t fix the issue, we were able to work with them to get a proper fix to the issue put in place with version 0.5.2.

As of November 15 the WPScan Vulnerability Database listed the vulnerability as being fixed in version 0.5:

A week later it was supposed to have been fixed 0.5.1:

You Need To Double Check Their Data

If you are using data from the WPScan Vulnerability Database and you actually want to be sure that vulnerabilities in plugins you use have been fixed you will need to test out any relevant vulnerabilities yourself, or you could sign up for our service, where we actually do the testing when adding vulnerabilities to our data (there are a number of other advantages that come with our data).

11 Oct

Another Example of the WPScan Vulnerability Database’s Spotty Inclusion of Recently Disclosed Vulnerabilites

When it comes to data on vulnerabilites in WordPress plugins, at this time you really only have two choices our data or the data from the WPScan Vulnerability Database. We think that WPScan’s data is a good option for a lot of websites since it can had for free, but for websites that can afford to spend money on the security of the websites using their data comes with some significant limitations. A couple of weeks ago we looked at an example of one of those, we found that with related arbitrary file upload vulnerabilites in four plugins we had disclosed they had only included one of them. Considering that type of vulnerability is likely to be exploited and that two of the plugins they didn’t include listings for had not been fixed, so doing the basic security of keeping your plugins up to date would not have protected you, that was a pretty big issue. By comparison we had included all of them in our data at the time we disclosed them.

The source of our discovery of those vulnerabilites also is a big difference between the data sources, our data isn’t just compilation of third-party data on vulnerabilites like WPScan’s. One of the other sources of vulnerabilites in our data set is vulnerabilities we find based on monitoring what plugins hackers are targeting. Sometimes it is obvious from that what vulnerability they are targeting, but in other cases we only see that them probing for usage of the plugin, but not what they would target if it existed. The four vulnerabilites mentioned earlier came from that.

Through that monitoring we recently saw a hacker probing for usage of six plugins. Unlike most cases where we are pretty sure we found the vulnerability the hacker would be targeting, this time we are not sure if the vulnerabilities we found are the ones being targeted. Last Monday we disclosed vulnerabilites in five of the plugins (and mentioned they may be other security issues). For the sixth plugin the vulnerability we spotted while trying to figure out what might have been the connection between the plugins had already been disclosed more that two years, but must never have been reported the wordpress.org Plugin Directory as the plugin still remained there until the time we notified the people running it.

The next day the WPScan Vulnerability Database added the persistent cross-site scripting (XSS) vulnerability in WordPress Appointment Schedule Booking System to their data (incorrectly labeling it as being an authenticated vulnerability though). The other four vulnerabilities that we disclosed at the same time have not been added (the previously disclosed vulnerability was already in their data).

In the previous instance we couldn’t see anything that might explain why the vulnerability they did add was included and the others were not. That is also the case in this instance. The vulnerability they included didn’t have the most active installs, it was tied for second with 400+, while another had 1,000+. It also wasn’t the type of vulnerability as there were two other persistent XSS vulnerabilites disclosed. It wasn’t a combination of the active installs and type, as the other 400+ active installs vulnerability was also had the same type of vulnerability.

While missing vulnerabilites is a pretty significant issue, as long as WordPress chooses to leave the public in the dark about plugins they know contain vulnerabilites in their most recent version even if you don’t get notified about all of the vulnerabilites being disclosed, using the WPScan data will provide additional protection over keeping your plugins up to date. But if you want the best data when it comes to that signing up for our service provides you that. We also include vulnerabilites that we see being exploited in the companion plugin for the service, so installing that even if you have yet to sign up for the service, will provide protection over and above keeping your plugins up to date. Security plugins on the other hand will provide you little in the way of protection as can be seen in our recent tests of them against vulnerabilites in plugins.

03 Oct

Without Us Vulnerable Plugins Would Remain in the WordPress.org Plugin Directory

A couple of the important things we do when it comes to vulnerabilities in WordPress plugins came together the other day, providing an example of what happens if we were not doing it. One of the ways we keep track of what plugin vulnerabilities are out there is to monitor our websites apparent hacker activity. Through that we came across a request for the readme.txt for several plugins, including the plugin Gallery Objects, that we didn’t have installed. That type of request is usually an indication that hackers are probing for usage of the plugins before attempting to exploit something in it.

While trying to figure out what the vulnerability the hacker might be targeting in the plugins, we thought there might be some connection between the vulnerabilities in all of them. After spotting what looked to be a SQL injection vulnerabilities in several of them, we took a look at the others to see if they might contain them as well. When we got to Gallery Objects we easily found one. After we had done that, we did a check to see if there were any other vulnerabilities that had previously been disclosed in the plugin and found that the same SQL injection vulnerability we found had already been disclosed in July of 2014, which was before we started collecting data for our service (so our data for that time period is more limited than it is for newer vulnerabilities).

When we come across a disclosed vulnerability that exists in the current version plugin we usually notify the developer (unless they appear to be long gone) and if they don’t respond or we didn’t notify them first, we notify the wordpress.org Plugin Directory. At that point, unless it is really minor vulnerability, they will pull the plugin pending a fix. If anyone else had been doing the same at the time this vulnerability was disclosed the plugin shouldn’t currently be in the Plugin Directory, but it still was there as of the other day:

gallery-objects-plugin-directory

After we notified the Plugin Directory the plugin was removed within half an hour, further confirming that no one had previously notified them. It isn’t that others didn’t know, for example the WPScan Vulnerability has had the vulnerability in their data for over year:

wpscan-vulnerability-database-gallery-objects-vulnerability

But they must have never bothered to notify the Plugin Directory, which would have lead to the plugin being being removed and protected anyone who would have otherwise installed that known vulnerable plugin (we give them credit for having the vulnerability in their data before us, though).

26 Sep

Omission of Very Exploitable Vulnerabilities From the WPScan Vulnerability Database Is a Reminder of Its Limitations

If you are looking to be warned about vulnerabilities in the WordPress plugins used on your website there are really only two sources of data available to do that as far as we are aware of. There is the data for our service and the data from the WPScan Vulnerability Database (there are some others out there, but they haven’t been updated in quite some time). While we obviously think highly of our data, we think that for a lot of people that the WPScan data is a good option since it can be accessed for free through several plugins available in the Plugin Directory. That free price though hints at the fact that their data has some important limitations in comparison to the data that is provided when using our service.

Because the vulnerabilities are not actually verified before be included in their data, as we do, that leads to situations where vulnerabilities that don’t actually are exist are included and more problematically leads to vulnerabilities being listed as already being fixed when they still exist in the current version of the plugin. Because we actually test out each vulnerability we are able to catch situation where vulnerabilities have not been fixed and often able to help get those quickly resolved, which limits the impact that false claim that vulnerabilities have been fixed on those relying on WPScan’s data.

Another limitation with their data is that even though it is easier for vulnerabilities to be added to their data since they don’t need to be verified first, we have seen that they are missing a fair amount of recently disclosed vulnerabilities. That can be seen in something we noticed with a set of four vulnerabilities we disclosed a week ago.

Two months ago while looking into the possibility of a vulnerability elsewhere in the code of the plugin N-Media Post Front-end Form we found an arbitrary file upload vulnerability in it. In looking at the other plugins from the same developer we found that there was similar code with the same type of vulnerability in WooCommerce Extra FieldsN-Media Website Contact Form with File Upload, and Front end file upload and manager Plugin. One of those, WooCommerce Extra Fields, was fixed a couple weeks after we notified the developer of the issue, but the other three were not fixed. After waiting two months for them to be fixed we disclosed the vulnerabilities, notified the Plugin Directory of the issue, and they have been removed from that pending a fix (one of those, Front end file upload and manager Plugin, has now been fixed and returned).

Seeing as arbitrary file upload vulnerabilities are probably the most targeted type of vulnerability and we frequently see them being the source of successful hacking attempts, you would want the data source you use to warn you about them. As of today WPScan Vulnerability Database only contains a listing for the vulnerability in N-Media Website Contact Form with File Upload, which was added to their data two days after we disclosed it. We can’t think of a reason why that one would be the only included. One possibility we considered and rule out was that maybe it was the most popular of the plugins, but it only recently had 1,000+ active install according to wordpress.org, while two others had 2,000+ active installs (the final one had only 90+).

Since we discovered the vulnerabilities we have had them in our data since we disclosed them. (We don’t currently include vulnerabilities we have discovered, but not disclosed due to the fact that while it limits our customers knowledge of potential threats against them, it would possible for malicious actors to sign up for the service and use the same data for malicious purposes.)

If you understand the limitations of WPScan Vulnerability Database it can be a good option as the other free option is to not be warned at all. Where things can be more problematic is if a service provider (a web host or security company) is using their data without disclosing the source and not disclosing the limitations inherent in their data.

Their data can sometimes be degraded when used by providers, as we recently found that web security SiteLock appears to be using its data from that and was ignoring some of the data included, leading them to falsely claim that vulnerabilities existed in the WordPress version installed on some websites.

Also, in the case of Shield WordPress Security, they are actually trying to get people to sign up for a paid service on the basis of it checking WPScan’s data, despite the fact that it can be easily access for free through other plugins (incidentally while that plugin is marketed as being the “most powerful” and “most advanced” it has fail to stop exploitation of a vulnerability in a plugin in either of our recent tests of security plugins).

11 Jul

Wordfence Is Either Providing Bad Information Or Taking Credit For Vulnerabilities Someone Else Discovered

From what we have seen recently, the Wordfence company has a habit of saying things that are not true, from claiming a WordPress plugin vulnerability had been fixed when it wasn’t, to claiming their Real-Time Threat Defense Feed has “unmatched access to information about how hackers compromise sites” while not detecting vulnerabilities being exploited in the current version of plugins that we easily detected, to claiming that their firewall provides blanket protection against persistent cross-site scripting (XSS) while not actually catching real world exploit attempts. With noticing all that in just the past few weeks the latest situation isn’t all that surprising, but is worth noting, since at best they are putting out bad information and at worst they are trying to credit for discovering vulnerabilities in a plugin that had already been fixed when they claimed to have contacted the developer about them.

On July 6 Wordfence posted about three vulnerabilities they had discovered in the WP Maintenance Mode. They claimed that version 2.0.7 “included fixes for 3 security vulnerabilities”, and the title of the post indicates that the vulnerabilities existed in “2.0.6 and older”. The post also states that they “notified the plugin author last week”, which would mean that they notified the developer on June 26 at the earliest.

When we went to look at the vulnerabilities to add them to our data, we quickly found the changes related to fixing the authenticated remote code execution (RCE) vulnerability in version 2.0.7. We couldn’t find any changes that look related to the other two vulnerabilities. But based on the description we were pretty sure where the issue would have been, but found that the proper security was in place to protect against them 2.0.6. When we went and looked back to older versions we found that vulnerabilities had in fact existed from version 2.0.0 to 2.0.3 and had then been fixed in version 2.0.4.

Version 2.0.4 was release on June 17, which is more than a week before Wordfence claims to have contacted the developer about the vulnerabilities.

The changelog for 2.0.7 credits Wordfence for two items:

  • reset_settings _wpnonce check (thanks # Wordfence)
  • modules > google analytics code sanitization (thanks @ Wordfence)

The first is something that Wordfence didn’t bring up in their post and the other refers to the authenticated remote code execution vulnerability. The changelog for 2.0.4 doesn’t mention Wordfence or even mention anything that appears to be related to the vulnerabilities fixed.

In the best case, Wordfence actually reported all of the vulnerabilities and then incorrectly listed what version was vulnerable and when they contacted the developer. That wouldn’t be a huge issue, but with so much of security being about trust and considering their track record we would probably recommend avoiding them based on that track record alone. It would much more of an issue if they are taking credit for vulnerabilities discovered by someone else.

We Always Verify Data Before Adding It To Our Service

When we add vulnerabilities to the data set for our service we test it out first so that we can insure the vulnerability existed (there are more than a few false reports of vulnerabilities), that it has actually been fixed (many times we find that a vulnerability has not been fixed, despite a claim that it has), so that we can let you know what version are vulnerable, and so that we can accurately label the vulnerability. Other similar data sources don’t do any testing, so for example in this case, if you use a plugin or service that uses data from WPScan vulnerability database you are incorrectly told that those two vulnerabilities existed up to version 2.0.6 and were fixed in 2.0.7 (you also are not told which other versions were vulnerable):

wpscan-vulnerability-database-wrong-vulnerable-version-2

While that has a limited impact in a case where the vulnerability has been fixed, since most people are probably just concerned about being protected now that the vulnerability has been exposed, but in other cases they will falsely claim that a vulnerability has been fixed when it hasn’t.

27 May

Web Host Pantheon Spreading Inaccurate Information About WordPress Plugin Vulnerabilities

One of the things we do to keep track of what vulnerabilities are out there in WordPress plugins, so that we can provide our customers the best data, is to monitor the WordPress forums for postings related to them. One thing that has lead us to notice is that the quality of postings isn’t always great, take for example a claim of a vulnerability in the plugin Advanced Custom Fields. That claim lead to three separate posts in a matter of a week all mentioning the same issue, instead of those people just adding to the existing post (that isn’t an uncommon occurrence).

In this case the claimed vulnerability is something that we don’t consider a vulnerability. The claimed issue is that the plugin allows cross-site scripting (XSS), but since the only people that would be able to access the functionality needed to do it are Editor and Administrator level users that would normally have the unfiltered_html capability, they are specifically given the ability to use the equivalent of cross-site scripting (XSS) already. It would probably be more accurate to describe the issue as a bug. The people running the Plugin Directory agreed with us that it wasn’t a vulnerability.

It was perfectly reasonable for the posters to have brought this up since your average WordPress user isn’t going to have the expertise to review the report as we can (and had already done when it was released in the beginning of May). What seems to be more of an issue is that others that should be better informed would be passing this claim along without doing the proper checking. One of those was the web host Pantheon, which had notified one of their customers and then the customer had then been one of the posters.

On the homepage of Pantheon’s website they claim to have Enterprise-Grade Security

pantheon-enterprise-grade-security

and they state that they have a

Relentless, around the clock commitment to website security

So it isn’t too much to think they could handle reviewing such a report before passing it along to their customers.

Instead they look to have outsourced doing that to the WPSCan Vulnerability Database.

From the post:

They link to this website: https://wpvulndb.com/vulnerabilities/8481

With a little more checking we found that as part of their WordPress Launch Check tool they take data from the WPScan Vulnerability Database to warn about plugin vulnerabilities. The problem with doing that is that data source is known to not always contain the most accurate information, due to a lack of verification.

Just this week we looked at a completely false report of a vulnerability, which they include in their data. And a couple weeks before that we noticed another false report that they listed and listed as being fixed, but also being a potential false positive that “Needs further investigation.”. How they can know it was fixed, but not be sure if it actually existed in the first place is odd.

It isn’t just including false report of vulnerabilities, they also list vulnerabilities as being fixed in a certain version when the vulnerability has yet to be fixed.

If Pantheon wants to continue to use that data they really should be manually reviewing it before passing it along to customer or at least warn them that is isn’t necessarily accurate.

In the meantime if you are looking for higher quality Plugin vulnerability data, you can always sign up for our service. We verify each vulnerability we add to our data set, so you don’t run into those issues and we help to make sure that outstanding vulnerabilities actually get fixed instead of listing them as being fixed when they are not.

23 May

False Vulnerability Report: CKEditor 4.0 Arbitrary File Upload Exploit

As part of our cataloging the vulnerabilities in WordPress plugins for our service we come across false reports of vulnerabilities from time to time. So that others don’t spend their time looking over these as well, we post our findings on them.

We have recently had requests for a file in the plugin CKEditor for WordPress on one of our websites as part of a series of requests that seem to be looking for use of plugins, likely to then try to exploit them. We couldn’t find any valid reports of vulnerabilities in this plugin, but we did find one false report of a vulnerability that clearly has continued to confuse some people into believing it was real long after its release.

The report from February of 2013 is titled CKEditor 4.0 Arbitrary File Upload Exploit and includes code that is described as allowing to “upload a shell to compromise the system” through the plugin. If take a look at this for a second it becomes clear it is false. The code has you send a request to the file/includes/upload.php in the plugin. If you do that in version 4.0 you will received the following error message

Fatal error: Call to undefined function _e() in [server location]/wp-content/plugins/ckeditor-for-wordpress/includes/upload.php on line 3

Looking at the first three lines of code in the file you can see what is going on:

1
2
3
<div class="wrap">
	<div id="icon-wp-ckeditor" class="icon32"><br /></div>
	<h2><?php _e('CKEditor - Upload Settings', 'ckeditor_wordpress') ?></h2>

The first two are just HTML code and third uses the function _e(), which is part of WordPress, so when accessing this file directory that won’t exist. That leads to the error, so this could not possibly work.

In version 4.5.3.2 code was added to the beginning of the file that stops direct access to the file:

1
<?php if ( !defined('ABSPATH')){ exit; } // Exit if accessed directly

Going back to version 1.0 the third line has contained the use of the e_() function, so sending a request directly to the file could never had worked.

The other major problem with this is that the file /includes/upload.php doesn’t process uploads at all, instead it contains the code for displaying the Upload Options settings page for the plugin. So we have no idea why someone though this would possibly allow uploading files.

A GitHub Project and the WPScan Vulnerability Database

Somehow all of that didn’t stop from someone from creating a project on Github to exploit the non-existent vulnerability last year. No surprisingly the part where the code to exploit vulnerability would be, it states that “This part is not ready”:

 #TODO: This part is not ready.
 files = {'NewFile': open(file_to_upload, 'rb')}
 r = requests.post(("%s/wp-content/plugins/ckeditor-for-wordpress/includes/upload.php" % website), files=files)
 print r.text

The vulnerability is also listed in WPScan Vulnerability Database despite not actually existing, which is yet another reminder of the pretty serious accuracy issues with their data:

wpscan-vulnerability-database-false-report

09 May

WPScan Vulnerability Database Includes Fake Vulnerability, Claims It Was Fixed

Last month there was report of a remote code execution vulnerability in the plugin Robo Gallery, as we discussed at the time the vulnerability didn’t actual exist (though another vulnerability did exist in the relevant code). Despite the fact that it didn’t exist and couldn’t possibly have been exploited as shown in the included proof of concept, that hasn’t stopped people from trying to exploit. We had one attempt on our website the week after the report and a recent thread on wordpress.org indicates that attempts are continuing to happen. Based on what request were sent in those two situations, those were done by different people, with the second one being from someone who was less aware of the problems with the advisory, considering they sent a GET request when that couldn’t possibly work.

While doing some more looking around on this we found it is not only hackers that didn’t bother to actually look at the vulnerability report. The fake vulnerability is also listed in the WPScan Vulnerability Database, which is a database of vulnerabilities related to WordPress. That database is used in a number of plugins for alerting to vulnerable plugins.

What is rather strange about the listing it states that “This is potentially a False Positive. Needs further investigation.”, while at the same time claiming that it has been fixed:

wpscan-vulnerability-database-fake-vulnerability

How they know it has been fixed, but not being sure if it actually exists in the first place, is curious at best.

What makes this more problematic is that it looks like many of the tools that use their data just display the title of the vulnerability, so the disclaimer in the description would not be shown.

This is great reminder of the importance of testing out vulnerabilities before including them in data sets of vulnerabilities, which we do, but others, including the WPScan Vulnerability Database don’t do. That lack of testing leads to other problems like the WPScan Vulnerability Database claiming that vulnerabilities that haven’t been fixed were in fact fixed, which leaves users of their data falsely believing they are secure against publicly disclosed vulnerabilities.

29 Mar

WordPress Allowing Plugins With Known Vulnerabilities To Return To The Plugin Directory

Two weeks ago we discussed the need for fixes for vulnerabilities in WordPress plugins to tested, using an example of a plugin that had a vulnerability that was disclosed in 2012 that had not actually been fixed. That plugin has now been removed from the Plugin Directory due to our reporting to the people running it that the issue remained and that there was another security vulnerability was in the plugin. While WordPress badly needs to finally start notifying when a website already has a plugin with known vulnerabilities installed, stopping others from adding the plugins while they know it to be insecure is a lot better than nothing. But a couple of recent vulnerabilities we reviewed show that WordPress is allowing plugins that have been removed from the Plugin Directory to return without the vulnerabilities being fixed.

The first case involves the SP Project & Document Manager plugin, which was found by Michael Helwig to have a several security vulnerabilities. The advisory indicated that WordPress security team had been aware of the vulnerabilities and that the vulnerabilities had been fixed in version 2.6.0.0. When we went to test out the vulnerabilities to add them to our service we found that what we considered to be the most serious vulnerability had not been fixed as of the then current version, 2.6.1.2. That vulnerability allowed anyone who was at least a subscriber level user the ability to upload any kind of file, so for example they could upload a .php file and execute code on the website through that.

This vulnerability is quite easy test for, all you have to do is:

  1. Installed and activate the plugin.
  2. Create a new post with the [sp-client-document-manager] in it.
  3. Visit the new post (preferably while log in as subscriber level user).
  4. Attempt to upload .php file.

After doing that you would see the file has been successfully uploaded.:

sp-project-document-manager-php-file-upload

So we have hard time understanding how it was the WordPress folks could have missed it that it had not actually been fixed.

The second case involves a persistent cross-site scripting (XSS) vulnerability in the DW Question & Answer plugin, which was discovered by Rahul Pratap Singh. The advisory indicated that WordPress security team had removed the plugin several days before a new version was released, 1.4.2.3, that patched the vulnerability. When we went to test out the vulnerability to add it to our service we found that the vulnerability had not been fixed as of the then current version, 1.4.2.3.

In this case it would have been more complicated for the WordPress security team to check if the vulnerability had been fixed since the proof of concept provided with advisory was not very good. But looking at the changes made in version 1.4.2.3 should had given them pause that it probably had not been fixed, since we don’t see anything that looks like it should had fixed the claimed issue.

WPScan Vulnerability Database Fails As Well

In these both of these cases you had the plugin’s developer, the discoverer of the vulnerability, and the WordPress people all aware of a vulnerability, but it still remained in the plugin. If you used our service you would have been warned as soon as we had reviewed the vulnerabilities and we also made sure that vulnerabilities actually got fixed, but what about similar services? Last week we reviewed one plugin and found that it didn’t warn about these vulnerabilities or any of from the last month. But what about if used one of the plugins that gets it data from the WPScan Vulnerability Database? You would have been out of luck as well, in both cases they improperly list the vulnerabilities as been fixed in earlier versions:

WPScan Vulnerability Database claims the vulnerability in SP Projects & Document Manager was fixed in version 2.6.0.0

WPScan Vulnerability Database claims the vulnerability in DW Question & Answer was fixed in version 1.4.2.3