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.

Concerned About The Security of the Plugins You Use?

When you are a paying customer of our service you can suggest/vote for the plugins you use to receive a security review from us . You can start using the service for free when you sign up now.