Dreamhost FTP/Shell Password Database Breached

← Back to Stories (view on slashdot.org)

Dreamhost FTP/Shell Password Database Breached

Posted by Soulskill on Saturday January 21, 2012 @09:59AM 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.'"

94 of 123 comments (clear)

Min score:

Reason:

Sort:

Not a big deal by slimjim8094 · 2012-01-21 10:04 · 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 · 2012-01-21 10:10 · 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 · 2012-01-21 10:16 · 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 Anonymous Coward · 2012-01-21 10:20 · Score: 1
  
  >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.
4. Re:Not a big deal by ZackZero · 2012-01-21 10:22 · Score: 1
  
  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.
5. Re:Not a big deal by Anonymous Coward · 2012-01-21 10:33 · Score: 1
  
  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.
6. Re:Not a big deal by sortius_nod · 2012-01-21 10:37 · 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.
7. Re:Not a big deal by Anonymous Coward · 2012-01-21 10:41 · 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.
8. Re:Not a big deal by Literaphile · 2012-01-21 10:42 · Score: 1
  
  Where? I've been a DH customer for 5 years and I've never been able to recover a password, only reset it. You can see the password when you first set it (i.e. it just confirms that you've chosen XYZ as your password), but after that you can only reset it, which would lead to the conclusion that it's hashed.
9. Re:Not a big deal by jafo · 2012-01-21 10:47 · 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...
10. Re:Not a big deal by Anonymous Coward · 2012-01-21 10:48 · 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.
11. Re:Not a big deal by dgatwood · 2012-01-21 11:01 · Score: 1
  
  Uh... what do WordPress user databases have to do with shell account user databases?
  
  --
  Check out my sci-fi/humor trilogy at PatriotsBooks.
12. Re:Not a big deal by slimjim8094 · 2012-01-21 11:08 · Score: 1
  
  Yes, it does. Those are stored in plain text anyways, at least the mysql ones (your config files). The passwords in question are for shell/FTP accounts, as the title says.
  
  --
  I have developed a truly marvelous proof of this comment, which this signature is too narrow to contain.
13. Re:Not a big deal by Anonymous Coward · 2012-01-21 11:16 · Score: 5, Funny
  
  it's good to see some rationality being injected somewhere.
  You mean as opposed to SQL being injected somewhere, of course.
14. Re:Not a big deal by Anonymous Coward · 2012-01-21 11:24 · 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!
15. Re:Not a big deal by LordLimecat · 2012-01-21 11:31 · Score: 3, Informative
  
  Just because you can get it emailed to you does not mean that it is stored plaintext.
16. Re:Not a big deal by metrix007 · 2012-01-21 11:36 · Score: 1
  
  It means they are stored in a less than ideally secure way. If a script can retrieve the password, so can an attacker.
  
  --
  If you ignore ACs because they are anonymous - you're an idiot.
17. Re:Not a big deal by ZackZero · 2012-01-21 12:13 · Score: 4, Funny
  
  Of course, since rationality hasn't historically been deliverable by SQL injection :P
18. Re:Not a big deal by tqk · 2012-01-21 12:20 · Score: 1
  
  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. Yet again, someone dropped the ball, IMO. If you're not sure what the downsides are, don't turn it on until you do know and understand how to mitigate it.
  FTP, in 2012! Eeeww! Just sayin'.
  
  --
  "Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.
19. Re:Not a big deal by etresoft · 2012-01-21 13:24 · 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.
20. Re:Not a big deal by etresoft · 2012-01-21 13:43 · 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.
21. Re:Not a big deal by Anonymous Coward · 2012-01-21 14:00 · Score: 1
  
  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
22. Re:Not a big deal by JWSmythe · 2012-01-21 14:03 · 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.
23. Re:Not a big deal by asdfghjklqwertyuiop · 2012-01-21 14:17 · Score: 1
  
  If they can email you the plain text then they are not hashed.
24. Re:Not a big deal by LordLimecat · 2012-01-21 14:38 · Score: 1
  
  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.
25. Re:Not a big deal by MichaelJ · 2012-01-21 14:49 · Score: 1
  
  And why is the web server running as root?
  
  --
  
  Michael J.
  Root, God, what is difference?
26. Re:Not a big deal by fluffy99 · 2012-01-21 15:16 · Score: 1
  
  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.
27. Re:Not a big deal by Voyager529 · 2012-01-21 15:31 · Score: 1
  
  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.
28. Re:Not a big deal by fluffy99 · 2012-01-21 15:55 · Score: 1
  
  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.
29. Re:Not a big deal by Mike · 2012-01-21 15:56 · Score: 1
  
  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.
30. Re:Not a big deal by Alex+Zepeda · 2012-01-21 16:20 · Score: 1
  
  I'd be hard pressed to believe you've dealt with anyone other than DreamHost. When I failed to renew my service with them it was because their hosting was glacial. It could barely keep up with a lightly used PHP image gallery. That was years ago. When I migrated clients away from DH last year it was because of chronic downtime. "Oops we fucked up" is great, and it's honest. It's also not something you want to keep seeing. "Oops we fucked up, but your worthless blogs about your kittens' trousers are safe" is /not/ something you want to see, ever. 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. Certainly it's not something you want to keep seeing
  Not doing any manner of scheduling for intrusive maintenance is not simply a tactic to scare away high maintenance customers, it's a tactic to scare away paying customers. You wanna know what's even less professional? Not having any phone support in the first place, and then not having any e-mail support or publicly available system status because everything's on the same network. A single point of failure isn't a tactic to "scare off the clueless, high-maintenance market" it's a hallmark of someone who doesn't know what they're doing.
  
  --
  The revolution will be mocked
31. Re:Not a big deal by spong · 2012-01-21 16:37 · Score: 1
  
  Apparently the passwords were hashed [...]
  I'm not sure that's quite true across the board. According to a blog comment here 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 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.
32. Re:Not a big deal by metrix007 · 2012-01-21 17:13 · Score: 1
  
  For that to work any records of email address would have to protected. Not really a practical solution.
  
  --
  If you ignore ACs because they are anonymous - you're an idiot.
33. Re:Not a big deal by Solandri · 2012-01-21 18:14 · 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.
34. Re:Not a big deal by makomk · 2012-01-21 22:35 · 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.
35. Re:Not a big deal by Tanktalus · 2012-01-22 02:47 · Score: 1
  
  "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.
36. Re:Not a big deal by dkf · 2012-01-22 02:51 · Score: 1
  
  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 injection in one part of a system is a good indication that the rest is not much better.
  
  --
  "Little does he know, but there is no 'I' in 'Idiot'!"
37. Re:Not a big deal by tqk · 2012-01-22 05:31 · Score: 1
  
  "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, and it's not any more difficult to use. Thanks. HAND."
  It seems like millennia ago that I had to warn my local university that their finger service was the perfect stalker enabler.
  
  --
  "Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.
38. Re:Not a big deal by xous · 2012-01-22 06:34 · Score: 1
  
  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.
39. Re:Not a big deal by xous · 2012-01-22 06:40 · Score: 1
  
  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.
40. Re:Not a big deal by t4ng* · 2012-01-22 08:59 · Score: 1
  
  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 appropriately.
41. Re:Not a big deal by LordLimecat · 2012-01-22 16:55 · Score: 1
  
  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 is used to decrypt the corresponding password, which is then mailed to you.
  I believe that this is the most secure way to store a password if being able to recover it is required, since only a bruteforce or the account owner would be able to recover it.
42. Re:Not a big deal by ozbon · 2012-01-22 22:42 · Score: 1
  
  The Status for dreamhost is always available on http://status.dreamhost.com , which I understand is a completely separate hosted setup. I know it's been available when the rest of DH has been broken.
  
  They also have a twitter feed for their status, @dreamhoststatus, I think.
  
  Phone support is available, but at a fee. Email / control-panel- based support is (IME) excellent
  
  --
  I say we take off and nuke it from orbit. It's the only way to be sure...
43. Re:Not a big deal by fluffy99 · 2012-01-23 01:06 · Score: 1
  
  I understood the concept. Just pointing out that they need to have your contact info somewhere which would naturally include your email address
44. Re:Not a big deal by LordLimecat · 2012-01-23 03:27 · Score: 1
  
  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.
45. Re:Not a big deal by Alex+Zepeda · 2012-01-23 21:19 · Score: 1
  
  status.dreamhost.com = dreamhoststatus.com = down when they bork one of their core routers. After last year, I'd sure hope that they've put the status blog and corporate e-mail on a separate network. Pretty sure that they've been too busy posting pictures of cat anuses to have bothered changing anything tho. Phone support /is/ available, but you've got to plead for a call back via e-mail. That's all fine and dandy except for the fact that it's all on one network. A single point of failure is a single point of failure. You can't plead via e-mail for a callback when they can't read their e-mail. But, hey, tech support via twitter makes everything better, yeah?
  I don't like DreamHost because they're unprofessional, I took my business elsewhere because they don't know wtf they're doing.
  
  --
  The revolution will be mocked
FTP? by MichaelSmith · 2012-01-21 10:06 · Score: 5, Insightful

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

--
http://michaelsmith.id.au
1. Re:FTP? by Wayne247 · 2012-01-21 10:29 · Score: 1
  
  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.
2. Re:FTP? by reve_etrange · 2012-01-21 10:40 · Score: 2
  
  I believe Dreamhost handles this by issuing a separate password for FTP.
  They should handle it by only supporting SFTP.
  
  --
  .: Semper Absurda :.
3. Re:FTP? by awilden · 2012-01-21 10:50 · 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.
4. Re:FTP? by trip23 · 2012-01-21 11:10 · Score: 2
  
  For what it's worth, there's FTPS and FTPES. So you can secure FTP-Conntections since quite a time.
5. Re:FTP? by Billly+Gates · 2012-01-21 11:42 · Score: 1
  
  Content management software from commercial vendors lack it. I guess they assume you have your own ftp servers in your big corporate office. They forget not everyone has the luxury of 10 t1s for a good network connection and their own IT management and servers in the same building. Most small to medium businesses use an ISP.
  
  --
  http://saveie6.com/
6. Re:FTP? by Grishnakh · 2012-01-21 12:18 · Score: 1
  
  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. But just like some people just won't stop using IE5.5 and IE6, I guess there's other ancient MS junkware that a bunch of home users won't give up, no matter how much MS tries to coerce them to.
7. Re:FTP? by reve_etrange · 2012-01-21 13:50 · Score: 1
  
  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.
  
  --
  .: Semper Absurda :.
8. Re:FTP? by Solandri · 2012-01-21 18:08 · Score: 1
  
  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.
9. Re:FTP? by fnj · 2012-01-21 19:09 · Score: 1
  
  Are there any FTP programs left that don't know SFTP?
  Is that a serious question? If so, how about /usr/bin/ftp just for starters? And I imagine c:\windows\system32\ftp.exe as well, though I don't use toy operating systems myself. Those are by far the most common ftp clients.
10. Re:FTP? by Grishnakh · 2012-01-22 11:04 · Score: 1
  
  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 setting up a small bash script using "lftp" which has an ftp/sftp mirroring feature.
  Here's my script if it helps anyone. To use ftp instead (not that I recommend it), change the PORT variable and change "sftp://" to "ftp://". The problem with this approach, however, is that it's pretty slow, as the sftp mirroring algorithm has to go into every directory on the remote server and compare all the files with all the files on the local side, so whether you're changing a single character of one file, or 30 files, there's not much difference in execution time, and the time greatly depends on the total size of your site. If you have a big site with tons of content, or some giant shopping cart system installed like osCommerce, expect it to be pretty slow to update. rsync is much, much, much faster than this. There is another program, called "sitecopy", which I used to use for mirroring over ftp long ago; it stores a local copy of the state of the remote machine, so its updates are extremely fast (just don't go change stuff on the remote side without going through this program, or else it'll get out-of-sync). However, it hasn't had any development in a long time, and while they did implement sftp just before the developers apparently abandoned it, they didn't finish it and it doesn't work at all.
  
  #!/bin/bash
  HOST="ftp.domain1.com"
  PORT="2222"
  USER="username"
  PASS="password"
  LCD="~/website/domain1/"
  RCD="~/"
  lftp -c "open -u $USER,$PASS sftp://$HOST:$PORT;
  lcd $LCD;
  cd $RCD;
  mirror --reverse \
  --delete \
  --verbose \
  --exclude-glob .membership \
  --exclude-glob *.swp \
  --exclude-glob .git/ \
  --exclude-glob cgi-bin/ \
  --exclude-glob stats/ \
  --exclude-glob sessions/ \
  --exclude-glob other_dir_to_exclude/"
  It probably wouldn't be too hard to modify this so you can pull down your website stats from the stats/ directory too. I believe you'd just run the same command a second time, but get rid of the --reverse option, and either --exclude-glob everything but the directories you want to pull from, or just change the $LCD and $RCD variables to the directory you want.
11. Re:FTP? by reve_etrange · 2012-01-22 21:06 · Score: 1
  
  By default, rsync simply uses SSH. It can also use any remote shell or the rsync protocol.
  
  --
  .: Semper Absurda :.
12. Re:FTP? by Grishnakh · 2012-01-22 22:24 · Score: 1
  
  Unfortunately, no there's ssh access on my webhost, so sftp (w/ password) is the only secure way.
13. Re:FTP? by reve_etrange · 2012-01-23 07:48 · Score: 1
  
  SFTP is SSH - that's what the "S" is for. I guess they just don't want you to have command line access...
  
  --
  .: Semper Absurda :.
Only since last June.. by Dynamoo · 2012-01-21 10:15 · 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 · 2012-01-21 10:27 · 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 · 2012-01-21 12:53 · 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.
3. Re:Only since last June.. by Rakishi · 2012-01-21 16:48 · Score: 1
  
  The entire point behind using a hosting provider and not just running your own server is for them to deal with shit like that.
  
  No it's not. It's like saying it's a car rental companies fault if someone steals a rented car and crashes into a school bus. All a hosting provider does is provide the hosting environment, after that it's up to the customer to deal with things unless they pay for some specific service.
4. Re:Only since last June.. by Zaiff+Urgulbunger · 2012-01-22 07:13 · Score: 1
  
  If I recall correctly, the traditional way to manage WP was by the customer installing it. Then DH introduced one-click-installs to make it easier to install and update, but the customer was still responsible for updating since an automatic update might break their site. And I *believe* (but don't use) there's a way to use a single DH managed instance of WP. This is less flexible - I think you're limited on themes and plugins - but is managed by DH.
  
  In all case except where the customer has manually installed WP themselves, DH always have updates available as soon as they're available *except* where they've discovered problems.... this has occured in the last year where presumably DH testing has discovered a problem, communicated the problem with the Wordpress folks, and then subsequently made the fixed-fix available.
  
  Seriously, if you want to attack DH, just complain about their shared servers often being stupidly over commited, and generally kind of sluggish all the time. I'd agree with that! But from a technical stand-point, they're usually pretty good.
Were they hashed? by Anonymous Coward · 2012-01-21 10:17 · Score: 1

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?
Painless by radcore · 2012-01-21 10:22 · Score: 1

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.
1. Re:Painless by dgatwood · 2012-01-21 10:27 · Score: 1
  
  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.
  
  --
  Check out my sci-fi/humor trilogy at PatriotsBooks.
2. Re:Painless by dgatwood · 2012-01-21 10:32 · Score: 1
  
  Err... s/SSL/RSA/g.
  
  --
  Check out my sci-fi/humor trilogy at PatriotsBooks.
3. Re:Painless by chimericdream · 2012-01-21 10:36 · 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.
4. Re:Painless by radcore · 2012-01-21 11:05 · Score: 1
  
  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."
Found a planted perl script by dem0n1 · 2012-01-21 10:45 · 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?
I'll see your SFTP and raise you... by sakdoctor · 2012-01-21 10:45 · 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 · 2012-01-21 11:05 · 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
2. Re:I'll see your SFTP and raise you... by reve_etrange · 2012-01-21 13:44 · Score: 1
  
  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.
  
  --
  .: Semper Absurda :.
3. Re:I'll see your SFTP and raise you... by antdude · 2012-01-22 05:08 · Score: 1
  
  Can sftp and scp do resume downloads and uploads yet?
  
  --
  Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
4. Re:I'll see your SFTP and raise you... by xous · 2012-01-22 15:31 · Score: 1
  
  Use rsync over ssh.
5. Re:I'll see your SFTP and raise you... by antdude · 2012-01-22 15:46 · Score: 1
  
  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.
  
  --
  Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
Conversation probably went like this by webbiedave · 2012-01-21 11:35 · Score: 1

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 ahead and change the passwords."
Re:-1 hysterical by icebraining · 2012-01-21 12:06 · 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
Why a Database of Password? by segedunum · 2012-01-21 12:44 · Score: 1

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?
1. Re:Why a Database of Password? by etresoft · 2012-01-21 13:30 · Score: 1
  
  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.
Meanwhile under the radar by dbIII · 2012-01-21 13:58 · 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.
The stolen laptop problem renders that insane by dbIII · 2012-01-21 14:13 · Score: 1

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 for anything that comes in remotely. You can be one click away from a thief getting access.
1. Re:The stolen laptop problem renders that insane by hobarrera · 2012-01-23 00:39 · Score: 1
  
  People who store keys on their disks SHOULD be taught to use full-disk-encryption, specially in case of laptops.
Reading comprehenion? by sakdoctor · 2012-01-21 15:10 · Score: 1

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.
Cleartext passwords by phorm · 2012-01-21 16:04 · Score: 1

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).
Didn't they stored passwords crypted?! by hubertf · 2012-01-21 16:14 · Score: 1

As the Unix does since ... 1969?
Seriously, WTF?!
- Hubert
1. Re:Didn't they stored passwords crypted?! by sl3xd · 2012-01-22 11:27 · Score: 1
  
  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 terrifyingly effective - primary because password policies that require things like 10+ characters, a number, and a non-alphanumeric character -- are often almost trivial to crack, because they're still based on a word - something like 'h@w7n3s5' is cracked surprisingly quickly.
  If the authentication database (even encrypted or hashed) is comprimised, then the only sane course of action is to expire ALL passwords immediately. An admin has no way of knowing which passwords are "safe", so the best solution is to ensure that no cracked password will work for the attacker.
  
  --
  -- Sometimes you have to turn the lights off in order to see.
Love Dreamhost by seandiggity · 2012-01-21 17:44 · Score: 1

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 resetting the shell/FTP/SFTP passwords. It was an annoyance late last night when I went to do routine maintenance and couldn't get shell access, and I (somewhat comically) kept trying other passwords, thinking for some reason that there was a problem with my keyring. But I was greeted by a very visible message as soon as I logged into the Dreamhost web control panel, took two seconds to reset my pass, and that was that. Nothing to see here folks, move along.

--
Geeks like to think that they can ignore politics, you can leave politics alone, but politics won't leave you alone.-rms
I think they do store clear text passwords by Anonymous Coward · 2012-01-21 19:46 · Score: 1

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?
argh! by jthomp · 2012-01-21 22:16 · Score: 1

What sucks about this is I set up a DH account the day before this happened x.x
More info on what happened from CEO by t4ng* · 2012-01-22 09:35 · Score: 1

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
Also, due to the number of customers changing their passwords, the password sync time is very slow right now. More info here.
Re:-1 hysterical by sl3xd · 2012-01-22 11:54 · Score: 1

Any admin that has to manage a large number of machines with common authentication is INSANE to use /etc/passwd or /etc/shadow. It's FAR too much work, FAR too much trouble, and will cause FAR too many problems.
I'd bet the farm they're using some combination of Kerberos + LDAP. Kerberos+LDAP is the standard for holding the authentication and user information - even Microsoft uses it in their Active Directory.
PAM = Pluggable Authentication Modules. This means you just use a Kerberos+LDAP plugin for authentication, and the user/password database doesn't even exist on the servers in the network.
Thing is: Kerberos doesn’t do anything unencrypted; passwords are never passed between machines. The client and server machines are able to authenticate each other as genuine, as well as authenticating users.
LDAP is easily (and properly) configured to use X.509 certificates and encryption as well - so nothing is ever passed "in the clear".
I'm very interested to learn exactly what happened.

--
-- Sometimes you have to turn the lights off in order to see.