Zerologon : une vulnérabilité au sein d'Active Directory et d'AES permettait d'élever les privilèges-administrateurs !

Dévoilée en douceur le 11 Août dernier par Microsoft, une rustine sécuritaire a été appliquée concernant le NRP (Netlogon Remote Protocol), Qualifiée de critique, elle affecte plusieurs versions de Windows Server utilisés en tant que contrôleur de domaine ou usitant - trafic - le port 445...

 

L'équipe Sécura, dans son billet et rapport détaillé du 11 Septembre dernier, relate cette vulnérabilité, désormais assignée (et, donc, corrigée) CVE-2020-1472 : celle-ci repose, en partie, sur une faille (CVE-2019-1424) découverte en Novembre 2019. A l'époque, le (N)RPC (Netlogon - Remote Procedure Call) relatif au protocole Netlogon, mettait déjà en relief une défaillance dans l'authentification via une attaque MitM (Man-in-the-Middle ou Homme du Milieu), en interceptant, au cours du trafic-réseau, une des étapes (handshake) pour transformer l'échec d'authentification en succès (spoofing). Concernant Zerologon et comme indiqué par sa dénomination, l'affaire se corse, sécuritairement : le détournement ne repose non-plus sur une étape mais sur le chiffrement lui-même. Tout comme Raccoon mis en lumière récemment, c'est le chiffrement AES (2DES étant peu sécurisé et, en général, exclu lors des tentatives de connexion par ce biais) qui est remis en cause sur l'environnement-système Windows Server, via une possibilité potentielle de contourner l'authentification en remplaçant certaines parties (fixes) par des zéros !

 

"Afin de pouvoir chiffrer les octets initiaux d'un message, un vecteur d'initialisation doit être spécifié pour amorcer le processus de chiffrement. Cette valeur 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 cette valeur est fixe et doit toujours se composer de 16 octets zéro. Cela enfreint les exigences pour utiliser AES-CFB8 en toute sécurité : ses propriétés de sécurité ne sont valables que lorsque ces valeurs sont aléatoires [...] J'ai donc essayé de créer moi-même des attaques en texte clair choisies et j'ai trouvé quelque chose d'intéressant : pour 1 clé sur 256, l'application du cryptage AES-CFB8 à un texte en clair tout zéro entraînera un texte chiffré tout zéro", est-il expliqué.

 

De là, l'attaque se coordonne en plusieurs étapes :

  • Aspiration des identifiants-client (serveur) : depuis NetrServerAuthenticate / ClientCredential, le challenge (défi) - question - réponse lié à l'authentification peut être compromis en remplaçant la clé ou chaîne par 8 zéros. Le rapport fait état d'un temps de changement (test malveillant) de l'ordre de 3 secondes pour éprouver les 256 probabilités ;
  • Désactivation de la signature et du scellement : du fait qu'il s'agisse d'options facultatives, la connexion peut s'établir sur Windows Serveur sans autre préambule ;
  • Détournement d'un appel et de l'horodatage, en modifiant quelques paramètres (pour l'horodatage, une date purement indicative : aucune règle à ce niveau) avec, là aussi, un remplacement de la clé-session (inconnue) par des zéros ;
  • Modification du mot de passe par DoS (Déni of Service) : une fois l'appel établi / effectué, la réinitialisation du mot de passe est opérée (le hashage NTLM étant chiffré, au même titre que la clé-session) en exploitant la défaillance AES-CFB8. Au final, cela donnera une suite de 516 zéros (relatifs aux 516 octets édictés sous Netlogon). A noter que si le mot de passe peut être modifié, celui d'origine sera conservé par le système mais il faudra, pour l'administrateur légitime, pouvoir le déverrouiller en manuel ;
  • Sécuriser l'accès en évitant une reprise en main : via un script malveillant ou détourné, une extraction de "tous les hashages utilisateur du domaine via le protocole DRS (Domain Replication Service)" peut être effectuée. Cela enlève la possibilité de conflit-serveur avec un mot de passe Active Directory différent de celui situé dans le registre, en local (HKLM / Security / Policy / Secrets / $machine.acc). Une fois la manipulation opérée, le système est entièrement détournée.

 

Depuis Août 2020, Microsoft a fourni un patch correctif pour rendre scellement et signature obligatoires. "En février 2021, ce mode d'application (ndlr : enforcement mode ou mode de mise en application, sous le NRPC) sera activé par défaut, obligeant les administrateurs à mettre à jour, à désactiver ou à mettre sur liste blanche les appareils qui ne prennent pas en charge Secure NRPC au préalable", rappelle l'équipe sécuritaire. A mettre à jour sans tarder, si cela n'est déjà fait... A veiller !

 

 

Source : Blog Secura - 11 Septembre 2020 - Zerologon : vulnérabilité dans le protocole Netlogon qui réinitialisation certaines valeurs de chiffrement AES-CFB8 en zéros.