Cenzic 232 Patent
Paid Advertising
sla.ckers.org is
ha.ckers sla.cking
Sla.ckers.org
Script obfuscation, filter evasion, IDS/IPS/WAF bypassing... this is where it should live. Because this topic is too big to live anywhere else. Phj33r! 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
Locating files with exotic unicode chars.
Posted by: rvdh
Date: January 12, 2010 04:25PM

Since it will be some time I have my blog back, I'll post it here for the time being. This is somewhat sexy and exotic fiddling with Unicode zero width non-joiners, who have a lot of destructive power since they are basically invisible to the human eye. I wondered if they were invisible to scripts who normalize i.e. canonicalize paths. Okay, here's the deal of my first experiment;

Utilizing 'ZERO WIDTH NON-JOINER' characters (U+200C) reveal some interesting output. Below 3 sequences of Zero non width chars are placed at:

src="[U+200C][U+200C][U+200C]../../../../etc/passwd"

As you can see (or can't see) it is embedded in this snippet:

<iframe src="../../../../etc/passwd"></iframe>

This results in this output below, where this file HAS been located successfully. If you try another (nonexistent) file it will just go to a 404 for example. But if it's forbidden, like etc/passwd is, it will echo something similar to this below:

Quote

&#15393;&#17487;&#17236;&#22864;&#17696;&#18516;&#19788;&#8272;&#21826;&#19529;
&#17184;&#8749;&#12079;&#18757;&#21574;&#12079;&#17492;&#17440;&#18516;&#19788;
&#8242;&#11824;&#12079;&#17742;&#8766;&#2620;&#18516;&#19788;&#15932;&#18501;
&#16708;&#15882;&#15444;&#18772;&#19525;&#15924;&#12340;&#8270;&#28532;&#8262;
&#28533;&#28260;&#15407;&#21577;&#21580;&#17726;&#2620;&#12104;&#17729;&#17470;
&#15426;&#20292;&#22846;&#2620;&#18481;&#15950;&#28532;&#8262;&#28533;
&#28260;&#15407;&#18481;&#15882;&#21608;&#25888;&#29285;&#29045;&#25971;&#29797;
&#25632;&#21842;&#19488;&#12133;&#29795;&#12144;&#24947;&#29559;&#8311;&#24947;
&#8302;&#28532;&#8294;&#28533;&#28260;&#8303;&#28192;&#29800;&#26995;&#8307;
&#25970;&#30309;&#29230;&#2620;&#18514;&#15882;&#15433;&#15991;&#30583;&#11891;
&#25441;&#29292;&#25972;&#29285;&#25646;&#28268;&#15407;&#18750;&#2620;&#12098;
&#20292;&#22846;&#15407;&#18516;&#19788;&#15882;
&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;
&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;
&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;
&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;
&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;
&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;
&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;
&#2570;&#2570;
&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;
&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;
&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;
&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;&#2570;
&#2570;&#2570;&#2570;

Whoah even this board is choking on it!;-) see the chars here: http://pastie.org/775671

Something is going on here which I haven't been able to find out -due to time restraints. read: laziness- However it does seem to work on a number of occasions & instances of Apache. It might be due to canonicalization issues which is a wild guess of course since I haven't been able to inspect the Apache source for this yet, which might reveal more. Anyway, just to let you know that this might hold some interesting research into exotic uses of non-width joiners.

More info on UNICODE spaces: http://www.cs.tut.fi/~jkorpela/chars/spaces.html



Edited 1 time(s). Last edit at 01/13/2010 05:04PM by rvdh.

Options: ReplyQuote
Re: Locating files with exotic unicode chars.
Posted by: Gareth Heyes
Date: January 12, 2010 05:04PM

@rvdh

Try with a utf-8 charset and used BOM characters too ;)

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]

Options: ReplyQuote
Re: Locating files with exotic unicode chars.
Posted by: rvdh
Date: January 12, 2010 05:24PM

What do you mean Gaz?

Options: ReplyQuote
Re: Locating files with exotic unicode chars.
Posted by: Gareth Heyes
Date: January 13, 2010 11:16AM

http://www.businessinfo.co.uk/labs/test_files/strangebuttrue.html

This files contains a line separator and a BOM character. The line separator is used as a new line and the BOM is ignored like zero width joiner. A utf-8 charset is required

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]

Options: ReplyQuote
Re: Locating files with exotic unicode chars.
Posted by: rvdh
Date: January 13, 2010 05:04PM

Ah okay.

The example I've used was saved as an Unicode html file. Curious though, on files not found like a 404, text is rendered as per usual UTF-8 and readable, but with a forbidden page (or actual file rendered, think etc/passwd in it's own charset) it becomes different. Something weird is going on there. After all, the iframe only renders the source not it's path, so I don't quite understand what is happening there. I do understand that the zero width non-joiner will concatenate possible chars to be rendered, problem is: why not on a 404? It sounds plausible to conclude that the actual etc/passwd was being rendered since a forbidden http code (403) has the same charset as a 404. hence the confusion, since it doesn't make any sense.

A few scenarios seem possible:

- file has been located, the content negotiation says it has to be rendered in Unicode, but then there is a problem: It's only rendered in an Iframe, so it seems that it overrides the charset set on the file that is rendered inside the iframe, from outside the iframe in the HTML that I set as Unicode. (this is interesting, since it SHOULD not happen)

- file has not been found, or simply is forbidden and the charset again travels to the iframe, which again SHOULD never happen, because if you may control the charset you essentially break the SOP right? albeit on charsets, but you still break which might have some impact in some situation where the charset needs to changed.

- the server responds with a forbidden page, the browser get's utf-8 sent back, but the HTML file that embeds the iframe is in Unicode, again overriding the charset given by the server, SHOULD not happen at all.

With some luck, I actually got the etc/passwd due to some issue in canonicalization in Apache. That would be major. But I'm not betting on it right now, it need more research.

But it looks promising in many areas, think file uploads, includes, SLQi, XSS, path traversal to name a few.



Edited 2 time(s). Last edit at 01/13/2010 05:16PM by rvdh.

Options: ReplyQuote
Re: Locating files with exotic unicode chars.
Posted by: rvdh
Date: January 13, 2010 05:45PM

It gets weirder than I thought.

I get an 404 HTTP CODE back on the Iframe, But! :)


Firefox does something strange. If I locate:
[U+200C][U+200C][U+200C]../../../../etc/passwd
it spits back all these chars on my server. If I do it on another server, like apache.org as test, it renders a 404 in text.


If I do only;
[U+200C][U+200C][U+200C]../../../../etc/
on my own test server, it also gives me plain text. So there is some crazy shit going on right there.


Oh and, MSIE just fails to load the whole thing and gives: "The webpage cannot be found". Which is funny in it's own right of course, since it does not obey the server's response, violating the RFC (yet again).

If you wanna try use:
unescape("\u200C\u200C\u200C");
to get a set of zero width non-joiners, and save the page in Unicode, without BOM.



Edited 2 time(s). Last edit at 01/13/2010 05:55PM by rvdh.

Options: ReplyQuote
Re: Locating files with exotic unicode chars.
Posted by: rvdh
Date: January 13, 2010 06:13PM

Another test:

[U+200C][U+200C][U+200C]../../../../etc/passwd

Gives me a 404 as HTTP_CODE but renders the page to the garble as seen above, or here; http://pastie.org/775671


[U+200C][U+200C][U+200C]../../../../etc/passwdS

Adding another char gives me a 404 as HTTP_CODE, but renders readable text; no garbled text.

Any ideas? it's tempting to assume it actually fetched the etc/passwd but threw
in a 404 instead but with the actual file contained in it, because according to
the RFC, sometimes 404 will also be given if the permission to view forbidden
files is not granted, this is to obscure the fact that you guessed the path
correctly. If that is the case, we got something worth while here.



Edited 1 time(s). Last edit at 01/13/2010 06:15PM by rvdh.

Options: ReplyQuote
Re: Locating files with exotic unicode chars.
Posted by: rvdh
Date: January 14, 2010 06:42AM

Some test cases:

Renders to plaintext:
http://scarletred.nl/one.html
../../../etc/

Renders to plaintext:
http://scarletred.nl/three.html
../../../etc/passwdS

Renders to garbled text:
http://scarletred.nl/two.html
../../../etc/passwd

So the question is, why does it something different? all get a 404 as result. Remember due to caching of Firefox you might get the same results.

Options: ReplyQuote
Re: Locating files with exotic unicode chars.
Posted by: thornmaker
Date: January 14, 2010 01:36PM

fwiw: garbled text, when properly interpreted is
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>404 Not Found</TITLE>
</HEAD><BODY>
<H1>Not Found</H1>
The requested URL /etc/passw was not found on this server.
<HR>
<I>www.scarletred.nl</I>
</BODY></HTML>

Options: ReplyQuote
Re: Locating files with exotic unicode chars.
Posted by: rvdh
Date: January 14, 2010 02:28PM

Yep, my luck it wasn't the actual passwd eh? ;-)

But it still is not resolved. Did you found out why it left out the "d"? I'm still pondering on the fact that it only seems behave like this on files that are actually there. Strange case.

Options: ReplyQuote
Re: Locating files with exotic unicode chars.
Posted by: rvdh
Date: January 22, 2010 08:11AM

Now I rewrite errors myself to a utf-8 text file, and it still happens. Ghost in the machine.

Options: ReplyQuote


Sorry, only registered users may post in this forum.