

CloudKick.com account takeover. - adam_baldwin
http://www.evilpacket.net/2009/sep/16/cloudkick-account-takeover/

======
polvi
(Alex from Cloudkick) This XSS is no longer valid. Thank you for the bug
report. This was definitely a mistake on our end, and we deeply apologize for
the error. Will post another report shortly...

~~~
polvi
Wanted to give an update explaining what happened and how we fixed it.

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

~~~
sunir
I just want to highlight that Cloudkick did the _right_ thing and required
password confirmation to change the email address.

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.

~~~
tptacek
The attacker _cannot_ get a new challenge, because in a CSRF attack the
attacker never got to see the challenge to begin with. CSRFs are blind drive-
by attacks.

~~~
sunir
Two possible failures:

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
    

2\. However, if this page is vulnerable to HTML injection, you can get the
hash back by embedding Javascript that creates another iframe or img back to
yourself on the attacked page.

    
    
        http://www.codecouch.com/2008/10/cross-site-scripting-xss-using-iframes/
    

So, I just find it safer to ask for the user's password.

~~~
adam_baldwin
You are absolutely right here. I guess I want to point out that I was not
wrong but simply vague (I guess I need to have a bit more peer review on these
things). I never said to put it in the cookie, I did say session (I meant
server side).

~~~
sunir
Just to be clear to the readers, putting the token in the session has the same
vulnerability. If you're going to use a token, put it in the form.

------
tptacek
Are these guys really dropping zero-day on production web apps to solicit new
business, or are they just not telling us that they've first gotten them
resolved with the vendor?

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.

~~~
adam_baldwin
Thomas, I believe in responsible disclosure, but mistakes happen and I have
apologized to CloudKick with a personal email and here in the comments. The
intention of evilpacket.net is to educate on the true impact of low hanging
fruit.

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.

~~~
tptacek
Good on you for posting the apology on your own site.

------
tptacek
Hey, let me give you all two quick pieces of advice for your startups, while
security again has your attention.

 _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
    

This costs you literally nothing, makes it clear when you're getting douched
over by consultants, and makes it easy for reputable security people (ie, most
of us) to submit vulnerabilities to you.

------
clemesha
"It still makes me chuckle that the cloud is supposed to be this amazing thing
and yet simple XSS and CSRF attacks and pwn the daylights out of it."

A web app that is a GUI for managing cloud computing instances is NOT "the
cloud" - that statement is FUD and/or misinformation.

------
gruseom
This seems dodgy to me on a post of this nature:

 _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?)

~~~
bittersweet
In my opinion this is a bit like finding a exploit in a site and contacting
the company and publishing it later. It certainly is more flashier then
reading a .txt.

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.

~~~
iuguy
I work in the industry and if what has happened is that the site requested a
test from them and was happy for them to publish this then yes I guess it's
appropriate, but I wouldn't really do it as it associates the firm with
hacking live sites.

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.

------
adam_baldwin
So I need to apologize to CloudKick for dropping this on them without notice.
It was not my intention and it was not my intention to surprise them with
this. I have a laundry list of vulns that I'm trying to get organized and
communication with vendors is probably the hardest part. Many of them don't
respond. Ever. Again this was my mistake.

To try and combat this I will be including vendor communication logs in the
future posts / advisories.

-EvilPacket.

------
colonelxc
I think the submitter himself said it well in his Rackspace XSS hack:

"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...](http://www.evilpacket.net/2009/jul/9/theft-rackspace-cloud-api-
key/)

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?

