WordFence Really Doesn’t Know What They Are Talking About

One of the biggest problems we see with improving the security of websites is the amount of bad information out there, as it is hard to start to address the underlying problems when so much of what is being said is wrong. What surprised us when we started dealing with security issues is how much of that bad information comes from security companies. We don’t have the time to go through every instance of this since it is so widespread, but it is worth looking at an example of a company putting out bad information from time to time when a larger security issue is also raised.

On February 11, security researcher Claudio Viviani publicly disclosed a SQL injection vulnerability in the WordPress plugin WORDPRESS VIDEO GALLERY. According to his advisory he had notified the developer of the plugin about the issue two days before that. The next Tuesday we added the vulnerability to our Plugin Vulnerabilities plugin and on Friday, after waiting a few days to give time to the developer to release the fix, we notified the people running the WordPress.org Plugin Directory of that the vulnerability existed and had not been fixed. Following that the plugin was pulled from the directory. Earlier today they let us know the plugin had been removed and that the fixed version should be available soon. While checking to confirm that issue was fixed in the new version, which it was, we came across a forum thread that linked to a WordFence, which sells a WordPress security service, blog post entitled Zero Day SQL Injection Vulnerability in WordPress Video Gallery.

The problems with their blog post start with the title. This vulnerability wasn’t a zero day vulnerability since that involves a vulnerability being exploited before the developer or the public knows about the vulnerability. That wasn’t the case here as the vulnerability was publicly disclosed a week before and it appears the developer knew about it before that. The implications of a zero day vulnerability are much different than what this actually is, so the distinction is important. Zero day vulnerabilities do get more press coverage, so you might ask if they characterized it that way to try to get them attention.

That wasn’t the end of the problems, it continues into the content of the post:

There is currently a zero day SQL injection vulnerability in the WordPress Video Gallery plugin. Our researchers are seeing exploits in the wild for this and the exploits claim the vendor has been notified on the 9th of February.

If you click the “exploits in the wild” link what you get is not anything to do with exploits of the vulnerability in the wild, instead it is a copy of Claudio Viviani’s advisory on the Exploit Database website. The advisory itself doesn’t provide any code to exploit vulnerability. The proof of concept (POC) given simply shows where the SQL injection code would go:

http://target/wp-admin/admin-ajax.php?action=rss&type=video&vid=[SQLi]

It doesn’t include any malicious SQL code and providing the POC doesn’t really make much difference in exploiting the vulnerability since with the details of the vulnerability someone should be able to recreated the provided POC quite easily.

You really have to wonder about the competency of the WordFence researchers when they are claiming that a security advisory is somehow evidence of “exploits in the wild”.

Also in that section they half acknowledge the developer was notified of the vulnerability ahead of the exploitation, which would mean that this isn’t a zero day vulnerability as they are claiming.

The plugin still has not been updated by the vendor. Because this is being exploited actively and the vendor has been notified, we are now publicly disclosing the existence of this vulnerability.

WordFence isn’t actually publicly disclosing anything since the person that discovered the vulnerability already did that, it isn’t clear if they don’t know what public disclosure actually is or if they are intentionally trying to take credit for something they didn’t do.

A ‘googledork’ is also available in the exploit which allows attackers to use Google to find sites which suffer from this vulnerability in order to exploit them.

While this might sound ominous it doesn’t really mean much, the “googledork” in this case is simply a search query that shows URLs in Google’s index that are from RSS feature of this plugin. Here it is from the advisory:

# Dork Google: inurl:/wp-admin/admin-ajax.php?action=rss

Again this doesn’t actually matter much since all the search query does is show indexed URLs that contain the start of the path that is exploited:

http://target/wp-admin/admin-ajax.php?action=rss&type=video&vid=[SQLi]

Protecting Against Unfixed Vulnerabilities in WordPress Plugins

The situation with this plugin does get to a real problem, how do we protect against websites being hacked when known vulnerabilities in WordPress plugins are not fixed. WordFence’s solution beyond reporting the issue to the Plugin Directory, seems to be more effective at promoting their website then dealing with this type of situation:

Please share/tweet/mail this to your fellow WordPress administrators to help create awareness about this serious issue.

We have been pushing for a better approach to handling than this type of situation for years, which would involve WordPress warning admins when an installed plugin has been removed from the Plugin Directory (if you would like to see that happen please vote for it on the WordPress Ideas website). Until that happens you can use our No Longer in Directory plugin that provides a more limited version of that functionality. For this type of situation though one of our other plugins, Plugin Vulnerabilities, is more useful. This plugin warns when installed plugins have known security issue and also provides information on vulnerabilities that existed in other versions, which is useful when cleaning up a hacked WordPress website. Last Tuesday we updated the plugin to warn about this security vulnerability, so if you had our plugin installed and you had version 2.7 of the WORDPRESS VIDEO GALLERY plugin installed you would have then seen the following warning on the Installed Plugins page:

Plugin Vulnerabilities Screenshot

Preparing to Have Your Magento Website Upgraded

Upgrading is Magento is no small task. It is something that we recommend you hire someone do for you, not because we provide Magento upgrades, but because we know from plenty of experience how much trouble it can be. Whether you hire us or someone else do your upgrade there are a number of things we have found are important to do and consider when preparing for the upgrade:

Upgrading Usually Won’t Fix an Existing Problem

One thing that comes up often with upgrades of Magento, as well as other software, is clients hoping that the upgrade will fix some problem with the website. In most cases the upgrade won’t fix the problem and in some cases the problem can instead cause additional problems during or after the upgrade. Your best bet is to ask the person you are contacting about doing the upgrade if the upgrade will fix the issue and if it won’t, finding out what else they suggest should be done to resolve the issue. In many cases we have dealt with, the fix for the problem requires doing much less work than doing an upgrade.

A Test of The Upgrade is a Must

Almost no Magento upgrade is going to be without issues, this is the biggest reason to hire someone who does Magento upgrade regularly to handle the upgrade as they should be aware of how to handle most issues that come up and will be better equipped to work through issues they haven’t seen before. What is key to making sure the issues that will occur don’t impact the normal function of your website is doing a test of the upgrade first. This allows the issues to be spotted before the production website is upgraded and while you can compare how things were working in the old version.

In addition to dealing with the issues that come up, the test will also allow you to adjust to any changes that have been made between the version of Magento you use now and the version you are upgrading to. We find that many of the things that clients bring up to us during the testing relate to these types of changes.

Test in a Matching Server Environment

To insure you don’t run in to any unexpected problems when the upgrade is applied to the production website you should make sure to do the testing in a server environment that matches the production environment. This can usually be best accomplished by placing the test version of the upgrade in a directory on the website or by using a staging server configured the same as the production server. If you don’t do this you may run into problems. For example, one time we found during the testing that the shipping module that was in use wasn’t working in the new version of Magento due to a PHP module not being enabled on the server. When our client contacted their web host to see about getting it enabled the web host first claimed that the modules was enabled and it ultimately took several days of back and forth for them to finally get it enabled. If this had only been discovered after the production website was upgraded it would have been a big problem.

Test, Test, Test

We can’t emphasize enough the importance of checking over everything in the test before upgrading the production website as it much easier to resolve any issues at this stage of the process than once the production website has been upgraded.

Mention Any Failed Upgrade Attempts

If there has previously been a failed attempt to upgrade Magento it is important to mention that when discussing the upgrade as this can create complications during the upgrade. The biggest of these being that sometimes after the failed upgrade the database is restored over the upgraded database, which then causes the database upgrade portion of the second upgrade attempt to fail when it tries to add new tables to the database that already exist because they were added during the previous upgrade attempt.

Changing Your Theme

When discussing upgrades we are often asked about changing the theme in use along with the Magento upgrade. Our suggestion is to split up the upgrade and the theme change as that makes it easier to deal with any issues that come up during either one. We also suggest doing the upgrade first and then using the test of the upgrade to test out the new theme.

Handling PHP Changes

One of the big changes that came with Magento 1.9.1 is that Magento will not function on versions of PHP below 5.3 (the listed minimum PHP is even higher, PHP 5.4). Some hosting environments making switching PHP versions quite easy, but in some cases it can require moving to a different server so this will be something you will want to discuss with the person handling the upgrade ahead of time. Also, if you are still running Magento 1.3 the process for handling this will be more involved since that version of Magento was not designed for PHP 5.3 or higher.

Clean Up the Database

The Magento database can grow rather large in size due to long term storage of data that doesn’t actually need to be stored on a long term basis. This can negatively impact website performance when interacting with the database and can cause the website to go over its disk usage quota. During the upgrade process is a perfect time to check out if this is the case with your website as cleaning out the excess data can significantly speed up the database upgrade portion of the upgrade and people that handle upgrades are usually familiar with this issue due to that. Due to a change in Magento 1.9.1 that makes sending most emails reliant on the Magento cron job being set and enabled, the person handling the upgrade will need to insure the cron job is set correctly, so most of the work to enable automated log cleaning that takes care of much of the excess data problem going forward is already being done as well.

Lessons from the FancyBox for WordPress Plugin Vulnerability

Last week a vulnerability in the WordPress plugin Fancybox for WordPress was exploited causing many websites to serve malware. A week later we thought it would be a good time to look at what went wrong and what lessons can be taken from the incident to hopefully improve WordPress plugin security going forward.

WordPress Plugin Security is in Bad Shape

When we started to look in to this, what we were most interested to see was what was the underlying vulnerability that allowed the websites to be hacked. Was it some obscure corner case that allowed a hacker access they shouldn’t have or was it some very fundamental failure? Since the developer stated they fixed the vulnerability in version 3.0.3 looking at the changes in that version was the starting place for understanding that. What the changes made show is that anyone could change the plugin’s settings. By anyone we truly me anyone, you didn’t have to be logged in to WordPress to change the settings. This wasn’t the intention of the developer, as can be see by the fact that only logged in users who are Administrators can access the plugin’s settings page.

The problematic code is the code for saving the settings, which did not check to make sure that the settings change came from the setting’s page. In 3.0.2 the code simply checked if a request for a setting updates was sent and then went on to save the settings:

if ( isset($_REQUEST[‘action’]) && ‘update’ == $_REQUEST[‘action’] ) {

The changed code in 3.0.3 checks to see where the request came from as well:

if ( isset($_REQUEST[‘action’]) && ‘reset’ == $_REQUEST[‘action’] && check_admin_referer( ‘mfbfw-options-options’ ) ) {

In many cases being able to change a plugin’s settings would not allow it to be used to serve malware. What allowed it in this cases is that the plugin has settings that allow additional code to be added to pages in which FancyBox for WordPress is present:

Fancybox for WordPress Extra Calls Settings Page

All the hacker had to do was to update the settings to turn on that feature and have it use their malicious code.

The fact that a plugin that now has over 600,000 downloads (each time an installed plugin is updated in WordPress that gets included in the download count, so the amount of websites using it is much lower) allowed anyone to change it’s settings and a hacker was the first person to discover this isn’t a good sign for the security of WordPress plugins. We think that Automattic has at least some responsibility for improving this situation.

The response after the fact was much better. The vulnerability was quickly fixed and WordPress automatically pushed the updated version for those running at least WordPress 3.7 (which introduced automatic updates)

Understanding the Scope of Vulnerability

When dealing with a hacked website an important element in the cleanup process is understanding the scope of the exploitation, so that appropriate cleanup action is taken. While it doesn’t hurt to do more than what is needed, it can take more time and increase expenses, which can be a major hardship depending on the website.

In this case the direct impact of the vulnerability is somewhat limited. The hacker is able to add code to the setting and that is loaded on pages on the website but because the setting is stored in the database safely using the update_option function they can not otherwise gain access the database through the vulnerability. It is possible for malicious JavaScript to provide the hacker additional access to the website if an admin was to have visited a page that has the code on it while logged in.

Once a website upgraded to at least version 3.0.4, any malicious code currently stored in the setting is disabled and the vulnerability is patched, so the website should be secure at that point, but you may want take the precautionary measures of changing the passwords associated with the website and checking over the website for malicious code or reverting the website to a backup made before the website was originally hacked.

The Settings API

When looking at how to improve code security, hoping that people will start writing secure code on their own isn’t a good bet. Some combination of making it easier to do things securely and making it harder to write insecure code seems to be an important element to improving the situation.

So could be something be done to deal with this type of situation? There already is a way to handle saving settings securely, the Settings API, which was introduced in WordPress 2.7. This API handles managing settings and only allows settings to be saved by users with manage_options capability, which is normally only given to Administrators (and Super Admins when using MultiSite). The problem with it is that it doesn’t appear to be used in many plugins (that includes our plugin with a settings page, which we are looking to rectify). It would be worth looking in to how to make it so that it is more widely used going forward.

Security Journalism is in Bad Shape

You don’t have to follow IT security closely to know that it isn’t in good shape these days, with major company after company revealing that sensitive customer data has been breached. Good IT security journalism could be an important piece of shining a light on bad practices (which are abundant) and ultimately getting security where it should be. Unfortunately, what we have found is that security journalism is in as bad or worse shape than the security they cover. Take for instance The Register’s article on the situation with this plugin. It misses many important details, like the fact the plugin was being automatically updated for many and that the update would take care of much of the issue. It then follows that up with some truly bad reporting:

The vulnerability followed what was described as the “most serious” hole in five years, disclosed last November, that affected what was then estimated to be 86 per cent of WordPress websites. That cross-site scripting hole was found in the hugely-popular WP-Statistics plugin.

First off we have yet to see any impact from the vulnerability that is mentioned as being the “most serious” hole in five years, its limited impact would be something to mention several months after it was fixed in outdated installs (the current version at the time was not vunerable, which would have been worth mentioning as well). The bigger mistake is that the author of the article is conflating a vulnerability in WordPress itself with an unrelated vulnerability in the the WP-Statistics plugin, despite having also written the article they are citing about the previous vulnerability.

FAQ: Will Upgrading Magento Make My Website Responsive?

When considering a Magento upgrade one of the most important things you should discuss with the person who might do the upgrade is whether the changes you think the upgrade will make are actually going to happen. We often have people come to us for upgrades of Magento or other web software who are expecting that it will fix a problem they are having, but in most cases the upgrade won’t have any impact (in many cases fixing the problem requires much less work that an upgrade would entail). Along similar lines we have had an increasing number of people coming to us asking about Magento upgrades who it turns out are actually interested in making their website responsive; that is making the website work well across desktops, tablets, and smartphones.

Upgrading Magento will not make a website responsive. The confusion surrounding this seems like it might be largely due to how Magento 1.9 was promoted by its developers. The blog post announcing that version is titled “Magento Enables Responsive Sites in Half the Time” and the clearest mention of what that actually means in the post isn’t all that clear. It states that a “new responsive design reference theme that makes it possible to quickly get a tablet and smart phone-friendly site”, what isn’t necessarily clear for someone who doesn’t deal with the more technical side of Magento is that all that means that Magento now comes with a new theme that is responsive. The new theme doesn’t have any impact on the existing theme you have, so you would have to switch to new theme to make the website responsive. With that you lose the current look of the website and would have to customize the default theme.

Since responsiveness comes from the theme and not from using a newer version of Magento, if you are looking to make your Magento website responsive you would want to replace your current theme with one that is responsive. You could customize the new default responsive theme that comes with Magento 1.9 & up, or you could use another responsive theme created by someone else as well. Depending on if the new theme is compatible with your Magento version you may or may not need to upgrade Magento as well.

Poor Security In Automattic Sponsored WordPress Plugin

A couple of weeks ago we discussed our opinion that Automattic, the company closely associated with WordPress, should bear some of the responsibility for improving the security of WordPress plugins. That came up after we bumped in to their use of WordPress plugins for the WordPress.com VIP service, while trying track down the developer of a plugin to let them know of a security issue. It was only days later that we came across a closer connection between Automattic and the poor security of WordPress plugin.

As part of our efforts to improve the security of WordPress plugins we have created the Plugin Vulnerabilities plugin that alerts when the currently installed version of plugins have known security vulnerabilities (as well as listing vulnerabilities that existed in installed plugins). When we add vulnerabilities to the dataset for that plugin we verify that vulnerability exists and what versions it existed in, in some instances we have found that vulnerabilities that discoverer of the vulnerability and or the developer of the plugin claim have been fixed have not actually been fixed. That is the case with two reflective cross-site scripting (XSS) vulnerabilities recently identified in the Pods plugin. While the report says that the vulnerabilities were fixed in version 2.5, we found that they still existed in that version. While looking for a way to contact the developers to let them know that issue existed and had been publicly disclosed, we noticed that footer of the website prominently displays that the project is sponsored by Automattic:

Pods Sponsored by Automattic

According to their About page, Automattic has been sponsoring development since 2012.

After a little more digging we were able to find Pods recommend method for reporting a security issue. While we got a quick response it didn’t seem like they really understood things. In our initial contact we recommended they use Firefox when confirming the vulnerabilities still exist, due to XSS filtering in other major web browsers that would protect against the example exploits of the vulnerabilities that were provided in the advisory (the XSS filtering would not necessarily protect against more advanced exploits). In response they asked how they could confirm them in Chrome for some reason. A week later two new version, 2.5.1 and 2.5.1.1, were released that based on the changelog fixed a number of bugs, but did not fix the security vulnerabilities that have been publicly available since January 12. As of today the vulnerabilities still exist in the plugin.

In reviewing the other vulnerabilities that were included in that report another thing stuck out to us, the security of Pods has actually gotten worse over time. One of the other vulnerabilities could have lead to all the of Pods data being deleted from a website if a malicious actor could get a logged in admin to visit a specified page through a cross site request forgery (CSRF) vulnerability. That vulnerability existed back to version 2.0, but as of at least the last version of 1.x series the reset function was protected from this type of vulnerability with a nonce.

What to Watch For When Upgrading to Magento 1.9.1

Now that it has been a couple of months since Magento 1.9.1 was released we have had enough experience upgrading from older versions of Magento to 1.9.1 to discuss what we have found to be the important things to keep in mind when upgrading to that version. We have found that two major issues impact the upgrade:

Sending Emails Now Relies on the Magento Cron Job

One of the under the hood changes made in 1.9.1 is that most emails to be sent out are first placed in queue and then the queued emails are sent the next time the cron job for Magento is run. If you do not have a cron job configured or enabled (as was the case for one website we dealt with) then many emails, including order confirmation and transactional, will not been sent out.

If you are having a problem with emails not being sent in Magento 1.9.1 you can check if unsent queued emails are the problem by reviewing the core_email_queue table, which contains the emails that have been added to the queue. Once the cron job has run the “processed_at” value for emails will have the time that they were sent and if they have yet to be sent they will not have a value set for that.

During testing of the upgrade you will also need to make sure that the cron job is set up for the test installation as well.

PHP 5.3.0 or Newer Is Required

Up until version 1.9 the bare minimum version of PHP that Magento permitted was 5.2.0, in version 1.9.1 that has been increased to 5.3.0. For most part this isn’t an issue considering that PHP 5.3.0 was released in June of 2009 and the listed minimum PHP versions for Magento 1.9.1 is 5.4. Where it can cause an issue is if you are doing an upgrade from the very old Magento 1.3, which wasn’t designed to support PHP 5.3. If you are doing the test of the upgrade in the same server environment as the production website and you can’t use multiple versions of PHP at the same time you will need to either modify the existing Magneto installation to support at least PHP 5.3 or do the upgrade in two stages (first upgrading to 1.9, then changing the PHP version, and then doing the upgrade to 1.9.1).

The Upgrade From Joomla 2.5 to 3.x Often Isn’t A One-Click Update

With support for Joomla 2.5 having concluded at the end of December more people are trying to upgrade to Joomla 3.x. With that more people are also realizing that the process isn’t quite as easy it might sound in many cases. While the Joomla documentation describes the upgrade type as “One-click to 3.x“, a number of issues can make the process more complicated. Before we get in to those issues, let’s get to the best piece advice we can provide after having done numerous upgrades from Joomla 2.5 to 3.0.x-3.3.x for clients over several years: make a copy of the website and test the upgrade on it first. This allows you to work through any issues that come up before you upgrade your production website, which makes the process easier and less stressful.

In most cases this is most easily accomplished by creating a copy the website in a new directory on the website, which you can then you would access by adding the directories  name to your websites address (for example if you website was www.example.com and the new directory was “joomla3” then the copy would be accessible at http://www.example.com/joomla3/). You can do that through the following steps:

  1. Make a copy of your websites file and put them in the new directory on the website.
  2. Create new database and import the contents of your production websites database in to that.
  3. Update your configuration.php with the credentials for the new database and if you have the $live_site variable set, update that as well.

With that running you can then move on to doing the upgrade in that.

Extension Problems

The biggest problems when upgrading from Joomla 2.5 to 3.x comes from extensions. In the worst case a problem with an extension can cause the upgrade to fail and the website to completely be broken. This issue unfortunately is all too common occurrence and it is big part of why we suggest doing the test of the upgrade first as restoring the website after a failed upgrade is not something you want to have to do if you don’t absolutely have to. With a test copy you can just remove the broken test copy, make a new copy, and then retry the upgrade, this time making changes to make sure the extension that caused the problem does not cause the problem again by disabling it or removing it first.

While making sure that you have all of the extensions up to date and removing any that are not listed as being compatible with 3.x before the upgrade starts can help to limit problems with extensions it won’t handle everything. In one case an extension had been removed some time in the past but a plugin that was part of got left behind, the plugin then caused the Joomla search functionality to be broken in the newer version.

For some more complicated extensions you need to do multiple upgrades of the extension, some before and after the upgrade of Joomla from 2.5, which is also something you want test before doing on the production website.

Extensions Not Compatible With Your Version of 3.x

Another problem we have found is that just because an extension is listed as being compatible with Joomla 3.x, that doesn’t mean that it will work in the latest version of 3.x. For example in one case during an upgrade we dealt with an extension that was not functioning properly and traced the issue to something caused by a change in JavaScript libraries made in Joomla 3.2.x. Unfortunately the Extension Directory only lists if an extension is compatible with 3.x, so for extensions that haven’t been updated in a while you won’t know for sure if it is going to work properly until actually are trying to use it with the new version of Joomla.

Template Changes

We often find that existing templates require some minor tweaks to keep their existing styling when running on Joomla 3.x. That is much easy to do if you can see the way it looks in Joomla 2.5 while making the changes.

In small number of cases there have been more serious problems due to coding in the templates that causes broken pages to be shown when running in Joomla 3.x. It is much better to find and fix this in the test copy then having trying to fix it while customers are trying to access it.

FAQ: Should I Upgrade Magento and Change My Theme at the Same Time?

When discussing Magento upgrades with clients these days what is coming up more and more often is questions about changing the theme in use on the website and more specifically whether that should be done at the same time as the upgrade. Our current recommendation is to split up the upgrade and the theme change, for reasons we will get to in a moment, doing the upgrade first and then using the copy of the website used for testing the upgrade to test out the new theme before finally changing the theme on the production website.

Avoiding Additional Issues with the Upgrade

Upgrading Magento is almost never a process without issues, if you are lucky they are rather small, but in many cases they are rather large. To the extent possible you want to avoid making other changes at the same time as doing that as makes it harder to deal with the issues since you won’t know which change is the root of the issue when you start dealing with it. That advice applies not just to theme changes, but other major changes.

While new themes do not cause problems on the same level as an upgrade, they can sometime cause problems, with this being more likely if the new theme also adds new extensions to the website. Often times the new theme is going to go through a fair amount of customization, which can be accomplished without impacting the production website by using the copy of the website created for the upgrade to do that.

Limited Downside

The downside to splitting up the upgrade and theme change is that often themes will need some minor changes made to them to make them compatible with versions of Magento released after the theme was released, with a new theme designed for the new version that shouldn’t be necessary. If you hire a professional to do the upgrade – which we would definitely recommend based having seen the many problems that can come up during an upgrade – they shouldn’t have a problem checking if changes need to be made and making those changes, so the advantage a new theme provides is limited based on that. Further limiting the advantage is that we often find that those changes need to be made in design files that come with an extension instead of a theme, so most of the work related to this still needs to be done if a new theme is used during an upgrade.

Automattic’s Responsibility for the Security of WordPress Plugins

As we have continued to refocus on the security of WordPress plugins due to our work on new plugin that warns of known vulnerabilities in WordPress plugins the question of who has a responsibility for improving the security of WordPress plugins has come up. Relying on the developers of the plugins to insure they are secure doesn’t seem to be working as many of the vulnerabilities we have reviewed are things that are not the result of complex issues, so they could have been prevented with relatively basic security precautions. Since WordPress is a volunteer effort expecting that those volunteers would be responsible for the overall security of third-party software doesn’t see right. But what about the company closely connected with WordPress, Automattic? With a valuation of over billion dollars they certainly have the financial wherewithal to bear the burden of some responsibility, but in the past we would have said no since they didn’t seem to have a direct connection with plugins, but as we recently stumbled upon they are taking advantage of them for business purposes.

Recently a reflected cross-site scripting (XSS) vulnerability was discovered in the Frontend Uploader plugin. After confirming that the vulnerability existed in the most recent version we went looking for a way to contact the developer of the plugin to alert that the vulnerability existed in their plugin. While doing that we came across a page for the plugin at Automattic’s  Wordpress.com VIP, a service where you can pay starting amounts of $5,000 a month for hosting and $1,250 for support. It turns out they offer a number of the plugins from the wordpress.org Plugin Directory to the customers of their VIP service. They tout those plugins (as partner integration) with this:

We’ve added 200+ extra features on top of WordPress for everyone on WordPress.com—and just for VIPs, we’ve added the additional plugins below, which can be integrated into your sites with a single-click, so you can take advantage of powerful partner integrations and features without touching a line of code.

Their marketing materials also touts their claimed security (which hopefully has improved after the major breach they had a few years ago):

We stay awake at night, watching over your site, so you don’t have to. Our site monitoring and secure codebase ensure an impressive uptime, and our operations team is always hands-on.

Based on all of this we certainly think that Automattic has a responsibility for improving the security of WordPress plugins since they are getting benefit from them.

If they are going to live up to that responsibility they have a lot of work to do, as can be seen in this case. After the vulnerability was disclosed in a plugin they are redistributing they don’t appear to have done anything about. As far as we can tell the vulnerability was only fixed after we reported the vulnerability to the people running the WordPress.org Plugin Directory (since we couldn’t find a direct contact for the developers of the plugin) and them pulling the plugin pending a fix. While the plugin was gone from the Plugin Directory it was still listed on the WordPress.com VIP website, though we don’t know if they continued to distribute it. It doesn’t even look as if people using WordPress.com VIP would know that the plugin had a vulnerability fixed since the changelog makes no mention of the new version, 1.9.3, or the security fix in it (which unfortunately is an all to common problem when plugins receive security fixes).

WPScan and Sucuri Put WordPress Websites at Risk

Yesterday we discussed a situation where the WPScan project didn’t bother to notify the developer of a WordPress plugin or the wordpress.org Plugin Directory about a vulnerability that they knew about. Some might excuse WPScan’s responsibility to alert them based on the fact that the vulnerability was discovered by someone else and already publicly disclosed. After running in to that situation we took a closer look at the WPScan project and found something more troubling. Back in March they started discussing a backup plugin that wasn’t properly securing backup files made by it. The issue was quite serious since some of the backup files, which can contain sensitive information, made by the plugin could be easily found with just a simple Google search. In the thread no one even brings up the idea of notifying the developer of the plugin or the Plugin Directory about the issue, which would be the way to get it fixed. Instead there is some discussion in thread on how to further exploit the poor security of the plugin in the WPScan vulnerability scanner.

We are quite sure that no one ever bothered to contact the Plugin Directory about the issue because within hours of us notifying them last week the plugin was pulled from the directory pending the security being improved. Within a few days of that, security improvements were introduced to the plugin. Based on the plugin developer’s comment at the end of the thread it doesn’t sound like WPScan had informed them either.

What makes this particular troubling is that at the same time they are at least knowingly leaving websites insecure they are selling WordPress security services.

They are not the only ones selling security services involved in this. Prominently displayed on the WPScan homepage is a banner letting you know the project is sponsored by Sucuri:

WPScan is Sponsored by Sucuri

We would ask why a security company would sponsor a project that seems more interested in exploiting security issues than fixing them, but we already know that Sucuri doesn’t have much interested in websites actually being secure. We have often been hired to re-clean websites that had previously cleaned by Sucuri. What we have found in those cases is that Sucuri didn’t do basic parts of a proper cleanup, including making sure the software on the website was up to date and determining how the website was hacked, which if done would have made it less likely that the website would be hacked again.