Zerologon CVE-2020-1472 Application Active Directory : pourquoi tant de DC ne l'ont toujours pas

Zerologon CVE-2020-1472 Application Active Directory : ce que cela signifie

Les lacunes d'application Zerologon CVE-2020-1472 sur Active Directory sont la partie de la remédiation de cette vulnérabilité qui continue d'être négligée, alors même que la vulnérabilité elle-même n'est plus une nouveauté. Zerologon est une faille critique (CVSS 10.0) d'élévation de privilèges dans le protocole Netlogon Remote Protocol (MS-NRPC), le mécanisme utilisé par les machines jointes au domaine pour établir un canal sécurisé avec un contrôleur de domaine. Elle a été découverte et divulguée de manière responsable par Tom Tervoort de Secura, qui a publié le livre blanc technique en septembre 2020 (Secura). L'avis de Microsoft la répertorie comme une vulnérabilité d'élévation de privilèges Netlogon (MSRC CVE-2020-1472).

La raison pour laquelle ce sujet mérite encore d'être traité plus de trois ans après sa divulgation n'est pas l'exploit en lui-même — c'est la phase d'application (enforcement). Microsoft a livré les correctifs de Zerologon en deux étapes, et c'est la seconde étape qui bloque silencieusement la plupart des environnements : corrigés, mais jamais confirmés comme appliquant réellement la protection. C'est d'autant plus problématique que « Zerologon » bénéficie d'une notoriété telle que de nombreuses équipes le considèrent comme un problème résolu et historique plutôt que comme un point à revérifier lors d'un audit de routine — et il continue d'apparaître aux côtés des mauvaises configurations Active Directory les plus courantes que les audits retrouvent chaque année.

Comment fonctionne Zerologon

La cause racine est une erreur d'implémentation cryptographique dans ComputeNetlogonCredential, la fonction que MS-NRPC utilise pour dériver une clé de session lors de NetrServerAuthenticate3. Netlogon utilise l'AES-CFB8 pour cet échange, mais l'implémentation de Microsoft fixait le vecteur d'initialisation (IV) à une valeur fixe de 16 octets nuls au lieu d'une valeur aléatoire — une violation de l'usage normal de l'AES-CFB8 (livre blanc Secura, via Pwnie Awards).

Cette faille a une conséquence exploitable précise : pour environ 1 clé possible sur 256, chiffrer un texte en clair entièrement à zéro avec l'AES-CFB8 et un IV nul produit un texte chiffré entièrement à zéro.

La séquence d'attaque

Un attaquant non authentifié sur le réseau peut :

1. Usurper l'identité d'un compte machine (y compris le compte du contrôleur de domaine lui-même) dans la négociation Netlogon.
2. Envoyer un challenge client composé de 8 octets nuls.
3. Répéter la négociation — en moyenne environ 256 tentatives — jusqu'à ce que le serveur accepte l'identifiant entièrement à zéro.
4. Une fois authentifié, appeler NetrServerPasswordSet2 pour réinitialiser le mot de passe du compte machine d'une cible, y compris le DC lui-même, à une valeur connue.

À partir de là, un attaquant ayant réinitialisé le mot de passe du compte machine d'un contrôleur de domaine peut s'authentifier en tant que ce DC et exécuter un DCSync pour récupérer tous les hachages de mots de passe du domaine — compromission complète du domaine, sans authentification, en quelques minutes. Aucun identifiant, aucun phishing, aucun malware sur le poste — seule une accessibilité réseau vers le service Netlogon d'un contrôleur de domaine est nécessaire. Notre article complémentaire sur l'abus d'ACL et DCSync détaille à quoi ressemble cet abus de réplication une fois qu'un attaquant dispose des droits nécessaires pour le déclencher.

Exploitation confirmée dans la nature

La CISA a ajouté le CVE-2020-1472 à son catalogue des vulnérabilités activement exploitées (Known Exploited Vulnerabilities) et a émis la directive d'urgence ED 20-04, ordonnant à toutes les agences fédérales américaines de corriger ou déconnecter les contrôleurs de domaine concernés avant 23h59 (heure de l'Est) le 21 septembre 2020 (CISA ED 20-04). La CISA a ensuite confirmé l'exploitation active de la faille par des acteurs étatiques (alerte CISA, octobre 2020), et elle a depuis été observée dans des intrusions de type ransomware ciblant des contrôleurs de domaine non corrigés. La combinaison d'un score CVSS maximal, d'une absence d'exigence d'authentification et d'une preuve de concept publique explique précisément pourquoi cette classe de vulnérabilité mérite une revérification plutôt qu'un simple correctif appliqué une fois pour toutes.

Pourquoi l'application est un problème distinct du correctif

Microsoft a livré le correctif en deux phases, et c'est précisément ce phasage qui explique pourquoi les lacunes d'application persistent des années après que tout le monde pense le sujet clos.

Phase 1 — Mise à jour du 11 août 2020

Ce correctif a modifié la façon dont les DC gèrent les connexions Netlogon vulnérables et a introduit le paramètre de registre FullSecureChannelProtection sous HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters, mais l'application était optionnelle. Les DC entraient dans une « phase de déploiement initial » où les appareils non conformes étaient journalisés, et non bloqués, à moins qu'un administrateur ne définisse explicitement la valeur de registre ou ne déploie la GPO d'application (Support Microsoft : gestion des connexions de canal sécurisé Netlogon).

Phase 2 — Mise à jour du 9 février 2021

Cette mise à jour a fait du mode d'application le comportement par défaut pour tous les contrôleurs de domaine Windows, indépendamment du paramètre de registre ou de stratégie de groupe (Tenable : Microsoft finalise l'application par défaut de Zerologon).

La lacune de la liste d'exceptions GPO

La lacune que la plupart des audits trouvent aujourd'hui n'est pas « Zerologon non corrigé » — ce sont des environnements où des appareils hérités ou tiers (NAS, serveurs d'impression, anciens clients Netlogon non Windows) ont cessé de fonctionner sous le mode d'application en 2021, et où un administrateur les a ajoutés à la liste d'exceptions de la stratégie de groupe « Contrôleur de domaine : autoriser les connexions de canal sécurisé Netlogon vulnérables » pour stopper la panne. Cette liste d'exceptions est exactement la lacune d'application : elle est toujours là, jamais revue, des années plus tard, et permet silencieusement la même négociation vulnérable que Zerologon exploite — limitée aux comptes qui ont été exemptés. Un contrôleur de domaine peut être entièrement corrigé et pourtant garder cette brèche ouverte par politique, ce qui explique pourquoi un simple rapport de niveau de correctif ne suffit pas à prouver l'application réelle.

Détection

Netlogon journalise des ID d'événement spécifiques pour l'activité de canal sécurisé vulnérable sur chaque contrôleur de domaine. Surveillez-les sur tous les DC, pas seulement sur un seul :

(Support Microsoft : gestion des connexions de canal sécurisé Netlogon)

Récupérer les événements

Concrètement, sur chaque contrôleur de domaine :

# Récupérer les événements récents de canal Netlogon vulnérable depuis le journal Système
Get-WinEvent -LogName System -FilterXPath "*[System[(EventID=5827 or EventID=5828 or EventID=5829 or EventID=5830 or EventID=5831)]]" -MaxEvents 200 |
    Select-Object TimeCreated, Id, Message |
    Format-Table -AutoSize

# Confirmer directement l'état d'application dans le registre (informatif sur les DC corrigés
# depuis février 2021, où l'application est activée par défaut indépendamment de cette valeur)
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" -Name FullSecureChannelProtection -ErrorAction SilentlyContinue

Tout événement 5829, 5830 ou 5831 mérite d'être investigué — il identifie précisément quel appareil dépend encore de la négociation vulnérable et pourquoi, et vous donne une liste concrète à traiter plutôt qu'une hypothèse de politique. Associez la surveillance des événements Netlogon à l'ensemble plus large des ID d'événements de sécurité Active Directory qui devraient déjà figurer dans votre SIEM, ainsi qu'à une revue plus large des priorités de durcissement afin que des correctifs au niveau protocole comme celui-ci ne soient pas traités comme des projets ponctuels qui sortent du périmètre avec le temps.

Remédiation

1. Confirmez le niveau de correctif sur chaque DC, pas sur un échantillon. Vérifiez que chaque contrôleur de domaine dispose au minimum de la mise à jour du 11 août 2020, et idéalement de la mise à jour cumulative du 9 février 2021 ou ultérieure, qui active l'application par défaut. Les DC oubliés (y compris les DC en lecture seule et les DC de domaines/forêts moins visibles) constituent la lacune la plus fréquente.
2. Auditez la GPO « Contrôleur de domaine : autoriser les connexions de canal sécurisé Netlogon vulnérables ». Passez en revue chaque entrée de la liste d'exceptions. Pour chaque appareil exempté, confirmez qu'il existe toujours, qu'il a toujours besoin de l'exception, et qu'aucune mise à jour firmware/logicielle du fournisseur n'ajoute désormais un support RPC sécurisé correct. Supprimez les entrées obsolètes.
3. Surveillez en continu les événements 5829/5830/5831, pas seulement pendant une fenêtre de déploiement ponctuelle. Toute nouvelle occurrence signifie qu'un appareil dépend aujourd'hui encore du chemin vulnérable.
4. Définissez (ou vérifiez) FullSecureChannelProtection = 1 sur tout DC n'ayant pas encore reçu la mise à jour de février 2021 ou ultérieure, en contrôle intérimaire pendant que le déploiement des correctifs se poursuit.
5. Revérifiez après chaque changement d'infrastructure. De nouveaux contrôleurs de domaine, des promotions de DC à partir de modèles/images, et des changements d'approbation de forêt/domaine peuvent tous réintroduire un état non appliqué ou non corrigé — intégrez cela à la revue standard des GPO et des builds de DC, pas seulement au déploiement initial de 2020/2021.
6. Traitez l'exposition DCSync comme le risque en aval. L'impact réel de Zerologon est qu'il donne à un attaquant la capacité de réinitialiser le mot de passe du compte propre d'un DC et d'extraire les hachages de mots de passe du domaine. Revoir qui et quoi dispose déjà de droits de réplication compatibles DCSync légitimes referme la seconde moitié de ce chemin d'attaque — voir notre guide sur l'abus d'ACL et DCSync.

Comment EtcSec détecte cela

Le contrôle ZEROLOGON_PATCH_ENFORCEMENT d'EtcSec signale les contrôleurs de domaine où l'application de Zerologon ne peut pas être confirmée — qu'il s'agisse d'un correctif manquant, d'un paramètre FullSecureChannelProtection désactivé sur un DC antérieur à février 2021, ou d'une GPO d'exception Netlogon active — afin que cela ne soit pas silencieusement présumé « corrigé en 2020 ». Il est associé à DCSYNC_CAPABLE, qui signale les comptes et objets ordinateur détenant des droits de réplication qu'une compromission de type Zerologon permettrait à un attaquant d'exploiter pour une extraction complète des identifiants. Ensemble, ces deux contrôles couvrent l'intégralité du chemin d'attaque : le point d'entrée initial non authentifié et les droits de réplication privilégiés qui le transforment en compromission de tout le domaine.