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.

Posted in Bad Security, Sucuri Security, WordPress Plugins | Leave a comment

An Easy Way to Check If You Are Using Vulnerable Versions of Revolution Slider, Showbiz Pro, and Other WordPress Plugins

When it comes to the security of WordPress, despite lots of misinformation and outright fear mongering, the security is quite good. The developers of WordPress have been quite good at handling security, and when a security issue is found they promptly respond to the issue and the fully automatic update mechanism for security updates included since WordPress 3.7 means that those security updates are promptly applied for most websites. Unfortunately the handling of security of plugins isn’t as good. While most of the vulnerabilities found in plugins are unlikely to lead to your website being hacked, there are some that are easily exploitable. In most cases simply updating your plugins when WordPress notifies you of a new version will protect you (or setting them to automatically update with our Automatic Updates Plugin or another similar tool), but there are a couple of situations where that isn’t true.

The first situation is where a plugin that is in the wordpress.org Plugin Directory has a vulnerability that isn’t’ fixed. Once the people running Plugin Directory are informed of the issue they will pull the plugin. That will prevent anyone more from installing the plugin but leaves everyone already running the plugin vulnerable as they are not provided any warning. We have been pushing for that to be changed for several years, but that still hasn’t happened. If you would like to see that change then please vote for that to happen.

The second situation is where a vulnerability exists in a plugin that isn’t in the wordpress.org Plugin Directory. While it is possible for these plugins to be hooked into WordPress’s normal update mechanism that isn’t always done, leaving the admin of the website to be unaware of a new version with a security fix being available.

For the first situation, we have for some time provided a plugin that lists installed plugins that have been removed from the directory and in some cases also includes a security advisory. For the second situation, we have new plugin that can help with that by warning if versions of plugins with known vulnerabilities are installed in WordPress.

Let’s take a look at how that works. Recently the Revolution Slider and Showbiz Pro plugins have been getting a lot of attention for a couple of security issues that existed in older versions. The first vulnerability allowed the viewing of arbitrary files (that could be exploited to view the database credentials stored in the wp-config.php file), that impacts Revolution Slider versions 4.1.4 & below and Showbiz Pro versions 1.5.2 & below. The second and much more serious vulnerability allows malicious files to be uploaded on to the website, that impact Revolution Slider versions 3.0.95 & below and Showbiz Pro versions 1.7.1 & below. If you have our Plugin Vulnerabilities plugin installed and you have one of those versions of Revolution Slider or Showbiz Pro installed you will see an alert message on the Installed Plugins page like this:

alert message shown for vulnerability in Revolution Slider

In addition to the vulnerabilities in Revolution Slider and Showbiz Pro our plugin currently has data on 116 vulnerabilities. That is still a small portion of all the plugin vulnerabilities out there, but we are continuing to add additional vulnerabilities. This week we added 30 vulnerabilities to the plugin. Going back to the first situation where plugin have been removed from the wordpress.org Plugin Directory the plugin also helps with that as we have data on security vulneabilities in the most recent versions of 24 plugins, which have been removed from the Plugin Directory.

With the plugin you can also see vulnerabilities that have existed in other versions of plugins you have installed from the Plugin Vulnerabilities page in the Plugin menu.

Posted in WordPress Plugins | Leave a comment

Wordfence and WPScan Acted Irresponsibly With WordPress Plugin Vulnerability

Several years ago we noted a pretty big problem when it came to the security of WordPress plugins; many plugins with known security vulnerabilities in their most recent version were still available in the wordpress.org Plugin Directory. That was a big failure as making sure that those vulnerabilities were fixed or the plugin was pulled until it was fixed was such a low hanging fruit towards better plugin security. For a while after that we were keeping a watch for unfixed vulnerabilities to make sure that wasn’t occurring, but after a while we were simply too busy with services unrelated to security of WordPress that we didn’t have time to do this anymore. Recently we again had time to focus on the security of WordPress plugins, as part of that we started working a new plugin, Plugin Vulnerabilities, which lets you know of security vulnerabilities that exist and existed in the plugins you have installed.

When we started working on the plugin we quickly found that the issue of plugins with known vulnerabilities in their most recent versions still being available in the wordpress.org Plugin Directory hasn’t gone away. In less than a month we have helped to get known vulnerabilities in seven plugins fixed by either contacting the developers of the plugins – who in many are not notified by the person who discovered the vulnerability – or letting the people running the Plugin Directory know that a vulnerability exists in the plugin. Some of them were rather serious, one that we mentioned before involved a backup plugin that permitted any logged in user to download backups made by the plugin. In that case within a day of us passing along the issue to the Plugin Directory people the issue was resolved, that was after almost a month had gone by since the developer had been notified of the issue and two weeks after it was made public.

While looking into another vulnerability we found something more troubling. On September 10 a claimed vulnerability was disclosed in the plugin Rich Counter. In late November when we took a look at it to verify that it was real before add it to our plugin, we found that as described the exploit didn’t work. To exploit the vulnerability it said you should change your web browser’s user agent to “Mozilla<script>alert(document.cookie)</script>”. For us it didn’t work that way, but it did work if you removed “Mozilla” from the start of the user agent. We were somewhat curious as to what had happened to cause a situation where a vulnerability was correctly identified but the explanation of the exploitation of it to not work. We thought it might be case where someone else had actually discovered the issue and someone else was trying to take credit for it. We didn’t find anything to explain the situation, but while doing that we found that several WordPress related security projects had mentioned the disclosure of the vulnerability. We are rather troubled that they were aware of the vulnerability but had not made sure it was fixed or the plugin was pulled from the directory. What made this worse was that within days of us alerting the developer to the issue a partial fix was made and after further message the issue appears to be fully fixed. It would have been quite easy for them to have done the same, but they didn’t leaving website vulnerable when they didn’t have to be, so we feel it is worth highlighting their irresponsible behavior.

First up is Wordfence, which sells a WordPress security service. They mentioned the vulnerability back on October 30 in a post about plugins with vulnerabilities they wanted  “to draw your attention to”, unfortunately they were more interested in drawing your attention to their website then actually drawing the attention of the developer to the issue who would have actually fixed the issue if they had contacted them as we did (or if the developer was unwilling at that time Wordfence should have then contacted the WordPress.org Plugin Directory about it).

The other place we found it mentioned was the in WPScan Vulnerability Database, a website that lists WordPress vulnerabilities,  in an entry added on October 18. Again this came from someone selling WordPress security services and the project is also sponsored by another security company Sucuri. You have to question why security companies would be in the business of providing wider notice of security vulnerabilities in WordPress plugins but not letting the developer, who could actually fix the issue, or the people at the Plugin Directory know about the issue if their interest was truly in security versus making you more vulnerable and then selling you their security services.

Posted in Bad Security, WordPress Plugins | Leave a comment

Be Careful With Your Website’s Backup Files

When a high profile website gets hacked it always useful to see what lessons can be gleamed to insure that other websites don’t get hacked. Several days ago the technology website Ars Technica (who doesn’t have the best track record with security reporting) was breached, while the details on how they were hacked are somewhat limited, one thing stood out (emphasize ours):

At 20:00 CT on December 14, an Internet intruder gained access to one of the Ars Web servers and spent the next hour attempting to get from the Web server to a more central machine. At 20:52, the attempt was successful thanks to information gleaned from a poorly located backup file.

That is a good reminder that since backup files often store sensitive information (including database login details and user info), securely storing them is important to the security of your website. For example, you would not want to store the backup in a file named backup.zip in the root of your website since hackers will go looking for that as can be seen in the log file entries below from a recent attempt to find backup files on our website:

124.231.26.79 – – [03/Dec/2014:04:11:07 -0500] “HEAD /www.whitefirdesign.com.7z HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:07 -0500] “HEAD /www.whitefirdesign.com.xls HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:08 -0500] “HEAD /www.whitefirdesign.com.xlsx HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:09 -0500] “HEAD /www.whitefirdesign.com.sql HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:10 -0500] “HEAD /whitefirdesign.com.rar HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:12 -0500] “HEAD /whitefirdesign.com.zip HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:12 -0500] “HEAD /whitefirdesign.com.7z HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:14 -0500] “HEAD /whitefirdesign.com.xls HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:15 -0500] “HEAD /whitefirdesign.com.xlsx HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:15 -0500] “HEAD /whitefirdesign.com.sql HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:16 -0500] “HEAD /whitefirdesign.rar HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:17 -0500] “HEAD /whitefirdesign.zip HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:18 -0500] “HEAD /whitefirdesign.7z HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:19 -0500] “HEAD /whitefirdesign.xls HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:20 -0500] “HEAD /whitefirdesign.xlsx HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:20 -0500] “HEAD /whitefirdesign.sql HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:21 -0500] “HEAD /back.rar HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:22 -0500] “HEAD /back.zip HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:23 -0500] “HEAD /back.7z HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:23 -0500] “HEAD /back.xls HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:24 -0500] “HEAD /back.xlsx HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:25 -0500] “HEAD /back.sql HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:26 -0500] “HEAD /backup.rar HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:27 -0500] “HEAD /backup.zip HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:28 -0500] “HEAD /backup.7z HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:29 -0500] “HEAD /backup.xls HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:30 -0500] “HEAD /backup.xlsx HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:31 -0500] “HEAD /backup.sql HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:31 -0500] “HEAD /web.rar HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:32 -0500] “HEAD /web.zip HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:33 -0500] “HEAD /web.7z HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:34 -0500] “HEAD /web.xls HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:35 -0500] “HEAD /web.xlsx HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:35 -0500] “HEAD /web.sql HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:36 -0500] “HEAD /webroot.rar HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:37 -0500] “HEAD /webroot.zip HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:38 -0500] “HEAD /webroot.7z HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:39 -0500] “HEAD /webroot.xls HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:40 -0500] “HEAD /webroot.xlsx HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:41 -0500] “HEAD /webroot.sql HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:41 -0500] “HEAD /www.rar HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:42 -0500] “HEAD /www.zip HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:43 -0500] “HEAD /www.7z HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:44 -0500] “HEAD /www.xls HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:45 -0500] “HEAD /www.xlsx HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:46 -0500] “HEAD /www.sql HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:46 -0500] “HEAD /wwwroot.rar HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:48 -0500] “HEAD /wwwroot.zip HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:48 -0500] “HEAD /wwwroot.7z HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:49 -0500] “HEAD /wwwroot.xls HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:50 -0500] “HEAD /wwwroot.xlsx HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:51 -0500] “HEAD /wwwroot.sql HTTP/1.1″ 404 506 “-” “-”

Unfortunately not every risk is that easy to spot, take for example a vulnerability in the XCloner – Backup and Restore WordPress plugin that we discussed last week that allowed any logged in user to download any backups made by the plugin.

Posted in Website Security | Leave a comment

The Joomla Extension Directory Finally Moves Off of Joomla 1.5

When it comes to the security of websites what we see is that basic security measures are often not taken and unfortunately all too often those measures are not being taken by those who should know better and have the ability to make it easier to accomplish them. Take for instance the Joomla, until yesterday the Extension Directory portion of their website, an important section of the website, was still running Joomla 1.5:

jed-joomla-15

That is despite the fact that support for that version ended back in September of 2012. It obviously doesn’t look good when the developers of software can’t even keep on a supported release of their own software.

Thankfully, the Extension Directory has now been moved to Joomla 3.3:

jed-joomla-33

Unfortunately it doesn’t appear that even their inability to get off of Joomla 1.5 for so long has lead them to provide anything to make it easier to move off that version, which many others still remain on.

Posted in Bad Security, Joomla | Leave a comment

Security Vulnerability Fixes Often Left Unmentioned In WordPress Plugin Changelogs

When it comes to security companies, we often see that they seem less interested in actually improving security than getting themselves attention. In some cases the harmful effects of this are quite obvious, like when a security companies falsely implicates a piece of software as being a common connection between a group of hacked websites leading people to believe that software is insecure when it isn’t. A less obvious situation where this attention seeking comes in to play is when a security company warns that you need to update a WordPress plugin since it has a security vulnerability. What could be the problem with that you are probably thinking? The answer is that you need to update all of your plugins in a timely manner, and not try to keep track of what ones might have a security vulnerability and therefore need to be updated immediately. The reason for this is that there is a good chance that you won’t be able to tell if an update fixes security vulnerability, even if you review the changelog for plugin (which in turn is more likely to warn you about security issue than following any security company).

Recently we started working on a new plugin, Plugin Vulnerabilities, that provides information on vulnerabilities that exist and previously existed in the plugins you have installed in WordPress. One of the places we look at when determining what versions of a plugin are susceptible to a vulnerability is the plugin’s changelog. In doing that we have found that the amount of details provided in the changelog when a security issue is fixed varies widely. In many cases the fact that a vulnerability has been fixed is disclosed (sometimes with basic details of the vulnerability include as well), but in plenty of cases there is no mention at all that a security vulnerability has been fixed.

To get a better idea how frequently security vulnerability fixes are left out of the changelog, we went through the vulnerabilities currently listed in our Plugin Vulnerabilities plugin for which the relevant plugin is currently in the wordpress.org Plugin Directory and tallied up whether the vulnerability being fixed was mentioned in the changelog or not. In our sample of 66 plugin updates, we found that in 19.7 percent of them the changelog made no mention of a vulnerability being fixed. The breakdown of the changelog mentions are as follows:

  • 43 updates listed that a vulnerability fix was included
  • 10 updates mentioned that a fix for a potential or possible vulnerability was included (in all cases the vulnerability was in fact exploitable)
  • 13 updates made no mention of a vulnerability being fixed

Jut based on the fact that you have about a 1/5 chance that a security fix isn’t mentioned in changelog, not updating plugins all the time seems like a bad idea, but what is more important is how severe the vulnerabilities fixed that are not mentioned can be. Take for instance version 5.2.91 of Special Text Boxes plugin, which had the following listed as the change made in the release:

The possibility of manipulating custom themes has been removed by request of administration of wordpress.org plugins repository.

Would you have guessed that referred to fixing an arbitrary file upload vulnerability that was being actively exploited before 5.2.91 was released? Probably not.

Posted in WordPress Plugins | Leave a comment

The Security Risks That Could Be Lurking in Your WordPress Backup Plugin

One of the things that we have noticed in looking at security vulnerabilities in WordPress plugins over the years is that backup plugins are often found to have vulnerabilities. While working on our new plugin that lets you know what vulnerabilities are or have in the past existed in the WordPress plugins you use we have seen that the poor security of backup plugins is continuing. Two examples highlight the problems with security of not just backup plugins, but all plugins.

DB Backup Plugin

Because backup plugins create files containing sensitive data, backup plugins need to prevent unauthorized users from downloading those files. One way to do that is block direct access to the files and then permit users to download them through the plugin. Unfortunately that can introduce a new security risk since if the download mechanism is not secured it can be abused to download files that someone shouldn’t have access to. That is the case with the plugin DB Backup, which was found to allow anyone to download arbitrary files from the website. That could for example be used to download the wp-config.php and therefore provide the login credentials for the website’s database.

The bigger problem that this highlights is what happens when a security vulnerability doesn’t get fixed, as is the case with this plugin. Right now if you go to the page for this plugin https://wordpress.org/plugins/db-backup/ you get served a search page:

Page shown for https://wordpress.org/plugins/db-backup/

This is due to the plugin being pulled from the Plugin Directory, probably due to someone notifying WordPress of the issue. This prevents anyone from downloading the plugin, but what about people that already have it installed? Unfortunately they are not given any notice that they are using a plugin with a security vulnerability. That obviously shouldn’t be the case, but despite our pushing for that to change for years WordPress still has corrected this issue. If you would like to see that change then please vote for that to happen.

XCloner – Backup and Restore

Another general problem with plugins is that the developers don’t always have much concern for security. The developer of the XCloner – Backup and Restore plugin falls in to that category, which has put the users of the plugin at risk in multiple ways.

The most recent vulnerability discovered in the plugin allowed any one who could log in to WordPress to download any backup files created by XCloner. What is of more concern is the developer’s response. The person who discovered vulnerability states that they notified the developer on November 7 and 13, the vulnerability wasn’t fixed after either of those. It also wasn’t fixed after the vulnerability was publicly disclosed on November 19. It finally got fixed within a day of us reporting the vulnerability to WordPress and the plugin being pulled pending a fix. You can see they only had to make minor changes to fix the issue, so this could have easily been fixed before if they had been interested. If we hadn’t reported the vulnerability it is quite possible the vulnerability still wouldn’t have been fixed.

This isn’t an isolated incident. Below is the list of the unsuccessful attempts a security company made to notify of them of vulnerabilities in a standalone version of XCloner:

- 6 notifications by email
– 4 notifications via contact form
– 1 notification via twitter.

The latest vulnerability is one of five that have been discovered in the plugin. The others are:

The developer’s lack of concern for security isn’t just for their software, seeing as their website is currently running a nearly four year old version of WordPress:

 

The XCloner website is running WordPress 3.0.5

Posted in WordPress Plugins | Leave a comment

Magento Adds PHP 5.5 Support with Magento 1.9.1.0

Our previous posts about using Magento with PHP 5.5 continues to be one of our most visited posts, so there are sure to be lots of people interested to hear that with the release of Magento 1.9.1.0, Magento now officially supports PHP 5.5.

Magento continues to be rather slow in supporting new versions of PHP, as it took 17 months after PHP 5.5’s release for support to be added, but that was improvement from the 23 months it took for PHP 5.4 support to be added. PHP 5.6 was released at the end August, so they are still not up to date, but at this point we haven’t dealt with any one looking to use Magento with PHP 5.6, so it doesn’t seem to be much of an issue yet.

If you are need of a Magento upgrade to support PHP 5.5 or take advantage of the other new features, including security enhancements, in 1.9.1.0 we can take care of that for you.

Posted in Magento | Leave a comment

GoDaddy Distributing Software With Known Security Vulnerabilities

Oftentimes when a website is hacked the web host will blame the hack on outdated software running on the website. From our experience they often do this without any evidence to back that up and in some cases they obviously haven’t even checked if the website is running outdated software since the website in question was using up to date software at the time of the hack. Based on that you would think that web hosts would be very careful when distributing software to their clients that they make sure that it is up to date, but as we keep seeing that isn’t the case. The latest example this came up while we were looking into GoDaddy’s bad response to the Drupal 7 vulnerability. We noticed in their Hosting Connection, which they say has been used to install 6.9 million apps, that they were still installing Drupal 7.32:

GoDaddy's Hosting Connectin is installing Drupal 7.32

Drupal 7.33 was released last Friday and includes “numerous bug fixes”. Since the new version didn’t include any security fixes it wasn’t a huge issue that they hadn’t updated the version they installed yet. But then we started looking at the version of other software they were offering and things got much worse.

They are still installing Joomla 2.5.14:

GoDaddy's Hosting Connectin is installing Joomla 2.5.14

 

That version is now a year out of date, the next version was released on November 6, 2013, and GoDaddy hasn’t updated their Joomla version despite there having been four subsequent releases with security fixes (2.5.1.5, 2.5.19, 2.5.25, and 2.5.26).

Joomla is among the software GoDaddy lists as being the five most popular in the Hosting Connection and unfortunately isn’t the only one where they have failed to keep up with security updates. They are currently installing Simple Machines Forum version 2.0.6:

GoDaddy's Hosting Connectin is installing Simple Machine Forum 2.0.6

Version 2.0.9, which was released over a month ago, addressed “several security issues” and the developers recommended “that you update your forums immediately to ensure that your community is safe”.

Looking at other software we work with frequently we found more problems. GoDaddy is still offering MediaWiki 1.21.1:

GoDaddy's Hosting Connectin is installing MediaWiki 1.2.1.1

Support for the MediaWiki 1.21.x series ended back in June, so GoDaddy should have switch to a newer series by that point. Before that though they failed to update for any of the nine security updates (1.21.2, 1.21.3, 1.21.4, 1.21.5, 1.21.6, 1.21.8, 1.21.9, 1.21.10, and 1.2.11) released for the 1.21.x series.

Next up, GoDaddy is still offering OpenX despite it being re-branded as Revive Adserver over a year ago:

GoDaddy's Hosting Connectin is installing OpenX 2.8.3

The version they are offering is nearly five years out of date, the next version was released in January of 2010, and they fail to update for the last eight security updates (2.8.6, 2.8.7, 2.8.8, 2.8.9, 2.8.10, 3.0.0, 3.0.2, and 3.0.5).

For Moodle they are still providing Moodle 1.9.19:

GoDaddy's Hosting Connectin is installing Moodle 1.9.19

That was the last release of the Moodle 1.9.x series, for which support for security fixes ended entirely last December. Anyone unlucky enough to install this version and start using it now would discover they will have a lot of work to get it to a supported version as the upgrade from Moodle 1.9.x to 2.x is a major one and they will have to do at least two upgrades as you have to an intermediate upgrade 2.2.x before getting to a supported version.

GoDaddy’s Partnership with SiteLock

It gets worse from there, while GoDaddy is putting their client’s websites at risk they then want to sell them additional service to “Defend your website against hackers.”, which is done in partnership with SiteLock. We would ask how it is that SiteLock hasn’t informed them about the issue with outdated software but our past experience is the SiteLock doesn’t do the basic security check of making sure the software on a website is up to date, which would expect from a company that GoDaddy says provides the “most advanced and complete security solution available”, or make sure that software gets updated when they clean up a hacked website.

Posted in Bad Security, Outdated Web Software | Leave a comment

GoDaddy’s Bad Response to the Drupal 7 Vulnerability

Back on October 15, Drupal released Drupal 7.32, which resolved a highly critical security vulnerability that existed in prior Drupal 7 versions. Unlike security vulnerabilities that have been fixed in recent years in Drupal and other major software, this vulnerability was easily exploitable. By the next day we were seeing attempts to exploit the vulnerability and we have been seeing a steady pickup of people contacting us about cleaning up their hacked Drupal websites, which were hit due to this. The speed and scope of the exploitation points to the need to improve how security vulnerabilities are handled in Drupal and more broadly.

Since making software that is completely free of vulnerabilities is next to impossible the best solution for this type of situation is to introduce an improved upgrade mechanism, like the one in WordPress. Starting with WordPress 3.7, security updates are automatically applied without requiring any user intervention. Checks for new versions are normally done every 12 hours and the WordPress server can instruct them to happen more frequently ahead of a planed update, so within a day most websites will have the security update applied. Not only does this protect those websites, but it makes the remaining vulnerable websites a less attractive target since the success rate of trying to exploit the vulnerability is much smaller (that doesn’t mean that they won’t get hacked though).

In the meantime, getting the word out on the need to update or take remedial as soon as possible is important to lessening the severity of security vulnerabilities. In this case Drupal recommend restoring a backup from before October 15 if you didn’t upgrade right away and every day that passes makes it harder to do that. Web hosts could play an important role in getting the word out. At least some of the largest web hosts already have the capability to detect what software and in some cases what version is in use, so they can inform impacted customer of the situation. GoDaddy has attempted to do this for the Drupal 7 vulnerability, though their implementation leaves a lot to be desired.

Today we have had a number of people contacting us saying that they had just been informed of they needed to upgrade Drupal due to a security issue. Considering that the last security update for Drupal 7 was 7.32 and that was released in the middle of October we were wondering what was causing this. It turns out that GoDaddy has just been letting people know of the vulnerability. While rather late, what was more problematic was what they said in the email.

The first big problem is that based on their email you would think that that is just occurred:

A few days ago Drupal announced a “Highly Critical Public Service announcement” that affects all Drupal users. In short, there’s a major security vulnerability that attackers can leverage against your visitors.

The Highly Critical – Public Service announcement was released back on October 29, not a few days ago. Even before that was released it was widely known that there was urgent need to update as the details of the vulnerability were disclosed with the release of the update on October 15.

The email gets more problematic from there. The beginning of the emails indicates that the required action is updating:

Action required:

Update your Drupal website

Later it says:

It’s extremely important that you update your site immediately to ensure you’re not putting your customers at risk.

At this point if you have Drupal 7 website still running a version below 7.32, that hasn’t been otherwise protected against the vulnerability, you should assume that it has been hacked, so just updating isn’t an appropriate resolution. That isn’t mentioned in the email at all, despite the public service announcement they cite being very clear about that.

Drupal Did Not Recommend This

After reading over this we were curious to see if GoDaddy was spreading this bad information on their website as well. It looks like they only got around to mentioning the issue on November 6, but at least in that case they provided accurate information. Another article linked to from that page those highly inaccurate though. Specifically the section Manually Remove Backdoors, which says:

If you do not have a backup of either your website or database (or both), you must manually remove any backdoors from your Drupal installation.

To do this for you, we offer an Expert Service for $79. With this service, we will perform all of the work for you to make our best effort to remove all backdoors using the procedures identified by Drupal. This service does not guarantee your website is free from compromise, but it is as close to compromise-free as anything can come if your Drupal installation wasn’t upgraded before the first reported compromises or restored from a backup created before Oct. 15, 2015 at 11pm UTC.

To purchase the Expert Service, contact customer support.

You can also manually remove any backdoors yourself using the Drupal-recommended procedure outlined here. This procedure is very complicated and requires an advanced understanding of the technologies Drupal uses (PHP, MySQL) to use effectively. Not all steps listed in the procedure are applicable to shared hosting environments, but completing what you can from this list will provide you the greatest likelihood of removing backdoors from your site.

If you follow the link “the procedures identified by Drupal”, you will find that it isn’t actual something from Drupal. Later GoDaddy links to the same page and describes it as the “Drupal-recommended procedure”, but if you actually look at the page it says “The official recommendation is: Restore from pre-October-15-backups.”. You really have to wonder about a company trying to sell you on an “Expert Service”, for which they don’t have the expertise to actually understand a basic, that is they they are citing something that isn’t actually procedures identified by Drupal or recommend by them.

Posted in Bad Security, Drupal | Leave a comment