AD CS Domain Escalation
Il s'agit d'un résumé des sections des techniques d'élévation de privilèges des articles :
Modèles de certificats mal configurés - ESC1
Explication
Explication des modèles de certificats mal configurés - ESC1
Les droits d'inscription sont accordés aux utilisateurs à faibles privilèges par l'AC d'entreprise.
L'approbation du gestionnaire n'est pas requise.
Aucune signature du personnel autorisé n'est nécessaire.
Les descripteurs de sécurité sur les modèles de certificats sont excessivement permissifs, permettant aux utilisateurs à faibles privilèges d'obtenir des droits d'inscription.
Les modèles de certificats sont configurés pour définir des EKU qui facilitent l'authentification :
Les identifiants d'utilisation étendue de clé (EKU) tels que l'authentification client (OID 1.3.6.1.5.5.7.3.2), l'authentification client PKINIT (1.3.6.1.5.2.3.4), la connexion de carte à puce (OID 1.3.6.1.4.1.311.20.2.2), tout usage (OID 2.5.29.37.0), ou aucun EKU (SubCA) sont inclus.
La possibilité pour les demandeurs d'inclure un subjectAltName dans la demande de signature de certificat (CSR) est autorisée par le modèle :
L'Active Directory (AD) donne la priorité au subjectAltName (SAN) dans un certificat pour la vérification d'identité s'il est présent. Cela signifie qu'en spécifiant le SAN dans un CSR, un certificat peut être demandé pour se faire passer pour n'importe quel utilisateur (par exemple, un administrateur de domaine). La possibilité de spécifier un SAN par le demandeur est indiquée dans l'objet AD du modèle de certificat via la propriété
mspki-certificate-name-flag. Cette propriété est un masque de bits, et la présence du drapeauCT_FLAG_ENROLLEE_SUPPLIES_SUBJECTpermet au demandeur de spécifier le SAN.
La configuration décrite permet aux utilisateurs à faibles privilèges de demander des certificats avec n'importe quel SAN de leur choix, permettant l'authentification en tant que n'importe quel principal de domaine via Kerberos ou SChannel.
Cette fonctionnalité est parfois activée pour prendre en charge la génération à la volée de certificats HTTPS ou d'hôte par des produits ou des services de déploiement, ou en raison d'un manque de compréhension.
Il est noté que la création d'un certificat avec cette option déclenche un avertissement, ce qui n'est pas le cas lorsqu'un modèle de certificat existant (tel que le modèle WebServer, qui a CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT activé) est dupliqué puis modifié pour inclure un OID d'authentification.
Abus
Pour trouver des modèles de certificats vulnérables, vous pouvez exécuter :
Pour exploiter cette vulnérabilité pour se faire passer pour un administrateur, on pourrait exécuter :
Ensuite, vous pouvez transformer le certificat généré au format .pfx et l'utiliser pour vous authentifier à nouveau en utilisant Rubeus ou certipy :
Les binaires Windows "Certreq.exe" & "Certutil.exe" peuvent être utilisés pour générer le PFX : https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee
L'énumération des modèles de certificat dans le schéma de configuration de la forêt AD, en particulier ceux ne nécessitant pas d'approbation ou de signatures, possédant une EKU d'authentification client ou de connexion de carte à puce, et avec le drapeau CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT activé, peut être effectuée en exécutant la requête LDAP suivante :
Modèles de certificat mal configurés - ESC2
Explication
Le deuxième scénario d'abus est une variation du premier :
Les droits d'inscription sont accordés aux utilisateurs à faibles privilèges par l'entreprise CA.
L'exigence d'approbation du gestionnaire est désactivée.
Le besoin de signatures autorisées est omis.
Un descripteur de sécurité excessivement permissif sur le modèle de certificat accorde des droits d'inscription aux certificats aux utilisateurs à faibles privilèges.
Le modèle de certificat est défini pour inclure l'EKU Tout Usage ou aucun EKU.
L'EKU Tout Usage permet à un certificat d'être obtenu par un attaquant pour n'importe quel usage, y compris l'authentification client, l'authentification serveur, la signature de code, etc. La même technique utilisée pour ESC3 peut être utilisée pour exploiter ce scénario.
Les certificats sans EKU, qui agissent comme des certificats de CA subordonnés, peuvent être exploités pour n'importe quel usage et peuvent également être utilisés pour signer de nouveaux certificats. Ainsi, un attaquant pourrait spécifier des EKU ou des champs arbitraires dans les nouveaux certificats en utilisant un certificat de CA subordonné.
Cependant, les nouveaux certificats créés pour l'authentification de domaine ne fonctionneront pas si la CA subordonnée n'est pas approuvée par l'objet NTAuthCertificates, qui est le paramètre par défaut. Néanmoins, un attaquant peut toujours créer de nouveaux certificats avec n'importe quel EKU et des valeurs de certificat arbitraires. Ceux-ci pourraient être potentiellement abusés pour une large gamme d'usages (par exemple, la signature de code, l'authentification serveur, etc.) et pourraient avoir des implications significatives pour d'autres applications dans le réseau comme SAML, AD FS, ou IPSec.
Pour énumérer les modèles correspondant à ce scénario dans le schéma de configuration de la forêt AD, la requête LDAP suivante peut être exécutée :
Modèles d'agent d'inscription mal configurés - ESC3
Explication
Ce scénario est similaire aux deux premiers mais exploite un EKU différent (Agent de demande de certificat) et 2 modèles différents (donc il a 2 ensembles de conditions),
L'EKU de l'agent de demande de certificat (OID 1.3.6.1.4.1.311.20.2.1), connu sous le nom d'Agent d'inscription dans la documentation Microsoft, permet à un principal de s'inscrire pour un certificat au nom d'un autre utilisateur.
L'"agent d'inscription" s'inscrit dans un tel modèle et utilise le certificat résultant pour cosigner une CSR au nom de l'autre utilisateur. Il envoie ensuite la CSR cosignée au CA, s'inscrivant dans un modèle qui autorise "l'inscription au nom de", et le CA répond avec un certificat appartenant à l'utilisateur "autre".
Conditions 1:
Les droits d'inscription sont accordés aux utilisateurs à faibles privilèges par le CA d'entreprise.
L'exigence d'approbation du gestionnaire est omise.
Aucune exigence de signatures autorisées.
Le descripteur de sécurité du modèle de certificat est excessivement permissif, accordant des droits d'inscription aux utilisateurs à faibles privilèges.
Le modèle de certificat inclut l'EKU de l'agent de demande de certificat, permettant la demande d'autres modèles de certificat au nom d'autres principaux.
Conditions 2:
Le CA d'entreprise accorde des droits d'inscription aux utilisateurs à faibles privilèges.
L'approbation du gestionnaire est contournée.
La version du schéma du modèle est soit 1, soit dépasse 2, et spécifie une exigence d'émission de politique d'application qui nécessite l'EKU de l'agent de demande de certificat.
Un EKU défini dans le modèle de certificat permet l'authentification de domaine.
Aucune restriction pour les agents d'inscription n'est appliquée sur le CA.
Abus
Vous pouvez utiliser Certify ou Certipy pour abuser de ce scénario:
Les utilisateurs autorisés à obtenir un certificat d'agent d'inscription, les modèles dans lesquels les agents d'inscription sont autorisés à s'inscrire, et les comptes pour lesquels l'agent d'inscription peut agir peuvent être restreints par les CA d'entreprise. Cela est réalisé en ouvrant le certsrc.msc snap-in, en cliquant avec le bouton droit sur la CA, en cliquant sur Propriétés, puis en naviguant vers l'onglet "Agents d'inscription".
Cependant, il est noté que le paramètre par défaut pour les CA est "Ne pas restreindre les agents d'inscription". Lorsque la restriction sur les agents d'inscription est activée par les administrateurs, en la définissant sur "Restreindre les agents d'inscription", la configuration par défaut reste extrêmement permissive. Cela permet à Tout le monde d'accéder à tous les modèles pour s'inscrire en tant que n'importe qui.
Contrôle d'accès vulnérable aux modèles de certificats - ESC4
Explication
Le descripteur de sécurité sur les modèles de certificats définit les autorisations spécifiques que les principaux AD possèdent concernant le modèle.
Si un attaquant possède les autorisations requises pour modifier un modèle et mettre en place des erreurs de configuration exploitables décrites dans les sections précédentes, une élévation de privilèges pourrait être facilitée.
Les autorisations notables applicables aux modèles de certificats comprennent :
Propriétaire : Accorde un contrôle implicite sur l'objet, permettant la modification de tous les attributs.
Contrôle total : Permet une autorité complète sur l'objet, y compris la capacité de modifier tous les attributs.
Écrire le propriétaire : Autorise la modification du propriétaire de l'objet à un principal sous le contrôle de l'attaquant.
Écrire Dacl : Permet l'ajustement des contrôles d'accès, accordant potentiellement à un attaquant un Contrôle total.
Écrire la propriété : Autorise la modification de toutes les propriétés de l'objet.
Abus
Un exemple d'une élévation de privilèges comme le précédent :
ESC4 est lorsque qu'un utilisateur a des privilèges d'écriture sur un modèle de certificat. Cela peut par exemple être exploité pour écraser la configuration du modèle de certificat afin de le rendre vulnérable à ESC1.
Comme nous pouvons le voir dans le chemin ci-dessus, seul JOHNPC a ces privilèges, mais notre utilisateur JOHN a le nouvel avantage AddKeyCredentialLink vers JOHNPC. Puisque cette technique est liée aux certificats, j'ai également mis en œuvre cette attaque, connue sous le nom de Shadow Credentials. Voici un petit aperçu de la commande shadow auto de Certipy pour récupérer le hachage NT de la victime.
Certipy peut écraser la configuration d'un modèle de certificat avec une seule commande. Par défaut, Certipy va écraser la configuration pour la rendre vulnérable à ESC1. Nous pouvons également spécifier le paramètre -save-old pour sauvegarder l'ancienne configuration, ce qui sera utile pour restaurer la configuration après notre attaque.
Contrôle d'accès aux objets PKI vulnérables - ESC5
Explication
Le vaste réseau de relations interconnectées basées sur les ACL, qui inclut plusieurs objets au-delà des modèles de certificats et de l'autorité de certification, peut impacter la sécurité de l'ensemble du système AD CS. Ces objets, qui peuvent affecter significativement la sécurité, englobent :
L'objet ordinateur AD du serveur CA, qui peut être compromis par des mécanismes comme S4U2Self ou S4U2Proxy.
Le serveur RPC/DCOM du serveur CA.
Tout objet AD descendant ou conteneur dans le chemin de conteneur spécifique
CN=Services de clés publiques,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>. Ce chemin inclut, mais n'est pas limité à, des conteneurs et des objets tels que le conteneur Modèles de certificats, le conteneur Autorités de certification, l'objet NTAuthCertificates et le conteneur Services d'inscription.
La sécurité du système PKI peut être compromise si un attaquant à faibles privilèges parvient à prendre le contrôle de l'un de ces composants critiques.
EDITF_ATTRIBUTESUBJECTALTNAME2 - ESC6
Explication
Le sujet discuté dans le post de CQure Academy aborde également les implications du drapeau EDITF_ATTRIBUTESUBJECTALTNAME2, telles que décrites par Microsoft. Cette configuration, lorsqu'elle est activée sur une Autorité de Certification (CA), permet l'inclusion de valeurs définies par l'utilisateur dans le nom alternatif du sujet pour toute demande, y compris celles construites à partir d'Active Directory®. Par conséquent, cette disposition permet à un intrus de s'inscrire via n'importe quel modèle configuré pour l'authentification de domaine - en particulier ceux ouverts à l'inscription d'utilisateurs non privilégiés, comme le modèle Utilisateur standard. En conséquence, un certificat peut être sécurisé, permettant à l'intrus de s'authentifier en tant qu'administrateur de domaine ou toute autre entité active dans le domaine.
Remarque : L'approche pour ajouter des noms alternatifs dans une Demande de Signature de Certificat (CSR), via l'argument -attrib "SAN:" dans certreq.exe (appelés "Paires Nom-Valeur"), présente un contraste par rapport à la stratégie d'exploitation des SAN dans ESC1. Ici, la distinction réside dans la manière dont les informations de compte sont encapsulées - dans un attribut de certificat, plutôt que dans une extension.
Abus
Pour vérifier si le paramètre est activé, les organisations peuvent utiliser la commande suivante avec certutil.exe:
Cette opération utilise essentiellement l'accès au registre à distance, par conséquent, une approche alternative pourrait être :
Des outils comme Certify et Certipy sont capables de détecter cette mauvaise configuration et de l'exploiter :
Pour modifier ces paramètres, en supposant que l'on possède des droits d'administration de domaine ou équivalents, la commande suivante peut être exécutée à partir de n'importe quelle station de travail :
Pour désactiver cette configuration dans votre environnement, le drapeau peut être supprimé avec :
Après les mises à jour de sécurité de mai 2022, les certificats nouvellement émis contiendront une extension de sécurité qui intègre la propriété objectSid du demandeur. Pour ESC1, ce SID est dérivé du SAN spécifié. Cependant, pour ESC6, le SID reflète l'objectSid du demandeur, et non le SAN.
Pour exploiter ESC6, il est essentiel que le système soit vulnérable à ESC10 (Mappings de certificats faibles), qui donne la priorité au SAN sur la nouvelle extension de sécurité.
Contrôle d'accès vulnérable de l'autorité de certification - ESC7
Attaque 1
Explication
Le contrôle d'accès pour une autorité de certification est maintenu à travers un ensemble d'autorisations qui régissent les actions de la CA. Ces autorisations peuvent être consultées en accédant à certsrv.msc, en cliquant avec le bouton droit sur une CA, en sélectionnant Propriétés, puis en naviguant jusqu'à l'onglet Sécurité. De plus, les autorisations peuvent être énumérées en utilisant le module PSPKI avec des commandes telles que :
Cela fournit des informations sur les droits principaux, à savoir ManageCA et ManageCertificates, qui correspondent aux rôles d'« administrateur de CA » et de « gestionnaire de certificats » respectivement.
Abus
Avoir des droits ManageCA sur une autorité de certification permet au principal de manipuler les paramètres à distance en utilisant PSPKI. Cela inclut le basculement du drapeau EDITF_ATTRIBUTESUBJECTALTNAME2 pour permettre la spécification SAN dans n'importe quel modèle, un aspect critique de l'escalade de domaine.
La simplification de ce processus est réalisable grâce à l'utilisation de la cmdlet Enable-PolicyModuleFlag de PSPKI, permettant des modifications sans interaction GUI directe.
La possession des droits ManageCertificates facilite l'approbation des demandes en attente, contournant efficacement la sauvegarde "approbation du gestionnaire de certificat de CA".
Une combinaison des modules Certify et PSPKI peut être utilisée pour demander, approuver et télécharger un certificat:
Attaque 2
Explication
Dans l'attaque précédente, les autorisations Gérer CA ont été utilisées pour activer le drapeau EDITF_ATTRIBUTESUBJECTALTNAME2 afin d'effectuer l'attaque ESC6, mais cela n'aura aucun effet tant que le service CA (CertSvc) n'est pas redémarré. Lorsqu'un utilisateur a le droit d'accès Gérer CA, l'utilisateur est également autorisé à redémarrer le service. Cependant, cela ne signifie pas que l'utilisateur peut redémarrer le service à distance. De plus, ESC6 pourrait ne pas fonctionner immédiatement dans la plupart des environnements patchés en raison des mises à jour de sécurité de mai 2022.
Par conséquent, une autre attaque est présentée ici.
Prérequis :
Seulement la permission
Gérer CAPermission
Gérer Certificats(peut être accordée depuisGérer CA)Le modèle de certificat
SubCAdoit être activé (peut être activé depuisGérer CA)
La technique repose sur le fait que les utilisateurs ayant le droit d'accès Gérer CA et Gérer Certificats peuvent émettre des demandes de certificat en échec. Le modèle de certificat SubCA est vulnérable à ESC1, mais seuls les administrateurs peuvent s'inscrire dans le modèle. Ainsi, un utilisateur peut demander à s'inscrire dans le SubCA - ce qui sera refusé - mais ensuite émis par le gestionnaire par la suite.
Abus
Vous pouvez vous accorder vous-même la permission Gérer Certificats en ajoutant votre utilisateur en tant que nouvel officier.
Le modèle SubCA peut être activé sur le CA avec le paramètre -enable-template. Par défaut, le modèle SubCA est activé.
Si nous avons rempli les prérequis pour cette attaque, nous pouvons commencer par demander un certificat basé sur le modèle SubCA.
Cette demande sera refusée, mais nous sauvegarderons la clé privée et noterons l'ID de la demande.
Avec notre Gérer CA et Gérer Certificats, nous pouvons ensuite émettre la demande de certificat échouée avec la commande ca et le paramètre -issue-request <ID de demande>.
Et enfin, nous pouvons récupérer le certificat délivré avec la commande req et le paramètre -retrieve <ID de la demande>.
NTLM Relay vers les points de terminaison HTTP AD CS - ESC8
Explication
Dans les environnements où AD CS est installé, s'il existe un point de terminaison d'inscription web vulnérable et qu'au moins un modèle de certificat est publié autorisant l'inscription des ordinateurs de domaine et l'authentification des clients (comme le modèle par défaut Machine), il devient possible pour n'importe quel ordinateur avec le service spouleur actif d'être compromis par un attaquant!
Plusieurs méthodes d'inscription basées sur HTTP sont prises en charge par AD CS, rendues disponibles via des rôles serveur supplémentaires que les administrateurs peuvent installer. Ces interfaces pour l'inscription de certificats basée sur HTTP sont susceptibles aux attaques de relais NTLM. Un attaquant, à partir d'une machine compromise, peut se faire passer pour n'importe quel compte AD qui s'authentifie via NTLM entrant. En se faisant passer pour le compte de la victime, ces interfaces web peuvent être accessibles par un attaquant pour demander un certificat d'authentification client en utilisant les modèles de certificat User ou Machine.
L'interface d'inscription web (une ancienne application ASP disponible à
http://<caserver>/certsrv/), par défaut en HTTP uniquement, ce qui ne protège pas contre les attaques de relais NTLM. De plus, elle autorise explicitement uniquement l'authentification NTLM via son en-tête HTTP Authorization, rendant des méthodes d'authentification plus sécurisées comme Kerberos inapplicables.Le Service d'inscription de certificats (CES), le Service Web de stratégie d'inscription de certificats (CEP) et le Service d'inscription des périphériques réseau (NDES) prennent en charge par défaut l'authentification de négociation via leur en-tête HTTP Authorization. L'authentification de négociation prend en charge à la fois Kerberos et NTLM, permettant à un attaquant de revenir à l'authentification NTLM lors d'attaques de relais. Bien que ces services web activent HTTPS par défaut, HTTPS seul ne protège pas contre les attaques de relais NTLM. La protection contre les attaques de relais NTLM pour les services HTTPS est uniquement possible lorsque HTTPS est combiné avec la liaison de canal. Malheureusement, AD CS n'active pas la Protection étendue pour l'authentification sur IIS, ce qui est nécessaire pour la liaison de canal.
Un problème courant avec les attaques de relais NTLM est la courte durée des sessions NTLM et l'incapacité de l'attaquant à interagir avec des services qui requièrent la signature NTLM.
Cependant, cette limitation est surmontée en exploitant une attaque de relais NTLM pour acquérir un certificat pour l'utilisateur, car la période de validité du certificat dicte la durée de la session, et le certificat peut être utilisé avec des services qui exigent la signature NTLM. Pour des instructions sur l'utilisation d'un certificat volé, consultez :
pageAD CS Account PersistenceUne autre limitation des attaques de relais NTLM est que une machine contrôlée par un attaquant doit être authentifiée par un compte victime. L'attaquant pourrait soit attendre, soit tenter de forcer cette authentification :
pageForce NTLM Privileged AuthenticationAbus
Certify’s cas énumère les points de terminaison HTTP AD CS activés :
La propriété msPKI-Enrollment-Servers est utilisée par les autorités de certification d'entreprise (CAs) pour stocker les points de terminaison du service d'inscription de certificat (CES). Ces points de terminaison peuvent être analysés et répertoriés en utilisant l'outil Certutil.exe:
```powershell Import-Module PSPKI Get-CertificationAuthority | select Name,Enroll* | Format-List * ```
Abus avec Certify
Abus avec Certipy
La demande de certificat est effectuée par Certipy par défaut en fonction du modèle Machine ou User, déterminé par la fin du nom du compte relayé en $. La spécification d'un modèle alternatif peut être réalisée en utilisant le paramètre -template.
Une technique comme PetitPotam peut ensuite être utilisée pour forcer l'authentification. Lorsqu'il s'agit de contrôleurs de domaine, la spécification de -template DomainController est requise.
Aucune extension de sécurité - ESC9
Explication
La nouvelle valeur CT_FLAG_NO_SECURITY_EXTENSION (0x80000) pour msPKI-Enrollment-Flag, appelée ESC9, empêche l'intégration de la nouvelle extension de sécurité szOID_NTDS_CA_SECURITY_EXT dans un certificat. Ce drapeau devient pertinent lorsque StrongCertificateBindingEnforcement est défini sur 1 (paramètre par défaut), ce qui contraste avec un paramètre de 2. Sa pertinence est accrue dans les scénarios où un mappage de certificat plus faible pour Kerberos ou Schannel pourrait être exploité (comme dans ESC10), étant donné que l'absence d'ESC9 ne modifierait pas les exigences.
Les conditions dans lesquelles le réglage de ce drapeau devient significatif incluent :
StrongCertificateBindingEnforcementn'est pas ajusté à2(le paramètre par défaut étant1), ouCertificateMappingMethodsinclut le drapeauUPN.Le certificat est marqué avec le drapeau
CT_FLAG_NO_SECURITY_EXTENSIONdans le réglagemsPKI-Enrollment-Flag.Une EKU d'authentification client est spécifiée par le certificat.
Des autorisations
GenericWritesont disponibles sur n'importe quel compte pour compromettre un autre.
Scénario d'abus
Supposons que John@corp.local détient des autorisations GenericWrite sur Jane@corp.local, dans le but de compromettre Administrator@corp.local. Le modèle de certificat ESC9, pour lequel Jane@corp.local est autorisée à s'inscrire, est configuré avec le drapeau CT_FLAG_NO_SECURITY_EXTENSION dans son réglage msPKI-Enrollment-Flag.
Initialement, le hachage de Jane est acquis en utilisant les informations d'identification Shadow, grâce à GenericWrite de John :
Ensuite, le userPrincipalName de Jane est modifié en Administrateur, en omettant délibérément la partie de domaine @corp.local :
Cette modification ne viole pas les contraintes, étant donné que Administrator@corp.local reste distinct en tant que userPrincipalName de Administrator.
Suite à cela, le modèle de certificat ESC9, marqué comme vulnérable, est demandé en tant que Jane:
Il est noté que le userPrincipalName du certificat reflète Administrator, sans aucun "object SID".
Le userPrincipalName de Jane est ensuite rétabli à son original, Jane@corp.local:
En essayant l'authentification avec le certificat émis, on obtient maintenant le hachage NT de Administrator@corp.local. La commande doit inclure -domain <domain> en raison du manque de spécification de domaine du certificat:
Faibles mappages de certificats - ESC10
Explication
Deux valeurs de clé de registre sur le contrôleur de domaine sont mentionnées par ESC10 :
La valeur par défaut de
CertificateMappingMethodssousHKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannelest0x18(0x8 | 0x10), précédemment définie sur0x1F.Le paramètre par défaut de
StrongCertificateBindingEnforcementsousHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdcest1, précédemment0.
Cas 1
Lorsque StrongCertificateBindingEnforcement est configuré comme 0.
Cas 2
Si CertificateMappingMethods inclut le bit UPN (0x4).
Cas d'abus 1
Avec StrongCertificateBindingEnforcement configuré comme 0, un compte A avec des autorisations GenericWrite peut être exploité pour compromettre n'importe quel compte B.
Par exemple, en ayant des autorisations GenericWrite sur Jane@corp.local, un attaquant vise à compromettre Administrator@corp.local. La procédure reflète ESC9, permettant à n'importe quel modèle de certificat d'être utilisé.
Initialement, le hachage de Jane est récupéré en utilisant les informations d'identification Shadow, exploitant le GenericWrite.
Ensuite, le userPrincipalName de Jane est modifié en Administrateur, en omettant délibérément la partie @corp.local pour éviter une violation de contrainte.
Suivant cela, un certificat permettant l'authentification du client est demandé en tant que Jane, en utilisant le modèle par défaut Utilisateur.
userPrincipalName de Jane est ensuite rétabli à son original, Jane@corp.local.
Authentifier avec le certificat obtenu donnera le hachage NT de Administrator@corp.local, nécessitant la spécification du domaine dans la commande en raison de l'absence de détails de domaine dans le certificat.
Cas d'abus 2
Avec les CertificateMappingMethods contenant le drapeau UPN (0x4), un compte A avec des autorisations GenericWrite peut compromettre n'importe quel compte B ne disposant pas d'une propriété userPrincipalName, y compris les comptes machine et l'administrateur de domaine intégré Administrator.
Ici, l'objectif est de compromettre DC$@corp.local, en commençant par obtenir le hachage de Jane via les informations d'identification Shadow, en exploitant le GenericWrite.
userPrincipalName de Jane est ensuite défini sur DC$@corp.local.
Un certificat d'authentification client est demandé en tant que Jane en utilisant le modèle Utilisateur par défaut.
userPrincipalName de Jane est revenu à son état d'origine après ce processus.
Pour s'authentifier via Schannel, l'option -ldap-shell de Certipy est utilisée, indiquant le succès de l'authentification comme u:CORP\DC$.
À travers le shell LDAP, des commandes telles que set_rbcd permettent d'activer les attaques de délégation contrainte basée sur les ressources (RBCD), compromettant potentiellement le contrôleur de domaine.
Cette vulnérabilité s'étend également à tout compte utilisateur ne disposant pas d'un userPrincipalName ou lorsque celui-ci ne correspond pas au sAMAccountName, le Administrator@corp.local par défaut étant une cible principale en raison de ses privilèges LDAP élevés et de l'absence d'un userPrincipalName par défaut.
Compromission des forêts avec des certificats expliquée à la voix passive
Rupture des confiances inter-forêts par des AC compromis
La configuration de l'inscription inter-forêts est relativement simple. Le certificat de l'AC racine de la forêt de ressources est publié aux forêts de compte par les administrateurs, et les certificats de l'AC d'entreprise de la forêt de ressources sont ajoutés aux conteneurs NTAuthCertificates et AIA dans chaque forêt de compte. Pour clarifier, cet arrangement accorde à l'AC de la forêt de ressources un contrôle complet sur toutes les autres forêts pour lesquelles elle gère la PKI. Si cet AC est compromis par des attaquants, des certificats pour tous les utilisateurs des forêts de ressources et de compte pourraient être contrefaits par eux, rompant ainsi la frontière de sécurité de la forêt.
Privilèges d'inscription accordés à des principaux étrangers
Dans les environnements multi-forêts, il est nécessaire de faire preuve de prudence concernant les AC d'entreprise qui publient des modèles de certificat permettant aux Utilisateurs Authentifiés ou aux principaux étrangers (utilisateurs/groupes externes à la forêt à laquelle l'AC d'entreprise appartient) des droits d'inscription et de modification. Lors de l'authentification à travers une confiance, le SID des Utilisateurs Authentifiés est ajouté au jeton de l'utilisateur par AD. Ainsi, si un domaine possède un AC d'entreprise avec un modèle qui autorise les droits d'inscription des Utilisateurs Authentifiés, un modèle pourrait potentiellement être inscrit par un utilisateur d'une forêt différente. De même, si des droits d'inscription sont explicitement accordés à un principal étranger par un modèle, une relation de contrôle d'accès inter-forêts est ainsi créée, permettant à un principal d'une forêt de s'inscrire à un modèle d'une autre forêt.
Les deux scénarios entraînent une augmentation de la surface d'attaque d'une forêt à une autre. Les paramètres du modèle de certificat pourraient être exploités par un attaquant pour obtenir des privilèges supplémentaires dans un domaine étranger.
Dernière mise à jour
