Analyse technique des vulnérabilités CVE-2022-33679 et CVE-2022-33647 Kerberos

Écrit par Yoav Iellin et Dor Segal, chercheurs à Silverfort

Le patch Tuesday de septembre 2022 de Microsoft comprenait deux vulnérabilités d'élévation des privilèges à haut risque dans Kerberos, qui ont été découvertes par Google Project Zero. Les deux vulnérabilités tirent parti de la possibilité de forcer Kerberos à rétrograder son codage du cryptage AES par défaut vers le MD4-RC4 obsolète. Une fois le cryptage rétrogradé, les deux vulnérabilités entrent en jeu et permettent à un attaquant d'abuser des faiblesses du cryptage MD4-RC4.

La première, CVE-2022-33679, permet à un attaquant d'obtenir une session authentifiée au nom de la victime pouvant conduire à l'exécution de code arbitraire. Le second, CVE-2022-33647, permet à un attaquant qui a déjà réussi à effectuer une attaque Man-in-the-Middle d'émettre des tickets de service Kerberos au nom de l'utilisateur cible, obtenant ainsi les mêmes privilèges que l'utilisateur.

Il est important de noter que si les deux vulnérabilités ciblent les faiblesses du cryptage MD4-RC4 hérité, chacune abuse d'une faiblesse différente, ce qui entraîne des conditions préalables et des scénarios d'attaque différents.

Cet article comprend une analyse technique détaillée et des explications sur CVE-2022-33679 et CVE-2022-33647.

CVE-2022-33679 – Analyse de vulnérabilité

La vulnérabilité CVE-2022-33679, pour lequel une preuve de concept a été récemment libéré, réside dans la façon dont Kerberos crypte sa clé de session et est rendu possible par l'utilisation de Kerberos si le type de cryptage RC4-MD4 obsolète. L'attaque se compose de deux parties A) demandant un nouveau ticket TGT en utilisant le type RC4-MD4 suivi de B) une rupture octet par octet du flux de clé.

Processus d'exploitation :

1. Obtenez le ticket TGT en envoyant le paquet AS-REQ au serveur KDC. la requête doit demander le type de cryptage RC4-MD4. Pour que l'attaque réussisse, les deux conditions suivantes doivent être remplies :
   1. Rétrogradez explicitement Kerberos le cryptage de son AES par défaut ou du plus faible RC4-MD4. Cela rend l'attaque possible car sa clé n'est que de 8 octets sans IV ni sel.  
   2. L'indicateur de l'objet utilisateur « Ne pas nécessiter la pré-authentification Kerberos » est activé. Cela permet d'obtenir un TGT avec une clé de session cryptée sans avoir besoin de connaître le mot de passe de l'utilisateur. Pré authentification est un mécanisme par lequel le client crypte l'horodatage actuel avec le mot de passe saisi et l'envoie au KDC où il valide l'intégrité du mot de passe avant de générer une clé de session et un TGT. Grâce à l'indicateur « Ne nécessite pas de pré-authentification Kerberos », le KDC peut être ciblé directement et ne nécessite aucune technique d'attaque spéciale telle que Man In The Middle.
2. Une fois que l'attaquant a réussi à obtenir un ticket chiffré, le paquet AS-REP consiste en une clé de session TGT chiffrée d'une longueur de 40 bits. En utilisant le type de chiffrement obsolète RC4-MD4, l'attaquant peut tirer parti de sa connaissance du début fixe du paquet chiffré pour extraire 45 octets du flux de clé.
3. Désormais, l'attaquant peut utiliser ce flux de clés pour rechiffrer et demander un ticket TGT au KDC avec une pré-authentification personnalisée qui sera utilisée pour vérifier si le flux de clés est correct et casser le reste de la clé de session TGT 40 bits suivante. octet par octet. Cela se fait en abusant de deux faiblesses du protocole ASN.1 utilisé pour le codage Kerberos, pour tirer parti du contrôle limité de l'attaquant sur la taille du champ de pré-authentification :
   1. L'analyseur KDC ignore les chaînes terminées par NUL à la fin de l'objet. Cela nous permet d'ajouter un caractère NUL à la fin de l'objet KerberosTime. Cela fonctionnera pour une estimation d'un seul octet, mais nous devons encore en deviner quatre autres.
   2. L'analyseur KDC ne valide pas la longueur des longueurs codées. Les longueurs de chaîne ASN.1 sont représentées par 1 à 4 octets et l'analyseur KDC ASN.1 n'applique pas le chemin le plus court. Par conséquent, nous pouvons représenter notre longueur de chaîne d'horodatage avec une taille de 1 à 4 octets comme nous le souhaitons. Cela signifie que nous pouvons agrandir encore plus la longueur du texte brut et pousser l'octet NUL à la position suivante et deviner l'octet suivant du flux de clé.
4. Enfin, l'attaquant peut rechiffrer l'horodatage et valider chaque supposition en envoyant un AS-REQ avec une pré-authentification chiffrée et recevra une erreur si la date de pré-authentification chiffrée est incorrecte. Si la pré-authentification a réussi, l'attaquant est en mesure de découvrir un autre octet du flux de clés car il existe jusqu'à 256 options de supposition pour chaque octet. La répétition de ce processus permet d'obtenir tous les octets de flux de clé requis pour déchiffrer la clé de session stockée dans le ticket d'origine.

La clé de session obtenue donne à l'attaquant la possibilité de demander un ticket à n'importe quel SPN au nom de l'utilisateur ciblé.

Analyse technique CVE-2022-33647

Heureusement pour l'attaquant, la vulnérabilité CVE-2022-33647 fonctionne avec une pré-authentification, contrairement à CVE-2022-33679. Ceci est important car la pré-authentification est activée par défaut pour chaque objet créé dans Active Directory. La principale exigence pour cette attaque est un Man-In-The-Middle entre le client et le contrôleur de domaine (ce type d'attaque est courant et il existe de nombreuses façons d'y parvenir, comme l'usurpation DNS, l'empoisonnement ARP, etc.). Le MITM est utilisé pour forcer le client à rétrograder le cryptage vers MD4-RC4.

Flux d'exploitation

Lorsque la première requête AS est envoyée par le client, le KDC répond avec le message « pre-auth is required ». Cependant, l'attaquant peut altérer la réponse du KDC car à ce stade de l'authentification il n'y a pas de vérification. Nous allons modifier le cryptage pris en charge par le KDC en RC4-MD4, comme indiqué sur la figure. En conséquence, (si RC4 est activé), le client enverra un AS_REQ avec pré-authentification à l'aide de l'algorithme MD4-RC4.

À partir de ce moment, l'attaquant a deux options :

1. Brute force la clé de session de 5 octets, ce qui peut ne pas être aussi efficace et prendre beaucoup de temps.
2. L'autre option consiste à tirer parti de la connaissance des données en clair - la pré-authentification. Dans Kebreros, l'adversaire MITM peut avoir une estimation précise de l'horodatage de pré-authentification en clair créé par le client dans la demande AS. Le mécanisme de chiffrement n'a pas de vecteur d'initialisation ou nonce et il ignore la valeur d'utilisation de la clé. Par conséquent, le même flux de clés est utilisé dans différentes parties de l'échange d'authentification. Ainsi, la plupart du flux de clés utilise le même flux de clés RC4. La pré-autorisation contient un horodatage crypté, donc en utilisant notre connaissance de l'heure actuelle, l'attaquant peut découvrir une partie du flux de clés. Si l'attaquant a de la chance, le même flux de clé sera utilisé pour déchiffrer 4 octets de la clé de session TGT dans la réponse AS. Le dernier octet chevauche le plus petit octet de l'horodatage, qui représente des microsecondes, inconnues de l'attaquant. Le dernier octet sera cassé lors d'une attaque par force brute contre une requête TGS réalisée de la victime, comme indiqué ci-dessous.

Zoom avant sur la sérialisation ASN.1

Le codage ASN.1 DER est un système de codage d'étiquette, de longueur et de valeur pour chaque élément. L'horodatage de pré-authentification est codé à l'aide de cette méthode. La structure de l'horodatage codé consiste en une séquence à deux éléments. Le premier, un objet GeneralizedTime (KerberosTime) au format Zulu. Le deuxième élément est un entier qui représente les microsecondes.

Chaque élément a sa propre balise et sa propre longueur après la valeur. Pour cette raison, nous pouvons identifier 10 octets constants qui représentent toutes les balises et longueurs.

• 30 -> Balise de séquence
• 1A – (int) 26 (longueur de toute la structure)
• A0 – Balise du 1er élément
• 11 – longueur de l'élément
• 18 – Généraliser l'horodatage
• 0F – longueur de la valeur (int) (15)
• A1 – Balise du 2e élément
• 05 - (int) longueur de l'élément
• 02 – Balise de type INTEGER
• 03 - longueur de la valeur (entier)

Le nombre total d'octets constants est de 10, nous ajouterons une autre longueur de 15 octets pour deviner l'horodatage. Les trois derniers octets sont l'élément microsecondes qui n'est pas efficace à deviner. Enfin, 24 octets supplémentaires de zéros avant la partie cryptée donneront un flux de clés de 49 octets. La clé de session TGT est située entre les octets 46 à 50 de la réponse AS. Le dernier octet de flux de clés manquant peut être brutalement forcé contre un ticket de service intercepté de la victime.

Pièce

Ces vulnérabilités ont été fermées par Microsoft dans la mise à jour de sécurité de septembre. La mise à jour a désactivé le type de cryptage RC4-MD4 (-128) ainsi que le type de cryptage RC4-HMAC-OLD (-133). Une fois corrigé, les futurs AS-REQ/TGS-REQ utilisant l'un de ces deux types de chiffrement recevront l'erreur « Type de chiffrement non pris en charge ».

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-33679

renseignements supplémentaires

https://bugs.chromium.org/p/project-zero/issues/detail?id=2310&q=label%3ACVE-2022-33647 – analyse de James Forshaw