Vulnerability Details: PHP Object Injection Vulnerability in Google Analytics Counter Tracker

_{From time to time vulnerabilities are fixed in plugin without someone putting out a report on the vulnerability and we will put out a post detailing the vulnerability. While putting out the details of the vulnerability increases the chances of it being exploited, it also can help to identify vulnerabilities that haven’t been fully fixed (in some cases not fixed at all) and help to identify additional vulnerabilities in the plugin.}

Something we are going to be discussing in an upcoming post is the issue of WordPress plugins that have been removed from the Plugin Directory not being returned to it in a timely manner once a fix for the vulnerability has submitted. During the delay websites using the plugins remain vulnerable to the vulnerability as there is a new version available to update to, so improving the process of reviewing those changes and getting the plugin could improve security. In the meantime we have run into an instance where it looks like hackers might be trying to exploit a vulnerability that has been at least partially fixed, but the plugin remains out of the Plugin Directory.

Yesterday we had a request for the file /wp-content/plugins/analytics-counter/view/scripts/wpadm-ga.js on one of our websites, since the plugin that file is part of, Google Analytics Counter Tracker, is not something that we use that is likely an indication that a hacker was probing for usage of the plugin before exploiting something in it. The plugin is currently not available in the Plugin Directory, possibly indicating that a security issue in it had been reported to the Plugin Directory.

The development log for the plugin shows that an update to the plugin, version 3.4.1, was made four days ago, with the message “- bug fixes”. The changes made in that are an attempt to fix a PHP object injection vulnerability.

In version 3.4.0 in the file class.wpadm-ga.php the function proccessRequest() unserializes user input, which makes PHP objection injection possible:

214
215
216

protected static function proccessRequest() {
	$request_name = self::REQUEST_PARAM_NAME;
	$params = unserialize(base64_decode($_POST[$request_name]));

In 3.4.1 it has been changed to this:

protected static function proccessRequest() {
	$request_name = self::REQUEST_PARAM_NAME;
 
	$str = base64_decode($_POST[$request_name]);
	if(strpos($str, 'a:2:{') !==0  || preg_match('|O\:\d+|', $str, $m)) {
		exit;
	}
	$params = unserialize($str);

The checks done in the if statement are looking for evidence of object injection in the user input and if so, exiting. Though it isn’t clear to us if this would fully prevent the vulnerability from being exploitable. Ideally you wouldn’t run the unserialize() function on user input at all.

The function proccessRequest() is called in the function init() also in the file class.wpadm-ga.php and that function is in turn run during init, which means there is a possibility of PHP object injection anytime WordPress is loaded:

50	add_action('init', array( 'Wpadm_GA', 'init'));

For customers of our service, as always, if you are using a vulnerable plugin that doesn’t have a fixed version available yet, you can get in touch with us so that we can help you to determine how to best handle the situation until a new fixed version is made available to update to.

Proof of Concept

The following proof of concept will cause the specified object to be injected.

Make sure to replace “[path to WordPress]” with the location of WordPress and “[Object to be Injected]” with the object to be injected.

<html>
<head>
</head>
<body>
<form method="post" action="http://[path to WordPress]">
<input type="hidden" name="wpadm_ga_request" value="[Object to be Injected]" />
<input type="submit" value="Submit" />
</form>
</body>
</html>

3 thoughts on “Vulnerability Details: PHP Object Injection Vulnerability in Google Analytics Counter Tracker”

Egidio Romano - November 16, 2016 at 2:53 am

<>

Actually that patch does NOT prevent PHP Object Injection attacks, there exists a pretty easy bypass for such a fix…

- White Fir Design - November 16, 2016 at 9:45 am
  
  The post didn’t mention any patch, maybe you are referring to the changes in version 3.4.1 (that has not been made available yet). In any case we didn’t say the change did fix it. For our customers you can always get in touch with us to determine the best way to deal with such a situation where a fixed version of the plugin is not available to update to.
  
Pingback: A Case Study in Webserver Malware for Admins and Users Alike – CF033 – The Average Guy Network