Using Insecure WordPress Plugins?Does your WordPress blog contain known insecure plugins? Check Now
Search This Blog
- Is Your Web Host Keeping PHP Up to Date?
- StopTheHacker: A Website Security Company That Doesn’t Care About Security
- FEMA Website Running Outdated and Insecure Version of Drupal
- OWASP Website Running Outdated and Insecure Version of MediaWiki
- White House Website Running Outdated and Insecure Version of Drupal
Web Software Updates
WordPress VersionWe are running WordPress 3.5.1 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
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.
Last week TrustWave’s SpiderLabs claimed that there were multiple vulnerabilities in WordPress 3.3.1 and below. Their report was also discussed in a post on threatpost. Unlike the Websense and M86 Security Labs reports of a vulnerability in WordPress 3.2.1 that were based on false information, these claims are based on factual information but the issues are presented in a way that we consider to be misleading.
What should have been made very clear by TrustWave and threatpost is that the possible security issues only exist if you have placed the WordPress files on your website but have not run the install script. If you are currently running WordPress this is not an issue in your installation.
If for some reason you have an extra copy of WordPress on the website that has never been used and someone could determine where that it is then this could be an issue. You should remove that copy, as you should with any software on your website that is not being used
Here are the findings made in TrustWave’s SpiderLabs’ report and some possible mitigations for the issues raised:
The WordPress ‘setup-config.php’ installation page allows users to install WordPress in local or remote MySQL databases. This typically requires a user to have valid MySQL credentials to complete. However, a malicious user can host their own MySQL database server and can successfully complete the WordPress installation without having valid credentials on the target system.
It is not uncommon for WordPress to be setup with a remote database server, so removing or restricting the ability to do that would not seem to be advisable.
One possible mitigation for this vulnerability be to require the person using the install script to add or modify a file on the website to confirm that they have control of the website before proceeding through it. A similar mitigation would be to require the database credentials be entered into a file on the website instead of through the web installer. Either of those would make the installation process more complicated for users without providing any security benefit for anyone that promptly runs the install script after putting the WordPress files on a website.
The WordPress ‘setup-config.php’ installation page allows users to install WordPress in local or remote MySQL databases. When using this installation page the user is asked to supply the database name, the server the database resides on, and a valid MySQL username and password.
Malicious users can omit the “dbname” parameter during this process, allowing them to continually bruteforce MySQL instance usernames and passwords. This includes any local or remote MySQL instances which are accessible to the target web server. This can also be used as a method to proxy MySQL bruteforce attacks against other MySQL instances outside of the target organization.
What this is saying is that if the WordPress files are on a website and the install script has not been run someone could use install script to make login attempts on a local or remote database server.
In addition to the mitigations mentioned for Finding 1, it would be possible to place limits on the number of attempts to log in into database servers with the installer. That would add complication to the installation process without providing any security benefit for anyone that promptly runs the install script after putting the WordPress files on the website.
The WordPress ‘setup-config.php’ installation page allows users to install WordPress in local or remote MySQL databases. When using this installation page the user is asked to supply the database name, the server that the database resides on, and a valid MySQL username and password.
WordPress responded to the report by stating that “We give priority to a better user experience at the install process. It is unlikely a user would go to the trouble of installing a copy of WordPress and then not finishing the setup process more-or-less immediately. The window of opportunity for exploiting such a vulnerability is very small.”
We largely agree with WordPress’ view. We would further say that trying to make this a WordPress issue seems inappropriate as the most serious claim is related to having a user friendly web based install script, which is common among web software, rather than something specific to WordPress. If TrustWave’s SpiderLabs believes this is a serious issue they should have raised it instead of trying to make this into an issue with WordPress.
On Friday DreamHost reset all of their customers “FTP/shell access passwords” after they had unauthorized activity within one of their databases, the situation is discussed in blog posts on DreamHost Status blog and the The Official DreamHost Blog!. Since then there have been questions and confusion as to whether DreamHost only stores passwords in their hashed form. While we have no way of knowing if the database they detected unauthorized activity stored non-hashed password there is no question that they store non-hashed passwords in their systems. It’s fairly easy to see that DreamHost is doing this and we will show you how you can check this for yourselves at the end of the post.
The fact that they stored passwords in a non-hashed form has been discussed for many years and DreamHost has so far has decided that insuring that they were follow proper security practices by only storing password hashes wasn’t necessary for whatever reason. It’s then not all to surprising that they had this most recent security incident and the other apparent security incidents they have had over the years. For some time we have listed DreamHost in our list of web hosting providers with security issues due to them storing non-hashed passwords.
One possible reason for some of the confusion from DreamHost is that they don’t understand the difference between encryption and hashing, in which case it they probably shouldn’t be handling the security of a website, much less that of a major web host.
While discussing DreamHost’s security it is also worth bringing up the fact that both of those blogs are running an outdated version of WordPress, 3.2.1. They are also are running an outdated and now unsupported release of MediaWiki, 1.16.5, on a portion of their website (so are a number of the websites of web software). In a message that was forwarded to us while we were cleaning up a hacked website for client recently, DreamHost had told them that they should make sure to keep web software running on their website up to date. Obviously DreamHost don’t feel it is important to follow the advice they give to their customers. If you want to see when websites are running out of date version versions of WordPress, MediaWiki, and other software check out our Meta Generator Version Check web browser extension for Firefox and Chrome.
Considering DreamHost’s questionable security practices we would recommend that people avoid using their services until they have fixed these lapses in their security. We also don’t think that WordPress should be recommending them or describing them to be one of the hosts that “represent some of the best and brightest of the hosting world”.
What is Hashing?
You can think of hashing as one way encryption. To produce a hash you run a hash function on a specified value, in this situation it would be the value being set as a password. For example, using the MD5 hashing function the hash for the password value “password” would be “5f4dcc3b5aa765d61d8327deb882cf99”.
Unlike encryption, hashes are not meant to be decryptable and ideally you wouldn’t be able to determine what the password value was if you gained access to its hash. This is why it is important to store passwords as hashes. If they are stored them in a non-hashed way someone that gains access to them could easily use the passwords to log into your account, which has happened previously after web host’s were exploited, or if you use the same password on different systems they could potentially gain access to those as well. There are a number of ways to determine the underlying value of passwords hashes, so systems using hashing for passwords need to insure they follow best practices including making sure they use salts.
So how does a system know that the correct password was entered during a login attempt if they only have the hash? The answer is that when the login attempt is made the password you enter is run through the same hash function and then compared with the stored hash of the password. If the two are they same the login attempt will succeed. If you entered the wrong password the hashes would be different and it would fail.
If passwords are only stored in hashed form there will be no way for a provider to retrieve the password from storage that for you. The only instances where they could show you the password would be when they are generating a new password for you or if they show you the password in response to you entering it.
The most common place to see that passwords are being stored in non-hashed form is on pages for handling a situation where you forgot your password. If they can show or send you the password it means the password in being stored non-hashed in their systems. With web hosts we also sometimes see that passwords are visible somewhere in the control panel for the websites.
Spotting Non-Hashed Password Storage at DreamHost
If the password were only stored in the hashed form they wouldn’t be able to email you your password because they wouldn’t know what it was.
When the makers of web software talk about security they always emphasize the importance of keeping software updated. One of the developers of WordPress said it this way “The only thing that I can promise will keep your blog secure today and in the future is upgrading.” Keeping software updated is good advice, but isn’t advice that the software makers, including WordPress, always follow themselves.
We recently mentioned a pretty egregious example of this from OpenX. Their blog, where they recently said it is critical to keep software up to date, is running a version of WordPress that is over three years out of date. Also, the main portion of their website appears to be running a version of Drupal that is over a year out of date.
MediaWiki, the software the powers the Wikipedia, is run on portions of many web software websites so we decided that it would be a good choice to see if software makers are keeping other people’s software running on their website up to date. There are several ways to check what version of MediaWiki is running and the easiest way to check for outdated MediaWiki installations is to use our Meta Generator Version Check web browser extension, available for Firefox and Chrome. The extension will show a warning icon when a web page has a meta generator tag from an outdated version of web software.
For those not familiar with MediaWiki they currently provide security updates for the two most recent releases 1.17.x and 1.18.x. The most recent version of those releases 1.17.2 and 1.18.1, both of which were released on January 11. We update our web browser extension a month after a new version is released, so until then it will check for MediaiWiki versions below 1.17.1.
Before mentioning the websites running outdated versions it is worth noting that one website we checked was actually up to date. TYPO3′s TYPO3Wiki is running 1.18.1.
The WordPress Codex is the most out of date as it is running 1.15.5, which is two supported releases out of date. Support for 1.15.x ended in December of 2010.
The Zen Cart Wiki is one supported release out of date and running a version, 1.16.2, that that is three minor updates out of date. Support for 1.16.x ended in late November of last year.
Joomla! Documentation is one supported release out of date and running a version, 1.16.4, that that is one minor update out of date.
The phpBB Development Wiki is at least running the most recent version of 1.16.x, 1.16.5, but that release is no longer supported.
MoodleDocs is at least running a supported release, 1.17.x, but the version, 1.17.0, is two minor updates out of date.
We finally have an opportunity to discuss our first two security bug bounty payouts for WordPress plugins, both for relatively minor issues. We actually paid them out in late October but we were waiting until after one them was finally fixed (the other was fixed within hours of the developer being notified) to write about the issue.
XSS vulnerabilities are not as big an issue as vulnerabilities that allow adding arbitrary code to a database or into a file. Because these two vulnerabilities are only accessible in the admin area, it limits there severity even more. If they were to be used by an attacker they would be used in a attack to target at an individual website instead of a mass attack. Most attacks on WordPress based websites are mass attacks.
A fix for NextGEN gallery was included in version 1.8.4 and a fix for WP e-Commerce was included in version 188.8.131.52.
Web Browser Based Reflective XSS Protection
We found that both Chrome 15 and Safari 5, whose protection come the WebKit rendering engine they share, were able to successfully block the attempted XSS.
We found that Internet Explorer 9 only blocked the attempt XSS if you were already logged into WordPress when attempting to access the malicious page. If you were not logged in you would be asked to login and then be taken to the malicious page where the XSS was not blocked. This is due to Internet Explorer disabling the protection for requests originating from the same website. This is one of a number of weaknesses in Internet Explorer’s protection discussed in the paper Bypassing Internet Explorer’s XSS Filter (PDF).
Firefox doesn’t currently provide any similar functionality, but with the NoScript add-on installed we found the attempted XSS was blocked.
Keep in mind that the web browser protections are not full proof and it is possible that XSS attacks could be crafted that can evade the protections.
Testing Security Plugins Against These Vulnerabilities
Now that updates for both plugins have been released the way to prevent these vulnerabilities is to make sure you are running the latest version, which should make sure to with any installed plugins, but what about similar vulnerabilities that developer are not yet aware of? The biggest protection that you have is that targeted attacks are rather uncommon, so you are unlikely to be exposed to this type of issue. Then protection comes from being careful when clicking on links and using a web browser that provides protections against this type of hack.
For this test, we tested plugins that did not require signing up for any service. We tested the following plugins:
For all four plugins we found that provided no protection. This is rather disappointing as this is just the type of thing they might be useful for. Most times when WordPress based websites are successfully attacked it is due to outdated software, which keeping software updated would have prevented, or it is due to a hacker gaining access to the underlying files that make up WordPress. In a case where the hacker has access to the underlying files the plugins cannot prevent access to the files (making files un-writeable is generally not effective as the hacker generally has the ability to make the writeable again) and the hacker could remove or modify the plugins. They could even modify the software to report that the website is still secure (You probably won’t find much security software of this type warning about this serious weakness, though it doesn’t appear that many hackers bother doing that as the software isn’t popular enough to be worth the time it would take to do that.).
Last Thursday OpenX released version 2.8.8 of their software. They have yet to make any sort of public announcement of the update on their blog or anywhere else that we could find. The only information given, found on the Product Updates page in the OpenX admin interface, says that:
It is highly recommended to install this update as soon as possible, because it contains a number of security fixes. The version of OpenX which you are currently using might be vulnerable to certain attacks and is probably not secure.
With a release that includes important security fixes, as this seems to be, you would expect that they would want to make sure people that use their software would be well aware of the update.
There was no information was given as to what the vulnerabilities were or what other changes were made in the new version. This is a continuing practice from OpenX as we have written about before. While it is understandable that developers would want to limit the amount of information to make it harder to for people to be able to exploit the vulnerabilities, hackers have shown that they are able to hack OpenX without this information and the information would be useful for people not looking to hack OpenX. To repeat what we said after the last OpenX release, “[w]ithout knowing what the issue or issues that were fixed makes it hard to determine the source of a hacking, potentially leading to new vulnerabilities that are exploited in OpenX going undiagnosed in the future if the OpenX installation hacked was running an out of date version.” It also makes it hard for anyone to independently verify the vulnerabilities were fully and properly fixed in the newer version.
The larger concern we have now is that OpenX seems to continue to be releasing security fixes in response to vulnerabilities being actively exploited, commonly referred to as zero-day exploits, instead them being found beforehand during development or during subsequent security reviews. We know that with past vulnerabilities they were being exploited before updates were released. We have seen some reporting that vulnerabilities in the last version were being exploited (with the most specific report we were not able to replicate the vulnerability, but that could be because of using a different server configuration) before this version was released. This at least means that users keeping the software up to date are not safe from being hacked, which they generally are with most web software that have a good track record of finding and fixing vulnerabilities in their software before they can be exploited. It also could be an indication that OpenX is not as concerned about the security of the software as they need to be for something that is so widely deployed.
What makes there apparent lack of concern towards the security of their software more troubling is the way they used the update message for 2.8.8 as a chance to promote their hosted solutions. This is the message that followed the warning about the need to update:
OpenX also provides both free and Enterprise hosted versions of the ad server, offering significant improvements in both infrastructure and functionality. Both of these products are managed and operated by the OpenX team, including upgrades, maintenance, and security scans, freeing you and your team from handling such issues. If ad serving is mission-critical to your business, we suggest contacting our team to learn more about OpenX Enterprise. As always, please let us know of any potential security problems by emailing email@example.com.
All the hacks of OpenX we have dealt with so far have been due to security vulnerabilities in the OpenX software and not due directly to something related to self-hosting. In many of those cases OpenX had released a update before they were hacked, so automatic upgrades provided by their hosted solutions would have helped. But unless OpenX is providing their hosted customers with a more secure version of OpenX, then the hosted customers remain as vulnerable before the fixes for the security vulnerabilities are released. The quality of their security scans should be in question as well, if vulnerabilities keep getting found and exploited before they are fixed by OpenX.
Update (November 14, 2011):
Another thing that should be noted when considering how OpenX views the importance of security is the fact that their blog is still running WordPress 2.6.2. One of the most basic and important security measure anyone running a website should be doing is making sure they keep any software running on the website up to date. The version they are currently running is now over three years out of date. Since version 2.6.2 there have been 16 releases that include security fixes that they have missed (and 26 overall releases).
We are always looking for ways how we can help to improve the security of the web. One of the basic security measures that needs to be taken to keep websites secure is keeping the software running on them up to date, as newer releases often contain security fixes and enhancements.
The developers of web software have done a lot to make that easier by providing messages in the software that the websites is in need of update and making the update process easier. Even with this there is still many website running outdated versions of that software.
When we are in touch with people running websites whether they are potential clients, people we are contacting to let them know their website has been hacked, or for some other reasons, we make sure to let them know if we see they are running outdated software that needs to be updated. We only reach a limited number of people so to increase awareness that outdated software is running on websites we have created a new web browser extension, named Meta Generator Version Check, to make it easier for others to see when there is outdated software running a website.
With the web browser extension installed, each time a web page finishes loading the extension checks the web page’s source code for a meta generator tag. The one for the current version of WordPress looks like:
<meta name="generator" content="WordPress 3.2.1" />
After reading that, the extension then provides a warning if it detects one of the following software is running on the website:
- WordPress versions prior to 3.2.1
- Joomla 1.0 and Joomla 1.6
- Mediawiki versions 1.16.4-1.13 (earlier versions do not contain a meta generator tag)
- vBulletin versions prior to 3.8.7
- TYPO3 versions prior to 4.3
- Movable Type versions prior to 4.37, 5.06, and 5.12
- Melody versions prior to 1.0.2
Looking at that list you might notice that there is a fair amount of software missing. The limitation of checking the meta generator is that not all software produces one and some of those that do, do not provide a tag that allows us to identify what version is running. In other cases only partial version information is given. For Joomla, this means the extension can warn about websites running Joomla 1.0 and 1.6, which are no longer supported, but for Joomla 1.5 and Joomla 1.7 there is no indication if they are running the current version of those, as of yesterday they were 1.5.24 and 1.7.2, or an older version.
Another issue we have found as we looked to add checks for more software is that the supported versions of software are not always easy to find. We would recommend that software developers make sure that they prominently display what versions of their software are supported so that people looking for that information can easily find it.
If you see that we are missing a check for software that provides the required information in the meta generator tag please let us know so that we can include that in the extension.
While it would be possible to have the extension do a more intensive check to determine what version of software is running on website, using information not available in the meta generator tag, this would in most cases require requesting additional files when each page is loaded and would provide information that is not being made available by the web page itself.
We currently plan to update the extension to warn that software is outdated a month after a subsequent version has been released or support has ended for a version. For severe security vulnerabilities the extension may e updated sooner provide an earlier warning.
The main use for the extension is to be alerted that websites that you are visiting are running outdated software so that you can let them know that they need to update it or if they are your client you can do the update yourself.
It also could be useful in looking at who you considering doing business with or what software you might use on your website.
If a web host isn’t keeping software on the frontend of their website updated, it is reasonable to be concerned that they might not be taking proper security measures for their hosting clients as well. After checking just a few web hosts we found that both Just Host (3.0.3) and IX Web Hosting (3.1) were running outdated version of WordPress. It is also interesting to note that homepage of IX Web Hosting’s website has security seals from both McAfee Secure and something called Ecommerce HackerShield (which appears to something created IX Web Hosting’s parent company) claiming the website is secure despite the outdated software, with known security vulnerabilities, running on a sub-domain of the website and linked directly from the homepage.
For software, an example of something that might be concerning that we just noticed with a piece of software that we run on our website, Piwik, is that their website is still running WordPress 3.0.4.
A version of the extension is now available for Chrome. A version for Firefox is currently pending a review from Mozilla. The Firefox version has some limitations in comparison to the Chrome version due to current limitations of the Mozilla Add-On SDK, as the Add-on SDK is further developed those limitations will also go away. A version for Safari will not be released until Apple modernizes their enrollment process for Safari Extension development.
You can also find a web-based version of the tool here.
Is Running Outdated Software Always a Security Concern?
Outdated software is not automatically less secure than a newer version, it would only be more insecure if it contains a security vulnerability that does not exist in a newer version. Often new releases include fixes for security vulnerabilities or security enhancements. There is also a possibility that changes have been made in a newer version that removed a security vulnerability that was not known to be security vulnerability at the time. To be safe it is a good rule to update the software even if the developers have not warned of vulnerabilities in prior versions. To keep things simple we have decided that the extension will warn if outdated version is running instead providing a warning only when we know an old version contains a security vulnerability.
Is Including a Meta Generator a Security Concern?
With software that includes a meta generator tag there are often people claiming that it makes websites less secure, this is especially true when it comes to WordPress. We previously discussed the issue in detail in regards to WordPress. The summary of that is as follows: The bad guys are not generally checking the meta generator tag and they usually don’t even check if you are running the software they are trying to exploit. On a daily basic there are attempts to exploit software that is not and has never been on our website. Because the bad guys attempting to exploit vulnerabilities do not bother to check what version of software you are running the website, you will get hacked if you are running a version with that vulnerability even if you managed to completely hide the version running. Finally, if someone wanted to find out what version you are running they could do that even if you remove the meta generator tag.
With our new extension we think it makes even more sense to include a meta generator tag as it increases the usefulness of the tag by letting people inform others they have outdated software running on their website that needs to be updated.