ZeroLogon, nouvelle vulnérabilité du protocole Netlogon
Mardi 11 août 2020, Microsoft a publié l’alerte de sécurité concernant la vulnérabilité CVE-2020-1472 « Élévation de privilège sur Netlogon », aussi appelée « ZeroLogon » ▶️ Lire le bulletin
Cette vulnérabilité affecte le protocole distant Netlogon (aussi appelé MS-NRPC pour Microsoft Netlogon Remote Protocol) utilisé par les machines reliées à un domaine Windows.
Qu’est-ce que le protocole Netlogon ?
Le protocole Netlogon est utilisé lors de la création de canaux de communication sécurisés, pour des opérations liées à l’authentification d’un actif d’un domaine Windows. Cela concerne par exemple la connexion à des machines distantes connectées au domaine, mais aussi la mise à jour du mot de passe d’un compte utilisateur de domaine.
Le protocole Netlogon passe par le port TCP 135 ainsi que par des ports dynamiques RPC (Remote Procedure Call) c’est-à-dire des ports ouverts temporairement sur la tranche TCP 49152-65536, ou par des échanges sur un canal SMB (port TCP 445).
Comment se déroule un échange Netlogon ?
Un échange NetLogon se déroule de la manière suivante :
1. Le client génère un mot aléatoire de 8 octets, nommé ChallengeClient, et envoie ce mot au serveur Netlogon, par exemple un contrôleur de domaine.
2. Le serveur génère un mot aléatoire de 8 octets, nommé ChallengeServeur, et envoie ce mot au client.
3. Le client et le serveur calculent une clé de session, nommée CléSession, à partir des éléments suivants :
2 variables :
1. Un secret partagé nommé EmpreintePassClient (empreinte du mot de passe de l’utilisateur sur le domaine, connue à la fois du client et du serveur, le client stockant cette information dans le registre et le serveur de domaine disposant de l’information via l’annuaire Active Directory).
2. Un mot de 16 octets nommé ChallengeClientServeurChallengeClientChallengeServeur
2 fonctions :
1. Une fonction de calcul d’empreinte MD4 (Message Digest 4).
2. Une fonction de dérivation de clé, notée KDF (pour Key Derivation Function) qui prend en argument une clé et un challenge, puis calcule le HMAC_SHA256(clé, challenge), et en garde les 16 premiers octets.
La formule ci-dessous
Elle permet de calculer CléSession :
CléSession=KDF(EmpreintePassClient, ChallengeClientServeur)
4. Ensuite, le client chiffre ChallengeClientCléSessionAES avec une clé de 128 bits, en mode « rétroaction » / Cipher Feedback avec 8 bits par itération) et obtient son identifiant IdentifiantClient.
5. Le client envoie son identifiant IdentifiantClient au serveur.
6. Le serveur, qui dispose déjà de CléSession et de ChallengeClient, vérifie qu’il est en mesure de déchiffrer IdentifiantClient.
7. Le serveur chiffre à son tour son challenge ChallengeServeur avec CléSession, via AES-128-CFB8 là-aussi, et obtient ainsi son identifiant IdentifiantServeur.
8. Le serveur envoie son identifiant IdentifiantServeur au client.
9. Le client, qui dispose également de CléSession et de ChallengeServeur, vérifie qu’il est en mesure de déchiffrer IdentifiantServeur.
10. La communication sécurisée est alors établie.
L’ensemble du processus est représenté par le schéma ci-dessous :
En quoi consiste la faille Zerologon CVE-2020-1472 ?
La vulnérabilité Zerologon CVE-2020-1472 est liée à l’utilisation de la technique de chiffrement AES-128-CFB8.
AES-128-CFB8 ajoute 16 octets au début du message à chiffrer, via ce que l’on appelle un « vecteur d’initialisation » généré aléatoirement, aussi appelé « IV » (pour Initialisation Vector). Une fois ce vecteur obtenu, AES-128-CFB8 consiste à chiffrer l’ensemble « IV + message » avec une clé, de la manière suivante :
1. Prendre les 16 premiers octets de l’ensemble « IV + message ». Nommer cet ensemble EnsembleEtudié.
2. Appliquer AES sur EnsembleEtudié avec la clé choisie. Conserver uniquement le premier octet de ce résultat.
3. Calculer le XOR, c’est-à-dire le « OU Exclusif », entre l’octet obtenu à l’étape 2 et l’octet situé juste après EnsembleEtudié.
4. Stocker le résultat de l’opération 3 dans l’octet situé juste après EnsembleEtudié.
5. Décaler EnsembleEtudié d’un octet vers la droite.
6. Répéter les étapes 2 à 5 jusqu’à avoir parcouru tout l’ensemble « IV + message ».
7. Supprimer les 16 premiers octets de l’ensemble « IV + message ». Le message chiffré est constitué de ce qu’il reste.
Cet algorithme est illustré ci-dessous :
Le chercheur à l’origine de la vulnérabilité CVE-2020-1472, Tom Tervoort, a identifié un problème dans l’implémentation d’AES-128-CFB8 au sein de Netlogon : le vecteur d’initialisation y est systématiquement fixé à 16 octets nuls (0x00). Le vecteur d’initialisation n’est donc ici pas aléatoire, ce qui enfreint les bonnes pratiques de cryptographie.
Le choix de cette valeur de 16 octets nuls (0x00) comme vecteur d’initialisation fait que si le message à chiffrer est composé uniquement d’octets nuls (0x00), alors le message chiffré obtenu via AES-128-CFB8 peut se retrouver lui aussi composé intégralement d’octets nul (0x00). Cela dépend uniquement de la valeur de la clé de chiffrement utilisée, et si celle-ci est aléatoire, cela se produit statistiquement 1 fois sur 256.
Or, dans le cas du protocole NetLogon, le client a le contrôle sur le message à chiffrer : il s’agit de ChallengeClient. Ce message peut ainsi être fixé arbitrairement à 8 octets nuls (0x00). De même, CléSession, qui est utilisée pour chiffrer ChallengeClient avec AES-128-CFB8, est supposée être aléatoire par construction. Nous nous retrouvons ainsi dans les conditions exactes indiquées précédemment, et le chiffrement de ChallengeClient par CléSession et AES-128-CFB8 produit alors statistiquement un message de 8 octets nuls 1 fois sur 256.
Illustration du problème causé par un vecteur d’initialisation nul
La vulnérabilité CVE-2020-1472 consiste simplement à « tenter » d’envoyer un message IdentifiantClient composé de 8 octets nuls jusqu’à acceptation du serveur. Avec une chance de succès de 1 sur 256, et via un script, cette action se déroule en quelques secondes seulement.
En résumé, la CVE-2020-1472 repose sur un défaut d’implémentation cryptographique dû à un vecteur d’initialisation fixé à 16 octets nuls, d’où son surnom « ZeroLogon ».
Quels sont les actifs affectés par la vulnérabilité CVE-2020-1472 ?
Les systèmes affectés par ZeroLogon / CVE-2020-1472 sont les actifs Windows Server 2008 / 2012 / 2012 R2 / 2016 / 2019 / Server 1903, 1909, 2004 qui n’ont pas installé la mise à jour de sécurité du 11 août 2020, avec une attention toute particulière à porter aux systèmes qui agissent comme contrôleurs de domaines.
La liste détaillée de ces éléments est disponible sur le site de l’Agence Nationale de la Sécurité des Systèmes d’Information.
Quel est l’impact de la vulnérabilité ZeroLogon / CVE-2020-1472 ?
La vulnérabilité ZeroLogon permet à un utilisateur malveillant de prendre le contrôle total et à distance d’un contrôleur de domaine, ou de modifier le mot de passe d’un utilisateur du domaine.
Les contrôleurs de domaine doivent ainsi être traités en priorité dans le déploiement des dernières mises à jour de sécurité afin de neutraliser cette vulnérabilité.
Quelle est la facilité d’attaque de ZeroLogon / CVE-2020-1472 ?
Plusieurs exploits sont disponibles gratuitement et publiquement sur Internet, dont https://github.com/dirkjanm/CVE-2020-1472.
Kevin Beaumont, analyste au « Microsoft Threat Intelligence Global Engagement & Response », a indiqué avoir détecté des tentatives d’exploitation de cette vulnérabilité dès le 26 septembre 2020, confirmant ainsi la probabilité de subir une attaque à l’aide de ZeroLogon.
Comment neutraliser ZeroLogon / CVE-2020-1472 ?
Microsoft a mis à disposition les mises à jour de sécurité suivantes :
- KB4571729 / KB4571719 pour Windows Server 2008 R2
- KB4571736 / KB4571702 pour Windows Server 2012
- KB4571703 / KB4571723 pour Windows Server 2012 R2
- KB4571694 pour Windows Server 2016
- KB4565349 pour Windows Server 2019
- KB4565351 pour Windows Server version 1903 et version 1909
- KB4566782 pour Windows Server version 2004
Microsoft recommande d’appliquer ces mises à jour en ciblant en priorité les contrôleurs de domaine, et incite également à configurer les connexions de canaux sécurisés Netlogon suivant la procédure définie ici.
Cyberwatch recommande par ailleurs de consulter le bulletin de l’Agence Nationale de la Sécurité des Systèmes d’Information CERTFR-2020-ALE-020 et d’effectuer une recherche de la vulnérabilité sur votre système d’information dans les plus brefs délais, en ciblant a minima les contrôleurs de domaine.
Pour aller plus plus loin
Pour d’autres informations d’ordre technique sur la vulnérabilité, vous pouvez aussi consulter la publication de Tom Tervoort sur le site de Secura, ou l’épisode du podcast NoLimitSecu consacré au sujet.