The “Scob” virus last week that was swimming around the web reportedly was capturing keystrokes and sending them back to a russian site somewhere. Its unclear if the recipients of this data were sophisticated enough to actually use the data they stole, but if they were, the poor souls that lost their data could be in for real trouble.
The notion of “Stealing Keystrokes” has me thinking. I’m no expert on keyboard drivers in windows, but why is it that a 3rd party application can be installed in windows to steal keystrokes which were intended for a different application? Just like we have segmented memory today, shouldn’t we have segmented keystrokes? In Unix, when I press a key on my virtual terminal, you’d have to be super-user to steal it. (XWindows probably opens up a whole set of holes, but lets not talk about that yet)
So, why not write some sort of driver inside of windows to protect the keyboard messages? Maybe some types of keys, like control-keys, shift-keys, etc would still be sent around globally so that hotkeys can work and such. But for regular old keypresses, is there a way we can make sure they only arrive at the intended application?
We know that these virus attacks are going to get worse. I think we need to start protecting even the individual subsystems in windows.
I wish I were proposing a better “solution” here, rather than just complaining about shortcomings…. I’ll do some research and see if I can’t learn anything.
Hi Mike,
Capturing key strokes in Windows is a very easy thing to do (its built into Windows). It is done during the event message processing in Windows by using “hooks”. Essentially, any event can be intercepted before it is processed!
There are two types of hooks. Thread specific hooks and System wide hooks. A thread specific hook is associated with particular thread only (Any thread owned by the calling process.). If you want to associate the hook with other processes and threads, you use a system wide hook. There is a hook procedure associated with a hook. This procedure is always called when the particular event occurs. For eg. the keyboard. When there is an event associated with the keyboard, this hook procedure is called. The hook is set by calling the function SetWindowsHookEx( ). The hook is removed by calling UnhookWindowsHookEx( ).
Hooks are very useful and powerful, but as you can see, can be used for malicious intent…
Steve
Thanks, Steve. I’ve used the keyboard event hooks myself, and you are right, they are easy easy to hijack.
I guess thats my point; seems like there is room for someone to write a utility that plugs this hole. Application X should not be able to steal keystrokes from Application Z – ever. I am sure that some utilities (like hotkey stuff) will break if you plug this hole. But, its pretty important to make sure that keystrokes get to their proper destination; otherwise we’ve got this whole class of evil viruses/spyware to worry about…
Mmmm, looks to me that the best approach would be to control the hooking. You would have to intercept calls to SetWindowsHookEx() and only let “trusted” applications have the ability to hook the keyboard or have access to that call at all. Im not sure how easy this would be to do. But, this would at least make it more secure and block the majority of the keystroke stealers Steve