Yesterday we ran across a vague claim that the WordPress security plugin WordPress HTTPS, which has 50,000+ installs, might have a security vulnerability that is involved in hacks of website. The source isn’t a reliable one (despite being the developer of a popular security plugin) and they didn’t provide any information to back that up. In checking over the plugin, we quickly found a reasonably serious vulnerability, though one that seems unlikely to be connected with the hacking claim being made.

We tested and confirmed that our firewall plugin for WordPress protected against the vulnerability even before we discovered it, as part of its protection against zero-day vulnerabilities.

The plugin registers its functions that handle saving and resetting its various settings to be accessible through WordPress’ AJAX functionality. The registration for its function for its URL filtering settings is done with these lines in the file /lib/WordPressHTTPS/Module/UrlMapping.php:

23
24

add_action('wp_ajax_' . $this->getPlugin()->getSlug() . '_url_mapping_save', array(&$this, 'save'));
add_action('wp_ajax_' . $this->getPlugin()->getSlug() . '_url_mapping_reset', array(&$this, 'reset'));

That makes them accessible to anyone logged in to WordPress.

As can be seen with the function for saving those, the functions have a nonce check, but not a capabilities check:

129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155

public function save() {
	if ( !wp_verify_nonce($_POST['_wpnonce'], $this->getPlugin()->getSlug()) ) {
		return false;
	}
 
	$message = __('URL Mapping saved.','wordpress-https');
	$errors = array();
	$reload = false;
 
	$ssl_host_mapping = $this->getPlugin()->getSetting('ssl_host_mapping');
	$mappings = array();
	$i = 0;
	for( $j=0; $j<sizeof($_POST['url_mapping']['scheme']); $j+=2 ) { if ( isset($_POST['url_mapping']['host'][$j]) && $_POST['url_mapping']['host'][$j] != '' && isset($_POST['url_mapping']['host'][$j+1]) && $_POST['url_mapping']['host'][$j+1] != '' ) { $mappings[$i][] = array( 'scheme' => $_POST['url_mapping']['scheme'][$j],
				'host'   => $_POST['url_mapping']['host'][$j]
			);
			$mappings[$i][] = array(
				'scheme' => $_POST['url_mapping']['scheme'][$j+1],
				'host'   => $_POST['url_mapping']['host'][$j+1]
			);
			$i++;
		}
	}
	$mappings = stripslashes_deep($mappings);
	$this->getPlugin()->setSetting('ssl_host_mapping', $mappings);
 
	$this->getPlugin()->renderView('ajax_message', array('message' => $message, 'errors' => $errors, 'reload' => $reload));
}

As long the relevant nonce is restricted to users that should have access to changing the settings, the missing capabilities check wouldn’t create a vulnerability. Unfortunately, anyone with the ability to edit posts (so normally down to Contributors) can access the nonce as the same nonce is used for the settings and the plugin’s HTTPS meta box.

As the proof of concept below confirms, there isn’t sanitization, validation, or escaping used with at least the URL filtering settings, so a low-level user could place malicious JavaScript into the settings. That is an authenticated persistent cross-site scripting (XSS) vulnerability.

WordPress Causes Full Disclosure

As a protest of the moderators of the WordPress Support Forum’s continued inappropriate behavior we changed from reasonably disclosing to full disclosing vulnerabilities for plugins in the WordPress Plugin Directory in protest, until WordPress gets that situation cleaned up, so we are releasing this post and then leaving a message about that for the developer through the WordPress Support Forum. (For plugins that are also in the ClassicPress Plugin Directory, we will follow our reasonable disclosure policy.)

You can notify the developer of this issue on the forum as well.

Hopefully, the moderators will finally see the light and clean up their act soon, so these full disclosures will no longer be needed (we hope they end soon). You would think they would have already done that, but considering that they believe that having plugins, which have millions installs, remain in the Plugin Directory despite them knowing they are vulnerable is “appropriate action”, something is very amiss with them (which is even more reason the moderation needs to be cleaned up).

If the moderation is cleaned up, it would also allow the possibility of being able to use the forum to start discussing fixing the problems caused by the very problematic handling of security by the team running the Plugin Directory, discussions which they have for years shut down through their control of the Support Forum.

Update: To clear up the confusion where developers claim we hadn’t tried to notify them through the Support Forum (while at the same time moderators are complaining about us doing just that), here is the message we left for this vulnerability:

Is It Fixed?

If you are reading this post down the road the best way to find out if this vulnerability or other WordPress plugin vulnerabilities in plugins you use have been fixed is to sign up for our service, since what we uniquely do when it comes to that type of data is to test to see if vulnerabilities have really been fixed. Relying on the developer’s information can lead you astray, as we often find that they believe they have fixed vulnerabilities, but have failed to do that.

Proof of Concept

The following proof of concept will cause an alert box with any available cookies to be shown on the plugin’s settings page, when logged in as a Contributor.

Replace “[path to WordPress]” with the location of WordPress and “[nonce]” with the value of the input “wordpress-https” on the page to create a new post.

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

Concerned About The Security of the Plugins You Use?