La protection de LMCompatibilityLevel

la réponse LM (LM et LMv2).
Les deux dernières sont plus difficiles à  percer. On peut donner à  la LMCompatibilityLevel,
du type REGDWORD, des niveaux de 0 à  5, le niveau 5 offrant le plus de sécurité
et le moins de compatibilité amont. Pour permettre la sécurité la plus élevée,
il faut empêcher la transmission de la réponse LM, vulnérable aux outils de piratage
du commerce. Le tableau 1 donne une brève description de la sécurité pour chaque
valeur de LMCompatibilityLevel.

Niveau 0. Le niveau 0 envoie à  la fois les réponses NT
et LM. Il est donc extrêmement vulnérable aux attaques lancées contre la réponse
LM. Le niveau 0 est également la valeur par défaut de LMCompatibilityLevel lors
de l’installation du SP4. C’est pourquoi, la simple installation du SP4 ou ultérieur
n’améliore pas la sécurité.

Niveau 1. Le niveau 1 applique la sécurité de session
NTLMv2, si elle négociée entre le client et le serveur. Par sa description, le
niveau 1 semble négocier automatiquement le niveau d’authentification le plus
élevé possible (c’est-à -dire NTLMv2). Mais il retombe à  l’authentification LM,
si nécessaire, et n’améliore pas la sécurité de l’authentification.

Pour comprendre le niveau 1, revenons au SP3 et à  la correction lm-fix. Remédier
aux vulnérabilités engendrées par l’authentification LM était plus compliqué que
ce que croyait Microsoft. Cette complication était due à  l’authentification passthrough
et au besoin de compatibilité amont avec des systèmes ne supportant que l’authentification
LM, mais pouvant fonctionner comme clients ou serveurs de systèmes NT. Si L0phtCrack
2.5 est utilisé pour saisir des authentifications à  partir d’un système SP3 avec
lm-fix et LMCompatibilityLevel sur le niveau 2, LophtCrack affichera la réponse
NT normale et des zéros pour la réponse LM, ce qui confirme que cette configuration
désactive l’authentification LM. Mais la solution était trop simple car la négociation
de l’authentification NT entre le client et le serveur, spécifiée par le niveau
1, n’est pas vraiment possible.

Avec le SP3 et lm-fix, le niveau 1 a été mis à  mal de deux manières. D’abord il
confondait la sécurité de session et l’authentification. Celle-ci ne peut pas
utiliser en toute sécurité la réponse LM pour négocier, parce que ce n’est pas
le serveur qui prend la décision, mais le contrôleur de domaine. Le client et
le serveur ne peuvent négocier que la sécurité de session car l’authentification
implique que le client et son contrôleur de domaine s’entendent sur l’authentification
à  utiliser. Deuxièmement, la négociation de la sécurité de session est sujette
à  des attaques dites man-in-the-middle et ne fournit donc pas une protection
réelle.

Microsoft a envisagé de désactiver le niveau 1 dans le SP4 mais ne l’a pas fait.
Il s’est rendu compte, en fait, que si un utilisateur possédant un client NT et
un client Windows 3.x change son mot de passe à  partir de la machine Windows 3.x,
le hachage NTLM ne se trouve pas dans le SAM. L’authentification d’un utilisateur
à  partir de NT échouera alors au niveau 2. Moyennant quoi, Microsoft a inclus
le niveau 1 dans le SP4 pour permettre à  ses clients de bénéficier de la sécurité
de session NTLMv2.

Microsoft a inclus le niveau 1 dans le SP4 pour permettre à  ses clients
de bénéficier de la sécurité de session NTLMv2

D’après la documentation, le niveau 1 envoie si possible toujours la réponse
LM et la réponse NTLMv2 plutôt que NTLM. Ordinairement L0phtCrack 2.5 perce les
mots de passe LM tout en majuscules, puis effectue rapidement toutes les variations
de casses possibles pour déterminer les versions NT (sensibles à  la casse) du
mot de passe. Théoriquement, L0phtCrack pourrait se contenter de ne percer que
les réponses LM, laissant le pirate imaginer la version sensible à  la casse, puisque
l’outil ne peut pas percer les réponses NTLMv2. Pourtant avec le niveau 1, j’ai
percé la totalité des authentifications du niveau sensible à  la casse que j’avais
saisies, ce qui signifie que le client a envoyé la réponse NTLM au lieu de NTLMv2
et que la négociation de niveau 1 pourrait présenter des bugs. Par conséquent
le niveau 1 est vulnérable aux attaques de la réponse LM à  la fois par la méthode
du dictionnaire et par la force.

Niveau 2. Le niveau 2 ne spécifie que l’authentification
NTLM. En appliquant le mode SMB Packet Capture de L0phtCrack à  un système de niveau
2, les pirates pourraient s’attendre à  ce que seule la colonne NT Hash se remplisse
de données et la colonne LanMan Hash de zéros. Or comme le montre l’écran 2, ligne
3, les deux colonnes de réponses ont la même valeur. Avec le niveau 2, Windows
NT remplit à  la fois les colonnes NT Hash et LanMan Hash avec la réponse NTLM.
Ces doubles réponses permettent aux clients de niveau 2 du SP4 ou ultérieur de
se connecter à  des serveurs non-NT par le biais d’un compte de domaine sans envoyer
la réponse LM. Comme ces derniers ne comprennent que l’authentification LM, ils
ignorent la réponse NT et envoient la réponse LM au contrôleur de domaine. Si
le contrôleur de domaine est équipé du SP4 ou ultérieur, l’authentification fonctionnera.

Le niveau 2 bat le mode par défaut de L0phtCrack, qui se concentre sur la réponse
LM. Dans ce cas, L0phtCrack utilise l’algorithme de percement LM sur une réponse
NT. Un pirate peut toujours configurer L0phtCrack pour effectuer une attaque par
dictionnaire sur la réponse NT afin de trouver le mot de passe. Mais les mots
de passe nécessitant l’attaque hybride dictionnaire/force seront probablement
trop longs à  percer pour présenter le moindre intérêt pour un pirate et les mots
de passe nécessitant la force risquent de mettre des années à  être percés, même
avec de très nombreux systèmes se répartissant la charge du percement. Aussi,
pour éliminer les vulnérabilités de LM, réglez vos stations de travail sur le
niveau 2, mais rappelez-vous qu’à  ce niveau, les mots de passe de mauvaise qualité
sont toujours susceptibles d’être percés.

Tant que L0phtCrack Heavy Industries n’aura pas mis à  jour L0phtCrack,
le niveau 3 sera très sûr… à  condition de fonctionner

Niveau 3. Le niveau 3 spécifie seulement l’authentification NTLMv2.
Lorsqu’un pirate renifle une authentification de niveau 3, la colonne NT Hash
se remplit de la réponse NTLMv2 et la colonne LanMan Hash de la réponse LMv2.

Microsoft avait prévu de remplacer la réponse LM par la réponse NTLMv2 pour permettre
l’authentification passthrough aux serveurs non-NT, mais les réponses NTLMv2 font
plus de 24 octets. Le protocole d’authentification NTLM spécifie que les réponses
sont de longueurs variables, c’est pourquoi les serveurs non-NT devraient envoyer
la totalité de la réponse au contrôleur de domaine. Or ces OS ne sont pas conformes
au protocole et n’envoient que les 24 premiers octets de la réponse LM au contrôleur
de domaine. Microsoft a donc créé une réponse NTLMv2 de 24 octets, que les clients
de niveau 3 envoient comme réponse LM et que L0phtCrack inscrit dans la colonne
LanMan Hash.

LMv2 est plus sûr que NTLM, parce qu’il utilise un algorithme de 128 octets (au
lieu des 56 octets de NTLM) à  partir du mot de passe. L0phtCrack 2.5 ne peut pas
percer les réponses combinant NTLMv2 et LMv2.

Tant que L0phtCrack Heavy Industries n’aura pas mis à  jour L0phtCrack pour percer
les réponses NTLMv2, le niveau 3 sera très sûr… à  condition de fonctionner. Au
cours des tests répétés que j’ai effectués, les clients de niveau 3 n’ont à  aucun
moment réussi à  se connecter aux serveurs SP4 ou ultérieurs, quel que soit le
niveau LMCompatibilityLevel du serveur. Avec un compte sur le contrôleur de domaine,
j’ai émis la commande Net Use pour me connecter à  un dossier partagé sur un contrôleur
de domaine. Malgré de nombreuses tentatives, le niveau 3 n’a pas fonctionné du
tout. Au moment de la mise sous presse, Microsoft n’avait pas répondu au problème
posé par le niveau 3.

Niveau 4. La documentation sur le niveau 4 est quelque
peu ambiguà«. Elle affirme par moments que le niveau 4 refuse l’authentification
LM, ce qui pourrait signifier qu’il refusera tout client envoyant la réponse LM.
A d’autres moments elle précise que le niveau 4 refuse les clients non-NT. Au
cours de mes tests, j’ai constaté qu’il ne s’applique qu’aux clients non-NT. Par
exemple, sur mon serveur, il a refusé une connexion à  d’un poste de travail DOS
exécutant le logiciel client LAN Manager, mais n’a pas refusé les connexions de
clients NT, même quand ils envoyaient la réponse LM. Bien entendu, le niveau 4
ne s’applique pas aux clients non-NT se connectant à  un serveur autre qu’un contrôleur
de domaine avec un compte de domaine, parce que le serveur envoie simplement les
références au contrôleur de domaine.

Le Niveau 4 spécifie que les serveurs refusent les connexions aux clients non-NT
utilisant un compte local sur ce serveur et que les contrôleurs de domaine leur
refusent toute connexion. On peut donc l’utiliser pour s’assurer de ne pas avoir
de clients non-NT envoyant la réponse LM si vulnérable. On ne peut toutefois pas
l’utiliser pour empêcher les connexions aux clients NT qui envoient encore la
réponse LM. Pour les systèmes NT, il faut empêcher la transmission de la réponse
LM au niveau de la station de travail avec le SP4 ou ultérieur et LMCompatibilityLevel
2 ou plus.

Niveau 5. Le niveau 5 spécifie que les clients envoyant
toute réponse autre que NTLMv2 sont refusés. (Il observe la même exception que
le niveau 4 pour l’authentification passthrough aux serveurs autres que les contrôleurs
de domaine). Le niveau 5 permettrait d’imposer la sécurité la plus élevée et de
garantir la conformité de tous les clients à  NTLMv2, mais malheureusement il a
des bugs. Dans mes tests, les serveurs de niveau 5 ont refusé toutes les connexions,
y compris avec les clients NTLMv2 correctement configurés. Microsoft a reconnu
ce bug sérieux, mais n’avait pas sorti de correction au moment de la mise sous
presse. Le SP5 n’a pas apporté de solution à  ce problème.