Are Your Websites Up to Date?You can keep track of what versions of concrete5, Drupal, Joomla, Magento, MediaWiki, Moodle, PrestaShop, Revive Adserver, TYPO3, SPIP, WordPress, and Zen Cart are running on all of the websites you manage with our Up to Date? Chrome app.
Search This Blog
- Hackers Hiding Malicious Code in Exif Data of Images
- Outdated Software Is Not Necessarily the Cause Of Your Website Being Hacked
- ManageWP Shows Lack of Concern for Security by Running Insecure Version of WordPress
- Keeping Track of the Update Status of Web Apps on the Websites You Manage
- Drupal Websites Not Receiving Security Updates in a Timely Manner
Web Software Updates
WordPress VersionWe are running WordPress 3.9.2 and despite what many supposed "security experts" claim letting you know what version we are running does not make us less secure.
Did We Make a Mistake?While it seems to be acceptable for blogs discussing web security to contain numerous factual mistakes, we hold ourselves to a higher standard. We only write about things that we actually understand and only after we have double checked the information. So if you see a mistake in one of our posts please leave a comment on the post or contact us so that we can add a correction.
Category Archives: Website Security
As part of our continued focus on the problems related to the security of WordPress plugins, last month we compiled some statistics on plugin vulnerabilities found during the second quarter of 2012. As they might be useful to others we wanted to share them.
We used Secunia’s advisories for our data set as their advisories include vulnerabilities discovered by the developers of the plugins and those discovered by others, which provides a good mix of data. Secunia reviews the reported vulnerabilities so their advisories do not include false reports of vulnerabilities that we find in other sources of vulnerability data.
It is important to keep in mind that the vulnerabilities found are not necessarily representative of what vulnerabilities remain in plugins. A lot of what determines what vulnerabilities are found is what kind people happened to look for or find.
A few more quick notes on the data: we have excluded a plugin that was not ever available in the WordPress.org plugin directory, the data was generated on July 16, and the numbers in the charts do not correlate with each other as some plugins had multiple vulnerabilities.
This chart shows the breakdown of the types of vulnerabilities found in the plugins:
The largest percentage were reflective cross-site scripting (XSS) vulnerabilities, which, while serious, are not a kind of that are likely to be used in an targeted hack of a website so they are not a major concern. The second largest group of vulnerabilities was unrestricted file upload vulnerabilities. This type of vulnerability can be easily exploited to place backdoor script on a website, which a hacker can then use to do pretty much anything on the website. Some may be familiar with the TimThumb vulnerability, which was this type of vulnerability. That so many unrestricted file upload vulnerabilities were found is a good reminder of need for plugins with file upload capabilities to be carefully scrutinized to insure that plugins with this type of vulnerability are not available in the plugin directory.
This chart shows the number of plugins with vulnerabilities that have been fixed and not fixed:
That over a quarter of the plugins have not fixed is troubling, but even worse is the types of vulnerabilities in those plugins:
A third of those vulnerabilities are unrestricted file uploads. Not surprisingly due to the ease of exploitation and power granted, we have been seeing attempts to exploit the plugins found to have those vulnerabilities.
There is good news, plugins with unresolved security vulnerabilities are getting removed from the WordPress.org plugin directory, which had not always happened in the past. That is partly due to our making sure that plugins with unresolved security vulnerabilities are reported to the people maintaining the plugin directory, so that they get properly handled. Removing the plugins does not help when the plugin is already installed and that is why WordPress needs to provide alerts for removed plugins with unresolved security vulnerabilities. In the mean time you can use our plugin No Longer in Directory to check if you are using plugins that have been removed. If a removed plugin has a Secunia advisory that will be linked to in the plugin’s report.
Yesterday, Magento released an announcement on a serious security vulnerability in previous versions of Magento that “potentially allows an attacker to read any file on the web server” that “might include password files, configuration files, and possibly even databases if they are stored on the same machine as the Magento web server”. The vulnerability is due to a vulnerability in the XmlRpc component of the Zend Framework, which was announced last week. The details of the vulnerability can be found in the advisory by SEC Consult.
Magento has provided several solutions for protecting against this vulnerability. There is a workaround, patch files for older version of Magento, and a new release, 18.104.22.168, which is secured against the vulnerability. The workaround and patch files will resolve this issue for Magneto installations still running on outdated versions, but we would recommend, as always, that you upgrade to the latest version of software you run (the previous release, 22.214.171.124, fixed “some potential security vulnerabilities” according to Magento).
If you use any software that has the Zend Framework you should check to for an update or announcement from the developers on the status of the vulnerability in the software. Piwik announced last week that the current version of Piwik is not vulnerable as “Piwik neither uses nor includes the XmlRpc component from Zend Framework”. OpenX does contain the XmlRpc component and uses it, we didn’t check if their use is vulnerable but we did inform them of the vulnerability (we would strongly recommend strongly recommend against using anything from OpenX as they continue to have an atrocious security record). There are several WordPress plugins which contain the vulnerable component and we have informed the WordPress.org Plugin Directory maintainers of the vulnerability so they can take appropriate action.
Currently when a WordPress plugin is reported to have a security vulnerability it is removed from the WordPress.org Plugin Directory until the vulnerability has been resolved, but no warning is provided to anyone who already installed it. While many plugins are promptly fixed, there are quite a few that remain vulnerable for a long time or are never fixed. We think that WordPress should alert on the Installed Plugins page in WordPress if an installed plugin has been removed from the directory and provide at least a general reason it has been removed, as many are removed for reasons other than security vulnerabilities, so that appropriate action can be taken by admins. If you would also like to see that happen you can help by voting for our idea on the Ideas section of WordPress.org. To vote you will first need to create a WordPress.org Forum account (or log in if you already have account) and then you can rate the idea by clicking on one of the stars under the heading Rate This (click the right most star for the highest rating for the idea). You can also add your own comments on how the issue should be handled.
Until an alert is added in WordPress itself, you can get a more limited version of this functionality using our No Longer in Directory plugin (we just released our beginning of the month update for the plugin).
While we are discussing the issue of plugin vulnerabilities, we should say that since our last post about this we have been seeing that plugins with Secunia advisories for outstanding issues are being promptly removed from the Plugin Directory until those are resolved. This is great improvement from earlier this year when we found that vulnerable plugins had remained in the directory for years. With that happening we are now looking to make sure that they maintainers of the Plugin Directory are aware of any vulnerabilities which haven’t received Secunia advisories. We just reported a plugin that was found to have a fairly serious information disclosure vulnerability to them and they promptly took action (we alerted the developer of the plugin a week ago and had not received any response). For anyone that finds a vulnerability in a plugin available in the Plugin Directory and is unable to get a response from the developer, you can find directions for contacting the Plugin Directory here.
Over the past few weeks numerous serious security vulnerabilities have been found in WordPress plugins. Many of the vulnerabilities allow arbitrary file uploads, which can be used to add a backdoor script website to a website and allow an attacker remote access to the website. When websites are hacked using an exploit of software running on the website this is often the type of vulnerability that is utilized. Other vulnerabilities that have been recently discovered include file upload vulnerabilities limited to certain file extensions, remote file disclosure (so the contents of the wp-config.php or other sensitive file could be displayed), an SQL injection, and cross-site scripting (XSS) vulnerabilities. The details of many of the vulnerabilities can be found in Secunia’s advisories for them.
So far we have had several attempts on our website to exploit some of these plugins that had vulnerabilities related to Uploadify, which appears to have been first publicly disclosed on April 5. We have yet to see exploit attempts for any of the other plugins.
After spotting the attempts related to Uploadify, we started looking to the vulnerability and if the plugins had been fixed yet. During that process we noticed that some of those plugins were among a large number of plugins with unresolved vulnerabilities listed in recent Secunia Advisories. We then informed WordPress.org Plugin Directory maintainers of the plugins with those unresolved security vulnerabilities. We also informed them, as we have in the past, that they can that they can monitor Secunia Advisories for WordPress plugins, so that they are not reliant on issue being reported to them so that they can quickly respond.
The good news to report is that many of the plugins have been quickly updated to fix the vulnerabilities and the people in running the WordPress.org Plugin Directory have been fairly proactively in removing plugins from the directory until they have been fixed (though there are still some of the plugins we have notified them that still remain in the directory despite their vulnerabilities). The bad news is that some of the plugins are unlikely to be fixed and no warning is displayed in WordPress when these vulnerable plugins are installed. Until the time that WordPress handles that properly, which we have previously discussed the need to do, our No Longer in Directory plugin provides an interim solution. On the plugin’s page in WordPress it will identify any installed plugins that have been removed from the Plugin Directory and provides links to Secunia Advisories when available. We have just put out an update with a refreshed list of plugins removed from the WordPress.org Plugin Directory and added links to Secunia Advisories for 19 of the recent vulnerabilities. The Secunia Advisories include workarounds for the vulnerabilities, so that people running those plugins will be aware of a possible temporary fix for the vulnerability until it is hopefully properly fixed.
Last week we mentioned that we had found that a WordPress plugin that had a security vulnerability in its current version, that had recently been attempted to be exploited, had remained in the WordPress.org Plugin Directory for six months after it was publicly disclosed. That plugin had received an advisory from Secunia and we have reviewed the rest of Secunia’s WordPress advisories to check for any other plugins in the directory that also had unresolved security vulnerabilities. We identified 24 more plugins that have vulnerabilities in their current versions and had remained in the Plugin Directory since the advisory was released. We have reported those plugins to WordPress and they have been removed from the Plugin Directory. If and when the vulnerabilities are fixed they should return to the directory.
You can check if your WordPress installation is running any plugins that have been removed from the Plugin Directory, whether for security issues or other issues, with our plugin No Longer in Directory. We have just updated it with the plugins that we reported to WordPress and have added links to Secunia Advisories for any of the plugins that have received them.
The oldest Secunia advisory for a plugin with an unresolved issue that had remained in the Plugin Directory was from January of 2008 and the most recent was from February of this year. The types of vulnerabilities in these plugins included cross-site scripting (XSS), cross-site request forgery (CSRF), SQL injections, and file inclusion. These plugins had over 560,000 combined downloads. The number of downloads that individual plugins had ranged from 300 to 93,000. Four of the plugins had over 50,000 downloads, which should be a reminder that just because a plugin is popular it doesn’t mean that it is more secure than less popular plugins.
We also found a situation where a plugin had been removed from the directory but a fork of the plugin has remained in the Plugin Directory despite also containing the vulnerability and two plugins that had their vulnerabilities fixed but the version number was not changed so that people that already had the plugin installed will remain vulnerable to being exploited. Resolution on those plugins’ issues from WordPress is still pending.
We plan to review other sources of claimed vulnerabilities to see if there are more plugins with publicly known vulnerabilities in their current versions that have remained in the Plugin Directory.
While reviewing recent logs for attempts to exploit WordPress plugins, for another post on this blog, we spotted one plugin that seemed out of place. While nearly all of the exploit attempts involved plugins that were no longer in the WordPress.org Plugin Directory or had recently been updated with security fixes, the WP CSS plugin was in the directory but hadn’t been updated since 2009. We then got a copy of the plugin to see if the vulnerability that was being attempted to be exploited worked in the current version. A quick check showed that the exploit worked. According to Plugin Directory statistics as of Friday the plugin had been downloaded 17,803 times. That a plugin was available in the Plugin Directory that has vulnerability that is actively being exploited was troubling, but what we found next was more troubling.
Before contacting the developer of the plugin and WordPress, we decided to take a look if there was more information about the vulnerability available. We first found a post from someone who had also had recent attempts to exploit the vulnerability on their website. We then found a Secunia advisory for the vulnerability that was release on August 26, 2011. We also found that a company named SecPod had created a OpenVAS plugin for the vulnerability. It is also likely that exploit attempts were caught in various honey pots.
With the vulnerability being publicly known for at least six months and recent attempts to exploit it, the question that needs to be asked is how the vulnerable plugin continued to be available in the WordPress.org Plugin Directory all of that time. Did no one ever contacted WordPress about the vulnerability or were they contacted about it and decided not to remove the plugin, pending a fix? It seems highly unlikely that WordPress was contacted and left the plugin in the directory as they responded to our message, and removed the plugin, within in two hours of us contacting them. It is possible that some of the people who had spotted the vulnerability contacted the developer of plugin and had not contacted WordPress despite the plugin being hosted in the Plugin Directory and it being recommend that they be contacted about WordPress plugin security issues.
While it appears no one contacted WordPress, they still should have been monitoring for plugins included in the Plugin Directory that have a publicly released vulnerabilities. For Secunia, all WordPress related vulnerabilities can be found here.
For anyone running the WP CSS plugin they should remove the plugin or remove the w-css-compress.php file until it is fixed, unless they are comfortable making a modification to the file to prevent exploitation. Deactivating the plugin will not prevent the plugin from being exploited.
The other issue that this situation raises is the lack of information provided to those running plugins that have been removed from Plugin Directory for security issues, we have addressed that in another post on this blog and plugin that provides an interim solution for the problem.
These days when WordPress gets hacked it isn’t likely to be due to a vulnerability in WordPress, it’s much more likely to be due to a plugin. Unfortunately, there hasn’t been enough focus on the security issues related to plugins and working to fix those. A glaring example of this, that we found while preparing some information for this post, is that the WP CSS plugin contained a vulnerability that had been publicly known for six months, that the vulnerability had been recently attempted to be exploited, and yet it was still being distributed in the WordPress.org Plugin Directory until last Friday.
WP CSS also highlights another failing of the current plugin security handling. It’s something that we share some of the blame for because we should have realized the issue existed long ago and we are now trying to make an amends for that by taking on the issue. The following is the process that is supposed to take place after a security vulnerability in a plugin is reported to WordPress, as we had done with WP CSS.
- The plugin is de-listed from the repository, to prevent further downloads of an insecure plugin.
- If the exploit is accidental or not obviously malicious, the developer is notified via email. The email comes from a valid address (plugins at wporg) and can be replied to.
- The plugin developer presumably fixes the exploit or tells us that it is an invalid exploit, updates the plugin in SVN, and emails back saying so.
- We check it out, and either provide advice or re-enable the plugin.
For websites that haven’t had the plugin installed yet the process protects them from the vulnerability. But the same can’t be said for all the websites that already have the plugin installed. If the vulnerability is promptly fixed then the websites should be okay as long as the plugins on the website are kept up to date. The big problem comes when plugins are either not promptly fixed or never fixed at all. In those cases websites with the plugin installed admins receive no notification in WordPress that there is a security vulnerability in the plugin or even that it has been removed the Plugin Directory. There also isn’t any indication on the WordPress Plugin Directory that the plugin was removed, instead when you go to the page where the plugin used to exist you are just told “Whoops! We couldn’t find that plugin. Maybe you were looking for one of these? ” (you can currently see an example of this with the WP CSS page).
It’s not clear why no information is provided, it seems hard to believe the people who are handling plugin security issues at WordPress would not be concerned what happens to websites who already have the plugins installed. If the idea is that hiding the issue would provide the websites with the plugins installed some protection it doesn’t make much sense and isn’t working. In many cases the vulnerabilities have been publicly released, as is the case with WP CSS. For potential attackers it is easy to find the information, but people running WordPress websites are much less likely to be looking at those things. It’s then not surprising that we are seeing attempts to exploit removed plugins. In the month of February the following 14 removed plugins were attempted to be exploited on our website:
- 1 Flash Gallery (1-flash-gallery)
- Category List Portfolio Page (category-list-portfolio-page)
- Disclosure Policy Plugin (disclosure-policy-plugin)
- DP Thumbnail (dp-thumbnail)
- IP Logger (ip-logger)
- is_human() (is-human)
- jQuery Slider for Featured Content (jquery-slider-for-featured-content)
- Kish Guest Posting (kish-guest-posting)
- LISL Last-Image Slider (lisl-last-image-slider)
- Really Easy Slider (really-easy-slider)
- Rent-A-Car-Plugin (rent-a-car)
- VK Gallery (vk-gallery)
- WordPress News Ticker (wordpress-news-ticker-plugin)
- WP Marketplace (wp-marketplace)
You would only need to have one of those plugins installed to have your website successfully hacked. In all of those attempts, it looks like the attempts were part of a general attempt to exploit as many websites as possible. It appears that many removed plugins contain vulnerabilities that wouldn’t be useful for this type of mass attack, but would be useful for a targeted attack on a website so the issue plugins with known vulnerabilities should be a major concern for websites that are likely to targeted for attack.
An Interim Solution
Instead of just complaining about this we have come up with an interim solution for the issue by creating a plugin that reports any installed plugins that have been removed from the WordPress.org Plugin Directory. All you have to do is to install the plugin and go the plugin’s page to see if there are any installed plugins that have been removed from the directory.
One obvious and reasonable question is to ask is why our plugin warns about all removed plugins instead of just the ones with security vulnerabilities. The biggest reason for doing it this way is that because WordPress doesn’t release information on why plugins were removed we don’t which ones were removed security issues. We could just limit our warning to plugins that have publicly released vulnerabilities, but that leaves the possibilities that we miss some or many more plugins. The other issues is that plugins that have been removed for other reasons are unlikely to be fixed if a security vulnerability is found after it has been removed, for some plugins it appears that this has been the case.
A limitation of the plugin is that it will only warn about plugins that have been removed as of the last time we updated the plugin list in the plugin. Our current plan is to update the full list once a month.
We are looking at the possibility of integrating information on the security vulnerabilities in removed plugins into the plugin, so that admins can make more informed decision about what to do if there are removed plugins installed in their WordPress installation.
If WordPress does make changes to Installed Plugins page to warn of removed plugins, then it would also be good to also provide the option of showing the relevant changelog entries as well so that admin are aware of when security issues have been fixed in plugins. Some plugins already have similar functionality built into them. That functionality is also available with the Changelogger plugin.
If you are looking to increase the security of your WordPress installation and you perform software updates in WordPress you should take a look at out our plugin for performing update processes using HTTPS.
Ars Technica has been running a series of articles about the recent hack of several US Federal Trade Commission websites hosted at Media Temple. The latest reporting indicates that “critical vulnerability in some versions of Parallels’ Plesk Panel control panel software appears to have been key to the recent penetration”. A patch for the vulnerability was released in September, though the article mentions that Parallels didn’t send email alerting customers to the critical nature of the vulnerability until February. Media Temple’s failure to keep Plesk up to date goes back years and we unsuccessfully tried to get them to address the issue back in July of 2010.
Media Temple and Parallels are both part of the Hosting Security Forum, which is supposed to “share critical security information in order to protect the integrity of a customer’s data, their web presence, and online availability”. That organization’s website is running an outdated version of WordPress, 3.2.1, which might be a good indication as to the group’s level of dedication to security. Media Temple, as well as Dreamhost and other members of that organization, is also running outdated software on their website.
Warning Media Temple
Back in July 2010, during a period of hacks that were targeting Media Temple customers (but that Media Temple claimed was not due to their security failings), Media Temple made some long needed security improvements and asked for people to contact them if they were missing any security measures.
While cleaning up a hacked website running on their Dedicated-Virtual service we noticed that Media Temple was using a nearly two year old version of Plesk, which also meant that the other software that comes with Plesk was also two years old. We contacted Media Temple alert them to the need to keep that and other software running on their systems up to date and at the time we hoped that they would quickly resolve the issue as they were publicly claiming to want to improve their security.
Media Temple’s response was that there hadn’t been a known vulnerability in Plesk since 2007 and therefore they were secure. We don’t why they felt they didn’t need to keep their up to date just because there had not been known vulnerabilities, but in any case it wasn’t the whole truth. While the version of Plesk didn’t have any known vulnerabilities other software that came with that version of Plesk did have known vulnerabilities. We specifically brought to their attention there were apparently security issues in at least the versions of ProFTPd, Ruby, and phpMyAdmin that came with it. We never received any response after we brought that up. Overall, their response seemed to be more focused on creating the impression that they cared about security then about actually making sure they and their customers were secure.
During the email exchange they claimed they had recently put in place a policy that “requires us to patch any software with security flaws within 30 days of a patch being made available. For the most critical issues, such as a kernel exploit, we will patch immediately. ” We certainly would describe the vulnerability in Plesk as being a critical issue, but for some reason they didn’t feel the need to apply the patch immediately or even in the 30 day window.
Blame the Customer
When the issue of the hack was first surfacing Media Temple was quick to blame their customer for the hack and criticize them for running outdated software. While it’s true that many hacks are due to issues which the customer is responsible for and many of those are due to outdated software, it is irresponsible to claim that it was the customer’s fault without actual evidence to support that, especially to do that publicly. For Media Temple’s to do this is worse as during our email exchange they excused not keeping Plesk up to date on there not being known vulnerabilities, so they certainly should understand that just running outdated software doesn’t mean that it is vulnerable. To be criticizing a customer for running outdated when they don’t keep the software they are responsible for up to date makes the response appalling.
Unfortunately, Media Temple’s response to this incident isn’t out of line with the usual response that customer’ with hacking issues receive when contacting their web host about a hacking issue.
Media Temple Runs Outdated Web Software
Based on the rest of Media Temple’s actions it isn’t surprising that they fail to keep software running on their website up to date (while criticizing others for doing the same).
Their blog is running WordPress 3.3. The latest version, 3.3.1, was release nearly two months ago and included a “fix for a cross-site scripting vulnerability that affected version 3.3“.
The Media Temple Community Wiki is running a version of MediaWiki, 1.16.x, that hasn’t been supported for nearly three months. They also failed to apply the last three updates, all of which included security fixes, for 1.16.x. The oldest update they failed to apply, 1.16.3, was release over ten months ago.
We don’t believe, as others do, that web host’s have a responsibility to clean up their customer’s website if it’s are hacked, unless it was caused by something on the host’s end. They do have responsibility to properly handle the security of their own systems, which as of just a few weeks ago Dreamhost didn’t do in a basic way. We also think they have a responsibility to not be giving bad security advice to their customers or the public at large, as Dreamhost does. It does a serious disservice to their customers, including the potential that customer’s hacked websites could remain vulnerable to being re-hacked because of their bad advice. The bad security advice, which certainly isn’t limited to web hosts, also makes it harder for people that deal with security issues, and take security seriously, to do their job. We have to spend to much time explaining to clients that the information they are seeing and being told is in most cases wrong. What makes Dreamhost worth focusing on is that in addition to the bad advice they give, they don’t bother following the good advice they give others.
In this post will focus mostly on comments they made in a recent post on their blog and some communication between them and one of their customers, whose website we recently cleaned.
From the blog post:
Based on the sites we have cleaned up already, these attacks have almost universally been due to insecure website software running on the site in question. You could have the best passwords in the world, but if the apps you’ve installed on your server have any security vulnerabilities or aren’t kept up to date, attackers can still find their way in.
Based on the websites we clean up and other data we collect the claim that attacks are “almost universally been due to insecure website software running on the site in question” is completely false. Vulnerabilities in web software are one of the top two things, but the other, compromised FTP credentials, has nothing to do with the software running on the website. From what we see, which one of issues is the biggest changes from time to time. For example, we might see a spike in web software attacks after a new vulnerability is discovered. There are other things that are lesser but not insignificant causes of attacks, like security vulnerabilities at web hosts.
What could explain the discrepancy between what we and Dreamhost see? It could be that they have systems in place that are effective at preventing other types of hacks. It could be that they only look for certain types of hacks, so they only find what they are looking for. Or it could be that don’t actual bother looking at the cause of attacks at all.
Determining if Outdated Web Software is the Cause of a Hack
Recently we were cleaning up a hacked website hosted at Dreamhost. From reviewing the information we had available it didn’t look the hack came through a security vulnerability in web software. Unfortunately, we couldn’t review the necessary logs to be able to determine how the hack occurred because of poor log retention at Dreamhost.
To determine if the website was hacked due to a vulnerability in web software, we would have reviewed the log of HTTP activity. That show all the requests made to the website, so it would show any exploit of software running on the website. Unfortunately, those are only stored for a very short time at Dreamhost. If Dreamhost actually wanted to determine that websites were in fact being hacked by vulnerabilities in web software they would also need to look at that as well. Except for cases where the hack is found immediately, how could they make a strong determination that the hack was due to a vulnerability in web software? The answer seems to be they don’t even try, as will get to in a little bit.
The other thing we wanted to look at was the log of FTP activity. If this is available for the time period of the hack it is easy to see whether the hack came through FTP by reviewing the log. Our client was told that the logs are only stored for two weeks and because the hack occurred before then the log wasn’t helpful. The short retention of the FTP log also means that Dreamhost couldn’t check if the hack came through FTP if it occurred more than two weeks before, which would limit their ability to know that hacks are not coming through FTP as they seem to think is the case. This also makes another claim in the post seem questionable. In regards to a recent hack of Dreamhost they stated that “An extensive investigation has revealed that no customer FTP or SSH user accounts have been maliciously accessed due to this password breach.” If you don’t keep logs longer than two weeks how could you claim to do an extensive investigation, as you can’t look at data older than two weeks once you discovered the issue?
While we couldn’t make a strong determination on the source of the hack, Dreamhost didn’t have a problem doing that. They said:
Also, “hacks” usually occur due to outdated web software, and since you’re running joomla, it’s safe to say, the hack occurred there.
There hasn’t been the kind of vulnerability in Joomla that has led to the software being hacked in a long time. That isn’t to say that something couldn’t be found, but if somebody is telling you that a hack likely occurred from that or that Joomla is not secure then they don’t know what they are talking about. From the hacked websites that we see that are running Joomla, the issues that lead to hacks are vulnerable extensions, compromised FTP credentials, a hack of the hosting provider, and recently we have had a number of clients hit by a dictionary attack campaign that is targeting Joomla websites. It clearly isn’t safe to say the hack occurred because they were running Joomla, as Dreamhost, unless they have done a thorough investigation and found evidence to back that up.
Let’s say you did believe that the cause of a hack was due to a Joomla vulnerability, there would be more work to do after that. You would need to determine if the vulnerability has been fixed in Joomla before you tell somebody “simply reinstall your software, and make sure you’re always keeping it up to date”, as Dreamhost did, because doing that would have no impact if the vulnerability hasn’t been fixed in Joomla.
If the hack is on a website was running the latest version of Joomla it would mean that the vulnerability hasn’t been fixed or more likely that it wasn’t a vulnerability in Joomla.
For a website running an older version you would need to compare what information you had about the hack to the vulnerabilities that have been fixed in subsequent versions to see if the probable vulnerability has been fixed. For example, there was recently fixed vulnerability that could make it easier for some to guess a user’s password after causing it to be reset. To check for that you would ask the client if the password stopped working recently, which would have happened if it was reset. If the logs were available, you could also check those for additional information. If you don’t find a corresponding vulnerability it would mean that the vulnerability hasn’t been fixed or more likely that it wasn’t a vulnerability in Joomla that caused the hack.
Dreamhost didn’t inquire into what version of Joomla was running when the website was hacked or doing anything else, that is another good indication that don’t know what they are doing or they just don’t care. If this customer interaction is any indication of how they handle this type of situation for other customers, it doesn’t appear they do any checking at all and instead just assume a hack must have been caused by software on the website.
Failure to Warn About Vulnerable Software
When it comes to dealing with outdated web software that is actually vulnerable to being exploited, and has been exploited, Dreamhost fails their customers. Dreamhost has tool that scans a customer’s files to find the web software in the account and warn if it is out of date. As of a couple days ago it was listing OpenX 2.8.7 as being “Up-to-date.”, despite the fact that OpenX 2.8.8 was released back in November. OpenX 2.8.7 isn’t just out of date, it contains a serious security vulnerability that was being exploited even before version 2.8.8 was released. You have wonder how they wouldn’t be aware of this if they were actually determining how websites were being hacked or just keeping track of security issues in web software.
Dreamhost Runs Outdated Web Software
In another post by the same author they recommended “upgrading website software as soon as there is an update available”, which is actually good advice. It just isn’t advice that Dreamhost follows.
If you visit the Dreamhost blog with our Meta Generator Version Check extension (available for Firefox and Chrome) you would get an alert the blog is running an outdated version of WordPress, 3.2.1. That version is not that far out of date, it’s only one major version out of date and two months out of date. (Also, contrary to recent claims by Websense there are not known vulnerabilities in 3.2.1.) But considering that Dreamhost is telling people how important it is to keep software up to date and they don’t do it themselves then it seems like Dreamhost either does not care about the security of their website or they don’t believe what they are saying.
What make this more ridiculous is that the person that wrote both of those posts, who is described as Dreamhost’s Web Application and Security administrator, will be giving a talk titled “Security 101″ at a WordPress event. Should you be telling other people about WordPress security if you don’t even bother to take the basic step of keeping WordPress up to date?
It’s not just that blog that is running outdated software, the Dreamhost Wiki is running an outdated version of MediaWiki, 1.16.5. Support ended for that major release, 1.16.x, two and half months ago. Like the WordPress installation that is not far out of date, but for whatever reason Dreamhost doesn’t feel it is important to keep the software running on their website up to date.
Since we discussed that Websense’s claims of a vulnerability in WordPress 3.2.1 were baseless they have updated to their post to basically admit that the infections had nothing to do with WordPress. What is more curious about the update is that they now claim that they actually originally suspected a vulnerability in WordPress plugins not WordPress 3.2.1 was leading to the infections. This doesn’t match up with the previous claims or the press coverage the claims received. The new claim does seem to be a poor attempt to explain away their previous false claims, but if they actually believed that the infections were due to plugin vulnerabilities then the advice they gave webmaster on how protect themselves would have continued to leave the vulnerable websites open to being exploited.
Let’s take a look at some key sections of the post’s update.
Not All Running WordPress 3.2.1
After obtaining access to logs and PHP files from compromised Web servers, further analysis indicates that most of the compromised Web sites were running older versions of WordPress, but they were not all running 3.2.1.
This doesn’t make much sense. The logs and PHP files related to the infection would give only basic information, if any, on what software the website is running. If you wanted to know what they were running you could get more information by looking at the websites.
As we mentioned in the previously there appears to be a serious problem with how Websense identified infected websites that lead them to only find websites running WordPress 3.2.1 to be infected. This would also bias the selection of logs and PHP files they reviewed and would have led them to continue have an over-weighted sample of websites running WordPress and WordPress 3.2.1 in their sample.
Source of the Infections
The attackers’ exact point of entry is uncertain.
Now that we have access to data from several compromised Web servers, the logs show us that, in some cases, the point of entry was compromised FTP credentials. In several instances, once attackers had access, they scanned WordPress directories and injected specific files (e.g., index.php and wp-blog-header.php) with malicious PHP code.
Somehow the point entry is unknown, but they also our say that they found the entry point in at least some cases was through compromised FTP credentials. They don’t make many mention of finding any other entry point. If the websites were infected through compromised FTP credentials, which seems fairly likely possibility, that means the infection has nothing to do with WordPress. In what seems to be an attempt to try give the impression of a link between the infection and WordPress they mentioned the attackers scanned WordPress directories and infected a WordPress specific file. We know that the infection has infected websites not running WordPress so they attacker would have scanned the directories whether they were related to WordPress or not. index.php is a generic file that exists in any websites programmed in PHP, so that specific file would be a target no matter what PHP based software is running. Why bring up WordPress other than to try to make it still seem like this is something strongly related to WordPress when it pretty clearly is general issue that would have impacted websites running any software?
Suspected Plugin Vulnerabilities?
At first, we suspected vulnerable WordPress plugins, because a subset of analyzed sites were running vulnerable versions of the same WordPress plugins.
This claim that they originally believed that websites were exploited due to vulnerable WordPress plugins just doesn’t line up with the originally posting at all. The most relevant portion of the original post:
You don’t get much clearer than that. If they believed that this was a plugin issue then it wouldn’t have mattered what version of WordPress was running as the vulnerability would exploitable as long as you are running plugin. You could be running WordPress 3.3.1, WordPress 3.2.1, or any other version and it would make any difference only if you had the plugin installed. Yet the original post repeatedly mentioned WordPress 3.2.1 and never mentioned plugins at all. The title of the post is “3-2-1 WordPress vulnerability leads to possible new exploit kit “, the list of traits for the infection mentions WordPress 3.2.1, there is a section of the post titled “What To Do If You Are Running WordPress 3.2.1″.
The attacks are taking advantage of website owners who are hosting an older — and vulnerable — version of WordPress, 3.2.1, which was updated in December but is still widely in use.
The reason for bringing up plugins now, seems to be because we pointed out the claimed vulnerabilities they cited as WordPress 3.2.1 were in fact vulnerabilities in plugins. We previously mentioned how it looks like those plugins vulnerabilities got confused to be WordPress 3.2.1 vulnerabilities (try this search).
If they believed that it was plugins then those plugin exploits they cited don’t make sense. When we looked some of the websites they listed in their sample of infected websites, none of them were running those plugins. The type of vulnerability, a blind SQL injection, which was claimed in those plugins, isn’t something that would be likely to be used in this type of hack.
For the sake argument let’s say that they actually believed the vulnerability was due to WordPress plugins. The way to protect websites from this would be for the vulnerability in the plugins to be fixed or for the plugins to be removed. Which did Websense suggest be done? Neither, remember they never even mentioned plugins in the post. Instead their advice was:
If you have been infected, be sure to upgrade WordPress while simultaneously removing the injected code so that your Web pages aren’t simply being reinfected after being cleaned.
Upgrading WordPress would have no impact on the vulnerability in plugins, they would have been just as vulnerable as before. Even if you assume they meant that the plugins should be upgraded along with WordPress, it wouldn’t have done anything as plugins they were citing did not have updates available to fix the vulnerabilities. (We will be discussing this in more detail soon, but it is worth mentioning here that both of these plugins have been removed from the WordPress.org Plugin Directory, one of the reasons plugins get removed is for security issues that have not been fixed. You can use our new WordPress plugin, No Longer in Directory, which checks if installed plugins have been removed from the WordPress.org Plugin Directory to warn about such situations.) So why would Websense have wanted the websites to remain vulnerable? We certainly can’t think of a reason why they would want to do that. The reasonable explanation for this is that the advice was based on their belief that there was a vulnerability WordPress 3.2.1, not in plugins as they came up with later to try cover for their false claims, and upgrading WordPress would have fixed the vulnerability.