Understanding Repurposing of Window and Thread Messages

Applications running on the Windows operating system use messages to control how the applications behave. Every time a user clicks a button, moves the mouse, presses a key on the keyboard, and so forth, a message is sent to the application. The application chooses which messages it listens to and handles only those specific events. These messages can be repurposed to cause a security problem in an method known as shatter attacks.

The problem with messages is that any application can send a message to another application, and the recipient application has no way of determining who sent the message. Nothing prevents a lower privileged application from sending a message to an application that is running with higher privileges. As a result, if a high privilege application accepts messages, it might allow a lower privileged account to perform unexpected actions in the high privilege security context, including running arbitrary code.

To send messages in the Windows operating system, an attacker needs to run code on the box. However, this code can run as a lower privileged account and attack an account with higher privileges. For example, an attacker might be able to escalate privileges from Guest to System (an account that allows accessing everything on the computer).

Although this problem has existed since the early days of the Windows APIs, Chris Paget realized the security implications and released a paper ( http://security.tombom.co.uk/shatter.html ) that explains in depth the background of the vulnerability and why it is a problem.

Testing for Shatter Attacks

Winspector ( http://www.windows-spy.com/ ) enables you to enumerate all processes, windows, and window messages on a machine at run time. It is a lot like Spy++, which is a tool available with Microsoft Visual C++, but has some extra features that will help identify which windows a process creates. By using Task Manager or Process Explorer to determine which user started a process and then Winspector to determine whether any windows were created by a high privileged user, you might be able to wreak some havoc, such as a shatter attack. The user account that creates specific windows is not always the same account that starts the process. Some applications use impersonation to create windows as an account with less or greater privileges as the account that started the process. The next step is to write code to send messages to the message pump running with higher privileges in an attempt to elevate privileges. Use PostThreadMessage , PostMessage , or SendMessage to construct the messages. Three particularly common ways to craft malicious messages are buffer and integer overruns, callback function pointers, and class or interface pointers passed in the parameters of the windows messages. Another generic way is to manipulate the UI, which governs settings.

If you have access to the source code of the target application or have permission to disassemble it, find where each custom message is handled, and assess how the parameters are used and what can happen if the attacker can specify arbitrary parameters. To attack/test the custom message handlers, you will need to call RegisterWindowMessage as well. In addition to targeted testing, fuzz testing might also be worthwhile.