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

161–170 of 282 posts

Re: Security incident update

#161

Post by bjterry »

sparkinson wrote: post #99
regecks wrote: post #76

Earlier quoted context omitted.

Well, the official statement re: the passphrase is: > @Eivind – our private key is stored only in encrypted format. The passphrase is not guessable, sufficiently long and complex, not based on dictionary words, and not stored anywhere but in our heads.

> in our heads So it's short enough to remember and likely has some sort of pattern. There's a limit to what a person can remember, lower if there are several people that have to remember it.

It's trivial to memorize an entire sonnet. Actors and actresses memorize many times that amount. It's also trivial to write a sonnet. How many bits of entropy do you think a sonnet has?

Re: Security incident update

#162

Post by moxie »

"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 Lish passwords, meaning that Linodes running without firewalled sshd are potentially vulnerable.

I hope Linode communicated who had "the occurrences" of compromised cleartext Lish passwords, so that those users could take appropriate action.

Re: Security incident update

#163

Post by joeyh »

joeyh wrote: post #156
gingerlime wrote: post #25

Earlier quoted context omitted.

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…

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 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 coldfusion runs as a single process, and its memory can be accessed using the ColdFusion wrapper

Re: Security incident update

#164

Post by lifeguard »

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…

E commerce is expensive to develop and ISPs operate on razor thin profit margins. Most ISPs grow organically, so their code-base is older.

The ISP 'grave yard' is full of companies that tried to roll their own billing system in PHP.

Re: Security incident update

#165

Post by acdha »

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…

Even back in 2002, the writing was on the wall for ColdFusion as the costs went up and many bugs[1] had gone unfixed for multiple major expensive releases during the legacy-customer milking phase of fading out of the market. Forget PHP4, even PHP 3 was a big step up in features, performance (e.g. simply issuing a database query was over an order of magnitude faster!), reliability and even security – it was easy to find advice for fixing the risky defaults and libraries for common tasks like sanitization.

My guess is that this was either licensed or not considered a core feature and handed off to someone who was already invested in Cold Fusion.

1. e.g. nested loops were broken so for i: for j would repeat j[0] i times rather than correctly iterating the inner loop. The app server tended to leak memory and crash, particularly on non-Windows platforms, and the automatic restart mechanism was completely broken.

Re: Security incident update

#166

Post by darkarmani »

UnoriginalGuy wrote: post #118
corford wrote: post #89

Earlier quoted context omitted.

This is what Caker (founder of Linode IIRC?) has to say about the strength of the passphrase: "our private key is stored only in encrypted format. The passphrase is not guessable, sufficiently long and complex, not based on dictionary words, and not stored anywhere but in our heads." [1] [1] http://blog.linode.com/2013/04/16/security-incident-update/c...

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.

Re: Security incident update

#167

Post by sabat »

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…

The immediate, apparent, utter dishonesty of Linode in this incident had me closing my account yesterday—and watching my credit card's recent activity. It's bad enough that their security was awful; it's so much worse that they're trying to spin the incident instead of being 100% honest about it, and perhaps offering to compensate those who may have been wronged.

Re: Security incident update

#168

Post by jlongster »

I can't believe they don't address the claim that the public and private keys were stored in the same place. It makes me wonder if that's actually true, which knocks my trust down just a little bit more.

Re: Security incident update

#169

Post by sabat »

rjbond3rd wrote: post #146
laumars wrote: post #119

Earlier quoted context omitted.

It's hard to find good Perl developers and even harder to run multi-language libraries for the same online portal (ie same site, domain, database, hosting environment: hardware, OSs....and so on).

I disagree. First, it's hard to find good developers, period. S econd, in general, good developers are hard to find by design (e.g., to avoid recruiters, but also because they are most tof the time already doing interesting work). Lastly, yes, it's hard to find good Perl programmers to do boring work, under boring conditions, at a boring wage. But then that's true of all good developers. Try to find a Rails programme…

Try to find a Rails programmer to remediate crappy code (I've tried).

It's easy to find good Rails programmers, as long as you aren't fixated on them doing facetime.

Re: Security incident update

#170

Post by kijin »

purephase wrote: post #148
facorreia wrote: post #120

Earlier quoted context omitted.

Correct. I wasn't clear, so let me clarify: I regard every PDF I read as a static document. That's how I see them and that's how I read them, with readers that treat them as static. I have no use for a PDF document that wants to acts as software and I wouldn't use a bug-nest of a piece of software to run it.

You're not the target market for those types of PDF's then. In large corporate environments, PDF's are roughly the equivalent of small web-apps that handle a lot of the data entry and sharing across the organization. I'm not a proponent of this approach, but it is what it is and it is the reason that Reader is such a bloated security-ridden nightmare.

Then those features should only be enabled by default in corporate versions of Adobe Reader. Average internet users have very little use for non-static PDFs, except the occasional "fill out this form" PDFs where you can't save any changes.
Post reply on HN