The way these things have been going (client-side vulnerability exploitation), I would suspect that the exploited vulnerabilities were closer to the laptops of Twitter employees than the Twitter application itself.
The blog post mentions turning off Java in your browser, which could be a clue to the attack vector Twitter suffered, and it's written by someone from "Information Security" rather than someone from Application Security.
Great point. I'm sure it's easier to compromise a developer or sysadmin and use that to jump onto the production system, rather than going straight at the main app.
Issue is that you don't know which of the tens of thousands of internal IP addresses would correspond to the one or two sysadmins who would have production access.
Which means either the production servers were hacked or there was a widespread compromise of their internal network and systems e.g. email, IM.
I'm sure more than 2 people at twitter have production access.
And identifying the senior staff isn't probably that hard, they probably have quite visible twitter accounts.
As someone mentioned in a completely different thread, it'd be enough to have a vulnerable rails running on localhost:3000 on your laptop and "accidentally" being hit with a CSRF, for example.
Get a shell on some staffers laptop and stay dormant, I'm sure you'll catch a live ssh session soon enough [with access to that ssh client's process memory] (in fact you'd get quite far just with a copy of the id_rsa + known_hosts files)
Yea you really only need the contents of ~/.ssh and you could access every server the laptop could.
Even if they didn't have production access, a lot of times servers are configured to easily hop from one to another. They could have connected to a development server and then just hopped to the DB server with the accounts it seems they were looking for.
It's useful, but if an attacker got a shell on the dev laptop, I assume he could just coredump the ssh-agent process and steal the unlocked key from there.
I sincerely hope Twitter would know better than to leave those vulnerabilities exposed on any Rails code they're still using. Also, that probably wouldn't count as a "sophisticated" attack in their book...
Attacks are always described as sophisticated in press releases. What do you expect them to say? We were asleep at the wheel and got owned by someone pointing Metasploit on our servers?
