system security vulnerabilities, an overview and demonstration
This page contains supplementary material to the presentation "Event-driven system security
vulnerabilities, an overview and demonstration" given at the Hack In The Box 2003
Security Conference which took place on Dec 11-13, 2003 in Kuala
The event-driven model is used to implement software systems such as
graphical user interfaces (GUIs). An example of such a GUI is Microsoft
Windows which we examine in detail. In an event-driven system,
applications communicate with each other and with the system through
events. While in Windows NT/2000/XP/2003 there is memory protection
between applications belonging to different users, there is no
protection against receiving events. Thus, events turn out to be an
avenue of attack. In this presentation we explain the basics of
event-driven systems, provide demonstrations, give an overview of
existing work on security vulnerabilities in event-driven systems and
discuss future developments.
This page supersedes the contents of http://www.isg.rhul.ac.uk/~simos/event_demo/,
created on May 2002 and made public early July 2002.
Under Presentation files you can
find the presentation in different file formats. Under Supplementary files you can find
source code and binaries (Win32, static builds) of utilities shown
during the presentation.
- MySpy-1.4.exe, demonstration
application to locate window objects and send events (Win32 binary,
demonstration application to locate window objects and send events
demonstration application to enumerate desktop windows and window
stations (source code, also includes Win32 binary, static build)
- Test document.txt, text
document (it is referenced in the presentation)
demonstration application to demonstrate the WM_TIMER issue (Win32
binary, static build)
demonstration application to demonstrate the WM_TIMER issue (source
Documentation for MySpy tool
This application is provided under the GNU Public License. Running this
application implies that you adhere to the license.
Note: Before sending events to
a victim application, you must select one using either one of the two
methods in Area 1.
In area 1, you select the window object. You drag and drop the
cross-hair to the visible window object of the victim application.
Alternatively, you can specify the window object by supplying the
window object handle (assuming it was retrieve with other means). Other
applications that can be used to find window object handles are Spy++
(provided by the Visual C/C++ compiler) and WinSpector (google on
"WinSpector" for the Website URL).
Area 2 shown under what credentials you execute MySpy. You can choose
to run this application as a normal/restricted user and try to attack
other applications owned by an administrative account. Use the RunAs
facility found in Windows 2000, Windows XP and latter.
Area 3 shows information of the current window handle selected. It
shows the window handle id (in hex), the class name (for example, if it
is an edit control) and the current window text if applicable. For a
label or edit box, the window text is the text shown in the object.
Area 4 is a proof of concept for the retrieval of a password when the
victim user tries to authenticate. It works by sending events to the
edit control (rather than intercepting events, which is the common
case). The interception of events does not work if the attacker runs
with different credentials from the victim user (that is, under two
different accounts). Thus, an attacker can be a restricted user and the
victim an administrator. The victim needs to point to edit box that
contains the password (the edit box shows the password as asterisks).
Then, clicking on "Bring password"
will retrieve the password.
Area 5 allows to make the victim application to execute code located on
its address space, at the address provided above. This is done by
sending the WM_TIMER event and supplying the address given in the edit
box as parameter. The WM_TIMER event carries an address that the victim
application by default executes!. During the first versions of MySpy,
Microsoft did not fix this bug and you could get any application to
divert execution anywhere you pleased (of course, in the address space
of the victim application). With other techniques, it is possible to
inject code into the victim application, calculate where it landed and
divert execution over there. Normally, an application to use the
WM_TIMER event properly, it should "register a timer" with the system.
The fix provided by Microsoft enables the receipt of WM_TIMER events
only if the victim application registers at least one such timer, else
they are rejected. Applications that indeed use timers legitimately
have no system level protection; they have to filter on their own those
WM_TIMER events. For demonstration purposes, we include an test
application that enables one such timer, thus responds to WM_TIMER events. Run
TimerVictim provided at Supplementary
files and select any window control with MySpy. Then, use the
address already supplied by TimerVictim (points to a subroutine that
has special functionality). Finally, hit the Execute button.
At area 6 you can use these buttons to send predefined events to victim
- Close. Sends the WM_CLOSE event to the window handle. Almost all
window controls terminate execution after the receipt of this event.
You can use it to remove window controls from a dialog box (the main
application will probably still execute) or close applications. It can
be used to terminate effectively applications such as Personal
firewalls, Antivirus programs.
- Melt. Sends an event to make a window control writable (so that
you can edit it). Works with edit and other similar controls.
- Freeze. Sends an event to make a window control read-only (so
that no edits can take place). For edit controls only. You can
Freeze/Melt at will.
- Reveal Password. For edit boxes that have the Password Character
attribute (show characters as asterisks). It removes this requirement.
- Set Password Character. Sets the Password Character attribute to
any edit box/control.
- Enable Object. Window controls in general can be enabled or
disabled. This enables already disabled controls. It might be tricky to
retrieve the handle of a disabled control. Not all controls can be
- Disable Object. This disables a control. Try to keep a copy of
the window handle if you wish to enable it latter.
- Enable Object and Click. Does an Enable Object and also simulates a click.
Useful for some dialog boxes that have some protection functionality to
re-disable buttons. With this, you can enable and click very fast.
Add more material from presentation to this page.
Describe here the scrollbar bug
(shown in presentation).
Talk about window stations and desktop windows.
Issues with license agreements ("Click Accept to continue" style).
On "Interface-based" security.
Overview of WinSpector (nice third party tool).
I would like to thank Dhillon Andrew Kannabhiran <dhillon at
hackinthebox dot org> for inviting me and the rest
of the people at the organisation committee for their work to make this
Feel free to contact me at simos74 at gmx dot net.
Page created: 13 Jan 2004
Last updated: 14 Jan 2004
Back to my homepage