04 Dec

New WordPress Plugins Continue to Use Third-Party Library with Vulnerability Disclosed Years Ago

As we continue to work on expanding what security issues our WordPress plugin security checker tool can check for, one of the things that doing that work has lead us to take notice of is the extent that plugins are using third-party libraries that haven’t been supported in a long time. Just like a plugin that hasn’t been supported, if there has been a security vulnerability that has been discovered, it is unlikely to be fixed. That is the case with the third-party library CSSTidy, which was last updated in 2007.

One of the files in that contains a reflected cross-site scripting (XSS) vulnerability that has been publicly disclosed for years, for example, it was disclosed in one WordPress plugin back in July of 2012. Where we ran across recently across it was in a disclosure by Ricardo Sanchez of it in the plugin AMP Toolbox. That plugin has included the file and therefore been vulnerable since the first release of the plugin, which was only in May of last year.

As we were looking around at this before adding a check for usage of the vulnerable file from the library to our tool we found that it was also used in the plugin Super Simple Custom CSS, which has only been around since July of last year.

In Super Simple Custom CSS the relevant files is located at /super-simple-custom-css/css_optimiser.php and the relevant lines for the issue mentioned in the previous discomposure 142 and 143 of that:

name="url" id="url" <?php if(isset($_REQUEST['url']) &&
!empty($_REQUEST['url'])) echo 'value="'.$_REQUEST['url'].'"'; ?>

The PHP code there checks if a GET or POST input “url” exists and isn’t empty, if both of those are true then the value of the input is output without being escaped.

We notified the developer of the issue a week ago. We haven’t heard back from them and no new version has been released to fix the issue. In line with our disclosure policy, which is based on the need to provide our customers with information on vulnerabilities on a timely basis, we are now disclosing this vulnerability.

Also, worth noting with this, is that this is something that the security review that is done of new plugins in the Plugin Directory is supposed to be catching, as one of the items on their security checklist is:

Escape all data before output (See: Data Validation)

Considering that the review team seems to be missing more obvious instances of this type of issue, missing this in this plugin and AMP Toolbox through a third-party library isn’t all that surprising. While we think the reviews would be better if they focused on issues more likely to lead to exploitable vulnerabilities, running newly submitted plugins through our tool would now catch usage of this library. Currently we allow paying customers to use the tool to test plugins that are not currently in the Plugin Directory, but we would be happy to provide free access to that capability to the plugin review team.

Proof of Concept

The following proof of concept will cause an alert box with the message “XSS” to be shown. Major web browsers other than Firefox provide XSS filtering, so this proof of concept will not work in those web browsers.

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

http://[path to WordPress]/wp-content/plugins/super-simple-custom-css/css_optimiser.php?url=%22%3E%3Cscript%3Ealert('XSS');%3C/script%3E

Timeline

  • November 27, 2017 – Developer notified.
29 Nov

Sucuri Only Became Aware of Exploitation of WordPress Plugins Weeks After Public Disclosure of That Exploitation

One of the problems we find in being part of the web security industry is that the public often believes that companies that don’t seem to know and or care much about security are actually leading on things. As example of the difference between reality and that belief let’s look at something recently from Sucuri, which is one of the best known companies (though also one that has trouble doing the basics of what they offer and is engaged in rather shady practices).

Currently on their homepage you will find a testimonial that reads in part:

Another thing we like is that Sucuri knows about security issues before they become a problem – in advance.

That is very different from the reality of the exploitation a couple of recently fixed vulnerabilities in WordPress plugins (and plenty of other examples we can think of from just our cursory knowledge of Sucuri).

Back on November 7 Robert Mathews disclosed that he had discovered a vulnerability as it was being exploited in the plugin Shortcodes Ultimate and that he had then seen attempts to exploit it through another vulnerability that was in the plugin Formidable Forms. That vulnerability in Shortcodes Ultimate was fixed on October 31.

On November 9 we put out a post on the details of the vulnerability in Formidable Forms as there had not been any publicly disclosed information put out on it. That vulnerability had been fixed on October 25. The discoverer of that vulnerability, Klikki Oy, released a report on it on November 13.

Also on November 9 we added both vulnerabilities to the free data that comes with our service’s companion plugin (as we do for any vulnerabilities that hackers appear to be exploiting), so even for websites that are not using our service they could be warned if they were still using a vulnerable version of the plugins.

Despite all of that, Sucuri only became aware of the exploitation of those vulnerabilities on November 20:

On Monday, November 20th, we were notified about a vulnerability that poses a serious security risk when the Shortcodes Ultimate and Formidable Forms plugins are used together on a single WordPress installation.

Even when they belated became aware of this someone else was notifying them, which reminds of the time Wordfence only became aware of a vulnerability that was publicly disclosed and looked to be being widely exploited, when someone notified them of us discussing the issue. How people can think companies like these are leaders in the face of things like that is amazing.

It wasn’t until four days later that they released their post.

Just like we discussed with Wordfence recently with one of these vulnerabilities, these security companies don’t present the obvious lesson for the public from these situations, which is you should be keeping your plugins up to date at all times, which can be done with things like our Automatic Plugin Updates plugin. Instead they are telling people only to update this plugins after they belated become aware of the issues. Here is Sucuri’s recommendation:

Update Now

As you can see, attackers are actively looking for this issue in the wild. If you’re using a vulnerable version of these plugins, we highly recommend that you update them now!

In the event where you cannot do this, we strongly recommend leveraging the Sucuri Firewall or equivalent technology to get it patched virtually.

The second part of the recommendation is problematic for a number reasons, including that Sucuri’s firewall can often easily be completely bypassed (which they are aware of), they only belated became aware of these vulnerabilities and therefore couldn’t have added virtual patching for them till long after they started being exploited, and there isn’t evidence presented by them, much less evidence based on independent testing, that their firewall is actually effective in protecting against vulnerabilities (just a month and a half ago it was found that it was susceptible to a fairly basic bypass technique).

So why not tell people that they should be keeping their plugins up to date? Well it could that they don’t understand that this important (both of those companies don’t understand other basics basics of security). It could be that they would rather people not to do best practices that likely would provide much better protection that their services (it certainly looks like it would have here). It also could be that would get in the way of trying to get people to share their blog posts, since if everyone was keeping plugins up to date it would lot less important to tell people to update certain plugins.

A Service That Protects

If for some reason you are not able to keep your plugins up to date in general, which is claimed to be something common in academia, our service would probably provide you much better protection than security services since we actually keep up on vulnerabilities in WordPress plugins and warned our customers weeks before Sucuri mentioned these vulnerabilities.

Our focus though isn’t in just warning people about vulnerabilities after they are discovered by others as was the case with these vulnerabilities, but being proactive in finding and fixing plugin vulnerabilities, which is something if we had more customers we could be do a lot more than we already do (which is already much more than Sucuri or Wordfence seem to be doing). We do that through things like our proactive monitoring of changes made to plugins to try to catch serious vulnerabilities, security reviews of plugins suggested/voted for by our customers, our new tool for helping to identify possible vulnerabilities in plugins in an automated fashion.

We think we could make things even better if we were not dealing with a situation where the people of the WordPress side of things are intentionally blocking improvements to security and denying the reality of the problems that exist.

28 Nov

The Limited Capability of Existing Plugins for Checking the Security of Plugins

As we have been looking at what more we can do with our new tool for doing security checks of WordPress plugins, one of things we have been looking at is what existing tools are out there that provide similar functionality. In doing that we found a couple of plugins that do security checks of other plugins, though their capability is rather limited.

WP Plugin Security Check

The first plugin is WP Plugin Security Check, which was last updated seven years ago. The plugin is described as:

WP Plugin Security Check checks plugins for bad practices and possible security holes limiting the risk of a compromised WordPress installation to a ‘hate to say I told you so’.

The description doesn’t spell out what types of things are looked for. In looking at the underlying code we found it checks for three items:

  • Usage of the variable $_SERVER[‘REQUEST_URI’]
  • Usage of the function eval()
  • Usage of variable functions

Warning about usage of eval() seems reasonable enough as the documentation for that states:

The eval() language construct is very dangerous because it allows execution of arbitrary PHP code. Its use thus is discouraged. If you have carefully verified that there is no other option than to use this construct, pay special attention not to pass any user provided data into it without properly validating it beforehand.

Though the tool just checks for its usage, not say if the usage might be exploitable.

Variable functions could potentially allow arbitrary PHP functions to be executed, though we can’t recall coming across them with any vulnerable or intentionally malicious code, so we are not sure if that would be of much use to check for.

The check for use of $_SERVER[‘REQUEST_URI’] is rather odd as that variable just provides with the address of the page being requested. That does include user input, so it does need to be properly handled (though as we noted before, the value is usually encoded, limiting issues that can come from improper use of it), but what the “bad practices and possible security holes” involved with that are is something we can’t think of. That variable is used in many of the most popular plugins, so it would cause a lot of those plugins to be flagged for a reason that isn’t clear to us.

Plugin Inspector

The second one is Plugin Inspector, which was last updated 12 months ago. The plugin is described as:

The Plugin Inspector plugin is an easy way to check plugins installed on your WordPress and make sure that plugins do not use deprecated WordPress functions and some unsafe functions like eval, base64_decode, system, exec, etc. Some of those functions may be used to load malicious code (malware) from the external source directly to the site or WordPress database.

Some of the functions it checks for usage of seem like they could accurately be described as being unsafe, as was already mentioned with eval(), but others seem more problematic as they just are functions that make requests to other websites.

The problems with its usage can probably be best seen by the result when the plugin scans itself and the developer’s response to that result. Here is the result when the plugin is scanned by itself:

When the developer of the plugin was asked about this they responded:

What is the question? This is just a warning, not an issue.

You can ignore all Unsafe messages if you trust the author and the source of this plugin.

Just because you trust the author and the source of the plugin, it doesn’t mean the plugin is safe.

There is also the issue that the checks are rather simply done. As an example of this, in one of the screenshots provided for the plugin you can see that a line of code that uses a function to making a request to another website, the plugin states that it could “load data from any external server”:

Since a variable is used, you can’t tell just by the line what websites or website requests might be through it. But below that in the screenshot is another line with the same message despite the code in that line making a request for a specific web address:

This tool does seem useful for someone with some level of expertise that wanted to have a better understanding of what a plugin might do, but for others it seems the checks are of limited value.

27 Nov

Did the WordPress Plugin Directory Know That PHP Event Calendar Contains an Exploitable Vulnerability?

A day ago we had what looks to be a request from a hacker for a file that would be located at /wp-content/plugins/php-event-calendar/server/file-uploader/index.php. That would be a file in the plugin PHP Event Calendar. In the Plugin Directory the plugin “has been closed and is no longer available for download”, but no reason is given as to why that is.

In looking around we couldn’t find any public disclosure of a security issue related to that file.

Looking at the code in that file, /server/file-uploader/index.php, in the most recent version of the plugin it simple sets up an instance of the jQuery File Upload Plugin PHP Class library located in the file /server/file-uploader/UploadHandler.php:

13
14
15
16
17
error_reporting(E_ALL | E_STRICT);
require('UploadHandler.php');
 
$custom_dir = $_REQUEST['custom_dir'];
$upload_handler = new UploadHandler(array('upload_dir' => $custom_dir));

In the UploadHandler.php file there is no restriction placed on what type of files can be uploaded through it:

92
'accept_file_types' => '/.+$/i',

So any type of file can be uploaded through it, leading to an arbitrary file upload vulnerability.

Because WordPress continues to refuse to properly handle closed plugins like this, we have no idea if they have known about vulnerability and didn’t warn people about it or if the plugin was closed for some other reason.

Since this vulnerability is being exploited, we are adding the vulnerability to the free data that comes with our service’s companion plugin, so even those not yet using our service can be warned if they are using a vulnerable version of the plugin.

Worth noting here is that this vulnerability was introduced as a security fix, as the relevant changelog entry when it was added was:

Important security fix. Replace Uploadify with jQuery File Upload

As far as we can tell what they replaced was actually more secure and had been inaccurately labeled as leading to an arbitrary file upload vulnerability (as the types of files that could be uploaded were limited).

That change seems like a good example of where our idea of providing an ability for plugin developers to submit information to WordPress on security fixes and then allowing others to review the changes could help to improve security. In the meantime we continue to offer free help to developers dealing with security vulnerabilities (that is an offer that hasn’t been taken up outside of developers we have contacted to let them know of vulnerabilities we or others have discovered).

Proof of Concept

The following proof of concept will upload the selected file to the directory /wp-content/plugins/php-event-calendar/server/file-uploader/.

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

<html>
<body>
<form action="http://[path to WordPress]/wp-content/plugins/php-event-calendar/server/file-uploader/" method="POST" enctype="multipart/form-data">
<input type="file" name="files" />
<input type="submit" value="Submit" />
</form>
</body>
27 Nov

A WordPress Plugin Having Ten Thousand Installs Doesn’t Mean it Will Have Been Reviewed for Security

When it comes to the security of WordPress plugins there are a lot of misconceptions out there (many times they are being repeated by security companies). One of them is that a more popular plugin is going to be more secure because it has been reviewed for security. Here is an example of this claim from a recent thread on Reddit:

it is important to note that there are many thousands of WordPress plugins available, and many of them have only been installed on a handful of websites. Lesser known or less popular plugins will often not have been reviewed for security, and may contain flaws.

For that reason, I recommend avoiding plugins or themes that don’t have several thousand installs (10k+ is a good rule of thumb) on security-conscious installs, unless you can have a developer inspect and vet the code for you.

As is true of so much security advice, there isn’t any evidence presented to back that claim up, which should be a red flag. In our compiling data on WordPress vulnerabilities for our service we haven’t seen evidence that there are many security reviews being done of WordPress plugins, so assuming that more popular plugins have had a security review is not a good idea.

Another way to look at is to see if there are easy to spot vulnerabilities in say a plugin 10,000+ active installations, which happen to have an example of from some checking we were doing related to our tool for doing limited automated security checks of WordPress plugins. One of the checks included in the tool is when user input is being directly output, which could lead to reflected cross-site scripting (XSS). That is something it would have detected in the plugin WP Customer Area up until we notified the developer of the issue and it was fixed.

Before we get the details its worth mentioning that this plugin has a couple of other attributes that get cited as being ones that should be used to decide if a plugin is secure, those being that it was recently updated (as of when we went to notify the developer) and with having positive reviews:

In three files the plugin contained the following line:

 

<input type="hidden" name="page" value="<?php echo $_REQUEST['page'] ?>"/>

That would echo the GET or POST input “page” without escaping it, so for example malicious JavaScript code could be output. Major web browsers other than Firefox provide XSS filtering, so to be exploitable the hacker would have to figure out a way around that or hope that the person to be exploited is using Firefox.

Now there is little bit more to this vulnerability, which gets to why simply using an automated tool, like ours, isn’t enough to determine if there are vulnerabilities. In this case to get that code to run the value of the GET input “page” has to be set to a specific value, in the case of one of the files, /src/php/core-addons/admin-area/templates/private-post-list-page.template.php, it would have to be set to “wpca-list,content,cuar_private_fil”. So that couldn’t also be used for malicious code, but you can set the POST input to another value and it looks like normally the $_REQUEST variable would contain the value of the POST input instead of the GET input.

After we notified the developer of the issue, they released version 7.4.3, which fixes the vulnerability escaping the user input:

<input type="hidden" name="page" value="<?php echo esc_attr($_REQUEST['page']) ?>"/>

There Isn’t an Shortcut to Determining if a Plugin is Secure

With all the claims we have seen so far relate to determining if a plugin is secure, none of them have pointed to a way that you can truly determine if a plugin is secure without actually having a security review done. For example, even using a much more popular than one with 10,000+ active installations, isn’t going to mean that it is secure, as can be seen with another plugin with 300,000+ active installations we looked at recently that had five different vulnerabilities (and still has them, as they still haven’t been fixed).

Our aforementioned tool is able to detect some possible issues and we are continuing to expand what it can do, but it won’t catch a lot of issues, including any of those in 300,000+ active installation plugin at the moment.

If you want to get plugins you use checked over, that is something we offer. If you are paying customer of our service one of the things you get is the ability to suggest/vote for plugins from the Plugin Directory to receive a review from us and you can also order a security review separately from us.

Proof of Concept

The following proof of concept will cause any available cookies to be shown in alert box, when logged in as an Administrator. Major web browsers other than Firefox provide XSS filtering, so this proof of concept will not work in those web browsers.

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

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin.php?page=wpca-list%2Ccontent%2Ccuar_private_file" method="POST">
<input type="hidden" name="page" value='"><script>alert(document.cookie);</script>' />
<input type="submit" value="Submit" />
</form>
</body>

Timeline

  • November 21, 2017 –  Developer notified.
  • November 21, 2017 –  Developer responds.
  • November 24, 2017 –  Version 7.4.3 released, which fixes vulnerability.
27 Nov

Easy to Spot Vulnerabilities in WordPress Plugins Can Be an Indication of Poor Development Practices and Further Issues

In testing out a new check we were adding to our tool for doing limited automated security checks of WordPress plugins we ran the plugin ProfileGrid through the tool, since it had previously had the security issue being checked for. That security issue involved usage of a third-party library that hadn’t been updated in 8 years (the library was added to the plugin 9 months ago) and would leak potentially sensitive information about financial transactions. When we ran the plugin through the tool we found that the tool identified that plugin possibly contained a fairly obvious reflected cross-site scripting (XSS) vulnerability. In looking over things we found that there were multiple instances of this issue in the plugin and that it looks like debugging code has been left in the plugin, so the plugin didn’t look exactly production ready in addition to be being insecure.

That wasn’t really surprising when we noticed that one of the developers is CMSHelpLive, which is a company we noted over a year ago at our main blog was still running a version of Joomla that had been EOL’d four and half years ago, while offering to clean up hacked Joomla websites. Over a year later they are still running that version. (It would be hard to make up claims about the poor handling of security by companies involved in security that could outdo what they really do.)

There are several places the reflected XSS vulnerability existed, but as an example let’s take a look one of them that has existed since the first version of the plugin. That involves the usage the outputting of the GET input “search” in the file /admin/partials/user-manager.php, which is used to generate the page /wp-admin/admin.php?page=pm_user_manager. On lines 112 and 115 of that file that input is echo’d without being escaped:

 <input type="text" class="sb-search" name="search" id="search" value="<?php if(isset($_GET['search'])) echo $_GET['search'];?>">
 </div>
 <?php if(isset($_GET['search']) && $_GET['search']!=''):?>
 <div class="sb-search-keyword" id="search_keyword"><?php echo $_GET['search'];?> <span onclick="show_hide_search_text()">x</span></div>

That is a pretty clear cut issue and when we went check things out to make sure there wasn’t any code elsewhere that would restrict that from being exploitable, there wasn’t.

Also, worth noting with this, is that this is something that the security review that is done of new plugins in the Plugin Directory is supposed to be catching, as one of the items on their security checklist is:

Escape all data before output (See: Data Validation)

The plugin is only eleven months old, so the failure to spot this doesn’t seem like it can be blamed on a previous lower standard. While we think the reviews would be better if they focused on issues more likely to lead to an exploitable vulnerabilities, if the team behind this was interested with improving what they are doing now we could certainly help them considering that our automated tool was able to pick this issue up.

In terms of the debugging code, an example were the following commented out lines in the file /admin/partials/add-section.php:

 //echo '<pre>';print_r($_POST);echo '</pre>';die;
 //print_r($identifier);die;

Beyond not needing to be there, in another location what looks to be debugging code was left running in the production version of the plugin. The last line shown below would output any POST input with a request after the code generates a success message (in the file /public/partials/profile-magic-payment-process.php):

 case "success": // success case to show the user payment got success
 echo '<div id="crf-form">';
 echo "<div class='info-text'>".__('Payment Transaction Done Successfully','profile-magic')."</br>";
 echo '</div></div>';
 print_r($_POST);

After we notified the developer of the issue, they released version 2.6.7, which resolved the instances of the plugin directly outputting unescaped output. The example shown above was changed to this:

 <input type="text" class="sb-search" name="search" id="search" value="<?php if(isset($_GET['search'])) echo esc_attr( filter_input(INPUT_GET, 'search', FILTER_SANITIZE_STRING) );?>">
 </div>
 <?php if(isset($_GET['search']) && $_GET['search']!=''):?>
 <div class="sb-search-keyword" id="search_keyword"><?php echo esc_html( filter_input(INPUT_GET, 'search', FILTER_SANITIZE_STRING) );?> <span onclick="show_hide_search_text()">x</span></div>

It isn’t clear why they used an escaping function and filter_input on those, since the escaping function should be enough.

They also removed the relevant debugging code made some other security changes in that version.

Proof of Concept

The following proof of concept will cause any available cookies to be shown in alert box, when logged in as an Administrator. Major web browsers other than Firefox provide XSS filtering, so this proof of concept will not work in those web browsers.

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

http://[path to WordPress]/wp-admin/admin.php?page=pm_user_manager&search=%22%3E%3Cscript%3Ealert%28document.cookie%29%3B%3C%2Fscript%3E

Timeline

  • November 20, 2017 – Developer notified.
  • November 21, 2017 – Developer responds.
  • November 23, 2017 – Version 2.6.7 released, which fixes vulnerability.
22 Nov

Our WordPress Plugin Security Checker Identified a Fairly Serious Vulnerability in a Plugin by MailChimp

Recently we introduced a tool to do limited automated security checks of WordPress plugins in the Plugin Directory (and more recently expanded it to check plugins not in the directory). As part of improving that we have been logging any issues identified by the tool in plugins in the Plugin Directory (we don’t log the results for other plugins) and checking some of those to see how well the tool is in identifying real issues.

In one instance, which we will be describing in more detail once the developer has had a chance to fix the vulnerability, we found that a possible issue identified by the tool turned out to not be an issue, but it did indicate a general poor handling of security within the plugin and we then found the plugin has a fairly serious vulnerability. In another instance the tool identified a pretty serious issue in a plugin.

One of the items we check for with the tool is certain instances of local file inclusion (LFI). The checks for that were originally based on a LFI vulnerability we recently found in a brand new plugin as we were in the process of documenting another vulnerability we had found in it through our proactive monitoring of changes made to plugins to try to catch serious vulnerabilities. The checks were then improved by reviewing some other vulnerabilities of that type we had previously found.

Since the LFI checks are something that we haven’t been using elsewhere for some time (as is the case with some of the other checks in the tool are), we didn’t have much idea as to what they might end up picking up in other plugins. So we didn’t know what to expect when we saw that a possible LFI issue had been picked up with the plugin MailChimp for WooCommerce. It turned out that it was a clear cut vulnerability in a plugin with 30,000+ active installations and developed by a company with hundreds of millions of dollars of revenue that makes impressive sounding claims about their handling of security, which is reminder that the security of WordPress plugins is not in great shape.

The file with the vulnerability was /admin/partials/tabs/notices.php, which looked like this before we notified the developer of the issue:

<?php if(isset($_GET['error_notice']) && file_exists(__DIR__.'/errors/'.$_GET['error_notice'].'.php')): ?>
    <?php include(__DIR__.'/errors/'.$_GET['error_notice'].'.php'); ?>
<?php endif; ?>

<?php if(isset($_GET['success_notice']) && file_exists(__DIR__.'/success/'.$_GET['success_notice'].'.php')): ?>
    <?php include(__DIR__.'/success/'.$_GET['success_notice'].'.php'); ?>
<?php endif; ?>

The first line of that file checks if a GET input “error_notice” exists and that file, whose name is partially defined by that input, exists. If the input exists and the file exists then the file is included. Due to a lack of protection against directory traversal, files outside of the intended directory can be included.

That could have allowed a hacker to get code in another file to run that they otherwise would not have been able to. One possible scenario for that sort of issue is if the hacker could upload an image file, they could include PHP code in an image and then that type of vulnerability to cause the PHP code to execute.

The same code is then repeated with a GET input “success_notice”, so an attacker could load two files with one request.

Seeing as this file isn’t intended to be loaded directly, it is an example of why it makes sense to restrict direct access to files that don’t need it, which is something that we check for during the security reviews of plugins we do.

That file has existed in that form since the first version of the plugin, which was released 13 months ago.

A week after we notified MailChimp they released version 2.1.2, which fixes the vulnerability. You wouldn’t know that a vulnerability had been fixed from the changelog, as these are all the entries in the changelog for that version:

  • Fix store deletion on plugin deactivation
  • Correct shipping name is now used on order notifications.
  • Admin orders are now handled appropriately.
  • Skip incomplete or cancelled orders from being submitted when new.
  • fix hidden or inactive products from being recommended.

Not disclosing that a security vulnerability has been fixed could be seen as another questionable element of MailChimp’s handling of security.

The fix made was to remove the file inclusion from the file and instead handle what was done with that code and additional files entirely through one file. That code begins:

<?php if(isset($_GET['error_notice'])): ?>
<div class="error notice is-dismissable">
 <?php
 switch($_GET['error_notice']) {
 case 'missing_api_key':
 _e('MailChimp says: You must enter in a valid API key.', 'mailchimp-woocommerce');
 break;

Getting a Security Review

As this result shows, our plugin security checker is already able to help identify fairly serious vulnerabilities in plugins (and we hope to continue make further improvements going forward to identify even more vulnerabilities). The results of it just point to possible security issues though, so the results need to be reviewed by someone with the proper expertise.

That is where our security reviews come in. If you are a paying customer of service, once you see that a plugin from the Plugin Directory you use contains a possible issue you can suggest it to receive a review as part of the reviews we do through that service (or if someone else has already suggested it, vote for it to receive a review to move it up in the line to receive a review). If you are not interested in the service for some reason, need a plugin not in the Plugin Directory reviewed, or need a review done immediately we also now offer to do the same type of review separately from our main service.

Companies might also want to get a security review done of their plugins to insure their developers are actually producing plugins in line with the company’s claims about their handling of security and to insure that they don’t become aware of an issue when it is already being exploited.

There are other companies that also offer to do reviews of WordPress plugins, but from what we have seen of them, not all of them seem to be qualified to do that (there is a lot of the security industry that doesn’t seem to be qualified to do anything security related). With us you can get some idea of the quality of the reviews based on reviewing the results of previous reviews we have done and the numerous vulnerabilities we have discovered.

Proof of Concept

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

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

http://[path to WordPress]/wp-content/plugins/mailchimp-for-woocommerce/admin/partials/tabs/notices.php?error_notice=../../../../../../../test

Timeline

  • November 14, 2017 – Developer notified.
  • November 14, 2017 – Developer responds.
  • November 21, 2017 – Version 2.1.2 released, which fixes vulnerability.
17 Nov

Wordfence’s Idea of Keeping “site owners safe from exploitation” Actually Puts Them At Risk

When it comes to improving the poor state of security, what can be seen over and over is that the focus needs to be on the basics. Take for instance the widely covered breach of Equifax, which was a situation where simply keeping their software up to date would have prevented the breach from happening. But the security industry isn’t focused on that and doesn’t seem to ever consider that what they are doing is far too often part of the problem, even when it impacts them.

That type of issue applies with WordPress plugins, where many hacks involve exploitation of vulnerabilities that have already been fixed. So what is probably going to provide you better protection then any security product or service would be to simply keep your plugins update at all times (many of the security plugins don’t seem to provide any protection against those vulnerabilities), which can be done with things like our Automatic Plugin Updates plugin. But telling you that doesn’t help the security industry to sell their products and services, so you don’t often here that from them.

As example let’s take a look at a post from yesterday from Wordfence about vulnerabilities in several plugins, which ends:

We encourage you to share these vulnerabilities with the larger WordPress community to help keep site owners safe from exploitation.

If you read through the rest of the post they don’t ever say that you should be keeping your plugins up to date at all times, which is actually the best advice when it comes to the vulnerabilities mentioned there. Instead they tell you the plugins they are mentioning now should be updated “immediately”, which for one of the plugins is well after a hacker had started trying to exploit one of the vulnerabilities that had been in it. The three plugins they mention are far from the only recent updated plugins that had updates that fixed security vulnerabilities, so only mentioning that people should update those isn’t all that helpful.

The rest of the post is like so much from Wordfence, mainly an ad for their services, which seems to be the real reason they want people to share it. As well get to in a moment one of the vulnerabilities in the plugins they mention is an example of the poor quality of what Wordfence paid service provides over doing the basics and the post shows again that Wordfence has very limited security knowledge, despite claims to the contrary.

A Week Behind

A week ago Thursday we discussed the details of a vulnerability that had been fixed in Formidable Forms, after Robert Mathews disclosure that it was being used to exploit vulnerability in another plugin (it is probably worth another post discussing how it was being exploited after it was fixed but before the discoverer had disclosed it). Since it was being exploited, we also added the vulnerability to the free data that comes with the companion plugin for our service, so that anyone that hadn’t updated the plugin already could have been warned about the issue last Thursday if they used our plugin. The update that fixed the vulnerability had been released a couple weeks before all that happened.

According Wordfence’s post they only got around to adding to protection against that to their paid service yesterday:

We released a firewall rule today, protecting Wordfence Premium customers from attempts to exploit this vulnerability.

That paid service is promoted by the claim that Wordfence has “unmatched access to information about how hackers compromise sites”. We would love to hear how Wordfence would try to justify that claim when they are a week behind the information that someone simply following our blog would have. That is far from the first time they have been well behind our blog, in another instances they only became aware of a vulnerability that was already being exploited because we were “making some noise about it” on this blog.

That was not the only thing that points to Wordfence not having the expertise they promote themselves as having (they claim to have a “large team dedicated exclusively to WordPress security”), take their mention of the vulnerability:

  • A preview function allowed unauthenticated users to execute an arbitrary shortcode. Normally, the use of shortcodes is restricted to site authors or administrators, as many of them could be used to exploit a site.

If they had simply read another recent post of ours they would have known that normally any one logged in to WordPress can access shortcodes, not just “site authors or administrators”:

In that access had not been there, then the vulnerability wouldn’t have existed, as those logged in to WordPress are already allowed to execute shortcodes through AJAX.

A Lack of Due Diligence or Worse

For another one of the vulnerabilities mentioned by Wordfence, they either didn’t do any due diligence or they don’t understand an even more basics element of web security:

WPVulnDB also reports that the Duplicator, running on over 1 million active sites, fixed a stored cross site scripting vulnerability affecting versions 1.2.28 and older. This report also included the code changes.

For some reason Wordfence didn’t actually link to the report on the vulnerability or credit the discoverer Ricardo Sanchez (though they managed to link to another page on their own website in that). If you look at that report you would not see any mention that this is a stored (or as we refer to them, persistent) cross-site scripting (XSS) issue, instead it indicates that it is a reflected XSS:

The XSS reflected because the values are not filter correctly:

The security implications of those two types of vulnerabilities are very different, so you would hope anyone in the security industry that provides a service related to dealing with them understands the difference.

It is possible that Wordfence doesn’t understand what they are talking about here (considering they link to changes in the code that don’t show the vulnerability they claimed), but a simpler explanation is that they just repeated the labeling of it by the WPScan Vulnerability Database:

That would be a bad idea as their data is well known to have accuracy issues, one of them lead to Wordfence recently falsely claim that the current version of a plugin contained a vulnerability that had been fixed six years ago. Does Wordfence with their “large team dedicated exclusively to WordPress security” not know this or do they not care enough to make sure they are presenting accurate information to their customers and the wider public?

A Paid Service That Really Helps

While Wordfence just got around to mentioning to people about Duplicator’s vulnerability yesterday we started notifying our customers about the issue last week when it was originally disclosed and before it was fixed. We also notified the developer that this unfixed vulnerability had been disclosed. That type of notification is something that we frequently do (we seem to be about the only ones) and can lead to unfixed vulnerabilities getting fixed within hours, which helps to protect everyone, not just our customers.

That is far from the only thing we do that others don’t, that helps everyone, one of the other things that we do that we have seen no evidence that anyone else does is that we monitor changes being made to plugins in the Plugin Directory to detect serious vulnerabilities.

Help Site Owners by Getting the Word out on Wordfence

This isn’t the first time Wordfence has put out type of post that is less focused on helping protect websites, than on marketing Wordfence. In other cases their posts are worse because they lie about what are security threats against WordPress and lead people believe that WordPress is insecure in ways it isn’t or they focus on making people reliant on them instead of actually improving WordPress, which would lead to  everyone being better protected then they would be by Wordfence.

Even worse they falsely promote their plugin with an unqualified claim that it “stops you from getting hacked”, despite them knowing this isn’t true. If the WordPress community would get involved in warning others about security companies that are so obviously dishonest, we think it would go a long way to helping to protect the public from companies like Wordfence that have shown they don’t have even their own customers best interest at heart, much less that of the larger WordPress community.

17 Nov

When Results of a Security Review Are Incorrectly Cited As Evidence a WordPress Plugin Contains a Vulnerability

As we have been working on improving our new tool for checking on the security of WordPress plugins, one of our focuses has been on making sure the results are useful (something that we have will have some news on once the developers of a couple of plugins that it has identified security issue in, have had a chance to fix them) and another has been on making sure that we are not causing plugin developers to waste their time dealing with inaccurate claims about the security of their plugins. That latter item is quite hard, as we have found in the extensive monitoring we do of claims of vulnerabilities in WordPress plugins for our service that often you have people making claims that have little to do with the underlying information they are citing.

As an example of what goes on, let’s take a claim that we recently looked at involving the plugin Really Simple CAPTCHA. A thread was started on the wordpress.org forum for the plugin with the title “High risk vulnerabilities detected”, which stated that:

Hi,
I’m getting alert message that there are “High risk vulnerabilities detected” at this plugin pointing SQL injection Possible. Please have a look and prevent from it.

The developer responded:

Who detected it?

As you see in its source code, it has no space to make any SQL Injection possible.

We reviewed the code and confirmed that it doesn’t make any connection to the database, much less has SQL queries that would possibly be susceptible to SQL injection.

Instead of just blowing the person off at that point, the developer had asked them for more information and the original poster responded:

Hi,

Thanks for your immediate response, i have added the link of screenshot.

https://ibb.co/hKjRkb

That link goes to a page with an image with the results of a series of scans, including the following one:

Those results are from a scan from outside of the website from what looks to be a scan by Beyond Security.

We are not familiar with results from Beyond Security, so things may be different with their scanner, but our experience with other scanners of this type is that they can produce quite bad false positives in terms of claimed SQL injection vulnerabilities, so it wouldn’t be clear just based on the results there is there was truly that type of issue at all.

What is more important in the context of this post, is that the results don’t make any claim that a particular plugin was the cause of this. Since the scan does not involve scanning the underlying files it wouldn’t even be possible for it to tell that. This plugin works with other plugins, not as standalone item, so we don’t how the person making the claim would have decided it must be Really Simple CAPTCHA that caused this.

17 Nov

The Developers of WordPress Security Plugins Should Be Setting the Example of Good Security Practices

Recently someone left a negative review of the companion plugin for our service, which seemed more like it was just someone looking to bash us than a legitimate review of the plugin (based on another review of theirs they are a paying customer of Wordfence, which explains a lot). The reviewer didn’t even seem to be all that aware of what the plugin did as they said “just tells me that something is bad” or what we do. Part of their review was:

Maybe it’s just the authors continued bashing of every competitor in the security industry that turns me off. Why isn’t the author doing more to help with the security community instead of bashing everyone?

We are not sure if they meant that we should be helping other companies to do their job, but that is how it reads. If that is the case, a better solution seems to be for companies to not to offer to do things they don’t have the capability to do, instead of expecting more capable companies to do their work for them. Beyond that, it isn’t like we can force companies to improve their practices. We can suggest things, but others have to choose if they want to be setting an example of what to do instead of what not to do.

An example of where a company in the security industry is not following advice we have given comes from an unfixed reflected cross-site scripting (XSS) vulnerability that has been disclosed in the plugin Appointments, which was discovered by Ricardo Sanchez. That plugin is developed by WPMU DEV, who also makes the Defender security plugin. They also promote their plugins as:

Guaranteed to work, always updated, top quality plugins. Beautifully coded, packed with features, and easy to use.

When we went to look at the underling code causing that so that we could provide a suggested solution when we notified WPMU DEV of the disclosure (we actually can help other security companies as well as pointing out the problems with them), we noticed that file probably shouldn’t have been included with the plugin.

The file is a test file that comes with a third-party library, which isn’t hard to spot based on the directories it is inside of: /bower_components/jquery-ui-multiselect-widget/tests/visual/formsubmission.php

After spotting an issue just like this during a security review we wrote a Security Tip for Developers post back in April titled Remove Testing Files from Third Party Libraries Included in Your Plugin.