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

221–230 of 282 posts

Re: Security incident update

#221

Post by jmillikin »

dangrossman wrote: post #217
toomuchtodo wrote: post #215

Earlier quoted context omitted.

So they violated the whole "only store those encrypted numbers on a system not accessible from the public internet" part.

No, they didn't... You have to be able to reach the server over a network somehow to be able to store new cards and charge existing ones. The requirement is not that the server have no NIC, just that it not be internet-facing itself. The DB server was only accessed through the compromised web server, not directly through the public internet.

The attacker claimed that he compromised their webserver. If he had access to the private key and encrypted numbers, then they were indeed being stored on an internet-facing machine.

  07:52  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.

Re: Security incident update

#222

Post by dangrossman »

jmillikin wrote: post #221
dangrossman wrote: post #217

Earlier quoted context omitted.

No, they didn't... You have to be able to reach the server over a network somehow to be able to store new cards and charge existing ones. The requirement is not that the server have no NIC, just that it not be internet-facing itself. The DB server was only accessed through the compromised web server, not directly through the public internet.

The attacker claimed that he compromised their webserver. If he had access to the private key and encrypted numbers, then they were indeed being stored on an internet-facing machine. 07:52 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…

Let's make this more clear:

Linode has two servers. One is a web server that runs their website and contains its source code. One is a database server containing customer information and encrypted credit card numbers. The web server is connected to the internet. The database server is not. They communicate over the private network.

The web server is compromised. The attacker has the source code, which includes the IP/host and login credentials for the database server, since the website code talks to the database to function. The attacker can now access the encrypted credit card numbers in the database by connecting from the web server.

At no point are the encrypted numbers stored on an internet-facing machine, but the attacker now has access to them. There is no evidence that says otherwise. There's no way to build this that doesn't have a path from the internet to the card numbers either, since eventually they need to get onto an internet-connected machine to talk to the payment gateway and actually charge those cards.

Re: Security incident update

#223

Post by scott_karana »

keidian wrote: post #15
AlexMuir wrote: post #6

Hmm. I'm sort of re-assured, but what's happened to the claim that this was targeting a specific customer?

It seems HTP went after nmap.org machines, so I'm guessing that woudl be the directed customer they picked?

Do you have a chatlog or citation?

I'm not arguing, I'd love to read it! :)

Re: Security incident update

#224

Post by eco »

rellik wrote: post #190
powertower wrote: post #178

Earlier quoted context omitted.

I've been a Linode customer since the start of 2007 and my biggest worry right now is this... > Credit card numbers in our database are stored in encrypted format, using public and private key encryption. The private key is itself encrypted with passphrase encryption and the complex passphrase is not stored electronically. By not providing further clarification that the private key was stored outside that compromised…

Why won't they just tell us the private key's passphrase, so we can judge for ourselves how secure it is?

Once they give the private key passphrase out there would be no need for us to judge for ourselves. The hackers would have everyones credit card information at that point.

Re: Security incident update

#225

Post by DanBC »

lawnchair_larry wrote: post #212
moxie wrote: post #162

"There were occurrences of Lish passwords in clear text in our database." I think that this is what's most criminal about the whole event. It's probably safe to assume that "there were occurances of Lish passwords in clear text..." is a euphemism for "we stored all Lish passwords in cleartext." Simply invalidating these is probably not enough. It's very likely that people reused their root login passwords as their Li…

sabat: You are hellbanned, FYI.

This comment is the last live comment: (https://news.ycombinator.com/item?id=5399303)

This comment is the last dead comment: (https://news.ycombinator.com/item?id=5399305)

Re: Security incident update

#227

Post by darkarmani »

UnoriginalGuy wrote: post #195
darkarmani wrote: post #192

Earlier quoted context omitted.

> What he says is correct, the attackers now have the private key file I will concede that this is highly likely, but they did not confirm that the private key was taken.

It is implied that it was taken. The IRC log said that they had taken it and since Linode is talking about the passphrase in their blog post, the implication there is that it was taken too. If the bad guys didn't have the private key then the passphrase is literally irrelevant to the discussion. Since they would have to break the primary cryptographic key rather than just the passphrase. A passphrase protects a priva…

> A passphrase protects a private key file NOT the data. So why would Linode even bring it up?

I would bring it when discussing how I cryptographically secured sensitive data. Especially, when people might be confused and try to argue that they should have used pbkdf2 and not encrypted the information (because they were thinking about password hashes).

Re: Security incident update

#228

Post by jmillikin »

dangrossman wrote: post #222
jmillikin wrote: post #221

Earlier quoted context omitted.

The attacker claimed that he compromised their webserver. If he had access to the private key and encrypted numbers, then they were indeed being stored on an internet-facing machine. 07:52 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…

Let's make this more clear: Linode has two servers. One is a web server that runs their website and contains its source code. One is a database server containing customer information and encrypted credit card numbers. The web server is connected to the internet. The database server is not. They communicate over the private network. The web server is compromised. The attacker has the source code, which includes the IP…

  > The web server is compromised. The attacker has the
  > source code, which includes the IP/host and login
  > credentials for the database server, since the website
  > code talks to the database to function.
IMO, if internet-facing machine A is storing login credentials to machine B, then machine B should be considered internet-facing.

There is no reason for a properly-designed system to be storing passwords or credit card numbers in the same database as the rest of the user's data. Such security-critical data should always be placed on a hardened machine, with the web server communicating via a small and easily-auditable interface.

Re: Security incident update

#230

Post by bradleyland »

plusbryan wrote: post #208
powertower wrote: post #178

Earlier quoted context omitted.

I've been a Linode customer since the start of 2007 and my biggest worry right now is this... > Credit card numbers in our database are stored in encrypted format, using public and private key encryption. The private key is itself encrypted with passphrase encryption and the complex passphrase is not stored electronically. By not providing further clarification that the private key was stored outside that compromised…

I'd recommend reporting your card likely stolen and getting a new number. The slight inconvenience is worth the peace of mind.

I recommend not bothering. Liability for fraudulent CC activity (in the US) is very low (max $500), and banks never enforce the liability for two reasons: 1) it's easier for them to chargeback the transaction to the vendor, thus they're not out of pocket, and 2) it causes customers to leave for a provider that doesn't hold them liable.

How much of your time spent chasing down and changing a CC number is worth a maximal risk of $500 with a vero low probability of occurring?

EDIT: Thanks to nenolod for the correction!

Post reply on HN