fortra/cve-2024-6769Windows 시스템에서 DLL 하이재킹과 활성화 캐시 중독(activation cache poisoning)을 연계하여 중간 무결성(medium integrity)에서 높은 무결성(high integrity)으로 권한을 상승시키는 CVE-2024-6769에 대한 기술 문서 및 PoC입니다.
이 블로그는 두 가지 연쇄 버그에 관한 것입니다. 1단계는 ROOT 드라이브 리매핑으로 인한 DLL 하이재킹 버그이며, 2단계는 CSRSS 서버가 관리하는 활성화 캐시 중독 버그입니다.
1단계는 BlueFrost Security의 Nicolás Economou가 Ekoparty 2023에서 발표한 "I'm High"라는 프레젠테이션에서 자세히 소개되었습니다. 그는 당시 Microsoft가 아직 패치하지 않은 취약점을 악용하는 방법을 설명했습니다. 이를 통해 MEDIUM INTEGRITY 사용자가 제한된 HIGH PRIVILEGES를 가진 상태로 권한이 상승될 수 있었지만, 완전한 관리자가 되기 위한 모든 액세스 권한은 없었습니다.
2단계는 해당 컨퍼런스에서 발표되지 않았지만, 연구를 시작하기 위한 몇 가지 단계가 제안되었습니다.
먼저 서론적 맥락을 제공하기 위해 1단계를 검토하겠습니다. 그런 다음 제한된 HIGH INTEGRITY에서 완전한 관리자로의 전체 권한 상승을 달성하는 세부 사항을 다루는 2단계 연구에 대해 자세히 살펴보겠습니다. 여기에는 모든 Windows 버전을 위한 두 단계 모두의 완전한 동작 PoC가 포함되며, Windows 10, Windows 11, Windows Server 2022 및 Windows Server 2019에서 모든 업데이트가 적용된 상태로 성공적으로 테스트되었습니다.
이 단계의 유일한 요구 사항은 초기 프로세스가 MEDIUM INTEGRITY LEVEL에서 시작되고 사용자가 Administrators 그룹에 속한다는 것입니다.
1단계 악용은 다음 단계로 요약할 수 있습니다.
예: 디스크를 다음에서 리매핑
"C:\" → "C:\users\public"
이렇게 하면 "system32" 폴더도 다음에서 리매핑됩니다.
"C:\windows\system32" → "C:\users\public\windows\system32"
이러한 영향을 받는 프로그램 중 하나는 HIGH INTEGRITY LEVEL로 실행되지만 관리자 권한이 없는 CTFMON입니다.
일반적으로 CTFMON은 실제 system32 폴더에서 MsCtfMonitor.dll이라는 모듈을 로드하려고 하지만, ROOT 드라이브가 리매핑되었기 때문에 우리가 제어하는 가짜 system32에서 MsCtfMonitor.dll을 찾습니다. 이 폴더에는 동일한 이름의 조작된 DLL을 만들어 배치할 수 있습니다.
이 시점에서 가짜 system32 폴더에 우리 버전의 MsCtfMonitor.dll을 배치하면 해당 DoMsCtfMonitor 함수가 호출되어 HIGH INTEGRITY LEVEL에서 우리 코드를 실행합니다.
동시에, 해당 프로세스가 HIGH INTEGRITY LEVEL임에도 불구하고 관리자 권한이 없음을 확인할 수 있습니다.
Nicolas는 Ekoparty 프레젠테이션에서 악용을 완료하기 위한 다음 단계를 제안했습니다.
단순해 보이지만, 리버싱과 디버깅에 많은 시간이 필요합니다.
이 공격 벡터에 대해 조금 더 파고들면서, 활성화 컨텍스트 캐시 중독이 일부 익스플로잇에서 사용되어 왔음이 분명해졌습니다. 따라서 추가적인 맥락과 통찰을 얻기 위해 이전에 악용이 어떻게 수행되었는지 배우는 것이 가치가 있습니다. 이 악용에 대한 자세한 내용은 Zero Day Initiative의 분석 자료인 *Activation Context Cache Poisoning: Exploiting CSRSS for Privilege Escalation*에서 확인할 수 있습니다.
활성화 캐시는 프로그램이 특정 버전을 요구하는 라이브러리를 로드하려고 할 때 사용됩니다.
예를 들어, 애플리케이션이 C:\Windows\System32\comctl32.dll을 로드하려고 할 때, 해당 위치의 comctl32.dll이 애플리케이션이 필요한 버전이라는 보장이 없습니다. 이것이 활성화 컨텍스트 캐시(Activation Contexts Cache)의 기본 사용 사례입니다. 프로그램은 새 활성화 컨텍스트 항목을 캐시에 추가하도록 CSRSS 서버에 요청을 보낼 수 있으며, 이를 통해 프로그램이 필요한 특정 라이브러리 버전을 로드할 수 있습니다.
이 목적을 위해 소위 매니페스트(manifest)가 사용되며, 이는 XML 형식입니다. 일반적으로 EXE 또는 DLL 파일에 리소스로 내장됩니다. 그렇지 않으면 Windows는 프로그램의 실행 파일이 있는 동일한 폴더에서 매니페스트 파일을 검색합니다.
위에서 언급한 URL에는 PATH TRAVERSAL 기술을 통해 공격자가 제어하는 디렉터리에서 advapi32.dll 라이브러리를 로드하도록 시스템을 속이는 것과 같은 오래된 익스플로잇에서 사용된 매니페스트 파일의 예가 있습니다.
물론, 사용되던 일부 공격 벡터는 패치되었고 일부 새로운 기술이 발견되었습니다. 또한 Windows 11 22H2의 2022년 10월 패치에는 새로운 검사가 추가되었습니다.
이 패치가 적용된 후, **활성화 컨텍스트(ACTX)**를 등록할 때의 검사는 캐시에 새 항목을 추가하는 프로세스의 RID가 이를 사용할 프로세스의 RID와 같거나 더 높은 경우에만 우회할 수 있습니다.
winnt.h에서 RID 값을 확인할 수 있습니다.
이 검사를 우회하기 위한 제안은 조작된 DLL이 실행되는 CTFMON 프로세스에서 활성화 컨텍스트 요청을 생성하는 것입니다. 이 조작된 DLL은 RID=0x3000을 가지며, 항목이 캐시에 추가된 후 RID=0x3000인 TCMSETUP이 tapi32.dll을 로드합니다.
단계를 따르려는 시도 동안, CreateActCtx를 사용하여 ACTX를 등록하기 위해 가능한 모든 조합을 시도했습니다. 그러나 항상 이를 회피하는 검사가 있었기 때문에 불가능했습니다.
이 함수는 사용자 영역에 있으며 kernel32.dll에서 내보내진다는 점에 유의해야 합니다. DLL을 메모리에서 패치하면 검사를 우회할 수 있습니다. 그다지 우아하지는 않지만 가능하며 작동할 것입니다.
Nicolas의 프레젠테이션 슬라이드는 LOW LEVEL을 사용하도록 제안합니다. 그러나 윙크하는 얼굴을 보면, 패치 없이 이 버그를 악용할 때 CreateActCtx를 사용하는 것이 더 나은 옵션이 아님이 분명했습니다.
**ALPC(Advanced Local Procedure Call)**는 Windows 운영 체제 내에서 고속으로 메시지를 전송하는 데 사용되는 프로세스 간 통신 메커니즘입니다. 표준 Windows API와 달리 ALPC는 애플리케이션에서 직접 사용할 수 없습니다. 대신 Windows 운영 체제의 구성 요소만 접근할 수 있는 내부 메커니즘입니다. (그리고 우리도요.)
추가 연구를 통해, 일부 오래된 캐시 중독 익스플로잇이 서버와 직접 통신하기 위해 ALPC를 사용한다는 것을 발견했습니다. 예는 Philip Tsukerman의 기사 *Activation Contexts—A Love Story*에서 볼 수 있습니다.
CsrClientCallServer 함수는 Win32 프로세스와 CSRSS 프로세스 간의 ALPC 인터페이스를 구현합니다.
따라서 서버 역할을 하는 CSRSS 프로세스에 CsrClientCallServer를 사용하여 호출을 시도해야 합니다.
이전 익스플로잇에서 예를 찾던 중, Packet Storm에서 관련 힙 버퍼 오버플로 문제에 대한 페이지를 발견했습니다.
CSRSS 서버가 올바른 패키지로 호출되면, 패킷은 sxssrv.dll 모듈에 속한 BaseSrvSxsCreateActivationContextFromMessage 함수에서 수신됩니다.
이 함수는 수신된 패킷에 대한 포인터 하나만을 인수로 받습니다. 이를 리버싱하기 위해 맞춤형 TotalMessage 구조체를 만들었습니다.
TotalMessage 구조체 패킷은 처음 0x40바이트가 HEADER이고, 그 뒤에 _BASE_SXS_CREATE_ACTIVATION_CONTEXT_MSG 구조체인 내장 활성화 컨텍스트 메시지가 옵니다.
TotalMessage 구조체는 아래에서 확인할 수 있습니다.
그리고 여기에 _BASE_SXS_CREATE_ACTIVATION_CONTEXT_MSG 구조체**:**가 있습니다.
이 구조체 내부에는 언어 또는 CultureFallbacks, AssemblyDirectory, TextualAssemblyIdentity, AssemblyName에 해당하는 여섯 개의 UNICODE_STRING과, 각각 내부에 하나의 UNICODE_STRING을 포함하는 두 개의 _BASE_MSG_SXS_STREAM 구조체가 있습니다.
아래는 _BASE_MSG_SXS_STREAM 구조체입니다.
서버가 수락하는 유효한 패킷을 생성하는 것이 어렵기 때문에, 그 방법을 자세히 설명할 가치가 있습니다.
