When we clean up a hacked website removing the hack is usually the easy part of the work, most of the time spent and needed expertise is used to determine how the website is hacked. Without doing this you leave the website vulnerable to being hacked and in some cases you leave many others vulnerable to also being hacked. Many companies that clean up hacked websites don’t do this or do it very poorly. In other cases people will just blame something without do any work to check if that actually was the cause, we recently discussed how Dreamhost does that.
In the past few weeks there have been ongoing series of hack on Dreamhost hosted websites. The characteristics of this particular hack are a directory named .logs created in the root of the website, a base64 encoded block of code added to PHP files, and the website sometimes redirecting to a .rr.nu domain name. When we went into clean up the first website with this hack the information we had indicated that it was likely due to a security vulnerability with Dreamhost. This would make it hard to determine the source of the hack as Dreamhost would be the only one with all of the necessary information to do that and web hosts have a history of not taking possibility of security issues in their systems seriously.
With the Dreamhost hack we almost immediately identified what appeared to be the source of the hack, but we needed a small but critical piece of information from Dreamhost to confirm the source. For two weeks Dreamhost has been stonewalling their customer’s requests for this information. Yesterday, Dreamhost posted something that, while showing they don’t understand the proper security of shared hosting and blaming their customers for that failure, confirmed that what we had suspected was correct. If Dreamhost had acted professionally and responded promptly to their customers in this situation this could have been resolved two weeks ago and many more websites would not been hacked. Even now Dreamhost is leaving most of their customers vulnerable to their security weakness; you can fix that for your account and please make sure to warn other Dreamhost customers to do so as well.
Whose File Is That?
Once we gain access to a hacked website’s files we do a thorough review of them using a number tools and methods. In this situation we almost immediately identified a file that seemed to be the root of the hack in the website and more importantly we noticed that the file was not owned by the client’s Dreamhost account. This file was not detected by the security scan run by Dreamhost on the website before we got to it (their scans also have a bad record of rather blatant false positives).
Our first thought was that the file’s owner might be different because it was created by software running on the website. In some setups those files are owned by a different user. We checked files that we knew were created by software on the website and they were owned by user’s account, so that was ruled out. This also meant that the file had not gotten there by a hacker exploiting a vulnerability in software on the website.
The next step was for our client to contact Dreamhost and find out who the file belonged to. The user could have been another user on the server, another Dreamhost user, or something belonging to software running on the server. We also asked them to see if Dreamhost would tell them how the file got there, but based on Dreamhost’s track record we assumed they would be unlikely to be able answer that. That client and subsequent clients have been contacting Dreamhost and asking them who the file belongs to in their accounts and so far Dreamhost has refused to give them any answer, despite sometimes repeated requests. Based on the timeline, it would appear that our information could have been being used by Dreamhost though.
Based on the usernames we were seeing we suspected that the other user was likely to be another Dreamhost user, probably on the same shared server, but we needed Dreamhost to confirm this to know for sure. We can’t think of any reason they wouldn’t tell their customers whose files it is, when it is showing up in their account. If Dreamhost had just given this basic information this issue could have been fixed then instead of this continuing on.
That is Not Enhanced User Security
How could one user add files to another user’s account? One possibility is that there was a vulnerability in some software on the server that allowed it to happen. Another possibility is that Dreamhost doesn’t properly handle permissions on their servers. In a shared hosting setup users should never be able to access other user’s files or directories no matter the permission the user sets on those files and directories. Web hosts that improperly handled permissions in the past have led to major hacks, so a web host has no excuse for not knowing that this needs to be done and they would be grossly negligent if they were not doing it. We have long warned that a web host needs to handle permissions properly to keep websites secure from likely hacks.
While looking for something else we found that Dreamhost has a feature they call Enhanced User Security.
The documentation for the feature says that when enabled:
- The user and his scripts have the same access to the home directory as when the option is disabled.
- Other users on the same account have limited access to your home directory (as other Dreamhost users do when Enhanced User Security is disabled, above).
- Other Dreamhost users no longer have any access to your home directory. They cannot enter your home directory or subdirectories or access any files, no matter how lax the permissions are set. Note: The Apache user is in the group ‘adm’, and thus still has access to the home directory.
The documentation for the feature says that when disabled:
- The user has full read/write access to his own home directory, as do user scripts (such as PHP) which run as the user, by using suEXEC.
- Other users on the same account also have full read/write access to the home directory, except that they may not rename, delete or create files or directories. However, they may perform these actions in sub-directories that have group +w permission (e.g. rwxrwx–x or 771).
- Other Dreamhost users have some limited access to your home directory. They may not read the list of filenames in the home directory, and may not rename, delete or create files or directories. However, they can read any other file or directory listing which is accessible to the web server, assuming they know the path and filename or can guess. They may also read, and possibly write or modify, any file or directory which has too lax permissions set (e.g. 755 or 777).
They can call that Enhanced User Security if they want, but what that features really provides is the basic level of security a web host should be providing. If this was enabled by default, as the documentation claims, then it would only be a concern if somebody were to accidentally disable the feature. Unfortunately, the claim that the feature is enabled by default is mostly false. The history of the documentation shows that the documentation was changed to claim that the feature is enabled by default on March 1, 2012. In the accounts we checked the feature was not enabled by default and the blog post says it ” is now on by default for all new users”. It unconscionable that Dreamhost would leave their existing customers vulnerable to this. Dreamhost should immediately enable feature this in all the accounts.
With Dreamhost’s improper permission handling hackers that had access to one account on a Dreamhost server could gain access to any account that had a directory with more permissive permissions that they could find on that server. We have seen indications that hackers have had access to Dreamhost accounts that could, in hindsight, have been due to this issue for some time. What appears to have happened now is that hacker(s) have become more aggressive in exploiting this or found a way to more easily identify more directories that were vulnerable due to Dreamhost’s negligence. It could be that additional information was gathered by them during the recent, acknowledged, hack of Dreamhost’s systems.
Enabling “Enhanced User Security”
To enable Enhanced User Security log in into your Dreamhost account, click the “Manage Users” link in the left hand menu, click the “Edit” link next to the account, on the next page check the “Enhanced security?” box and finally click the “Save Changes” button.
Dreamhost Doesn’t Care About Security
Just based on what has happened in this case we would say that it is pretty clear that Dreamhost doesn’t care about security and you should avoid them, but Dreamhost has a track record of ignoring glaring security issues. It was only after another recent hack of their systems, which exposed their user information, that they appear to have finally taken the step of hashing passwords despite being warned about that for years. They have also shown that they ignore the security advice they give to others when it comes to their own website. By continuing to use their service you are not only continue to put your website at risk, but you are supporting a company that puts many others at risk as well.
We also have to question why WordPress continues to list Dreamhost as a recommend web host. At least in the past, they emphasized the web host’s responsibility when it comes to permissions:
A properly configured web server will not allow users to access the files of another user, regardless of file permissions. The web server is the responsibility of the hosting provider. The methods for doing this (suexec, et al) have been around for 5+ years.