We don’t currently have any more plugins queued up for a review, so if you sign up now for the service, a plugin you suggest could be reviewed right away.

20 Mar

WordPress Plugin Security Review: Cloudflare

For our sixth security review of a plugin based on the voting of our customers (we are still waiting to release the results of the fifth until after the developer has a chance to fix the most serious issue found), we reviewed the plugin Cloudflare.

If you are not yet a customer of the service you can currently try it free for your first month and then start suggesting and voting on plugins to get security reviews after your first payment for the service. For those already using the service that haven’t already suggested and voted for plugins you can start doing that here.

The review was done on version 3.2.0 of Cloudflare. We checked for the following issues:

  • Insecure file upload handling (this is the cause of the most exploited type of vulnerability, arbitrary file upload)
  • Deserialization of untrusted data
  • Security issues with functions accessible through WordPress’ AJAX functionality (those are a common source of disclosed vulnerabilities these days)
  • Persistent cross-site scripting (XSS) vulnerabilities in publicly accessible portions of the plugin
  • Cross-site request forgery (CSRF) vulnerabilities in the admin portion of plugins
  • SQL injection vulnerabilities (the code that handles requests to the database)
  • Reflected cross-site scripting (XSS) vulnerabilities
  • Lack of protection against unintended direct access of PHP files

Results

During the review we only found one minor issue:

Lack of Protection Against Direct Access to Files

Numerous .php files that look like they are not intended to be accessed directly are lacking code at the beginning of the file to restrict direct access to the files. In the files we looked over we didn’t see anything that could be exploited due to that.

04 Apr

When Full Disclosure of a Claimed WordPress Plugin Vulnerability Leads To A Bigger Problem

When it comes to disclosing security vulnerabilities, a major issue is when the vulnerability should be disclosed. On one side is full disclosure, which involves disclosing it as soon as possible, including before the vulnerability has been fixed. On the other side is responsible disclosure, which involves disclosing a vulnerability in a coordinated manner sometime after it has been fixed. Both have issues worth discussing, but in this post we will focus on one example of what can go wrong when a claimed vulnerability in a WordPress plugin is disclosed without giving the developer prior notification.

On March 28 a report claiming there was a cross-site scripting (XSS) vulnerability in the CloudFlare plugin was released. We say claimed because in normal circumstances this would not be a vulnerability. While the report describes the threat as:

An attacker may leverage these issues to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This may allow the attacker to steal cookie-based authentication credentials and to launch other attacks.

What it doesn’t mention is the fact the attacker would have to be logged in as an admin level user to do what is describe. If an admin wants to do something malicious they would have normally have more effective options and would also normally have the ability to edit a plugin and therefore remove any restrictions on using cross-site scripting. The other relevant issue with calling this a vulnerability is that admin (and editors) are normally allowed to use the equivalent of cross-site scripting due to having the unfiltered_html capability. For those reasons we don’t include this type issue in our data.

While this isn’t something we would consider a vulnerability, it still would be best to make sure this type of issue does not occur.

Later on March 28 CloudFlare released a version 1.3.2.1 of the plugin to fix what they saw as a “zero day vulnerability“. Since it wasn’t actually a vulnerability they wouldn’t have needed to rush out a fix, but if they had been notified ahead of the public disclosure they wouldn’t have needed to rush either.

While CloudFlare claims to be a web security provider, it is clear they don’t have much knowledge when it comes to handling of the security of a WordPress plugin at least. Instead of following the good advice provided in the WordPress documentation on properly handling user input they decided to fix the issue with the following code:

$_GET = array_map("cloudflare_filter_xss", $_GET); 
$_POST = array_map("cloudflare_filter_xss", $_POST); 
function cloudflare_filter_xss($input) { 
 return htmlentities($input, ENT_QUOTES | ENT_HTML5, "UTF-8"); 
}

That code ran all GET and POST variables through their cross-site scripting filtering function instead of just the variable used in their plugin, which altered many things it shouldn’t and lead to a variety of WordPress functionality being broken.

CloudFlare quickly put out another release that fixed most of the issue, though as of the current version, 1.3.2.4, the new code they replaced the code that had been added in 1.3.2.1 with was still running several POST variables through their cross-site scripting filtering anytime they are submitted instead of just sanitizing those variables when they are clearly being submitted the plugin’s setting’s page:

$cfPostKeys = array("cloudflare_zone_name", "cf_key", "cf_email", "dev_mode", "protocol_rewrite");

foreach($_POST as $key => $value) {
 if(in_array($key, $cfPostKeys)) {
 $_POST[$key] = cloudflare_filter_xss($_POST[$key]);
 }
}

function cloudflare_filter_xss($input) {
 return htmlentities($input, ENT_QUOTES | ENT_HTML5, "UTF-8");
}

This situation does highlight another issue, the difficulty in notifying a developer of a WordPress plugin of a security issue. The address listed as the plugin’s homepage is now a 404 page and from CloudFlare’s homepage we couldn’t find a relevant contact page or address. If you run into a situation like this where you can’t find a way to directly contact the developer you can report the issue directly to Plugin Directory instead.