Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Security incident update

blog.linode.com

Post reply on HN
Print view View original

171–180 of 282 posts

Re: Security incident update

#171

Post by peterwwillis »

moxie wrote: post #162

"There were occurrences of Lish passwords in clear text in our database." I think that this is what's most criminal about the whole event. It's probably safe to assume that "there were occurances of Lish passwords in clear text..." is a euphemism for "we stored all Lish passwords in cleartext." Simply invalidating these is probably not enough. It's very likely that people reused their root login passwords as their Li…

The lish passwords are the easiest to abuse immediately, but the larger impact is on all the user accounts with weak reused passwords. While all of the manager passwords were reset, each VM's root password was not. Once a hashed password is cracked their root password is vulnerable (if it was reused). And that's probably a lot more people than had exposed lish passwords.

Everyone should go reset their virtual machine's root password if they reused them.

Re: Security incident update

#172

Post by yogo »

moxie wrote: post #162

"There were occurrences of Lish passwords in clear text in our database." I think that this is what's most criminal about the whole event. It's probably safe to assume that "there were occurances of Lish passwords in clear text..." is a euphemism for "we stored all Lish passwords in cleartext." Simply invalidating these is probably not enough. It's very likely that people reused their root login passwords as their Li…

Exactly! I'm pretty sure it was all Lish passwords. Yesterday the news was all focused on the credit card information but now it makes sense why Lish passwords were not working (when I was 100% sure I had it correct--Friday's email said nothing about lish iirc). Interestingly I even mentioned this as part of a ticket and they brushed it off as nothing... hmm.

Re: Security incident update

#173

Post by jberryman »

thaumaturgy wrote: post #77

They reset the passwords on Friday. Even assuming that they've been working for the last four days on discovering the extent of the intrusion, there's a pretty big gap between Friday's announcement: "This activity appears to have been a coordinated attempt to access the account of one of our customers. This customer is aware of this activity and we have determined its extent and impact. We have found no evidence that…

> we have no idea how feasible it might be to brute-force it.

Sorry to be morbid, but... there's also rubber hose cryptanalysis. Whether the payoff or actors involved here make that a legit concern I don't know.

Re: Security incident update

#174

Post by [deleted] »

jlongster wrote: post #168

I can't believe they don't address the claim that the public and private keys were stored in the same place. It makes me wonder if that's actually true, which knocks my trust down just a little bit more.

[deleted]

Re: Security incident update

#175

Post by hornd »

mekoka wrote: post #85

The one thing that puzzles me above anything else about this whole thing is: "Linode uses ColdFusion". I mean, you have this Linux company that's pretty much an open source champion to us Linux guys and then... Adobe ColdFusion. Really? I know nothing about ColdFusion, don't get me wrong, I just find it an incredibly odd choice for a Linux company. That having been said, I think Linode just learnt a really unpleasant…

Perhaps they simply enjoy using ColdFusion. It gets a lot of hate, but some of the features that ship with CF (templating, extremely easy db access, PDF generation) made/make CF a rather powerful and fun language. If only Adobe had chosen to release it for free...

You're right about it being an odd choice for a Linux company, though.

Re: Security incident update

#176

Post by corford »

joeyh wrote: post #152
corford wrote: post #91

Earlier quoted context omitted.

Also (and correct me if my understanding of this is wrong since I've never used it), LISH is just a remote terminal service. You still need to know the VM's root password. And frankly, if you're doing it right, the root password should be a long, unique random string that you store somewhere safe and never use since you should be using keys to login to your box on a day to day basis.

It's quite likely that someone has left root logged in on hvc0 (the LISH console) on their Linode, while logging out of LISH. Probably more than one person. Also, access to LISH even without a root password provides access to some scrollback output, which could expose sensitive information. Also, LISH allows multiple connections, all of which see the same console, so the attacker can just connect to it and wait for a…

Yeah but most of these are generic problems with providing a remote serial console (excluding LISH allowing multiple shared connections to one console, which is obviously bad).

They've now reset all the passwords and fixed the bug that meant some of them were being stored without encryption. So what we're saying is there was window of a week or so where only LISH users affected by the clear text bug may have been open to an attack if they happened to use LISH during this time frame and the attacker was targeting them. Not great, I agree, but could have been worse.

Hopefully, they'll change their setup going forward so that each LISH connection to the same VM gets its own console.

Re: Security incident update

#177

Post by singlow »

sparkinson wrote: post #99
regecks wrote: post #76

Earlier quoted context omitted.

Well, the official statement re: the passphrase is: > @Eivind – our private key is stored only in encrypted format. The passphrase is not guessable, sufficiently long and complex, not based on dictionary words, and not stored anywhere but in our heads.

> in our heads So it's short enough to remember and likely has some sort of pattern. There's a limit to what a person can remember, lower if there are several people that have to remember it.

It is not very difficult to memorize random strings of arbitrary characters. I use a password manager to manage most of my accounts, but the important ones, like banks and email, I keep in my head. I use my password manager to generate a 15 character string of alpha+numeric+symbols. The symbols would kind of make it hard, except that in my head they are just upper-case numbers, mostly (shift-7, not ampersand). And in any case they are just positions on a keyboard (God help me if I need to enter one from my cell phone).

To memorize, just copy it into your favorite text editor, then type it 25 times in a row and delete. If you are paranoid, make sure you use a text editor that does not store temp files. Do not save this password anywhere. Set a timer and do it again an hour later, then again the next day. 10 minutes of your time and you have a password in your head. I can keep 10-20 of these at a time, maybe more since I seem to be able to type older ones from years ago.

I don't consider myself to have a great memory. I can barely remember lyrics to songs I've listened to dozens of times and it takes me hours and hours to memorize lines for plays. But I started doing this for passwords ten years ago and it is very reliable.

Re: Security incident update

#178

Post by powertower »

moxie wrote: post #162

"There were occurrences of Lish passwords in clear text in our database." I think that this is what's most criminal about the whole event. It's probably safe to assume that "there were occurances of Lish passwords in clear text..." is a euphemism for "we stored all Lish passwords in cleartext." Simply invalidating these is probably not enough. It's very likely that people reused their root login passwords as their Li…

I've been a Linode customer since the start of 2007 and my biggest worry right now is this...

> Credit card numbers in our database are stored in encrypted format, using public and private key encryption. The private key is itself encrypted with passphrase encryption and the complex passphrase is not stored electronically.

By not providing further clarification that the private key was stored outside that compromised host in that update, you can read between the lines that they are trying hard not to address that particular issue.

I really don't want to assume that the attacker can now brute force the private key's passphrase, and it might not take long if that "complex" passphrase was a word out of /usr/share/dict/words.

Or worse, that the billing process was monitored via the compromised network, RAM, or a key logger - to get the unencrypted private key or it's passphrase.

Re: Security incident update

#179

Post by 33degrees »

sturadnidge wrote: post #3

I really wish they would officially comment on the 'cover up' aspect. Security breaches happen, and are forgivable. But attempting to broker a 'silencing' deal with the intruders and hoping your customers will never be the wiser is not. All this update does is restore my faith in their ability to store my information correctly. It does nothing to reassure me that they won't try to cover anything up again.

My guess is that they probably went straight to the authorities, while playing along with the intruders as a way of buying time and collecting as much information on them as possible. I'm not surprised that they wouldn't make an official comment on that, though.

Re: Security incident update

#180

Post by singlow »

VLM wrote: post #126
kbar13 wrote: post #12

Earlier quoted context omitted.

> Various people have reported fraudulent activity on their CCs Most likely not even related

Well, lets think about it a bit. It turns out the numbers are ridiculously hard to find although I'm a pretty good searcher/infovore. Better info would be appreciated. Anyway the best I could find was two claims: There were 11 million american victims of identity theft in 2011 (outta 400 million) for a ratio of about 1 in 40 of the general population gets p0wned per year. Obviously not all ID theft is CC theft but I'…

Nicely done.
Post reply on HN