Try it yourself - this DLL runs on Intel based IIS machines. Drop it in your scripts directory, and call it without any parameters using your Web browser. (i.e. http://www.yoursite.com/scripts/revert.dll) It creates a directory called C:\IIS-REVERT-TEST with no trouble at all :( I tested this on an NTFS partition with no normal user permissions on the root directory.

Additionally, Laxmikant Gunda was kind enough to report to us that there is yet another way to perform this same exploit. Laxmikant offers the following:

"ISAPI DLL runs under the security context of the IUSR_MACHINENAME account under IIS, and thus inherit the security permissions of that account. However, if the ISAPI DLL can create a process using a call to CreateProcess( ). The process created inherits the security context of the powerful LocalSystem account rather than IUSR_MACHINENAME, thus creating a hole. Thus, any system process can be fired by the ISAPI DLL using this technique.

This can be tried using a generic ISAPI DLL & inserting code for CreateProcess( ) with a process name present in the system.

This behaviour is documented in MSDN library on Impersonation : "When a thread is impersonating a user, most actions by the thread are done in the security context of the thread's impersonation token rather than the primary token of the process that owns the thread. For example, an individual thread of a server process can impersonate a client to verify that the client is allowed to access a securable object. However, some actions are always done using the security context of the process. For example, if an impersonating thread calls the CreateProcess function, the new process inherits the primary token of the process rather than the impersonation token of the calling thread. Similarly, the system always uses the primary token of the process to validate actions requiring the SE_TCB_NAME privilege."

Last Update: June 17, 1997