Fonctionnement de NTLM pour comprendre les vols d’identifiants et de condensats du mot de passe des utilisateurs par un simple hameçonnage (phishing)

Récemment, plusieurs techniques ont été publiées, permettant d’exfiltrer les identifiants d’utilisateurs ainsi qu’un condensat de son mot de passe, qui dans le pire des cas est facilement récupérable en clair.

La technique est finalement assez simple : héberger du contenu sur un (faux) partage réseau sur internet (similaire aux partages de fichiers sur le réseau interne des entreprises) puis demander une authentification permettant de récupérer un « défi-réponse » (ou «Challenge-response»).

Pour se prémunir de cette famille d’attaque, il faut bien évidemment n’ouvrir que les flux strictement nécessaires sur ses firewalls, ne pas autoriser les flux SMB vers internet et faire passer tous les flux des postes de travail vers internet par un proxy bien configuré.

Vol de condensat NTLM avec Outlook

Lors de la réception d’un mail au format RTF contenant un objet OLE pointant vers un partage de fichiers SMB, une faille dans Outlook permettait le traitement de l’objet OLE sans interaction avec l’utilisateur, dès réception du mail.
https://insights.sei.cmu.edu/cert/2018/04/automatically-stealing-password-hashes-with-microsoft-outlook-and-ole.html
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-0950

Vol de condensat NTLM avec Office

La fonctionnalité subDoc permet d’inclure le contenu d’un autre document dans un document Office.
Il est possible de spécifier le chemin vers le fichier à inclure et donc de mettre un lien HTTP ou un lien de partage SMB.
Dans le cas du lien HTTP, cela permettra d’assurer un suivi des ouvertures du document. Dans le cas d’un lien SMB, en mettant en écoute un outil comme Responder.py, il sera possible de récupérer le condensat NTLMv2-SSP de l’utilisateur.
https://rhinosecuritylabs.com/research/abusing-microsoft-word-features-phishing-subdoc/

Vol de condensat NTLM avec des PDF / BAD PDF

Tout comme pour les documents Office, il est possible d’inclure un lien dans les PDF.
La technique a été découverte par des chercheurs de Checkpoint : https://research.checkpoint.com/ntlm-credentials-theft-via-pdf-files/
Elle consiste à inclure un appel aux fonction GoToR (Go To Remote) ou GoToE (Go To Embedded) puis à inclure un fichier positionné sur un partage SMB.

La problématique est corrigée dans FoxIT Reader, mais pas dans Adobe Acrobat, car Adobe considère qu’il faut plutôt désactiver le Single Sign-On de Windows pour les ressources externes.
https://research.checkpoint.com/ntlm-credentials-theft-via-pdf-files/
https://github.com/deepzec/Bad-Pdf

Tout ceci exploite les « défis-réponses » (ou « Challenge-response »), ce qui demande quelques rappels techniques sur le sujet.

Un peu d’histoire

Du temps où Microsoft et IBM travaillaient ensemble sur le système d’exploitation OS/2, ils utilisaient différents protocoles dont le fameux SMB (Server Message Block) afin d’accéder à des fichiers sur des partages réseau et NetBIOS pour la résolution des noms.

Afin d’assurer un peu de sécurité, un protocole d’authentification basé sur un « défi-réponse » (ou « Challenge-response ») avait été défini. C’est-à-dire que pour réussir l’authentification, il faut résoudre un challenge (ou défi), basé sur un secret, ce qui évite de faire transiter ce secret sur le réseau.
Pour éviter également les risques liés au stockage des mots de passe en clair, côté serveur, ils sont stockés sous forme de condensats (ou empreintes).

LM

La première version du « défi-réponse » était LM (LAN Manager), datant des années 80.
Pour ne pas stocker le mot de passe en clair sur le serveur, celui-ci était stocké sous sa forme LM, détaillée juste ci-dessous.

Pour le « défi-réponse », le client devait réaliser quelques transformations sur son mot de passe et envoyer le résultat au serveur pour vérification.
Pour rentrer dans les détails, LM consiste à faire un chiffrement DES sur le texte « KGS!@#$% » et comme clef le mot de passe, découpé en deux groupes de 7 caractères mis en majuscules :

LM
Fortement inspiré de https://www.blackhat.com/presentations/win-usa-02/urity-winsec02.ppt

Voici quelques exemples :

condensat-LM

LM est considéré comme très faible pour plusieurs raisons :

  • Il est inutile de connaitre le mot de passe de l’utilisateur pour s’authentifier, il suffit d’avoir le bon condensat ;
  • Seuls les 14 premiers caractères du mot de passe sont pris en compte ;
  • La casse des lettres n’est pas prise en compte (le mot de passe est mis en majuscules), donc le mot de passe « TOTO » sera équivalent à « ToTo » ;
  • Si le mot de passe fait plus de 7 caractères, il est coupé en 2 morceaux de 7 caractères, dont un condensat est réalisé pour chaque morceau, ce qui facilite les attaques de cryptanalyse ;
  • Le condensat LM est réalisé à partir de DES (considéré comme faible dès la fin des années 90), algorithme de chiffrement symétrique fonctionnant avec des blocs de 8 et une clef de 7 octets (avec en plus un octet de parité pour détecter les erreurs) ;
  • Le condensat est généré sans diversifiant ce qui signifie qu’un condensat donné correspond toujours au même mot de passe.

Défi-réponse NTLM

Suite aux problématiques de sécurité de LM, Microsoft a publié le protocole « NTLM » (pour New Technology LanManger) en 1993, venant du nom du système d’exploitation de l’époque : Windows NT 3.1.

NTLMv1

Datant des années 90, cette version de défi-réponse utilise le condensat LM.
Pour ne pas stocker le mot de passe en clair sur le serveur et sur le client, celui était stocké sous sa forme LM.

Pour le « défi-réponse », le serveur tirait un nombre de 64bits (8 octets) au hasard et réalisait plusieurs chiffrements DES à partir du condensat du mot de passe de l’utilisateur pour obtenir la réponse au défi :

reponse-au-defi

Le serveur envoyait ensuite le nombre choisi au hasard au client et attendait de lui qu’il réponde avec la bonne réponse.

NTLMv2

Face à la faiblesse cryptographique de DES, en 1996, Microsoft a sorti la version 2 de ce protocole, en même temps que son nouveau système d’exploitation Windows NT 4.0.

Pour ne pas stocker le mot de passe en clair sur le serveur et sur le client, celui-ci est stocké sous une nouvelle forme dite « NT » :

  • Le mot de passe est pris entièrement et encodé en Unicode 16 bits, permettant de supporter les principales langues (chinois, russe, arabe…) ;
  • Le condensat est réalisé à partir de MD4 ;
  • Le condensat est encore généré sans diversifiant ⚠.

Le fonctionnement de ce « défi-réponse » est un peu plus compliqué. Il se base sur l’algorithme de condensat MD5 (aujourd’hui considéré comme faible) sous sa forme HMAC (« keyed-Hash Message Authentication Code »). Pour faire simple, HMAC-MD5 revient à faire tourner deux fois l’algorithme MD5 :

  • Une première fois avec une variation de la clef et un message ;
  • Une seconde fois avec le résultat de la première passe et une autre variation de la clef.

Le client et le serveur tirent chacun un nombre de 64 bits (8 octets) au hasard, se les échangent et procèdent à plusieurs opérations afin d’obtenir une réponse au challenge/défi qui normalement est la même :

hmac-md5

NTLMv2 est également considéré comme faible pour plusieurs raisons :

  • Il utilise LMv2 pour de la rétrocompatibilité, ce qui l’affaiblit ;
  • Il est inutile de connaitre le mot de passe de l’utilisateur pour s'authentifier, il suffit d’avoir le bon condensat. Cette attaque ultra connue se nomme « Pass the Hash » et fonctionne malheureusement encore... Parfois 😉 ;
  • Le condensat NT est généré sans diversifiant ce qui signifie qu’un condensat donné correspond toujours au même mot de passe.

NTLMv2-SSP

Les versions récentes de Windows embarquent une librairie nommée Security Support Provider Interface (SSPI) permettant de gérer plusieurs protocoles de « défi-réponse », dont NTLM mais également Kerberos.
Lors de l’accès à une ressource réseau, c’est NTLMv2-SSP (Security Support Provider) qui est utilisé et il dispose de plusieurs modes :

  • 0 - LM & NTLM response, la version la moins sécurisée basée sur LM et NTLMv1 ;
  • 1 - LM & NTLM – NTLMv2 if negociated, tout aussi peu sécurisé et basé sur LM et NTLMv1 mais avec la possibilité pour le serveur d’utiliser NTLMv2 ;
  • 2 - NTLM response only, utilisation de NTLMv1 mais avec la possibilité pour le serveur d’utiliser NTLMv2 ;
  • 3 - Send NTLMv2 response only, utilisation de NTLMv2 mais les contrôleurs de domaine peuvent accepter LM et NTLMv1 ;
  • 4 - Send NTLMv2 response only and refuse LM, utilisation unique de NTLMv2 mais les contrôleurs de domaine peuvent accepter NTLMv1 ;
  • 5 - Send NTLMv2 response only and refuse LM & NTLM, utilisation seule et unique de NTLMv2.

Etant donné que SSP permet la négociation du protocole de « défi-réponse », une attaque très connue consiste à intercepter un flux d’accès à une ressource réseau en se faisant passer pour le serveur et de lui demander de réaliser un « défi-réponse » faible, comme par exemple LM. Il est alors aisé de retrouver le mot de passe de l’utilisateur. L’outil le plus connu pour réaliser cette attaque est « Responder.py ».
Par contre, ce sont bien les résultats des « défis-réponses » qui sont interceptés ainsi et non les condensats « NT » des mots de passe.

Pour se prémunir de cette attaque, des stratégies de groupe (GPO / Group Policy Object) sont déployées sur les postes et serveurs afin d’interdire la négociation de protocoles faibles.
La GPO est la suivante : Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options -> Network security: LAN Manager authentication level = « Send NTLMv2 response only and refuse LM & NTLM ».

Tout ceci est documenté par Microsoft ici « [MS-NLMP]: NT LAN Manager (NTLM) Authentication Protocol Specification » : https://msdn.microsoft.com/en-us/library/cc207842.aspx