|
COMMAND NT Service Killer SYSTEMS AFFECTED Windows NT4, 2000, XP PROBLEM tomotocigare [tomotocigare@securiteinfo.com] says : http://www.securiteinfo.com Picture yourself as a win32 programmer, you were provided with local administrator rights. You are in charge of developing NT system services, i.e. applications that do not need opened session to be running. During the debugging phase, you might need to stop your service prototype. Trying to kill it using the kill command or the Windows™ NT task manager simply won't work. In addition to that the Stop event cannot be reached because of any bug in the core of the executable. Imagine you are a privileged Windows™ NT user, with full local administrator rights. A virus worm could be implemented as an NT service that your mail client will set up. Such a service will be running in quite a malicious way. You cannot stop it using the kill command nor the task manager. Moreover, the virus programmers "forgot" to handle the stop event so that you cannot stop this very service using the net stop command. You need a new tool. Such a tool is also an NT service that you can register provided you have sufficient rights. It allows stopping any service running on your machine. It was actually validated on Windows™ 2000. It is supposed to work on NT 4.0 and XP. Development =========== You may download the proof of concept from our site http://www.securiteinfo.com/download/ntskiller.zip This tool is very easy to handle. It consists of a single executable. First of all the service killer has to be installed using the command line 'skill -i'. Secondly the presented service needs to be started using the command line 'net start skill'. Enter the PID of the service that is to be halted in the field. You can reiterate this operation, as many times as required, if you needed to kill several services. Then you may stop the service killer by typing 'net stop skill'. How does it work? On a Windows™ NT-based workstation, two users use the CPU. - The currently logged on user - The local system (that handles the operating system subroutines) The logged user has no impact on the local system, even if this very user is granted with the administrator rights. This is a major difference comparing to UNIX-based systems where the root user can do everything. By default, a system service is launched under the local system account. Therefore, it can handle this account's processes. This is the mean by which one can stop easily any services, even if those services are armed against the stop event. You can program a pesky NT service, which won't stop. To do so, you can use Visual C++, create a new COM project. Check the service .exe option. Alter the Stop event to get the following: void CServiceApp :: Stop() { // removed to refrain the service from stopping: if( m_hStop ) // removed to refrain the service from stopping //::SetEvent(m_hStop); ::AfxMessageBox("I refuse to stop!",MB_OK,NULL); } Because of the fact that the SetEvent method is not called then service is not stopped by the OS, nor the associated process. Conclusion ========== This is a proof a concept of killing presumably protected local system services. This also highlights a system security bias. The Microsoft™ developers seem to have design a boundary between the core system and the users' workspace in order to protect the running system. This is why there are always two distinct users whereas on the UNIX systems the root user might ruin the system since the running OS uses the same root account. However, a bias exists so that a programmer can find a workaround to this designed protection. SOLUTION None