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

81–90 of 282 posts

Re: Security incident update

#81

Post by thaumaturgy »

entropy_ wrote: post #73
cheald wrote: post #2

Good to see some discussion and acknowledgment from Linode, but their treatment of the credit card encryption is distressing. They don't address the claim that the private keys were on the servers' filesystems, and instead focus on them being password protected. If the password is brute-forced, then it's game over.

That doesn't make any sense. It's exactly like saying: "Oh sure, the credit card numbers were encrypted but if the encryption key is brute-forced then it's game over". The CC numbers were encrypted using a public key. The corresponding private key was itself encrypted using "[a] complex passphrase [that] is not stored electronically". They could be lying, but if they are not then this is perfectly valid security. Usi…

> When you want to bill your customers you'd input the passphrase which wouldn't be stored anywhere, would be used to temporarily decrypt the CC numbers and bill everyone.

I've had account changes billed to my card within minutes, even (and especially) in the middle of the night (when I do most of that stuff). I'm having a little bit of trouble imagining that someone's sitting in front of a terminal and typing a passphrase into a prompt every three to five minutes, all day long.

Re: Security incident update

#82

Post by otherdave »

moconnor wrote: post #50
dchest wrote: post #35

Earlier quoted context omitted.

"There were occurrences of Lish passwords in clear text in our database."

Bear in mind this can be as simple as a handful of people emailing their LISH password to support while asking if it is correct etc.

Or someone mistakenly logging "Bad LISH Password: 'FOO' for user 'BAR'" somewhere that logs to the DB.

Re: Security incident update

#83

Post by jaxbot »

abalone wrote: post #75

If the hackers got to the ColdFusion source code then it is quite possible they decrypted credit card numbers. The passphrase may not be stored in the database but presumably the decryption key is kept in memory by the app server while running. Otherwise it wouldn't be able to charge anything. And if the hackers could modify the ColdFusion source code, they can get to anything the app server can, including the decryp…

From what HTP said on IRC, the credit card numbers were decrypted within the application context, which would be consistent with what you said. But during the IRC conversation, HTP willingly gave out the last four digits of people's CC#s, but ignored any request for digits before that, which would be more consistent with what Linode is stating.

It's all a very confusing world where nobody has a definite answer. Just 2 cents, don't act like I'm sharing a fact or anything

Re: Security incident update

#85

Post by mekoka »

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 lesson and will become an even more secure provider for it. I believe that moving my sites away from them at this moment would be like selling stocks when they're about to go up.

Re: Security incident update

#86

Post by codeulike »

vrta wrote: post #51
troels wrote: post #33

Earlier quoted context omitted.

It's not really a zero-day, if a patch has been out for a week though.

It was 0-day when they got hit. Sad thing is that they do not tell how much time has passed since the hack.

I'm not sure, their wording around it is a bit convoluted

"... previously unknown zero-day vulnerability in Adobe’s ColdFusion application server. The vulnerabilities have only recently been addressed in Adobe’s APSB13-10 hotfix (CVE-2013-1387 and CVE-2013-1388) which was released less than a week ago."

To me that reads like 'it was a former zero-day exploit", as all exploits are.

Re: Security incident update

#87

Post by Confusion »

dchest wrote: post #47
Confusion wrote: post #43

Earlier quoted context omitted.

Which is entirely different from "all passwords were stored in plain text". We don't know whether there were 1, 100 or a majority of such passwords. It's a bad oversight in each case, but the latter is quite a bit worse than the former.

Right, we don't know because they failed to disclose this.

Wouldn't you rather have them working on assessing, containing and repairing the damage rather than catering to the impatient internet crowd that is so used to immediate updates on everything that they can't fathom putting together a responsible, useful, correct response might actually take a while? Honestly, these people don't understand what it takes to run a company and handle such an incident. As far as i'm concerned, the indignant vocal minority could shove it while I was working on resolving the problem for the majority of customers that exactly that from us.

Re: Security incident update

#88

Post by entropy_ »

thaumaturgy wrote: post #81
entropy_ wrote: post #73

Earlier quoted context omitted.

That doesn't make any sense. It's exactly like saying: "Oh sure, the credit card numbers were encrypted but if the encryption key is brute-forced then it's game over". The CC numbers were encrypted using a public key. The corresponding private key was itself encrypted using "[a] complex passphrase [that] is not stored electronically". They could be lying, but if they are not then this is perfectly valid security. Usi…

> When you want to bill your customers you'd input the passphrase which wouldn't be stored anywhere, would be used to temporarily decrypt the CC numbers and bill everyone. I've had account changes billed to my card within minutes, even (and especially) in the middle of the night (when I do most of that stuff). I'm having a little bit of trouble imagining that someone's sitting in front of a terminal and typing a pass…

You make a good point

Re: Security incident update

#89

Post by corford »

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…

This is what Caker (founder of Linode IIRC?) has to say about the strength of the passphrase:

"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." [1]

[1] http://blog.linode.com/2013/04/16/security-incident-update/c...

Re: Security incident update

#90

Post by rjknight »

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…

Linode is a Linux company, but it's also a company founded in 2002-3. Back then, there weren't many great options for web programming and ColdFusion would have made a degree of sense (PHP 4.0 was released in 2000, and Ruby on Rails 1.0 didn't appear until 2004; Django was released in 2005). A modern, reasonably-secure web stack in those days really did mean "PHP with register_globals=Off". (Facebook and YouTube were both created later, and in PHP).

It's a bit surprising that they haven't moved away from CF, but this is a good example of how hard it can be to transition away from legacy technologies. It's also not clear that security would have been improved by adopting, say, Rails, given that there has been no shortage in security issues there either.

Post reply on HN