The update has quite a frank and an apologetic tone to it. Especially the concluding paragraph gives it a very empathetic touch. It must be truly tough for the ops folk at Linode to have suffered an attack due to a third party 0-Day exploit. It could happen to any of us really. On a side note, I am not sure of the "some occurrences of plaintext Lish passwords". Seems like quite a goofup on Linode's part.
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 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 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".
What isn't in this post: - Any mention of the claim that they had made a deal with the hackers. No attempt to deny the claim. - Any mention of when the systems were compromised or when they discovered that they were compromised. The post starts with "Yesterday," mentions working "around the clock" and mentions Friday, giving the impression that this is all very recent, when according to the hacker Linode has known fo…
I find it somewhat worrying that they haven't directly address the points of the hacker's claim.
I am particularly interested to find out whether linode did enter into a deal with the hackers.
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
Right. I guess I had confused it with hashing. If the credit cards were hashed then it would be relatively easy to crack. Edited my comment.
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.
Even then, attackers with half a brain (and malicious intent) would also have backdoored the payment page to harvest "fresh" credit cards numbers during the period they went unnoticed (possibly days/weeks).
It's another good reason to leave the credit card handling to a reliable 3rd party imo.
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…
Sure, but in this case it wasn't Linode who initially came forward - it took a public announcement from the intruders for Linode to notify us.
Devils advocate: preparing a press release from a company after plugging holes and auditing that makes the appropriate admissions and apologies probably takes more time than writing up a successful hit after attacking a page.
Linode didn't just take their time to announce this, just a few hours ago they were apparently telling customers definitively that their credit card information hadn't been accessed.
"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."
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?
I know Linode has been getting hammered for not being trustable or that they don't respond well when contacted, but in my experience they have been extremely responsive to any issues I have raised. I don't just mean technical issues either, we had what looked like a security breach on our account and it kicked of a small frenzy in their support staff and supervisory team to track down the problem. They figured out wh…
I can second this - Linode has always responded quickly and effectively in my experience.