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

22 Jun

Reflected Cross-Site Scripting (XSS) Vulnerability in Product Catalog

We recently have been trying to get an idea of how effective it would be to try to proactively catch some vulnerabilities when changes are made to WordPress plugins that include those vulnerabilities. In doing one of the preliminary checks we immediately came across a reflected cross-site scripting (XSS) vulnerability that exists in the plugin Product Catalog that has existed since its first version was released nearly four years ago.

Contrary the scaremongering we have seen from other web security companies this type of vulnerability isn’t a major concern as we don’t see hackers trying to exploit it on a large scale and all major web browsers other than Firefox have filtering that would need to be evaded to make it work. At the same this type of vulnerability shouldn’t be remaining in a plugin that long as it involves a failure of security at a fairly basic level and in the form it was here, easy to detect.

The vulnerability occurs in the file /html/CatalogueDetails.php on line 44:

<form id="nav-menu-meta" action="admin.php?page=UPCP-options&Action=UPCP_Catalogue_Details&Selected=Catalogue&Catalogue_ID=<?php echo $_GET['Catalogue_ID']; ?>#Catalogues" class="nav-menu-meta" method="post" enctype="multipart/form-data">

The value of GET input “Catalogue_ID” is output without being escaped, which could permit malicious JavaScript on to the page.

We notified the developer of the issue a week ago, we haven’t heard back from them and while the plugins has been updated since then, the vulnerability hasn’t been fixed.

Proof of Concept

The following proof of concept will cause any available cookies to be shown in alert box. 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?page=UPCP-options&Action=UPCP_Catalogue_Details&Selected=Catalogue&Catalogue_ID=%22%3E%3Cscript%3Ealert%28document.cookie%29%3B%3C%2Fscript%3E

Timeline

  • June 15, 2017 – Developer notified.