01 Sep

What Happened With WordPress Plugin Vulnerabilities in August 2017

If you want the best information and therefore best protection against vulnerabilities in WordPress plugins we provide you that through our service.

Here is what we did to keep those are already using our service secure from WordPress plugin vulnerabilities during August (and what you have been missing out on if you haven’t signed up yet):

Plugin Security Reviews

Customers of the service can suggest and vote on plugins to have a security review done by us. This month we released details for a review of:

We don’t currently have any more plugins queue up for a review, so if you sign up now for the service, a plugin you suggest could be reviewed right away.

Plugin Vulnerabilities We Discovered and Publicly Disclosed This Month

We don’t just collect data on vulnerabilities in plugins that others have discovered, we also discover vulnerabilities through proactive monitoring of changes made to plugins, monitoring hackers activity, reviewing other vulnerabilities, and by doing additional checking on the security of plugins.

This month the most concerning vulnerability is a PHP object injection vulnerability in WP Smart Security, since that type of vulnerability is likely to be exploited and the vulnerability hasn’t been fixed yet.

Plugin Vulnerabilities We Helped Get Fixed This Month

Letting you know that you are using a vulnerable version of plugin is useful, but it is much more useful if you can fully protect yourself by simple updating to a new version. So we work with plugin developers to make sure that vulnerabilities get fixed. This month we helped to get vulnerabilities fixed in plugins that have 177,800+ active installs:

Plugin Vulnerabilities Added This Month That Are In The Current Version of the Plugins

Keeping your plugins up to date isn’t enough to keep you secure as these vulnerabilities in the current versions of plugins show:

Additional Vulnerabilities Added This Month

As usual, there were plenty of other vulnerabilities that we added to our data during the month. Most of the new vulnerabilities that were fixed this month are relatively minor.

24 Aug

Authenticated Persistent Cross-Site Scripting (XSS) Vulnerability in FG Joomla to WordPress

While looking into an unrelated issue with the plugin FG Joomla to WordPress, we found that it contained an authenticated cross-site scripting (XSS) vulnerability.

The plugin has a number of actions that are run through the function ajax_importer(), which is accessed through WordPress’ AJAX functionality and is accessible to anyone logged in to WordPress (/includes/class-fg-joomla-to-wordpress.php):

184
$this->loader->add_action( 'wp_ajax_fgj2wp_import', $plugin_admin, 'ajax_importer' );

The function ajax_importer() located in the file /admin/class-fg-joomla-to-wordpress-admin.php didn’t do any capabilities check. For most actions that function passes the action request to the function dispatch():

228
$result = $this->dispatch($action);

In the function dispatch(), also located in the file /admin/class-fg-joomla-to-wordpress-admin.php, most of the actions check for a valid nonce, so under normal circumstances only Administrators could access them. One of the exceptions was saving the plugin’s settings:

307
308
309
310
311
// Save database options
case 'save':
	$this->save_plugin_options();
	$this->display_admin_notice(__('Settings saved', 'fg-joomla-to-wordpress'));
	break;

In addition, for other actions the saving of the settings also occurs and it occurred before the nonce check:

313
314
315
316
317
318
// Test the database connection
case 'test_database':
	// Save database options
	$this->save_plugin_options();
 
	if ( check_admin_referer( 'parameters_form', 'fgj2wp_nonce' ) ) { // Security check

The lack of a nonce check would also allow for cross-site request forgery (CSRF) to occur.

Before the settings are saved there is validation done, but for the “url” setting the sanitization done doesn’t prevent cross-site scripting (XSS):

937
$url = filter_input(INPUT_POST, 'url', FILTER_SANITIZE_URL);

Using FILTER_SANITIZE_URL will:

Remove all characters except letters, digits and $-_.+!*'(),{}|\\^~[]`<>#%”;/?:@&=.

That leaves the characters needed for cross-site scripting.

After we notified the developer of the issue they fixed each of the issues in version 3.31.0 .

They added a capabilities check:

211
212
213
public function ajax_importer() {
	$current_user = wp_get_current_user();
	if ( !empty($current_user) && $current_user->has_cap('import') ) {

They added a check for a valid nonce when using the save action (as well moving the saving of settings for other actions after the nonce check):

311
312
313
case 'save':
	if ( check_admin_referer( 'parameters_form', 'fgj2wp_nonce' ) ) { // Security check
		$this->save_plugin_options();

And added passing the “url” setting through the esc_url() function:

944
$url = esc_url(filter_input(INPUT_POST, 'url', FILTER_SANITIZE_URL));

Proof of Concept

The following proof of concept will cause an alert box with any accessible cookies to be shown on the page /wp-admin/admin.php?import=fgj2wp, when submitted while logged in to WordPress.

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" method="POST">
<input type="hidden" name="action" value="fgj2wp_import" />
<input type="hidden" name="plugin_action" value="save" />
<input type="hidden" name="url" value='"><script>alert(document.cookie);</script>' />
<input type="submit" value="Submit" />
</form>
</body>
</html>

Timeline

  • August 23, 2017 – Developer notified.
  • August 23, 2017 – Developer responds.
  • August 24, 2017 – Version 3.31.0, which fixes the vulnerability.