By exploiting existing Windows NT services, an application can locate a certain API call in memory (OpenProcess), modify the instructions in a running instance, and gain Debug level access to the system, where it then grants the currently logged-in user complete membership to the Administrators group in the local SAM database.
Microsoft"s Security Bulletin states:
Specifically, the exploit program does the following:
To download the UPDATED demonstration program code, including SECHOLED that attempts to gain Domain-level access click here
The following describes how any normal (non-administrative) user on a Windows NT system can instantly gain administrative control for the entire machine by running a simple executable program.
Requirements: You need to have a machine running the retail/free build of Windows NT 4.0, 3.51, or even Windows NT 5.0 beta -- either Workstation or Server will do.
1. Login on your NT machine: Login as any non-admin user on the machine (even guest account will do). You may verify that the logged in user does not possess admin privilege at this time by trying to run the "windisk" program from the shell. This should fail since the user does not have admin privilege.
2. Copy: After logging in, copy the software (sechole.exe and admindll.dll) onto your hard disk in any directory that allows you write and execute access.
3. Run SecHole.Exe : After running the program, your system might become unstable or possibly lock up.
4. Reboot the machine if necessary: You will see that the non-admin user now belongs to the Administrators group. This means that the user has complete admin control over that machine -- for instance, you will be able to run programs like "windisk", create new users, delete existing users, install drivers, even format hard disks.
FURTHER COMMENTS FROM THE AUTHORS:
SECHOLE.EXE is designed only to work on the workstation/server machine it is executed on. Using the same technique, it is possible to gain domain-level Administrator control over the entire Windows NT network, provided certain other conditions are met. The example program SECHOLE.EXE is not designed to demonstrate this additional vulnerability.
\[NOTE: Microsoft informs The NT Shop that remoting this exploit is not possible. We personally think it may be usable against a remote IIS system via a browser, which may grant the IUSR_MACHINENAME acct undue authority. \]
We (Prasad Dabak, Sandeep Phadke and Milind Borate) have written a book entitled "Undocumented Windows NT" for O"Reilly & Associates. The book discusses a host of undocumented NT API calls -- something every serious programmer must have. The book also discusses the security holes and risks posed by Windows NT operating system.
The complete manuscript of the book is ready to go. O"Reilly has decided not to publish the book for reasons not related to the contents or its authors, thus, the authors are looking for a new publisher for the book. Interested publishers should contact us at [email protected], [email protected] and [email protected]
In the continued absence of interested publishers, the authors will make the book available online for a cost. Two previously posted samples from the book may be reviewed at:
If you are interested in getting the first copies of the book send email to: [email protected] -- the book should be available soon.
\[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.
INTERVIEW WITH THE DISCOVERSThe NT Shop conducted a brief interview with Prasad Dabak, Sandeep Phadke and Milind Borate, the discoveres of this security problem. Below, you"ll find a copy of the transcipt, with our questions listed in bullet items and their answers following each quesiton.
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.
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.
Last year, Konstantin Sobolev from Russia tampered with the NtGlobalFlag (GetAdmin attack) to do the same thing.
We have not tried this.
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.
Prasad found the hole and jumped on it. He had a program \[capable of\] breaking into NT systems within a couple of hours.
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.
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.
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.
Any serious NT programmer
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 [email protected], [email protected], [email protected]. We will maintain a list and positively send out first copies of the book to the people on the list.
All of us are from Pune, India and have a Masters degrees in Computer Engineering. We often travel to the U.S. and work on software consulting projects for California based software companies.
Load the proper hotfix -- U.S. version fixes are listed below. International users should check Microsoft"s FTP directory for proper hotfix versions.