> Tech > Au coeur des améliorations de sécurité du SP4 : NTLMv2

Au coeur des améliorations de sécurité du SP4 : NTLMv2

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

En décidant de rendre Windows NT compatible amont avec LAN Manager, Microsoft se rendait-il compte des problèmes qu'allait engendrer cette décision ? Le SP4 corrige certes la faiblesse de sécurité qu'introduisait la compatibilité LM mais peut-on jamais semer les pirates… En rendant Windows NT compatible avec LAN Manager, Microsoft entendait faciliter la mise en oeuvre de NT dans les environnements LAN Manager et les sites sous Windows 95, Windows 3x, DOS et OS/2 existants. On pouvait en effet continuer à  utiliser le logiciel client LAN Manager déjà  présent dans ces OS clients. Mais en bénéficiant de la compatibilité amont, NT a du même coup hérité de certaines faiblesses importantes en matière de sécurité dues au mode de hachage des mots de passe et d'authentification du réseau propres à  LM, le protocole d'authentification de LAN Manager. (Pour en savoir plus sur les faiblesses de l'authentification LM, voir l'article " Protégez vos mots de passe " de décembre 1998). L'authentification LM utilise un mécanisme de question/réponse pour l'ouverture de session, pour éviter de devoir transmettre le mot de passe sur le réseau. Mais les vulnérabilités de LM permettent aux hackers d'espionner un segment de réseau, de saisir la question/réponse et de percer le logon. Windows NT est donc tout aussi vulnérable puisque, pour offrir cette compatibilité, il envoie et accepte automatiquement les réponses LM, ce qui est carrément dangereux.

L0phtCrack, outil de percement de mots de passe de L0pht Heavy Industries, fait peser une lourde menace sur NT, grâce à  un renifleur de question/réponse capable de capturer les logons au moment où ils ont lieu sur le réseau. Une fois en possession de ce couple question/réponse, L0phtCrack exploite les faiblesses de LM pour récupérer le véritable mot de passe. Dans sa version 2.5, l'outil est doté d'un renifleur amélioré avec interface graphique intégré dans le moteur principal (écran 1) et il ne nécessite plus, comme la précédente version, de driver de paquet spécial. Cet outil vendu dans le commerce permet même aux pirates novices d'apprendre sans difficulté les mots de passe de quiconque ouvre une session sur son segment de réseau.

L0phtCrack, outil de percement de mots de passe de L0pht Heavy Industries, fait peser une lourde menace sur NT

Avant la sortie du Service Pack 4 (SP4), les administrateurs système devaient, pour se défendre, appliquer la correction lm-fix, postérieure au SP3. Cette correction ajoutait un paramètre au Registre, LM-CompatibilityLevel, qui indiquait à  NT de ne pas supporter l'authentification LM, battant ainsi en brèche le renifleur L0phtCrack. Evidemment, cette solution impliquait de n'utiliser que NT sur les postes de travail clients, puisque Win9x, Windows 3x, DOS et OS/2 ne supportent que l'authentification LM. Malheureusement, lm-fix posait des problèmes de stabilité et Microsoft a dû le supprimer du Web, privant les administrateurs d'une solution à  un problème sérieux.

Dès la sortie du SP4, voulant vérifier si Microsoft avait inclus la fonction lm-fix, j'ai découvert une révision du protocole d'authentification de réseau NTLM, spécialement conçu par Microsoft pour améliorer la sécurité de NT. NTLMv2 se caractérise par plusieurs améliorations permettant de traiter les problèmes d'authentification, ainsi que la confidentialité, l'intégrité et le chiffrage 128 bits nécessaires pour sécuriser les sessions. Dans cet article nous présenterons les options de NTLMv2 et un certain nombre de détails non documentés et de bugs graves pour la sécurité. Nous verrons également comment chaque option permet de résister aux attaques de L0phtCrack 2.5 et traiterons les éventuelles futures attaques. Enfin, nous terminerons par des recommandations pratiques pour mettre en oeuvre la meilleure sécurité possible tout en préservant la compatibilité.

Au coeur des améliorations de sécurité du SP4 : NTLMv2

Lorsqu’un utilisateur veut se connecter à  un serveur, il est authentifié par un
protocole de question/réponse. Le serveur émet une chaîne d’octets aléatoire baptisée
question à  destination du client. Celui-ci crypte la question avec le hachage
du mot de passe de l’utilisateur et la renvoie, cryptée, comme réponse. Le serveur
décrypte la réponse avec le hachage officiel du mot de passe stocké dans le compte
de l’utilisateur. Si la réponse décryptée correspond à  la question originale,
l’utilisateur est authentique.

Les clients NT envoient deux réponses à  la question du serveur : la réponse LM
et la réponse NTLM. Comme le client envoie les deux réponses, le hachage et la
réponse NTLM n’ont aucune importance. Mais la réponse LM permet à  NT de se connecter
ou d’accepter des connexions de systèmes autres que NT.
Lorsque L0phtCrack intercepte une authentification, il affiche les réponses dans
deux colonnes séparées baptisées LanMan Hash et NT Hash, comme sur l’écran 2.
A l’origine ces colonnes contenaient leurs types de réponses correspondants. Cependant,
depuis lm-fix, elles donnent des types de réponses différents de ceux que l’on
pourrait attendre.

En effet, Microsoft a créé de nouvelles versions de réponse LM et de réponse NT
pour la sécurité et la compatibilité amont. Dans NTLMv2, la valeur du Registre
LMCompatibilityLevel contrôle les améliorations de l’authentification et possède
en outre des fonctions améliorées.L’authentification pose, il faut le savoir,
d’autres problèmes concernant la fonction passthrough et l’authentification du
réseau local.
Lorsqu’un client se connecte à  un serveur NT ou non-NT au moyen d’un compte de
domaine, ce système n’effectue pas l’authentification, mais l’envoie à  un contrôleur
de domaine.

Ce processus est dit authentification passthrough. Lorsqu’un client se connecte
à  un serveur au moyen d’un compte local ou d’une sécurité au niveau du partage
(possible avec des OS non-NT), celui-ci fait appel au SAM local pour traiter l’authentification.
Ce processus est dit authentification de réseau local. Comme je l’explique plus
loin, l’authentification passthrough et l’authentification de réseau local compliquent
encore les efforts de Microsoft pour réduire les vulnérabilités de l’authentification
des réseaux NT.

Téléchargez cette ressource

SD-WAN de confiance : guide de mise en œuvre

SD-WAN de confiance : guide de mise en œuvre

Ce livre blanc décrit les différents aspects indispensables pour la mise en place d’une approche SD-WAN sécurisée et de confiance. Ce document s’adresse aux consultants et responsables sécurité des systèmes d’information pour bien comprendre les enjeux du Trusted SD-WAN à l’heure de la transformation numérique des entreprises.

Tech - Par iTPro.fr - Publié le 24 juin 2010

A lire aussi sur le site

Revue Smart DSI

La Revue du Décideur IT