Re: exploiting IIS unicode bug using tftp.exe and samba

[Robert Graham <bugtraq () NETWORKICE COM>]

> Unicode v2.0
> allows multiple encoding possibilities for each character, for
> instance:
> 2f
> c0 af
> e0 80 af
> f0 80 80 af
> f8 80 80 80 af
> fc 80 80 80 80 af

Microsoft only supports 16-bit UCS2 rather than the full UCS4. Therefore, it
only supports UTF8 up to 3-bytes long (i.e. e080af, but not f08080af). I
tested this on IIS4, I assume the same applies to IIS5. It likewise applies
to IExplore 5.5 and Netscape 4.7, though Netscape 6 supports the full UTF8.
(I.e. on Netscape 4, fc80808080af decodes to gibberish, but decodes
correctly on Netscape 6 to a '/' character).


> This is where things go wrong in IIS4.0 and 5.0, IIS first scans the
> given url for ../ and ..\ and for the normal unicode of these
> strings, if those are found, the string is rejected...

Not completely. The string is "canonicalized". This means that the following
is a perfectly good URL:

nc www.networkice.com 80
GET /advice/nosuchdirectory/../default.htm HTTP/1.0

This will get the URL http://www.networkice.com/advice/default.htm

The reason I'm showing netcat here is because your web browser will
"cononicalize" the URL before it sends it to the webserver, so you have to
be a bit more raw. It is interesting to note that when Apache canonicalizes
the URL, it double-checks that the directory exists. In the above example,
the directory "nosuchdirectory" doesn't exist, but IIS accepts the request
anyway. In contrast, Apache will check for the subdirectory, and reject the
URL if it doesn't exist.

The only reason IIS will reject the URL is when you canonicalize past the
root directory, in which case there is no directory it could possibly match
with.


> Since the filter does NOT check for the huge amount of overlong
> unicode representations of ../ and ..\ the filter is bypassed and
> the directory traversalling routine is invoked.

Essentially, the logic is:
foo(char *url) {
        FILE *fp;
        canonicalize(url);
        fp = fopen(url,"r");
}
The problem is that the canonicalization function did not understand unicode
... but the underlying operating system DOES use unicode. In other words:
http://www.networkice.com/advice/..rob../default.htm
is a perfectly good URL that isn't canonicalized. Since the canonicalization
function doesn't understand Unicode, it treats it just like ..rob.. (i.e.
doesn't strip it).

The core problem here, and it is much more widespread than just Microsoft
products, is that all paths passed to programs MUST be canonicalized, and
the canonicalization interpretation MUST match the underlying operating
system file system interpretation. Just go back through all the .. traversal
bugs reported in BUGTRAQ; you'll probably find a good percentage of them are
vulnerable to this exact problem or variations.

(Note: after typing "cononicalization" ten times, I want to shoot the
Microsofty that coined the term :-)


> Anonymous, remote ( IUSR_xxxxx ) users can view, copy, delete, md
> and issue other non-ACL protected commands from their browser
> windows. The possibilities even include uploading trojans and
> other hostile codes, viewing .asp files, ...

Note that the primary use for this is defacing websites and running DDoS
trojans since you don't get immediate Administrator control. You would have
to use a local exploit to elevate your privilege to Administrator if you
wanted full control over the box. (E.g. David Litchfield's latest exploit).


> By using tftp.exe that comes with NT and win2k by connecting and
> downloading a trojan from a tftp daemon ....

WinNT hardening note: get rid of the TFTP.EXE client (and FTP.EXE client
while you are at it). These were heavily used for the RDS/MDAC/RDO exploit
as well. While you are at it, remember to remove IUSR_xxx privileges on the
system32 directory and rename C:\WINNT to some other directory name (e.g.
C:\MYWINNT) [Note: 'rename' is a bad word: you can only name the directory
at install time; so install it that way in the first place]. Finally, note
that every default installation of RedHat Linux, Solaris, and WinNT+IIS ever
shipped has been vulnerable. If you don't spend the time hardening the
system (any system) and keeping up with security updates, you will regret
it.


> This *should* get patched asap, since a lot of servers seen to be
> vulnerable.

Network ICE believes this is the most severe vulnerability of the last few
months. We are already detecting widespread attempts. People test our own
site many times per day, and of course we have lots of customers sending
stuff that they are seeing. If your webserver hasn't been scanned yet, my
bet is that it will be within the next week.

Curiously, some idiot out there has posted a script that does the following:
/scripts/..%c0%ae../winnt/system32/cmd.exe
which decodes to:
/scripts/...../winnt/system32/cmd.exe
I don't know if they've confused the dot and the slash because they are so
close, or whether they are confused about the "....." bug that affects Win9x
but not WinNT.

We are also seeing attempts at (decoded for readibility):
/scripts/../../winnt/system32/cmd.exe?/c+type+c:\winnt\repair\sam._
I'm not entirely certain why they just don't try for:
/../../winnt/repair/sam._


Regards,
Robert Graham