The hacker won't be able to take your CC number for themselves in this case, but they'll sure be able to put spurious/malicious charges on your account.
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 the previous post though.
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.
> However, the private key can be then used to carry out crypto operations.
Surely this is of concern? According to the logs they'd known about the breach for a week - that seems like enough time to decrypt each card one by one and exfiltrate them.
Thinking about it though, that's basically the role of the key passphrase.
That's why this line, that most SSL providers give in their instructions, is so dangerous:
openssl rsa -in server.key.org -out server.key
> The private key is itself encrypted with passphrase encryption and the passphrase is not stored electronically
So even if the hacker bragged about obtaining both the public and private keys, the private key was protected and therefore unusable without the passphrase.
At this point, we can all hope linode used a very complex passphrase... My gut feeling is that they did.
Once the attacker has root, they can dump the memory and access this information. The attacker claims to have gigabytes of data, which could well include a memory image (or swap partition image, if the program that stored this in memory didn't lock the memory to prevent it being swapped out).
> 07:52 < HTP> the CCrypter class of the linode application context was accessable from outside the wwwroot using undocumented ColdFusion methods. i was fully able to decrypt the ccs using the in-memory privkey that they supplied the password for. > 07:53 < HTP> coldfusion runs as a single process, and its memory can be accessed using the ColdFusion wrapper
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...
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.
An encoded filesystem doesn't mean the sysadmin types in the passphrase every time something hits an "open()" call, its (usually) just once at boot time. Or sudo can be configured so you get to authenticate every hour not every time you run a command.
Also to be honest I've never had a problem with linode, combined with I've heard they've got pretty good support, so if there is a dude on duty at 3am he probably has nothing to do other than type in a password. So that would be an alternative, simple architecture. Now where it gets hard to justify is when there's enough traffic to pay a dude to sit there typing in the password all day, but they're apparently not that big.
(edited to add I hope they didn't actually use encfs and/or sudo, I was using them as an example of a user interface not as the final answer for how it would be implemented.)
They may've changed their billing system in the last 12+ months.
If it's a strong, long non-dictionary passphrase, then I'm not nervous. But, we don't really have any idea if it is or not. The fact that their web interface boxes had the private key on them is a huge concern - you'd ideally run all billing stuff on a machine that is highly locked down, perhaps not even accessible outside of a very strict range of IP addresses. The practice of leaving the private keys hanging around on the same boxes that ran the website makes me awfully nervous about the other links in the chain.
At that point, it really depends on how strong their passphrase is. If it's a dictionary word, we're pretty much fucked.
Having the private key in the web frontend sounds like a bad idea (as this incident has proved), they should use a backend system that is not accessible from the Internet. I don't know how they system works but the web frontend needs to encrypt CC numbers but I'm not sure it is required to decrypt them as that could be performed in a more restricted environment.
Security incidents suck, but the good news is that they now have a chance to improve their security.