Date: Mon, 8 Mar 1999 11:27:48 -0500 From: Fabien Royer To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM 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 To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: Re: ISAPI Extension vulnerability allows to execute code as SYSTEM > -----Original Message----- > From: Scott L. Krabler [mailto:scottk@visi.com] > Sent: Monday, March 08, 1999 11:41 PM > To: Fabien Royer; NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM > 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:NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM]On Behalf Of Fabien Royer > Sent: Monday, March 08, 1999 10:28 AM > To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM > 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 To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM 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