Forgot your password?
typodupeerror
Security The Internet

Dreamhost FTP/Shell Password Database Breached 123

Posted by Soulskill
from the another-day-another-intrusion dept.
New submitter Ccmods writes "Below is a snippet from an email Dreamhost sent to subscribers early Saturday morning, describing an intrusion into the database storing FTP and SSH usernames and passwords: 'We are writing to let you know that there may have been illegal and unauthorized access to some of your passwords at DreamHost today. Our security systems detected the potential breach this morning and we immediately took the defensive precaution of expiring and resetting all FTP/shell access passwords for all DreamHost customers and their users. ... Only the FTP/shell access passwords appear to have been compromised by the illegal access. Web panel passwords, email passwords and billing information for DreamHost customers were not affected or accessed.'"
This discussion has been archived. No new comments can be posted.

Dreamhost FTP/Shell Password Database Breached

Comments Filter:
  • Not a big deal (Score:5, Informative)

    by slimjim8094 (941042) <slashdot3@justconnected . n et> on Saturday January 21, 2012 @06:04PM (#38776719)

    As a Dreamhost customer, I watched this unfold in real time. Apparently the passwords were hashed, and there's no indication that they were compromised, other than the fact that it was technically possible. So they changed the passwords because it's cheaper, PR-wise, than being wrong.

    There's a big warning up on the panel, which has a password stored in a different, non-compromised DB. Between the panel and the email, I doubt anybody's confused as to what's going on.

    In other words, it's really not that big of a deal. The database shouldn't have been compromised, and I'll expect a full postmortem of how they screwed that up, but in terms of damage (or even inconvenience), there really isn't any to speak of.

    • Re: (Score:3, Insightful)

      by ZackZero (1271592)
      After spending time reading the misplaced anger and blatant misunderstanding of the method of password storage over on DreamHostStatus, it's good to see some rationality being injected somewhere.
      • by Anonymous Coward on Saturday January 21, 2012 @07:16PM (#38777195)

        it's good to see some rationality being injected somewhere.

        You mean as opposed to SQL being injected somewhere, of course.

    • As a Dreamhost customer, I watched this unfold in real time. Apparently the passwords were hashed, and there's no indication that they were compromised, other than the fact that it was technically possible. So they changed the passwords because it's cheaper, PR-wise, than being wrong.

      There's a big warning up on the panel, which has a password stored in a different, non-compromised DB. Between the panel and the email, I doubt anybody's confused as to what's going on.

      In other words, it's really not that big of a deal. The database shouldn't have been compromised, and I'll expect a full postmortem of how they screwed that up, but in terms of damage (or even inconvenience), there really isn't any to speak of.

      It's good to see they took the matter seriously, even with the circumstances you describe. Bad that it happened in the first place, but it sounds like the situation was nicely handled.

    • by Anonymous Coward

      >Apparently the passwords were hashed.

      If you choose the "forgot my password" option for the dreamhost webpanel it automatically emails you your current password in plain text form (not a new password or a way to reset).

      Given that webpanel password is stored in platintext by dreamhost I have little confidence that ftp passwords have stronger protection.

      • by ZackZero (1271592)
        The only offered method for dealing with a forgotten ftp/shell password is to force a reset through the panel, either by having one generated on request or by providing one yourself. It is displayed only once after that point, in the panel, as a confirmation.
      • Re:Not a big deal (Score:4, Informative)

        by LordLimecat (1103839) on Saturday January 21, 2012 @07:31PM (#38777265)

        Just because you can get it emailed to you does not mean that it is stored plaintext.

        • by metrix007 (200091)
          It means they are stored in a less than ideally secure way. If a script can retrieve the password, so can an attacker.
          • That is probably true in this case, but is not necessarily true in all cases. Imagine, for example, that the password is encrypted with the email address as its key, and the email address is hashed. Upon login, a hash lookup is done for the email address, and the encrypted password is decrypted and compared to the one sent. Or alternatively, the password is stored both encrypted as mentioned, and hashed, so that logins are done by 2 hash checks.

            Either scenario would allow the user to retrieve the passwor

            • by fluffy99 (870997)

              That is probably true in this case, but is not necessarily true in all cases. Imagine, for example, that the password is encrypted with the email address as its key, and the email address is hashed. Upon login, a hash lookup is done for the email address, and the encrypted password is decrypted and compared to the one sent. Or alternatively, the password is stored both encrypted as mentioned, and hashed, so that logins are done by 2 hash checks.

              Either scenario would allow the user to retrieve the password without the host or an attacker being able to see what the associated email or password is.

              I'm pretty sure the hosting provider would require an unencrypted/unhashed copy of your email address.

              • No, they would not. This is simple. They store only the email hash. Your account id is tied to that hash. Upon login, you are required to provide your email address and password; the email is used to try to decrypt the password, and is then hashed and compared to their stored hash. If the provided password matches the decrypted password, and the hashed email matches the stored hash, you get logged in.

                For password recovery, all you provide is the email, which is again used to perform a hash lookup, and

                • by fluffy99 (870997)

                  I understood the concept. Just pointing out that they need to have your contact info somewhere which would naturally include your email address

                  • Email address could be stored in a cookie upon login. The site would indeed be unable to send you unsolicited email, but would be able to email you upon login or password reset.

            • by metrix007 (200091)
              For that to work any records of email address would have to protected. Not really a practical solution.
            • by dkf (304284)

              That is probably true in this case, but is not necessarily true in all cases. Imagine, for example, that the password is encrypted with the email address as its key, and the email address is hashed. Upon login, a hash lookup is done for the email address, and the encrypted password is decrypted and compared to the one sent. Or alternatively, the password is stored both encrypted as mentioned, and hashed, so that logins are done by 2 hash checks.

              Store the password hashed in the "production" database, and keep an encrypted copy in a separate database hosted on a service that is responsible for sending out emails relating to password reminders (or resets). All the frontend services can do are to validate that a supplied password matches (through hashing) or request a reminder or reset for a particular user; nothing else should be possible since the encrypted version is kept out of reach.

              Not that I expect anything so sensible in this case. SQL injecti

              • by xous (1009057)

                Why store the password in a retrievable fashion?

                Sending the actual password to the end-user via email in clear-text is stupid. The end-user will likely go "ohh, right" and keep using it. Much better to send them a random one-time use password or a link that allows them to reset the password once.

        • If they can email you the plain text then they are not hashed.

    • by Anonymous Coward

      This has been a problem for at least 3 months, any dreamhost user can upload a php based rootkit and download the password database.

      I'm speaking from experience in removing rootkits from dreamhost hosted wordpress sites.

      • by dgatwood (11270)

        Uh... what do WordPress user databases have to do with shell account user databases?

        • by Anonymous Coward

          Not a wordpress database. Upload a rootkit to DH, and you can read any file on the system as if you were root. It has nothing to do with wordpress other than that being the mechanism by which the rootkit was dropped into DH's servers. The rootkit runs with the privileges of the web server, not the user. You can read all the files in /etc

    • Re:Not a big deal (Score:5, Insightful)

      by sortius_nod (1080919) on Saturday January 21, 2012 @06:37PM (#38776925) Homepage

      I actually think it's a big deal, but not for the reason most people are crying about.

      It's a bit deal that they have been open, honest, & cautious about the intrusion. Having seen so many high profile companies take the opposite stance lately, the DH intrusion should be made a big deal of, if anything, to show other companies how you react to being hacked without losing face with customers.

      For me, there is only one chance when it comes to security to get it right. If you try to hide intrusions, lie to customers, or stonewall tech sites trying to get more information, you aren't a company to be trusted with my data.

      • Re: (Score:2, Informative)

        by Anonymous Coward

        Let me second that. I got the email, checked into my dreamhost account, used the excuse to call my sister (and will have a conversation with someone else). and then I was done with the *protective* aspect. Actually, the protection happened right away because dreamhost locked the possibly-compromised accounts immediately, as I understand it. The *recovery* aspect, then, just took a few minutes, and involved an enjoyable family chat.

        I don't think of dreamhost as "less secure" than I thought it was.

        • by tqk (413719)

          Had I found out months later, that hackers had compromised dreamhost, and that dreamhost had kept it quiet, I would have been an unhappy customer. As it is, I'm a happy one.

          I'm happy for all the DH customers that this's turned out to be little more than "HEADS UP", and it appears DH went out of their way to handle the damage correctly. Great! Bravo!

          However, as an IT guy interested in system security, I *hate* that this happened in the first place, and seems to happen far too often regularly. Why is FTP still being used, and why don't you guys know how powerful a shell account can be in the hands of a master (or a gifted amateur, for that matter)?

          This !@#$ shouldn't happen.

          • Re: (Score:3, Informative)

            by etresoft (698962)
            Alas, Dreamhost markets to the public at large, who often have no idea anything other than FTP exists. Dreamhost also provides sftp, ssh, WebDAV, and secure e-mail.
          • FTP is still a useful protocol because:

            1.) few people upload sensitive data to a web hosting service.
            2.) it requires less CPU overhead.
            3.) FTP transfers, while better with a client like Filezilla/Cyberduck/xFTP, don't *require* a client since both Windows and OSX support it natively.

            • by Solandri (704621)

              FTP is still a useful protocol because:

              1.) few people upload sensitive data to a web hosting service.

              The problem with FTP isn't that it transmits data as cleartext (though it does that too). The problem is it transmits passwords as cleartext. Anyone snooping on your FTP session will know your username and password.

            • by xous (1009057)

              1. User names and passwords are sensitive.
              2. CPU is cheap.
              3. Time to force end users to use a real ftp client and/or have MS or Apple implement a modern protocol.

          • by Tanktalus (794810)
            "Shell account" is why I'm with DH. I upload everything using rsync-over-ssh. It's not like those other options aren't there.
            • by tqk (413719)

              "Shell account" is why I'm with DH. I upload everything using rsync-over-ssh. It's not like those other options aren't there.

              Yeah, but stuff that was determined more than a decade ago to be inherently insecure should not be supported and ought to be turned off. Make the users happy, sure, but try to keep them from shooting themselves too, yes?

              DH customer: "Why can't I get to my ftp login?!?"
              DH Tech Support: "Because we can't know whether your box is infected with a keylogger trojan (or worse) or if your network connection's being sniffed. Please use the much more secure ssh & etc. You'll prefer it once you get to know it,

      • by dbIII (701233) on Saturday January 21, 2012 @09:58PM (#38777997)
        Here's an example of somebody getting it badly wrong but little press about it.
        A few weeks ago Telstra Bigpond, one of Australia's largest ISPs, was caught out with the utterly stupid situation of having their customer list of username, plain text password, email address and mailing address out there naked on the internet. Outsourced workers in call centres needed the information but some idiot decided instead of them having to log in somewhere to get access that they should simply be able to use a URL with the customers username on the end of it. The site with the passwords was still up ten hours after it hit the mainstream news.
        Now that's the sort of thing I expect when I see something like the article summary above, but instead it's the opposite - full disclosure early instead of being caught out by the press and not plain text passwords.
    • Re: (Score:2, Interesting)

      by Anonymous Coward

      It's a bit less trust-inspiring than you represent it.

      Brian H. from Dreamhost initially posted on the Dreamhoststatus page that FTP/SSH passwords are only stored hashed. Later he deleted that statement. Why?

      Web panel passwords are definitely stored in a retrievable way, because when you forget your web panel password they mail it to you. Not a nonce key that allows you to set a new password, they mail you the actual password. According to Dreamhost CEO Simon Anderson [dreamhost.com], they're now evaluating if they could

    • by jafo (11982)

      Well, it *IS* a big deal, but only for people who are using the same password on dreamhost and other services. Obviously, people shouldn't do that, for reasons that are now obvious, but people do. Whoever got this password list is likely to start looking at facebook and other sites for accounts with similar names and use any passwords they can crack from this database.

      The compromise is sometimes not the obvious one... For example, I had an account on a service that was recently compromised, and that acco

    • by fluffy99 (870997)

      Except that they found a symptom, and not the actual problem. Someone has unauthorized access to their servers. Until they figure out how they've gotten in and closed the door, it's pointless to scramble passwords. This also wasn't a "quick response" as people have been complaining about their accounts getting hacked and their WP configus and .htaccess files getting modified for months.

    • by Mike (1172)

      Well, my sister's company uses Dreamhost, and they were hacked. They do use ftp (instead of sftp) to upload their files, so I'm guessing that's the likely culprit. I've since set them straight.

      I've been a loyal Dreamhost cusomter since 1998 and I'm happy with their response.

    • As a dreamhost customer (who doesn't store anything overly sensitive there), I've noticed that they also have a tendency to send me mail with my real password in the past, which indicates that it's stored somewhere in cleartext (which is BAD).

    • by spong (32007)

      Apparently the passwords were hashed [...]

      I'm not sure that's quite true across the board. According to a blog comment here [dreamhost.com] by Simon Anderson (dreamhost CEO):

      Zachary:- some more detail - our systems have stored and used encrypted passwords for a number of years, however the hacker found a legacy pool of unencrypted FTP/shell passwords in a database table that we had not previously deleted. We've now confirmed that there are no more legacy unencrypted passwords in our systems. And we're investigating furthe

    • by t4ng* (1092951)

      In other words, it's really not that big of a deal. The database shouldn't have been compromised, and I'll expect a full postmortem of how they screwed that up, but in terms of damage (or even inconvenience), there really isn't any to speak of.

      I run dozens of web sites on DreamHost with almost as many shell accounts associated with them. Going through all those account and assigning new passwords to them, then reconfiguring my development tools with the new passwords is a major undertaking. I think that qualifies as an inconvenience (especially since the password change sync seems to be taking much longer than usual right now).

      However, given what had happened, I wouldn't have it any other way. I'm glad they recognized the problem and responded

  • FTP? (Score:5, Insightful)

    by MichaelSmith (789609) on Saturday January 21, 2012 @06:06PM (#38776741) Homepage Journal

    If the passwords are used for FTP they should be considered comprimised anyway.

    • by Wayne247 (183933)

      Very valid comment, this deserves to be modded up. Since FTP authenticates in cleartext, anyone capable of sniffing the transaction gets the authentication credentials in full.

      That's why it's never, ever safe to attach FTP credentials to anything else.

      I believe Dreamhost handles this by issuing a separate password for FTP.

      • I believe Dreamhost handles this by issuing a separate password for FTP.

        They should handle it by only supporting SFTP.

        • by sakdoctor (1087155) on Saturday January 21, 2012 @06:45PM (#38776995) Homepage

          I'll see your SFTP and raise you disabling password authentication entirely, and using SSH public key authentication only.

          If your SSH server is visible over the Internet, you should use public key authentication instead of passwords if at all possible. If you don't think it's important, try logging all of the malicious login attempts you get for the next week.

          -- https://help.ubuntu.com/community/SSH/OpenSSH/Keys [ubuntu.com]

          • by MichaelSmith (789609) on Saturday January 21, 2012 @07:05PM (#38777129) Homepage Journal

            I'll see your SFTP and raise you disabling password authentication entirely, and using SSH public key authentication only.

            I do this on my own servers but I don't use plain file transfer at all. Instead I use a distributed version control system (mercurial) and I push to the server. Mercurial lets me define a hook to update the remote copy to the repository tip when new changesets are pushed to it. Working this way I have a full version history at the local and remote end. Additionally I only have to manage the directory tree locally. The remote end is taken care of.

            Another advantage is that mercurial hashes the whole repository so if anybody does fiddle with any files, I hear about it as soon as I touch the repository.

          • I do this myself, but unfortunately I can't convince my university division's so-called "UNIX admin" to disable remote root logins, let alone password authentication, on our machines. In spite of this it's somehow a "security risk" to run our (computer science) lab's web applications on port 80.
          • Your suggestion is actually even worse. A passphrase or password of some kind shows that there is a human being that should be allowed in instead of whoever just happens to possess something with that key.
            I think you've misunderstood some good advice of using BOTH a key AND a password/passphrase. The quote you've used has left out the point that typically when you generate a key it also prompts you for a password/passphrase. Passwordless keys are useful within internal networks but are a very bad idea fo
            • Nobody implied that you shouldn't encrypt your private key with a strong passphrase.

              This setup is absolutely perfect for laptops, because it's two-factor authentication. The thief will need both the key from the laptop and the passphrase.

              • Nobody implied that you shouldn't encrypt your private key with a strong passphrase.

                Apart from some guy under the handle of "sakdoctor"?

                disabling password authentication entirely, and using SSH public key authentication only

                It's not a "reading comprehension" thing if you state the opposite of what you now say you intended.
                My point stands - as written it's very bad advice to do it all with keys and no password authentication with the keys.
                What the fuck do you expect readers to think you mean by "disabling pa

            • People who store keys on their disks SHOULD be taught to use full-disk-encryption, specially in case of laptops.

          • by antdude (79039)

            Can sftp and scp do resume downloads and uploads yet?

            • by xous (1009057)

              Use rsync over ssh.

              • by antdude (79039)

                Ah cool, so it can resume upload and download? I will check it out later. Currently, I use old school sz and rz through SecureCRT and PuTTY's zmodem hack/mod.

        • by Grishnakh (216268)

          That'd be nice, but for some reason it still seems to be the standard to support FTP for web hosts. My host, fatcow,com, does so as well. Why, I don't know; I'm guessing it's probably because a bunch of people use shitty website-authoring tools that don't support SFTP. I wouldn't be surprised if MS FrontPage is the big reason; my host supports FP and FP extensions, even though last time I checked, FP is defunct and unsupported, and has been replaced by some other MS tool with a totally different name. B

          • Horrifying. Still, it would be easy to use SSH forwarding to keep using an FTP-only client, but I guess the people who know that use rsync.
            • by Grishnakh (216268)

              rsync only works if the hosting service supports it, IIRC. My hosting provider, fatcow.com (owned by Tucows I believe), does not seem to support it from everything I could find in their help pages, only FTP and SFTP. rsync would be much better because it's really fast and works really well, but I guess most hosting account customers are clueless about it, probably mostly being Windows users using some sort of commercial web authoring software, and rsync being mostly a Unix-only tool it seems. I ended up

        • by Solandri (704621)
          They support FTP and/or SFTP. As much as I like the idea of forcing everyone to use SFTP, it's really a decision for each customer to make. If you want to only allow SFTP connections, you can.
      • by awilden (110846)
        I'm pretty sure it's the same password for both. Inside the control panel there's a popup to assign each user "ftp", "sftp+ftp", or "shell+sftp+ftp" access. But if you choose either of the latter two, you have "disallow ftp" checkbox. Fairly bassackwards in my opinion, but does let you block ftp into your account - one user at a time.
      • by trip23 (727132)
        For what it's worth, there's FTPS and FTPES. So you can secure FTP-Conntections since quite a time.
  • by Dynamoo (527749) on Saturday January 21, 2012 @06:15PM (#38776787) Homepage
    This has been going on since last June [dynamoo.com]. Dreamhost were completely unresponsive to reports that their services were being abused. Hey, it only took 'em half a year to figure out there was a breach..

    It got so bad at one point that I recommended that readers of my blog . [dynamoo.com]

    • by Dynamoo (527749)
      ..darn it, I screwed up the formatting. I recommended [dynamoo.com] that people consider blocking the Dreamhost IP ranges altogether.
    • by Maestro4k (707634) on Saturday January 21, 2012 @08:53PM (#38777665) Journal

      This has been going on since last June [dynamoo.com]. Dreamhost were completely unresponsive to reports that their services were being abused. Hey, it only took 'em half a year to figure out there was a breach..

      Probably because that has all the hallmarks of a software PHP vulnerability web-hack of a site, NOT an FTP compromise. I've seen plenty of those, they use some vulnerability to gain access, then upload a file (through the web software) that gives them what's basically a PHP web-based shell. There's no need for the FTP account password to be compromised (and it usually isn't).

      All web hosting companies get a lot of that type of attack because their customers don't all update and/or secure their sites properly. WordPress is a particularly popular target.

  • by Anonymous Coward

    Were these passwords hashed?

    If not, sweet mercy, Dreamhost, what could you possibly have been thinking?

    If so, sweet mercy, Slashdot, could you be troubled to include this little detail in the summary?

  • As a long time Dreamhost customer, I have never encountered an incident like this before. However, I think it was a good decision to reset the passwords as it was a painless process both for them and for their users. In any case, I'm bracing myself for any aftershock.
    • by dgatwood (11270)

      I'm not sure what the password for my account was before, and I'm really not sure what it is now. I use an SSL key for authentication anyway, so this doesn't matter much....

      What would be really cool would be if DreamHost allowed you to inject an SSL public key into the account for login purposes, and stopped having a password database entirely. Just my $0.02.

    • I disagree that the process is entirely painless. As a developer and reseller, my account has several dozen different sFTP users set up. Each of them required a password change. Easy? Absolutely. Frustrating? A little, but I'm really glad DreamHost chose to play it safe. Painless? Not really, since the process took over an hour and involved me emailing my users to let them know why they couldn't log in with their old user/pass combinations. In all, I prefer having to spend an hour or two changing passwords
      • by radcore (2558169)
        If you're reselling to several dozen users, then that would be a different story. I could be totally wrong about the nature of reselling through Dreamhost, but why did you have to individually change their passwords? I was assuming you could've just sent an email blast to your users providing some "explanation."
  • A copy of the script shown at http://www.nk.ca/blog/index.php?/archives/1275-Phishing-spam-mail-script-intercepted.html [www.nk.ca] was sitting at the root of my domain. Pretty sure it's a remailer.
  • If I had to guess, the conversation at Dreamhost probably went something along the lines of:

    "The passwords are hashed though, right?"

    "Yes."

    "So they can't reverse the passwords out of it?"

    "Virutally impossible."

    "Is there any advantage they gain from having the hashed passwords?"

    "Well, it would allow them to brute force their guesses against it without fear of being slowed down or blocked."

    "But wouldn't they need to know our salting algorithm for that to be useful?"

    "Um..."

    "Let's go
  • It could just be me and that it is late at night here, but why on Earth would you want to keep a database of SSH and FTP passwords, hashed or not?
    • by etresoft (698962)
      The massive web hosting companies don't run vanilla Linux. The require custom setups to run hundreds or thousands of sites per server and the flexibility to change servers based on usage.
  • As the Unix does since ... 1969?
    Seriously, WTF?!

      - Hubert

    • by sl3xd (111641)

      Why do you just assume the passwords are cleartext? Do you not understand that even hashed or crypted passwords are easy things to crack?

      There are numerous programs specifically designed to crack passwords. They start with the obvious things (dictionary), then adds in misspellings, moves on to simple substitutions (1=l, 4=a, @=a), and finally to more difficult things, like multiple words+substitutions. Many crackers combine clustering with GPUs, which makes for highly effective cracking.

      They are terrifyingl

  • Dreamhost seems to have a surprisingly participatory workplace, runs on a free software stack, and has an environmentally-friendly setup. I've set up many sites with them and have tried all the other big hosts, and I now recommend only Dreamhost to friends/family/coworkers.

    Their support is very responsive, and the occasional technical hiccups with hosting packages are handled quickly and professionally. Although this break-in is a bit scary, it seems like they're playing "better safe than sorry" by res
  • by Anonymous Coward

    At least in the past they sent me my web panel password when I asked them to.
    How else can they send the password back?

  • by jthomp (1266534)
    What sucks about this is I set up a DH account the day before this happened x.x
  • Simon Anderson Says:
    January 21st, 2012 at 11:55 am

    some more detail – our systems have stored and used encrypted passwords for a number of years, however the hacker found a legacy pool of unencrypted FTP/shell passwords in a database table that we had not previously deleted. We’ve now confirmed that there are no more legacy unencrypted passwords in our systems. And we’re investigating further measures to ensure security of passwords including when a customer requests their password by email (this was not the issue here, though). Re your shell accounts, I’d suggest that you select a new password just to be sure.

    Search for "January 21st, 2012 at 11:55 am" at this link [dreamhost.com]

    Also, due to the number of customers changing their passwords, the password sync time is very slow right now. More info here. [dreamhoststatus.com]

Do not simplify the design of a program if a way can be found to make it complex and wonderful.

Working...