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.
This is likely about Twitter getting creepy. Every online advertising company is worried about the growth of the mobile environment, because it's harder to do all of the tracking that they're used to on those platforms. There are no cookies that follow you across apps.
The cookie equivalent in the mobile world is the SDK. Rather than scattering your "like"/"tweet"/"follow" buttons all over the web to track users' movements, you embed your SDK into everyone's apps to do the same thing.
If you are currently a Crashlytics customer, think about how much information is being transmitted to Crashlytics from your app, and what Twitter is going to be able to do with that now.
Interesting thought. Any idea how many apps use Crashlytics? There's lots of value in knowing what potential competitor numbers are or even for other strategic reasons.
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.