CloudKick.com account takeover.
evilpacket.net
evilpacket.net
The main issue is that we offer the ability for a user to change their email address. This is a very common feature, and thus something a lot of sites fall victim to. The basic nature of an XSS is that a malicious site can cause you to POST or GET arbitrary URLs. Since cookies are always sent along with the request, if you are authenticated, the attacking site can cause you to hit traditionally protected URLs. This is normally a non-issue, as only your browser reads the content -- the attacking site has no visibility into the data. However, it is an issue when there are side-effects, when the malicious site can change things to their advantage. In this case, they changed the email address to their own via a post. From there, all they had to do was hit the password reset function for their email address.
As soon as we found out about this, we immediately turned off email and password reset. This prevented the XSS from working, as the urls in the attack 404'd. This was a temporary solution.
Next, we now require you to enter your current password when you reset your email. This would also prevent the XSS, as the attacker would need to know the users password. It also prevents against other attacks, such as someone with physical access to your logged in session from resetting your email address with out you knowing.
We also implemented the Django CSRF middleware. This protects the rest of our forms on the site from similar problems.
As for impact, our audit logs show that only the attackers account was compromised for the sake of his demo. Fortunately, he did not randomize the email address used to change the password. If anyone did become a victim to his example, it would not have changed the email to his address (we only allow unique email addresses in the system). However, it is possible this XSS was in "the wild" with other addresses, but according to our logs and the nature of the vulnerability, it is highly unlikely that it impacted any users.
As others mentioned in the comments, it would have been great for the author to contact us before posting this. As motivation to future security researchers, we will happily offer a bounty if you report your bug to us before posting it publicly. In fact, if you're really good -- we'll happily make the bounty a full time job with benefits! :)
If you have any questions or concerns about this issue, please do not hesitate to contact me personally! polvi@cloudkick.com
The attacker, EvilPacket, recommended the wrong thing. They wrote, "The best protection I have seen so far is to use tokens that are time sensitive, tied to the user session and verified when the request is submitted back to the server."
The reason that is wrong is because the attacker can request a new token using the same method it submits a change.
Email and passwords work as challenges as they both cycle through the human being that owns the account, rather than just the browser. it's important to have more than one method that is tied to the account owner because if you want to change one, you need to use the other to confirm.
1. Attacker makes one request. I read EvilPacket to suggest the time-limited challenge is a token stuffed into the cookie. Attacker then waits a few seconds before making the change request with the token safely in the cookie.
You should rather load a challenge in the submit form. I do recommend that for user-generated content.
http://usemod.com/cgi-bin/mb.pl?EditHash
http://www.codecouch.com/2008/10/cross-site-scripting-xss-using-iframes/
At this point, we're "discussing" something on Hacker News that even Wikipedia has right (search for "XSRF"). But if you have to think about how to handle this problem, you're doing it wrong. Use your framework's builtin XSRF protection.
If your page is vulnerable to DOM injection, you have much bigger problems than XSRF.
Also, you know DOM injection is a very common problem. It's better if you don't have to assume the website has no DOM injection problems to do the right thing.
Therefore, I think it is reasonable to recommend asking password confirmation as a general best practice, since it's a straightforward way to be the safest. I'm not sure why you are arguing with that point.
Brian Mastenbrook was hard on 37signals when he found his (much more interesting) XSS filter evasion bug, but even he went to 37s before he posted a website with a video, instructions, and a solicitation for business.
I don't believe that demonstrating to a client or audience using an alert('a') dialog box shows the true potential impact of these vulns. Sure you and I get it, but those outside the industry may not. Many businesses are flocking to the cloud for utility computing and cheap storage and need to be aware that these complex systems are vulnerable too.
As for the other video's on the site and the advisories I have published the vendors were notified first. This again was a mistake on my part. There is not an intention to be purposefully unethical.
1. Go Fix The Email-Form CSRF On Your Site
The exploit that just got dropped on Alex at Cloudkick isn't an XSS attack; it's a CSRF. You're probably CSRF-able if your forms don't include individual hidden tokens that match form submission up to an actual form render. If you don't, anonymous web pages can trick your users into GET'ing and POST'ing to your forms.
What you need to do now is go make sure your email-changing form, in particular, isn't CSRF'able. Because the email form is the CSRF attack that videotapes well. Your password-change form is probably not CSRF'able, because you probably require the user to enter their old password. But the email form doesn't have that protection, and is password-equivalent.
You will probably not fully scrub your site of CSRFs; empirically, we just don't see a lot of non-.NET apps that are fully protected from that attack. But most CSRF attacks are hard to demo effectively, and are low/medium-low severity. So at least get rid of this one.
2. You Need A Security Contact Right Now
Get everyone who can code into a room and draw straws. The loser is the security contact. Route security@yourapp.com to her. Then put up a page that looks like 37signals' security page (maybe with a little less detail for now):
http://37signals.com/security-response
A web app that is a GUI for managing cloud computing instances is NOT "the cloud" - that statement is FUD and/or misinformation.
Does your web app need a security audit? YES. Get your security assessment here <-- links to presumed sales contact form
Can someone who knows the industry comment on this practice? (tptacek?)
He uses a sort of scare tactic to let people see how easy it is to get into some of the sites, it might work well. I bet Cloudkick has this as their top priority now.
On the other hand, I don't know how many companies would want to hire him if he didn't take the time to contact Cloudkick.
To put it another way, to demonstrate the exploit you have to actually conduct the attack. To find the exploit you have to do a PoC. If this was done without explicit permission from the site owner it's legally shaky ground at best and certainly (at least as far as I'm concerned) unethical.
I don't know enough about what's going on here to comment further, but I can say that nGenuity is going to find it hard to keep working with major vendors if they're going to actively screw over other vendors. Maybe that's not what they're doing here though.
To try and combat this I will be including vendor communication logs in the future posts / advisories.
-EvilPacket.
"Web applications are never 100% secure. Also the amount of vulnerabilities previously found in a product does not directly relate to the current state of security in a product or service. A better measure of this is how quickly the company responds and how they care about security related issues." ~ http://www.evilpacket.net/2009/jul/9/theft-rackspace-cloud-a...
Responding to security issues has got to be crucial to these SaaS web apps. If you can't trust a company to at least be diligent in trying to protect your data, why should you give it to them?