- Qu'est-ce qui conduit à cette vulnérabilité d'AD ?
- Escalade de privilèges avec la vulnérabilité AD CVE-2022-26923
- Modification du compte machine dNSHostName
- Modèle de certificat avec l'indicateur SubjectAltRequireDns
- Abus de la vulnérabilité AD CVE-2022-26923
- Variations de la trajectoire d'attaque
- Facteurs atténuants
- DSP détection de cette vulnérabilité AD
- Autres détections de CVE-2022-26923
- Remédiation aux vulnérabilités AD
Le 10 mai 2022, une vulnérabilité dans Active Directory (AD) et Active Directory Certificate Services (AD CS) a été divulguée et corrigée. Cette vulnérabilité AD peut conduire à une escalade des privilèges. Dans les installations par défaut d'AD CS, un utilisateur à faibles privilèges peut exploiter la vulnérabilité en demandant un certificat d'authentification, puis en utilisant ce certificat pour se faire passer pour un autre compte d'ordinateur, ce qui entraîne une prise de contrôle complète du domaine. En quoi consiste cette vulnérabilité AD ? Lisez la suite pour un guide complet sur CVE-2022-26923.
Qu'est-ce qui conduit à cette vulnérabilité d'AD ?
AD a été publié pour la première fois en 1999 par Microsoft en tant que système centralisé de gestion des identités, composé d'un ensemble de processus et de services. AD contient plusieurs protocoles qui peuvent être utilisés pour l'authentification et l'autorisation des identités au sein d'une entreprise. Le plus souvent, AD est utilisé pour gérer facilement les utilisateurs, les groupes et les ordinateurs au sein d'une entreprise. AD est devenu le système de gestion des identités le plus populaire, utilisé pour gérer les identités dans la grande majorité des entreprises.
Dans Windows Server 2008, Microsoft a introduit AD CS, qui permet de créer et de gérer facilement des certificats d'infrastructure à clé publique (PKI). Ces certificats peuvent être utilisés pour la signature numérique, la protection des protocoles et l'authentification.
Lorsque des certificats d'AD CS sont utilisés pour l'authentification dans un environnement AD (PKINIT), de nombreuses nouvelles voies d'attaque sont ouvertes, y compris des configurations erronées et des vulnérabilités. En juin 2021, Will Schroeder et Lee Christensen ont publié un livre blanc détaillant plusieurs configurations erronées susceptibles d'entraîner une escalade des privilèges. Certaines de ces configurations erronées étaient par défaut dans AD CS lors de l'installation et peuvent conduire à une prise de contrôle complète du domaine. Ces erreurs de configuration sont indépendantes de la vulnérabilité décrite dans ce billet.
Lecture associée
Escalade de privilèges avec la vulnérabilité AD CVE-2022-26923
CVE-2022-26923 est une vulnérabilité d'escalade de privilèges découverte par Oliver Lyak. L'exploitation repose sur deux actions principales :
- Modification du nom de l'hôte d'un compte d'ordinateur dNSHostName pour qu'il corresponde à celui d'un autre compte d'ordinateur.
- Demande d'un certificat pour le compte de l'ordinateur, à l'aide d'un modèle configuré avec l'option SubjectAltRequireDns
L'indicateur SubjectAltRequireDns pour les modèles de certificat signifie que les certificats demandés à l'aide de ce modèle ont un certificat Sujet correspondant à l'attribut dNSHostName du compte AD demandeur.
Ces deux actions sont possibles dans une installation par défaut d'AD et d'AD CS.
En demandant un certificat à l'aide d'un compte d 'ordinateur qui a le même dNSHostName qu'un autre compte d'ordinateur, les attaquants peuvent s'authentifier en tant que compte d'ordinateur cible et élever leurs privilèges. Cette vulnérabilité peut être utilisée pour cibler n'importe quel ordinateur actif dans AD.
Modification du compte machine dNSHostName
Dans une installation AD par défaut, tout utilisateur authentifié peut ajouter des comptes machine. Cette action est régie par les paramètres suivants :
- Les Ajouter des postes de travail au domaine dans la stratégie du contrôleur de domaine, qui définit qui se voit accorder des privilèges pour ajouter des comptes d'ordinateur au domaine (défini par défaut sur Utilisateurs authentifiés ; figure 1).
- Les ms-DS-MachineAccountQuota sur l'en-tête du contexte de nommage (CN), qui définit le nombre de comptes d'ordinateur que les utilisateurs à faible privilège sont autorisés à ajouter (fixé à 10 par défaut ; figure 2).
Avec ces paramètres par défaut, tout compte à faible privilège peut facilement créer jusqu'à 10 comptes d'ordinateur sur le domaine en utilisant la cmdlet New-MachineAccount de Powermadpour ajouter un compte d'ordinateur nommé LowPrivComputer(Figure 3).
La liste de contrôle d'accès discrétionnaire (Dacl) pour ce nouveau compte d'ordinateur montre que le compte créateur a l'autorisation Validated write to DNS host name(Figure 4).
Par conséquent, l'attribut dNSHostName peut être modifié par le compte qui l'a créé, simplement en utilisant la cmdlet Set-DomainObject de PowerView(Figure 5).
Modèle de certificat avec l'indicateur SubjectAltRequireDns
Dans une installation AD CS par défaut, plusieurs modèles de certificat ont l'indicateur SubjectAltRequireDns activé. Par exemple, le modèle Machine est utilisé par défaut pour inscrire des comptes d'ordinateur à l'authentification par certificat. La cmdlet Get-DomainCertificateTemplate de PowerView est utilisée pour afficher l'attribut msPKI-Certificate-Name-Flag du modèle Machine(Figure 6).
En utilisant le compte machine créé précédemment, il est possible de demander un certificat en utilisant ce modèle pour le compte LowPrivComputer avec le dnshostname modifié(somethingelse.f105-d01.lab). Pour ce faire, l'outil Python Certipy est utilisé(Figure 7).
Abus de la vulnérabilité AD CVE-2022-26923
Comme nous l'avons déjà mentionné, cette méthode peut être utilisée pour élever les privilèges au sein d'un domaine AD. Un chemin d'attaque courant consiste à cibler un contrôleur de domaine (DC). Après avoir créé le compte d'ordinateur(LowPrivComputer), les attaquants commencent par modifier l'attribut dNSHostName du compte pour qu'il soit identique à celui du DC(F105-D02-DC01.f105-d01.lab), comme le montre la figure 8.
Pour ce chemin d'attaque, le contenu du servicePrincipalName (SPN) doit être effacé. Lorsque l'attribut dNSHostName est mis à jour, toutes les entrées SPN sont également mises à jour pour correspondre au nouveau nom. Cela entre en conflit avec les entrées SPN pour le compte authentique(F105-D01-DC01), et la modification échoue.
Après le changement de dNSHostName, un certificat pour ce nouveau nom peut être demandé(Figure 9).
Une fois le certificat récupéré, le dNSHostName doit être modifié à nouveau(figure 10) afin que, lorsque le certificat est utilisé et que le DC recherche le nom du client, il n'y ait qu'une seule correspondance (le compte DC authentique).
Il est maintenant possible de s'authentifier en tant que compte de l'ordinateur DC. Rubeus fournit un commutateur /getcredentials à la commande asktgt qui utilise une requête d'utilisateur à utilisateur (U2U). Lorsqu'un certificat est fourni pour l'authentification, le hachage NT des comptes demandeurs peut être récupéré grâce aux données d'identification PAC NTLM_SUPPLEMENTAL_CREDENTIAL PAC_INFO_BUFFER(Figure 11).
Ce hachage NT peut être utilisé pour s'authentifier davantage en tant que DC (à l'aide de pass-the-hash ou overpass-the-hash) ou les Silver Tickets peuvent être falsifiés.
Variations de la trajectoire d'attaque
Outre le chemin d'attaque présenté dans les exemples précédents, plusieurs légères variations peuvent être utilisées pour exploiter cette vulnérabilité d'AD.
Premièrement, un attaquant ayant un certain contrôle sur un objet informatique existant n'a pas besoin de pouvoir créer un compte informatique. La figure 12 montre que le compte d'utilisateur à faibles privilèges dispose de la fonction GenericWrite sur l'objet informatique DatabaseServer.
Avec ce privilège, un attaquant peut effacer les SPN et modifier l'attribut dNSHostName pour qu'il corresponde à celui d'un autre compte d'ordinateur(figure 13).
Deux points méritent d'être soulignés :
- Le système visé n'est pas un DC. Cette vulnérabilité peut être utilisée pour cibler n'importe quel système relié à un domaine, et pas seulement les DC.
- Cette partie de l'attaque peut être effectuée sur des DCs complètement à jour. Lorsque le compte qui effectue la modification dispose d'autorisations GenericAll ou GenericWrite spécifiques, le dNSHostName peut être modifié pour correspondre à celui d'un autre compte d'ordinateur. (Ceci n'est pas possible lorsque l'autorisation Validated write to DNS host name est accordée au créateur d'un compte d'ordinateur).
Le nom dNSHostName ayant été modifié, un certificat peut être demandé en utilisant le nom d'hôte DNS cible(figure 14).
Le nom dNSHostName ayant été modifié, comme dans le chemin d'attaque précédent, l'attaquant peut maintenant utiliser le certificat acquis pour s'authentifier en tant que compte de l'ordinateur cible.
Une autre différence entre le chemin d'attaque précédent et celui-ci : L'attaquant n'a pas besoin d'utiliser le certificat pour s'authentifier auprès de Kerberos et demander un ticket d'octroi de ticket (TGT) pour le compte cible. Il peut utiliser le certificat pour s'authentifier directement auprès de certains services. L'exemple suivant utilise le certificat pour se connecter directement à LDAP et configurer la délégation contrainte basée sur les ressources (RBCD) sur l'objet informatique cible(Figure 15).
Notez que la configuration de RBCD n'est qu'un exemple de ce qu'un attaquant peut faire en utilisant le certificat pour s'authentifier directement auprès des services. WinRM, RDP et IIS prennent tous en charge l'authentification du client à l'aide de certificats, ce qui offre de nombreuses autres possibilités. D'autres actions, telles que la configuration d'informations d'identification fictives, peuvent être effectuées via LDAP, en fonction de l'environnement et des autorisations du compte de l'ordinateur compromis.
Pour terminer le chemin d'attaque, l'attaquant peut utiliser l'extension Kerberos Service-for-User (S4U) pour obtenir un ticket de service pour le système cible en tant qu'utilisateur administratif (à condition que l'utilisateur administratif n'ait pas été protégé contre la délégation), comme le montrent la figure 16 et la figure 17.
L'attaquant peut utiliser le ticket de service résultant pour accéder au service sur le système cible en tant qu'utilisateur usurpé. Une bonne démonstration consiste à utiliser WinRM/PowerShell Remoting pour sortir la valeur de "whoami", qui nécessite un ticket de service pour le service HTTP sur le système cible(Figure 18).
ServicePrincipalNames
Pour ces deux voies d'attaque démontrées, les SPN doivent être effacés avant de changer le dNSHostName. Cela peut sembler être une condition sine qua non de l'exploitation de la vulnérabilité, mais ce n'est pas le cas. En utilisant le protocole MS-SAMR pour créer un compte d'ordinateur à l'aide de la méthode SamrCreateUser2InDomain, un attaquant peut créer un compte d'ordinateur sans aucun SPN, simplement en utilisant le script d'exemple addcomputer.py d'impacketpour créer un compte d'ordinateur appelé NoSPNComputer (Figure 19).
Le compte d'ordinateur qui en résulte n'a pas de SPN et n'a pas besoin d'être effacé (voir la figure 20).
Facteurs atténuants
Restreindre la capacité des utilisateurs peu privilégiés à créer des comptes machines, soit en définissant l'attribut ms-DS-MachineAccountQuota sur la tête NC à 0, soit en modifiant le droit Ajouter des stations de travail à l' utilisateur du domaine dans la stratégie du contrôleur de domaine à un groupe spécifique plutôt qu'aux utilisateurs authentifiés, réduit les voies d'attaque viables pour cette vulnérabilité. Autres actions pour réduire le potentiel d'exploitation :
- Remplacez les modèles de certificat utilisant le "nom DNS" par quelque chose comme le "nom principal de l'utilisateur (UPN)"(Figure 21).
- Configurez les modèles de certificat de façon à ce que l'inscription nécessite l'approbation du gestionnaire(Figure 22).
DSP détection de cette vulnérabilité AD
Comme cet exploit ne comporte que deux actions obligatoires, Semperis Directory Services Protector (DSP) a deux possibilités de le détecter :
- Lorsque le changement de dNSHostName se produit
- Lorsque le certificat est demandé
DSP collecte déjà les données de changement AD, le choix évident est donc de détecter une tentative d'exploitation de cette vulnérabilité lorsque le dNSHostName est modifié. L'indicateur DSP commence par surveiller la modification de l'attribut dNSHostName d'un compte d'ordinateur.
Lorsqu'un tel changement est détecté, DSP effectue une requête LDAP pour tous les comptes d'ordinateur ayant cette valeur dNSHostName, à l'exclusion du nom distinctif de l'objet (DN) du compte qui a déclenché la requête LDAP. DSP marque chaque résultat comme un indicateur de compromission (IoC). Cet indicateur devrait permettre de détecter toute tentative d'exploitation de cette vulnérabilité, que l'attaque complète ait réussi ou non. Comme le montre la figure 23, l'indicateur de compromission renvoie les informations suivantes :
- Le compte qui a effectué le changement
- Les DN des deux comptes informatiques concernés
- Le nom dNSHostName d'origine du compte dont l'attribut a été modifié.
- L'attribut dNSHostName du compte ciblé
Autres détections de CVE-2022-26923
Plusieurs événements Windows pertinents peuvent également être utilisés pour aider à identifier les tentatives d'exploitation de cette vulnérabilité.
Effacer les SPN
Lorsqu'un chemin d'attaque nécessite l'effacement des SPN du compte d'ordinateur utilisé dans l'attaque, un événement 5136 pour chacun des SPN configurés est créé avec le type d'opération Valeur supprimée(figure 24).
Modification de dNSHostName
Lorsque l'attribut dNSHostName est modifié, un événement 4742 est créé(Figure 25).
La section Attributs modifiés de cet événement montre la nouvelle valeur du nom d'hôte DNS(Figure 26).
En plus de l'événement 4742, deux événements 5136 sont créés. Le premier montre la valeur dNSHostName d 'origine et est du type d'opération Value Deleted(Figure 27).
La seconde montre la nouvelle valeur de dNSHostName et est du type d'opération Value Added(Figure 28).
Création d'ordinateurs sans SPN
Comme indiqué précédemment, les attaquants peuvent créer des comptes d'ordinateur sans SPN initial en utilisant MS-SAMR. Lorsqu'ils le font, un événement 4741 est créé(figure 29).
Dans la section Attributs de cet événement, les noms des principaux services sont vides, comme le montre la figure 30.
Demande de certificat
Lorsqu'un certificat est demandé, un événement 4887 est créé sur l'autorité de certification (AC). Cet événement indique le nom du comptedemandeur (Requester). La valeur de l'attribut dNSHostName est indiquée comme sujet(Figure 31).
Remédiation aux vulnérabilités AD
Un correctif pour cette vulnérabilité a été publié dans le cadre des mises à jour de sécurité de mai 2022. Ce correctif a introduit quelques changements :
- Les comptes disposant de l'autorisation Validated write to DNS host name ne sont plus en mesure de modifier l'attribut dNSHostName pour qu'il corresponde à celui d'un autre compte sur les DCs patchés. Les tentatives de modification entraînent une violation de contrainte(Figure 32).
Note : Comme mentionné précédemment, même après ce correctif, les attaquants peuvent modifier l'attribut dNSHostName d 'un compte d'ordinateur pour qu'il corresponde à celui d'un autre compte d'ordinateur, même si cette action nécessite désormais des autorisations plus élevées telles que GenericAll/GenericWrite.
- Les certificats demandés aux AC corrigées contiennent le nouvel OID szOID_NTDS_CA_SECURITY_EXT (1.3.6.1.4.1.311.25.2.1)(figure 33).
Ce champ contient une chaîne ASCII (en hexadécimal) du SID du compte qui a demandé le certificat. Lorsqu'un certificat utilisé pour tirer parti de cette vulnérabilité est utilisé pour s'authentifier auprès d'un DC corrigé, une erreur CERTIFICATE_MISMATCH est renvoyée(Figure 34).
Note : Si ce certificat est utilisé pour s'authentifier auprès d'un DC non patché, l'authentification sera réussie et la vulnérabilité exploitable(Figure 35). Il est donc très important de mettre à jour tous les DC et CA avec le correctif approprié.
En savoir plus
Pour en savoir plus sur cette vulnérabilité AD et sur la manière de protéger votre organisation, consultez les références et ressources suivantes.
Ressources
En savoir plus sur Semperis Directory Services Protector ( DSP)
En savoir plus sur Purple Knight Outil d'évaluation de la sécurité d'Active Directory
Références
- https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-26923
- https://research.ifcr.dk/certifried-active-directory-domain-privilege-escalation-cve-2022-26923-9e098fe298f4
- https://offsec.almond.consulting/authenticating-with-certificates-when-pkinit-is-not-supported.html
- https://www.netspi.com/blog/technical/network-penetration-testing/machineaccountquota-is-useful-sometimes/
- https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html
