Il y a quelques jours, James Forshaw, une rock star de la sécu, a posté un article sur le blog de google Project Zero.
Project Zero, c’est la cellule de google liée à la sécurité. Le boulot des personnes qui sont là bas, c’est de trouver des 0-day au petit déjeuner. Et ça tombe bien, Forshaw en a trouvé une sympathique,que j’ai disséqué 🙂

De quoi parle t-on ?

Avant toute chose, rendons à Forshaw ce qui est à Forshaw : son article est disponible ici : https://googleprojectzero.blogspot.com/2022/10/rc4-is-still-considered-harmful.html. Il est très intéressant et il serait de bon ton d’aller le lire (mais après, restez ici pour l’instant 😃 ).
Je vais simplement réexpliquer rapidement la vulnérabilité dans un premier temps, puis on parlera de ce j’ai fait par rapport à cette faiblesse 🙂

Globalement, l’article de base nous explique que Forshaw a trouvé deux vulnérabilités sur l’implémentation d’un algorithme de chiffrement utilisés par kerberos. Rien que ça.

Attention cependant, pour comprendre l’article d’origine et celui-ci, une connaissance de kerberos reste recommandée.

La problématique

Sans rentrer dans les détails -l’idée n’étant pas de plagier l’article d’origine- le fonctionnement est le suivant : lors d’une authentification kerberos, il est possible d’utiliser plusieurs algos de chiffrement.
Ces algorithmes sont choisis par le client, qui peut préciser au serveur quel chiffrement utiliser : AES, RSADSI RC4-HMAC, etc. Certains de ces algorithmes sont définis dans la RFC, tandis que d’autres ont été rajoutés par Microsoft pour des raisons… qui leur sont propres 😁.

James Forshaw a donc analysé cryptdll.dll (la dll utilisée par windows pour tout ce qui est chiffrement) et l’algorithme RSADSI RC4-MD4 lui a sauté aux yeux. Les plus vieux d’entre nous se souviendront probablement de RC4 qui était utilisé par le protocole wifi WEP. Cependant, la vulnérabilité ici n’a que peu de rapport, n’essayez pas de faire un lien entre les deux 😀

Cette méthode est ici dangereuse pour plusieurs raisons :

• même si les clés font 16 octets, seuls les 8 premiers sont utilisés
• la clé est utilisée telle quelle, sans salt, IV, ou autre technique de ce genre. Cela signifie qu’elle sera toujours identique pour un même mot de passe
• le type de message est totalement ignoré, ce qui revient plus ou moins au même problème que la ligne précédente
• les données chiffrées ne sont pas protégées contre les modifications à la volée (le tampering)
• enfin, les clés de sessions générées ne contiennent que 5 octets d’aléatoire. Une fois ces clés de sessions récupérées, il est possible de tout déchiffrer.

Comme dit précédemment, l’article original détaille bien plus en profondeur tous ces points, l’idée ici n’était que de montrer que RSADSI RC4-MD4 est à considérer comme… nul !

Les vulnérabilités

De ce constat, Forshaw a donc creusé et a remonté deux faiblesses. La première nécessite de faire de la capture réseau afin d’intercepter les messages kerberos pour les modifier à la volée. Mais ce n’était pas assez marrant. Il a donc remonté une deuxième vulnérabilité : la CVE-2022-33679, et c’est celle-ci que j’ai analysé.

Cette faiblesse fonctionne simplement : Il est possible de demander un TGT qui sera chiffré avec le chiffrement RC4-MD4 si la pré-authentification Kerberos est désactivée. Vu qu’il a une forme connue, cela nous permet de récupérer le flux RC4 du début du paquet (24 bytes de checksum et 21 bytes de format de fichier) et donc de chiffrer n’importe quel paquet de taille inférieure ou égal.

Heureusement pour nous, la taille d’un paquet chiffré de timestamp peut être de longueur inférieure à 21. Etant donné qu’un null byte n’est pas pris en compte dans le timestamp, on va tester d’envoyer des paquets de demande avec le byte qu’on pense être déchiffré en null byte. Si le serveur valide notre requête, c’est que c’était le bon.

On décale ensuite le null byte jusqu’à déchiffrer le clé de session, qui nous permettra de demander un TGS et de compromettre le compte.

oracle padding

Ainsi, pour le premier TGT, on sait que le message envoyé contient 0 à l’octet N, et qu’il est chiffré en X. Pour le deuxième message d’authentification l’octet N+1 contient 0 et et chiffré en Y.
Grâce à ce fonctionnement, ainsi que par la faiblesse de RSADSI RC4-MD4, il est possible en envoyant moins de 1280 TGT de vérifier octet par octet que le chiffrement est toujours validé par le serveur.

Remédiation

Microsoft a reconnu les deux vulnérabilités, qui ont toutes les deux un score CVSS de 8.1. Afin de patcher ces faiblesses, Microsoft a proposé des KB sur tous les environnements vulnérables (c’est à dire quasiment toutes les versions de windows). Les références de KB sont disponibles ici :

• https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-33679
• https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2022-33647

De plus, MS recommande également de mettre en place le Kerberos Armoring, autrement appelé Flexible Authentication Secure Tunneling (FAST). Cette mesure doit tout de même être testée avant d’être mise en production 😀

My gift to the world

En lisant l’article de Forshaw, je me suis dit qu’il serait sympa de faire un PoC pour cette vulnérabilité. La faiblesse a un rapport clair avec les TI internes, personne n’a encore sorti de PoC, et développer cet exploit me donnait très envie.

J’ai donc sorti mon meilleur environnement de dev, mon plus beau sublime text, et je suis allé à la recherche du saint graal !
Après quasiment une semaine de compréhension de l’article, de tests, de dev, et de nuits trop courtes, je peux enfin annoncer la publication officielle d’un PoC fonctionnel pour la CVE-2022-33679 ! Le code est disponible sur mon Github : https://github.com/Bdenneu/CVE-2022-33679. N’hésitez pas à aller le star ⭐ !