CreateRCE - CreateUri의 또 다른 취약점
요약
Akamai 연구원 벤 바네아(Ben Barnea)는 Microsoft Windows에서 CVE-2023-35628로 지정된 심각한 취약점을 발견했습니다.
인터넷상의 공격자는 사용자 상호 작용 없이(제로 클릭) Outlook 클라이언트를 대상으로 이 취약점을 악용할 수 있습니다.
취약점은 CreateUri 함수에 의한 경로 구문 분석에 있습니다. 현재 이 취약점을 유발하는 것으로 알려진 2가지 방법은 (1) 조작된 이메일을 Outlook 클라이언트로 보내거나 (2) 사용자가 파일 탐색기를 통해 다운로드한 악성 파일이 포함된 폴더로 이동하도록 유도하는 것입니다.
이 취약점은 Microsoft에 제보되었으며 2023년 12월의 패치 화요일(Patch Tuesday)을 통해 수정되었습니다.
2023년 12월 소프트웨어 업데이트가 설치된 Windows 머신은 이 취약점으로부터 보호됩니다. 또한 2023년 3월 소프트웨어 업데이트로 패치된 Exchange 서버를 사용하는 Outlook 클라이언트는 악용되는 기능으로부터 보호됩니다.
서론
Microsoft는 기업 환경 안팎에서 광범위하게 사용되기 때문에 공격자들에게 크고 수익성 높은 표적이 됩니다. 이에 따라 Akamai는 Microsoft 제품군과 프로토콜에 대한 심층적인 리서치를 진행했으며, 여러 취약점을 발견하고 탐지 및 방어를 지원하는 툴도 개발했습니다.
이 리서치의 일환으로, Akamai는 기존 취약점인 CVE-2023-23397의 패치 과정에서 호출되는 WinAPI 함수 CreateUri에서 새로운 RCE(원격 코드 실행) 취약점을 발견했습니다. 기존 RCE 취약점 체인 은 두 개의 취약점을 결합해야 제로 클릭 RCE를 구현할 수 있었던 반면, 이번에 발견된 취약점은 단독으로 이를 수행할 수 있습니다.. Outlook 외에도 파일 탐색기에서 취약점을 트리거하는 방법도 보여드리겠습니다.
취약점에 관한 이야기
2023년 3월의 패치 화요일을 통해 해결된 취약점 중 하나는 Microsoft가 직접 발견한 Outlook의 심각한 취약점(CVE-2023-23397)으로, 이는 러시아 정부가 후원하는 공격 단체인 Forest Blizzard에 의해 실제 공격에 활용된 바 있습니다.
2023년 12월, Microsoft와 폴란드 사이버 사령부는 동일한 공격자가 최근 해당 취약점을 다시 악용하려 했던 정황을 발견했다고 발표했습니다. 공격자는 이 취약점을 통해 강제로 Outlook 클라이언트가 공격자의 서버에 연결하도록 할 수 있습니다. 이 연결 과정에서 클라이언트는 NTLM 인증정보를 공격자에게 전송하게 되며, 공격자는 이 정보를 오프라인에서 크래킹하거나 릴레이 공격에 활용할 수 있습니다. 해당 취약점은 사용자 상호작용 없이, 즉 제로 클릭으로 인터넷을 통해 원격에서 악용될 수 있습니다.
이 취약점에 대한 패치가 배포된 이후, Akamai는 이를 우회할 수 있는 두 가지 방법과 함께 사운드 관련 구문 분석 취약점도 발견했습니다. 우회 방법과 구문 분석 취약점을 조합하면 Outlook 클라이언트에서 완전한 제로 클릭 RCE 프리미티브로 이어질 수 있습니다.
MapUrlToZone
Outlook 취약점 CVE-2023-23397의 패치에는 사용자 지정 알림음 처리를 담당하는 코드에 MapUrlToZone 함수를 호출하는 로직이 추가되었습니다. 이 호출은 확장된 MAPI 속성인 PidLidReminderFileParameter를 통해 지정된 URL이 인터넷 리소스와 연결되는지 확인합니다.
이 조치는 원래 취약점의 악용을 방지하기 위한 것이지만, 동시에 MapUrlToZone 함수 자체가 새로운 공격 표면이 됩니다. Akamai는 이 MapUrlToZone에 전달되는 경로를 제어할 수 있기 때문입니다.
MapUrlToZone의 구문 분석 과정에서 CreateUri 함수가 호출됩니다. CreateUri는 URI(Uniform Resource Identifier)를 나타내는 IUri 오브젝트를 생성하는 함수로, URL뿐만 아니라 일부 DOS Windows 경로도 구문 분석할 수 있습니다.
CreateUri가 파일 경로(예: file:// scheme 또는 file/directory를 가리키는 Windows 경로)로 호출되면 CrackUrlFile 함수가 호출됩니다. 바로 이 함수에, 이전 블로그 게시물에서 소개한 우회 방법이 포함되어 있었습니다.
새로운 취약점
CrackUrlFile 함수는 시작 단계에서 URL이 들어오면 입력값을 복사한 뒤, PathCreateFromUrlW를 이용해 URL 사본을 Windows 경로로 변환합니다. 작업 버퍼는 동적으로 할당된 것으로 표시되므로 나중에 버퍼를 해제해야 한다는 것을 알 수 있습니다. 함수가 Windows 경로를 받으면 입력 경로에서 직접 작동하므로 포인터를 해제할 필요가 없습니다.
작업 버퍼를 구문 분석하는 과정에서 포인터는 앞쪽으로 이동될 수 있습니다. 예를 들어, 로컬 디바이스 경로("\\.\"또는 "\\?\"로 시작)인 경우 포인터를 네 글자만큼 이동시키고, 디바이스 이름이 "UNC\"이면 네 글자를 추가로 건너뜁니다. 백슬래시가 여러 개 있는 경우 이 함수는 중복된 백슬래시를 지나 버퍼를 전진시킵니다.
우회 방법에 대한 패치를 되짚어보던 중, 2023년 7월에 CrackUrlFile에 우회 방법과 관련이 없는 것으로 보이는 새로운 코드가 추가된 것을 발견했습니다(그림 1).
그림 1: 새로 추가된 코드의 디컴파일
해당 코드는 경로 구성요소가 드라이브 경로인지 루트 경로인지 확인한 뒤, 이에 해당하면 경로를 로컬로 표시합니다. 경로가 드라이브 경로인 경우, 새 코드는 원래 작업 버퍼 포인터를 앞으로 이동된 버퍼 포인터로 덮어씁니다.
이 지점이 버그의 발단입니다. 이동된 포인터가 변수에 저장되고, 이후 원래 작업 버퍼 포인터(PPWorkingBuffer, 그림 1) 값이 동적 할당된 것으로 간주되면 free()가 호출됩니다. 그러나 해당 포인터는 이미 이동된 포인터로 대체된 상태이므로, 결과적으로 malloc이 반환하지 않은 주소에 대해 free()가 호출됩니다. 이로써 공격자는 메모리 할당자에게 악성 청크의 메타데이터를 제공할 수 있는 프리미티브를 얻게 됩니다.
이 취약점이 트리거되려면 먼저 파일 체계 URL을 UNC 경로와 함께 지정해야 합니다. 그런 다음 경로를 드라이브 경로로 표시해야 하므로 공유(C:)를 사용해야 합니다. 취약점을 트리거하는 전체 경로는 다음과 같습니다.
file://./UNC/C:/Akamai.com/file.wav
수정된 코드는 이제 포인터를 저장하는 대신 RtlMoveMemory를 사용해 경로 구성요소의 바이트를 복사합니다.
탐색기를 통한 트리거
이러한 위치를 찾는 것은 리서치 범위를 벗어났지만, 한 가지 간단한 시도를 해보았습니다. 바로 Windows 탐색기를 통해 트리거하는 것입니다.
이를 위해 취약한 경로를 가리키는 단축키(.lnk file)를 만들었습니다. 피해자가 바로 가기 파일이 있는 디렉터리를 확인하면 탐색기에서 취약점이 트리거되어 즉각적인 충돌이 발생합니다(그림 2).
그림 2: PoC의 결과로 탐색기 충돌 발생
이 문제에 취약한지 확인하려면 Explorer를 강제 종료시키는 Akamai 팀의 개념 증명(PoC)을 다운로드해 테스트해 보세요. (사용 전에 Akamai 보안 리서치 보고서에서 PoC의 세부 사항과 리스크를 주의 깊게 읽어보세요.)
요약
이 글은 CVE-2023-23397의 잠재적 영향에 대한 리서치를 마무리하는 마지막 블로그 게시물입니다.
Akamai는 2023년 5월 첫 번째 우회 기법을 발견했을 당시, MapUrlToZone 사용이 새로운 공격 표면을 노출하기 때문에 해당 기능을 제거할 것을 권장한 바 있습니다. 또한 샌드박스 없이 제로 클릭 방식으로 원격 공격자에게 사운드 구문 분석 공격 표면을 노출하는 것은 사용자에게 가치보다 더 많은 위험을 초래할 수 있다고 언급했습니다.
Akamai는 후속 리서치에서 두 가지 우회 방법을 발견하고, 사운드 구문 분석 문제를 찾아냈고, 최종적으로 Windows 경로 구문 분석 메모리 손상 문제를 발견함으로써 이러한 경고가 타당했음을 정확히 입증했습니다.
이 시리즈를 통해 Windows 경로, 사운드 코덱, 다양한 취약점에 대해 새로운 인사이트를 얻으셨기를 바랍니다. 다른 연구자들도 패치를 살펴보고 이를 우회할 수 있는 방법을 생각해 보시기 바랍니다. MapUrlToZone 우회 방법이 더 존재할 가능성을 배제할 수 없습니다.
자세히 알아보기
