bugtraq - Win32: Postmessage API security flaw

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: 13 Mar 2003 21:07:08 -0000
From: Palan <palan@...ealbox.com>
To: bugtraq@...urityfocus.com
Subject: Win32: Postmessage API security flaw

Hello,

I would like to bring to your notice a certain vulnerability that has 
existed in Win 9x platforms for many years and now in Win2k/XP. Most of 
us our familiar with password revealers and password stealing trojans. 
Though flaws in Windows Messaging API have been show before this one 
relates to Windows 2000/XP WM_GETTEXT and EM_SETPASSWORDCHAR message.

The idea behind password capture is a concept called windows sub 
classing. You send a SendMessage API with the WM_GETTEXT to the password 
edit box it will give you the password stored in the edit box control. 
SendMessage API has been secured in Win2k, it will not let you send a 
WM_GETTEXT message to another processes window that doesn’t below to the 
current process thread. 

The traditional exploit would look like this:

        ‘Visual Basic Code Snippet
        'The WM_GETTEXT technique has been blocked in Windows 2k/XP
        nchrs = SendMessage(hwnd, WM_GETTEXTLENGTH, 0, 0) + 1
        pStr = Space$(nchrs)
        nchrs = SendMessage(hwnd, WM_GETTEXT, nchrs, ByVal pStr)

But the same password revealing functionality is possible with the same 
relative easiness as before, due to a vulnerability in PostMessage API. 
PostMessage API does not seem to check the handle and the type of the 
message before sending a message to any message queue. 

What I’ve shown below demonstrates that we can copy message from a 
password edit box control by acting like a regular application message.  

        'SendMessage posts the message and activates the message 
        'queue immediately  
        'Postmessage waits for the app to service the message queue
        ‘hwnd is the target Edit box handle
        'Get the password character from the Edit box
        current_passchar = SendMessage(hwnd, EM_GETPASSWORDCHAR, 0, 0)
        'Disable the Password Character
        'Only Post Message will work for SETPASS in win2k
        ret = PostMessage(hwnd, EM_SETPASSWORDCHAR, 0, 0)

This will unmask the password in the field after a few milliseconds; 
using a combination of Clipboard copying techniques this flaw could be 
dangerous.

As application programmers what you can do:

1.In your Win32 program’s make sure you handle the Message Queues for the 
Password text boxes, kill all EM_SETPASSWORD and WM_GETTEXT messages.
2.Harden your registry key access, eg. Run/RunOnce keys especially in the 
most neglected hive: HKEY_CURRENT_USER.

Finally some day PostMessage API has to be corrected so that it checks 
the handle and the type of the message before sending a message to any 
message queue.

-Palan

Researcher, Networking Lab,
Virginia Tech.
palan@...ealbox.com