지속적인 취약점 발견: Windows API의 중요한 결함을 발견한 Outlook Patch Analysis
편집 및 추가 기여: 트리샤 하워드(Tricia Howard)
핵심 요약
Akamai 연구원 벤 바네아(Ben Barnea)는 Internet Explorer 구성요소에서 새로운 중요 취약점을 발견했으며, 이 취약점은 CVE-2023-29324로 지정되었고 CVSS 기본 점수는 6.5입니다.
이 취약점으로 인해 Windows API 함수 MapUrlToZone이 원격 경로를 로컬 경로로 잘못 인식할 수 있습니다.
MapUrlToZone은 일반적으로 보안 수단으로 사용됩니다. 특히 이 함수는 중요한 Outlook 취약점 CVE-2023-23397을 방어하는 데 사용되었으며, 3월 패치 화요일에서 패치된 취약점입니다.
인터넷에서 인증되지 않은 공격자는 이 취약점을 악용해 강제로 Outlook 클라이언트가 공격자 제어 서버에 연결하도록 합니다. 이로 인해 NTLM 인증정보 도용이 발생합니다. 제로 클릭 취약점이므로 사용자 상호 작업 없이 트리거될 수 있습니다.
모든 Windows 버전이 이 취약점의 영향을 받습니다. 따라서 Windows의 모든 Outlook 클라이언트 버전은 악용될 수 있습니다. 하지만 Microsoft에 따르면 3월 업데이트가 적용된 Exchange 서버는 취약한 기능을 없애 취약한 클라이언트가 악용되는 것을 방지합니다.
이 문제는 Microsoft에 공개되어 2023년 3월 패치 화요일에서 처리됐습니다.
서론
2023년 3월 패치 화요일에서 해결된 취약점 중에는 CVE-2023-23397로 지정된 중요한 Outlook 취약점도 포함되어 있습니다.
공격자는 이 취약점을 통해 강제로 Outlook 클라이언트가 공격자의 서버에 연결하도록 할 수 있습니다. 이렇게 하면 클라이언트가 NTLM 인증정보를 머신에 전송하기 때문에 공격자는 오프라인으로 비밀번호를 해독하거나 릴레이 공격에 사용할 수 있습니다. 이 취약점은 사용자 상호 작용 없이(제로 클릭) 인터넷에서 원격으로 악용될 수 있습니다.
Microsoft Threat Intelligence에서 평가한 바와 같이 러시아의 한 공격자는 약 1년 동안 유럽 정부, 운송, 에너지, 군사 부문의 여러 기업을 대상으로 한 표적 공격에 이 취약점을 사용했습니다.
Akamai는 패치 분석 과정에서 이 중대한 취약점에 대한 수정 사항을 우회하는 방법을 발견했습니다. 이 블로그 게시물에서는 원래 취약점, 이에 대한 패치, 해당 패치의 우회 방법 등을 설명합니다.
원래 취약점
3월에 패치된 Outlook 취약점은 공격자가 맞춤형 알림음을 사용해 미리 알림을 포함한 메일을 보내면 트리거됩니다. 공격자는 이 맞춤형 알림음을 확장된 MAPI 프로퍼티인 PidLidReminderFileParameter를 사용해 경로로 지정합니다. 공격자는 클라이언트가 SMB 서버에서 사운드 파일을 가져오도록 트리거하는 UNC 경로를 지정할 수 있습니다. Net-NTLMv2 해시는 원격 SMB 서버에 대한 연결의 일부로서 협상 메시지로 전송됩니다.
이 문제를 해결하기 위해 이제 코드에서 MapUrlToZone을 호출해 경로가 인터넷 URL을 참조하지 않는지 확인합니다. 참조하는 경우 맞춤형 알림음 대신 기본 알림음이 사용됩니다.
방어 우회
먼저 Outlook의 관련 코드 흐름을 살펴보겠습니다. 맞춤형 사운드 파일을 로딩할 때 다음과 같은 두 가지 중요 기능이 호출됩니다.
MapUrlToZone - URL의 영역을 반환하며, 경로가 인터넷이 아닌 로컬, 인트라넷 또는 신뢰할 수 있는 경로인지 확인하는 데 사용됩니다.
CreateFile - 사운드 파일의 핸들을 엽니다
참고: SearchPath도 CreateFile 앞에 호출되지만 경로를 비슷하게 처리하기 때문에 이해를 쉽게 할 수 있도록 돕기 위해 여기서는 CreateFile만 언급하겠습니다.
우회를 찾으려면 MapUrlToZone에서 로컬, 인트라넷 또는 신뢰할 수 있는 영역으로 간주하고 CreateFile이 인터넷 도메인으로 취급하는 경로를 찾아야 합니다.
MapUrlToZone을 호출하려면 다음 PowerShell 스크립트를 사용해 COM(Component Object Model) 을 통해 함수를 호출할 수 있습니다.
MapUrlToZone이 적절한 방어 조치인지 확인하려면 취약점을 트리거한 동일한 경로, 즉 인터넷 도메인이 있는 절대 UNC 경로에서 MapUrlToZone을 호출해 테스트할 수 있습니다. MapUrlToZone은 경로가 예상대로 인터넷 영역에 있음을 나타내는 3을 반환합니다.
PS C:\Users\research1>[IEZones]::MapUrlToZone('\\Akamai.com\file.wav')
3
교묘하게 로컬 디바이스 경로를 사용해 UNC 경로를 조정할 수 있습니다.
PS C:\Users\research1>[IEZones]::MapUrlToZone('\\.\UNC\Akamai.com\file.wav')
3
위에서 보듯이 MapUrlToZone은 경로를 여전히 인터넷 영역으로 식별하므로 수정 의도대로 차단될 수 있습니다.
그러나 "UNC\" 뒤에 다른 ‘\’를 추가하면 MapUrlToZone은 로컬 경로를 의미하는 0을 반환합니다.
PS C:\Users\research1>[IEZones]::MapUrlToZone('\\.\UNC\\Akamai.com\file.wav')
0
따라서 MapUrlToZone은 이 URL이 로컬이라고 결론을 내립니다. 이제 해야 할 중요한 질문은 'CreateFile은 이 URL에 대해 어떻게 판단하나요?', 'SMB를 통해 로컬 파일에 접속하거나 이를 다운로드할 수 있나요?' 등입니다.
정답은...
그림 1: UNC 경로로 CreateFile 호출해 DNS를 요청으로 이어지는 시뮬레이션
간단합니다! Akamai.com 의 IP를 가져오기 위해 DNS 요청을 보냈습니다(그림 1). MapUrlToZone이 로컬이라고 결론을 내렸지만 아직 CreateFile이 인터넷에 요청을 보내게 만드는 경로를 찾은 것 같습니다!
이제 추가된 방어를 우회해 원래 Outlook 취약점을 트리거해 보겠습니다.
그림 2: 일정 이벤트를 트리거해 원격 서버에 대한 NTLM 인증을 유도합니다.
그림 2에서 볼 수 있듯이 알림이 나타나면 Outlook이 원격 서버에 연결되어 NTLM 인증을 받습니다.
Microsoft에 따르면 3월 소프트웨어 업데이트가 설치된 Exchange 서버에서는 PidLidReminderFileParameter 프로퍼티가 삭제되어, 맞춤형 사운드 파일 기능이 제거됩니다. 따라서 패치가 적용되지 않은 Exchange 서버에서 Outlook 클라이언트를 실행하는 머신만 이 문제에 취약합니다.
근본 원인
이 문제는 Windows에서 경로를 복잡하게 처리하기 때문에 발생하는 것으로 보입니다.
MapUrlToZone은 경로 '\\.\UNC\\Akamai.com\file.wav'를 ‘/.//UNC//Akamai.com/file.wav’로 잘못 변환하는 CreateUri 함수를 호출합니다.
후자의 경로에 의해 어떤 접속이 트리거되는지 확인하려면 제임스 포쇼(James Forshaw)의 블로그 게시물에 있는 ConvertDosPathToNtPath 스크립트를 사용할 수 있습니다.
PS C:\Users\research1> ./DosToRelativeNT.exe /.//UNC//Akamai.com/file.wav
Converting: '/.//UNC//Akamai.com/file.wav'
To: '\??\C:\UNC\Akamai.com\file.wav'
Type: RtlPathTypeRooted
FileName: file.wav
FullPathName: 'C:\UNC\Akamai.com\file.wav'
이제 이 경로가 로컬 C: 드라이브의 'UNC'라는 디렉터리를 가리키는 것을 볼 수 있습니다. 분명히 로컬 디렉터리이기 때문에 MapUrlToZone은 0을 반환합니다.
반면에 CreateFile은 먼저 RtlpDosPathNameToRelativeNtPathName을 호출해 원래 경로를 DOS 경로에서 NT 경로로 변환합니다. 다시 한 번, 스크립트를 사용해 변환이 어떤 출력 결과를 가져오는지 관측할 수 있습니다.
PS C:\Users\research1> ./DosToRelativeNT.exe \\.\UNC\\Akamai.com\file.wav
Converting: '\\.\UNC\\Akamai.com\file.wav'
To: '\??\UNC\Akamai.com\file.wav'
Type: RtlPathTypeLocalDevice
FileName: file.wav
FullPathName: '\\.\UNC\Akamai.com\file.wav'
이번에는 결과가 로컬 드라이브를 가리키지 않습니다. 그렇다면 SMB 요청이 트리거되는 이유는 무엇일까요? 위의 스니펫에서 볼 수 있듯이 결과 경로는 '\??\UNC\Akamai.com\file.wav'입니다. 이 NT 경로에 접속하면 오브젝트 관리자가 IO 요청을 MUP(Multiple UNC Provider) 드라이버로 라우팅합니다. (이는 "UNC"에 대한 글로벌 오브젝트 디렉터리 입력값이 "\Device\mup"에 대한 상징적인 링크이기 때문입니다.) RtlpDosPathNameToRelativeNtPathName이 추가 ‘\’를 제거하거나 축소했기 때문에 경로에 인터넷 도메인 이름만 포함됩니다.
이러한 혼란은 사용자 제어 경로에서 MapUrlToZone을 사용한 다음 동일한 경로에서 파일 운영(CreateFile 또는 유사한 API 등)을 사용하는 다른 프로그램에서 취약점을 일으킬 수 있을 것입니다. 또한 CreateUri를 호출하는 프로그램에서 발생하는 다른 문제를 배제할 수 없습니다.
탐지 및 방어
Microsoft는 원래 Outlook 취약점의 탐지 및 방어를 위한 포괄적 가이드를 발표했습니다. 관측 결과, 지정된 모든 방법은 PidLidReminderFileParameter 프로퍼티에 지정된 URL에 의존하지 않기 때문에 새로운 취약점에 적용 가능합니다.
요약
이 취약점은 패치를 면밀히 조사해 새로운 취약점과 우회를 발견한 또 다른 예입니다. 특히 이 취약점의 경우 문자 하나를 추가하면 중요 패치를 우회할 수 있습니다.
맞춤형 알림음 기능은 사용자에게 가치를 제공하는 것보다 더 많은 보안 리스크를 야기하기 때문에 완전히 제거되어야 합니다. 이는 제로 클릭 매체 구문 분석 공격표면으로 잠재적으로 심각한 메모리 손상 취약점을 포함할 수 있습니다. Windows는 어디서나 사용되기 때문에 이처럼 진화한 공격표면을 제거하면 매우 긍정적인 효과를 기대할 수 있습니다.
Akamai는 고객과 커뮤니티를 보호하기 위한 지속적인 노력의 일환으로 패치와 기타 시스템을 지속적으로 분석해 취약점을 찾을 것입니다. Akamai의 최신 보안 리서치를 확인하려면 Twitter에서 Akamai를 팔로우하세요.
이 문제를 해결하는 데 보여준 Microsoft의 협력과 신속한 대응에 감사드립니다.
