Hacker News Reader

Comment by derefr | Hacker News Reader

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 that does process the CC requests.

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.

View on HN

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.

Out of curiosity, is this token generation sufficiently general or is it tied to a specific bank/credit card provider? (Basically is it easy to switch providers without having all your customers enter their cc information again?)

Unfortunately it is tied to the merchant. :(

From their description it appears encrypted CC numbers were in the database amongst the other customer information. Sure, the data has to live somewhere, but the apparent situation of CC, customer, private key all accessible to the frontend looks sub-optimal.

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 the previous post though.

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

It's possible to debug targets running under the current user, so root privileges might not have been needed, if they had an agent running under the same UID as the application.

> 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.

Why would you keep the private key file on a machine on which you would never enter the passphrase?

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.

Right; this is a common experience with SSL/X.509 signing keys--they're encrypted by default, so any server you configure with your ssl.pem file will prompt for a passphrase on startup, and only keep the decrypted key in memory.

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

It strips this (rather useful) encryption, giving any successful attacker to your frontend server your private key, in exchange for letting the node come up non-interactively.

This is what ssh-agent does, and I could only hope Linode was using something similar. I think the statement suggests they did.

> 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.

Storing a passphrase (or unlocked private key) in memory is storing it electronically.

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).

Attacker claims to have done so in this irc log: http://pastebin.com/7WXRDyAg

> 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

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

Reply on news.ycombinator.com