Persistent Cross-Site Scripting (XSS) Vulnerability in 10Web Booster

We recently saw what looked to be a hacker probing for usage of the WordPress plugin 10Web Booster with this request on a couple of our websites:

/wp-content/plugins/tenweb-speed-optimizer/readme.txt

Looking into what might explain that, we found that the plugin is quite insecure, which shouldn’t be surprising, as we issued an advisory warning about using 10Web’s plugins in November based on repeated security problems on their part. The most serious issue we found in the plugin is that anyone can change the plugin’s settings (they don’t even need to be logged in to WordPress) and one of those settings stores JavaScript code to be run on frontend pages of the website. So you have a settings change vulnerability and a persistent cross-site scripting (XSS) vulnerability, the latter of which hackers would definitely be interested in exploiting.

We tested and confirmed that our firewall plugin for WordPress protected against the vulnerability even before we discovered it, as part of its protection against zero-day vulnerabilities.

The settings change vulnerability starts in the file /OptimizerAdmin.php, where this code starts the process of handling the importing of the plugin’s settings from a file:

if(isset($_POST["two_import_settings"])){
	$filePath = $_FILES['two_import']['tmp_name'];
	$TwoSettings-&gt;import_settings($filePath);
	header("Refresh:0");
}

That code and the subsequent code that runs doesn’t do any security checks, so anyone can upload a file and change the settings.

The persistent cross-site scripting (XSS) vulnerability involves the plugin’s JS callback setting.

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 for Settings Change

The following proof of concept will replace the plugins’ settings with the contents of the uploaded file. The plugin has an export capability to get a file that would be used for this, though in our testing, the contents needed to be slightly corrected for that file to be valid.

Replace “[path to WordPress]” with the location of WordPress.

<html>
<body>
<form action="http://[path to WordPress]"  enctype="multipart/form-data" method="POST">
<input type="hidden" name="two_import_settings" value="true" />
<input type="file" name="two_import" />
<input type="submit" value="Submit" />
</form>
</body>