Live data from Hacker News

Security incident update

blog.linode.com

251–260 of 282 posts

Re: Security incident update

#251

Earlier quoted context omitted.

> 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 c…

> communicating via a small and easily-auditable interface ... isn't that called 'a network'? This seems to contradict your earlier statement about 'machine B should be considered internet-facing.'

It's not a contradiction, because 1) the webserver would not have login credentials to the hardened machine and 2) the interface would be much smaller than "everything in SQL".

A typical example of such an interface would expose about four operations:

  // Return true if the given user/password pair is valid.
  bool PasswordValid(string user, string password)

  // Return true if the password was changed successfully.
  bool ChangePassword(string user, string old_password, string new_password)

  // Returns a reset token.
  string RequestPasswordReset(string user)

  // Returns true if the password was reset successfully.
  bool CompletePasswordReset(string user, string token, string new_password)
With reasonable changes to support two-factor, if needed.

Credit card data would have a similar interface -- add card, remove card, list user's cards without full cc#, charge card.

The advantages of this over the sort of "hashed passwords in MySQL" design are obvious. Not only is sensitive data protected against "SELECT *", but it's now possible to apply security policies to password management. For example, the password service might enforce rate limiting on how often a particular user's password can be checked -- that way, even if the web server is compromised, the attacker will be unable to compromise passwords any faster than they could via the standard login screen.

The password machine would typically be configured to have only the password service and SSH running, with SSH access limited to a key that's stored in a safe somewhere and used only for emergencies.

If a developer doesn't feel comfortable building such a system themselves (reasonable), then there are many commercial products available. They're expensive for a home user or ramen-budget startup, but a company like Linode would be able to afford one easily.

Re: Security incident update

#252
post #15

Earlier quoted context omitted.

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! :)

Here's the writeup from seclists.org: http://seclists.org/nmap-dev/2013/q2/3

It looks like seclists.org and nmap.org are hosted on different IP addresses, but both route to linode, and both have the same WHOIS information, so I think it's safe to say the writeup applies to both.

Re: Security incident update

#253

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…

Could you share the source of this statement?

Re: Security incident update

#254
post #85

The one thing that puzzles me above anything else about this whole thing is: "Linode uses ColdFusion". I mean, you have this Linux company that's pretty much an open source champion to us Linux guys and then... Adobe ColdFusion. Really? I know nothing about ColdFusion, don't get me wrong, I just find it an incredibly odd choice for a Linux company. That having been said, I think Linode just learnt a really unpleasant…

>That having been said, I think Linode just learnt a really unpleasant lesson and will become an even more secure provider for it. I believe that moving my sites away from them at this moment would be like selling stocks when they're about to go up. What concerns me is that the would have been perfectly happy to sweep most of this under the rug if Ryan hadn't forced their hand. The security lesson is one thing (hacks…

> What concerns me is that the would have been perfectly happy to sweep most of this under the rug if Ryan hadn't forced their hand.

That's a rather cynical thing to say. There's no proof that without Ryan's chat log, Linode wouldn't have told us anything.

Re: Security incident update

#255
post #209

Earlier quoted context omitted.

It's a private key. You need the public key to encrypt, which is not password-encrypted. Although I still wonder about how they run recurring charges.

It could be a manual script that he runs which prompts for the passphrase. I know that earlier in Linode's history, caker made it seem as if it worked that way from the way he acted in their IRC channel when the batch transactions were running.

This seems likely. Once a month, run a script, type in the complex passphrase, and all the billing gets done at once.

Re: Security incident update

#256

Earlier quoted context omitted.

>Facebook and YouTube were both created later, and in PHP youtube was always done in python as far as I understand. http://www.youtube.com/watch?v=G-lGCC4KKok But yeah, back in 2002-3 coldfusion was an option.

Youtube pre-Google was PHP

[deleted]

Re: Security incident update

#257

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…

Could you share the source of this statement?

It's from the pastebin'd IRC log: http://pastebin.com/7WXRDyAg

Re: Security incident update

#258

Earlier quoted context omitted.

>Facebook and YouTube were both created later, and in PHP youtube was always done in python as far as I understand. http://www.youtube.com/watch?v=G-lGCC4KKok But yeah, back in 2002-3 coldfusion was an option.

Youtube pre-Google was PHP

my primary reference that it has always been python is this video from 2007 which was only shortly after they were acquired.

http://youtu.be/ZW5_eEKEC28?t=4m8s

Re: Security incident update

#259

Earlier quoted context omitted.

It is not very difficult to memorize random strings of arbitrary characters. I use a password manager to manage most of my accounts, but the important ones, like banks and email, I keep in my head. I use my password manager to generate a 15 character string of alpha+numeric+symbols. The symbols would kind of make it hard, except that in my head they are just upper-case numbers, mostly (shift-7, not ampersand). And in…

The thing is for your personal bank account a 15 character password is acceptable. But for x many customer credit card details you're really looking for a much longer password that that. I'm talking 64 characters or more of pure random data. You shouldn't be compromising for the convenience of being able to remember a password when it secures such critical data in my opinion. Edit: I do agree though that your method…

At 15 characters and my character set ( [a-zA-Z0-9] and about 30 symbols) I have about 92 bits of entropy. Mean time to find a collision hash of my password is more than several years using 100% of computing power on the planet, much less do AES brute force. If memory is no issue - 256 bit passwords (usually displayed as 64 hex digits) are wonderful and there is no reason to stop short of that for pass keys that are stored electronically.

If I was responsible for this key I might increase from my normal 15 to 20 characters, giving me more than 120 bits of entropy, and I would expect to be safe from offline brute force for decades, and I could remember it.

Re: Security incident update

#260

Earlier quoted context omitted.

It could be a manual script that he runs which prompts for the passphrase. I know that earlier in Linode's history, caker made it seem as if it worked that way from the way he acted in their IRC channel when the batch transactions were running.

This seems likely. Once a month, run a script, type in the complex passphrase, and all the billing gets done at once.

I mentioned this elsethread, but I've had changes to my account get charged to my card immediately (within minutes), even in the middle of the night. Last example of this was January 2012, so they may've changed their billing practices since then.
Post reply on HN