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

71–80 of 282 posts

Re: Security incident update

#71

Post by seabee »

[deleted] wrote: post #69
gingerlime wrote: post #44

Earlier quoted context omitted.

Perhaps nitpicking, but looks like HTP might have gained password hashes and encrypted credit card numbers, as well as a passphrase protected private key file . That's if I'm reading between the lines of both ryan and Linode's statement. This is why you build security in layers. If one layer gets broken, there are other layers to protect you. I'm not underestimating the severity of this incident, but I think it's goo…

[deleted]

Even if they have a passphrase it has to be strong enough to withstand brute force for months. If you're not smart enough to keep the private key separate from the crap you're trying to protect, why should I think you're smart enough to ensure your passphrase is good enough?

Re: Security incident update

#72

Post by threeseed »

iaskwhy wrote: post #59
dchest wrote: post #35

Earlier quoted context omitted.

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

I believe the correct approach for us is to assume all Lish password where in clear text until a good explanation is given. It's not usual to store some password in clear text and encrypt the others, right?

Storing passwords in clear text is definitely not normal.

Also the social engineering implications could be huge. Many people use the same password across various sites so in theory there could be a lot of compromised email accounts. Which could then mean compromised internet banking sites, trading sites etc.

Re: Security incident update

#73

Post by entropy_ »

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.

Using this scheme, you can store new CC numbers any time you want using the public key. You'd have a regular billing cycle(say a month) with billings happening in a short time window(All my linode accounts get billed within minutes of each other so I think this is the case for linode). 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. Unless you are attacked in that window(or an attacker gains access before that window and can remain unnoticed until it happens, and even then they'd need root access to read the memory and not just access to the filesystem) then the CC numbers are pretty safe against any attack that leaks files/databases/etc...

Re: Security incident update

#74

Post by troels »

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.

Yeah, maybe you're right. The text is a bit unclear about that.

Re: Security incident update

#75

Post by abalone »

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 decryption key. ColdFusion uses an interpreted language so injecting code is possible with just filesystem access.

Linode says there's "no evidence" of decrypted card numbers but I think it's more a matter of no evidence.. yet. They also call salted hashes "useless" to hackers which betrays a rather unenlightened perspective on infosec.

Re: Security incident update

#76

Post by regecks »

markbao wrote: post #52
gingerlime wrote: post #44

Earlier quoted context omitted.

Perhaps nitpicking, but looks like HTP might have gained password hashes and encrypted credit card numbers, as well as a passphrase protected private key file . That's if I'm reading between the lines of both ryan and Linode's statement. This is why you build security in layers. If one layer gets broken, there are other layers to protect you. I'm not underestimating the severity of this incident, but I think it's goo…

Sorry, 6am here, that's what I mean. It is good to see Linode adopting this layered approach, though it is what you're supposed to do . The other route would be storing the private key file unencrypted, which, thank goodness that wasn't the case. Knowing Linode, I'm fairly confident it's a strong passphrase; it would be imprudent to secure credit card details with something like "swordfish".

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.

Re: Security incident update

#77

Post by thaumaturgy »

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 any Linode data of any other customer was accessed. In addition, we have found no evidence that payment information of any customer was accessed. ... Out of an abundance of caution, however, we have decided to implement a Linode Manager password reset,"

and their disclosure today. I find that I'm uncertain whether they would've released today's disclosure if it weren't for the IRC chat log getting passed around online.

I don't get why they thought it would be prudent to reset everyone's manager passwords "out of an abundance of caution", but didn't bother to mention the possible leak of payment information. We don't have any information on the strength of the passphrase used (nor can they provide any, of course); we have no idea how feasible it might be to brute-force it.

Even if the full credit card numbers are never broken, the last four digits are still available in the clear. That has been enough to give unauthorized persons access to accounts on other services in the past (see the Matt Honan thing from last year: http://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-hona...). Depending on what other information was stored in the database, customers may be at risk of having accounts compromised elsewhere using the billing information from Linode. Linode really should have included that information in Friday's announcement.

Also, ColdFusion has had 103 different CVEs going back to 1999 (http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=coldfusion). Adobe doesn't really have a sterling record when it comes to this stuff. A nice example is the recent CVE-2013-0632 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0632), a remote code execution exploit that was discovered already in use back on January 4th but didn't have a fix available until January 15th. Linode -- and their customers -- are a really big, juicy target for future CF vulnerabilities.

Re: Security incident update

#78

Post by mekoka »

chris_wot wrote: post #63

"Along with the encrypted credit card, the last four digits are stored in clear text to assist in lookups and for display on things like your Account tab and payment receipt emails." I really don't see the need for that at all. What sort of credit card "lookup" are they doing exactly?

It's not for them, it's for users. It helps to know which of your CCs is going to be charged.

Re: Security incident update

#79

Post by epo »

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.

I'd imagine the 'cover up' is because law enforcement is involved and this 'ryan' character is being looked for.

Re: Security incident update

#80

Post by mekoka »

antihero wrote: post #61

Who on earth uses ColdFusion any more? Surely when they re-built it a while back they could have used something more secure like Django?

I agree with questioning their choice of ColdFusion, but I have some reserves about your proposed alternative to use Django. I don't know how secure Django is, but I know it's big. And my perception is generally that anything that big is bound to have a few loose ends, if looked under the magnifier.
Post reply on HN