Un réseau informatique est vulnérable aux cyberattaques s’il n’est pas protégé de manière adéquate. Un réseau protégé est un réseau qui ne permet pas aux utilisateurs d’accéder librement à différentes ressources.

Ainsi, seul un utilisateur autorisé peut accéder à une ressource spécifique. Il est nécessaire d’intégrer un accès protégé dans un réseau, c’est-à-dire verrouillé. Cela nécessite l’installation de certaines procédures de sécurité. Avec le NT LAN Manager (NTLM), Windows a introduit son propre protocole d’authentification en 1993, mais ce protocole est aujourd’hui considéré comme  obsolète.

NTLM, c’est quoi ?

Windows NT LAN Manager (NTLM) est un protocole d’authentification par challenge-réponse qui permet d’authentifier un utilisateur auprès d’une ressource d’un domaine Active Directory. Lorsque le client demande l’accès à un service associé au domaine, le service envoie un défi au client, lui demandant d’effectuer une opération mathématique en utilisant son jeton d’authentification, puis de renvoyer le résultat de cette opération au service. Le service peut valider le résultat ou l’envoyer au contrôleur de domaine (DC) pour validation. Si le service ou le DC confirme que la réponse du client est correcte, le service autorise l’accès au client.

NTLM est un type d’authentification unique (SSO) car il permet à l’utilisateur de fournir le facteur d’authentification sous-jacent une seule fois, lors de la connexion.

La suite de protocoles NTLM est implémentée dans un Security Support Provider (SSP), une API Win32 utilisée par les systèmes Microsoft Windows pour effectuer une variété d’opérations liées à la sécurité, comme l’authentification. La suite de protocoles NTLM comprend le protocole d’authentification LAN Manager, les protocoles NTLMv1, NTLMv2 et NTLM2 Session.

Le protocole NTLM est largement déployé, même sur les nouveaux systèmes, afin de maintenir la compatibilité avec les anciens systèmes, mais son utilisation n’est plus recommandée par Microsoft car il ne prend pas en charge les méthodes cryptographiques actuelles, telles que AES ou SHA-256. Microsoft en revanche a recommandé l’utilisation de Kerberos comme protocole d’authentification pour Windows 2000 et les domaines Active Directory postérieurs.

NTLM est le successeur de LM, et il a été introduit en 1993 avec la sortie de Windows NT 3.1. Dans LAN Manager(LM), le hachage de chaque mot de passe devait être stocké sur chaque serveur LAN Manager(LM). Cela présentait un risque pour la sécurité ainsi qu’un manque de centralisation des données. Le plus grand changement apporté par NTLM a été l’introduction du concept de contrôleur de domaine. Ces contrôleurs de domaine conservaient les hachages de mots de passe de tous les utilisateurs d’un domaine et étaient les seuls serveurs de confiance pour conserver ces informations. Cependant, NTLM a peu changé la façon dont le mécanisme d’authentification fonctionnait.

Dans Windows NT 4.0 Service Pack 4, Microsoft a introduit une nouvelle version de cette authentification. Appelée NTLM Version 2 (NTLMv2), elle constitue une grande amélioration par rapport à LM et NTLM. Elle utilise des clés beaucoup plus longues pour l’algorithme de hachage et tire parti des mots de passe de plus de 14 caractères. Ces modifications, parmi d’autres changements cryptographiques, font de NTLMv2 un protocole d’authentification beaucoup plus sûr que ses prédécesseurs.

De quelle manière l’authentification NTLM fonctionne-t-elle ?

NTLM est un protocole basé sur le concept de hachage cryptographique, comme expliqué précédemment. Le système Windows stocke les mots de passe des utilisateurs dans un registre spécifique appelé Security Accounts Manager (SAM), ou dans la base de données Active Directory pour les domaines Windows 2000 ou supérieurs. Les mots de passe ne sont jamais stockés en texte clair chaque mot de passe est soumis à un algorithme de hachage à sens unique et le résultat est conservé dans le SAM.

 

 

Lorsque la procédure d’authentification d’un utilisateur sur le domaine est réussie, le contrôleur de domaine envoie des informations au processus de connexion de l’utilisateur sur le poste client.
Ce processus crée un jeton de sécurité sur le poste client de l’utilisateur. Le jeton de sécurité contient une liste de tous les identifiants de sécurité (SID) associés à l’utilisateur. Cette liste comprend le SID du compte utilisateur du domaine de l’utilisateur, ainsi que les SID de tous les groupes d’utilisateurs du domaine dont le compte de l’utilisateur est membre. Le poste client de l’utilisateur stocke ce jeton pour une utilisation future. Le jeton est également utilisé pour démarrer une session interactive ou une session shell de la session. Chaque fois qu’un processus est lancé par le biais de cette session, le jeton de sécurité original est associé à ce processus. De cette manière, Windows impose que tous les processus s’exécutent dans le contexte de sécurité d’un certain compte.

Lorsqu’un utilisateur authentifié tente d’accéder à des ressources (telles que des fichiers) sur son ordinateur client, ce dernier compare le jeton de sécurité de l’utilisateur à la liste de contrôle d’accès (ACL) de la ressource. Si l’ACL ne contient pas l’un des SID du jeton de sécurité, l’accès est refusé. Si la liste de contrôle d’accès contient l’un des SID du jeton de sécurité, l’utilisateur se voit accorder l’accès associé à ce SID dans la liste de contrôle d’accès. Si le jeton contient plusieurs SID (parce que l’utilisateur est membre d’un ou plusieurs groupes), l’autorisation cumulative de plusieurs SID peut être nécessaire pour obtenir le niveau d’accès souhaité. Cette opération est effectuée automatiquement par le sous-système de sécurité.

Lorsque l’utilisateur tente d’accéder à des ressources sur d’autres ordinateurs, comme des serveurs de fichiers, le serveur qu’il contacte doit d’abord contacter un contrôleur de domaine pour construire sa propre copie du jeton de sécurité de l’utilisateur. Le serveur ne peut pas faire confiance au jeton de sécurité présent sur l’ordinateur client de l’utilisateur, car il est possible pour l’utilisateur (Poste client) de le falsifier. Le serveur conserve une copie du jeton de l’utilisateur dans sa mémoire pendant un certain temps, de sorte que les demandes d’accès ultérieures ne nécessitent pas une nouvelle demande à un contrôleur de domaine.

Le protocole NTLM est-il sûr ?

Le protocole NTLM est considéré comme obsolète car il utilise une cryptographie dépassée, vulnérable à plusieurs modes d’attaque. NTLM est également vulnérable aux attaques de type « pass-the-hash » et « brute force ».

L’algorithme de hachage utilisé pour stocker les mots de passe est devenu bien connu. Cela permet aux attaquants de deviner les mots de passe des utilisateurs en faisant exécuter les mots de passe par le hachage jusqu’à ce que le résultat corresponde au résultat stocké dans le SAM. Comme l’algorithme restait constant, de grandes bibliothèques de mots de passe hachés pouvaient être stockées et utilisées pour attaquer rapidement un SAM.

Lorsque Microsoft a commencé à développer Windows 2000, il a décidé qu’un nouveau protocole d’authentification était nécessaire. Ils ont choisi d’implémenter un protocole d’authentification bien établi et basé sur des normes : Kerberos. Le protocole NTLM est bien sûr inclus dans Windows 2000 et Windows Server 2003, car les anciens clients Microsoft – Windows NT 4.0 et antérieurs et toutes les versions de Windows 9x – ne prennent pas en charge le protocole Kerberos.

Microsoft a développé un client Active Directory pour les anciens systèmes d’exploitation Microsoft. Ce client offre non seulement une fonctionnalité améliorée et la compatibilité avec Active Directory, mais aussi la fonctionnalité NTLMv2. Il n’assure pas la compatibilité avec Kerberos. Seuls les systèmes d’exploitation Microsoft Windows 2000 et supérieurs prennent en charge Kerberos.