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.

01 Nov

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in Pretty Links (Lite)

Earlier today we posted the details of a reflected cross-site scripting (XSS) vulnerability in the plugin Pretty Links (Lite) that was somewhat vaguely disclosed by Detectify about a month ago. Shortly after that had been disclosed the website WPCampus had included reference to that in their weekly spreadsheet of vulnerabilities in WordPress, though they pointed to information on a possible different ...


To read the rest of this post you need to have an active account with our service.

For existing customers, please log in to your account to view the rest of the post.

If you are not currently a customer, when you sign up now you can try the service for half off (there are a lot of other reason that you will want to sign up beyond access to posts like this one).

If you are a WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.

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.

28 Sep

WPCampus Failing to Credit Us and Spreading Inaccurate Information on WordPress Plugin Vulnerabilities

One of the many issues we have noticed when it comes to information on WordPress security you can find on the web is that often the original source of information is not being credited in articles written about issues. We have seen plenty of that happen not just to us, but to many others as well. That credit can be an important reward for doing things like discovering new vulnerabilities, which otherwise have little return. Another issue that comes with that is that we frequently see that the subsequent articles have inaccuracies, sometimes major, which without the possibility of seeing the original are more likely to be repeated subsequently.

As example of where that credit can have an impact, we recently had someone sign up for a free trial of service that originally came to our website from the page Vulnerable WordPress Plugins Report for the Week of September 1, 2017 on the WPCampus website.

In looking over that page we noticed that what was written about us was wasn’t entirely accurate. Here is what was written:

 Also disclosed this week were PHP Object Injectionvulnerabilities in the plugins JayJ Quicktag,VideoWhisper Live Streaming and WP Smart Security (currently unfixed).  All three were discovered by researchers at pluginvulnerabilities.com utilizing the php-grinder.com service. PHP-Grinder is a static analysis tool designed specially to scan WordPress plugins and PHP-based GitHub projects for potential security vulnerabilities.

We are not sure where the claim that all three of the vulnerabilities were found using php-grinder.com. If that post had linked to our posts for the vulnerabilities, people could have seen that we linked to php-grinder.com as a source for the one in WP Smart Security. For the other two we didn’t link to it because it wasn’t a source. That really isn’t a big issue, but as we started looking around we saw larger issues.

(Also worth noting, unlike the writer of the post, we didn’t find the data presented by that website to be of much value.)

Sources Lacking

On the post Vulnerable WordPress Plugins Report for the Week of September 22, 2017 the first paragraph reads as follows:

The critical disclosure this week is an Arbitrary File Upload vulnerability in the plugin All Post Contact Form.  It appears that the plugin doesn’t do any checking on the file type that is being uploaded and saves it to the uploads directory. This means an attacker could upload a backdoor script to your site and then access it in your site’s /wp-content/uploads/ directory.  If you remember back to my Access Denied presentation, this scenario is precisely why I suggest denying access to all file types in the uploads directory except for those you specifically want the public to have access to.  It is highly recommended that you remove this plugin immediately.

From that you wouldn’t have any idea we were the discoverer and discloser of the vulnerability. While there are three links in the paragraph none of them are to our post. That seemed odd to us.

The second paragraph again doesn’t mention us, but it reads a lot like something that was written based off of a post we wrote a week before:

While not in the report this week, I came across a google dorkentry in exploit-db.com that targets the .user.ini file generated by  the WordFence plugin.  The .user.ini file contains a full path listing to the wordfence-waf.php file.  By default, the plugin should include an entry in the site’s .htaccess file to deny access to this file.  In addition, it should warn nginx user’s to include an entry in their configuration file.  However, it doesn’t appear that the plugin verifies an .htaccess file is actually in use, or that the nginx configuration has been made.  IIS users are simply out-of-luck with no warning or instructions on how to deny access to the file.  A quick search shows that there are quite a few sites out there using Wordfence with no protection against disclosing this information.   Now, the disclosure of the full path by itself won’t compromise your site. However, this information can be used in combination with other attacks that require knowing the server path.  Regardless, if you use Wordfence, I would suggest checking your site to see if you can access the .user.ini file.  If so, make sure to add the configuration changes needed in order to block it from public access. If you run into issues figuring out how to do so, reach out to me and I’ll assist.

The post Vulnerable WordPress Plugins/Themes Report for the Week of August 25, 2017 is entirely based on a vulnerability we discovered and disclosed, but once again there is no mention of us or link to our post in their post.

Citing Your Sources

Beyond any common courtesy, seeing as WPCampus is focused on higher education you would expect that what is on their website is in keeping with higher education’s standards when it comes to sourcing.

As an example of that, which popped up at the top of search results when went looking for example of that standard, here is what UC Berkeley says:

Whenever you quote or base your ideas on another person’s work, you must document the source you used. Even when you do not quote directly from another work, if reading that source contributed to the ideas presented in your paper, you must give the authors proper credit.

Citations allow readers to locate and further explore the sources you consulted, show the depth and scope of your research, and give credit to authors for their ideas. Citations provide evidence for your arguments and add credibility to your work by demonstrating that you have sought out and considered a variety of resources. In written academic work, citing sources is standard practice and shows that you are responding to this person, agreeing with that person, and adding something of your own. Think of documenting your sources as providing a trail for your reader to follow to see the research you performed and discover what led you to your original contribution.

That clearly hasn’t happened here.

The WPCampus website prominently links to a code of conduct, which makes no mention of handling sourcing, so maybe they don’t care about it.

More Questionable Sourcing

While the posts are titled reports of vulnerabilities in plugins for a given week, if you actually want to see the vulnerabilities for a week you can have to look at a separate Google Sheets page. Looking at the one for last week we noticed another instance of questionable sourcing. The entries for Welcart e-Commerce and Invite Anyone are sourced to changeset entries, which don’t mention the vulnerabilities in question. It is possible the person behind these post noticed those all by themselves, but since we know they are looking at our blog, it seems plausible that a partial source was our plugin details posts about those vulnerabilities, which we spotted through our proactive monitoring of serious vulnerabilities being included in changes made to plugins (which it turns out can also spot vulnerabilities being fixed). That is a minor issue in comparison to the other issue we noticed in that spreadsheet.

Inaccurate Version(s) Affected

One of the things we tout about our service is that we are the only data source that tells you which version of plugins are vulnerable.  That can be rather important information in certain instances. Let’s say you are dealing with a hacked website with very out of date plugins, which is common. With our data you might be able to see that a vulnerability has existed in some older versions of the plugin, but didn’t exist in the version in use on the website. With other data sources you wouldn’t know that, so you might believe that was the source of the hacking and only later find out it wasn’t when the website has been hacked again.

If you were to look at the spreadsheets from WPCampus you would think that you could get that information from them as well, but it turns the information is not accurate.

Staying with the entries from last week, many of the entries have a range of affected versions like the one for a PHP object injection vulnerability in Invite Anyone, which states that “1.3.18 and earlier”. That vulnerability was introduced in version 0.8, so versions earlier than that didn’t contain it.

It isn’t a situation where the person behind this is simply listing that older versions are vulnerable, as the entry for a reflected cross-site scripting (XSS) vulnerability in 2kb Amazon Affiliates Store list that only version “2.1.0” is affected. When in fact all previous version were affected. We don’t know where the idea that it impacted less versions comes from since the discoverer of the vulnerability lists it as impacting versions “2.1.0 and below“.