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.

21 Dec

Not Really a WordPress Plugin Vulnerability, Week of December 21

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.

Shell Upload in Dean’s FCKEditor For WordPress and Monsters Editor for WP Super Edit

Related reports of claimed shell upload vulnerabilities were released for Dean’s FCKEditor For WordPress and Monsters Editor for WP Super Edit this week. The claim is that both of them contain

a very serious vulnerability that allowed hackers to gain full control a modify, upload and execute files on any website running WordPress. With the
plugin installed on a certain website, a hacker or malicious person can gain access to the web server via HTTP through a backdoor in the pluginas directory.”

In reality the relevant upload functionality is disabled in them and the file that is claimed to be vulnerable is a .html file that would be a frontend for uploads if the upload functionality was enabled (instead of the file that would even handle the file upload), which it isn’t.

14 Dec

Not Really a WordPress Plugin Vulnerability, Week of December 14

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.

Database Disclosure Vulnerabilities in CSS & JavaScript Toolbox, JoeBooking, MailPoet Newsletters, MiwoPolls, PDF Catalog for WooCommerce, Simple Ecommerce Shopping Cart Plugin, WP Bannerize,WPide, and WPL

Related reports of claimed database disclosure vulnerabilities were released for CSS & JavaScript ToolboxJoeBookingMailPoet NewslettersMiwoPollsPDF Catalog for WooCommerceSimple Ecommerce Shopping Cart PluginWP BannerizeWPide, and WPL. While the person behind these reports believes that the file they are listing for each of the plugins is a database backup, in reality they are files that came with the plugins. It hard to understand how they didn’t realize that as the contents are exactly the same for the same plugin file on every website they listed, but they apparently didn’t.

07 Dec

Not Really a WordPress Plugin Vulnerability, Week of December 7

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.

Database Disclosure Vulnerabilities in ARI Adminer, BackWPup, Batch-Move Posts wp plugin, Caldera Forms, Cart66 Lite, Contact Us Page Builder, Events Made Easy, Exports and Reports, L4 Shopping Cart, Orbis, Paid Memberships Pro, Search Engine, Shopp, WP EasyCart, and WP Editor

Related reports of claimed database disclosure vulnerabilities were released for ARI AdminerBackWPupBatch-Move Posts wp plugin, Caldera FormsCart66 Lite, Contact Us Page BuilderEvents Made EasyExports and ReportsL4 Shopping CartOrbisPaid Memberships Pro, Search EngineShoppWP EasyCart, and WP Editor. While the person behind these reports believes that the file they are listing for each of the plugins is a database backup, in reality they are files that came with the plugins. It hard to understand how they didn’t realize that as the contents are exactly the same for the same plugin file on every website they listed, but they apparently didn’t.

30 Nov

Not Really a WordPress Plugin Vulnerability – Week of November 30, 2018

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.

Arbitrary File Deletion Vulnerability in WP-DBManager

When you combine two entities that don’t seem to be concerned about the accuracy of their claims of vulnerabilities related to WordPress not surprisingly the results could be bad. Earlier this week the WPScan Vulnerability Database added this entry for a claimed arbitrary file deletion vulnerability in the plugin WP-DBManager:

They have only linked to the changes made in version 2.79.2 , so it seems possible all they actually looked at is what was mentioned in the changelog for that, “FIXED: Arbitrary file delete bug by sanitizing filename. Props RIPS Technologies.”. It isn’t clear if the lack of mention of that being vulnerability by the developer is intentionally or not.

The relevant functionality runs when accessing the file /wp-dbmanager/database-manage.php, which is done through the plugin’s Manage Backup DB admin page, which is accessible to those with the “manage_database” capability:

47
add_submenu_page('wp-dbmanager/database-manager.php', __('Manage Backup DB', 'wp-dbmanager'), __('Manage Backup DB', 'wp-dbmanager'), 'manage_database', 'wp-dbmanager/database-manage.php');

That capability is normally only give to users with the Administrator role (in the function dbmanager_activate()):

462
463
464
465
466
$role = get_role( 'administrator' );
if( ! $role->has_cap( 'manage_database') )
{
	$role->add_cap( 'manage_database' );
}

Then before you get to the relevant code in that file there is a check for a valid nonce (to prevent cross-site request forgery (CSRF):

22
check_admin_referer('wp-dbmanager_manage');

That nonce is only displayed on the same admin page.

So the only way for this to exploited normally would be intentionally by an Administrator and considering that Administrators could, for example, normally install code that would already allow them to delete arbitrary files, this wouldn’t really be a vulnerability.

Database Disclosure Vulnerabilities in Absolutely Glamorous Custom Admin, Jazzy Forms, Pods, and Universal Post Manager

Related reports of claimed database disclosure vulnerabilities were released for Absolutely Glamorous Custom AdminJazzy FormsPods, and Universal Post Manager. While the person behind these reports believes that the file they are listing for each of the plugins is a database backup, in reality they are files that came with the plugins. It hard to understand how they didn’t realize that as the contents are exactly the same for the same plugin file on every website they listed, but they apparently didn’t.

23 Nov

Not Really a WordPress Plugin Vulnerability – Week of November 23, 2018

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.

SQL Injection Vulnerability in Zotpress

Earlier this week we had a series of requests that look to be trying to exploit a vulnerability in the plugin Zotpress in the file zotpress.rss.php. We didn’t have any vulnerabilities for that plugin in our data set and the most recent version of the plugin didn’t contain that file. In then looking into this we found that the requests matched a report of a claimed SQL injection vulnerability from over 7 years ago. In looking into this we found that the claimed vulnerability wasn’t really one as it is stated that “magic_quotes has to be turned off” for it to work, but that is always on in WordPress even if otherwise disabled.

19 Oct

You Shouldn’t Assume That Wordfence Security or Other Security Tools Actually Provide Effective Protection

When it comes to explaining how so much money is spent on security while the results of that spending don’t seem to be appearing, a lot of the explanation seems like it can be found in the almost complete lack of evidence that those products and services marketed as providing protection provide effective protection. Considering that those are often promoted with extraordinary claims of their capabilities that seems to indicate those claims are baseless or that the developers actually know that they are false since if they actually had evidence to support them it seems unlikely they wouldn’t present that.

Everything we have seen over the years is there really is a lack of effectiveness and some combination of a lack of understanding by their developers that they are not effective and developers not caring if they do since they can make a lot of money while selling something that doesn’t have to work well (if at all). Certainly one of those would apply to the company behind the tied for most popular WordPress security plugin, Wordfence Security (the reality behind the other plugin is also telling about popularity not equally providing good security). For example, they previously very prominently claimed that their plugin “stops you from getting hacked” without any qualification (and still make the claims less prominently), despite that simply being false.

Earlier this week Janek Vind put a report claiming that they had found a “WordPress username disclosure protection partial bypass” vulnerability in Wordfence Security, which they explained with the following:

Testing:

Let’s try well know WordPress username disclosure method with activated Wordfence:

http://localhost/wp498/?author=1

Result: “Oops! That page can’t be found.”

Now let’s try modified query:

http://localhost/wp498/?author[]=

Result: “Author: root”

This method can disclose only one username – from author of the last post

That wouldn’t be the first time that it was found that claimed protection by that plugin could be bypassed. We have found that with much more serious issues in the past, both a persistent cross-site scripting (XSS) vulnerability and an arbitrary file upload vulnerability. Both of those being the kind of vulnerabilities that hackers would be interested in exploiting, the latter one being a type where it isn’t a question if hacker will try to exploit if they are aware of it, but just how soon they will.

What seems more important about this though is that with WordPress usernames are not intended to be private. Maybe the developers of the Wordfence Security plugin don’t really understand the WordPress security model, which would be a problem, or if they really believe that usernames being disclosed is a problem they should be pushing for WordPress to change how they do things instead or requiring people to use a plugin to provide something that should be integrated in to WordPress (if that were the case, it wouldn’t be the first time).

If you are looking for a security product or service that will provide protection we would recommend finding one that provides evidence, preferably from independent testing, that it is effective. Though from what we have seen you are unlikely to find that or a one that could actually provide that protection.

12 Oct

Not Really a WordPress Plugin Vulnerability – Week of October 12, 2018

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.

Arbitrary File Viewing Vulnerability in Advanced uploader

Last week we wrote about the security community’s problem understanding the basics when it comes to arbitrary file viewing and local file inclusion (LFI) vulnerabilities. We ran across that again with a false report of an arbitrary file viewing vulnerability in the plugin Advanced uploader. On one of our websites we had this attempt from a hacker to try to exploit what they thought was a vulnerability in the plugin:

/wp-content/plugins/advanced-uploader/upload.php?destinations=../../../../../../../../../wp-config.php%00

We didn’t have a vulnerability that seemed to match that already in our data set and in looking at the most recent version of the plugin we didn’t see code that looked like could be related to that.

When we did a search on the path used in the exploitation attempt one of the results was from the WPScan Vulnerability Database:

What is shown there doesn’t make sense. If there was a local file inclusion vulnerability you wouldn’t use it to include the WordPress configuration file as that did, since that file is already included each time WordPress runs. That proof of concept would be relevant if the vulnerability was an arbitrary file viewing vulnerability, not a local file inclusion vulnerability.

That page cites a report located here, which doesn’t actually describe what kind of vulnerability there is supposed to be, so the WPScan Vulnerability Database got the type of claimed vulnerability wrong on their own. The larger issue is that the vulnerability doesn’t exist.

The vulnerability is supposed to be in version 2.10 of the plugin. If you look at the code in the relevant file of that version of the plugin what you will see is that the only time user input “destinations”, which is part of the proof of concept, is used is in places in the code that are not accessible when sending a request directly to the file. It looks like someone might have looked at some of the code and thought there was vulnerability without actually understanding the totality of the code or actually testing things out, considering their proof of concept wouldn’t work (nor would it even make sense for testing purposes).

Arbitrary File Upload Vulnerability in Cnhk Slideshow

We also had a request that looked to be trying to exploit a vulnerability in Cnhk Slideshow recently:

/wp-content/plugins/cnhk-slideshow/uploadify/uploadify.php

There is a report from four years ago that would seem to be related to that, which involves a claim that there is an arbitrary file upload vulnerability in that file (which doesn’t exist in more recent versions of the plugin), but in looking at the code in the file the request would have been sent to, it is clear that the claim is false. Basic details, like the name of the file input used in the code are wrong in the proof of concept. There is also the issue that the code in the file will stop running before even getting to the upload code with the proof of concept provided as this is the first code:

3
4
5
6
7
8
9
10
if (isset($_POST['sid'])) {
	session_id($_POST['sid']);
	session_start();
} else {
    header('Status: 403 Forbidden');
    header('HTTP/1.1 403 Forbidden');
    exit();
}

The proof of concept doesn’t include a POST input “sid” so the rest of code won’t run. Even if you added that input to the request, it would fail at the next check done.

05 Oct

Not Really a WordPress Plugin Vulnerability – Week of October 5, 2018

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.

Arbitrary File Upload Vulnerability in Wp-Insert

If there really was an unfixed arbitrary file upload upload vulnerability in a WordPress plugin with 30,000+ active installations, as was claim to be the case with a report of a vulnerability in the plugin Wp-Insert, that would be a big deal since it would be basically guaranteed to be exploited. But it isn’t true.

The big red flag that this might not be true from the report is that they reporter was listing a website impacted. What we have often found is that people will find a website running outdated software and for who knows what reason assume it is running the latest version. We have often seen this with software that is easily downloaded, so the person behind the report could have easily checked things out, but didn’t. The claimed vulnerable files in this case are supposed to be in the directory /fckeditor/, but the only directory in the current version of the plugin is /includes/. Looking at the readme.txt on the website listed in the report, the version of the plugin on that website looks to be 1.7.3, which was superseded over 7 years ago. The next version 1.7.4 was the last version to contain the /fckeditor/ directory.

In looking at version 1.7.3 we found the file upload capability mentioned in the report didn’t work.

According to the developer of the plugin they tried to make it clear that their claim was incorrect to the person behind the report, but it didn’t stop the release of that false report.

Username Disclosure Vulnerability in Breadcrumb NavXT

With a claimed username disclosure vulnerability in Breadcrumb NavXT the reason it is not really a vulnerability is that you can do the equivalent through WordPress as well and with WordPress usernames are not intended to be private.