If you were paying attention the last few days, you’ve probably read about the wave of attacks launched against the popular Twitter service. It started over the weekend, with a series of phishing attacks sent to unsuspecting Twittizens via Direct Message. Then, on Monday morning, Fox News announced Bill O’Riley (sic) was gay, CNN anchor Rick Sanchez tweeted that he was high on crack, and the Barack Obama transition team decided to raise a few bucks using affiliate referral links to survey websites. All told, 33 celebrity accounts were compromiwsed before Twitter caught on and took control of the hacked accounts.
Naturally, people wanted to know how it was done. A Twitter blog entry provided some vague detail:
The issue with these 33 accounts is different from the Phishing scam aimed at Twitter users this weekend. These accounts were compromised by an individual who hacked into some of the tools our support team uses to help people do things like edit the email address associated with their Twitter account when they can’t remember or get stuck.
What’s interesting about that paragraph is that the celebrity account hacks were not related to the phishing attacks, as one might assume, and they had nothing to do with an exploitable vulnerability in the Twitter app itself. Just a case of somebody getting hold of an admin account. Ho-hum.
Tonight, the “hacker” explained to Wired Magazine how he did it. I’ll try to summarize the attack, but you might have to read it several times because it’s subtle and complicated. Ready? Brace yourself… He used a dictionary attack to brute force a password.
Continue reading here after you’ve picked yourself up off the floor. Here’s the money quote:
The hacker, who goes by the handle GMZ, told Threat Level on Tuesday he gained entry to Twitter’s administrative control panel by pointing an automated password-guesser at a popular user’s account. The user turned out to be a member of Twitter’s support staff, who’d chosen the weak password “happiness.”
Now let’s consider the application security best practices that Twitter could have followed when designing their service, any of which would have foiled the attack.
- Password complexity. In case you were wondering, the only restriction on Twitter passwords is a minimum length of six characters. No mixed case, no numbers, no special characters, none of that. Although they do encourage you to “Be tricky!”
- Brute-force protections. Clearly there’s no account lockout mechanism, unless of course “happiness” was at the top of the word list. While there is no perfect solution to brute force attacks, it would appear Twitter didn’t even try.
- Segregation of administrative functionality. I won’t underestimate the amount of effort required to segregate the admin interface. That being said, the attack would’ve failed if Twitter admins had to perform privileged functions via a dedicated internal interface.
Any others? Leave them in the comments.
In all fairness, it’s hard to make security a top priority in ANY company, much less a startup with overworked non-security-aware developers using an agile methodology with tight iterations (making some educated guesses here about Twitter). Ideally you want to start prioritizing security before you become an attractive target. Twitter missed the boat on that one, but I bet they’re paying attention now.
Veracode Security Solutions
Static Code Analysis
Vulnerability Scanning Tools
Web Application Security
Software Testing Tools
Source Code Security Analyzer
Software Code Security
Source Code Analysis