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.

13 Jun

Automattic Seems More Committed to Marketing Their Jetpack Service Than to a Safer WordPress Experience

For years WordPress has been knowingly leaving websites at risk of being hacked due to a refusal to warn when plugins are in use that known to be vulnerable and have been removed from the Plugin Directory due to that fact. Considering the damage that is caused by this and there not being any reasonable argument for not warning people, at times when removed plugins have been widely exploited we have started to wonder if this might not be due to gross negligence, but if there might be a more nefarious explanation.

The company closely associated with WordPress, Automattic, does have a several products marketed as security products, Jetpack and VaultPress, so allowing websites to be hacked to help those services could be an explanation, though we highly doubt it. That being said Automattic doesn’t seem to have the best interest of the public when it comes to security. For example, they have helped other security companies in pushing the false notion that there are many brute force attacks against WordPress admin logins, which takes the focus away from real security threats like unfixed vulnerable plugins.

While looking for something for another post we ran across something that relates to the issue of those removed plugins. On the Jetpack website they have a set of pages on the security of WordPress plugins named the WordPress Security Library. There they give the public information that WordPress has been refusing to. For example, they warn that plugin Form Lightbox is unsafe:

 

 

That refers to an option update vulnerability that exists in that plugin.

In explaining these pages in another in this section of the page, there is the following text:

About this information


This WordPress security information is part of our security library and is brought to you by Jetpack as part of our committment to a safer WordPress experience.

If you have any questions, please do not hesitate to contact us.

What isn’t mentioned there (as is so often is the case) is the source of that data, which is pretty clearly the WPScan Vulnerability Database. If you follow our blog, you would already be aware of the serious issues that come with the use of that source. As example of that, the plugin Downloads Manager is listed as being “Good” and the “current version safe”:

There is an indication there that it might not be, as they are not showing the name of the plugin instead its slug, “downloads-manager”, which seems to be because the plugin has been removed from the Plugin Directory. The reason for that is that the most recent version of the plugin has an arbitrary file upload vulnerability, which we discovered after we saw hackers targeting the plugin. That vulnerability isn’t in WPScan Vulnerability Database, as is the case with many very exploitable vulnerabilities we have discovered and publicly disclosed.

Even when WPScan has data on a vulnerability the Jetpack website isn’t always accurately presenting it (this seems to be a frequent issue with services and products reusing their data). For the plugin Delete All Comments they also list it as being “Good” and the “current version safe” despite the fact that they list a vulnerability being in up to version 2.0, which is the most recent version:

 

So Automattic is presenting bad information to those looking at this section of the website, but what makes this all the more troubling is that right below the “Safety Recommendations” section of these pages is two sections advertising their service:

So their commitment seems less to the safety of WordPress, seeing as they haven’t joined us in trying to finally get WordPress to warn about removed vulnerable plugins, and more to promoting their service using someone else’s data without disclosing that.

It is also worth noting that if their “Regular, automated scans of your site for malware, threats, and hacks.” are also using the WPScan Vulnerability Database’s data then you their customers are going to be unaware of many vulnerabilities, like the one in Downloads Manager, so if you are actually interested in protecting against vulnerable plugins then you should at least install the companion plugin for our service, since we list in the free data that comes with that, vulnerabilities like the one in Downloads Manager. For more complete data, as well the ability to vote/suggest plugins to receive a security review from us and helping us to further improve the security of WordPress plugins, sign up for our service.

01 Jun

DefenseCode and WPScan Vulnerability Database Falsely Label Unfixed Vulnerability as Being Fixed

A little over a month ago we put out a warning to be wary advisories from the company DefenseCode after our interaction with them regarding an issue with one of their advisories. In that instance their report claimed that they had contacted the developer of a plugin about a vulnerability that had been fixed in the plugin before they claim to have even first contacted the developer about it, which was odd. There was also this odd line:

Vendor did not respond to our repeated attempts to send this advisory. All users are strongly advised to update WordPress AccessPress Social Icons plugin to the latest available version.

What would have been the purpose of updating the plugin if the vulnerability hadn’t been fixed?

Yesterday they released a report of vulnerabilities in the plugin Newsletters. Once again when we went to review this before adding it to our data things didn’t add up.

The solution section reads as follows:

Vendor resolved the security issues after we reported the vulnerabilities. All users are strongly advised to update WordPress Tribulant Newsletters plugin to the latest available version.

So the vulnerability was supposed to be fixed, but in what version? It wasn’t directly stated anywhere, but at the beginning of the advisory it listed “Versions” as “4.6.4.2 and below”.

The timeline provided didn’t match that though. Here is the timeline provide:

2017/04/04 Vendor contacted
2017/04/06 Vendor responded, update released
2017/05/29 Advisory released to the public

Looking at the development log for the plugin you can see that the next version after 4.6.4.2, 4.6.5, was released on January 26, 2017. Which is well before they claim to have contacted the developer. So maybe it was fixed in a later version? The problem with that being true would be that the most recent change made was on March 29, which is before they claim to have contacted the developer.

Looking at the changelog for version 4.6.5 we found two entries that might be related to one of the claimed issues, a “file disclosure” vulnerability:

  • IMPROVE: Sorry, this file type is not permitted for security reasons
  • IMPROVE: More secure permissions on export files

In testing the first few examples listed in the advisory in version 4.6.4.2 we found them exploitable and then we found them still exploitable in 4.6.5. In fact we found that in the current version they still are exploitable. After discovering that we promptly notified the developer and we received this response early today:

We are currently checking and will confirm whether or not it has been resolved.
If not, we will release an update later today still with escaped data.

From that it isn’t clear if the developer had intended to fix it before and didn’t (there doesn’t appear to be any change related to the issues in version 4.6.5 or a later version) or if there had never been an attempt. If DefenseCode had actually contacted the developer and was told it was fixed they should have checked to make sure the vulnerability was in fact fixed, because we often find that developers mistakenly think they have fixed vulnerabilities when they haven’t.

It also worth noting here that the “file disclosure” vulnerability listed in the advisory doesn’t appear to be a vulnerability as it would only be exploitable by Administrator-level users that would normally be able to accomplish what that does with their permitted capabilities, by say installing a plugin that allows browsing files.

For those using our service they have already been notified by now if they are vulnerable and given instructions on how to get in touch with us if they wanted help with dealing the situation, where they are using a plugin that has a vulnerability in the latest version of it.

For those instead relying on a service or a plugin that uses data from the WPScan Vulnerability Database, as often is the case they would be getting lower quality information as they have added the vulnerability today, but are claiming that it was fixed back in version 4.6.5:

This is yet another reminder of the importance to double check that any vulnerabilities that the WPScan Vulnerability Database’s data is claiming have been in your plugins and have been fixed have in fact been fixed. Or just use a service that does that in the first place. Making things more problematic, providers using their data often don’t disclose it is the true source of their data and or provide a disclaimer as to the quality issues that come with their data.

25 May

The WPScan Vulnerability Database Doesn’t Contain the Most Complete List of WordPress Plugin Vulnerabilities

When it comes to the problem with security one of the issues that underlies a lot of it is lack of evidence based claims, whether the claims come from the security industry or the public. When coming from the security industry it looks like a lot of that is knowingly false, for example claiming that a service would protect websites from being hacked while the services actual function is to try to detect that the website has been hacked after it has been hacked.

A recent example of a claim from the public that isn’t backed by evidence involves an odd situation mentioned in the post on our recent security review of a plugin where the plugin, which is for protecting against spam, is checking if the installed version of WordPress has security vulnerabilities. We don’t understand why that functionality is in the plugin, but in doing that the plugin sends information that sometimes wouldn’t be publicly known to the website wpvulndb.com. In trying to explaining why it is checking for vulnerabilities in the installed version of WordPress the developer of the plugin made this claim:

The WPScan Vulnerability Database (wpvulndb.com) is legit, and is one of the best resources out there for WordPress security as it contains the most complete list of vulnerabilities for WordPress, Themes and Plugins.

No evidence is cited for that claim and from our own experience when it comes to plugins that isn’t back up by what we have seen. We know this not only because we on occasion check competing data sources to make sure we provide the best data on vulnerabilities in plugins to our customers, but also because we monitor this data source as part of our extensive monitoring for information on plugin vulnerabilities, as on occasion vulnerabilities are submitted directly there (most of their data comes from third-parties).

From doing that we know that many vulnerabilities that we have discovered, including many that hackers either were already or very likely to exploit in the future are not included. Considering that we discover quite a few of the vulnerabilities that on its own would be a problem with being the most complete list, but in occasions when they have added vulnerabilities we have discovered, there have been indications that they have spotty inclusions of vulnerabilities they are even aware of, as in two instances we looked into where we had disclosed multiple connected vulnerabilities at once (four in one instance and five in the other) they only included one of the vulnerabilities in each instance. We looked into those situations because we were trying to understand what led them to include those ones and not the others, but we couldn’t fix an explanation, so it looks like they just are not very thorough.

Simply having more vulnerabilities in your data set though isn’t necessarily better though, as the quality of your data also matters. That is where WPScan Vulnerability Database has serious issue because they usually don’t verify the vulnerabilities as we always do. That leads a number of problems, including them listing false reports of vulnerabilities in their data and claiming unfixed vulnerabilities are fixed. That latter issue seems rather important since knowing if you are using a vulnerable seems to be the most important use for this type of data, it also means you would need to double check any vulnerabilities they claimed are fixed (or you could use a service that actually does that for you).

There are two takeaways from that. First, when you see claims made about security you should look if there is evidence that supports the claims presented. If you don’t, the claim should probably be assumed to not be known be true. When evidence is present, if possible, you would want to check over the evidence presented, because we have found that in some of the few instances where it is provided, it has been manipulated. Second, if you are going to recommend relying on data from the WPScan Vulnerability Database it is important to note its limitations. We actually think it is a good source for a lot of people because its data can be accessed for free, but you get what you pay for and those relying on it should really be aware of its limitations.