Bien qu'un élément clé de la cyber-résilience consiste à s'adapter aux changements technologiques, il est tout aussi essentiel de continuer de protéger les éléments qui ne peuvent pas évoluer. Parfois, cela est dû au coût opérationnel de la migration ainsi qu'aux inquiétudes concernant la possibilité de casser des processus critiques en le faisant. Dans d'autres cas, c'est simplement parce que l'équipe informatique n'est pas au courant de l'existence des composants anciens. Mais quelle que soit la raison, l'infrastructure ancienne est une cible de choix pour les attaquants car elle est moins sécurisée que ses alternatives modernes. 

Dans cet article, nous explorons un exemple d'infrastructure ancienne : le protocole d'authentification NTLMv1. Cette première version de NTLM comportait des faiblesses de sécurité critiques, permettant aux attaquants d'exécuter une variété d' attaques basées sur l'identité. Et même s'il a maintenant plus de 30 ans, on peut toujours le trouver dans les environnements de production, ce qui les expose à des risques de compromis extrêmement difficiles à détecter.

Nous montrerons ensuite comment Silverfort permet aux entreprises de surmonter les risques de NTLMv1 avec la découverte, la surveillance et contrôle sur chaque authentification et tentative d'accès qui utilise encore ce protocole archaïque. 

Authentification NTLM : un bref historique

Selon Wikipédia, "Dans un Windows Windows, New Technology LAN Manager (NTLM) est une suite de Microsoft de sécurité destinés à assurer l'authentification, l'intégrité et la confidentialité des utilisateurs. NTLM est le successeur du protocole d'authentification de Microsoft Gestionnaire LAN. La suite de protocoles NTLM est implémentée dans un fournisseur d'assistance à la sécurité, qui combine le Gestionnaire LAN protocoles d'authentification NTLMv1, NTLMv2 et NTLM2 dans un seul package. (NTLM2 combine à la fois NTLMv1 et NTLMv2.) 

NTLMv1 publié en 1993, ​​est un protocole d'authentification par défi-réponse, ce qui signifie que le processus d'authentification s'effectue en trois étapes : 

1. La machine cliente établit une connexion réseau avec le serveur cible.
2. Le serveur envoie un défi à la machine cliente.
3. La machine cliente répond au défi et le serveur autorise ou refuse l'accès en fonction de la réponse.

En 1998, NTLMv2 est sorti sur Windows NT 4.0 SP 4 et est depuis lors la version actuelle du protocole.

Problèmes généraux de sécurité NTLM

Toutes les versions de l'authentification NTLM sont confrontées aux problèmes de sécurité suivants :

1. Manque de salage rend le mot de passe de hachage équivalent, ce qui signifie que si vous êtes en mesure de récupérer la valeur de hachage du serveur, vous pouvez alors vous authentifier sans connaître le mot de passe réel. Cela signifie qu'un attaquant qui peut récupérer un hachage - et il existe différentes façons de le vider de la mémoire de la machine - peut alors facilement accéder à un serveur cible et se faire passer pour l'utilisateur réel.
2. Bien que le serveur valide effectivement l'identité du client, il n'y a pas de validation correspondante de l'identité du serveur, ce qui ouvre la possibilité d'une attaque Man-In-The-Middle (MITM).
3. NTLMv1 n'a pas de défi client - en cas d'attaque sur NTLMv1, l'attaquant peut forcer le client à calculer la réponse NTLMv1 avec un défi serveur connu. Ensuite, l'attaquant peut efficacement deviner le mot de passe de l'utilisateur en comparant la réponse NTLMv1 à un table arc-en-ciel.
4. Manque de MFA le support prive le protocole de toute protection en cas de mot de passe ou de hachage compromis. 

Ces préoccupations ont conduit Microsoft à remplacer NTLM par le plus sécurisé Kerberos protocole d'authentification par défaut dans les environnements AD, tout en conservant NTLM en tant que sauvegarde. Mais même au sein de NTLM, NTLMv1 est nettement moins sécurisé que son successeur, NTLMv2.

Ce qui fait de NTLMv1 un risque de sécurité

Le niveau de sécurité du protocole dépend du défi - plus il est difficile à compromettre, plus l'authentification est sécurisée. 

Dans le cas de NTLMv1, la différence réside dans leurs défis spécifiques :

1. NTLMv1 produit un défi avec un nombre de longueur fixe de 16 bits tandis que NTLMv2 produit des défis de longueurs variables.
2. NTLMv1 utilise un algorithme de chiffrement DES faible qui est rapide à déchiffrer, ce qui le rend vulnérable à la force brute, tandis que NTLMv2 utilise le HMAC-MD5 plus lent qui peut mieux résister à ces attaques, car le déchiffrement ne peut pas avoir lieu en temps réel. 

Tout système qui utilise l'authentification NTLMv1 est donc exposé à la compromission, car les attaquants peuvent facilement trouver un moyen d'accepter le défi et ainsi accéder au système. 

Dans cet esprit, il est facile de comprendre pourquoi les équipes informatiques et de sécurité souhaitent s'éloigner de NTLMv1. En théorie, cela semble facile - il suffit de trouver tous les systèmes qui utilisent NTLMv1 et de passer à un protocole plus sécurisé. En pratique, cependant, c'est beaucoup plus difficile.

Obstacles à la détection et à la suppression de NTLMv1

Dans un monde idéal, il y aurait un filtre qui, une fois cliqué, révélerait toutes les authentifications NTLMv1 ayant lieu dans un environnement. Malheureusement, la réalité n'est pas si simple.

Le chemin le plus simple consiste à activer l'audit de connexion réussie sur le contrôleur de domaine. Selon la documentation de Microsoft, chaque point de terminaison doit ensuite générer un événement avec les informations requises (Success Auditing Event 4624, qui contient des informations sur la version de NTLM. Les journaux d'événements reçus contiennent un champ "Nom du package (NTLM uniquement)" indiquant le nom du NTLM. version). Cependant, la collecte de ces journaux ne peut pas être effectuée de manière centralisée sur le DC et doit être récupérée à partir de chaque machine individuelle. De plus, dans de nombreux cas, l'événement ne contient pas les données de version NTLM ou n'a même pas été créé. 

De plus, dans la plupart des cas, NTLMv1 se trouve dans une application héritée où l'authentification NTLMv1 est effectuée sur le serveur d'applications. En tant que tel, rien ne garantit que le programmeur qui a codé l'application a mis en œuvre un mécanisme d'audit solide. Si l'application utilise un serveur Windows, elle peut être partiellement auditée localement, par exemple si elle utilise des bibliothèques internes de Windows telles que l'authentification IIS (application serveur Web). Cependant, si l'application est entièrement écrite par un tiers, aucun journal n'est audité. Dans ce cas, il n'y a aucun moyen de savoir si NTLMv1 est utilisé sans étapes intrusives (telles que le décryptage des paquets ou l'analyse du code de l'application réelle).

Bien que les authentifications NTLMv1 puissent être partiellement détectées à l'aide d'une inspection au niveau du réseau, une telle inspection n'est pas possible car, dans la plupart des cas, ce trafic est chiffré.

Ainsi, le défi réside non seulement dans l'insécurité inhérente à NTLMv1 lui-même, mais également dans la difficulté de déterminer s'il est utilisé dans un environnement donné. 

Réduction de la surface d'attaque NTLMv1

Les Silverfort offre aux organisations la capacité de découvrir toutes les authentifications NTLMv1 dans un environnement et de les bloquer activement.  

Silverfort Le moteur d'analyse détecte les authentifications NTLMv1 et les signale comme un indicateur de risque. Cet indicateur de risque peut être utilisé, à la fois comme filtre pour découvrir les machines qui effectuent de telles authentifications, et comme déclencheur de politique d'accès. Voyons à quoi ça ressemble dans le Silverfort console:

Découverte

Dans l'écran Journaux d'authentification, cochez la case Authentification NTLMv1. Une fois vérifiées, toutes les authentifications correspondantes sont affichées, fournissant des informations exploitables sur les machines qui utilisent NTLMv1 pour aider à décider de les désactiver.

NTLMv1 activé dans SilverfortÉcran Journaux d'authentification de

Directory 

D'une manière similaire, Silverfort permet l'utilisation d'un indicateur de risque NTLMv1 comme déclencheur pour activer une politique d'accès. L'action serait alors soit :

• Refuser: choisissez cette option si vous ne souhaitez pas du tout autoriser NTLMv1 dans l'environnement par mesure de précaution supplémentaire.
  

Politique de blocage des accès via NTLMv1

• MFA: choisissez cette option si, pour une raison quelconque, vous ne pouvez pas éliminer l'utilisation de NTLMv1 (par exemple, s'il existe une ancienne application susceptible de casser et de mettre en danger des processus métier critiques). Dans ce cas, même si le flux d'authentification est compromis, le véritable utilisateur doit vérifier son identité via MFA afin d'obtenir l'accès, désarmant efficacement la capacité des attaquants à tirer parti des faiblesses du protocole pour un accès malveillant.
  

Silverfort stratégie pour exiger l'intensification de MFA lors de l'authentification via NTLMv1

La voie vers une sécurité complète

Dans l'environnement hybride d'aujourd'hui, de nombreux types de systèmes existent côte à côte, donc une sécurité complète signifie les surveiller et les protéger tous. NTLMv1 n'est qu'un exemple des problèmes rencontrés avec les systèmes hérités ; il est également important de comprendre que lorsque la faille de sécurité réside dans l'infrastructure héritée, un compromis ici peut permettre aux attaquants d'accéder également à d'autres parties de l'environnement. La bonne façon d'y penser n'est pas tant de sécuriser les systèmes hérités, mais plutôt d'empêcher les systèmes hérités de devenir la passerelle vers votre environnement. 

Silverfort Protection d'identité est la première plate-forme spécialement conçue pour protéger contre les menaces d'identité dans l'ensemble de l'entreprise hybride, que la ressource ciblée soit une application SaaS, une charge de travail cloud ou un serveur sur site. Silverfort étend la MFA et la sécurité des identités modernes à toutes les ressources de base qui ne pouvaient pas être protégées auparavant, y compris NTLMv1.

NTLMv1 est-elle une surface d'attaque vous voulez aborder ? Planifiez une rencontre avec un de nos experts ici.