3 ms·

CloudKick.com account takeover.

22 points by adam_baldwin 17y ago

gruseom 17y ago
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 17y ago
  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 17y ago
    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.
- tsally 17y ago
  I'm not employed in the industry, but unless they disclosed to vulnerability to the company before posting the video, it's definitely shady. I'm not so sure companies will respond well to researchers waving around exploits in public and then trying to sell an audit. Surprised and angry people aren't the best consumers.
- tptacek 17y ago
  I've never heard of Adam Baldwin, nGenuity's security person and presumably the impetus behind "evilpacket". He's ex-Symantec consulting; my cofounders cofounded @stake, which is now known as Symantec security consulting, and I don't believe it was ever their practice to make video demos of unpatched vulnerabilities. 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.
polvi 17y ago
(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 17y ago
  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
clemesha 17y ago
"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.
colonelxc 17y ago
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-api-key/ 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?
tptacek 17y ago
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 17y ago
  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 17y ago
    Good on you for posting the apology on your own site.
tptacek 17y ago
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.
adam_baldwin 17y ago
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.

22 points by adam_baldwin 17y ago

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 17y ago
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 17y ago
  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.
tsally 17y ago
I'm not employed in the industry, but unless they disclosed to vulnerability to the company before posting the video, it's definitely shady. I'm not so sure companies will respond well to researchers waving around exploits in public and then trying to sell an audit. Surprised and angry people aren't the best consumers.
tptacek 17y ago
I've never heard of Adam Baldwin, nGenuity's security person and presumably the impetus behind "evilpacket". He's ex-Symantec consulting; my cofounders cofounded @stake, which is now known as Symantec security consulting, and I don't believe it was ever their practice to make video demos of unpatched vulnerabilities. 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.

polvi 17y ago

(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 17y ago
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

clemesha 17y ago

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

colonelxc 17y ago

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-api-key/ 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?

tptacek 17y ago

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 17y ago
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 17y ago
  Good on you for posting the apology on your own site.

tptacek 17y ago

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.

adam_baldwin 17y ago

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.