Message-ID: <404B0134.3090701@sanctuminc.com>
Date: Sun, 07 Mar 2004 13:02:12 +0200
From: Amit Klein <amit.klein@...ctuminc.com>
To: peterw@....net
Cc: jeremiah@...tehatsec.com, webappsec@...urityfocus.com,
	bugtraq@...urityfocus.com
Subject: RE: "Divide and Conquer" - cross site response header tampering,
 cookie manipulation, and session fixation


Hi Peter,

Thanks for your message.

I would like to make a distinction here. The attack I described, HTTP 
Response Splitting (or Divide and Conquer), is mostly focused on 
crafting an entire new HTTP response message. The direction described 
below is manipulation of the HTTP response in such way that a new header 
is added, but not an entire new response message. This concept is 
mentioned in my paper, under related work, where I explain the 
difference and provide a link to the paper "CRLF injection" by Ulf 
Harnhammer  (http://www.securityfocus.com/archive/1/271515). In Ulf's 
paper, the idea of HTTP response manipulation (in the context of a 
*single* response message), and particularly of injecting a Set-Cookie 
header, is mentioned:

    HTTP defines a "Location:" header for redirecting to another URL,
    and a "Set-Cookie:" header to set cookies. By embedding CR and LF
    characters in user input, web scripts can be fooled into setting a
    cookie from their own web server while redirecting to another site.
    If the script constructs the redirect with a "Location:
    $url\015\012" string, and the $url string is not checked for CR and
    LF characters, we can redirect to a site while setting a cookie by
    giving $url the value "http://www.kuro5hin.org/\015\012Set-Cookie:
    evil=natas". If the cookie contains important data and one user can
    save URL's that another user will be redirected to, this can be
    serious.

So unfortunately, I cannot take the credit for this - it all goes to Ulf 
Harnhammer.

But it's a good thing that this whole subject of influencing the HTTP 
response re-surfaces, and I am glad to take part in it and to expand it ;-)

Thanks,
-Amit

PS - one (minor) result of the paper is indeed an HTTP response 
manipulation in a single response message context. This is the case with 
the ASP.NET 1.1 anti-XSS pattern bypassing (in case of being able to 
inject data into a Set-Cookie header).

-----Original Message-----
From: Peter Watkins [mailto:peterw@....net]
Sent: Saturday, March 06, 2004 00:51
To: Jeremiah Grossman
Cc: webappsec@...urityfocus.com; bugtraq@...urityfocus.com; Amit Klein
Subject: Re: "Divide and Conquer" - cross site response header 
tampering, cookie manipulation, and session fixation

Jeremiah Grossman wrote:

 > This technique builds upon the scenario that user-supplied data is
 > inserted into the headers of an HTTP response message.

 > GET /redirect%0aX-Test:%20foo_test HTTP/1.0
 >
 > HTTP/1.1 302 Found
 > Date: Fri, 05 Mar 2004 16:41:31 GMT
 > Server: Apache/1.3.29
 > Location: http://foo.com/redirect
 > X-Test-Header: foo_test

 > Here are the vulnerability requirements.
 > 1) User-supplied data is inserted in the headers of an HTTP Response
 > 2) User input is unescaped.
 >
 > The results could have the ability to poison the cache in an
 > intermediary device or a web browser.

I think it can be more interesting than that. A vulnerable web server 
could be coaxed into doing things like erase or change cookies in a 
victim's browser -- shades of CSRF & XSS. Consider an email with this 
image tag

<img
src="https://vulnerable.com/app?x=%0d%0aSet-Cookie:%20UID=victim%0d%0a"
height=0 width=0 style="visibility: hidden"/>

If a victim opened a page with such an "invisible" image and did not 
have cookie warnings enabled, such a tag could make the 
divide-and-conquer (DAC) vulnerable /app on vulnerable.com set (or 
change the value of) the victim's UID cookie for vulnerable.com.

Such a cookie-fixing attack would have nothing to do with any 
proxy/cache servers, and would not face the timing challenges that 
Sanctum outlines in its paper.

This could be used as a DoS/annoyance (change the UID to something 
invalid, so the victim cannot maintain their session) or could be used 
to facilitate something like session fixation attacks, as described in 
Dec 2002 by Acros (attacker gets a sessionid, uses DAC vuln to put that 
cookie on the victim's browser, then is able to cohabitate the victim's 
session on the targeted site).

With regards to session fixation and app servers that use "typical"
sessionid cookie, it's worth noting that likely *any* site within the 
same second-level domain could set a cookie that would be recognized by 
other sites in that domain, e.g. a DAC-vulnerable app on the http site 
at "legacy.example.com" could set an ".example.com" cookie that would be 
presented and honored by the https site at "banking.example.com".

To me, DAC seems like a twist on XSS. XSS discussions focused largely on 
embedding content within the body of an object (HTML page); with DAC the 
concern is Response headers, completely outside the message body. Nice 
work, Amit.

-Peter

Powered by blists - more mailing lists