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

151–160 of 282 posts

Re: Security incident update

#151

Post by trebor »

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…

And for exactly that reason I've had my credit card reissued as well, even though no fraudulent charges have been made. The risk is just too great for me to feel safe with the old credit card number.

Edit: Fixed spelling mistake.

Re: Security incident update

#152

Post by joeyh »

corford wrote: post #91
dchest wrote: post #35

Earlier quoted context omitted.

"There were occurrences of Lish passwords in clear text in our database."

Also (and correct me if my understanding of this is wrong since I've never used it), LISH is just a remote terminal service. You still need to know the VM's root password. And frankly, if you're doing it right, the root password should be a long, unique random string that you store somewhere safe and never use since you should be using keys to login to your box on a day to day basis.

It's quite likely that someone has left root logged in on hvc0 (the LISH console) on their Linode, while logging out of LISH. Probably more than one person.

Also, access to LISH even without a root password provides access to some scrollback output, which could expose sensitive information.

Also, LISH allows multiple connections, all of which see the same console, so the attacker can just connect to it and wait for a root prompt to appear when root logs in next. (Does changing the LISH password prevent this attack if they're already connected? I doubt it.)

Also, most distribution boot processes can be messed with at boot from the console. For example, you can ctrl-c to stop important daemons from loading. In some cases you may be able to get a shell without the root password.

Also, Magic SysRq can be accessed over a serial console by sending a BRK. You do not need to be logged in to do this, and it could be used to kill processes, reboot, etc. I don't know if LISH allows sending BRK.

Re: Security incident update

#153

Post by [deleted] »

tbatterii wrote: post #132
rjknight wrote: post #90

Earlier quoted context omitted.

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…

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

[deleted]

Re: Security incident update

#154

Post by codeulike »

zorbo wrote: post #135
codeulike wrote: post #86

Earlier quoted context omitted.

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.

Not all exploits are zero-day exploits. As I understand it, a zero-day exploit is one that is used in the wild before it is disclosed. Plenty (most) vulnerabilities are only disclosed once a fix has been implemented.

I stand corrected

Re: Security incident update

#155

Post by 127001brewer »

porker wrote: post #133
mosburger wrote: post #123

Earlier quoted context omitted.

There was a heck of a lot of Java out there used for web development around that time. But your point still stands - Java probably would've been a lot more difficult to setup and maintain than CF.

Although if I remember rightly it wasn't in 2004, isn't CF now Java-powered under the surface?

Yes, ColdFusion is now Java-powered:

"With the release of ColdFusion MX 6.0, the engine had been re-written in Java and supported its own runtime environment, which was easily replaced through its configuration options with the runtime environment from Sun. Version 6.1 included the ability to code and debug Shockwave Flash." [0]

[0] http://en.wikipedia.org/wiki/Adobe_ColdFusion#Other_features

Re: Security incident update

#156

Post by joeyh »

gingerlime wrote: post #25
JonnieCache wrote: post #14

Earlier quoted context omitted.

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.

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

Re: Security incident update

#157

Post by jtolj »

joeyh wrote: post #152
corford wrote: post #91

Earlier quoted context omitted.

Also (and correct me if my understanding of this is wrong since I've never used it), LISH is just a remote terminal service. You still need to know the VM's root password. And frankly, if you're doing it right, the root password should be a long, unique random string that you store somewhere safe and never use since you should be using keys to login to your box on a day to day basis.

It's quite likely that someone has left root logged in on hvc0 (the LISH console) on their Linode, while logging out of LISH. Probably more than one person. Also, access to LISH even without a root password provides access to some scrollback output, which could expose sensitive information. Also, LISH allows multiple connections, all of which see the same console, so the attacker can just connect to it and wait for a…

Shoot, you are correct. Definitely an attack vector.

The connection is to the same TTY when I log in via the web terminal and SSH at the same time, so if you are logged in via LISH anyone with the LISH password has access to the logged in user's console + scrollback.

I wasn't able to send BRK from Putty though.

Re: Security incident update

#158

Post by andyhmltn »

ciaron wrote: post #60
jpallen wrote: post #5

I know Linode has been getting hammered for not being trustable or that they don't respond well when contacted, but in my experience they have been extremely responsive to any issues I have raised. I don't just mean technical issues either, we had what looked like a security breach on our account and it kicked of a small frenzy in their support staff and supervisory team to track down the problem. They figured out wh…

I can second this - Linode has always responded quickly and effectively in my experience.

I third this. I've never had a problem. Most of my tickets have a response within 10 minutes and they always seem to have been open when anything has gone wrong on their end. Is anyone not thinking that the reason they didn't come out in public talking about this until now is because law enforcement was involved? Notifying the public could ruin the investigation.

Re: Security incident update

#159

Post by andyhmltn »

threeseed wrote: post #65
ultimoo wrote: post #8

The update has quite a frank and an apologetic tone to it. Especially the concluding paragraph gives it a very empathetic touch. It must be truly tough for the ops folk at Linode to have suffered an attack due to a third party 0-Day exploit. It could happen to any of us really. On a side note, I am not sure of the "some occurrences of plaintext Lish passwords". Seems like quite a goofup on Linode's part.

Sorry but having passwords in plaintext is not a "goofup". It is completely and utterly inexcusable.

A) It wasn't account passwords. It was LISH (no better but I thought I'd point that out) B) Not all passwords were in plaintext C) Judging from the above, I would say that there was some stuff up where passwords were written to the logs when they were changed but that's just speculation.

Re: Security incident update

#160

Post by Confusion »

threeseed wrote: post #113
Confusion wrote: post #87

Earlier quoted context omitted.

Wouldn't you rather have them working on assessing, containing and repairing the damage rather than catering to the impatient internet crowd that is so used to immediate updates on everything that they can't fathom putting together a responsible, useful, correct response might actually take a while? Honestly, these people don't understand what it takes to run a company and handle such an incident. As far as i'm conce…

I don't understand where you are coming from here. Why do you think companies can only do one thing at a time ? And where have you worked where software engineers are drafting press releases or conducting security audits ? And why shouldn't keeping customers (who have their own apps) informed be their top priority ?

  Why do you think companies can only do one thing at a time?
Amdahl's law. Recovering from a catastrophic hack isn't parallellizable. Nobody can draft a press release before the security audit has been performed. You can't inform anyone before the security audit has been performed. The software engineers can't go to work before certain parts of the security audits have been performed. Certain parts of the security audit can't be performed before other parts have been performed.

  And where have you worked where software engineers are 
  drafting press releases or conducting security audits?
A bootstrapped startup? Depending on the scale of the company (and I have no clue how many people work at Linode), the work may be sequential simply by lack of manpower.
Post reply on HN