Monday, July 05, 2010

Full Disclosure, Reverse Responsible Disclosure and Bob

Hey!

I know I haven't posted for a long time, sorry.. I hope I still have some followers.

Today was an interesting day, I started the day with yet-another-xss on some social website, and I found a vulnerability (kinda lame) on Paypal, later on the day I met my girlfriend's parents, and now it's late, so I'm writing a blogpost.. One vulnerability report was done on a 'responsible way', and the other, on what I just called 'reverse responsible disclosure'.. I like to invent buzzwords (and they are all jokes, please don't use them on real life).

I do think responsible disclosure is important, mostly because giving advance notice to the vendor allows them to work on a fix, before the bad guys start exploiting it. That's what I've been using, and what I think is the right thing to do. However, this is something that, depends on the vendor as much as on the researcher.

I've been working with several vendors on fixing vulnerabilities, most notably Microsoft and Google, both (in my opinion) do work hard to fix stuff, Microsoft takes considerably a lot more time to fix stuff, but they do communicate with me, letting me know what they are doing, and also share their ideas of fixes with me, in case I have any opinions (and they do take them into consideration). This dialog, or a swift and fast fix of vulnerabilities (like today's youtube's XSS that was full disclosed but apparently fixed fast enough) is what I consider a responsible response from the vendor.. I know this is not an opinion shared between all the industry, and that the loooooooong patching cycles of Microsoft are largely criticised, but in general, they are not so bad apart from that.

Other vendors that work similarly are Adobe and Symantec (humm, except for this girl that seems to have a job she shouldn't), and I was happy to work with them as well.

Now, the bad guys..

SMF (simplemachines.org)

While their developers seem to understand security vulnerabilities, their PM is probably living in the stone age.

Some time ago, elhacker.net, a security community I'm member of, created a project to make a security audit of SMF 2.0 before using it. It was great, the project found around 45 vulnerabilities, half of them serious, and they were mostly fixed (not all of them, but most of them were). The change log included credits and all, so it was great, and we declared the project as a success.

However, a few months later, the PM of SMF asked google to close our project page, because we were 'violating their license', thing that Google had to comply with. I had to remove the comments on the code, and the patches, code reviews, and repositories, so Google could re enable the project page (http://smf2-review.googlecode.com/).

Overall, this sucks. We did the project to help them, and we did asked them BEFORE if the way we were going to work was correct, I even sent an email asking for permission to redistribute their code with patches, but since I had no response, I decided to just mirror it for code reviews, but don't modify it. They keep on saying it's their right to protect their code, and etc.. but I really do think they acted wrong by not notifying us first.. (they had our contact email, and we interchanged a LOT of emails) when we did them a favor.

In the future, I don't recommend working with them, if you don't want to be stabbed on your back. I do think this response was very lame on their part.

OpenCart

Some of you may know Daniel Kerr, the developer of Open Cart, that thinks that Paypal, Google and Yahoo are always vulnerable to CSRF, and that an antivirus would stop CSRF attacks (thing that made more than one person laugh for a while). Someone already had a media circus with this guy, (he actually savotaged the security patches that another guy did because he refused to fix them). But now I will talk about something else.

A good friend, WHK is a skilled developer, that does security auditories as a hobby, he is known for finding stuff in several popular CMS and he found a couple of vulnerabilities in OpenCart, so he documented them. Overall, there are Local File Inclusion vulnerabilities, direct remote code execution, and yet another CSRF vulnerability that allows an attacker to take complete compromise of the server. His english is not very good so he asked me to contact the developer, which I did. My email was saying that WHK and a few other users where going to make a free auditory of OpenCart, and that he will get notified before making the new vulnerabilities public.

His response was:

I prefer if you mind your own business and not bother me or the opencart community. The exploit that is being discussed will be fixed in the next release. I don't need your services. Stop wasting my time.

Stop bothering me!

So, we did stopped bothering him since then, and now there are a total of 14 vulnerabilities. This vulnerabilities are now private, because we think he won't fix them if we make them public (as he hasn't fixed the first ones). And we can't make them public, because thousands of users use OpenCart and they actually manage security sensitive information. (In this case I don't think full disclosure will work).

Knowing that Daniel Kerr has a bad history even with fully disclosed vulnerabilities, we are clueless on what to do. The best thing may be to urge everyone to stop using OpenCart as soon as possible.

Paypal

So, paypal help center was vulnerable to a XSS for over 1 year, with a vulnerabilty that I reported to them 3 years ago.. and was only fixed because someone posted it on xssed.org (http://xssed.org/mirror/34771/). Since then, I felt it was not worth privately reporting stuff to them. But actually I didn't find any other vulnerabilities on paypal until recently.

So, today I found one, that is actually not really dangerous, requires the victim to be logged in on a place they probably wont be logged in.. And since full disclosure seems to be the only way to catch their attention, I did it.. and twitted about a clickjacking attack that allows you to send money to your account from a victim with 2 clicks.

https://twitter.com/sirdarckcat/status/17738238439

Anyway, I don't think this can be abused in real life, but I do think it should be fixed, so after posting it on twitter, I waited a few hours and then reported it to paypal with a few suggestions on how to fix it. This is what I called reverse responsible disclosure.

What about Bob?


Well, I did found a XSS in a popular social network! but since they behaved cool in the past, I decided to report it privately, and let them fix it.. I may make it public when its fixed, but I don't think it's interesting enough (it's on the search engine.. They made a new version and missed to check for <> in JS strings).

So.. that's pretty much all.

What I think will happen now


1. The SMF guys will react and write me an email/comment/blogpost saying how an evil and unreasonable man I am.
2. Daniel Kerr from OpenCart will probably start trolling about this on email/his forum, without fixing any vulnerabilities whatsoever.
3. Paypal will fix this vulnerabilities, and say I was a bad guy.
4. Bob will fix the bug.

Soooo, that's all, I was really biting my tong on the opencart/smf responses.. And I am happy that I finally found a time to write about it.

And this is not intended to be used in the famous disclosure debate, or similar, is just a catharsis after dealing with this couple of lame vendors (except for bob, bob is cool, hi bob!).

Thanks for reading..

PS. I just noticed AdSense is showing Paypal ads on my site.. lol, that reminded me when the caesars palace twitter account retweeted how to hack their own wireless network.

7 comments:

  1. Daniel definitely deserves Pwnie award. I also had experience in contacting with him, response was somehow in his manner. Maybe, if you own OpenCart site, then he would listen to you, as in my case ;) Seems that such 'hardcore' guys requires the same evidence provision strategy.

    ReplyDelete
  2. congrats for "meeting the parents" and feel free to report bugs on our sites :) yk from China

    ReplyDelete
  3. not sure what this post is supposed to accomplish except say look at me i found vulns but im not reporting to vendor or to th public. lame.

    opencart has already made it clear they dont give a crap. if you really "care" about their users then you drop the vulns either force opencart to start giving a crap or reinforce to their users (by releasing details) to find different software. sitting on vulns and neither reporting them to the vendor or the public doesnt accomplish anything. FD isnt just for vendors in some cases its the only way people know they are running crap software.

    ReplyDelete
  4. Why not posting it on secunia or something like that? Since you just mentioned that there's problem in OpenCart and since the Four Horsemen of the Apocalypse are there in the wild Knowing that there's Problem and Looking. And they will not rest until they'll hack into innocent people lives.

    * * *

    Reverse Responsible Disclosure - love the term!

    * * *

    I'm "sitting on vulns" personally, not yet sure what I should do with them. Contact vendors? Go for secunia (it's just that I don't know others, I'm not affiliated ;)? Try to sell? Tweet 'em? Any suggestions welcome!

    ReplyDelete
  5. They are not my vulns to decide how to publish them.

    ReplyDelete
  6. I've recently had funny conversation with jCart creator about http://www.exploit-db.com/exploits/15171. On its website there was an email to contact, but my email with vulns description got to Spam folder :) Till I pointed him to the fact I've sent email, he was sure I'm a bad guy

    ReplyDelete
  7. If you were to publicly disclose the vulnerabilities in OpenCart, wouldn't the site owners at least be able to attempt to fix it themselves? I mean, it is PHP/MySQL isn't it?

    ReplyDelete