Earlier today we announced we are changing how we handle the disclosure of vulnerabilities in WordPress plugins. Until the inappropriate behavior by the moderators of the WordPress Support Forum ends we are going to be doing full disclosure, that is just disclosing the vulnerabilities, and after that only notifying the developer of the plugin through the Support Forum. We hope that this will be the thing that finally causes the current moderators and or other people in charge of WordPress to understand that they need to clean up the moderation, because it is causing many more problems than these full disclosures will.

We thought it would be a good idea to start these full disclosures off with a bang by disclosing a vulnerability in a very popular plugin, one with 700,000+ active installations according to wordpress.org. The type of vulnerability being disclosed though has almost no chance of being exploited on the average website, unless you were to believe the misinformation put out by other security companies.

Last week as part of our monitoring of indications of changes being made to WordPress plugins we ran across the changelog entry for the latest version of the plugin FV Flowplayer Video Player, which read “Security – adding nonce for the Shortcode Editor preview”. Looking at the changes made in that version and the other code related to the changed code in the plugin though we couldn’t understand what the vulnerability there would be. A nonce is used to prevent cross-site request forgery (CSRF), which is when you cause someone to take an action they didn’t intend to. The problem was we didn’t see anything that would happen when the relevant code would run that seemed to need CSRF protection.

The closest thing was this line of code:

239

echo do_shortcode($shortcode);

That would allow someone to cause a specified shortcode to run, which wouldn’t really be what we would consider an issue with the plugin since you can do the same thing through WordPress itself. In looking over the code we also thought there might be a reflected cross-site (XSS) issue somewhere, but we didn’t find one.

The next day though we could see what we missed when the discoverer of the issue, Janek Vind, released a report on it. It turned out the line of code above could cause reflected XSS to happen.

After seeing that we were interested in seeing about adding a new check to our automated tool for detecting possible security issues in WordPress plugins, the Plugin Security Checker, to catch some instances of that issue. To get a better idea of what be might out there when it comes to this type of issue we did some checking of the 1,000 most popular WordPress plugin in the Plugin Directory.

When we did that we found this line in the plugin Shortcodes Ultimate:

187

echo do_shortcode( str_replace( '\"', '"', $_POST['shortcode'] ) );

That certainly looked like it might be exploitable, especially due to its use of strip slashes, which could eliminate an impediment to that being exploitable.

Looking at where it was located made that seem more likely. That code exists in the function preview() in the file /inc/core/generator.php:

public static function preview() {
	// Check authentication
	self::access();
	// Output results
	do_action( 'su/generator/preview/before' );
	echo '<h5>' . __( 'Preview', 'shortcodes-ultimate' ) . '</h5>';
	// echo '<hr />' . stripslashes( $_POST['shortcode'] ) . '<hr />'; // Uncomment for debug
	echo do_shortcode( str_replace( '\"', '"', $_POST['shortcode'] )

That function is accessible to anyone logged in to WordPress through WordPress’ AJAX functionality:

add_action( 'wp_ajax_su_generator_preview',        array( __CLASS__, 'preview' ) );

Once we saw that, it was easy to craft a proof of concept, as shown below, that confirms the vulnerability is exploitable. Though again, this type of vulnerability is very unlikely to exploited on the average website.

Even prior to this disclosure the Plugin Security Checker had been updated to catch the possibility of this vulnerability, so it would have been relatively easy to spot it already. Whether we needed to change our disclosure policy when it comes things are able to be identified by that tool was something we considering before making the change in the disclosure policy (and we will need to return to that once we can return to the our old disclosure policy).

Update (9/27/18): Incredibly, while the moderators deleted our message to notify the developer of the issue, they didn’t bother to notify the developer of the issue. Once the developer got notified, they quickly took action. It really speaks to the moderators inability to act appropriately that they would choose to delete the notification and then not doing anything else.

Proof of Concept

The following proof of concept will cause any available cookies to be shown in alert box when logged in to WordPress. Major web browsers other than Firefox provide XSS filtering, so this proof of concept will not work in those web browsers.

Make sure to replace “[path to WordPress]” with the location of WordPress.

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin-ajax.php?action=su_generator_preview" method="POST">
<input type="hidden" name="shortcode" value='"><script>alert(document.cookie);</script>' />
<input type="submit" value="Submit" />
</form>
</body>

Concerned About The Security of the Plugins You Use?