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

191–200 of 282 posts

Re: Security incident update

#191

Post by mdip »

rjknight wrote: post #90
mekoka wrote: 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…

Linode is a Linux company, but it's also a company founded in 2002-3. Back then, there weren't many great options for web programming and ColdFusion would have made a degree of sense (PHP 4.0 was released in 2000, and Ruby on Rails 1.0 didn't appear until 2004; Django was released in 2005). A modern, reasonably-secure web stack in those days really did mean "PHP with register_globals=Off". (Facebook and YouTube were…

With all of the bugs/costs associated with CF, it's strange to think of how many huge web properties made use of it (MySpace comes to mind), but the world was a very different place back then. As you mentioned, the choices were far fewer and I think the comfort level surrounding open source also played a role. In addition...

1) It was most common then to go the cgi-bin route for server side, which wasn't pleasant. CF offered an alternative to that very early on and made webdev more "accessible".

2) ColdFusion was baked into a lot of GUI based web design tools (I can only think of the name of one, NetObjects Fusion, because I rarely used those sorts of tools). Even though they probably weren't using a GUI based tool, being baked into several meant that peoples' exposure to CF was pretty common. I did absolutely nothing with ColdFusion, but routinely ran into it with freelance work I did.

3) In a large "enterprise" shops, I remember losing a bid because a manager Google(tm)'ed PHP, saw that it was originally stood for "personal home page" and told me they needed to hire someone more professional (thank God I dodged that bullet). The comfort with the current offering of open source web programming languages, in general, made managers uncomfortable for various FUD reasons. Case in point, I remember on the Windows side CF jobs getting eclipsed, nearly overnight, by RFPs for ASP in VBScript. ASP, after all, was backed by Microsoft, commercial, and effectively free (included with their Windows NT/2000 Servers).

Re: Security incident update

#192

Post by darkarmani »

corford wrote: post #183
darkarmani wrote: post #166

Earlier quoted context omitted.

> A single private key passphrase is all that stands between a bad guy and everyone's credit card information... Well I know I feel better... Where do you get that from? They encrypt all of the CC info using the public key. You need the private key AND the private key passphrase -- and one of them isn't stored on a computer.

I'm pretty sure UnoriginalGuy understands that. What he says is correct, the attackers now have the private key file so all that prevents them from decrypting the CC data is the passphrase. They don't know what this is but they can try and brute force it which is why it's relevant to wonder what cipher the key uses, how many bits and how long, random and complicated the passphrase text is. Hopefully, they used 4096 b…

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

Re: Security incident update

#193

Post by singlow »

rainforest wrote: post #29
ultimoo wrote: post #24

Earlier quoted context omitted.

I agree to your position of not storing the CC in the consumer database. However, it cannot be in a write-only state since usually consumers have to billed periodically without having to ask for their number.

Ah, my description wasn't the best, apologies. What I meant was the payment backend, a separate server, could only service write requests from the frontend. The backend itself would possess decryption keys to make charges, but the frontend could only ever ask it to bill a customer or change the information via a write-only API. Having said that, if the API were provided via ColdFusion it wouldn't have helped anyway.

That is in fact what was done in an application I worked on. We used ColdFusion for both the Front-End and the "Commerce Server" and the commerce server only took credit card information from the front-end and could not give it back. It was behind its own hardware firewall and any exploit in ColdFusion would have been hidden from the front end unless it could be exploited through the API methods we exposed through the gateway. To gain access to any other url endpoints you would need to access the server from within the firewall by connecting to a VPN gateway on a separate physical network that was only connected by a dedicated T1 to our office. We did this before there was PCI, because it made sense.

The whole system has now been rewritten in dotNET. It would be interesting to see if I can find that old CF app. It ran solid for almost ten years on the same 3 NT4 servers handling tens of thousands of users per day. And it could have probably run on one server except that we isolated the commerce and MSSQL functions from the front-end app.

Re: Security incident update

#194

Post by UnoriginalGuy »

darkarmani wrote: post #166
UnoriginalGuy wrote: post #118

Earlier quoted context omitted.

A single private key passphrase is all that stands between a bad guy and everyone's credit card information... Well I know I feel better... But jokes aside, there is a huge gap between the strongest and weakest algorithms used to passphrase protect a private key. I wish they gave us more information about the certificates. Including: is it ONE private certificate for everyone? Or one per client/customer? How was the…

> A single private key passphrase is all that stands between a bad guy and everyone's credit card information... Well I know I feel better... Where do you get that from? They encrypt all of the CC info using the public key. You need the private key AND the private key passphrase -- and one of them isn't stored on a computer.

> Where do you get that from?

The article and the IRC log.

The IRC dude said flat out that the "bad guys" have the private key and the encrypted data. They also have made no claims that turned out to be untrue yet.

The Blog post infers that the bad guys have the private key by talking about passphrases. Why are passphrases on the private key even a discussion topic unless the private key has fallen into "enemy" hands?

Therefore the ONLY thing between them and unencrypted data is the passphrase protecting the private key.

Re: Security incident update

#195

Post by UnoriginalGuy »

darkarmani wrote: post #192
corford wrote: post #183

Earlier quoted context omitted.

I'm pretty sure UnoriginalGuy understands that. What he says is correct, the attackers now have the private key file so all that prevents them from decrypting the CC data is the passphrase. They don't know what this is but they can try and brute force it which is why it's relevant to wonder what cipher the key uses, how many bits and how long, random and complicated the passphrase text is. Hopefully, they used 4096 b…

> 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 private key file NOT the data. So why would Linode even bring it up?

Re: Security incident update

#196

Post by pyre »

mekoka wrote: post #142
JshWright wrote: post #139

Earlier quoted context omitted.

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

Don't assume that the most transparent company out there isn't choosy about what it's being transparent about. There are plenty of things we never know that don't hurt us. I choose not to concern myself with such things.

The problem is when you don't know things that could hurt you. "Your credit card was stolen" is something that you need to know. "Your password was compromised" is something that you need to know. "Let's not tell anyone about it, and hope that this information isn't abused" is not a valid course of action for a company that cares about their customers.

Re: Security incident update

#197

Post by ryan-c »

corford wrote: post #183
darkarmani wrote: post #166

Earlier quoted context omitted.

> A single private key passphrase is all that stands between a bad guy and everyone's credit card information... Well I know I feel better... Where do you get that from? They encrypt all of the CC info using the public key. You need the private key AND the private key passphrase -- and one of them isn't stored on a computer.

I'm pretty sure UnoriginalGuy understands that. What he says is correct, the attackers now have the private key file so all that prevents them from decrypting the CC data is the passphrase. They don't know what this is but they can try and brute force it which is why it's relevant to wonder what cipher the key uses, how many bits and how long, random and complicated the passphrase text is. Hopefully, they used 4096 b…

Cracking even a 1024 bit RSA key would cost at least millions of dollars. Credit card numbers are not worth that much.

Re: Security incident update

#198

Post by ryan-c »

jrockway wrote: post #92
seabee wrote: post #71

Earlier quoted context omitted.

Even if they have a passphrase it has to be strong enough to withstand brute force for months. If you're not smart enough to keep the private key separate from the crap you're trying to protect, why should I think you're smart enough to ensure your passphrase is good enough?

why should I think you're smart enough to ensure your passphrase is good enough Key strengthening.

OpenSSL doesn't use key strengthening on password protected RSA keys. GPG does, but I don't know how much it does by default.

Re: Security incident update

#199

Post by hvs »

ig1 wrote: post #93

I've canceled the card I used with Linode, the hacker may or may not have got access to the card number, but given the level of uncertainty I'd just rather cancel my card and get a new one reissued. I imagine my bank feels the same way. Remember that depending on where you're based / your agreement with your bank that you might lose any standard "protection" for any fraudulent transactions that occur after you learn…

Agreed. As soon as I heard about this, I called my bank and canceled the card (no suspicious activity on it) and then regenerated 32 character passwords for all of my logins associated with Linode. An ounce of prevention and all that.

Re: Security incident update

#200

Post by kyrra »

codeulike wrote: post #86
vrta wrote: post #51

Earlier quoted context omitted.

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'm not sure, their wording around it is a bit convoluted "... previously unknown zero-day vulnerability in Adobe’s ColdFusion application server. The vulnerabilities have only recently been addressed in Adobe’s APSB13-10 hotfix (CVE-2013-1387 and CVE-2013-1388) which was released less than a week ago." To me that reads like 'it was a former zero-day exploit", as all exploits are.

Linode brought this issue to Adobe's attention. It's pretty clear that the hack happend 1-2 weeks BEFORE it was announced to the public on Friday. See: http://seclists.org/nmap-dev/2013/q2/3

seclists.org was one of the sites hit in the hack. See how they were down "over the last week". Also note that the Adobe security bulletin was release on April 9: http://www.adobe.com/support/security/bulletins/apsb13-10.ht...

So ya, these hackers found the problem (a 0-day in Coldfusion), used it against Linode. then Linode got Adobe to look into it and found the cause.

Post reply on HN