Prev: Help with CHTMLView and Session
Next: leak using Clipboard in Unicode with richedit
From: Joseph M. Newcomer on 13 Dec 2006 17:08
Most processes are created by the user by clicking some icon. Therefore, except in Vista,
they they all run with the user's login credentials, and therefore are hookable.

I once was at a site where I used a hook to snarf passwords (if it isn't blindingly
obvious how to do this, I'm not going to explain it). I snarfed a password from the
top-secret database login screen (and the password I snarfed was "topsecret", which he
assures me is NOT the password to the top-secret database. And I mean top-secret in the
military classification sense!) The database program was launched as an ordinary user
program. (I was demonstrating how trivial it was to attack password security; I wrote the
password snarfer, which included a server to receive the passwords and used UDP messages
to transmit it, over lunch, and still had time to eat a sandwich)

In Vista, this would fail because the database program would be run at an elevated
security level.
joe

On Tue, 12 Dec 2006 08:51:12 -0800, "Alexander Grigoriev" <alegr(a)earthlink.net> wrote:

>Systemwide (desktop-wide actually) hooks can only be set to processes to
>which the hooking process have PROCESS_MEMORY_WRITE access. Thus, it cannot
>be set to a process running with different credentials. So the security is
>not breached by hooks.
>
>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
>news:seson21ntvhv7pi2gn2l811sv3it8felod(a)4ax.com...
>>I am reasonably convinced that Microsoft is totally clueless with respect
>>to hooks and
>> security. The pre-Vista security was a joke, and the key APIs needed,
>> such as
>> EnumerateHooks (I once wrote a specification and sent it to the hook
>> group), to allow
>> security audits, were omitted "by design". Why shouldn't I be able to
>> discover which
>> processes have set system-wide hooks, or for that matter, all hooks?
>> joe
>>
>> On Sun, 10 Dec 2006 13:27:44 GMT, Daniel James
>> <wastebasket(a)nospam.aaisp.org> wrote:
>>
>>>In article news:<eBAeh.242$yC5.98(a)newssvr27.news.prodigy.net>, David Ching
>>>wrote:
>>>> I was told at PDC 2003 (way early, I know) that SetWindowsHookEx would
>>>> continue to work as long as the app doing the hooking had at least as
>>>> much priviledge as the app being hooked.
>>>
>>>So it does for many hook types, AIUI, but the WH_JOURNALXXX hooks are
>>>essentially system-wide hooks -- they don't just hook the current app,
>>>they
>>>hook everything -- so unless they are running at as high a privilege as
>>>anything in the system they have to have a special privilege.
>>>
>>>My point was that there is a "Gotcha" here, because a lot of apps that use
>>>the journal hooks don't actually look at keystrokes to/from other apps --
>>>they only want to log their own input. Maintainers of these apps may not
>>>expect their macro facility to be broken by UAC, and will be in for a
>>>nasty
>>>surprise.
>>>
>>>To implement an appropriate degree of security, here, UAC doesn't have to
>>>block the SetWindowsHook call, it could just filter the hook callbacks so
>>>that the app only saw its own keystrokes unless it had special permission
>>>to see them all. IOW: MS *could* have made UAC less intrusive, here, than
>>>they have.
>>>
>>><irony>
>>>Thanks a bunch, guys.
>>></irony>
>>>
>>>Cheers,
>>> Daniel.
>>>
>> Joseph M. Newcomer [MVP]
>> email: newcomer(a)flounder.com
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: Help with CHTMLView and Session
Next: leak using Clipboard in Unicode with richedit