10 Nov

Not Really a WordPress Plugin Vulnerability – Week of November 10, 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.

SQL Injection Vulnerability in Simple Events Calendar

With a claimed SQL injection vulnerability in the plugin Simple Events Calendar the claim seems shaky before even getting in to the details as it is stated that “Type user acces: administrator user.” If a vulnerability has to be exploited by an Administrator it likely isn’t a vulnerability, since those users normally have the ability to do almost anything (including editing a plugin to remove security code or adding another plugin that can take the action that could be done through the vulnerability).

Where there still could be an issue is with cross-site request forgery (CSRF), which causes a user to take an action they didn’t intend to. The plugin doesn’t include protection against CSRF before the claimed vulnerable code runs, which ends up being part of a real vulnerability we saw while reviewing this claimed vulnerability (and we will disclose that after the developer has had a chance to fix it). With the type of SQL query in claimed vulnerable code that could mean there is a vulnerability if the value of a GET input is involved (which is something we really should have put up a post on by now), but in this case the value involved is from a POST input:

312
313
$edit_event = $_POST['event_id'];
$update = $wpdb->get_results(" SELECT * FROM $table_name WHERE id = $edit_event ", "ARRAY_A");

Since an attacker can’t get back the result of the query in through CSRF in this situation, there isn’t a vulnerability there. While there isn’t a vulnerability, the code could be improved by using a prepared statement and validating the input (since it should only be an integer).

The person behind the claim stated that “Vendor no finded”. We are not sure what that means as the developer’s website is listed both on the plugin’s page on the Plugin Directory and in a couple of place in the WordPress admin area when the plugin is installed. We have notified the developer of the disclosure and the possible improvements.

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.

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.

06 Oct

Not Really a WordPress Plugin Vulnerability – Week of October 6, 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.

Reflected Cross-Site Scripting (XSS) Vulnerability in Google Doc Embedder

Earlier today we mentioned that there are a number of issues with the Plugin Directory’s reviewing plugins before they return to the directory, which is one of many issues that seems like it could be improved if the people behind that were more open about what they are doing and able incorporate outside suggestions for improvement. Another area that seems like it might be improvable based on what is describe below, is deciding when to remove plugins.

The plugin Google Doc Embedder was recently removed from the Plugin Directory and the maintainer of the plugin wrote this about why that occurred:

There was a security alert whereby it appeared a cross-site scripting attack could have been carried out. This was inside a file that was no longer in use so it has just been removed from a new version 2.6.3 that should be released shortly.

Looking at the changes made to the plugin the file referred there was /js/tb-newwin.php. If you were to just look quickly at the code there is what appear to be a reflected cross-site scripting (XSS) vulnerability in it.

First the value of a couple of GET inputs are set to variables without being sanitized:

16
17
18
19
if ( isset( $_GET['url'] ) ) {
	$url = $_GET['url'];
	if ( isset( $_GET['hl'] ) ) {
		$lang = $_GET['hl'];

And then those variable are output without being escaped:

96
thisIFrame = "https://docs.google.com/viewer?url=" + "<!--?php echo $url; ?-->*chrome=true&hl=<!--?php echo $lang; ?-->";

If you were to test out exploiting this, which seems to be a step that is too often not done when checking on possible vulnerabilities, you would find that it doesn’t work. The reason for that is that the file set the content-type to “text/javascript”:

27
header("Content-type: text/javascript");

That would prevent JavaScript code from running. If a web browser could be tricked into believing that the page being served was actually a different content type than what is specified JavaScript code could run. That seems to have been more of a possibility with some older versions of web browsers. Since the page would contain a fair amount of content other than what comes from the reflected cross-site scripting (XSS), it might not be possible in that situation. So while it was good to resolve this, it seems questionable to have removed the plugin for it.

22 Sep

Not Really a WordPress Plugin Vulnerability – Week of September 22, 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.

Reflected Cross-Site Scripting (XSS) Vulnerability in Shibboleth

The claimed reflected cross-site scripting (XSS) vulnerability that had been in the plugin Shibboleth is good example of why the lack of testing done for claimed security issues can lead to missing important limitations surrounding them. We first came across the claimed vulnerability when the WPScan Vulnerability Database added the claimed vulnerability, which they didn’t verify before adding to their data set. They cited two references, one being a security improvement change made to the plugin in March of 2016 and the other a discussion on the Debian mailing list. That discussion makes mention of waiting for “real world testing”, but there is no mention of it being completed.

When we did just that type testing before adding this vulnerability to our data set we found that reflected cross-site scripting (XSS) wouldn’t occur. In looking at the underlying claims behind the claim of a vulnerability in this plugin, we found that both the WordPress team and the security company Sucuri (which is part of GoDaddy) had failed to note important limitation with the potential security issue at issue here. Sucuri’s posting about the underlying issue is missing even basic technical details, which if included, might have allowed someone point out that they were overstating the issue (they have a history of doing that sort of thing and worse).

WordPress’ posting on this is better as it provides an important detail which gets to the limitation:

Both add_query_arg() and remove_query_arg() have an optional argument to define the base query string to use. If this argument is undefined, it will use $_SERVER['REQUEST_URI'], which is unescaped. When printed out to a page, this could be used as an XSS attack vector.

The claim that $_SERVER[‘REQUEST_URI’] is unescaped is partially true. While there isn’t any escaping of that done by PHP or WordPress, the value would normally be encoded due to URLs being encoded when sent from web browsers. That would act as escaping. That would normally mean that reflected cross-site scripting (XSS) could not occur due to this issue.

The change made to plugin makes sense since it makes sure the issue couldn’t be a problem and doing that change in general when using the add_query_arg() and remove_query_arg() make sense since when the result of them is used in a different way than this plugin did, it could cause an exploitable vulnerability.

01 Sep

Not Really a WordPress Plugin Vulnerability – Week of September 1, 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.

SQL Injection Vulnerability in Photo Gallery by WD

In the report for a claimed SQL injection vulnerability in Photo Gallery by WD it is stated that access to the vulnerability is limited:

Additional: function bwg_edit_tag() has a checking about user permission, so administrator permission is required to trigger this vulnerability.

Checking the code, it specifically requires the “manage_options” capability, which normally only Administrators have and if others had the capability they normally would be able to create Administrator accounts using what that capability provides:

208
209
210
function bwg_edit_tag() {
  if (function_exists('current_user_can')) {
    if (!current_user_can('manage_options')) {

On its own this really isn’t a vulnerability since among other things, Administrators could normally remove any security protection in a plugin. With the information provided it sounded possible that the vulnerability might be exploitable through cross-site request forgery (CSRF), which can cause someone to take an action they didn’t intend to. Though looking several lines further in to the function bwg_edit_tag() shows that there is in fact a check to prevent that from occurring:

218
219
220
  if (!WDWLibrary::verify_nonce('')) {
    die('Sorry, your nonce did not verify.');
  }

Worth noting is that while many fixes for real vulnerabilities don’t get mentioned in changelog the change made related to this was, “Fixed: Security issue”. The change made was to use a prepared statement for SQL statement, which would have fixed this if there really was a vulnerability and doesn’t hurt to have done anyway.

23 Jun

Not Really a WordPress Plugin Vulnerability – Week of June 23, 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 detailing those issues.

Authenticated Arbitrary File Viewing Vulnerability in Photo Gallery

The title of the report, “Path traversal in Photo Gallery may allow admins to read most files on the filesystem” seems to explain the issue well as only Administrators (or more accurately those with the “manage_options” capability) were able to take advantage of the issue and normally not only could they edit the plugin to remove protection against the issue, but they also could just install another plugin that could do what the issue in this plugin would have allowed.

Reflected Cross-Site Scripting (XSS) in Facebook Members

The claimed reflected cross-site scripting (XSS) vulnerability involves the value of the variable $_SERVER[REQUEST_URI]. That value is normally URL encoded by a web browser, so normally outputting it unescaped could not permit XSS. It would probably be more accurate to describe this type of issue as a possible vulnerability.