Slashdot Mirror

← Back to Stories (view on slashdot.org)

Dreamhost FTP/Shell Password Database Breached

Posted by Soulskill on 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.'"

29 of 123 comments (clear)

  1. Not a big deal by slimjim8094 · · Score: 5, Informative

    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.

    --
    I have developed a truly marvelous proof of this comment, which this signature is too narrow to contain.
    1. Re:Not a big deal by ZackZero · · Score: 3, Insightful

      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.

    2. Re:Not a big deal by kelemvor4 · · Score: 2

      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.

    3. Re:Not a big deal by sortius_nod · · Score: 4, Insightful

      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.

    4. Re:Not a big deal by Anonymous Coward · · Score: 2, Interesting

      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, they're now evaluating if they could change this practice.

      Anderson also said that FTP/SSH passwords are stored "encrypted". He didn't say "one-way hashed" or "salted and hashed", he said "encrypted". So it could be a reversible encryption with the master password retrievable from somewhere else. Anderson doesn't reply to requests to specify what "encrypted" means.

      “however the hacker found a legacy pool of unencrypted FTP/shell passwords in a database table that we had not previously deleted.”

      So they had stored passwords in plaintext in the past and forgotten about it.

      Allegedly, email passwords were not compromised, but they recommend changing them just to be sure. Actually an intruder with a FTP password could just FTP into the user's home directories and with a pretty good chance retrieve SQL and email passwords from config files and logs of any webapp that uses a database/email. Most webapps store those in plaintext. Dreamhost doesn't say if they checked which user files where accessed in the vulnerable time span. SQL connections are restricted to Dreamhost servers, but an SQL password gives you web access to databases over phpmyadmin.

      There are several requests in the web panel's Suggestions section to stop sending passwords to customers or displaying them in the web panel. Dreamhost has been ignoring those requests for years.

    5. Re:Not a big deal by jafo · · Score: 2

      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 account had a special e-mail address associated with it that was whitelisted. The password on that account was a strong password, and wasn't shared with another service, but it didn't take long before I started getting all sorts of spam to my inbox that used that e-mail address to get around my anti-spam filters...

    6. Re:Not a big deal by Anonymous Coward · · Score: 3, Interesting

      >Where? I've been a DH customer for 5 years...

      The "forgot my password" link on the webpanel login page (discovered today by virtue of needing to log in to set user passwords again).

      You are right that for users within your webpanel account there is no email reset option - you log into the webpannel to set these passwords.
      But the webpanel account itself - passwords are emailed in plaintext.

    7. Re:Not a big deal by Anonymous Coward · · Score: 5, Funny

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

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

    8. Re:Not a big deal by Anonymous Coward · · Score: 2, Informative

      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. I think of it as *more* secure than I thought it was. Before, I assumed they followed good practices. Now I have more reason to think so.

      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.

      Nice work, dreamhost!

    9. Re:Not a big deal by LordLimecat · · Score: 3, Informative

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

    10. Re:Not a big deal by ZackZero · · Score: 4, Funny

      Of course, since rationality hasn't historically been deliverable by SQL injection :P

    11. Re:Not a big deal by etresoft · · Score: 3, Informative

      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.

    12. Re:Not a big deal by etresoft · · Score: 3, Insightful

      Like many Dreamhost customers, I have used many other hosts over the years. None has even come close to Dreamhost. Many companies try to project an aura of professionalism but are really mickey mouse operations on the inside. Dreamhost is the opposite. I think they make a point to act like clowns only to scare off the clueless, high-maintenance market.

    13. Re:Not a big deal by JWSmythe · · Score: 2

          Well, several years ago, before they moved their servers, I was in the same datacenter with them. My cage was almost next to theirs. On several occasions, I talked to them. All of their folks knew their stuff, and showed me around the inner workings a good bit. I was impressed. I highly recommended them at the time. Unless someone made some horrible decisions, I strongly suspect they're still worth the praise.

          Now, what happened? Hell if I know. I'm on the other side of the country now, and we don't talk. Was it that someone snagged the shadow file, or a hashed password list? Was it that someone brute forced several passwords? Either way, they did the right thing, and changed all the passwords that were potentially compromised.

          Sure, there's a risk of finding hashed passwords via rainbow tables. Someone could brute force the passwords on their home machine (otherwise, someone would notice a script taking 100% of the CPU time). And, if users can pick their own passwords, there's always a huge risk of weak passwords. I've known so many people that use dictionary words, or dictionary words followed by one or two digits. And of course, I follow that up by lecturing them on strong passwords, and password security. So they may pick a strong password that time. They'll probably go back to using weak passwords for other things.

         

      --
      Serious? Seriousness is well above my pay grade.
    14. Re:Not a big deal by Solandri · · Score: 2

      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.

    15. Re:Not a big deal by makomk · · Score: 2

      We're suffering a DDoS... no... wait... we don't know how to fix our Cisco equipment... is not something you want to see ever.

      I think off-hand - though I don't deal with Cisco kit - that is indeed a failure mode that shouldn't happen ever.

  2. FTP? by MichaelSmith · · Score: 5, Insightful

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

    --
    http://michaelsmith.id.au
    1. Re:FTP? by reve_etrange · · Score: 2

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

      They should handle it by only supporting SFTP.

      --
      .: Semper Absurda :.
    2. Re:FTP? by awilden · · Score: 2

      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.

    3. Re:FTP? by trip23 · · Score: 2

      For what it's worth, there's FTPS and FTPES. So you can secure FTP-Conntections since quite a time.

  3. Only since last June.. by Dynamoo · · Score: 2, Interesting
    This has been going on since last June. 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 .

    --
    Never email donotemail@WeAreSpammers.com
    1. Re:Only since last June.. by Dynamoo · · Score: 2

      ..darn it, I screwed up the formatting. I recommended that people consider blocking the Dreamhost IP ranges altogether.

      --
      Never email donotemail@WeAreSpammers.com
    2. Re:Only since last June.. by Maestro4k · · Score: 3, Informative

      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.

  4. Re:Painless by chimericdream · · Score: 2

    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 and contacting people to discovering that my site (or that of one of my clients) has been hacked.

  5. Found a planted perl script by dem0n1 · · Score: 2

    A copy of the script shown at http://www.nk.ca/blog/index.php?/archives/1275-Phishing-spam-mail-script-intercepted.html was sitting at the root of my domain. Pretty sure it's a remailer.

    --
    Why save your soul when you can sell it for a profit?
  6. I'll see your SFTP and raise you... by sakdoctor · · Score: 4, Insightful

    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

    1. Re:I'll see your SFTP and raise you... by MichaelSmith · · Score: 3, Informative

      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.

      --
      http://michaelsmith.id.au
  7. Re:-1 hysterical by icebraining · · Score: 2

    Those passwords aren't stored in a database, but in the shadow file.

    Not necessarily. SSH can validate the passwords using PAM, and PAM can use a database (e.g. Postgres or LDAP) as backend.

    --
    Dilbert RSS feed
  8. Meanwhile under the radar by dbIII · · Score: 3

    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.