11 Jan

Closures of Very Popular WordPress Plugins, Week of January 11

While we already are far ahead of other companies in keeping up with vulnerabilities in WordPress plugins (amazingly that isn’t an exaggeration), in looking in to how we could get even better we noticed that in a recent instance were a vulnerability was exploited in a plugin, we probably could have warned our customers about the vulnerability even sooner if we had looked at the plugin when it was first closed on the Plugin Directory instead of when the vulnerability was fixed (though as far as we are aware the exploitation started after we had warned our customers of the fix). So we are now monitoring to see if any of the 1,000 most popular plugins are closed on the Plugin Directory and then seeing if it looks like that was due to a vulnerability.

This week four of these plugins was closed and two have been reopened.

Ad Inserter

Ad Inserter, which has 200,000+ installations, was closed on Monday. According to the developer it was not closed due a policy guidelines violation.

In looking over the plugin we didn’t find any obvious security issues and the changes made to the plugin between its removal and return don’t look security related.

It was reopened on Tuesday.

KingComposer

KingComposer, which has 80,000+ installations, was closed on Monday. That was due a vulnerability we disclosed the same day (strangely another plugin with the same number of installs and same vulnerability also disclosed in the same post was not closed and remains vulnerable). The developer didn’t give an accurate answer when asked why it was closed, stating:

currently the plugin kingcomposer is appearing some errors need to be fixed so we have to close the download to perform error correction,

They wouldn’t have been the ones that closed it and fixing the vulnerability wouldn’t have required them to close it, just release a new version that fixes the issue. That seems like a good reason for WordPress to provide people accurate information n why plugins have been removed.

It was reopened on Tuesday.

Storefront Product Pagination

Storefront Product Pagination, which has 40,000+ installs, was closed on Thursday. The developer removed the plugin from the Plugin Directory.

In looking over the plugin we didn’t find any obvious security issues.

Storefront Sticky Add to Cart

Storefront Sticky Add to Cart, which has 50,000+ installs, was closed on Thursday. The developer removed the plugin from the Plugin Directory.

In looking over the plugin we didn’t find any obvious security issues.

11 Jan

Not Really a WordPress Plugin Vulnerability, Week of January 11

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 release 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. For those that don’t rise to level of getting their own post we now place them in a weekly post when we come across them.

Cross-Site Scripting (XSS) in Google XML Sitemaps

The report of a claimed cross-site scripting (XSS) vulnerability in Google XML Sitemaps states:

In the case where multiple administrators manage the WordPress site with the affected plugin, an administrator with malicious intent may embed an arbitrary script into the plugin settings page. The embedded script may be executed when another administrator logs in and browses the page.

If you have an Administrator with malicious intent the security of plugins really isn’t going to matter since among other things the Administrator can install arbitrary code on the website. What might be of concern is if there was a lack of protection cross-site request forgery (CSRF), since that could cause an Administrator to take an action they didn’t intend, but that wasn’t the case with the relevant functionality.

11 Jan

Our Proactive Monitoring Caught a Remote Code Execution (RCE) Vulnerability in an Unreleased Version of MailPress

In a reminder of the negative impact of WordPress intentionally leaving those using vulnerable plugins unaware of it, there are still 3,000+ active installs, according to wordpress.org, of the plugin MailPress. Back in July of 2016 we noted that it appeared that hackers were targeting it, while disclosing a vulnerability we had found in it after noticing the apparent hacker interest. At the time the plugin had already been removed from the Plugin Directory and remains so today. The hacker interest has continued as well, as multiple times in the last week we have seen probing for usage of the plugin on our website.

In the meantime the developer has at various times submitted changes to the plugin and one of the recent changes was flagged by our proactive monitoring of changes being made to WordPress plugins to try to catch serious vulnerabilities when they are introduced in to plugins. Maybe not surprisingly considering that the plugin appears to have had a vulnerability that was serious enough that hackers would be interested in exploiting it and that the developer has yet to get the issue resolved that lead to the plugin being removed, it turns out that versions of the plugin that have not been released contain a remote code execution vulnerability.

Due to the moderators of the WordPress Support Forum’s continued inappropriate behavior we are full disclosing vulnerabilities in protest until WordPress gets that situation cleaned up, so we are releasing this post and then only trying to notify the developer through the WordPress Support Forum. You can notify the developer of this issue on the forum as well. Hopefully the moderators will finally see the light and clean up their act soon, so these full disclosures will no longer be needed (we hope they end soon). You would think they would have already done that since a previously full disclosed vulnerability was quickly on hackers’ radar, but it appears those moderators have such disdain for the rest of the WordPress community that their continued ability to act inappropriate is more important that what is best for the rest of the community.

Technical Details

In the file /Mailpress.php the plugin registers the function mp_cron() to be accessible through WordPress’ AJAX functionality to those logged in to WordPress as well as those not logged in:

91
92
add_action( 'wp_ajax_mp_cron',			array( __CLASS__, 'mp_cron' ) );
add_action( 'wp_ajax_nopriv_mp_cron',		array( __CLASS__, 'mp_cron' ) );

That function will pass a value specified by the GET input “hook” to the WordPress function do_action(), which will “execute functions hooked on a specific action hook”:

345
346
347
348
public static function mp_cron() //wp_cron
{
	define( 'DOING_CRON', true );
	do_action( $_GET['hook'] );

Proof of Concept

The following proof of concept will cause the WordPress action/function do_feed_rss to run.

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

http://[path to WordPress]/wp-admin/admin-ajax.php?action=mp_cron&hook=do_feed_rss
11 Jan

The Mess that is Imperva’s Claim That WordPress Vulnerabilities Tripled in 2018

A good rule of thumb based on what we have seen over the years is that stats on security are probably not accurate. So it isn’t surprising that when we looked into a claim by a company named Imperva that WordPress vulnerabilities tripled in 2018, it was a mess, but that hasn’t stopped security journalists from repeating the claim.

When we ran across the claim our first question was what the source of their data was and looking at Imperva’s post they only give a vague explanation:

 To do this, we use internal software that collects information from various data sources such as vulnerability databases, newsletters, forums, social media and more, integrates it into a single repository, and assesses each vulnerability’s priority.

They provide this chart “Top 10 vulnerable WordPress plugins”:

Looking around various source to try to find a match or understand their sourcing we couldn’t find anywhere near 11 reports of vulnerabilities in the first plugin shown, Event Calendar WD. In fact we only found one, if you count each change made related to that vulnerability you would to more than 11, so we can’t figure out where the figure might have come from. What makes that more problematic is that the other portions of their post don’t seem to be written by someone that understands the topic at hand, so the accuracy of the data seems suspect to us.

Speaking of the problematic portions, what really makes this a mess is that this company is mixing up vulnerabilities discovered in software with other things. Right above the chart they wrote this:

In Figure 8 below, you can find the ten WordPress plugins with the most vulnerabilities discovered in 2018. Please note, that these are not necessarily the most-attacked plugins.

But at another point in their post they write this:

Despite the slowed growth in new plugins, the number of WordPress vulnerabilities tripled! The explanation for this could either be the code quality of the plugins, or the fact that WordPress is such a popular CMS, which motivate more attackers to develop dedicated attack tools and try their luck searching for holes in the code.

Since this is supposed to be measure of vulnerabilities discovered the explanation for the claimed tripling could, say, have to do with improvements in spotting vulnerabilities, not that there were more vulnerabilities. That they don’t seem to understand that raises serious questions about their whole endeavor.

What seems more important is the hypothesis that “more attackers to develop dedicated attack tools and try their luck searching for holes in the code” as that makes no sense, since the vast, vast majority of vulnerabilities being discovered are not connected to attackers. Based on what we saw during the year, the new vulnerabilities being discovered by attackers that would lead others to notice the issue (its possible that more advanced attackers are exploiting vulnerabilities that are not then spotted) would run in the tens of vulnerabilities at most (and it probably in the single digits), which is nowhere near the 542 they list as the total.

Bad Journalism

As example of example of the bad journalism based on that, take Lindsey O’Donnell at Threatpost on this. The quality of the journalism is pretty telling from this at the bottom of the post:

Automattic, the owner of WordPress, did not immediately respond to a request for comment from Threatpost.

Automattic isn’t the owner of WordPress, though you might think otherwise based on what has happened related to Gutenberg, so asking them for comment is odd.

The start of the post is also quite problematic:

Despite fewer plugins being added to WordPress last year, the CMS saw an astounding tripling of vulnerabilities in its platform in 2018.

Vulnerabilities in popular content management system (CMS) WordPress are growing at a staggering rate, almost tripling in 2018, according to new web application bug research released Wednesday.

Again these are vulnerabilities discovered, so the number of new plugins should not necessarily have any correlation and the increase in discoveries could be a good thing, but that isn’t ever grappled with or discussed in their post.

10 Jan

WordPress Plugin Developers Don’t Do a Good Job of Making Sure There Plugins Are Free of Vulnerabilities They Know of

Our proactive monitoring of changes being made to WordPress plugins to try to catch serious vulnerabilities when they are introduced in to plugins recently caught a good example of an ongoing problem we see when it comes to the developers of WordPress plugins, a failure to make sure that security vulnerabilities that have been in their plugins have been fully removed. In some cases that involves them only fixing one instance of a vulnerability in a plugin and not making sure that there are not any others in the plugin, in others, like this situation, making sure that the vulnerability isn’t in other of their plugins.

Back in October we disclosed a cross-site request forgery (CSRF)/local file inclusion (LFI) vulnerability in the plugin Companion Auto Update. We recently started checking for that type of vulnerability with our proactive monitoring and it quickly lead to us finding that another plugin by the same developer, Companion Sitemap Generator, contains it as well due to the same code that caused the issue with their other plugin.

Clearly relying on developer’s to keep their plugin secure when they fail to make sure to avoid issue they know have been in their plugins leaves a lot to be desired and that is where we come in. Our Plugin Security Checker will alert you if plugins you use possibly contain the same type vulnerable code (and possibly contain more serious vulnerable code). From there if you are a paying customer of our service you can suggest/vote for it to receive a security review that will check over that or you can order the same type of review separately.

Due to the moderators of the WordPress Support Forum’s continued inappropriate behavior we are full disclosing vulnerabilities in protest until WordPress gets that situation cleaned up, so we are releasing this post and then only trying to notify the developer through the WordPress Support Forum. You can notify the developer of this issue on the forum as well. Hopefully the moderators will finally see the light and clean up their act soon, so these full disclosures will no longer be needed (we hope they end soon). You would think they would have already done that since a previously full disclosed vulnerability was quickly on hackers’ radar, but it appears those moderators have such disdain for the rest of the WordPress community that their continued ability to act inappropriate is more important that what is best for the rest of the community.

Technical Details

The issue occurs in a couple of files in the plugin. One of those is /dashboard/sitemap/start.php. In that file if the GET input “tabbed” exists it will be included (through use of the require() function):

21
22
23
24
25
26
27
if( !isset( $_GET['tabbed'] ) ) { 
 
	require( 'dashboard.php' );
 
} else {
 
	require( $_GET['tabbed'].'.php' );

Through path traversal that code could allow any file with a .php extension to be included, causing the code in the specified file to run.

That file is run when the function csg_dashboard() is run:

224
225
function csg_dashboard() {
	require( 'dashboard/sitemap/start.php' );

And that in turn runs when accessing the plugin’s Sitemap page, which is accessible to those with “manage_options” capability:

182
add_submenu_page( 'tools.php', __('Sitemap', 'companion-sitemap-generator'), __('Sitemap', 'companion-sitemap-generator'), 'manage_options', 'csg-sitemap', 'csg_dashboard' );

Normally only Administrators have that capability. Seeing as Administrators can normally do whatever they want, them intending to use that to cause a file to be included wouldn’t be a vulnerability since among other things they could normally remove security code that would restrict something like this from being possible or just upload a plugin that runs any code they want already.

But in this case, an attacker can cause this to happen without the Administrator intending it since if the attacker could get the Administrator to visit a URL they specify they can cause the local file inclusion vulnerability to be exploited.

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, when logged in as an Administrator.

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

http://[path to WordPress]/wp-admin/tools.php?page=csg-sitemap&tabbed=..%2Ftest
10 Jan

WordPress Plugin Security Review: WordPress Notification Bar

Recently we started reviewing the security of the WordPress plugins we use, and for our third review we had checked over the security of the plugin WordPress Notification Bar.

If you want a security review of plugins you use, when you become a paying customer of our service you can start suggesting and voting on plugins to get security reviews from us. 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 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.3.9 of WordPress Notification Bar. 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 the frontend portions of the plugin and in the admin portions accessible to users with the Author role or below
  • Cross-site request forgery (CSRF) vulnerabilities in the admin portion of the plugin
  • 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()
  • Security issues with usage of add_option(), delete_option(), and update_option()
  • Host header injection vulnerabilities
  • Lack of protection against unintended direct access of PHP files
  • Insecure and unwarranted requests to third-party websites
  • Any additional possible issues identified by our Plugin Security Checker

Results

We found a couple of really minor issues. After we notified the developer of the results they replied the same day that changes would be made in relation to those, though in the week since then that has yet to happen.

Lack of Capabilities Check When Resetting Settings

The plugin has a function reset_defaults(), which is accessible to anyone as it runs during admin_init, so it should check to make sure the request the reset is coming from a user with the proper capability. The function does check for a valid nonce, so in normal circumstances it shouldn’t be possible for those without the proper capability to get access to a valid nonce, but that shouldn’t be relied on alone.

Somewhat oddly the while the reset capability has existed since the first version of the plugin, the code that would provide the frontend for that has been commented out since the first version as well, so it has never been accessible through normal usage of the plugin. In the developer’s response they mentioned that they had removed that due to the limited number of settings.

Lack of Protection Against Direct Access to PHP Files

The plugin’s .php files lack code at the beginning of the files to restrict direct access to them.  We didn’t see anything that could be exploited in the files without the restriction in place.

08 Jan

Vulnerability Details: Cross-Site Request Forgery (CSRF)/SQL Injection in Ninja Forms

This Vulnerability Details post about a vulnerability in the plugin Ninja Forms provides the details of a vulnerability we didn't discover and access to it is limited to customers of our service, unlike the posts on vulnerabilities we have discovered, which are freely available and give you an idea of what information is provided in the details posts as well.

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

If you are not currently a customer, you can sign up here. There are a lot of other reason that you will want to sign up beyond access to posts like this one, including that you would have already been warned about this vulnerability if your website was vulnerable due to it.

If you are a WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.

07 Jan

Our Plugin Security Checker Could Have Warned You About the Possibility of Vulnerabilities in a Couple of WordPress Plugins with 80,000 Installs

On Friday we noted in our post detailing a reflected cross-site scripting (XSS) vulnerability in the WordPress plugin Ninja Forms, which has 1+ million active installations according to wordpress.org, that our Plugin Security Checker,  which is a tool that allows anyone to see if there are possible security issues in WordPress plugins that could use further investigation, had been updated to better catch that type of issues like that based on variations that existed in that plugin’s code from how things are normally done.

We were also interested in seeing if there were other popular plugins that might have similarly vulnerable code that had yet to be have been caught by anyone due those variations, so we ran the updated check from the Plugin Security Checker over the 1,000 most popular plugins in the WordPress Plugin Directory. What we found was there are a number of those plugins that look like they might be vulnerable, though most of them didn’t contain the variations, so our Plugin Security Checker would have already spotted them.

We took a look at two of the most popular plugins, both with 80,000+ installations, with the possible issue and found that both were in fact vulnerable. That is yet another good reason to check plugins you use through our Plugin Security Checker since it will alert you if plugins you use possibly contain a similar issue (and possibly contain more serious vulnerabilities). From there if you are a paying customer of our service you can suggest/vote for it to receive a security review that will check over that or you can order the same type of review separately.

Due to the moderators of the WordPress Support Forum’s continued inappropriate behavior we are full disclosing vulnerabilities in protest until WordPress gets that situation cleaned up, so we are releasing this post and then only trying to notify the developer through the WordPress Support Forum. You can notify the developer of this issue on the forum as well. Hopefully the moderators will finally see the light and clean up their act soon, so these full disclosures will no longer be needed (we hope they end soon). You would think they would have already done that since a previously full disclosed vulnerability was quickly on hackers’ radar, but it appears those moderators have such disdain for the rest of the WordPress community that their continued ability to act inappropriate is more important that what is best for the rest of the community.

Anti-Spam by CleanTalk

In plugin Anti-Spam by CleanTalk the issue appears to exist in several places, but we happened to check the following line in the file /inc/cleantalk-comments.php:

88
<input id="ct_date_range_from" class="ct_date" disabled="disabled" readonly="readonly" type="text" value="<?php echo isset($_GET['from']) ? $_GET['from'] : ''; ?>" />

That code will output the value of the GET input “from” without escaping it, which is a reflected cross-site scripting (XSS) vulnerability, if it exists, when visiting the plugin’s “Find spam comments” admin page.

Proof of Concept

The following proof of concept will cause any available cookies to be shown in an 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/edit-comments.php?page=ct_check_spam&from="><script>alert(document.cookie);</script>

KingComposer

In the plugin KingComposer there are two lines of code that are potentially vulnerable, but one of them doesn’t lead to a vulnerability since other code in the same file limits what values can be output. That doesn’t appear to have been done with a thought to security, since several lines later in the code the issue is there again without that type of protection being elsewhere in the code. The issue occurs in the file /includes/extensions/kc.screen.tmpl.php on the following line:

91
<input class="wp-filter-search" name="q" type="search" value="<?php echo isset($_GET['q']) ? $_GET['q'] : ''; ?>" placeholder="<?php _e('Search Extensions', 'kingcomposer'); ?>" aria-describedby="live-search-desc" />

That code will output the value of the GET input “q” without escaping it, which is a reflected cross-site scripting (XSS) vulnerability, if it exists, when visiting the plugin’s “Extensions” admin page.

Proof of Concept

The following proof of concept will cause the any available cookies to be shown in an alert box, when logged in as an Editor. 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?tab&page=kc-extensions&q="><script>alert(document.cookie);</script>
04 Jan

Vulnerability Details: Reflected Cross-Site Scripting (XSS) in Ninja Forms

This Vulnerability Details post about a vulnerability in the plugin Ninja Forms provides the details of a vulnerability we didn't discover and access to it is limited to customers of our service, unlike the posts on vulnerabilities we have discovered, which are freely available and give you an idea of what information is provided in the details posts as well.

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

If you are not currently a customer, you can sign up here. There are a lot of other reason that you will want to sign up beyond access to posts like this one, including that you would have already been warned about this vulnerability if your website was vulnerable due to it.

If you are a WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.