Archive for the ‘Non-Technical’ Category

Humble Helps

Sunday, May 23rd, 2010

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.

From: “Ben”
Sent: Friday, January 22, 2010 8:06 PM
To: < *******@opencart.com>
Subject: OpenCart – Enquiry

Hi,

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?

followed immediately by:

On 2010-01-22, at 8:05 PM, Daniel Kerr wrote:
“…your [sic] just wasting my time.”

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.

CCSF CNIT 123 Talk

Sunday, April 18th, 2010

Hi all! I enjoyed sharing a bit of infosec with you on Saturday, and I hope you learned a bit and had some fun.

Here are the slides as a PDF: 200 Milliseconds to Owned

The first “mother may I” exploit was MS06-014. The second demo I did was the more interesting MS10-002, a heap spray used in the Aurora attacks. Symantec has a good writeup.  If you actually want to play with either of these, you’ll find them both in Metasploit. You should have little trouble duplicating the demos on XP virtual machines with IE6, and with a little websearching you can probably find a version of the MS10-002 exploit that will work on Vista and IE7 machines.

The small reversing demo with the serial number checking program was from crackmes.de. Grab a copy of OllyDbg and start poking around.

Happy hacking!

Your Password Policy Tells Me That You Don’t Understand Security

Monday, March 22nd, 2010

How many times have you tried to create a password and discovered that it was too secure for the site?

“Please enter a password consisting of letters and numbers.” What?! This is 2010; there’s no reason any software out there shouldn’t support quotes, backslashes, exclamation points, or even kanji characters in a password. A site that fails to support at least all the printable characters on a modern keyboard is saying something very, very scary about their backend software: “We don’t know how it will react.” Think about that. The developers are so unsure about the quality of the implementation of this standard, well-trodden area of code that they have to have their customers help to make sure it doesn’t break.

Do you really want to do business with a company that isn’t sure it can handle textual passwords? This problem isn’t limited to podunk websites; bank and brokerage sites are implicated particularly frequently in this.

So, next time this happens to you, don’t just click away or grumble and pick a weaker password; send a message to customer service, tell them it’s a problem, and send this article.

If you are a website affected by this:

First of all, thanks for reading. Whether you’re with PR or Engineering, the fact that you’re actually looking into a complaint puts you head and shoulders above a lot of sites.

Here is the question you should ask internally: “Is this a policy decision or a technical one?

If it’s a policy decision, you might be okay. Some organizations decide that special characters are too much for their users to handle: perhaps they result in too much customer support work doing password resets. If that’s the case, please take the time to look at the numbers, gauge your current customer base, and revisit that decision. The typical computer user has matured a lot in the last 5 years and with this change you can easily upgrade your users’ security (and confidence).

If it’s a technical decision, it’s time to start worrying. The user registration and login process is the most clear-cut example of security related code in any system. That entire code path, from the front end GUI to the back end database should have been thoroughly checked, tested, and made absolutely bulletproof. If there’s any doubt in anyone’s mind that the code on this path doesn’t do exactly what it should, that calls the entire rest of the development process into question. The key issue here is input validation, sanitization, and proper practice in isolating code (how your software makes decisions) from data (what it bases those decisions on). If this is done correctly, then there is no technical reason that special characters (indeed, any characters!) cannot be used in passwords. If it’s not done correctly, then the software is vulnerable to a whole class of potent attacks. Specifics of those attacks have been well covered elsewhere but the takeaway needs to be that this single detail may indicate much deeper problems. Looking hard at this issue now may save a great deal of pain and expense later.

Be aware that it might actually be a technical problem even if it’s also codified in policy. This is the most insidious case. What started as a technical limitation “way back when” got papered over with user documentation, and a well-intentioned inquiry gets nowhere. Make sure you push for an answer. If you’re a non-technical person trying to get a clear answer, ask what happens if international users try to use non-English characters in their username or password (Internationalization and Unicode support raise some of the same issues of character sets and separation of code and data). If it wouldn’t work, you’ve got an opportunity to kill a security bird and an internationalization bird with one stone by addressing this issue

Getting Help:

The Open Web Application Security (OWASP) project is a phenomenal resource for anyone wanting to get serious about security. Check out the OWASP Top 10 for a quick view of the kinds of vulnerabilities that exist in software, and what practices fix them (a short overview video; poor sound, good explanation).

Wall Of Shame:

(This is a starter collection based on polling a few friends, I’m sure there are hundreds more. Leave a comment if you have others, or if any of these have fixed it)

Capital One
Aetna
GoDaddy
Fidelity
Smith Barney
Verizon
Digg
StumbleUpon
Mvelopes.com
Wells Fargo (toLowerCase()?)
Progressive.com (Only special chars are @.-_)
GoGo Inflight Wifi
ADP.com