22 Mar

Not Really a WordPress Plugin Vulnerability, Week of March 22

In reviewing reports of vulnerabilities in WordPress plugins to provide our customers with the best data on vulnerabilities in plugins they use 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.

Stored XSS and Password Viewing in Easy WP SMTP

In a reply in a topic about the vulnerability that was being exploited this week in Easy WP SMT, which was subsequently deleted (as were numerous other replies), someone asked if the vulnerabilities that a report claimed existed in the plugin had been fixed. That report is nearly two years old, but we are always looking to have our data be more complete even if involves adding something fixed long ago. But what we found is that there really wasn’t a vulnerability as the person making the claim seemed to not have a great understanding of the WordPress security model.

The first claimed vulnerability isn’t really one because the underlying claim is that a user with the “manage_options” capability, so normally only an Administrator, would intentionally place malicious JavaScript code in the plugin’s settings, referred to as persistent (stored) cross-site scripting (XSS). Not only is an Administrator normally allowed to do the equivalent of XSS due to having the “unfiltered_html” capability, but they also normally could edit the plugin to remove any security restrictions.

The same type of issue applies for the second issue, which is that the SMTP password is viewable by Administrators, but Administrators would normally be able to access any data stored on the website’s database even if it isn’t shown on an admin page since they have the ability run arbitrary code on the website and could use that to access anything in the database.

15 Mar

Not Really a WordPress Plugin Vulnerability, Week of March 15

In reviewing reports of vulnerabilities in WordPress plugins to provide our customers with the best data on vulnerabilities in plugins they use 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.

Authenticated Option Update Vulnerability in CF7 Customizer

The first changelog entry for versions “1.2.0/1/2” of the plugin CF7 Customizer is

TL;DR Major security update due to Freemius. (MUST UPDATE right now)

You would reasonably assume that means the plugin was impacted by the authenticated option updated vulnerability that was recently fixed in Freemius, but prior to that update the plugin was using a very out of date version of Freemius, from before the introduction of the vulnerable code, so this isn’t actually a “Major security update”. We would, as always, recommend updating plugins right away no matter if there is claimed to be a security fix in a new release.

15 Feb

Not Really a WordPress Plugin Vulnerability, Week of February 15

In reviewing reports of vulnerabilities in WordPress plugins to provide our customers with the best data on vulnerabilities in plugins they use 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.

Local File Inclusion Vulnerability in WP Staging

The report of a claimed local file inclusion vulnerability in the plugin WP Staging is the kind of strange report we have never understood what might be the explanation of, as you have someone subtly modifying real code from a plugin to present a very different situation from reality.

The report lists the vulnerable file as /index.php, the actual file is /apps/Backend/views/tools/index.php. The report shows that two lines of code are the cause of this:

30:require_once $this->path . “views/tools/tabs/” . $activeTab . “.php”;
5: $activeTab = $_GET[‘tab’] : “import_export”;

The first of those is largely accurate, as this is how the line actually looks:

30
<?php require_once $this->path . "views/tools/tabs/" . $activeTab . ".php"?>

The second line though is very different:

5
$activeTab  = (isset($_GET["tab"]) &amp;&amp; array_key_exists($_GET["tab"], $tabs)) ? $_GET["tab"] : "import_export";

What they removed is very important since it limits the values of the variable $activeTab, which is used in the previous line, and that prevents local file inclusion. We thought it might be that while the report listed the version impacted as 2.4.8 they were actually looking at an earlier version of the plugin when the code was different, but the older versions don’t look like that either and are not vulnerable either.

Cross-Site Request Forgery/File Upload in Jssor Slider

Now in a reoccurring part of these posts we are pointing out that someone going by the handle is “KingSkrupellos” is getting more false reports listed with Packet Storm. This time it turned out that they copied a real report of ours from June of 2016 of an arbitrary file upload vulnerability in Jssor Slider that we noted had already been fixed and claimed that it was a cross-site request forgery/file upload vulnerability in the most recent version. The plugin has been changed significantly since our disclosure and it doesn’t even contain similar code anymore, so this wasn’t a situation where there could be any confusion over it being fixed or being possible in the latest version.

08 Feb

Not Really a WordPress Plugin Vulnerability, Week of February 8

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 Request Forgery / Shell Upload Vulnerability in Ultimate Member

Recently many of the claimed vulnerabilities we have mentioned in these posts have come from someone with the handle “KingSkrupellos” that the website Packet Storm continues to allow to post false reports. They were at it again with a claimed cross site request forgery / shell upload vulnerability in Ultimate Member. In this case they claim that there is vulnerability in the latest version of the plugin involving files that don’t exist in it.

In the older version of the plugin they also mention, which includes those files, they seem to be confusing an error indicating that the file upload code has not run, ‘{“error”:”A theme or plugin compatibility issue”}’, as meaning that a file has been uploaded.

Shell Upload Vulnerability in WP User Manager

The claimed shell upload vulnerability in WP User Manager seemed false based on this based on this part of the proof of concept, “you can upload your shell by adding image extensions to end of your shell. (ex: SHELL.php.png)”. Since the file has an image extension the server shouldn’t see it as type of file that allows code to run, so it wouldn’t be “shell”. The uploading is handled through the WordPress function wp_handle_upload(), so if someone wants to claim there is an issue with allowing dual extensions, then they should be labeling it as a security issue with WordPress.

Cross-Site Scripting (XSS) Vulnerability in Parallax Scroll

With a claimed vulnerability in Parallax Scroll the tip off that something might be amiss came with the claimed vulnerability be listed as a cross-site scripting (XSS) vulnerability, despite usually there being a modifier included (for example a reflected XSS or a persistent XSS). Looking at the changes made that were supposed to fix this, it involved outputting the value of the WordPress function get_the_title(), which returns the title of a post. WordPress shouldn’t be outputting values that lead to unintended XSS and in fact it isn’t. What we found was that this involved a custom post type, where the title allows JavaScript code only if the user has the “unfiltered_html” capability, which permits the equivalent of XSS. To put this another way, even without this plugin installed the users who could create customs posts through it, could do the same thing that was supposed to be a vulnerability, but just by creating a normal post or page.

01 Feb

Not Really a WordPress Plugin Vulnerability, Week of February 1

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 Add Code To Head, All-in-One WP Migration, Diamond MultiSite Widgets, Smush, and Yeloni Exit Popup

Related reports of SQL injection vulnerabilities in Add Code To Head, All-in-One WP MigrationDiamond MultiSite WidgetsSmush, and Yeloni Exit Popup appears to come from someone that has no idea what a SQL injection vulnerability is. As an example, take the plugin Add Code To Head, where they claim that there is this vulnerability in the file add-code-to-head.php despite there being no SQL statements in that file and the GET parameter “id” that is supposed to be utilized as part of this, isn’t used. What they are claiming proves that there is an issue is the following, which they refer to as a “SQL Database Error”:

Fatal error: Uncaught Error: Call to undefined function wp_die() in
/home/tramhaltevenlo/public_html/wp-content/plugins/upsite_analytics_plugin
/uninstall.php:9 Stack trace: #0 {main} thrown in /home/tramhaltevenlo/public_html
/wp-content/plugins/upsite_analytics_plugin/uninstall.php on line 9

That is actually an error indicating that a function doesn’t exist, which occurs because the file is not intended to be accessed directly and the code is trying to access a function that would exist if that file was loaded by WordPress. That type of error message would not normally be shown due to the display of errors being disabled by default, but if that were an issue, it would impact the core WordPress software as well.

25 Jan

Not Really a WordPress Plugin Vulnerability, Week of January 25

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.

CSRF / Shell Upload vulnerability in  Category and Page Icons

The claimed report of a CSRF/ shell upload vulnerability in the plugin Category and Page Icons is a mess. The report looks like it was copied from a real report of a restricted file upload vulnerability in the plugin from years ago and then additional information that isn’t accurate was added. If you look at the most recent version of the plugin you will find that  what is claimed in the report wouldn’t even be possible with that version as the proof of concept has you sending a request to a file at /wp-content/plugins/category-page-icons/include/wpdev-flash-uploader.php, but the first line of that file restricts you from sending a direct request to the file:

9
if ( ! defined( 'ABSPATH' ) ) die('<h3>Direct access to this file do not allow!</h3>');
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.