Les manières d'exploiter ActiveDirectory sont très diverses et il en va de même pour ses vulnérabilités. En cause, le nombre de services nécessaires au fonctionnement de l'environnement. C'est Kerberos qui récemment a été victime de la découverte d'une faille, menant à une vulnérabilité assez importante que nous allons découvrir dans cet article.
Je recommande au préalable la lecture de l'article sur Active Directory sur ilearned si vous n'êtes pas à l'aise avec le concept. A noter également que la majorité des informations que j'exposerais sont tirées de l'article de l'auteur du protocole d'exploitation de la vulnérabilité.
Retour sur le TGT
Kerberos repose sur un système de requête pour obtenir un ticket d'accès qui permettra d'accéder aux différents services de l'environnement. La dernière étape du processus est l'AS_REP, qui contient la réponse du KDC. Dans le cas d'une réponse positive, c'est à dire lorsque l'utilisateur s'est authentifié avec succès, l'AS_REP contient le TGT. Ce dernier contient un certain nombre d'informations, le nom de l'utilisateur et autres données du genre, et surtout le PAC pour "Privilege Attribute Certificate" qui décrit les privilèges de l'utilisateur notamment et ses groupes d'appartenance. De sorte que lorsque l'utilisateur demandera un TGS, c'est le PAC qui sera lu pour savoir s'il peut lui être accordé. Le PACest signé par krbtgt (l'utilisateur service responsable de Kerberos, il n'a pas besoin d'être managé) avec son secret, ainsi, il est impossible de modifier ces informations sans avoir ce dernier. Cela dit, quand on le possède, on peut faire ce que nous voulons. Par exemple créer de toute pièce un TGT dans lequel il est dit que nous sommes l'utilisateur "ilearned" (même s'il n'existe pas) et se donner tous les droits d'administration en s'ajoutant, sans que ce soit la réalité, dans les groupes d'administration, cette méthode, nommée Golden Ticket, est surtout utilisée pour la persistance, c'est à dire l'étape d'une intrusion où l'attaquant cherche à maintenir son accès à sa cible, en particulier avec des privilèges dans ce cas (si vous souhaitez plus d'information, il y a cet article de hackndo). Le PAC est donc un morceau très important du TGT.
CVE-2021-42287/CVE-2021-42278
Le PAC a déjà été victime d'une vulnérabilité il y a quelque temps : MS14-068 (CVE-2014-6324) qui consistait en la possibilité pour n'importe quelle utilisateur de forger un PAC arbitraire, ce qui menait à une élévation de privilège. Oui, mais voilà, on modifie un PAC pour obtenir un accès supplémentaire. Deux questions se posent alors est-il possible d'obtenir un TGT sans PAC? Et dans ce cas que ce passe-t-il concernant nos droits ? Premier fait amusant, la réponse à la première question est positive d'après la description de la faille CVE-2021-42287. Dans cette situation, lorsque l'utilisateur demandera un accès, c'est à dire un TGS, il obtiendra une surprise dans son TGS : un PAC sera ajouté. Mais, ce dernier ne contiendra pas nécessairement l'identité de celui qui l'a demandé. Pour forcer ce changement d'identité il faut spécifier à un utilisateur l'attribut, (c'est à dire la propriété LDAP) altSecurityIdentities avec l'identité de notre utilisateur. C'est peut être un peu brouillon, mais voici un schéma pour illustrer le processus :
Ainsi, nous agissons en tant qu'un autre. On pourrait alors se dire que nous pouvons tirer partie de cette vulnérabilité directement avec cette petite méthode, mais en réalité pas vraiment. En effet, il est nécessaire comme nous l'avons vu, d'ajouter/modifier un attribut d'un utilisateur, ce qui suppose que nous possédons déjà des droits d'écriture sur ce dernier, et il existe déjà des méthodes très efficace dans cette situation (sans compter que j'ai aussi mis sous silence la condition d'attaquer un domaine externe). Donc ce n'est pas vraiment intéressant. Cependant, on peut faire mieux.
Pour se fixer les idées on se place dans un domaine ilearned.local, et on nommera DC son contrôleur de domaine. Le processus d'exploitation démarre avec une idée un peu bête. Pour exploiter le domaine local, on peut créer un compte machine (ça peut paraître une chose farfelu, mais par défaut tous les utilisateurs ont le droit de le faire dans un Active Directory) portant le même nom que le contrôleur de domaine (sans le $ qui apparaît à la fin des noms SAM), c'est le sujet de la CVE-2021-42278, car cela devrait théoriquement être impossible. Et ainsi, lorsque nous demanderons un ticket sans PAC, cela supprimera le champ "machine account" du demandeur. Par conséquent lorsque nous demanderons un TGS pour le service DC, le champs étant vide et le PAC de même, un processus similaire à la précédente situation entrera en jeu et le TGS contiendra un PAC avec… le compte complet du contrôleur de domaine: DC$. La raison est simple, le TGT ne contient pas de nom de machine correct, et donc le KDC cherchera le nom le plus proche, d'où le résultat. Avec ce ticket, portant le nom du contrôleur, on peut effectuer une réplication des hashs du domaine (opération de backup grossièrement) et obtenir, en particulier celui de l'administrateur.
La plupart des méthodes d'exploitation de cette vulnérabilité se base sur PowerShell, même si un certain nombre d'outils ont été publiés pour faciliter le travail comme noPac un outil de @cube0x0 auquel fait référence le titre de l'article. Il va s'en dire que les acteurs malveillant ont d'ores et déjà commencé à l'utiliser !
Conclusion
Cette vulnérabilité permet donc une escalade de privilège assez rapide à effectuer dans un environnement Active Directory, et mène à sa compromission la plus totale. Pour s'en prémunir, il n'y a pas de secret, faire la mise à jour proposée par Microsoft, ne pas permettre à des utilisateurs d'ajouter des comptes machines au domaine (ce qui d'ailleurs endigue un grand nombre d'attaques), et mettre en place une détection des différentes traces que cause l'attaque !