13 Sep

When an Old Vulnerability Gets a New Vulnerability Report

As part of preparing an upcoming enhancement to the service, we have recently been taking a look at what traffic to our website indicates as to what hackers are targeting. Through that we noticed a connection between the existence of YouTube videos on exploiting vulnerabilities and what vulnerabilities are getting exploitation attempts. In the past few days we have seen a pickup in requests for pages on our website relating to the plugin Cherry Plugin. In looking for any recent mentions of vulnerabilities in this plugin we found a Youtube video showing how to exploit an arbitrary file upload vulnerability in it and an report on that vulnerability.

We had actual already looked at the report when it was released several days ago as part of our monitoring of various vulnerability database websites. In a reminder as to the low quality of many of these reports, the report list the “version” as being 3.8, which could not refer to the plugin’s version since the most recent version is 1.2.8.2. The vulnerability being reported was actually disclosed and fixed more than a year and half ago, which isn’t mentioned in the report. Since the plugin is not available through the Plugin Directory the normal update mechanism for plugins doesn’t come in to play and there is more chance that someone would still have an outdated version and vulnerable version installed at this time.

This is a good example of where our service can be handy even when not alerting you to a vulnerability in the current version of the plugin, as you can see what vulnerabilities have existed in other versions of the plugin, so you could have checked to see this vulnerability was already disclosed and fixed. With the support that comes with the service you could also get in touch with us if you have a question about something like this.

Since the we had already seen exploit attempts against this vulnerability it has been included in the free data that comes with service’s companion plugin for several months, so even if you haven’t signed up for the service yet you would have been warned if you were still using a vulnerable version of the plugin.

The developers of the Cherry Plugin still haven’t fixed a less severe vulnerability that we discovered in the plugin and notified them of back in June.

30 Jun

Wordfence’s Firewall Doesn’t Protect Against a Real World Stored XSS Vulnerability

Last week we wrote a couple of posts about Wordfence, the second one was based on a claim we noticed while working on the first. That leads to this post, which is based on a claim we saw while working on the second post.

In a post about vulnerability in a plugin from earlier this month (in which the discoverer of the vulnerability conspicuously wasn’t mentioned) Wordfence said people using their product were already protected against that vulnerability “because Wordfence has built in protection against stored XSS attacks”. That unqualified claim that there product can protect against such a broad type of vulnerability doesn’t sound like something you would hear from a responsible security company and when it comes to this type of vulnerability, which we refer to as persistent cross-site scripting (XSS), it sounded unbelievable.

To understand why it sounded unbelievable it it is important to understand what persistent XSS is. It is the storage of some form of malicious code on a website, most often that code would be JavaScript code. Since JavaScript is integral part of websites these days, just being able to store JavaScript isn’t a vulnerability. In WordPress for example, users with the role of Editor or Administrator normally have the unfiltered_html capability, which allows them to use “JavaScript code in pages, posts, comments and widgets”. Throw in the fact that persistent XSS vulnerability might involve inserting JavaScript code into the middle of some existing JavaScript code and it is hard to believe that it would be possible to do what Wordfence was claiming.

If Wordfence had said they could protect against that particular vulnerability or some of this type vulnerability it would be a different story.

To see if Wordfence was on the level with their claim or if they were again making a claim not backed up by reality, we did a simple test. We installed their plugin, enabled the firewall (with the Enabled and Protecting status), and tried to exploit the newest persistent XSS vulnerability we had discovered at the time. The vulnerability in the Cherry Plugin allows anyone logged in to WordPress to turn the plugin’s maintenance mode on and have the maintenance page serve JavaScript code specified by the attacker. We would say that this type of vulnerability isn’t a major threat since it requires to be logged in to WordPress and on many websites it would be very difficult for an attacker to do that, but Wordfence seems to think that limitation isn’t even important enough to mention when they disclose vulnerabilities, as we have found when we looked at four recent vulnerability disclosures they made.

Since the vulnerability existed in the current version of the plugin and as far as we are aware we are the only one that have noticed it so far, it seemed to be a good test if Wordfence provided some value, as people would otherwise completely unprotected against this.

We when submitted the exploit we got a blank page back, which would occur if it was successful:

The looking at the homepage when not logged in, we found the persistent XSS exploit was successful:

So Wordfence didn’t actual prevent a real world persistent XSS vulnerability from being exploited.

The question we are left with is whether Wordfence doesn’t understand security enough to know the limitations of their product, they feel that they don’t need to be responsible when making bold security claims (which is all to common among security companies these days), or if they just feel it is appropriate to outright lie to public. In any case it is yet another reminder of the really poor state of WordPress security companies these days.

30 Jun

Authenticated Persistent Cross-Site Scripting (XSS) Vulnerability in Cherry Plugin

As we continue looking at ways we can improve the security of WordPress plugins, one of the thing we are trying is checking over plugins that we have recently added new vulnerabilities to our data set to see if we can find any other obvious vulnerabilities. The third we have spotted is in the plugin Cherry Plugin.

We recently added two vulnerabilities to our data set that existed in older version of the plugin, which were caused by having code that was only intended to be used by Administrator level users accessible to anyone (you didn’t even have to be logged in). The vulnerability we found shows that the developers still are having problems with properly restricting access in the plugins. In this case the function cherry_mtc_save(), which is located in the file /includes/plugin-assets.php, is made accessible to any logged in user through an AJAX request. Since it is also only used through the Maintenance Mode page for the plugin, which is only accessible to Administrators, the function should have restrictions to prevent lower level users from accessing it. That isn’t the case:

69
70
71
72
73
function cherry_mtc_save() {
	$post_date = isset($data) ? $data : $_POST['data'] ;
	update_option('mtc_options', $post_date);
	exit();
}

You can see that there is also no nonce check in the function, so the function can also be exploited through cross-site request forgery (CSRF).

The function saves changes to the settings for the plugin’s maintenance mode. With that a lower level user could turn on the plugin’s maintenance mode, which would be a nuisance on its own. But a real security risk comes from the fact that they can set the description that is shown on the page shown when the maintenance mode is on to include JavaScript code, meaning there is a persistent cross-site scripting (XSS) vulnerability.

You can see that no sanitization is done when the settings are saved and then when it is output in the file /includes/plugin-under-construction-content.php:

69
70
if(isset($mtc_options['mtc_mode_description'])){ ?>
	<p id="under_construction_description"><?php echo stripslashes( $mtc_options['mtc_mode_description'] ); ?></p>

It isn’t clear if the developer intended for Administrators to use JavaScript in that field or if they just hadn’t bothered to sanitize or escape the value.

Proof of Concept

The following proof of concept will turn on the maintenance mode and display an alert reading XSS, when submitted while logged in to WordPress.

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="mtc_save" />
<input type="hidden" name="data[mtc_mode_on]" value="1" />
<input type="hidden" name="data[mtc_mode_description]" value='/><script>alert("XSS");</script>' />
<input type="submit" value="Submit" />
</form>
</body>
</html>

Timeline

  • 6/23/2016 – Developer notified.
22 Jun

Old Vulnerability Report: Arbitrary File Viewing Vulnerability in Cherry Plugin

One of the things that we do to keep track of the  plugin vulnerabilities out there is to monitor hacking attempts on our websites. That sometimes leads us to finding what looks to be exploitation of vulnerabilities that a hacker has just discovered. In other cases it shows really old vulnerabilities that hackers are still trying to exploit. We have recently had some attempts to exploit a couple of vulnerabilities in older versions of the plugin Cherry Plugin. One was an arbitrary file upload vulnerability mentioned here and the other was an arbitrary file viewing vulnerability that we couldn’t find any prior mention of.

In version 1.2.6 and below the file /admin/import-export/download-content.php will serve up the contents of any file requested. It looks like that functionality was intended to be only accessible by admins, but there were no restrictions in place to prevent anyone else from accessing it.

Proof of Concept

The following proof of concept will download the website’s wp-config.php file.

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

http://[path to WordPress]/wp-content/plugins/cherry-plugin/admin/import-export/download-content.php?file=../../../../../wp-config.php