Token manipulation integration and proper security setup

[bencikpeter]

• [x] Ensure that CageManager is running with sufficient privileges to perform token manipulation (SE_CREATE_TOKEN_NAME)
• [x] Randomize group name (currently static testname)
• [x] Perform token manipulation & restriction before launching on desktop
• [x] Clean-up after yourself (currently the group created for access to the desktop is left dangling in the system)

[DonatJR]

Randomize group name (currently static testname)

We already create a randomized name for the desktop and labeler window class, maybe you find this code useful:

#include <Rpc.h>
#pragma comment(lib, "Rpcrt4.lib")

// name should be unique every time -> create UUID
UUID uuid;
if (::UuidCreate(&uuid) != RPC_S_OK)
{
    std::cout << "Failed to create UUID" << std::endl;
    return;
}

RPC_WSTR uuid_str;
if (::UuidToString(&uuid, &uuid_str) != RPC_S_OK)
{
    std::cout << "Failed to convert UUID to rpc string" << std::endl;
    return;
}

std::wstring uuid_stl(reinterpret_cast<wchar_t*>(uuid_str));
if (uuid_stl.empty())
{
    ::RpcStringFree(&uuid_str);
    std::cout << "Failed to convert UUID rpc string to stl string" << std::endl;
    return;
}

::RpcStringFree(&uuid_str);

const std::wstring DESKTOP_NAME = std::wstring(L"shark_cage_desktop_").append(uuid_stl);

[bencikpeter]

Currently blocked by #68

[bencikpeter]

Resolved in #72 and #71

[bencikpeter]

In case you are interested, current status update on #71 problems:

• When reverting merge, the original thought was, that ::CreateProcessAsUser fails for some reason and does not spawn any processes. This is not true however

• Processes are actually started (confirmed by calling ::GetExitCodeProcess right after launch, which returns STILL_ACTIVE (259) )

• Right after launch processes crassh (or are killed) returning seemingly random return values (sometimes value that is used to fill uninitialized memory in debug, other times value meaning segfault, etc...)

• The problem lies somewhere in the template token aquisition process because if the token is aquired this way, the crashes happen

       ULONG sessionId = ::WTSGetActiveConsoleSessionId();
    if (!WTSQueryUserToken(sessionId, &userToken)) {
        std::wcout << L"Cannot query user token";
        changeTcbPrivilege(false);
        return std::nullopt;
    }
    HANDLE duplicatedUserToken = nullptr;
    if (!DuplicateTokenEx(userToken, MAXIMUM_ALLOWED, NULL, SecurityImpersonation, TokenPrimary, &duplicatedUserToken)) {
        std::wcout << L"Cannot duplicate token" << std::endl;
        return std::nullopt;
    }

• if the tepmlate aquisition is changed to this, everything works seamlessly (except the process does not have proper access rights)

    HANDLE currentProcessHandle;
    HANDLE userTokenHandle;
    currentProcessHandle = GetCurrentProcess();
    if (!OpenProcessToken(currentProcessHandle, TOKEN_ALL_ACCESS, &userTokenHandle)) {
        wprintf(L"Error getting token for privilege escalation\n");
        return std::nullopt;
    }
    return userTokenHandle;

[DonatJR]

Thank you for the update! :) and tell us if you need help of any kind from us ;)

[bencikpeter]

I think I’ve mostly figured that out by now... now I am trying to get out of the git hell created by that revert 😅

[SailReal]

Sounds awesome 👍! What kind of problems have you now because of the revert?

[bencikpeter]

Well... because of the revert, all the reverted changes cannot be merged into the develop branch again due to the fact, that git considers them already merged and revert is viewed as a more recent change so it ignores everything until revert and includes only changes that happened afterwards.

Obvious solution of cherry-picking a revert commit into my feature branch, then "reverting a revert" (yeah I know 😅) and then applying additional fixes does not work, due to the fact that the revert didn´t happen on develop directly but instead on a separate branch and then was merged, which messes up the history even more....

What should work is creating a new branch, cherry-pick individual commits to it, iteratively resolve conflicts and then merge (which will create new commit hashes so they wont be ignored anymore). But... that´s like 13 commits that are interdependent with a different pull request and a branch that was merged and deleted in a meantime... so a proper git hell 😬

[bencikpeter]

Git hell already resolved and changes posted in #91.

Moral of the story: don´t revert through PR, do it directly on develop

[DonatJR]

Ugh, sorry to hear the revert did so much damage. :/