Auttomattic Sponsored WordPress Plugin Pods Still Hasn’t Fixed Publicly Known Security Vulnerability After Two Months

In discussing how the security of WordPress plugins could be improved we have put forward that Automattic, the company closely connected with WordPress, should have some responsibility for that. With a valuation of over billion dollars they certainly have the financial wherewithal to bear the burden of some responsibility. Shortly after putting forward that idea that we came across a security advisory for multiple vulnerabilities in Pods, a plugin that Automattic sponsors.

When we checked on the vulnerabilities to add them to Plugin Vulnerabilities plugin we found that despite the advisory saying that they were fixed in version 2.5, that in fact two reflective cross-site scripting (XSS) vulnerabilities listed still existed. Three days after the advisory was put out, January 15, we notified the Pods developers that vulnerabilities still existed. We promptly received a reply from them, but it didn’t seem like they really understood the situation.

A week later versions 2.5.1 and 2.5.1.1 were released, neither of which addressed the security vulnerabilities.

On February 5 and 9 we received emails from the developers that the vulnerabilities would be fixed in version 2.5.2. That version has yet to be released and it has now been two months that they have knowingly left the vulnerabilities in the plugin. Maybe this will be a wake-up call to Automattic that plugin security needs to be taken more seriously and that they can start playing a constructive role by improving the security of plugins they sponsor.

Google’s Bad Instructions for Upgrading Zen Cart

Google started out just providing text snippets and links to other websites in their search results and then overtime started adding more information directly in to the search results. For example, you can get sports scores right on the search results page. Sports scores are simple factual data so it hard to get those wrong, but more complex information is easier to get wrong. We recently made aware example where they are providing quite bad information.

Currently if you do a search related to upgrading Zen Cart you will get shown the following instructions above the results:

Google Zen Cart Upgrade Instrutctions

The instructions are taken from a page on GoDaddy’s website.

What sticks out to us is that not only are the instructions wrong, but they seem to have been written by some who doesn’t have any actual familiarity with Zen Cart.

Let’s start with the note above the instructions on GoDaddy’s page:

NOTE: If you are using Zen Cart schema 1.3.8a, you need to upgrade to 1.3.9 before upgrading to version 1.5. Otherwise, you will get errors.

This just doesn’t make any sense as the Zen Cart installer, which is used to upgrade the database schema, doesn’t have a problem doing an upgrade from 1.3.8a to the latest version, 1.5.4, without going to 1.3.9 first. Below is screenshot when doing that, you can see that not only does it allow you upgrade going back to that version, but it allows you to start from version 1.2.7:

Zen Cart Database Upgrade Selections

The next thing that stands out is step 5, “Disable all plugins and set your theme to the default.” The way Zen Cart handles addons is different than a lot of other software. With WordPress for example, plugins are stored separately from the core software and you have the ability to enable and disable them from a central location. With Zen Cart addons they are more tightly connected to Zen Cart. In some cases the addons are modification to core Zen Cart files, which cannot be disabled short of removing the code. For other addons the addon itself would have to provide a mechanism for disabling, which many do not. We get the sense that the person writing took this advice from some other software, without understanding that it wasn’t applicable to Zen Cart.

Finally, the biggest problem with the instructions is the lack of any actual instructions on doing the upgrade. The entirety of GoDaddy’s instruction is “Upgrade Zen Cart to 1.5.0. For more information, see this Zen Cart help article.” The “more information” implies that “Upgrade Zen Cart to 1.5.0.” actually provided some information, which it didn’t. If you follow the link you land on Zen Cart’s 1,200+ word upgrade instructions that are nothing like GoDaddy’s. The whole thing comes across as attempt to write something around the link to the actual instructions, which they filled with incorrect information. Google’s inclusion directly in the search results then compounds this.

When we do Zen Cart upgrades we use the patch files we have created, which can make it easier to do the upgrade than using the official Zen Cart method.

SiteLock Still Failing To Do Basic Security Check

Back in September we looked at the fact that a website we were doing an upgrade of Magento on had a security seal from SiteLock claiming that the website was secure, despite the fact that it wasn’t since the website was running outdated software with known security issues. Fast forward six months and SiteLock is still labeling websites as secure when they are running outdated and insecure software.

Today’s case involves a website that we are doing an upgrade from Zen Cart 1.3.8a. That version is nearly five years out of date and there have been numerous releases with security improvements since then (due to its age, it isn’t clear exactly how many of those fix issues that existed in 1.3.8a). Despite that the website is labeled as being secure by SiteLock:

Sitelock Security Seal

Not only does falsely claiming the website is secure mislead those visiting the website, but it also gives webmaster a false sense of security, which a security service shouldn’t do.

If SiteLock was actually interested in security it would quite easy for them to make sure the software on websites is up to date. Our Zen Cart Version Check extension for chrome is able to correctly detect the version in use from outside the website in this case:

Zen Cart Version Check

With access to the website’s file, as Sitelock does, it is even easier to do and more accurate. For Zen Cart the version number is listed in the file /includes/version.php, so all you would need to do is to check files matching that for the following lines and you would know whether an outdated version of Zen Cart is in use:

define(‘PROJECT_VERSION_NAME’, ‘Zen Cart’);
define(‘PROJECT_VERSION_MAJOR’, ‘1’);
define(‘PROJECT_VERSION_MINOR’, ‘3.8a’);

We Have Now Helped Get 16 WordPress Plugin Vulnerabilities Fixed

It has now been a little over three months since we introduced our Plugin Vulnerabilities plugin amid our renewed effort to improve the security of WordPress plugin and it seems like a good time to provide on what we have accomplished so far. For years we have discussing the problem that many publicly disclosed vulnerabilities existed in the current version of WordPress plugins and that those plugins were still available on the WordPress.org Plugin Directory. That obviously is bad sign for the overall security of WordPress plugins since making sure that known vulnerabilities get fixed is a low rung of making sure that plugins are secure. In the past we hadn’t kept track of how many of these vulnerabilities we had some part in getting fixed, but when we started working on the new plugin we started tracking that. This week two more of the plugins got fixes bringing the total to 16 vulnerabilities fixed in as many plugins. Developers of two more plugins have indicated that vulnerabilities in their plugin will be fixed in upcoming releases.

One of the vulnerabilities fixed this week gives an indication of how poor the situation still is years after we first noticed it. Back on September 1 a vulnerability was publicly disclosed in the Easy Media Gallery plugin, which has 10,000+ active installs. The person disclosing the vulnerability decided not to inform the developers beforehand and it would appear no one else bothered to either considering that a fix was released within two day of us informing them on Monday. It wasn’t a case that no one else saw the post as there are several comments and two follow up posts have comments from people complaining the discoverer is not informing developers of the vulnerabilities.

The first comment on that post ties into another troubling issue that we have seen in the vulnerabilities fixed. The commentor mentions that they would inform the developers of WPScan, which they describe as a ” black box WordPress vulnerability scanner”, of the vulnerabilities. The commentor did in fact do that.  It would appear that WPScan folks didn’t inform the developer of the vulnerability either. That certainly wouldn’t be the first time, as previously discussed in another situation they disclosed a serious vulnerability in a plugin but didn’t bother to inform the developer, which meant that like this vulnerability, it wasn’t fixed. We also found that they put vulnerabilities in their database, but don’t inform the developers of them, so that people with malicious intent are aware of vulnerabilities but everyone else is left vulnerable.

While just informing the developers of the vulnerabilities can in many cases get the vulnerability fixed quickly we have found that in other cases that isn’t enough. For example, in the case of the Xcloner plugin it required the Plugin Directory having removed the plugin, after we reported it to them, for the developer to finally fix the vulnerability. In other cases we have found that despite discoverer of the vulnerability and the developer of the plugin saying the vulnerability had been fixed, it actually wasn’t. But our checking, done while determining what versions are vulnerable when adding the vulnerability to the Plugin Vulnerabilities plugin, have led to the vulnerabilities actually getting fixed.

If you run across a report of a vulnerability in the current version of a WordPress plugin please make sure to inform the developer of the plugin and or the people running the Plugin Directory. You can also let us know by leaving a message in the support forum for Plugin Vulnerabilities or sending an email to pluginvulnerabilities@whitefirdesign.com, which will allow us to add the vulnerability to our plugin and make sure that the vulnerability is handled properly.

MOJO Marketplace Sells WordPress Security Service While Using Insecure WordPress Version

In a previous post we looked at the fact that MOJO Marketplace distributes outdated software with known security vulnerabilities. Their lack of concern for security doesn’t end there; they have not kept their WordPress installation up to date:

The MOJO Marketplace blog is running WordPress 4.0

 

If they actually used their own service they could be up to date, because unlike other software they offer they actually provide the latest version of WordPress:

MOJO Marketplace is providing WordPress 4.1.1

Not only have they not updated to the latest major release of WordPress, 4.1, they haven’t applied the “critical security release” for 4.0 that was released on November 20. That would have normally have happened automatically, so either they disabled automatic updates, which is bad idea if you are not going to be on top of updating WordPress, or they have some problem blocking that from happening. If there was a problem and they actually cared about WordPress security getting to the bottom problem would have been the right thing to do as it could possible help others as well. Their lack of concern for the security of WordPress on their own website hasn’t stopped them from feeling it is appropriate for them to sell a WordPress security service to others though.

If you are looking to improve the security of your WordPress website you should check out our free Plugin Vulnerabilities plugin, which warns if you are using WordPress plugins with known security vulnerabilities.

MOJO Marketplace Distributing Software With Known Security Vulnerabilities

Last week we noted that web hosts should stop providing the SimpleScripts software installation service to their users since it hasn’t been supported for some time, leaving people with outdated and insecure software on their websites. As part of that we noted that it looks like their service was replaced with the MOJO Marketplace. We decided to take a quick look at that service to see if they were keeping the software provided though it up to date and the results show that they have some problems, though nowhere near as bad as we found with GoDaddy last November.

To start with, they are still offering Joomla 2.5, despite support for that version having ended in December:

MOJO Marketplace is providing Joomla 2.5.28

Somewhat oddly they provide the latest version of Drupal 7, but they don’t provide the latest version Drupal 6, despite those being released together in November. That version of Drupal 6, 6.34, fixed a session hijacking vulnerability.

MOJO Marketplace is providing Drupal 6.33

For MediaWiki they have missed the last two updates to MediaWiki 1.23, both of which included multiple security updates. Version 1.23.7 was released in November and 1.23.8 was released in December.

MOJO Marketplace is providing MediaWiki 1.23.6

For Zen Cart they have missed version 1.5.3, which includes security improvements and was released last July, and 1.5.4, which was released at the end of last year.

MOJO Marketplace is providing Zen Cart 1.5.1

For concrete5 they have missed the last two updates to MediaWiki 5.6, both of which included multiple security updates. Version 5.6.3.2 was released in September and 5.6.3.3 was released in February.

MOJO Marketplace is providing concrete 5.6.3.1

Many WordPress Plugin Vulnerabilities Have Not Been Fixed

As of today’s release, our Plugin Vulnerabilities plugin includes entries for 200 security vulnerabilities that have existed in WordPress plugins. While that is far from all of the vulnerabilities out there, it does include a good mix of vulnerabilities. So far we have focused on adding newly discovered vulnerabilities, vulnerabilities that we are seeing exploit attempts for, and vulnerabilities from the archives of security researchers. We have included some stats we collected on those vulnerabilities below.

One stat stands out, over a quarter of the vulnerabilities – 54 of 200 – have not been fixed. A few of these were only recently discovered or the developer was only recently informed of them (all too often no one bothers to inform the developer and this is something that our work on the plugin has been rectifying), but for the vast majority there has been ample time and notice to the developer so they should have been fixed by now. This is a big problem because simply keeping plugins up to date won’t protect you if the latest version of the plugin has a known security vulnerability that can be exploited.

Right now what happens when a vulnerability isn’t fixed is that the plugin will be removed from the WordPress.org Plugin Directory until it is fixed, assuming the people running the Plugin Directory are informed of the issue. That does nothing for any websites that already have the plugin installed though. It is a problem we have been highlighting for three years now, without getting a solution. It also has been over two years since there was indication that a solution was being worked on. We hope that it won’t take another year to finally get fixed. In the meantime you can use our Plugin Vulnerabilities plugin to get alerted to known vulnerabilities in installed plugins and our No Longer in Directory plugin to find out what installed plugins have been removed from the WordPress.org Plugin Directory.

Plugin Vulnerability Stats As of March 2, 2015

  • 200 vulnerabilities included
  • 54 included vulnerabilities are in the most recent version of plugins (49 of these plugins have been removed from the Plugin Directory)
  • 14 vulnerabilities have been fixed in part due to our work on this plugin
  • 5 included vulnerabilities in security plugins
  • Top vulnerability types:
    • cross-site request forgery (CSRF)/cross-site scripting (XSS): 49 vulnerabilities
    • reflected cross-site scripting (XSS): 39 vulnerabilities
    • unrestricted file upload: 31 vulnerabilities
    • arbitrary file viewing: 16 vulnerabilities
    • SQL injection: 15 vulnerabilities
  • Top vulnerability discoverers:

WordPress.org Makes It Harder For Security Journalists to Hype WordPress Plugin Vulnerabilities

Last Wednesday we discussed an ongoing issues where security journalist conflate WordPress plugin’s download count at WordPress.org with how many websites are using the plugin, making a vulnerability seem like it has much larger impact than it actual it does. In the case last week the headlines proclaimed things like “More than 1 million WordPress websites imperiled by critical plugin bug” about a security vulnerability that existed in older versions of WP Slimstat, beyond explaining the fact that the security vulnerability in question was unlikely to be widely exploited, we pointed out that the website count used was way off base. The journalist were taking the 1.3 million downloads the plugin had and using that to back up their claim on over 1 million websites impacted, which they shouldn’t have since it isn’t close to being appropriate substitute for an actual count of use.

Over the weekend WordPress.org made a change that should stop this, as they started displaying a count of Active Installs in addition to download counts for WordPress plugins. In the case of the WP Slimstat plugin the actual number of websites using it is much less than a million, with the Active Installs listed at 100,000+:

wp-slimstat-active-installs

Hopefully this will be a wake-up call to some of those journalist that they need to stop taking so many liberties when reporting on WordPress plugin security issues, since this isn’t the only problem that there has been with their coverage of the issue (which could use more quality coverage).

Note to Web Hosts: SimpleScripts is No Longer Being Updated

When it comes to what needs to be done to improve the security of websites there are so many things that could and should be done, but certain of them stand out for various reasons. One of the issues that stands out for us is web hosts who are distributing outdated web software. Web hosts are quick to blame many hacks on outdated web software – usually without evidence to support the claim – so you would think they would be careful about making sure that when they distribute web software through one-click installers and other similar mechanism that they are keeping the version available up to date. Too often that isn’t the case, back in November we looked at GoDaddy’s distribution of quite old versions of various software. The other day we ran across another example worth highlighting involving the one-click installer SimpleScripts.

While doing a cleanup of a hacked WordPress website we logged into the web host’s control panel for the website and got a pop up that the WordPress installation needed to be updated. Following the link in that brought up the SimpleScripts upgrade page and on that there was obvious problem, it listed the current version of WordPress as 3.9:

SimpleScripts Web Page Screenshot

Version 3.9 hasn’t been the current version since 3.9.1 was released on May 8, 2014. A quick look at the list of the software versions provided by SimpleScripts showed that WordPress wasn’t alone in having a very out of date version provided. As best we can tell SimpleScripts is not being supported anymore. The SimpleScripts website makes no mention of it, but it appears that the service might have been replaced with another one-click installer MOJO Marketplace.

If you use a web host that is still using SimpleScripts please let know that it is no longer being updated and should be replaced.

One Easy Step To Hype A WordPress Plugin’s Security Vulnerabilty

We would love to see more quality press attention to the issue of WordPress plugin security because there certainly is much discuss, unfortunately, as with security journalism in general, when it does get discussed these days the reporting is mostly awful. Take for instance the Ars Technica article More than 1 million WordPress websites imperiled by critical plugin bug (written by the same person who last year wrote an article that we found to be completely baseless).

The words imperiled and critical are probably not appropriate, considering that the vulnerability in WP Slimstat was fixed in an update last week (you can turn of WordPress ability to automatically updates plugins with one of our plugins) and due to the type of vulnerability. The vulnerability is a blind SQL injection vulnerability, which can allow data to be read out of the database. While this has the potential to be rather serious if you store sensitive data on the website, this type of vulnerability isn’t often exploited by hackers that are not targeting specific websites (most hacks are not targeted). So the chances of it being exploited are rather small in comparison to say a vulnerability that allows PHP files to be uploaded to a website, which we can almost guarantee is going to be exploited, most likely sooner rather than later. The chances of this plugins vulnerability being exploited are even slimmer because it requires a fair amount computing being done before you can exploit it, unlike plenty of other blind SQL injections that have been found in WordPress plugins.

The big problem with the article comes from the claim in the title that “more than 1 million WordPress websites imperiled”. Over a million websites impacted make this sounds like a major issue, the problem is that it isn’t close to being true. If you read through the article nothing is provided that backs that number up, instead only the download count of the plugin is mentioned:

WP-Slimstat is an analytics tool. Its listing on WordPress shows it has been downloaded more than 1.3 million times. People who operate websites that use the plugin should update immediately.

Downloads of software obviously are not the same as how many websites are using software, so treating them the same is something a journalist concerned about accuracy wouldn’t be doing. But what makes it so bad for WordPress plugins is that each time a plugin gets updated through the WordPress admin area that counts as new download, so the actual user count is going to be much smaller than the download count, especially if the plugin is updated frequently. The download graph for one of our plugins dramatically shows how updates impact the download count:

download-count-graph

You see that huge spike that on the graph, that is when we updated the plugin. On that day there were 148 downloads and the next day there 47 the next day. That compares to 9 downloads a day we averaged over the last week. Those two days work out to 13 percent of total downloads so far.

WP Slimstat is updated more often so there are lots of spikes on the graph, of which, most if not all are due to updates:

wp-slimstat-download-graph

Ars Technica isn’t alone in this, a quick search pulled up more articles on this vulnerability with the same highly inflated website use count:

It also worth mentioning that this type of article has the potential to be somewhat harmful to security since you need to being keeping your WordPress plugins update to date all the time instead of trying to be on the lookout for mentions of fixed security issues since security fixes often are not even mentioned in plugins’ changelogs.