13 Feb

Actually MainWP, You Will Miss out on Vulnerabilities if You Rely on the WPScan Vulnerability Database

The marketing of security products and services often consists of misleading or outright false claims, which isn’t all that surprising considering how awful the security industry is.  One thing we have seen being misleadingly used fairly often is the phrase real-time, which often is used in way that make it sounds like a much higher level of service is being provided.

As example of that involving our area of focus, we recently ran across MainWP, a service for managing multiple WordPress websites, promoting an extension for their service that accesses data from the WPScan Vulnerability Database with this claim:

  • The Vulnerability database updates itself real-time so you don’t miss out on any vulnerabilities.

While it is true that data source updates in real-time that doesn’t mean that you won’t miss out vulnerabilities, because the real-time part is that you can access data on vulnerabilities in real-time after they are added to that data source. They first have to be added though, so what would matter is how long it takes for them to be added or if they are added at all. That is something MainWP doesn’t address there and we would guess they probably didn’t bother to look into it (it wouldn’t be the first someone made an inflated claim about the WPScan Vulnerability Database without knowing what they are talking about).

The reality is that in some cases a non real-time updated data source for plugin vulnerability data provides data that is missing entirely from the WPScan Vulnerability Database. That being the companion plugin for our service, for which we include data on vulnerabilities that appear to be being exploited, so that even those not using our service yet can be warned about them.

Two recent vulnerabilities missing from their data, but in our plugin, are good examples of how WPScan’s data is less than ideal and really should be paired with our plugin (or even better, just use our service).

On January 4 NinTechNet disclosed that they had seen an arbitrary file upload vulnerability in the plugin LearnDash LMS being exploited and that it had been fixed after they notified the developer. That didn’t seem to be an isolated situation as we were in contact with someone shortly after that whose website was likely had exploited through that vulnerability well.

That would seem to be an important vulnerability to warn about, but more than a month later it still hasn’t been added to the WPScan Vulnerability Database. By comparison our plugin has been warning about it since January 9 (and our service before that). Because that data comes with the plugin, our plugin would need to be updated to be warn about that, but if you are not keeping plugins up to date, you are going to have larger security issues.

On November 27 we disclosed an arbitrary file upload vulnerability in the plugin PHP Event Calendar.  We had noticed that after seeing someone probing for usage of the file the vulnerability existed in, on our website the day before, so it is likely that vulnerability is being exploited as well.

Two and half months later, during which we have seen additional probing for the plugin in third-party data we monitor, the vulnerability still hasn’t been added to the WPScan Vulnerability Database. It was added to our plugin’s data the same day we disclosed it (and added to our services data then as well). That vulnerability hasn’t been fixed, so simply keeping plugins up to date would not protect you from it.

Those examples stick out, not just because the vulnerabilities were being exploited, but because it would be so easy for the people behind the WPScan Vulnerability Database to make sure to include those, since all they would have to do is monitor changes being made to our plugin. It therefore probably isn’t all that surprising to hear that their database is also missing a lot of other vulnerabilities as well. For example, when we did a comparison of  new vulnerabilities added to the data set for our service versus WPScan’s during the month of June last year, we found that we had added three times as many vulnerabilities. There are other serious issues with their data, which we have discussed in the past.

Another thing to keep in mind, when it comes to real-time claims, is that they also depend on how often the source is being checked. MainWP doesn’t provide any information on how often their extension checks things, but with our service you can check as often as hourly to see if there are any vulnerabilities in the versions of plugins you are using.

This isn’t the only incident where something marketed as real-time has left a lot to be desired when it comes to plugin vulnerabilities, as back in June of 2016 we discussed Wordfence’s apparent lack of knowledge of numerous probable zero-day vulnerabilities despite the claims they make about their Real-Time Threat Defense Feed.

19 Dec

More Evidence That the Data in the WPScan Vulnerability Database Isn’t All That Reliable

Yesterday we noted how the WPScan Vulnerability Database had incorrectly labeled a reflected cross-site scripting vulnerability discovered by Robb Carr in the plugin RegistrationMagic as having been fixed. While it would have been easy to check the proof of concept provided with the report on the vulnerability and see that the vulnerability still existed, as we did, they pretty clearly didn’t. That lack of testing is a big issue, since if you are relying on their data, you really need to test out any vulnerabilities in the plugins you use to make sure they truly have been fixed (or just use service that test vulnerabilities when adding them to their data set, of which we seem to be the only one that exists).

Looking at the entry for that in their database today, they have changed the entry to indicate that the vulnerability has been fixed as of the version released after we notified the developer of the issue:

They also changed the entry for a related claimed authenticated SQL injection vulnerability in the plugin to indicate it was fixed in that version as well:

That seems to be incorrect and an indication that they still didn’t bother to test things out.

As was mentioned in our previous post, we wouldn’t consider what was claimed to be vulnerability there to be a vulnerability, as the issue could only be exploited by Administrators, who normally would be able to do the equivalent of this (or to change a plugin to remove security code). But if you consider it a vulnerability, then it looks to us that it was fixed in the version that WPScan previously listed it as having been fixed in. As with the other vulnerability this would be easy to test out. All that they would have needed to do that would be to install version 3.7.9.2 and visit the proof of concept URL and see that it worked, then switch to version 3.7.9.3 and see that it didn’t work. Looking at the underlying code, it looks like that version 3.7.9.3 fixed it as well.

18 Dec

Lack of Due Diligence by the WPScan Vulnerability Database and WPCampus Lead to False Claim That WordPress Plugin Vulnerability Was Fixed

We are big believers in having the full details of vulnerabilities, whether they are in WordPress plugins or other software, be disclosed in most instances. That isn’t because that makes our work of compiling data on ones in WordPress plugins easier, but because we see the positive impact that has, as well as the more often emphasized negative impact. One of the important reasons for doing that is that we often find vulnerabilities that were supposed to have been fixed have only been partially fixed or not fixed at all. With more details it makes it easier for others to check to make sure the vulnerability has been fully fixed.

What is important to keep in mind though is that just releasing those details doesn’t mean that they will be checked and any unfixed vulnerabilities will be caught. When it comes to WordPress plugins, that is one of quite a few things that we seem to be the only ones doing. You wouldn’t know that by claims that people make about us, for example in a recent review of the companion for a plugin, which was less a review of the plugin and more someone just bashing us, they wrote:

Why isn’t the author doing more to help with the security community instead of bashing everyone?

Based on one of their other reviews they are a customer of Wordfence, so it wasn’t surprising that they wouldn’t know what we are up to do, since Wordfence is a company that intentionally hid that we had been the discoverer and discloser of a vulnerability they were discussing not too long ago (something they have done not just with us, but others companies as well). We had responded to that review asking for evidence that someone does more than we do and we have yet to get any response.

In another review, which was changed well after it was written (after, it seems the writer didn’t take kindly to us disagreeing with them about something, which seems to be a reoccurring issue with them), the reviewer made this claim:

The WPScan Vulnerbility Database is a valuable resource for WordPress users and developers, but the author has nothing but negative things to say about them, presumably since they do “competing” work. (Even though they are in completely different leagues – WPScan’s resources are far more robust.)

We have repeatedly said that is good resource for a lot of people (since the data can be accessed for free), but also that there are important limitations that people should know about. So claiming that we have “nothing but negative things to say about them” isn’t true. What also wasn’t true was the last part of that “Even though they are in completely different leagues – WPScan’s resources are far more robust.”. There wasn’t any evidence provided that backed that up and it certainly isn’t true for a number of reasons. One of them is that in terms of newly disclosed vulnerabilities, we are adding many more vulnerabilities than them. Another reason that isn’t true is that we actually test out vulnerabilities before adding them to our data set and WPScan doesn’t, which would catch unfixed ones.

Claims of Fixed Vulnerabilities in RegistrationMagic

Last week Rob Carr put out claims that there had been an authenticated SQL injection and a reflected XSS vulnerability that had been in the plugin RegistrationMagic and had been fixed in version 3.7.9.3.

Those claims were then repeated on the WPScan Vulnerability Database:

And also by WPCampus:

 

Only Accessible by Administrators

When we went to see about adding those vulnerabilities to our data set we first looked at the claim of an authenticated SQL injection vulnerability. While the report contains a lot of detail, it is missing a key detail, what level of user is required to exploit this. That is important since if it was only Administrators that could access this, it wouldn’t really be a vulnerability, since those users would normally be able to do the equivalent of SQL injection.

When we started testing it, we tried the proof of concept URL logged in as Administrator and it worked. We then tried it logged in as a user a level below, an Editor. When we did we got served a page that said:

Sorry, you are not allowed to access this page.

That would seem to indicate that only Administrators could exploit this. To confirm that, we looked at what capability the page that was being visited in the proof of concept required. The code that does is that below, and the fourth parameter in that list the capability required:

add_submenu_page("", RM_UI_Strings::get('ADMIN_MENU_MNG_FIELDS_PT'), RM_UI_Strings::get('ADMIN_MENU_MNG_FIELDS_PT'), "manage_options", "rm_field_manage", array($this->get_controller(), 'run'));

The “manage_options” capability is a capability that normally only Administrator level users have (and normally if lower level users have it they would also have the capability to create new Administrator users). So there isn’t really a vulnerability here, as we see it. It could be that those other sources have a different view of things, but based on looking into the second claimed vulnerability, it seems likely they did even check what users this was limited to.

This Vulnerability Hadn’t Been Fixed

The second vulnerability sounded unusual to us, as the claim was that the SQL injection vulnerability could be used to cause reflected cross-site scripting (XSS). That isn’t something we can recall seeing before.

We first tried out the proof of concept URL with version 3.7.9.2 installed and it worked. We then tried it in 3.7.9.3, which was what the discoverer and the listings on the WPScan Vulnerability Database and WPCampus claimed was the version that fixed it. The proof of concept still worked. We then tried it in the then latest version, 3.8.0.4, and it still worked. At that point we installed version 3.8.0.4 in a new install of WordPress, to make sure that the successful exploration when version 3.7.9.2 was tested didn’t cause the tries with newer versions to only appear to be vulnerable, and the proof of concept still worked.

Considering how easy it was to test this vulnerability, it indicates that those other sources are not doing any testing before making claims as to whether vulnerabilities have been fixed. That is pretty significant limit of the usefulness of their data and getting accurate information is one the important benefits of using our data instead, but one that people likely wouldn’t know about if we were not mentioning it since those sources don’t have a disclaimer that they don’t really know if their data is accurate. It certainly doesn’t help when the public is making further inaccurate claims about other data sources, like in the review mentioned earlier.

At that point we went to look at the changes made in the version that this was supposed to be fixed in, but it didn’t really giving us any idea what might be wrong.

We then looked at the HTML code being served when requesting the proof of concept URL. From that we could see that at least part of the issue is that value of the GET input “rm_form_id” from the proof of concept URL was being output numerous times on the page.

In looking at the underlying code form the plugin we found that one of those instances was generated by the following code:

var loc = "?page=rm_field_add&rm_form_id=<?php echo $data->form_id; ?>&rm_form_page_no=" + curr_form_page + "&rm_field_type";

So at least part of the issue was that the value of $data->form_id was not validated or sanitized and then being output without being escaped. Trying to trace through the code to find where that value came in to the plugin was a bit difficult. That wasn’t really all that surprising once we noticed that the developer was CMSHelpLive, which is company that doesn’t really have a great concern for security (even of their own websites despite offering security services) or for code quality.

We eventual tracked down were the value is brought in to the plugin, it was one three instances of the following line in the file /admin/controllers/class_rm_field_controller.php:

177
$data-&gt;form_id = $request-&gt;req['rm_form_id'];

Restricting the value being brought in to integers removed all the instances of cross-site scripting (XSS). Prior to that there were a couple of instances of the XSS that might have come from data passed through SQL statements, but we weren’t able to easily tell where they were coming from.

After we notified the developer they released version 3.8.0.9, which fixes this by restricting the value $request->req[‘rm_form_id’] to an integer by adding the following line to function manage() in the file /admin/controllers/class_rm_field_controller.php:

124
$request-&gt;req['rm_form_id']= absint($request-&gt;req['rm_form_id']);
03 Nov

Not Really a WordPress Plugin Vulnerability – Week of November 3, 2017

In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we have been releasing posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. We have been thinking that providing information on why those are not included in our service’s data could be useful, so we are trying out putting a weekly post when that occurs detailing those issues.

Full Path Disclosure in Inline Image Upload for BBPress

At the end of September we mentioned that the website WPCampus wasn’t properly crediting us when discussing things we had written, but it isn’t just us that is true with us. Last week in their post on plugin vulnerabilities they credited Wordfence for discovering a vulnerability, but for the other claimed issue they discussed they left out any mention of the discoverer:

For this week’s unfixed vulnerabilities, the Full Path Disclosure issue with the Inline Image Upload for BBPress (and it’s Pro version) isn’t a vulnerability by itself, but can be used in combination with other attacks that require knowing the server path. Hopefully the vendor will release a fix soon, but if not, you can mitigate this issue by ensuring display_errors is disabled for php for your site.  The specifics of how you disable it will depend on your hosting set up.  If you’re not sure, contact your hosting provider or system administrator.

In looking at the linked spreadsheet with the details, we immediately noticed it looked like this wasn’t really a vulnerability as it said in the note for it, “Ensure error_reporting/display_errors is turned off/disabled”. As we noted back in May with a claim made by Wordfence if you consider this a vulnerability then WordPress is also vulnerable:

So is that a vulnerability? We would say probably not if it doesn’t display when error reporting isn’t enabled (though the issue in this plugin could easily be fixed), but if it is, there is a much larger issue because the same thing will occur in the core WordPress software. For example, if you were to visit /wp-includes/wp-diff.php with error reporting enabled you would get this:

Warning: require(ABSPATHWPINC/Text/Diff.php): failed to open stream: No such file or directory in [redacted]/public_html/pluginvulnerabilities.com/wp-includes/wp-diff.php on line 13

Fatal error: require(): Failed opening required ‘ABSPATHWPINC/Text/Diff.php’ (include_path=’.:/usr/local/lib/php’) in [redacted]/public_html/pluginvulnerabilities.com/wp-includes/wp-diff.php on line 13

WPCampus isn’t the only source of WordPress plugin vulnerabilities passing along inaccurate information on vulnerabilities that we ran across this week. During our monitoring of the WordPress Support Forum we looked at thread bringing up a claimed vulnerability in the plugin Comment Attachment. The message from the plugin Vulnerable Plugin Checker that uses data from the WPScan Vulnerability Database shown in the thread stated:

Comment Attachment has a known vulnerability that may be affecting this version. Please update this plugin.

Comment Attachment 1.0 – XSS

That isn’t all that helpful to someone trying to figure out what is going on. Looking at the relevant entry in WPScan’s data pointed to the source of the claim. The instructions for exploiting the claimed issue are as follows:

1) Download “Comment Attachment” And Install
2) Go To Sitting Comment Attachment :
Settings > Discussion > Comment Attachment
3) Insert In “Attachment field title” This Code And Save :
“><script>alert(/Arsan/)</script>
4) And Try To See Your Post And Comment; Follow Link :
http://localhost/wp/?p=1

To access that page you have to have the “manage_options” capability. Users with the “manage_options” capability would normally only be Administrators (and if others are given the capability they would normally be able to create Administrators accounts), which would normally have the “unfiltered_html” capability and therefore could do the equivalent of this.

20 Oct

WPScan Vulnerability Database Falsely Claims WP Job Manager Contained Arbitrary File Upload Vulnerability

When it comes to getting data on vulnerabilities in WordPress plugins there are a number of companies that are interested in making it appear they are generating that type of data without having to do the work it takes to provide that. They instead of reuse data from the WPScan Vulnerability Database, sometimes without disclosing that is the source and in every instance we have seen so far, without providing a warning as the low quality of the data. As example here was what Wordfence’s plugin recently sent out to people using the plugin Sermon Browser:

The Plugin “Sermon Browser” has been removed from wordpress.org.
Current Plugin Version: 0.45.19

Severity: Critical

Vulnerability Information:
https://wpvulndb.com/vulnerabilities/6404

Status New

It has unpatched security issues and may have compatibility problems with the current version of WordPress. Get more information.
https://docs.wordfence.com/en/Understanding_scan_results#Plugin_has_been_removed_from_wordpress.org

As we noted previously, the vulnerability being linked there had been fixed six years ago. For whatever reason when it was added to WPScan’s data three years ago it was not listed as being fixed, so when Wordfence reused the data without checking it first they spread inaccurate information. They didn’t include a disclaimer to warn people that they hadn’t checked that data, they even make it sounds like the opposite as they said “It has unpatched security issues”, and therefore didn’t know if it there was any veracity to the claim of a vulnerability in the plugin.

The problem with WPScan’s data isn’t limited fixed vulnerabilities are not correctly labeled as being fixed. Another issue is vulnerabilities that didn’t actually exist being included and labeled as being fixed despite not existing, an example of we just ran across while preparing another post. That could be a problem if you were using WPScan’s data while working on cleaning up a hacked website, since you might believe that you have discovered a likely cause of a hacking, through an outdated plugin, only to later find that wasn’t the case when the website gets hacked again.

This isn’t the first time we have run across this, but what we found notable about this instance is that one of our blog posts is cited despite contradicting their information.

Here is the entry as it is currently:

The claim is that there was an unauthenticated arbitrary file upload vulnerability in the plugin WP Job Manager, which has been fixed. There first reference for that, an entry at Packet Storm from July of last year, makes the claim that there was a remote shell upload/arbitrary file upload vulnerability as of version 1.25. In August of last year we wrote a post detailing why that was false, as the plugin limits what types of files can be uploaded. The plugin did and still does allow anyone to upload files permitted by WordPress.

The third reference cited by WPScan states that:

 Fix: Prevents use of Ajax file upload endpoint for visitors who aren’t logged in.

All that indicates is that those not logged in to WordPress can no longer uploads files through WordPress AJAX functionality, but as we already mentioned the plugin did not allow arbitrary files to be uploaded, so the change does not relate to what they said was fixed.

What is the other important part of this is what was mentioned in the post of ours that was cited:

But more importantly we didn’t understand how the change made was supposed to fix the issue since by default those that didn’t already have a WordPress accounts could still upload images through the plugin.

As the title of our post indicates, “Image Upload Capability in WordPress Plugin Being Abused”, the issue with this plugin was that the ability to upload images was being abused. The change made doesn’t actually remove that capability, it just removes the ability to do that through AJAX. You don’t have to take our word from that, here is what one of the developers said:

Hi there! They shouldn’t be prevented from uploading files, just through the use of the Ajax endpoint. The forms should fallback to normal file uploads and work just fine.

So to recap, the vulnerability that WPScan lists didn’t exist, but if there was a security vulnerability in the plugin, it still exists, just the way it was being abused at the time was removed.

While we think that WPScan’s data is good source for a lot of people because it can be accessed for free, you do get what you pay for. Where its use is more problematic is when it is used by security companies without a proper disclaimer as to the sourcing and quality issues, which also extend to have a limited set of new vulnerabilities in it. If those companies were to admit to all of that, it would probably make more people understand that the inflated claims these companies often make about their expertise are far from the truth. (It would also help us, as once people realize the value of such data, getting better quality data would likely be of more interest to some of them.)

13 Oct

Not Really a WordPress Plugin Vulnerability – Week of October 13, 2017

In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we have been releasing posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. We have been thinking that providing information on why those are not included in our service’s data could be useful, so we are trying out putting a weekly post when that occurs detailing those issues.

Directory Traversal Vulnerability in WP Smush

There recently was a report of a directory traversal vulnerability in WP Smush. If you believed the developers (who are also the developer of a security plugin) this is a vulnerability, the changelog for version 2.7.6 is:

  • Security: Fixed path traversal vulnerability. Thanks Ricardo Sánchez(@neorichi) for responsible disclosure.

The report provides a link that is supposed to confirm that it is a vulnerability, that link is to this comment in a thread on the WordPress Support Forum:

@neorichi, Just to update you, we’ve a new security release to fix the bug.

Appreciate your efforts to report this responsibly.

Cheers, Umesh

Looking at the proof of concept it seemed like something might be off about this, as it seemed that you might need a nonce to exploit the issue, but the report doesn’t explain whether a valid nonce is needed or not and if so, where it could be found:

http://localhost/wordpress/wp-admin/admin-ajax.php?dir=../../../../../../&multiSelect=true&action=smush_get_directory_list&list_nonce=xxxxxxx

That URL indicates that an AJAX accessible function is being accessed. Looking at version 2.7.5 that function is only accessible to those logged in, which is not noted in the report (that would make this an authenticated vulnerability at least):

43
add_action( 'wp_ajax_smush_get_directory_list', array( $this, 'directory_list' ) );

Looking the function being accessed, directory_list(), which is located in the file /lib/class-wp-smush-dir.php, you can see that before it checks for a valid nonce it checks to make sure the user making the request has the “manage_options” capability:

341
342
343
344
345
346
347
function directory_list() {
	//Check For Permission
	if ( ! current_user_can( 'manage_options' ) || ! is_user_logged_in() ) {
		wp_send_json_error( "Unauthorized" );
	}
	//Verify nonce
	check_ajax_referer( 'smush_get_dir_list', 'list_nonce' );

Users with the “manage_options” capability would normally only be Administrators (and if others are given the capability they would normally be able to create Administrators accounts), which would normally have the ability to view the directory structure with their capabilities, so this isn’t really a vulnerability.

If you are going to claim this is a vulnerability (as the folks at ThreatPress,  WPCampus, and the WPScan Vulnerability Database have) we don’t see how it could be claimed that it is fixed as the change just restricts you to accessing directories within in the WordPress directory:

349
350
351
352
353
354
355
356
357
358
359
//Get the Root path for a main site or subsite
$root = realpath( $this-&gt;get_root_path() );
 
$dir     = isset( $_GET['dir'] ) ? ltrim( $_GET['dir'], '/' ) : null;
$postDir = strlen( $dir ) &gt; 1 ? path_join( $root, $dir ) : $root . $dir;
$postDir = realpath( rawurldecode( $postDir ) );
 
//If the final path doesn't contains the root path, bail out.
if ( !$root || $postDir === false || strpos( $postDir, $root ) !== 0 ) {
	wp_send_json_error( "Unauthorized" );
}

Persistent Cross-Site Scripting (XSS) Vulnerability in Contact Widgets

A frequent source of false claims of vulnerabilities in WordPress plugins is a lack of understanding of the WordPress security model. WordPress has a capability “unfiltered_html” that allows users to do the equivalent of cross-site scripting (XSS), which in simply terms is just the ability to use JavaScript code. A claim of a persistent cross-site scripting (XSS) vulnerability in the plugin Contact Widgets  involved adding JavaScript code to a widget that is part of the plugin. Normally only Administrators are allowed to edit widgets, so the testing likely was done with a user who has the ability to do the equivalent of the vulnerability.

In one of the responses to the claim, one of the developers responded:

Then this is not a bug. We explicitly allow Administrators to do whatever they want in the widget via that unfiltered_html permission, just as core does with the Text widget.

Looking at the code here is what he is talking about (in the file /includes/class-contact.php):

201
'sanitizer'     =&gt; function( $value ) { return current_user_can( 'unfiltered_html' ) ? $value : wp_kses_post( stripslashes( $value ) ); },

Just to further confirm things were working correctly, we gave an Author level user, who doesn’t have the “unfiltered_html” capability, the ability to edit widgets by giving them the “edit_theme_options” and then tried the proof of concept. As expected the malicious input was sanitized and there was not exploitation, so there isn’t a vulnerability here at all.

26 Sep

Wordfence Falsely Claims Current Version of Removed Plugin Contains Vulnerability That Was Fixed Over Six Years Ago

A couple of weeks ago we noted that Wordfence was trying to make people reliant on their plugin instead of helping everyone in the WordPress community by getting behind the effort for WordPress to start alerting when websites are using plugins that have been removed from the Plugin Directory. One of the reasons we noted as to why what they were doing was problematic even for those using their plugins, is that the people on the WordPress side of things know why plugins are removed and could let people know why, while Wordfence can’t. It turns out though that Wordfence will present things in way that leads to people to believe otherwise, while in the case of at least one plugin, presenting incredibly inaccurate information about the security of it.

Through monitoring of the WordPress Support Forum we do to keep track of vulnerabilities in WordPress plugins, we came across the thread about the plugin Sermon Browser, which has been removed from the Plugin Directory. The original poster in thread wrote:

I just received a “Critical” security notice from my website last week. It stated that the plugin was removed from the WordPress repository because of critical security issue. Apparently a SQL injection vulnerability has been identified.

I am sure the owner was notified of the removal. But I would expect a “sticky” post or an update or something. Has anybody else heard of any response to this?

Below that was the message from Wordfence:

The Plugin “Sermon Browser” has been removed from wordpress.org.
Current Plugin Version: 0.45.19

Severity: Critical

Vulnerability Information:
https://wpvulndb.com/vulnerabilities/6404

Status New

It has unpatched security issues and may have compatibility problems with the current version of WordPress. Get more information.
https://docs.wordfence.com/en/Understanding_scan_results#Plugin_has_been_removed_from_wordpress.org

Following the link to the entry on the WPScan Vulnerability Database in that message brings up this page:

The most important things to note in that is the vulnerability is not labeled as being fixed and the dates, the listing was added on “2014-08-01″ and last updated ” 2015-05-15″. From that page you can get the actual information on the vulnerability.

In looking over things we found that the vulnerability was actually fixed the same day it was disclosed, back on April 26, 2011.

That the information in the WPScan Vulnerability Database isn’t accurate isn’t a surprise. It was just back in June that we discussed their inaccurately label an unfixed vulnerability as being fixed. In April we noted another instance where they labeled fixed plugins as not being fixed. We could go because there are plenty of instances we have discussed on this blog, which certainly are not all of them.

WPScan’s accuracy issues are only part of the problem here, as Wordfence is choosing to further spread the inaccurate information. Either they haven’t done any due diligence at all on their data source on plugin vulnerabilities, which would not put them in a good light, or what seems more likely, they know and don’t care. It’s not like no one has pointed out the problem with Wordfence using that data before, we did that back in May. The other option Wordfence could use is to check the information to make sure it is correct before passing it along to those using their plugin, but what we have seen repeatedly is they either don’t have the skills to do that sort of thing or are too lazy to do that.

If you are a customer of Wordfence’s you might want stop that since you are giving money to a company that doesn’t seem to have interest in really improving security, but you should at least contact them and let them know they should get behind the effort to get WordPress to properly handle alerting for removed plugins.

If you want accurate data on vulnerabilities in WordPress plugins you can get that with our service or in more limited form with the free data on vulnerabilities that are already being exploited that comes with the companion plugin for our service.

If you are using a plugin that isn’t being supported by the developer anymore, over at our main website we offer a service for taking over abandoned WordPress plugins, which includes doing a security review of it.

18 Sep

Neither ThreatPress’ Database Nor Any Other Contains All Known WordPress Plugin Vulnerabilities

When it comes to getting data on vulnerabilities that have been in WordPress plugins that are being used on a website you have two main options. You can pay for our service and gain access to the data that comes with that or there several free sources of vulnerabilities available that can be accessed through plugins (there are others selling access to that free data and other sources that provide limited data on plugin WordPress plugin vulnerabilities as part of more general vulnerability data).

The free data is good option for a lot of people because it is free, but as the old saying goes you get what you pay for. The quality and quantity of data is lacking in comparison to what we provide, so we wouldn’t recommend them for websites that have security needs that would warrant being able to spend money on security.

A problem that we have found is that there are people unintentionally or intentionally making claims that those free sources are in fact much better than they are. That obviously is problematic for us, since people might believe that they are not getting more when paying for access to data, but it also leaves people that use those sources believing that they are being provided better data than they really are.

In May we touched on a claim that the WPScan Vulnerability Database has the “the most complete list of vulnerabilities” in WordPress plugins and in July we further confirmed that to not be accurate as we found that we had added 3 times as many vulnerabilities as that source in the month of June.

Recently we ran across someone that was has repeatedly promoted another source of data, ThreatPress. One claim being made about that source stood out:

It includes all known vulnerabilities

Based on knowing what we do and checking on how others are doing (because we want to make sure we are providing the best data possible), we can say with complete certainty that no data source contains all known vulnerabilities in WordPress plugins.

One way quick way to measure the completeness of data is to look at how many newly disclosed vulnerabilities have been added to sources recently. To do that we took a look at how many vulnerabilities disclosed so far this month have been added to the data sets of ThreatPress, WPScan Vulnerability Database, and for us. Here are the results:

  • ThreatPress: 2
  • WPScan Vulnerability Database: 3
  • Plugin Vulnerabilities: 14

You can see there is a clear difference between what you are getting with a free source versus paying for access to our data. Even the 14 vulnerabilities we have in our data isn’t all of them this month, as there are several vulnerabilities that we are still in the process of reviewing before adding to our data set.

Looking at the vulnerabilities the other two sources are missing, a couple of things stood out.

One of them is that neither of the free sources have any of the 3 vulnerabilities we have added to our data set that have not been fixed, which seem like they would be important to include.

The other is that the majority of new vulnerabilities added in our data set so far this month are also vulnerabilities that we discovered, all of which are missing from those free sources, despite them being publicly disclosed at the same time we added them to our data set.

That second issue also gets to an important point about our service; our service isn’t just about collecting data on vulnerabilities disclosed by others as those other data sources incompletely do. Among other things, we are discovering vulnerabilities and helping to get vulnerabilities we and others have discovered fixed. Recently most of the vulnerabilities we have discovered have come from our proactive monitoring of changes made to plugins to try to catch serious vulnerabilities. Other sources are the security reviews we do of plugins selected by our customers and additional vulnerabilities we identify while reviewing reports of vulnerabilities that have been discovered by others.

28 Jul

We Actually Help to Get Vulnerabilities in WordPress Plugins Fixed

When it comes to the security industry surrounding WordPress one of the disheartening things we see is when companies that are doing harmful things, like making claims that WordPress is insecure in ways it isn’t, to sell their products and services are somehow praised for being focused on the community. When that happens companies are less likely to do things that would actually help everybody and instead focus on things that actual make the security situation worse. At this point it wouldn’t take much to help out improve the security of hundreds of thousands of websites.

We do rather extensive monitoring of reports of vulnerabilities in WordPress plugins to make sure we are providing the best data on WordPress plugins. One of the places we monitor is the WPScan Vulnerability Database because occasionally people will submit reports of vulnerabilities directly to them. Through that monitoring last week came across a report from another website of a reflected cross-site scripting vulnerability in the plugin WP Statistics. That is a type of vulnerability that is highly unlikely to be attempted to be exploited on the average website, but with 400,000 active installs according to wordpress.org, there is a decent chance that it might be installed on some website that would be targeted by hackers and there could be exploit attempts against those websites (the average website doesn’t face targeted attacks).

The report on the vulnerability didn’t make any mention of any attempt to contact the developer of the plugin and based on the quick response and resolution we saw when we reported a similar vulnerability we found to the developer several months ago, it seemed likely that hadn’t happened. When we contacted the developer this time we also got a quick response and several days later the vulnerability was resolved. The developer made it sound like no one else had notified them before us, despite the vulnerability already being included the WPScan’s data, which is used by numerous WordPress security products and services.

It would seem that the people behind the WPScan Vulnerability Database didn’t do notify the developer either as we received several follow up emails from the developer letting us know that the new version had been submitted to GitHub and the released on the Plugin Directory. So if the WPScan people had also notified the developer they would have known that this has been fixed. But as of now it is not listed as being fixed in their data, despite the fix being released four days ago (if it was, there would be a mention of that in the Affects section):

This isn’t a one off situation, as we have regularly found that developers have not been notified of publicly disclosed vulnerabilities in their plugins.

11 Jul

We Added Three Times As Many Previously Unknown Vulnerabilities as the WPScan Vulnerability Database Did Last Month

If you are getting vulnerability data on WordPress plugins from someone other than us it is likely coming from the WPScan Vulnerability Database. That this is the data source being used often isn’t disclosed and we have yet to see anyone put any proper disclaimer as to the quality of the data or that they are simply passing along unverified claims.

If you go back through previous posts we have tagged related to that data source you can see more about the issues that come with their data, but we thought another way of looking how we provide superior data (which is just one of the features of our service) and why anyone paying a security service shouldn’t be provided their data was to look at how we compared to them in adding previously unknown vulnerabilities to our data set last month. In doing that we spotted an improvement to our process to provide even better data (we have a post coming out soon about another recent improvement) and a reminder that others involved in disclosing vulnerabilities can do a better job.

The top line, which people would probably be most interested in, is that we added 43 previously unknown vulnerabilities to our data last month and WPScan Vulnerability Database only added 14. That works out to them having only added a third as many, 33%, vulnerabilities last month.

WPScan Missed the Most Serious Vulnerabilities

Quantity isn’t everything though. While much of the security industry seems to be all too willing to make minor vulnerabilities sound like big threats, the reality is that most vulnerabilities are of little threat to the average website. They would be of more concern for the small sliver of websites that are likely to be targeted by hackers, which is the kind of websites we see more as being ones that it makes sense to use our service.

In looking at the vulnerabilities added to both sources last month, two vulnerabilities, an arbitrary file upload and arbitrary file viewing vulnerability, in one plugin stand out. Both of these are ones that are likely to be targeted by hackers if they were aware of them. The vulnerabilities were fixed, but the developer didn’t change the version number when they made that change. That means that those that already updated to the latest version remain vulnerable (as well as anyone still running an older version). We notified the developer after spotting that problem, but nearly a month later the version number still hasn’t been changed. For those using our service, they were notified long ago and provided instruction to resolve this problem by uninstalling and then reinstalling the plugin. For those relying on the WPScan Vulnerability Database’s data, they are completely unaware of these vulnerabilities.

There really isn’t a good reason for WPScan Vulnerability Database to missing those vulnerabilities. While we found that the vulnerabilities had been discovered and fixed through our extensive monitoring, which we have seen no evidence that anyone else even comes close to doing, the people behind that data source (or anyone else since they accept public submissions) could have simply followed our blog and become aware of these vulnerabilities, but apparently doing that is too difficult.

Room for Improvement on Our End

Since we have pointed several major problems with WPScan’s data additions, it would be unfair not to point out where we were less than perfect. To do that let’s take a look at the vulnerabilities added to WPScan’s data last month and whether we included them.

Also Included

10 of the 14 vulnerabilities they added were also added to our data during the month:

The last vulnerability listed there though is a good reminder of one of the quality issues with WPScan’s data. While their data lists the vulnerability as having been “fixed in version 4.6.5”, in truth it wasn’t fixed in that version or even fixed at the time they listed it as having been fixed. As we noted at the time, we notified the developer of the disclosure of the unfixed vulnerability and it was fixed shortly after that. If not for us the vulnerability likely would still be in the plugin.

Not Really a Vulnerability

Two of the reported vulnerabilities they included are ones that we were aware of but did not included in our data since they really are not vulnerabilities:

For Photo Gallery by WD, we already discussed the reason for the lack of inclusion.

For WP Jobs, access to the relevant page is restricted to those with the edit_themes capability, which would normally be Administrators, so this really wouldn’t be a vulnerability since Administrators normally already have the ability to do the equivalent of this. There is the possibility of related type of vulnerability that we have started to add to our data for which that plugin should be listed, which we will be discussing in an upcoming post.

Missed Vulnerabilities

Finally two vulnerabilities that actually existed that we were aware of but had not included in our data as of last month (they are now included):

For WP-Testimonials, the vulnerability was listed by the discoverer as being exploitable by an “authenticated user”, that is, someone logged in to WordPress. What was missing and often is missing from reports is what level of access a user has to have to exploit the vulnerability. That obviously makes a big difference, since most potential vulnerabilities are really not vulnerabilities if only accessibly by Administrators since among other things, they normally can edit plugins and remove any security protection.

In the case of this vulnerability it was normally only accessible by Administrators, but what we originally missed is that the plugin allows changing what users had access to the relevant page, so we should have listed it. We normally do check for that, but in preparing this post we realized a better way to do that. Instead of trying to look through a plugin’s settings, the better way to check for that is to look at the underlying code. In this instance when we went to write up this post we noticed the relevant code registering the vulnerable page listed the variable “$sfs_admng” as the capability need to access it:

add_menu_page('Testimonials', 'Testimonials', $sfs_admng, 'sfstst_manage', 'sfstst_adminpage', plugins_url('/wp-testimonials/sfstst_icon.png'));

When we went to look at what was used to specify that value we could see that it could be set from an option (setting):

if (get_option('sfs_admng') == '') { $sfs_admng = 'update_plugins'; } else {$sfs_admng = get_option('sfs_admng'); }

For WP Live Chat Support, the reason for our lack of earlier inclusion is the discloser had not provided enough information in their report to verify the vulnerability without us doing additional work. Doing that for this particular vulnerability got overtaken by other items that we needed to deal with. In this case though WPScan’s inclusion didn’t really provide their user with a better situation since when we got a chance to look into the details of the vulnerability we found that it had only been fixed in one of two locations it occurred. After we spotted that we notified the developer and it has now been resolved, so those relying on WPScan’s data and keeping their plugins up to date are protected despite not being told of what versions were really impacted.