Skip to main content

The Conflicting Incentives at the heart of the Twitter breach

(0 comments)

Techcrunch has a detailed post on how Hacker Croll broke into Twitter.  Read the whole article. Here is a summary of the attack:

1. HC accessed Gmail for a Twitter employee by using the password recovery feature that sends a reset link to a secondary email. In this case the secondary email was an expired Hotmail account, he simply registered it, clicked the link and reset the password. Gmail was then owned.

2. HC then read emails to guess what the original Gmail password was successfully and reset the password so the Twitter employee would not notice the account had changed.
HC then used the same password to access the employee’s Twitter email on Google Apps for your domain, getting access to a gold mine of sensitive company information from emails and, particularly, email attachments.

3. HC then used this information along with additional password guesses and resets to take control of other Twitter employee personal and work emails.

4. HC then used the same username/password combinations and password reset features to access AT&T, MobileMe, Amazon and iTunes, among other services. A security hole in iTunes gave HC access to full credit card information in clear text. HC now also had control of Twitter’s domain names at GoDaddy.

This attack is fascinating because it shows how attackers can exploit the economic incentives of service providers that have a huge number of users. The more users a service has, the more likely that even small events can create huge costs.  The small event in this case is the need to reset a password.  The total potential cost of resetting a password is huge when the cost of a helpdesk call is multiplied by millions, so these service automate the password reset with something that is quite simple and not very secure. 

Combine this with the fact that all web services require a username and password and now users have too many passwords to remember.  They re-use the same passwords on multiple services, both personal and corporate. 

Twitter just happens to be one of a number of a new breed of companies where almost the entire business exists online. Each of these employees, as part of their work, share data with other employees - be it through a feature of a particular application or simply through email. As these users become interwoven, it adds a whole new attack vector whereby the weak point in the chain is no longer just the weakest application - it is the weakest application used by the weakest user.

So, the attack becomes a search for that weakest user and the more a company relies on web-based services the more likely the attack will be successful. 

The article points out the conflict, but substitutes 'usability' for ' the fact that Google has no helpdesk support':

In an effort to balance usability with security, Gmail offered a hint as to which account the email to reset the password was being sent to, in case the user required a gentle reminder. In this case the obfuscated pointer to the location of the secondary email account was ******@h******.com. The natural best guess was that the secondary email account was hosted at hotmail.com.

We seen this with cell carriers and SMS more than once.  The large companies cannot afford to make it too hard to reset your password or the helpdesk calls would be prohibitively expensive. Croll was then able to guess the hotmail address, which was no longer active, sign up for it and get the new google password.  He was able to change the Gmail password back to the original by searching the gmail account for a password reset mail and, of course, the user reused the same password for a number of sites.

While OpenID and it's kith and kin are attempting to reduce the number of passwords a user needs, they will NOT solve this issue for corporations using Cloud services. 

Luckily, Google provides corporations with a solution for Google Apps Enterprise Edition.  You can use SAML/SSO to maintain control of the keys to your Cloud Kingdom

 

Currently unrated

Comments

There are currently no comments

New Comment

required

required (not published)

optional

Recent Posts

Archive

2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008

Categories

Tags

Authors

Feeds

RSS / Atom