One the things we find rather telling about the security industry is that they seem to find various statistics valuable, but ones they seem to be totally uninterested in are any that would actually show that their products and services are actually effective at protecting websites (despite that seeming like it should be a prerequisite before using so many of them). One type of statistic that we have seen them focus on instead is supposed measures of how many attacks the average website is facing. Earlier this year one company promoting their service with such a statistic, seemed to make a case that they are not really valuable, as they promoted the increase in attacks as being a concern and then when it when it went down they claimed that was also a bad sign:

“A decrease in attacks does not mean that websites are safer. In fact, it may even be the opposite,” says Neill Feather, president of SiteLock. “Hackers are constantly trying new avenues and even leveraging older tactics that continue to be successful. As our research shows, cybercriminals are now able to successfully breach a site with fewer, more targeted attacks. Now more than ever, businesses need to evaluate their current security posture and ensure they have both the right technology and a response plan in place should a hack occur.”

While that quote would imply that they are aware of how many attacks are effective they don’t provide that stat. If they truly know that (and based on everything we know about SiteLock they likely don’t), the reason for that would be quite obvious. The success rate of hacking attempts is in incredibly low, with the average website not even being successfully hacked once a year. It is a lot easier to sell a security services that don’t even focus on actually securing websites by getting people to fear thousands of attacks a year then less than one successful attack a year.

So why are so many attacks not successful? Something we recently looked at shows some of why that is.

We have had several recent exploit attempts that requested the following URL:

/wp-content/plugins/ungallery/source_vuln.php?pic=../../../../../wp-config.php

Those requests would be attempting to access a file from the plugin UnGallery, which currently has 100+ active installs according to wordpress.org. Seeing as we have never used that plugin those attempts would have never succeeded, nor would they on almost any other website considering the number of installs. But things get worse from there.

The filename, source_vuln.php, seemed odd to us. Specifically the “_vuln” part of it. When we went to look into this we didn’t find a file named that in any of the versions of the plugin we checked. A quick search though showed what was going on. The file that had been vulnerable was source.php, but for some reason in a report about it was instead listed as source_vuln.php.

So you have a hacker who is trying to exploit a vulnerability on what looks like it would be a fairly wide scale without doing any testing first. From what we have seen over the years that is not an uncommon situation. That is good news for people running websites, other than ones that get tricked in to using an ineffective to outright scammy security services based on attacks stats, since that means that a lot of the hackers’ resources are being wasted.

In this case there is another indication that the hacker didn’t do any research before trying to exploit this, as the vulnerability was resolved seven years ago, so even if they were not going after the wrong file they would have had to hit websites that are really out of date for the exploit to work.

Looking at what happened though is a reminder of why disclosing vulnerabilities so that others can review the details is important.

In version 1.5.8 of the plugin had commented out the following code in source.php:

if ($_GET['zip']) {
	$filename = $_GET['zip'];
	$len = filesize($filename);
	$lastslash =  strrpos($filename, "/");
	$name =  substr($filename, $lastslash + 1);
 
	header("Content-type: application/x-zip-compressed;\r\n"); 
	header("Content-Length: $len;\r\n");
	header('Content-Disposition: attachment; filename="' . $name . '"');  // Create a download stream link
	readfile($filename);	
}

That code would display the content of a user specified file from the website, also known as an arbitrary file viewing vulnerability. That was explicitly commented out due to the security issue as the changelog entry for that version was “Disabled zip archiving feature due to security issue. Will add back later if possible.”

Right below that were two more instances of nearly identical code that were not commented out in version 1.5.8:

if ($_GET['pic']) {
	$filename = $_GET['pic'];
	$len = filesize($filename);
	$lastslash =  strrpos($filename, "/");
	$name =  substr($filename, $lastslash + 1);   
 
	header("Content-type: image/jpeg;\r\n");
	header("Content-Length: $len;\r\n");
	header("Content-Transfer-Encoding: binary;\r\n");
	header('Content-Disposition: inline; filename="'.$name.'"');	//  Render the photo inline.
	readfile($filename);
} 
 
if ($_GET['movie']) {
	$filename = $_GET['movie'];
	$len = filesize($filename);
	$lastslash =  strrpos($filename, "/");
	$name =  substr($filename, $lastslash + 1);   
 
	header("Content-type: video/mp4;\r\n");
	header("Content-Length: $len;\r\n");
	header("Content-Transfer-Encoding: binary;\r\n");
	header('Content-Disposition: inline; filename="'.$name.'"');	//  Render the video inline.
	readfile($filename);
}

Where not sure what would have lead anyone to believe that only the first one was vulnerable, but that is what happened. It took two months for that additional vulnerable code to be dealt with. The exploit attempts we saw were trying to exploit the second one, but the third one was also exploitable.

Proof of Concept

The following proof of concept will display the contents of the WordPress configuration file, wp-config.php.

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

http://[path to WordPress]/wp-content/plugins/ungallery/source.php?movie=../../../wp-config.php