08 Dec

We Now Offer Our Plugin Vulnerabilities Service on a Pro Bono Basis for Human Rights Groups

Through our main business we have offered pro bono service to human rights groups for years and we had recently been thinking about offering this service in that fashion as well. Then we noticed that Human Rights Day would be coming up (it happens on Sunday), which seemed like a great reason to go ahead and launch that.

With our service the administrators of WordPress websites get notified if plugins being used on the website contain publicly disclosed vulnerabilities. While we try to work with developer to get any of those vulnerabilities that haven’t been fixed, promptly fixed (and can sometimes accomplish that very quickly), they don’t always get fixed in a timely manner or in some cases, ever. In those cases we are there to help the administrators make the best decision on how to handle the situation. In a lot of cases we can provide a workaround until the issue is fixed in a new version, though in some cases moving off the plugin is probably the best option. The service also provides access to our data set of vulnerabilities so that administrators can better access the security of plugin they or might want to use and it can also be used to determine if a vulnerability in a plugin was likely part of how a website got hacked.

For human rights groups looking to take advantage of this offer, just get in touch with us and we will provide you the information to set up a free account with the service.

08 Dec

Not Really a WordPress Plugin Vulnerability – Week of December 8, 2017

In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we have been releasing posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. We have been thinking that providing information on why those are not included in our service’s data could be useful, so we are trying out putting a weekly post when that occurs detailing those issues.

Directory Traversal Vulnerability in WooCommerce

A lot of reports of vulnerabilities that turn out to be false at least seem to have a valid basis, but occasionally you have truly strange ones. The claim of a directory traversal vulnerability in WooCommerce falls into the latter category. The claim made is:

Identifying woo commerce theme pluging properly sanitized against Directory Traversal,even the latest version of WordPress with woocommerce can be vulnerable.

Directory traversal refers to the ability to move outside of a specified directory, it isn’t a vulnerability on its own, just something that could be a piece of a vulnerability. An example of where that could come in to play as a vulnerability would be if you had code that allows downloading files from a particular directory and directory traversal could be used to download files outside of it.

The proof of concept included with the claim simply makes a request to the URL /wp-content/plugins/woocommerce/templates/emails/plain/. If you were to take a look at the latest version of WooCommerce you would see that in that directory there is no index file that would be served when requesting that, so there couldn’t be any code running for there to be directory traversal. There isn’t anything in the proof of concept code that shows an attempt to do anything related to directory traversal either.

What looks to be going on here is that the person behind this thinks that seeing a list of the files in the directory, if a server is configured to do that when there isn’t an index file, would be a vulnerability here. On the same vulnerability database we saw their claim of a directory traversal vulnerability they had submitted a Google dork for “intext:/wp-content/plugins/woocommerce/templates/emails/plain/” and wrote:

When you dork with this,it will generate juciy information in parent directory , for best practice filter according to the country .

That isn’t true though. You should already know what the files that are that directory since the directory shouldn’t contain files that don’t come with the plugin (custom template files would be located in theme being used not in the plugins directory structure).

Somehow, despite the issue being claimed here not actually being a vulnerability on in its own, this has been assigned a CVE number.

08 Dec

It Would Probably Be a Good Idea to Be Moving Off of the Captcha WordPress Plugin

The takeover of popular WordPress plugins and then use of them for nefarious purposes has been a major issue when it comes to the security of WordPress plugins this year. Even if the takeover is not done with malicious purposes in mind, a new developer that doesn’t know what they are doing can take an otherwise relatively secure plugin and in a short time make tens or hundreds of thousands of websites insecure. At least that latter issue is true of the plugin Captcha.

The plugin Captcha has 300,000+ active installations according to WordPress.org, including this website and another of ours. Back in July the plugin was handed over from the previous developer, BestWebSoft, to another entity. Then in September an update to the plugin caused the admin area of our other website using the plugin to not function, we were not alone in that. It was only at that point that BestWebSoft mentioned that ownership had been transferred, though the new developer isn’t named:

Recently, we’ve handed over all the rights to use and manage the free version of Captcha plugin. Now, it has new owners which are responsible for the updates, troubleshooting and support any processes connected with its free version.

Going back to the commit when that change occurred, the copyright listing on files was changed from listing BestWebSoft as being the copyrighter to no one listed. The new author of the plugin is “wpdevmgr2678”, which doesn’t exactly project a professional image of the new developer.

The issue of causing the admin area to be inaccessible was then fixed. But then another update caused the admin area of this website to be inaccessible yesterday. As we started to look in to what all was going on, one of things we noticed was the latest review of the plugin on the Plugin Directory:

Since the switch from BestWebSoft to Simplywordpress, the quality of this plugin has gone downhill, with numerous problems or issues introduced with what seems like every update. I no longer recommend using this plugin.

For example:

  • Formidable Forms discontinued its Math Captcha integration plugin with this plugin because of breaking updates (like reversing “cptch” to “hctpc” in the code for no discernible reason in an update)
  • As of update 4.4.4 adds ~500 queries associated with visitor tracking or some other nonsense, with many repeated queries, adding over 100ms to every page generation time (not even Memcached could help)
  • Increasingly poor English wording and grammar, leading to possible confusion

The second issue mentioned concerned us and as we will get to in a bit lead to us finding that plugin has multiple security issues caused by that. The third issue also seemed concerning based on us doing some looking into the developer at that point.

The profile page for the developer on wordpress.org lists them as being located in California. Their website, which was registered the day after the transfer of the plugin appears to have happened, though lists an address in the United Kingdom. In one of the prominent instances of a malicious takeover of a plugin there was similar situation where the developers were listing different locations as their supposed location in various places, so that raises a red flag. The server the website is hosted in located in Canada, for what that is worth.

Based on one of the comments from first time the plugin was making admin areas inaccessible the person responding there would seem to not be the person doing the development:

Hey guys thanks as you can see were aware of the plugin issues problem please remove it and accept my sincerest apologies.

I will be creating a mailbox where you can tell the Dev he is usless personally or maybe a skype group

On the website of the plugin’s developer they market their skills as being different than the actual quality of the changes being made to the plugin have shown. From the homepage there is this:

 We are professional programmers who simply love WordPress and can’t wait to make a custom designed plugin for you!

And this:

Hire a team not a guy working in his mom’s basement.

Also on the homepage they twice mention a security service included with their plugins:

With every plugin we have included our “simply-secured” service which helps protect your website from threats.

Every plugin comes with our simply-secured service which protects your site from threats.

Though as we will get to in a moment their Captcha plugins actual introduces security vulnerabilities.

On their services page they make several claims that don’t match the real results with the Captcha plugin:

WP plugin testing and validation

At Simply WordPress, we never improvise on a whim. While we develop fully customized WP plugins, we make sure they can pass validation by WordPress. We build up on the core WP files and add the functionalities you need.

 

Our team is on the ball 24/7 and you can be sure that nothing slips under our radar. If there is so much as a glitch, we fix it right away so your website can keep bringing you profit!

Also worth noting is that on their contact page, the captcha is not generated by someone else’s captcha plugin.

As of today the plugin has been removed from the Plugin Directory, though WordPress continues to not to handle that situation properly and inform people why a plugin has been closed. In this case the developer states that:

We just wanted to let you know the plugin wont be available to be downloaded for a few days as WordPress as asked us to change our brand name as it contains the word “wordpress” which goes against there terms. Obviously we were unaware of this issue and will get this fixed and be back shortly.

Failing at Security Basics

Back in October we announced a new tool that does limited automated security testing of WordPress plugins, so the public can get some idea if a plugin might contain security issues that warrant further review. One of the things that tool checks for is if the plugin registers AJAX accessible function to be accessible to those not logged in as well to those logged in. While there are perfectly safe situations where that happens, what we have found with many vulnerabilities we and others have discovered, is that often time’s plugins are making functionality accessible to those not logged in that they don’t need access to. A month ago we noted how that situation lead to attempts to utilize a vulnerability that had been in the plugin Formidable Forms to exploit a vulnerability in another plugin. That also turns out to be an issue with Captcha starting with version 4.3.6.

As part of the “visitor tracking” mentioned in the review previously mentioned, the file /live-trafic-lib/cptch_traffic_functions.php was added to the plugin and that makes several functions available to anyone whether they are logged in or not.

One of those is the function cptch_get_traffic_record_callback():

911
912
913
add_action( 'wp_ajax_cptch_get_traffic_record',        'cptch_get_traffic_record_callback' );
 
add_action( 'wp_ajax_nopriv_cptch_get_traffic_record', 'cptch_get_traffic_record_callback' );

When that function is requested it doesn’t do any checks on who is making the request before displaying the live traffic. So anyone can monitor visits to the websites, despite it looking like only Administrators are intended to be able to do that.

Other functions that are available allow anyone to block or unblock IP address or whole countries from logging in to the website or utilizing anything that requires a captcha.

What are missing here are not advanced security measures, just the basics, so it looks like the developer doesn’t have a basic understanding of how the security of WordPress plugins should be handled.

Some of the code in those functions isn’t properly handling things to protect against SQL injection, though in our quick check we didn’t see a way it could be exloited.

We have notified the developer of this issues. Due to our overall concern with the plugin and the fact that is currently removed from the Plugin Directory, we decided not to hold back disclosure as we would normally do.

Phoning Home

After you upgrade the plugin to the most recent version an “urgent” message is shown:

At the same If you visit the plugin’s admin page you will receive the following message:

If you click the “Recommend Settings” button shown in the first image or the “Select Prefered Settings” button shown in the second, the plugin will start contacting the developer’s website for a list of blacklisted IP addresses and pass along the site’s address. That would seem to be in violation of the guidelines for plugin’s in the Plugin Directory since there doesn’t seem proper notification of that:

In the interest of protecting user privacy, plugins may not contact external servers without the explicit consent of the user via requiring registration with a service or a checkbox within the settings. This method is called ‘opt in.’ Documentation on how any user data is collected, and used, should be included in the plugin’s readme, preferably with a clearly stated privacy policy.

This restriction includes the following:

  • No unauthorized collection of user data. Users may be asked to submit information but it cannot be automatically recorded without explicit confirmation from the user.
  • Intentionally misleading users into submitting information as a requirement for use of the plugin itself is prohibited.
  • Images and scripts should be loaded locally as part of the plugin whenever possible. If external data (such as blocklists) is required, their inclusion must be made clear to the user.
  • Any third party advertisement mechanisms used within the plugin must have all tracking features disabled by default. Advertisement mechanisms which do not have the capability of disabling user tracking features are prohibited.

The sole exception to this policy is Software as a Service, such as Twitter, an Amazon CDN plugin, or Akismet. By installing, activating, registering, and configuring plugins that utilize those services, consent is granted for those systems.

Moving Off This Plugin

At this point there is a new developer of this plugin that at best isn’t doing enough testing before releasing updates and is introducing other issues to the plugin, so it seems the best thing to do would be to move off of the plugin.

On our websites we have moved back to the last version by the previous developer until we can find a more permanent replacement.

Proof of Concept

The following proof of concept will cause the latest traffic to the website to be shown.

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?action=cptch_get_traffic_record" method="POST">
<input type="hidden" name="page" value="1" />
<input type="submit" value="Submit" />
</form>
</body>

Timeline

  • December 8, 2017 – Developer notified.
05 Dec

WordPress Plugin Security Review: Amazon Web Services

For our sixteenth security review of a WordPress plugin based on the voting of our customers, we reviewed the plugin Amazon Web Services.

If you are not yet a customer of the service you can currently sign up for the service for half off and then start suggesting and voting on plugins to get security reviews. For those already using the service that haven’t already suggested and voted for plugins to receive a review, you can start doing that here. You can use our new tool for doing limited automated security checks of plugins to see if plugins you are using have possible issues that would make them good candidates to get a review. You can also order a review of a plugin separately from our service.

The review was done on version 1.0.4 of Amazon Web Services. We checked for the following issues during this review:

  • 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
  • Security issues with functions accessible through any of the plugin’s shortcodes
  • Security issues with functions accessible through the admin_action action
  • Security issues with functions accessible through the admin_init action
  • Security issues with import/export functionality
  • Security issues with usage of is_admin()
  • Host header injection vulnerabilities
  • Lack of protection against unintended direct access of PHP files
  • Insecure and unwarranted requests to third-party websites

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. Most of the files only define classes, so there is nothing exploitable if they are accessed and adding a restriction has limited value. Other files though generate parts of admin pages and code will run when those are accessed. While in this case there was nothing that looks like a security issue due to that, in recent times we have added new vulnerabilities to our date set that were caused by files of that type where limiting access would have lessened the risk of the vulnerabilities.

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.
01 Dec

Not Really a WordPress Plugin Vulnerability – Week of December 1, 2017

In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we have been releasing posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. We have been thinking that providing information on why those are not included in our service’s data could be useful, so we are trying out putting a weekly post when that occurs detailing those issues.

Cross-Site Scripting (XSS) Vulnerability in amtyThumb and amtyThumb posts

The claim of a cross-site scripting (XSS) vulnerability in amtyThumb posts is a bit confusing as it is stated that

amtyThumb posts Plugin is prone to a stored cross-site scripting vulnerability because it fails to sufficiently sanitize user-supplied data.

and

The XSS reflected because the values are not filter correctly:

So they are claiming it is a stored (or as we refer to that type of vulnerability, persistent) XSS, a reflected, or maybe both.

The proof of concept given is:

/wordpress/wp-content/plugins/amty-thumb-recent-post/amtyThumbPostsAdminPg.php?”><script>alert(“XSS”)</script>=1

Looking at the underlying code in the file /amty-thumb-recent-post/amtyThumbPostsAdminPg.php it looks like what they are claiming is the vulnerability are in two instances of the following code:

echo str_replace( '%7E', '~', $_SERVER['REQUEST_URI']);

That could would output the variable $_SERVER[‘REQUEST_URI’] without escaping it, which theoretically could lead to reflected cross-site scripting (XSS). But, as we wrote in another of these series of post, that wouldn’t normally be an issue:

The claim that $_SERVER[‘REQUEST_URI’] is unescaped is partially true. While there isn’t any escaping of that done by PHP or WordPress, the value would normally be encoded due to URLs being encoded when sent from web browsers. That would act as escaping. That would normally mean that reflected cross-site scripting (XSS) could not occur due to this issue.

So there doesn’t appear to be the vulnerability as claimed, though there is a reflected XSS elsewhere in the code that we are in the process of trying to notifying the developer of.

After we wrote up the above details, we ran across a related claim of the vulnerability in the plugin plugin amtyThumb, which confirmed our analysis of what was claimed to be an issue in the other plugin. That issue has been given a CVE, despite really not existing either.

01 Dec

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in User Role Editor

From time to time a vulnerability is fixed in a plugin without the discoverer putting out a report on the vulnerability and we will put out a post detailing the vulnerability so that we can provide our customers with more complete information on the vulnerability.

All three changelog entries for version 4.38 of the plugin User Role Editor are security related, possibly indicating that some sort of ...


To read the rest of this post you need to have an active account with our service.

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

If you are not currently a customer, when you sign up now you can try the service for half off (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 security researcher please contact us to get free access to all of our Vulnerability Details posts.

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).

01 Dec

Vulnerability Details: Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in Special Text Boxes

Recently the web scanner service Detectify has been vaguely disclosing minor vulnerabilities in a number of WordPress plugins. It seems like they are aware that they could notify the developers of these, but usually haven’t been doing it. One of the more recent batch was an “Authenticated XSS” vulnerability in the plugin Special Text Boxes.

In a previous post we looked at a reflected cross-site ...


To read the rest of this post you need to have an active account with our service.

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

If you are not currently a customer, when you sign up now you can try the service for half off (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 security researcher please contact us to get free access to all of our Vulnerability Details posts.

01 Dec

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in Special Text Boxes

Recently the web scanner service Detectify has been vaguely disclosing minor vulnerabilities in a number of WordPress plugins. It seems like they are aware that they could notify the developers of these, but usually haven’t been doing it. One of the more recent batch was an “Authenticated XSS” vulnerability in the plugin Special Text Boxes.

Based on the previous instances we figured that would refer to ...


To read the rest of this post you need to have an active account with our service.

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

If you are not currently a customer, when you sign up now you can try the service for half off (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 security researcher please contact us to get free access to all of our Vulnerability Details posts.