Gain Local Admin Access on NT

[The following comments were sent to us by David LeBlanc]

The sechole exploit is local in scope unless there is a service running on the system which is running under a domain account. If it can attach to a service running under a context other than the local system, the code could be executed as that user. It is fairly trivial to replace the DLL which comes with the exploit to cause it to take other actions. However, if the lsa2-fix is not applied, the local user who has just become local admin can obtain the password of the domain user for the service and obtain the rights of that user in that manner. The lsa2-fix makes this more difficult (though not impossible).

Another area where sechole can be used to cause problems would be if ordinary users were allowed to place HTML content directly onto the web server. The #exec directive causes a HTML page to execute a command and direct the output to the client, and it is enabled by default in IIS 4.0. If a user were to place sechole.exe, the DLL and a web page which invokes sechole onto a web server, the IUSR_Machine account would then become admin. I would recommend disabling this feature for any web site directories where non-administrative users are allowed to place files.  

David LeBlanc
dleblanc@mindspring.com

We have been working on "Undocumented Windows NT" almost for last one and a half years. As a result we had a lot of knowledge about NT internals. Once we saw an opportunity, we zeroed in instantly. The sechole.exe was written in a day.

• I understand it"s pretty sophisticated in the way it snakes through the operating system to locate a certain API in memory -- is this correct?

Yes, however, all this will soon be commonplace knowledge once the book is out. We discuss the CSRSS, LPC mechanism etc. in fair amount of detail in the book.

All strong operating systems (UNIX for example) always perform validations in kernel mode code or in subsystems since it is not accessible to the ordinary user.

In case of Windows NT, we noticed that the DebugActiveProcess call performs some validation in the user mode code and fails to perform validations on the subsystem side. We believe that the debugging API is provided with the help of a subsystem called CSRSS. The DebugActiveProcess call takes one parameter namely the pid (process id) of the process to debug. The DebugActiveProcess function tries to open the handle to the process using the OpenProcess call. If the OpenProcess call fails then the function returns failure. However, the OpenProcess code resides in KERNEL32.DLL in user mode area. Hence one can modify the OpenProcess code to return success irrespective of the pid passed to it. That’s exactly what SECHOLE.EXE does.

After a successful OpenProcess call, DebugActiveProcess call does not use this handle at all, except for closing it. Next, the DebugActiveProcess sends message to the CSRSS subsystem using the local procedure call (using port object). Another problem with CSRSS was that it did not perform any validations on the caller. It simply sent all the debugging messages for the process being debugged to the caller. During this debug message passing it also passes the handle of the process being debugged. Once you get the handle to the process you can pretty much do anything with that process.

That’s exactly what SECHOLE.EXE does. It gets the handle to process called RPCSS (RPC Sub System), which always runs in full/admin privilege mode, using the above technique. Then it loads the ADMINDLL.DLL in the RPCSS process by creating remote threads and then executes a piece of code which adds the logged in user to the local administrator group thus granting him unlimited power on that machine.

During this we faced with another problem. Once you attach to any process as a debugger you can not detach from it. This is as per operating system design. Hence after SECHOLE.EXE quits, the RPCSS process gets killed and the system could hangs at the time of next login or on any other request to RPCSS. This could render the system unstable, while the damage is already done. A simple reboot could have easily brought the system back to a stable state, however, we did not want to take any chances of losing changes to the SAM database due to unsynced file system buffers. Hence the following:

We decided to get around this unstability. In the present version, after adding the user to local administartor group, the remote thread in RPCSS calls ExitProcess to kill itself. This results in a ExitProcess notification being sent to SECHOLE.EXE (once again by OS design). The SECHOLE.EXE in turn calls "net start RPCSS" to restart RPCSS and quits. This way the system still remains stable while the user has elevated his privileges to the admin level already.

We believe that the RPCSS process is always running on the NT machine. In absence of that, SECHOLE.EXE tries other processes running only in admin mode. Basically SECHOLE first tries to find RPCSS. If it can not find RPCSS then it tries to find SERVICES.EXE and so on.

Here is some information about how Microsoft fixed the problem. They modified the code in CSRSS which responds to the message sent by the caller. The code gets the handle to the caller process from its pid. Then the code impersonates the security context of the caller using this handle. Then the code tries to open handle to the process being debugged under this security context and if it fails then it returns the failure to the caller. Hence if the logged in user is guest and it is trying to open handle to system process such as RPCSS then it will fail. This impersonation and validation code was not there before Microsoft issued this hotfix.

• Are there other ways to accomplish this same exploit?

Last year, Konstantin Sobolev from Russia tampered with the NtGlobalFlag (GetAdmin attack) to do the same thing.

• Could this demo program of yours be slightly tweeked so that it would run remote in a scripts directory on an IIS server? If so, wouldn"t this grant the IUSR_MACHINE-NAME account Administrators access?

We have not tried this.

• Is it feasible using a derivative of this bug to actually gain admin access across the network on a domain controller? Or is it limited to local access only?

We completely disagree with [the Microsoft Security Bulletin statement quoted below] (http://www.microsoft.com/security/bulletins/ms98-009.htm)

"Sensitive systems such as the Windows NT Domain Controllers where non-administrative users do not have any local log on rights by default are not susceptible to this threat. The attack cannot be used over the network get domain administrative privileges remotely."

We believe that using a tweaked version of the SECHOLE.EXE (which we are about to put up on the site this week) we can become domain administrator in the domain from the client machine provided certain conditions are met on the client machine. We need to have a service running on the client machine which runs in Domain Administrator account. We believe that SMS does run some services on the client machine which run in Domain Administrator account.

So at least for cases where a service is running on the client machine with Domain Administrator privileges, the Windows NT Domain Controller is very susceptible to this kind of attack.

This also implies that the attack will work over a network controlled by a Windows NT Domain Controller and is not limited to local access only.

• How long did it take you all to actually get a program working do demonstrate this problem?

Prasad found the hole and jumped on it. He had a program [capable of] breaking into NT systems within a couple of hours.

• What motivated you to make this bug public?

We were writing a book on "Undocumented Windows NT" for O’Reilly & associates. Andrew Schulman was our senior editor. O’Reilly canceled the contract with us for the book mainly due to Andrew Schulman leaving O’Reilly. They have officially released us from the contract. Hence we are now looking for publishers who can publish our book. For this, we need to have exposure to the world. This motivated us the make this bug public and promote the book in the process. We feel that it will be a big loss to the programming world if the book were not to come out.

• Do you have any other bugs in the operating system you"re looking at right now?

Looking for bugs is not our goal. It is just a side effect. We can look for more bugs but that is not the immediate intention or the goal.

• Tell me a little about your book -- what"s the title, and what is the overall content?

The book is tentatively titled "Undocumented Windows NT". The major focus of the book is on system service layer in Windows NT which is mostly undocumented except for some documentation in Windows NT DDK (Device Driver Kit). The major topics covered in the book are.

*  Hooking system services and parameter descriptions for most of the system service.
*  Adding new system services to NT kernel
*  Local Procedure Call implementation covering details about port objects and related system services and sub systems that use the LPC mechanism (CSRSS mainly).
*  Memory management - All the internal data structures involved which are undocumented along with sample programs.
*  Hooking/Adding new software interrupts
*  Callgates on Windows NT etc. topics which have not been dealt with anywhere else.
*  Generic hooking scheme for API spying

• Who would benefit from reading your book?

Any serious NT programmer

• If readers want to get in touch with you about this bug or to obtain information about your book, how do they do that?

We have been contacted by a couple of publishers already. We have decided to wait for another week before going with one of them. The text is ready. Once the final editing is done we hope to get the book out as early as possible. We are also considering email sales since that will cut down the time to availability.

Interested readers are encouraged to send email at psdabak@hotmail.com, sandeepsandeep@hotmail.com, milind@cyberspace.org. We will maintain a list and positively send out first copies of the book to the people on the list.

• Can you tell us a little about yourselves?