Well it came and went without much fanfare, but November 14th was World Usability Day (there are some amusing posters at on this link). The first user comment on that blog post is pretty amusing too as it is being sponsored by SAP who apparently the commenter has issues with. Okay, so what does this mean for us in the security world? Here are RSnake’s tenants of security usability:

1) Don’t ask the user to change their password every 30 days and never recycle their password and never use anything that even vaguely resembles something a human could actually remember and then get upset when they write their password down on a sticky note or store it in a automatic form submission program.

2) Don’t tell users that they are “hacker safe” when they aren’t. Guess what, bad guys can make fake graphics that say the same thing about their phishing sites and your site isn’t safe anyway.

3) Don’t force users to install software from a website. The bad guys do the exact same thing and trust me, they aren’t as nice as you are.

4) Don’t rely on users remembering to carry a one time key fob with them every time they want to use your e-commerce site. People put them on keyrings, lend them to other people, loose them, or otherwise break them. That and everyone else is making them do the same thing. Now they have 50 fobs, and they have to remember which to use for what website. Here’s a clue, we’ve seen users who don’t know if the number they are supposed to type in is the one that changes or the serial number on the back. Yes, consumers are that helpless.

5) Don’t ship products that require other products to secure them.

6) Don’t launch an education program that is designed to stop fraud by x%. It’s not going to. Get over it. All you’re doing is wasting the user’s time. They’ll still get phished. If you stopped spending the money on education and fix your broken system you wouldn’t need to do education programs that no one will read.

7) Don’t make crazy elaborate password setups where people have to use their mouse to punch in random numbers on a keypad after remembering some algorithm in their head. Do I really need to explain why?

Don’t expect users to keep their machines up to date with patches. They hate that annoying popup window when they’re playing solitaire.

9) Don’t expect users to make configuration changes to their browser to protect themselves from your poorly designed web-application. They barely know how to click the “internet icon thingy” without their head exploding.

10) and lastly… Stop telling users that their cheapo $50 Office Depot firewall is going to save them. It’s not. They’re screwed.

And that is my small contribution to the security of “world usability day” even if I’m a week or so late. Don’t get too upset, I’m mostly joking anyway. I know everyone will keep doing what they’re doing regardless of how little it’s helping. God bless the free market economy and foolhardy developers.

The title of this post was going to be “we weren’t slashdotted again” but I thought that was just a little too sarcastic. Yesterday Slashdot ran an article on password theft via XSS. If this looks familiar it’s because it is. We have been talking about this for a few months here and here. I’m not bitter, but the information on slashdot is incorrect. The first example of this was actually built in a lab environment nearly two years ago and we’ve been talking about this since August. But who’s counting?

That’s the annoying news. The good news is that apparently Firefox has now decided it’s a problem (I guess it isn’t a problem when I say it but it is when Myspace gets attacked with it… go figure). The real problem here is that this isn’t a Firefox only issue. This is indicative of many types of password/form managers, and not just a single browser. So while they can protect their customers from this issue they can’t protect their customers from other third party tools that do the same.

So yes, old news, but new that Firefox has filed a bug on it. I wish I had better news, but I don’t think id would like it too much if we got slashdotted again. We’ve had enough server woes over the last few weeks, we don’t need any more.

I got an email from unsticky the other day that I thought was fairly interesting because it shows one of the rather obscure ways to get outside of encapsulation when certain characters (in his case the semicolon) are disallowed to attempt to prevent XSS. Here’s his email:

I know you’ve discussed ';alert('xss');// and the like, but when I’ve been trolling some sites for xss vulns, I’ve found that a few of them escape semi-colons, but the apostrophes, slashes, or parenthesis. To compensate, I’ve been using a plus instead of the first semi-colon and leaving out the second one all together, leaving me with '+alert('xss')//. I don’t know if it’s worth mentioning on your site or adding to the xss cheat sheet, but it’s sort of a ‘new concept’ that I don’t believe has been brung up before. Since most of the time, for the sites I’m pestering, the injection point is into a variable, you can add an alert() to a string. The alert() will be excuted when your browser tries to add the return value to the variable.
For example: var str=''+alert('xss')//;doSomething(str);

This is a variant of the escaping JavaScript escapes cross site scripting vector. The major difference is that instead of ending the assignment and starting a new line he is allowing his vector to fire within the confines of the variable assignment. The function (in this case alert()) returns true since it fires and the JavaScript doesn’t fail. The end slashes are actually not required as you could continue the assignment with something like, '+alert('xss')+' which would have the same effect.

There are other weird things like this that I’ve found that cause some minor issues when you are trying to allow some sort of function to fire. A number of times I’ve had to jump out of comment tags that are actually encapsulating the JavaScript. That’s another weird situation that requires no quotes, despite what most people think. Simply by ending the comment tag, then by ending the script (regardless if you are encapsulated this will still work) you can jump out of it.

Sometimes I think encapsulation is just silly. It’s nearly useless at preventing XSS unless everything is URL encoded or all special characters have been removed.

I got an interesting email from devloop today about a way to circumvent certain forms of CSRF protection. I’ve actually talked about this before but I never had a concrete example to show off. The basic premise is that if you have a two step process and the session is stored in a cookie and not on the page, you don’t need XSS to bypass it, you only need a series of CSRF (or same site request forgeries) to initiate the attack. Here is devloop’s email (modified for formatting):

Hi RSnake !
I’m one of your reader and also the developper of a web application vulnarability scanner called Wapiti ( http://wapiti.sourceforge.net/ ) Got my blog at http://devloop.lyua.org/blog/ (french)

I wanted to tell you about a Cross Site Request Forgery I found on the Last.fm website. This website allows users to create and join groups.

I study a little how the inscription to a group work and I was looking like a simple url will make the victim join to a group.

I created a group called “CSRF” ( http://www.last.fm/group/CSRF ) Tipically a user that want to join a group must go to the group homepage, click the “Join this group” link to go to the page http://www.last.fm/group/CSRF/join/. Then the user must confirm the inscription clicking on a submit bouton with an empty <form> with action=http://www.last.fm/group/CSRF/join/?confirm=yes

At this time I was thinking that users will join the CSRF group just by going to this page. But Last.fm got a kind of CRSF protection. Users were asked for a new validation, this time goin to http://www.last.fm/group/CSRF/join/?confirm=apply.

If the user go to http://www.last.fm/group/CSRF/join/?confirm=apply first, he will be redirected to http://www.last.fm/group/CSRF/join/?confirm=yes.

The solution was to make sure users go to the two urls. So I posted a news on the forum and in my journal section with to <img> linking to the urls [img]http://www.last.fm/group/CSRF/join/?confirm=yes[/img] [img]http://www.last.fm/group/CSRF/join/?confirm=apply[/img] (Last.fm allows some BB code)

I started with one unique member for the group (me) and now I got 14 users in the group http://www.last.fm/group/CSRF/members

I hope to get more users soon, as friends of the victims may be be infected to just by looking at the CSRF group page.

Bye ! and keep posting on your blog.
devloop

This is exactly what I was talking about. In some applications that I’ve seen (but can’t post for NDA reasons) a type of click protection is used to prevent users from going from page to page. However, the cookie to allow the activity is stored upon user submission of the first CSRF.

That allows the attacker to force you to perform the action through a series of clicks, without actually needing the page to render (as it breaks inside of an IMG tag). All the attacker really needs is to get you to visit the page so you pick up the proper headers (the authorization token) so that the second request is sent as an authorized user. Lesson learned? The one time use authorization token to stop CSRF has to be something that the page emits, not just something that the server headers emit. And even then you have to make sure there is no XSS on the same host or on the same IP even so they can’t read it. Tricky.

I know this isn’t 100% on topic, but I really get a kick out of viral issues in social networks. In this case there is a new virus that hit Second Life that auto-replicates a particular item all over the world. Second Life is an interactive game where users can create their own land and items etc for actual money. Sounds like trouble to me. Mixing personal interest with untested designs is often cause for exploitation.

In this case the virus called Grey Goo (named after the theory that a molecular self replicating machine could destroy the earth and turn it, essentially into grey goo) ended up taking the game down for just a little while as they fixed the issue. A minor annoyance, some bad press and a few lost customers at worst. But think about how bad self replicating code really is. There is no actual distinction between that and any genetic self replicating organism.

The only major difference is that we are personally immune the effects of the viruses (at least for the most part). It’s annoying, but we have out of band mechanisms for dealing with code. But think about a future where everything has an IP address. Something as simple as a flicker can cause epilepsy. A bug could drive your car off the road. A glitch could cause all the dams in the country to open up and flood the surrounding areas. Thankfully this grey goo scenario could be stopped by out of band mechanisms, but the more we automate systems in the physical world the less and less easy it will become to be completely in control of the machines we build.

It’s awfully nice to have the big red panic button. Let’s just make sure we don’t automate that too.

I was playing around with a pretty custom Google dork primarily used for breaking into random user accounts through helpdesk systems today. As you might guess, it’s not particularly good for targeted attacks, and for a while I thought it was pretty useless in general (who wants to read helpdesk tickets all day long anyway)? Then I happened upon a small online retailer with far more serious issues.

The search engine had somehow indexed a valid credential for the system. The credential was in the QUERY_STRING as was the user ID and the customer ID. Why those two things aren’t the same on this system I really have no clue. But sure enough changing the customer ID allows me to switch accounts. Not only that, but the customer ID is directly used in the SQL query and if that wasn’t bad enough each “customer” that I was looking at was actually a reseller and each reseller had many customers of their own, each of which had email addresses, full names and addresses, without even attempting to attack the data base (yes, there is a lot more info in the database). Ouch, ouch, ouch.

Let’s just count the ways in which this was a poorly designed system. 1) They stored user credentials on the QUERY_STRING. 2) They didn’t invalidate the credentials over time. 3) They didn’t validate that the user ID matched the customer ID. 4) They didn’t even attempt to stop the SQL Injection of the customer ID by validating that it was a valid looking number. Also, the auth token itself was what I would call “small”, being only 10MM total possible combinations. I doubt highly that anyone is monitoring that system so guessing 10MM requests might seem out of the realm of possibility, but a low and slow attack might be successful - not that you have to when the search engine has done a nice job of storing the credentials permanently for anyone who wants one.

Anyway, this was one of the worst secured systems I’ve seen in a long time, and I thought you all might like to hear about it. Almost all of these issues surface at one point or another but rarely all at the same time. To make matters worse this isn’t exactly a little known website according to Alexa. Makes me worry about where I’ve used my credit card in the past.

Well, maluc has done it again; he’s found a cross site scripting hole in Google’s search appliance. For a paltry $2000-30000 people can buy an appliance to search their site. Unfortunately maluc has discovered that if you keep it on your domain your whole domain is at risk of information leakage, session theft, etc…

The hole uses the selected encoding issue I’ve been talking about, but instead of using the US-ASCII encoding issue, he used the UTF-7 hole. Fantastic! He also disclosed a number of vulnerable websites including Stanford, the Food and Drug Administration and the National Institute of Standards and Technology.

This is the problem with adding outside applications onto your trusted domain. If they weren’t on the same domain the problem wouldn’t be nearly as bad from a security and public relations standpoint. Google will probably need to issue a patch to all of it’s customers. I’m not sure if the boxes are managed or not - my guess is not. So this will probably take a while to completely fix on all sites that use it. Expect this one to be around for at least a little while.

Over the last few weeks I’ve had a number of exchanges with Yosuke Hasegawa and Cheng Peng Su about various encoding issues within IE7.0 and IE6.0. Unfortunately I am fresh out of IE6.0 installs, so I have nowhere to test some of these theories. I sorta have to take it on faith that it works, or maybe someone out there can verify for me, but apparently Yosuke has found some interesting CSS obfuscation techniques. Here is the English version if it helps.

I was pretty frustrated during this testing because it really feels like there is more here, but without IE6.0 more than half of the tests don’t work properly. However, the ones that do work work in any encoding method which is nice. Here’s an example of some of the obfuscation:

<div style="{ left:&#x5c0065&#x5c0078pression( this.style.background='red')}">try me in IE</div>

What you are seeing is an HTML string creating a CSS escaped string that turns into the character in question. \ turns into a backslash. The backslash turns the resultant four character string into the ASCII equivalent. Pretty tricky and makes life quite a bit more difficult for testing these strings.

I’ve got to say, I’m actually really happy with all of the work that Yosuke and Cheng have been putting into these encoding methods, but the language barrier (Yosuke speaks Japanese and Cheng speaks Chinese) is making it difficult to do tests. As we come up with more, I’ll let everyone know. It’s just slow going at the moment. So while I admit that some of these things came out a few weeks back, mostly it’s been me who’s taken too much time actually testing all the various encoding methods against the strings they provided before making the one above that you see today. Anyway, great work from Yosuke!

I guess there is a first time for everything. We have gotten our first legitimate death threat by way of blog comments. Last night at Wed, 15 Nov 2006 20:54:51 -0800 (PST) we got many threatening posts. Don’t worry, I’m not running for the hills, but I thought you should all know about it, as I do try to be full-disclosure about events like this. Here is a choice snippet for your enjoyment:

IP: 211.144.105.161
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
…non threatening babble snipped…
IM GONNA SET FIRE TO UR FUCKING HOUSE AND DANCE ON UR FUCKING CORPSE!!! ( IM NOT A MENTAL PATIENT!!)

If I had a house I might be more worried, I guess, but if I’m dead why would I care if someone was dancing on me? Clearly he is not a mental patient as he says, although perhaps that should change as a result of this post. No, but seriously, at first I thought it was a joke, a la fthe.net: “No death threats or poetry please. Just Kidding. No Poetry please.” But after looking at his traffic and seeing the huge volley of posts talking about what I should suck and where I should shove things, I kinda doubt it. Not that I think he would actually come after me and dance on my corpse, but I still don’t take things like this lightly.

This is a user who has been on the site off and on for quite some time, so it is not in regard to any of the near recent past events, and in fact found me through a link talking about the imagecrash script. So I’m not exactly sure what the impetus was other than perhaps there is some clue in the post he looked at immediately before going crazy - the click fraud post. I can’t really see why click fraud would burn this user up, but there you have it.

Look, whatever the reason is, I’m not online to make enemies. I don’t care about harming companies, or about posturing in general. I’m really just interested in security as a whole. That doesn’t make me malicious. In fact, if anything I am one of those most level headed business oriented people you’ll ever meet. I’m a consumer advocate and a business advocate almost to a fault. The lab was built for me to test serious flaws that were affecting the company I worked for a the time. Why? Because I was trying to protect all of you. Yes, nearly every single one of you was being protected by me and the team I was on. That’s not a joke, and sooner or later it’ll come out about what I used to do.

My point being, I’m not sitting in a basement thinking of ways to destroy security companies or huge businesses. I’m very much a normal guy, who just has a passion for finding issues that would affect me or my family or good people like you all. I really love the Internet but it’s getting to be a scary place. I don’t feel safe on it (and it’s not just because of the death threat). By shutting people like us up all that will happen is that you end up with a more insecure Internet where only people in the shadows have any clue what’s going on.

I started the web application security lab because there was a huge void in the security space. There were a few good organizations like WASC and OWASP out there. Zeno had CGI Security but even he’ll admit that he wasn’t as free to talk about what he was working on as he would have liked. Frankly very few people were discussing web application security publicly while I was living the business end of it every day. I was dealing with all these issues for real, not as a game and I certainly wasn’t involved in the academics of security theory - at least not while I was on the clock. I had to protect millions of users while making half of it up as I went along, because there were no good resources out there for people like me.

Things have evolved in an odd way and I am sure some people think I am super malicious and out to destroy all that is good and holy. That could not be further from the truth. I have zero interest in vulnerabilities in particular companies. Yes, I like some companies better than others, but I don’t care about the issues in them. I’m a privacy advocate, but that doesn’t mean I live in shadows. I like for people to know what I’m thinking. Even if I’m dead wrong (and I have been wrong before) at least there is an avenue to discuss it, unlike two or three years ago when all we had was the webappsec mailing list, which had perhaps two or three posts a day on it if that. That’s just not enough for how serious an issue web application security actually is.

So I’m speaking both to our friend at the Chinese IP address as well as to any other people who think I am a self-servicing anarchist. I’m here protecting you. I’m a) keeping you people with jobs b) giving you an opportunity to see the issues before the bad guys use them against you and c) I’m attempting to find ways to fix those same holes. There are only a handful of people out there doing this sort of research and being public about it. Frankly, the more we do the closer we’ll get to figuring out the issues.

I’ve been out of the security industry for almost a year now but I think it’s about time to come back. This time on my own terms.

This is an idea I’ve shot around many times - the concept of using a emulated browser to detect cross site scripting. Well it looks like I wasn’t alone in my thinking. Rapid 7 has built a new JavaScript/DOM/Browser emulator that can help sniff out those pesky XSS exploits. I’ve actually had passing conversations with the SPI guys and I know they were at least thinking about something similar but I’m not sure if it’s been deployed yet or not.

There are some obvious pitfalls in this. It’s only a snapshot so you must run it over and over again. It can’t emulate all browsers because it is probably written with something like SpiderMonkey which only emulates Firefox. That leaves a pretty gaping hole in the things it can detect accurately. And probably the most important issue is that to detect things accurately it really should download every object on the page, which makes something like this deathly slow and bandwidth intensive.

But overall I really support this type of scanning. It’s at least solving some of the major issues that most scanners don’t find with things like obfuscated dynamically generated JavaScript, and very odd CSS obfuscation issues. That said, I’m still not sure this is the right answer, given the issues I mentioned above. But I’m glad smart people are thinking about it. But just a warning to all scanning companies I’m sure I have prior art somewhere from almost two years ago so no one had better patent this. I’d rather it be out there so everyone can use it and come up with better ideas on their own.