[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20030321213821.27566.qmail@mx1.ovh.net>
Date: Fri, 21 Mar 2003 21:38:21 GMT
From: "tomotocigare" <tomotocigare@...uriteinfo.com>
To: bugtraq@...urityfocus.com
Subject: NT Service Killer
Introduction
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.
Discovered by
TomotoCigare
tomotocigare@...uriteinfo.com
http://www.securiteinfo.com
Powered by blists - more mailing lists