Is it possible to Exploit this Line Feed?

Question

During a security assessment on a website I found a a redirection link that was reflecting the values in the Location header. The first thing that came to my mind was CRLF injection so I tried a few variation of "%0a" and managed to include my payload in the response:

Request:

"https://ads.example.com/promoredir?redirect=http%3A%2F%2Fmain.example.com%2F%E5%98%8A%E5%98%8DSet-Cookie:%20test"

Response:

HTTP/1.1 302 Moved Temporarily 
Date: Sun, 12 Jul 2015 14:18:41 GMT 
Server: Apache 
Set-Cookie: JSESSIONID=5C24F2C96CE37DAA026591F5CAD91900; Path=/; Secure; HttpOnly 
Location: mail.example.com

Set-Cookie: test

Content-Length: 0 
X-Content-Type-Options: nosniff 
Strict-Transport-Security: max-age=31536000 
Vary: User-Agent 
Connection: close 
Content-Type: text/plain; charset=UTF-8

However when I follow the redirection, my request changes to the following:

GET /Set-Cookie:%20test" HTTP/1.1
Host: main.example.com
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close

Where am I going wrong here?

So what the hell is "%E5%98%8D%E5%98%8A", could you link to some background information on this extremely obscure attack string? My guess is this is some kind of advanced multi-byte injection, care to elaborate? (https://hackerone.com/reports/52042) — rook, Sep 07 '15 at 19:36
Of course, the researcher who designed this string made a great post about it on this link: https://blog.innerht.ml/page/3/ — Mico, Sep 10 '15 at 09:59

score 1 · Answer 1 · edited Aug 04 '15 at 20:49

1

I would try to just do something like this:

http://www.example.com/somepage.php?page=%0d%0aContent-Type: text/html%0d%0aHTTP/1.1 200 OK%0d%0aContent-Type: text/html%0d%0a%0d%0a%3Chtml%3E TEST TEXT %3C/html%3E

to start with. Then, if you see 2 different responses, and one of them is a 200, and if you see the text, you can then try whatever stuff with cookies.

edited Aug 04 '15 at 20:49

schroeder

123,438
55
284
319

answered Aug 04 '15 at 20:18

superuser

121
1

%0d and %0a are replace with "space", also the response is still 302 (redirection). – Mico Aug 06 '15 at 09:02
The only payload that creates a new line is "%E5%98%8A%E5%98%8D" – Mico Aug 06 '15 at 09:03
An attacker shouldn't need two content-types to exploit this issue. In fact, this may confuse the browser. Controlling the header and the beginning of the HTML should be sufficient to control the content of the entire page. I have no idea what micro is referring to about "%E5%98%8A%E5%98%8D", that must be chinese (literally). – rook Sep 07 '15 at 19:40

score 0 · Answer 2 · answered Apr 08 '16 at 16:25

I have tried hard on same kind of bug you are talking about. But the same problem that I'm facing is, You can easily inject a cookie or Set-Cookie but Can't exploit further such as XSS, Content Injection etc. You can inject HTML content on 302 Redirection page but It doesn't make sense because very next you will get redirected to page.

In this case only %E5%98%8D%E5%98%8A will work for injecting cookie. Also as I guess you can't split the response header in two working response headers.

score 0 · Answer 3 · answered Aug 03 '15 at 13:28

It's impossible to say from your "screenshot" above, but I'd say you're not getting back 0x0D 0x0A after the location, but instead the high bytes you've sent (0x8A 0x8D), including your Set-Cookie.

And you're not interpreting the returned high bytes as CRLF either, so your user agent interprets the Set-Cookie as the non-host-part of the URL.

Try switching the order of CR and LF, and look at a hex dump of the response from the web server.

score 0 · Answer 4 · answered Aug 07 '15 at 15:01

I think you should send %E5%98%8D%E5%98%8A, not %E5%98%8A%E5%98%8D. Otherwise both tokens get expanded and you probably end up with an extra newline.

On the other hand, the extra newline apparently is not interpreted at all, so I'm wondering if your exploit is indeed working, or whether you're seeing your own payload echoed back harmlessly to you and then interpreted as a spurious newline.

I.e., you send

location=(...omitted...)%E5%98%8A%E5%98%8D(...)cookie%20test

and the server echoes back a single line

Location: (same as above)

and this is why your browser sends that GET. You appear to see a newline in your response because the single line above gets interpreted as two lines by your terminal.

Of course, the researcher who designed this string made a great post about it on this link: blog.innerht.ml/page/3 — Mico, Sep 15 '15 at 09:53

Is it possible to Exploit this Line Feed?

4 Answers4