iis.system.isapi.txt

`Date: Mon, 8 Mar 1999 11:27:48 -0500  
From: Fabien Royer <[email protected]>  
To: [email protected]  
Subject: ISAPI Extension vulnerability allows to execute code as SYSTEM  
  
  
There's a vulnerability in IIS (and other WEB servers executing as SYSTEM)  
that allows to execute an ISAPI extension in the security context of the  
server itself instead of the security context of IUSR_WHATEVER. How is this  
possible: when the server loads an ISAPI extension the first time, it calls  
GetExtensionVersion(). During the call to this function, an attacker can  
execute any code as SYSTEM. This is a problem if you're an ISP doing hosting  
with web servers offering ISAPI support (IIS, Apache 1.3.4, etc. ) because  
any user allowed to place a "CGI" on the server can take over. Of course,  
this problem is not limited to ISPs.  
Fabien.  
  
--------------------------------------------------------------------------------  
  
Date: Tue, 9 Mar 1999 00:32:03 -0500  
From: Fabien Royer <[email protected]>  
To: [email protected]  
Subject: Re: ISAPI Extension vulnerability allows to execute code as SYSTEM  
  
> -----Original Message-----  
> From: Scott L. Krabler [mailto:[email protected]]  
> Sent: Monday, March 08, 1999 11:41 PM  
> To: Fabien Royer; [email protected]  
> Subject: RE: ISAPI Extension vulnerability allows to execute code as  
> SYSTEM  
>  
>  
  
> By this, I'm assuming the required safeguard would be to only implement  
> ISAPI filters whose contents are known. Since ISAPI filters can only be  
  
Typically, filters and extensions fulfill different purposes. For instance,  
you would not implement an complete WEB based application as a filter for  
performance reasons. Filters see all http "traffic" while extensions only  
see the http traffic that is directed to them.  
  
Unless you have written the filter yourself (or someone trusted in your  
organization), you can't know if a filter is 100% secure either.  
  
> installed locally(?) there shouldn't be any general risk. Yes?  
  
This is not that simple. You can remotely install a filter under IIS if you  
can cause the following sequence of events to occur:  
  
1) Place the filter .dll in a location accessible from the web server.  
2) Update the registry to register the new filter.  
3) Cause a reboot of the machine or stop/start IIS.  
  
All of this can be done from the GetExtensionVersion() call mentioned  
earlier.  
  
Finally, you can host a filter *AND* an extension in the same .dll.  
  
Fabien.  
  
>  
> -----Original Message-----  
> From: Windows NT BugTraq Mailing List  
> [mailto:[email protected]]On Behalf Of Fabien Royer  
> Sent: Monday, March 08, 1999 10:28 AM  
> To: [email protected]  
> Subject: ISAPI Extension vulnerability allows to execute code as SYSTEM  
>  
>  
> There's a vulnerability in IIS (and other WEB servers executing as SYSTEM)  
> that allows to execute an ISAPI extension in the security context of the  
> server itself instead of the security context of IUSR_WHATEVER.  
> How is this  
> possible: when the server loads an ISAPI extension the first  
> time, it calls  
> GetExtensionVersion(). During the call to this function, an attacker can  
> execute any code as SYSTEM. This is a problem if you're an ISP  
> doing hosting  
> with web servers offering ISAPI support (IIS, Apache 1.3.4, etc. ) because  
> any user allowed to place a "CGI" on the server can take over. Of course,  
> this problem is not limited to ISPs.  
> Fabien.  
>  
  
--------------------------------------------------------------------------------  
  
Date: Wed, 10 Mar 1999 18:28:24 -0500  
From: Fabien Royer <[email protected]>  
To: [email protected]  
Subject: Re: ISAPI Extension vulnerability allows to execute code as SYSTEM  
  
Sure, however the executable that you are going to execute will run in a  
separate address space and if it is spawned by IIS, it will run in the  
security context of IUSR_xxx instead of SYSTEM. This is the *major*  
difference between what you can do with the .dll approach and the .exe  
approach.  
  
Fabien.  
  
> I don't know that .EXE's are that much safer. How about this:  
>  
> I upload 4nt.exe (Command.Com/CMD.Exe replacement program)  
> I write an EXE that calls it and runs the command 'reboot'  
> or even a 'del /zsx c:\*.*' (Which will recursively delete all  
> files that aren't currently in use)  
>  
> Same idea ... different way about it.  
>  
> Being a developer and having the tools available, I require that  
> I get to compile the code myself. That way, I can scan through  
> the code to see if it's trying to do anything malicious.  
> Granted, this isn't 100% foolproof, but it does help!  
>  
> Charlie  
  
`