iis-unicode.txt

`  
Recently I received an email from Par Osterberg that directed my attention  
to a post in the Packetstorm forums:  
  
http://209.143.242.119/cgi-bin/cbmc/forums.cgi?authkey=anonymous&uname=anonymous&datopic=Windows&mesgcheck=defined&gum=474&editoron=  
  
An anonymous person posts that they can run arbitrary commands on IIS 5  
(Win 2000) using the following URL:  
  
http://address.of.iis5.system/scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir+c:\   
  
They also gave a sample site that appeared to be vulnerable. Following  
the thread shows various people trying (unsuccessfully) to recreate the  
problem.  
  
So is the site listed a fake, meant to *appear* vulnerable? Was it due to  
a misconfiguration?  
  
First I tried my IIS5/Win2K test server--and it wasn't vulnerable.  
However, the sample site was in China (hence the .cn), and they were using  
a UNICODE character set different than mine.  
  
So doing a quick search on a search engine for sites hosting the default  
IIS5 web page, I found a dozen that had foreign UNICODE fonts--and all of  
them were vulnerable.  
  
Checking a few other US-font sites resulted in them being not vulnerable.  
So at this point there is enough confirmation that there is a problem. I  
can only speculate 'why' this is a vulnerability, and I figure it has to  
do something with UNICODE translation.  
  
However, it's still odd. And I'm not satisfied. Pulling up vi (yes,  
Marissa, vi--not pico (anymore)), I coded a quick little perl script that  
will check all 65535 combinations in place of the %c1%1c in the 'exploit'  
URL. Sorry, but I'm not going to post the script, since it's built on  
whisker v2.0 code, which I'm not ready to release. :)  
  
Anyways, the script chugged through all 65535, kicking back various errors  
from 'Not Found', 'Authentication Required' (?!?), 'Read Access  
Forbidden', and various API error messages ('The parameter is incorrect.'  
and 'The file, directory name, or syntax is invalid.').  
  
But there in the output, in two particular instances, I had a directory  
listing. Yikes.  
  
It seems the values of %c0%af and %c1%9c work for IIS 5. Curiousity  
getting the better of me, I tried it on IIS 4. Uh oh, works there too.  
  
So is it UNICODE based? Yes. %c0%af and %c1%9c are overlong UNICODE  
representations for '/' and '\'. There may even be longer (3+ byte)  
overlong representations too. IIS seems to decode UNICODE at the wrong  
instance (after path checking, rather than before). I didn't learn this  
until later on (after doing some research on UTF-8).  
  
Obviously, since this was initially posted to a public forum, I take no  
credit for the original find--all I did was further develop the research.  
Thanks again to Par Osterberg for sending me the URL.  
  
Microsoft has released MS00-078 to warn of the problem. The patch from  
MS00-057 ("File permission canonicalization") fixes this problem. Note to  
world: MS had a 2 hour turn-around on contact (at 1am, no less), and about  
12 hours for talking with the developers, going over the problem, and  
deciding a gameplan. I think that's worth a kudos. Thanks to Scott Culp  
and David LeBlanc for putting up with me and wasting their weekends. :)  
  
- rain forest puppy  
  
ps. while I thought this was going to be bigger than RDS, it turns out the  
program execution happens under IUSR_machine context, so you're limited  
(e.g. you can't just grab the SAM, etc).  
  
`