22th Mar 2003 [SBWID-6084]
COMMAND
NT Service Killer
SYSTEMS AFFECTED
Windows NT4, 2000, XP
PROBLEM
tomotocigare [[email protected]] 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