I just ran across a post at PreachSecurity about a recent CSRF discovered in OpenCart, and a blog post by the discoverer about his interactions with the maintainer. I share Rafal’s (and Ben’s) frustration with the interaction, but I think there’s an additional lesson to be learned here. Clearly this was a loss for the cause of security, but I think it was a loss in more ways than many of the participants see.

Ben didn’t just lose the battle to get one bug fixed, he also lost an ally in the fight. Daniel (of OpenCart) was and still is in the best position to make small changes to vastly improve the security of OpenCart for all users, but after a public browbeating what are the chances he’ll be willing to get help from security folks? That’s the critical part.

The bug by bug approach to information security is trench warfare: it will take us too many years and too many lives (or at least careers) to gain ten feet of mutilated ground. We need people and practices on our side, and “wins” in security should be measured in those terms, not just in bug counts.

Yes, we as security people often have to tell people that some code or process or idea is absolutely wrong. But to say those things without destroying the human capital we desperately need, we must do it with an overabundance of patience, humility, goodwill, and tact.

I think Ben did a reasonable job of trying to be respectful and helpful, but there was something jarring in it for me.

I recently installed OpenCart and I noticed that it is vulnerable to CSRF attacks. I have created a sample page that is capable of inserting a rouge user (the page currently prompts you but could be done silently if the attacker knows the url of the site).

http://visionsource.org/*********.html

Please let know that you are looking into the security issue and are going to release an update with a fix otherwise I will make the issue public.

If you need any help fixing the problem please let me know.

Thanks,
Ben.

See it? “…otherwise I will make the issue public.” Now, as a security person that may not seem hugely disconcerting; we know that when the carrot of coordinated disclosure fails, the stick of public disclosure can get results. However, put yourself in Daniel’s position: he just got threatened. Reread the email, and think honestly about whether anything else constructive that Ben said will have as much of an influence on Daniel as the mere feeling that he’s being bullied.

So, Daniel gets a lot of emails from people that misunderstand some code, and he sends back a quick response (on a Friday evening no less):

On 2010-01-22, at 4:50 PM, Daniel Kerr wrote: Ben you seem to be very clever to come up with this. But! you need to be logged in for this to happen.

So, clearly he didn’t get it. Amazingly, he still seems to be receptive to Ben. On the technical side, he may not even have checked out the PoC Ben provided. Ben responds with a lot of good information. It’s a technically accurate and helpful response for someone who is ready to learn about CSRF, but this is how he leads off:

HI Daniel, That is the whole point of a CSRF attack. Please read http://en.wikipedia.org/wiki/Csrf for an explanation on the attack.

Ouch. I’m sure it wasn’t Ben’s intent (or maybe he was just frustrated; understandable), but that line right there is going to put Daniel in defense mode. It’s subtle, but it’s an “I’m right, you’re wrong” moment. Even if Ben is right (he is), anyone’s ego would step in and interrupt rational thought right there.

Imagine if the second email had been even more patient and humble.

Hi Daniel, Yes, you’re right that it requires the OpenCart to be logged in, but CSRF really is a commonly used attack, and it can be very dangerous <<insert Ben’s other paragrahs here; they’re a great description of how CSRF could be exploited.>>

There’s more good information on wikipedia [link], and there’s actually a pretty straightforward fix that can eliminate CSRF vulnerabilities [link to owasp CSRF page, or whatever you like]. I’ve attached some files that fix these vulns, and added some anti-CSRF functionality to the URL class to make it easy to clean up any other cases.

Instead, things kinda spiral downward. It ends with:

On 2010-01-22, at 8:05 PM, Daniel Kerr wrote: what protection do you recommend?

Communication is no longer occurring. We as security people must take the responsibility to prevent that. What if, at the moment that things were spiraling downhill, Ben had sent an email like.

Hi Daniel, I hear your frustration with trying to protect users from doing dumb stuff, and I agree there’s no way to fix all the stupid things they could do, but at least CSRF is one type of attack that we can stop cold. If you have ten minutes, I’d love to talk about why I think it’s really important, and how some protections could be added to OpenCart without too much effort.

My phone number is 555-555-1212: call me any time, or let me know if there’s a good time to call you.

Yes, I know it’s crazy. It’s over the top, it’s above and beyond the call of duty, and it’s kinda weird: use the telephone… really? But that might, just might, have helped Ben win not just the battle over a single bug, but might have won an ally in the security of an entire application, and gained the cause of security goodwill in the bargain.

I’m not saying that there aren’t complete, incorrigible, asshat people out there, or that killing them with kindness is any kind of panacea. Ultimately, Ben may not have been able to make progress even if he was a genetic hybrid of Mother Teresa and Bruce Schneier. What I am saying is that we too often forget that real security comes from the people, not just the code.

So, when you find yourself in a situation like Ben, please consider digging deep into your well of patience and giving a bit more when you’re tempted to give less.

It’s not only OpenCart, even “big” some vendors *cough* microsoft *cough* ignore some reports and such.
And IMHO the only way to deal with security-by-obscurity vendors is publishing vulnerabilities [after a note/letter/email].

Interesting perspective … I do see both sides of it . The escalation into the 5-year-old playground mentality when the developer (purposely?) breaks the patch is just stupid though. I’m not sure I could believe attributing that to the early offensive take by Ben.

i agree with having tact and being cognizant of others feelings (especially developers–it is their baby you are beating up on). BUT if you sell a product and have customers especially when processing payments is involved the developer may need to swallow some pride when confronted with a security issue, you owe it to your customers who paid for your product.

Daniel should be happy that Ben even sent him an email about the problem before going public or blogging on it. The lack of knowledge about basic web attacks also means that the opencart team should probably spend some time on the OWASP site.

Thanks for commenting. Yes, I’m with you guys; I think Ben did a good thing, and actually did go above and beyond (further than I’d probably have gone before authoring this post). With the post I was just trying to think about how far beyond one would have to go to get through to the truly truculent.

Ali,
Yup; public disclosure always has to be on the table in our minds, but there’s no need to whip it out in the first email.

Rafal,
The patch-breaking behavior just does it for me: that’s beyond ridiculous, though it does show that ego is in play 😉 I think that probably vindicates Ben that nothing would have made the difference, but my post was a bit of a thought experiment anyway.

I can’t help but think about the Dale Carnegie book “How to win friends and influence”.

If Ben’s goal was to get the CSRF issue, fixed then really he needs to change his approach. Each one of the 12 items below can apply.

Twelve Ways to Win People to Your Way of Thinking
1. Avoid arguments.
2. Show respect for the other person’s opinions. Never tell someone they are wrong.
3. If you’re wrong, admit it quickly and emphatically.
4. Begin in a friendly way.
5. Start with questions the other person will answer yes to.
6. Let the other person do the talking.
7. Let the other person feel the idea is his/hers.
8. Try honestly to see things from the other person’s point of view.
9. Sympathize with the other person.
10. Appeal to noble motives.
11. Dramatize your ideas.
12. Throw down a challenge & don’t talk negative when the person is absent, talk about only positive.

So much of what we do as security professional requires this. I’m sure the majority of technical people feel their systems are secure. Who wants to admit they don’t understand what they are doing? Who wants to be told they screwed up? There is a better way.

We have to be influential in our approach. Showing respect and being friendly are always important.

Excellent post. I agree completely that consulting skills are important during a negotiation on something so sensitive as vulnerability disclosure. I would note that the product vendor also has something to learn here.