[part 1 in a series of 5 video write-ups from our BlackHat 09 talk, summary here]

Goal

We wanted to demonstrate how access to cloud resources can bring certain attack classes within reach of regular users. Instead of focusing on brute-forcing regular user credentials such as usernames and passwords, we decided to look at less noisy options since failed logins would typically be a closely watched metric.

To this end, different types of session identifiers were examined. The thinking was that by bruting session IDs instead of credentials the monitoring systems might be less likely to pickup the attack, and the cloud gives the attacker vast amounts of bandwidth and processing power that was not previously available. However even with access to cloud resources, most “strong” session IDs would still be large enough to avoid this attack (think 128-bit sessions such as those stored in ASP.NET cookies).

Of course, authentication tokens are not necessarily only stored in session carriers such as cookies/urls/hidden fields. A number of sites use a randomly generated link to effect a password reset, and if these random links can be brute-forced then the attacker still gains access to the account.

Thus, in the following set of videos we show how an attacker can generate a huge number of password reset links on the one hand, each of which is valid for the target account (he doesn’t get to see the links). The final step would be to randomly guess links until one is hit (left as an exercise to the reader).

Background

SugarSync is a cloud storage provider nestled in the Infrastructure-as-a-Service layer of the cloud model.

Users can sign-up for free trial accounts and upload/store/share files via the web interface, which is where authentication is handled. There were also client-side options, but we didn’t examine these.

Video 1

Here we show how the password reset process works for SugarSync.

1. The first part of the vid hints at the services promised by SugarSync: it’s global, secure and has mobile integration.
2. In order to reset a password, we need the username to target (i.e. an email address). Of minor interest: there is a username enumeration vulnerability in at this point in the process as we’re informed if the email address is not on file. Therefore we can quite easily guess usernames for a target until we get it right and then proceed with the rest of the attack below.
3. Once we have a username, we enter it into the reset form and submit. On the bottom left of the video we see the Growl notification for a new mail.
4. We open the mail in Mutt (yay!) and extract the link.
5. Open the link in a browser.

The process is quite a common one and simple to boot, however the link that gets sent uses a secret identifier similar to “for472gtb422”, which isn’t very long.

Video 2

The next video is short, and shows the execution of a Python script that submits many password reset requests for a single account.

Video 3

The final SugarSync video shows the masses of reset emails that were sent to the user.

Two items were of interest:

1. Each link was valid even though they all reset the password on a single account. In other words, rather than permitting at most 5 reset links per account, the account literally had thousands.
2. The links were still valid two weeks later.

What this means is that we can submit hundreds of thousands of reset requests (each of which is live), and we have many days in which to randomly request links with reset tokens, in order to stumble across the account.

Conclusion

The cloud gives us access to vast resources in terms of bandwidth and processing power and this brings within reach different brute-force attacks than simply password guessing. Where random tokens are used and the token’s space is not large enough, we can also try guessing the tokens since this is more likely to not trip up alarms.