Dans un récent article, nous vous informions Microsoft a corrigé un bug très important lié aux contrôleurs de domaine dans les réseaux d'entreprise. Il s'agit de l'attaque Zerologon qui permet aux pirates de prendre le contrôle des réseaux d'entreprise.
Ce nouvel article sur le sujet décrit certains des détails techniques de CVE-2020-1472 publié par Microsoft. Afin d'atténuer ce problème, il est fortement recommandé d'installer les correctifs de sécurité d'août 2020 de Microsoft sur tous les contrôleurs de domaine Active Directory. Laisser un contrôleur de domaine non corrigé permettra aux attaquants de le compromettre et de se donner des privilèges d'administrateur de domaine. La seule chose dont un attaquant a besoin pour cela est la possibilité de configurer des connexions TCP avec un contrôleur de domaine vulnérable, c'est-à-dire qu'ils doivent avoir un accès au réseau, mais n'ont pas besoin d'informations d'identification de domaine. Le correctif qui traite Zerologon implémente également des mesures de défense en profondeur supplémentaires qui obligent les machines jointes au domaine à utiliser des fonctionnalités de sécurité auparavant facultatives du protocole Netlogon. Une mise à jour en février 2021 renforcera encore ces restrictions, ce qui pourrait casser certains appareils ou logiciels tiers.
Veuillez noter que l'installation du correctif d'août 2020 sur tous les contrôleurs de domaine est suffisante pour bloquer l'exploit à fort impact décrit ici. Reportez-vous au guide de Microsoft sur ces modifications pour plus d'informations.
Si vous voulez vous assurer que vous n'êtes pas vulnérable, vous pouvez utiliser l'outil de test publié par Secura.
L'attaque décrite dans cet article tire parti des failles d'un protocole d'authentification cryptographique qui prouve l'authenticité et l'identité d'un ordinateur joint à un domaine au contrôleur de domaine. En raison d'une utilisation incorrecte d'un mode de fonctionnement AES, il est possible d'usurper l'identité de tout compte d'ordinateur (y compris celui du contrôleur de domaine lui-même) et de définir un mot de passe vide pour ce compte dans le domaine.
TOUT COMMENCE PAR LE PROTOCOLE NETLOGON...
Le protocole Netlogon Remote est une interface RPC disponible sur les contrôleurs de domaine Windows. Il est utilisé pour diverses tâches liées à l'authentification des utilisateurs et des machines, le plus souvent pour faciliter la connexion des utilisateurs aux serveurs à l'aide du protocole NTLM. D'autres fonctionnalités incluent l'authentification des réponses NTP, et notamment : laisser un ordinateur mettre à jour son mot de passe dans le domaine. L’interface RPC est disponible via TCP via un port dynamique alloué au service ‘portmapper’ du contrôleur de domaine, ou via un canal SMB sur le port 445.
Ce qui est intéressant à propos de ce protocole, c’est qu’il n’utilise pas le même schéma d’authentification que les autres services RPC. Au lieu de cela, il utilise un protocole cryptographique personnalisé pour permettre à un client (un ordinateur joint à un domaine) et à un serveur (le contrôleur de domaine) de se prouver qu'ils connaissent tous deux un secret partagé. Ce secret partagé est un hachage du mot de passe du compte d’ordinateur du client. La raison en est que les comptes d'ordinateur n'étaient pas des principes de première classe à l'époque de Windows NT, ils ne pouvaient donc pas utiliser les schémas d'authentification utilisateur standard tels que NTLM ou Kerberos.
Une session Netlogon est lancée par le client, dans laquelle le client et le serveur échangent des nonces aléatoires de 8 octets (appelés défis client et serveur). Ils calculent tous deux une clé de session en mélangeant les deux défis avec le secret partagé à l'aide d'une fonction de dérivation de clé. Ensuite, le client utilise cette clé de session pour calculer les informations d'identification du client. Le serveur calcule cette même valeur d'informations d'identification et, si elle correspond, il est conclu que le client doit connaître la clé de session et que, par conséquent, le client doit également connaître le mot de passe de l'ordinateur.
Lors de la négociation d'authentification, les deux parties peuvent négocier si elles souhaitent sceller et signer (chiffrer et authentifier par cryptographie) les messages suivants, ce qui est essentiel pour se protéger contre les attaquants au niveau du réseau. Lorsque le chiffrement est désactivé, tous les appels Netlogon qui exécutent une action importante doivent toujours contenir une valeur d'authentification qui est également calculée à l'aide de la clé de session.
La mise en œuvre de protocoles cryptographiques est délicate: un petit oubli peut conduire à toutes sortes de méthodes pour contourner la fonction prévue du schéma (dans ce cas: l'authentification informatique et la sécurité du transport). Et en examinant de plus près la cryptographie utilisée pour la poignée de main d'authentification initiale, les chercheurs de Secura ont découvert un contournement d'authentification générale beaucoup plus sévère, qui peut être effectué par tout attaquant capable de mettre en place une connexion TCP avec le contrôleur de domaine.
PUIS SURVIENT UNE UTILISATION NON SÉCURISÉE D'AES-CFB8...
La primitive cryptographique que le client et le serveur utilisent pour générer des valeurs d'informations d'identification est implémentée dans une fonction appelée ComputeNetlogonCredential, comme défini dans la spécification du protocole. Cette fonction prend une entrée de 8 octets et y effectue une transformation avec la clé de session secrète qui produit une sortie de longueur égale. L'hypothèse sous-jacente est qu'un attaquant qui ne connaît pas la clé de session ne sera pas en mesure de calculer ou de deviner la sortie correcte correspondant à une certaine entrée, ce qui lui permettra d'être utilisé pour prouver la connaissance de la clé de session.
Il existe deux versions de cette fonction : une basée sur 2DES et une version plus récente basée sur AES. Celui qui est utilisé dépend des indicateurs définis par le client lors de l'authentification. Cependant, la configuration par défaut d'une version moderne de Windows Server rejettera toute tentative d'authentification à l'aide du schéma 2DES. Par conséquent, dans la plupart des domaines, seul le schéma AES peut être utilisé. Fait intéressant, c'est précisément dans ce nouveau schéma qu'a été trouvé la vulnérabilité. L'ancienne version n'est pas affectée par cette attaque spécifique (bien que 2DES soit toujours considérée comme non sécurisée pour d'autres raisons).
L'opération de chiffrement de bloc AES de base prend une entrée de 16 octets et la permute en une sortie de taille égale. Afin de chiffrer des entrées plus ou moins grandes, un mode de fonctionnement doit être choisi. La fonction ComputeNetlogonCredential, qui n'a besoin de transformer que 8 octets, utilise le mode plutôt obscur CFB8 (retour de chiffrement 8 bits). Ce mode est environ 16 fois plus lent que n'importe lequel des modes de fonctionnement les plus courants utilisés avec AES, ce qui explique probablement pourquoi il n'est pas largement utilisé.
AES-CFB8 chiffre chaque octet du texte en clair en ajoutant un "vecteur d'initialisation" de 16 octets au texte en clair, puis en appliquant AES aux 16 premiers octets de IV+texte en clair, en prenant le premier octet de la sortie AES, et en XOR avec le prochain octet de texte brut.
Afin de pouvoir chiffrer les octets initiaux d'un message, un vecteur d'initialisation (IV) doit être spécifié pour amorcer le processus de chiffrement. Cette valeur IV doit être unique et générée aléatoirement pour chaque texte brut distinct chiffré avec la même clé. La fonction ComputeNetlogonCredential, cependant, définit que ce IV est fixe et doit toujours se composer de 16 octets zéro. Cela enfreint les exigences pour utiliser AESCFB8 en toute sécurité: ses propriétés de sécurité ne sont valables que lorsque les IV sont aléatoires.
Alors, est-ce vraiment un problème ici ? Qu'est-ce qui peut mal tourner avec une IV tout zéro ? En fait, il existe peu d'informations sur de CFB8. Pour mieux comprendre la faille, des attaques en texte clair choisies ont été simulé. Les résultats ont été les suivants : pour 1 clé sur 256, l'application du chiffrement AESCFB8 à un texte en clair à zéro entraînera un texte chiffré tout aussi à zéro.
En fait, cette propriété est un peu plus générale : quand un IV ne comprend que des zéros, il y aura un entier 0 ≤ X ≤ 255 pour lequel il admet qu'un texte en clair commençant par n octets avec la valeur X aura un texte chiffré qui commence avec n octets de valeur 0. X dépend de la clé de chiffrement et est distribué de manière aléatoire. Pour attaquer Netlogon, il suffit de savoir qu'une entrée tout à zéro peut entraîner une sortie tout à zéro.
ET POUR CONCLURE
En envoyant simplement un certain nombre de messages Netlogon dans lesquels divers champs sont remplis de zéros, un attaquant peut changer le mot de passe de l'ordinateur du contrôleur de domaine qui est stocké dans l'AD. Cela peut ensuite être utilisé pour obtenir les informations d'identification de l'administrateur du domaine, puis restaurer le mot de passe d'origine du contrôleur de domaine.
Cette attaque a un impact énorme : elle permet fondamentalement à tout attaquant sur le réseau local (comme un initié malveillant ou quelqu'un qui a simplement branché un appareil sur un port réseau sur site) de compromettre complètement le domaine Windows. L'attaque est totalement non authentifiée: l'attaquant n'a pas besoin d'informations d'identification utilisateur. Heureusement, le correctif publié le Patch Tuesday d'août 2020 résout ce problème en appliquant Secure NRPC (c'est-à-dire la signature et le scellement de Netlogon) pour tous les serveurs et clients Windows du domaine.
La Rédaction d’Africa CyberSecurity Mag
