Cenzic 232 Patent
Paid Advertising
web application security lab

Probably Useless XSS In Trace With Apache in IE

I know, it’s a hell of a title, but it’s just about as obscure as it sounds. While messing around with various malformed HTTP requests I found something that is practically useless, but could be scary if anyone could figure out how to exploit it. From a web application security perspective this could be bad, but I don’t know of a way to usefully exploit it given the known holes out there today. So a normal HTTP header might look like so:

GET / HTTP/1.0
Accept: */*
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: www.apache.org
Proxy-Connection: Keep-Alive

And here is how I modified it with burp proxy:

TRACE /?<SCRIPT>alert("XSS")</SCRIPT>
Accept: */*
Accept-Language: en-us
Pragma: no-cache
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: www.apache.org
Proxy-Connection: Keep-Alive

Notice that I removed the protocol (HTTP/1.1) and I changed the method to “TRACE” instead of “GET” or “POST”. Here’s the screenshot. This is just about as un-useful as it gets as I’ve described it. But if you’ve been reading this blog for a while you’ll say, “What about the Flash header spoofing?” I wish that had worked because it would have saved me a lot of wasted time trying. Here’s the problem.

Firstly, Flash doesn’t let you change the method to TRACE as far as I can tell (GET and POST methods only). Secondly I can’t omit the protocol (which is necessary to cause it to be mal-formed enough to cause this to happen). Thirdly it URL encodes the string, which causes it to not render HTML (as the server doesn’t un-encode the string). So, no go using Flash with what I know thus far. However, there may be other ways to do this that I’m not aware of so it’s something to hang onto.

It would have affected only Internet Explorer, on Apache instances with only servers that have TRACE allowed by default (even Apache.org has this, so I’m not too worried about that). So for now, this is not a useful vector, but in the future it may be as browser technology evolves. The reason it’s dangerous (if you could get it working) is that it affects 70% of browsers on about 60% of servers (number of Apache servers as a percentage) assuming they have TRACE enabled (most do). It’s worth keeping my eye on anyway. Sorry, it’s been a crazy last few weeks.

11 Responses to “Probably Useless XSS In Trace With Apache in IE”

  1. WhiteAcid Says:

    My RSS reader (from rssreader.com) creates an alert box when reading this post. I haven’t even got it set to show the page in HTML, just to show the main bits of the post.

    Time for me to write my own RSS reader me thinks.

  2. RSnake Says:

    Haha… well even if I didn’t find a useful vulnerability in TRACE, I did in rssreader ;) I guess it wasn’t for naught!

  3. CptKraM Says:

    Jeremiah Grossman did a writeup on a similar issue in ‘03. http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf

  4. Raif Says:

    Couldn’t this be used in a slightly different way of performing an HTTP Response Splitting attack? I’m pretty new to this sort of stuff, but it sounded somewhat plausible to me.

  5. RSnake Says:

    CptKraM, that is a good paper, but I’m actually talking about a different issue not covered by it. I am actually removing the protocol completely, causing a different issue. Mine would not be using XMLHttpRequest (as that would imply that there is already an XSS vulnerability on the site). Jeremiah is mostly covering cookie theft that is protected by HttpOnly. That’s a side effect of having XMLHttpRequest (requiring XSS). I’m trying to figure out new ways to get XSS on the site - slightly different application, although both eventually providing the same outcome.

    Raif, I doubt it could be useful in response splitting because you are already generating a new request that you have complete control over - why bother with this? The only way that could be practical is if the caching server did something weird with the request - which it really shouldn’t.

    Alas, yes, this is just a useless vector at the moment.

  6. unsticky Says:

    When I was playing with this, on IE, I noticed it cached the TRACE contents as the contents for the page I sent my origional request for. What I mean is, if I the GET request I sent, that I edited in burp suite was for apache.org/index.php, whatever code I had after TRACE would be cached as the normal page contents for index.php. So in a sense, if you could somehow manage to pull this ‘attack’ off, whether locally or remotely it could be used as some odd client-side cache poisoning for phishing, defacement, or xss, as you pointed out.

  7. unsticky Says:

    Note to self: always check theories before making public, otherwise you’ll make yourself look like a moron 2 minutes later :/

    Nevermind, it didn’t cache, IE just didnt want to reload the page..

  8. RSnake Says:

    Actually it was 6 minutes later. ;)

    I feel your pain, I tried about 50 different things thinking I could get this working… that’s why I finally posted what I did find so maybe other people could find a more useful application for it eventually. I’m not holding my breath though.

  9. zeno Says:

    Actually the RSS Reader issue was disclosed in my blackhat talk (along with several others) and demo’d ;p

    Oh and its local zone :)

    http://www.cgisecurity.com/papers/RSS-Security.ppt

  10. RSnake Says:

    Hahah, well, I wasn’t claiming I came up with it, I give complete props to whomever thought of RSS hacking first, you are welcome to it.

    My real intention was talking about this TRACE issue… even though it clearly isn’t useful (yet).

  11. jelmer Says:

    here is a nice white paper about traces and xss http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf