Cheng Peng Su came out with another pretty remarkable cross site scripting vulnerability using double bytes the other day in Hotmail and Windows Live Mail. If you don’t remember Cheng Peng Su he was the one who got us started with the variable width encoding issues. This is actually a hybrid of two attacks actually. The first of which is the fact that both Hotmail and Windows Live Mail allow the user to specify their own encoding methods in the email themselves using a header like so:

MIME-Version: 1.0
From: user<user@site.com>
Content-Type: text/html; charset=GB2312
Subject: example

Next he uses a double byte encoding for the letter “e” and the character “(” as follows:

[ascii 163][asii 197]xpression[ascii 163][ascii 168]

That allows the actual vector itself to fire inside of a style tag, as expression() allows CSS to run JavaScript in Internet Explorer. Pretty ingenious exploit, however, if they didn’t allow the user to specify their own encoding methods it wouldn’t have been an issue in ISO-8895-1 for instance. Click here for the full advisory. The issue has now been fixed, but it’s more how the exploit worked than who it worked on that I find interesting in this case. Pretty cool stuff coming from Cheng Peng Su. I’m glad to see he is still working on these issues!

Normally I make changes without telling anyone, because well, hell, no one notices generally. But last night I made a change that at least two people noticed because I inadvertently broke the xssAttacks.xml version of the XSS Cheat Sheet (which is getting more and more out of date unfortunately). I fixed the issue that broke the XML file (thanks to WhiteAcid and Nick for pointing it out). But I should probably explain one of the changes, since I think it’s worth noting.

I made a modification to the XSS Locater. Where it previously had said: </SCRIPT>!– I modified it to say: –></SCRIPT>">'>

These are very deliberately placed because the end comment tag is part of the most strict JavaScript convention which uses comments to made script invisible for readers that don’t gracefully ignore script if they can’t read it. I found a real example of this yesterday.

Then after the end SCRIPT tag which closes any JavaScript tag that it possibly can at that point I have the quote and the end angle bracket as well as the single quote and the end angle bracket to jump out of any HTML entities you are in. Surprisingly this small change makes it significantly more effective. I still don’t use the Locater personally, but it’s a great crutch if you are a) in a hurry or b) want to do a thorough test of some of the most common issues. It still doesn’t include CSS, so I’ll probably eventually add another one in there to pull out some of the most common CSS issues as well. That’s for another day.

Anyway, sorry for breaking the XML file. I’ll try to be better about that one. That’ll teach me to drink beer and author XML by hand at the same time!

Well this is by far one of the weirdest bugs I’ve seen in a while. In doing some tests with my fuzzer, I realized that Opera doesn’t really handle null bytes very well. And I use the word “handle” loosely. It sorta can’t handle them at all. I ran a test where I injected a null byte immediately before a paragraph causing the whole bottom of the page to not show up when you view source. The obvious uses for causing things to fail to load when you view source are data hiding and obfuscation.

The second and much weirder issue is if you inject a null before lines of text it can cause them to fail to render completely within Opera. Why? I cannot fathom why that would happen, but it’s a pretty bizzare bug. Clearly Opera cannot handle nulls properly. Both Firefox and Internet Explorer happily ignore it and move on, rendering the page without any issues.

If you’ve got Opera installed you can see for yourself what I mean. Click here to see the Opera null byte issues. I can’t say how easy or difficult it is to fix these types of issues within Opera because I have no idea how their rendering engine is built, unlike Gecko and Internet Explorer’s rendering engines. Either way, it’s time to fix that one. This blog post goes out to Kyran for getting me to play with Opera a little more this morning. With that said, I’m going back to Firefox for day to day browsing.

After much procrastination on my behalf, I finally sat down and tested Firefox 2.0 from start to finish with the attack vectors from the XSS Cheat Sheet. The results were actually not that interesting believe it or not. For the most part Firefox 2.0 looks exactly like Firefox 1.5 in terms of security against cross site scripting vectors. I was actually surprised there wasn’t more variation between the two revisions, to be honest. The really interesting part was when it got to the URL string evasion tests.

Just when I thought I was about done with my testing Firefox 2.0 throws me a curve ball and changes how the Feeling Lucky function works. The latter two of these were vectors I found while I was messing with security toolbars and finding ways around their detection mechanisms. The following vectors no longer work within Firefox:

• <A HREF="//google">XSS</A>
• <A HREF="http://ha.ckers.org@google">XSS</A>
• <A HREF="http://google:ha.ckers.org">XSS</A>

The last one really surprised me because it still works in the most latest version of Opera. Bizarre. But overall this is a good thing, it really should have never worked in the first place. There’s no reason to allow odd URL strings to do anything other than give you errors or take you to a page asking you if you’d like advice on how to find what you were looking for - not automatic redirection.

So overall Firefox 2.0 hasn’t changed much aside from how Feeling Lucky works. Opera 9.0 changed a little in regard to RFC2616 compliance and Internet Explorer 7.0 changed the most in terms of fixing XSS vectors. So although the results weren’t that interesting for Firefox, the overall results if you aggregate the three browsers together actually is pretty interesting. I wonder how this will pan out in future revisions.

Ferruh Mavituna emailed me today and told me today about a project he has been working on for a few months and finally released today - XSS Shell. In the wake of projects like Anton Rager’s XSS Proxy Petko D Petkov’s backweb and Bindshell’s BeEF Exploitation Framework Ferruh comes out with XSS Shell, complete with a flash video on how it works, it’s a very full featured and easy to use.

This is really interesting in how it allows you to maintain consistent and persistent access to the browser on the domain once it has been XSSed. Tying these sorts of things into heuristics engines can really allow you to gain tons of information about sites that you may not be able to access directly (like Intranet websites). The really interesting part is that Ferruh gives you the opportunity to talk to your victim. Maybe communicating with the victim is part of the game.

Suddenly the movie hackers popped into my mind. Hack into my video station and I start communicating with you through your browser in real time. Interesting thought anyway.

Let’s take a not so hypothetical scenario where a website in question has no visible cross site scripting holes in it, however it is designed to allow for multi-national users. That is, they allow for various (perhaps user defined) encoding methods. Either way the encoding methods are visible and changeable. Suddenly some of our non-obvious attack vectors are appearing more feasible.

How about this link? (Yes, I realize there are other XSS holes on this page, even though poor Jose has attempted to mitigate those risks, but bear with me). Let’s assume for a second that he had done a very good job of encoding all quotes, angle brackets or otherwise special chars. It appears to be a pretty safe function at that point. There is no other obvious way to do injection (yes I know there really is, just stay with me).

Now try the same link but switching it from UTF-8 to US-ASCII encoding (View in Internet Explorer to get it to work). Now you can see suddenly that an otherwise benign string becomes dangerous, because we have the ability to modify our encoding methods. In Internet Explorer this has now become a dangerous page (granted, it always was, but you agreed to go with me on this one, right?).

Giving users the ability to select their encoding method (by browser sniffing or otherwise) is a really bad idea as we can now clearly see in this example.

On one of the lists I’m on the concept of a “request bundle” came up. One of the major issues with performance of the web based internet is multiple requests coming in from a single browser. When a browser makes a request to a webpage, it’s not just one request. It could be dozens of them. Every single piece of embedded HTML, CSS, JavaScript, Flash Movies, Sounds and every image on a page must be called in it’s own session. The concept of a “request bundle” is to make a single call and get all of the items at once in one bundle instead of multiple requests.

If the server in question cannot handle a request bundle (older servers) the request would revert back into older style single requests at a time. It’s an interesting idea, but it may have several hidden implications. The first implication is perceived performance. Funny, because the whole point is to improve performance. But if you have a table with an image in it and the table doesn’t know how big the image will be because of poorly designed HTML it has to wait for the image to download before it can render. Likewise the whole style of the page could also be wrapped up in that bundle. What if I have JavaScript turned off? I have to download it anyway unlike before when I just downloaded what I needed.

The second is a more complex issue. What about the issue of session riding? Can I now make several requests at the same time? How does that effect the security model? Can I do GET DoS more efficiently by only making one request that in fact denotes thousands of calls to CPU or computationally expensive operations or functions? Previously I’ve seen people watch to see if certain objects were downloaded to tell if the user had certain things installed. Well now they are all downloaded at once. So maybe those would fall outside of the bundle and be called individually?

I’m sure there are other hidden issues, but I thought I’d at least throw that idea out to the general public to get the thought out there. Any other hidden issues?

Whelp, I finally found enough time to go through and test for Opera 9 and update the Cross Site Scripting Cheat Sheet thanks to help by Kanedaaa. Instead of it taking 4-6 hours it only took 2, thanks to him - so big thanks there!

The biggest thing to note was a change to the remote style sheet part 3 vector. Previously only Opera was vulnerable to it, and apparently they’ve fixed that. It’s a good thing because it wasn’t RFC compliant anyway.

For the most part Opera remains unchanged as far as vulnerability to XSS as a whole. It’s still pretty good, but hasn’t improved wildly over the last major revision. Thanks again to Kanedaaa, as I really just needed a kick to start on it. Next I have to test Firefox 2.0. I pretty much already have, but that’ll probably have to wait until the weekend when I have more time.

I got this letter yesterday and it’s so good, it’s worth posting in entirety and un-edited. David Byrne found a way to add additional non-visible characters to the list of non-alpha-non-digit cross site scripting vector. The most interesting of which is the backspace character. I’ve toyed with this character but haven’t been able to think of a reasonable use for it to evade security filters before. David Byrne found one:

First, thanks for the XSS Cheat Sheet, it’s a great resource for esoteric attacks. I was doing some testing with a simple fuzzing script and found something that I couldn’t locate on your page. You imply part of it with this:

Non-alpha-non-digit XSS. While I was reading the Firefox HTML parser I found that it assumes a non-alpha-non-digit is not valid after an HTML keyword and therefor considers it to be a whitespace or non-valid token after an HTML tag. The problem is that some XSS filters assume that the tag they are looking for is broken up by whitespace. For example “<SCRIPT\s” != “<SCRIPT/XSS\s”:

Given this string:

<script$x>alert(”XSS”)</script$x>

IE 6 will execute it if $x = \x00, \x09, \x0b, \x0c, \x20, or \x2f. Firefox 1.5.0.7 will work if $x = \x08, \x09 or \x20. Perl’s regex engine doesn’t match \x08 (backspace) or \x0b (vertical tab) to “\s”, allowing “<SCRIPT\s” to be bypassed in a similar fashion. Sorry, if this is already on your site and I missed it.

Thanks,
David Byrne

Pretty cool stuff if you ask me. David is right, I’ve mentioned all the other characters at one point or another but never talked about backspace. If regex is looking for something like this m/<script([\&;\`'"\\\|*?~<>^\(\)\[\]\{\}\$\n\r\0\t…whatever…])*>/ig; (I was guilty of writing code like this early in my career) then the regex will fail. Having taken everything into account that would seem to be reasonable still isn’t enough to stop non-digit-non-alpha. Here is where regex starts really having problems. I’m a huge fan of regex for it’s power, but the fuzzy syntax within HTML elements in the various browsers just makes this far too complex.

Well the results are in (yah, that means I just decided to make up my mind) and it is my humble opinion that Brian Eaton’s hacker pumpkin takes the prize in the first annual hacker pumpkin carving contest.

Click to enlarge

Brian Eaton has delivered us some tasty cialis spam to our inbox. We both love him and hate him for it. Next year I promise to make some sort of prize. The stakes just weren’t high enough, but next year they go up!