Vulnerability Development mailing list archives

Re: Summary of IIS 4.0/5.0 Unicode thread (end of thread?)


From: Marcelo Lamoglia <lamoglia () EASYNET COM BR>
Date: Fri, 27 Oct 2000 10:52:17 -0200

I've tested the code and it executes if the /winnt directory is not located
in the same partition as the webroot directory...

Regards,
Marcelo

-----Original Message-----
From: VULN-DEV List [mailto:VULN-DEV () SECURITYFOCUS COM]On Behalf Of Ryan
Yagatich
Sent: Thursday, October 26, 2000 1:17 PM
To: VULN-DEV () SECURITYFOCUS COM
Subject: Summary of IIS 4.0/5.0 Unicode thread (end of thread?)


Summary of IIS 4.0/5.0 Unicode thread (end of thread?)


Full analysis is enclosed, and should answer some questions, and may lead to
more.


Problem:
IIS 4/5 Chineese
IIS 4/5 Others

Overview:
There is a problem with unicode directory handling in Internet Information
Server by microsoft that allows remote execution of code.

raw unicode is a 2 byte character. the UTF-8 standard is based around a 7-8
bit ascii but with the unicode extensions. so, an ascii file is UTF-8, but
not vice-versa (as stated by Bluefish). as you recall from navigating
web-pages etc. you cannot see directory: http://ntserver/../ because the
server doesn't let directory transversal to be present. however, the server
software only parses that string for specific data, instead of it's unicode
reference number. Since the lower level of the platform is encoded using
unicode, the software thinks that it doesn't need to test for it. so, by
telling the daemon that you are requesting ../../../ ...etc... only with
it's unicode extensions, it will open up the particular file you are
requesting, but only if that file exists. so by attempting to grab the
location of / (or \) you will get nothing. this is because it is looking for
an exact reference.

this also works for doing https requests as well. but, depending on the
security of the file structure, your search will be halted immediately.

the following are 2 ways to test your system:

english:
http://EnglishNTServerNameHere/msadc/..%c0%af../..%c0%af../..%c0%af../winnt/
system32/cmd.exe?/c+dir+c:\

chineese:
http://ChineseNTServerNameHere/msadc/..%1c%0a../winnt/system32/cmd.exe?/c+di
r+c:\

this executes:
webdrive/winnt/system32/cmd.exe /c dir c:\

here, you can substitute any directory with the execute attribute set to it,
i.e. /msadc, /scripts, /Scripts, /cgi-bin etc...

exploit problem:
there is a problem with this exploit, where you cannot redirect output by
using the > < or |  symbols, and to try the unicode equivilant of this you
would still fail with "The paramater is incorrect". so thus we have a
problem.
        -how to overcome this problem-
                since you do have some rights to the directories, all you
need to do is copy the cmd.exe file over to another one, and you have the
redirect options available again.
                also, you can setup a tftp server on your box, and tftp the
file/trojan in which you are attempting to run. (netcat anyone?) all you
have to do is setup the command string, the same way.

Protection:
There are multiple ways of getting around this. first of all, your webroot
is the key. (so far) it has been shown that this code will only execute if
the /winnt directory is located in the same as the webroot directory... Even
though i haven't seen any tests for it, i'm sure you can substitute the
unicode values for those smaller characters in it too. so by setting up
different partitions during setup (or however you wish it to be) say c:
contains the winntdir, and drive d: contains the webroot.

another way of resolving this problem is by changing the /winnt directory to
something different (maybe /tnniw?) of course, this is another install-time
configuration (unless you want to go through more pain doing a
search-and-replace on all references in the registry, and start reading
ini/inf etc. files to find it too.

**haven't tested**> another possible workaround is to change directory
attributes. remember how it was stated earlier that only directories with
the +x flag can be used? well, if you take the +x flag off of the directory,
and place just on that particular file, you may have a quick fix (i'm not
exactly sure on doing this through NT, i know you can do it in *nix etc...
and i don't know if this opens any of the same holes)<**haven't tested**


conclusion:
although the multiple threads concerning this topic have been produced, i
have decided to put up this document as a reference to all of them. I think
i have covered all of the bases.


Ryan Yagatich

Brainbench Certified:
        MS Windows NT 4.0 Workstation Administration
        Linux Administration (Red Hat)
        Linux Administration (General)
        Master Computer Fundamentals (Win95/98)
        Master MS Windows 98 Navigation
        MS Windows 95 Navigation
        Web Programmer
        Typing Speed & Accuracy

http://www.brainbench.com/transcript.jsp?pid=224580


Current thread: