01 Sep

What Happened With WordPress Plugin Vulnerabilities in August 2017

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

Plugin Security Reviews

Customers of the service can suggest and vote on plugins to have a security review done by us. This month we released details for a review of:

We don’t currently have any more plugins queue up for a review, so if you sign up now for the service, a plugin you suggest could be reviewed right away.

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.

This month the most concerning vulnerability is a PHP object injection vulnerability in WP Smart Security, since that type of vulnerability is likely to be exploited and the vulnerability hasn’t been fixed yet.

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. This month we helped to get vulnerabilities fixed in plugins that have 177,800+ active installs:

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. Most of the new vulnerabilities that were fixed this month are relatively minor.

16 Aug

Settings Change Vulnerability in Asgaros Forum

One of the ways we make sure we have the best data on vulnerabilities in WordPress plugins is by monitoring the WordPress Support Forum for threads possibly related to those. Through that today we ran across a thread started earlier today that seemed to indicate malicious .php files were being uploaded through the Asgaros Forum plugin.

Looking over the plugin we found that the plugin’s settings would not normally allow that, but one of the posts in thread pointed to how it was occurring:

In addition to writing the specified file (which was destroyed by the antivirus server) the forum flew settings to permit all and all, as well as the skin fell back to the default. The impression that the settings were simply overwritten.

It sounded like the attacker was changing the plugin’s settings and then uploading files. We then went to see how the changing of the plugin’s settings was handled. What we found was that as of version 1.5.7 anyone could change the plugin’s settings.

The plugin registers the function save_settings() to run during admin_init (in the file /admin/admin.php):

11
add_action('admin_init', array($this, 'save_settings'));

That will cause it to run when visiting certain pages even if you are not logged in to WordPress.

The save_settings() function would then cause the function save_options() to run if the POST input “af_options_submit” exists:

104
105
106
function save_settings() {
	if (isset($_POST['af_options_submit'])) {
		$this->save_options();

The save_options() function does not do any checks before beginning to save the settings:

140
141
142
143
144
145
function save_options() {
	global $asgarosforum;
	$saved_ops = array();
 
	foreach ($asgarosforum->options_default as $k => $v) {
		if (isset($_POST[$k])) {

So anyone one could change the plugin’s setting by simply sending a request to a page where admin_init occurs.

At the same time we were notifying the developer of our findings they released version 1.5.8, which added a capabilities check before save_options() runs:

122
123
124
125
126
function save_settings() {
	// Only save changes when the user is an administrator.
	if (current_user_can('manage_options')) {
		if (isset($_POST['af_options_submit'])) {
			$this->save_options();

That prevents someone not logged in as Administrator from changing the settings since normally only Administrators have the manage_options capability.

With that change the saving of the settings is still susceptible to cross-site request forgery (CSRF), which means than an attacker could cause a logged in Administrator to changes the plugin’s settings unintentionally. That is less lot less likely to be exploited than the ability for anyone to change the settings, but still should be protected against and we let the developer know about that when we first contacted them and in our reply after they let us know that they had release version 1.5.8.

Proof of Concept

The following proof of concept will cause the “Senders name” in the settings to “settings changed”

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" method="POST">
<input type="hidden" name="notification_sender_name" value="settings changed" />
<input type="submit" name="af_options_submit" value="Submit" />
</form>
</body>
</html>

Timeline

  • August 16, 2017 – Developer notified.
  • August 16, 2017 – Version 1.5.8 released, which fixes the non-CSRF settings change vulnerability.
  • August 16, 2017 – Vulnerability added to free data that comes with our service’s companion plugin.
  • August 17, 2017 – Version 1.5.9 released, which fixes CSRF vulnerability.