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.