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

41–50 of 282 posts

Re: Security incident update

#41

Post by raverbashing »

JonnieCache wrote: post #14
derefr wrote: post #10

Earlier quoted context omitted.

I think a lot of people are failing to understand how credit card processing works. The private key needs to live on some machine, if you actually want to have any CC requests processed at some point. If the private key itself isn't on the frontend/user-facing server, then instead, when the frontend node is hacked, the hacker will find a shared secret or signing key to auth the frontend node against the backend node…

I suppose it could have been kept only in memory, rather than just chilling on the filsystem in a file called private_key which is basically what happened AFAIK. It's surely within the boundaries of sense to load the key manually each time the app boots. Thinking about it though, that's basically the role of the key passphrase.

Can anyone explain better how the passphrase is used to encrypt the private key? Is it AES?

Re: Security incident update

#42

Post by InclinedPlane »

rainforest wrote: post #11

Should CC info even be stored in the customer database? I would have thought that information should be write only. Does PCI allow that to happen with only PKI in place?

Most merchant account gateway providers have some sort of tokenization scheme to allow for recurring billing. The token is tied to transferring money from a specific credit card to a specific merchant account so it's not useful for 3rd parties to gain access to, unlike raw CC data.

Re: Security incident update

#43

Post by Confusion »

dchest wrote: post #35
nfm wrote: post #34

Earlier quoted context omitted.

"Linode Manager user passwords are not stored in our database, but their salted and cryptographically hashed representations are." Sounds like it's not stored in plaintext.

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

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.

Re: Security incident update

#44

Post by gingerlime »

markbao wrote: post #38
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 feel like there is a fine line between a "cover up" and a "grey hat disclosure". Reading the IRC logs from #linode [0], HTP hacker ryan* seems to say that they made a deal of "we don't tell if you don't tell" but then Linode broke the deal by reporting them to law enforcement. You could see this as a cover up or you could see this as a disclosure from the crackers to Linode. I see it as a cover up, since Linode sho…

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 good to see this layered approach being used by Linode. If the passphrase was strong enough, and not stored anywhere, then I doubt HTP would be able to gain access to the private key, even if they got the actual private key file.

Re: Security incident update

#45

Post by InclinedPlane »

derefr wrote: post #10
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.

I think a lot of people are failing to understand how credit card processing works. The private key needs to live on some machine, if you actually want to have any CC requests processed at some point. If the private key itself isn't on the frontend/user-facing server, then instead, when the frontend node is hacked, the hacker will find a shared secret or signing key to auth the frontend node against the backend node…

CC data however does NOT have to live on any machine that anyone except your merchant bank owns. If you are writing against billing APIs in the 21st century then you only need to store a token which you use for recurring billing. Not everyone does this, but it's a reasonably good practice, especially if you have had intrusions in the past.

Re: Security incident update

#46

Post by zhoutong »

EDIT 2: It seems that I have confused the "encryption" with normal hashing. So this comment is invalid if they are doing encryption properly.

I wonder how hard it is to brute-force the credit card numbers. Given the last 4 digits, the Luhn algorithm and the starting digit of common cards (e.g. 4 for Visa), there are essentially only 10 digits left to crack. That's just 10 billion combinations.

As part of the source code is exposed, most likely the encryption algorithm/sequence is already known. If the passphrase is shared among all credit cards and the encryption algorithm is a fast one, there's a fair chance that eventually these credit cards are going to be exposed all at once.

Or am I missing anything?

EDIT: Even if the encryption algorithm is as slow as 10,000 tries per second, exhaustively attempting every single credit card number possible is going to take 277 CPU-hours, or about a day in three quad-core machines.

Re: Security incident update

#47

Post by dchest »

Confusion wrote: post #43
dchest wrote: post #35

Earlier quoted context omitted.

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

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.

Re: Security incident update

#48

Post by gingerlime »

rainforest wrote: post #37
gingerlime wrote: post #27

Earlier quoted context omitted.

there's a difference between obtaining the private key and the private key file , which according to Linode was protected with a (hopefully strong) passphrase...

It might have been encrypted, but surely it must be exposed to their system somewhere to enable them to make charges? Is it feasible, if that was the case, that the attackers could use that to exfiltrate decrypted CC info? I suppose this wild speculation isn't helpful or conducive and waiting on more information might be a better idea. I think the reputation damage has already been done, judging by the comments on th…

It depends on how they implemented it. Maybe there's an operator that logs on once a day and enters the passphrase, and then they use it to charge credit cards. So the private key is exposed only for a brief period.

Another possibility is that the passphrase is entered when the machine is booted, and then the private key (not the passphrase) is loaded into memory. This is how e.g. ssh-agent[1] works. When this mechanism is used, you don't get access to the private key itself without direct memory access (which is possible, but not that easy to carry out, and would typically require root access and debug tools etc). However, the private key can be then used to carry out crypto operations.

From the IRC chat logs, it looks like ryan got the private key file, but he didn't get the private key itself. At least he didn't seem to provide any solid proof to suggest he did.

[1]https://en.wikipedia.org/wiki/Ssh-agent

Re: Security incident update

#49

Post by dchest »

zhoutong wrote: post #46

EDIT 2: It seems that I have confused the "encryption" with normal hashing. So this comment is invalid if they are doing encryption properly. I wonder how hard it is to brute-force the credit card numbers. Given the last 4 digits, the Luhn algorithm and the starting digit of common cards (e.g. 4 for Visa), there are essentially only 10 digits left to crack. That's just 10 billion combinations. As part of the source c…

If they used encryption properly (random or unique IV depending on cipher mode of operation), you can't bruteforce credit card numbers (encrypted content), you can only try to bruteforce the key used for encryption.

See http://en.wikipedia.org/wiki/Semantic_security and http://en.wikipedia.org/wiki/Ciphertext_indistinguishability

Re: Security incident update

#50

Post by moconnor »

dchest wrote: post #35
nfm wrote: post #34

Earlier quoted context omitted.

"Linode Manager user passwords are not stored in our database, but their salted and cryptographically hashed representations are." Sounds like it's not stored in plaintext.

"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.
Post reply on HN