WDigest, hachages LM et NTLMv1 : éliminer les héritages qui exposent les identifiants

WDigest : le mot de passe en clair en mémoire

WDigest est un protocole d'authentification ancien, utilisé notamment pour l'authentification HTTP Digest. Pour fonctionner, il conservait le mot de passe de l'utilisateur sous une forme réversible dans la mémoire du processus LSASS. Un attaquant disposant de droits d'administration sur la machine pouvait alors récupérer le mot de passe en clair de chaque utilisateur connecté, y compris des administrateurs de passage.

Depuis Windows 8.1 et Windows Server 2012 R2, ce stockage est désactivé par défaut, et une mise à jour a apporté la même possibilité aux versions plus anciennes. Il est contrôlé par la valeur de registre UseLogonCredential sous la clé du fournisseur WDigest. Si elle vaut 1, le comportement historique est rétabli. Un attaquant qui a pris la main sur une machine peut d'ailleurs la positionner lui-même et attendre la prochaine ouverture de session : sa modification doit donc être surveillée.

La mesure : forcer la valeur à 0 par stratégie de groupe (les modèles d'administration du guide de sécurité Microsoft proposent un paramètre dédié) et alerter en cas de changement.

Les hachages LM

Le hachage LAN Manager est un format très ancien : il découpe le mot de passe en deux blocs de sept caractères, convertis en majuscules, ce qui le rend extrêmement faible face aux attaques hors ligne. Depuis Windows Vista et Windows Server 2008, le paramètre « Sécurité réseau : ne pas stocker de valeur de hachage de niveau LAN Manager lors de la prochaine modification du mot de passe » est activé par défaut.

Deux points restent à vérifier. D'abord, que ce paramètre n'a pas été désactivé par une GPO ancienne. Ensuite, que des comptes dont le mot de passe n'a pas changé depuis longtemps ne conservent pas un hachage LM calculé à l'époque : le paramètre ne s'applique qu'à la prochaine modification du mot de passe. Les comptes anciens, notamment de service, doivent donc changer de mot de passe.

NTLMv1 et le niveau d'authentification LAN Manager

NTLMv1 utilise une cryptographie obsolète : une réponse capturée sur le réseau peut être ramenée assez facilement au hachage NT du compte, qui permet ensuite de s'authentifier ailleurs. Lorsqu'un contrôleur de domaine accepte NTLMv1, un attaquant qui obtient une authentification NTLMv1 d'un compte d'ordinateur de DC peut aller très loin.

Le paramètre clé est « Sécurité réseau : niveau d'authentification LAN Manager ». La valeur cible est « Envoyer uniquement les réponses NTLMv2. Refuser LM et NTLM », appliquée aux contrôleurs de domaine comme aux membres. Microsoft a annoncé le retrait de NTLMv1 dans les versions récentes de Windows ; vérifiez l'état exact pour les versions présentes dans votre parc dans la documentation Microsoft à jour.

Mesurer avant de bloquer

Refuser NTLMv1 peut casser des équipements anciens : copieurs, appliances, applications métiers. Avant de basculer, identifiez les clients concernés. Les événements d'ouverture de session (4624) sur les contrôleurs de domaine indiquent la version du protocole NTLM utilisée, et les paramètres « Restreindre NTLM » en mode audit permettent de recenser l'usage de NTLM de manière plus générale. Traitez les exceptions en mettant à jour ou en remplaçant les équipements, plutôt qu'en maintenant le niveau d'authentification bas pour tout le domaine.

Ce qu'un audit vérifie

• la valeur de UseLogonCredential sur les serveurs et postes, et les GPO qui la définissent ;
• le paramètre de stockage des hachages LM et l'ancienneté des mots de passe des comptes ;
• le niveau d'authentification LAN Manager appliqué aux contrôleurs de domaine ;
• la présence d'authentifications NTLMv1 dans les journaux des contrôleurs de domaine ;
• le déploiement de Credential Guard et de la protection de LSA.