Services de certificats AD : Paramètres à risque et leur remédiation

Les services de certificats Active Directory existent depuis longtemps, mais les ressources pour les apprendre ne sont pas excellentes. En conséquence, ils présentent souvent des mauvaises configurations qui sont un vecteur d'attaques croissant. En fait, SpecterOps a publié un whitepaper détaillant un certain nombre de configurations incorrectes et d'attaques potentielles et fournissant des conseils de renforcement. Dans ce blog, je couvre plusieurs des paramètres qui peuvent être mal configurés et comment les repérer, je propose plusieurs options pour renforcer davantage la sécurité, et j'explique comment utiliser un outil gratuit pour vérifier votre environnement.

Contexte

Lorsqu'un certificat basé sur l'authentification est émis pour une identité, le certificat peut être utilisé pour s'authentifier en tant que l'identité définie dans le Nom Alternatif du Sujet (SAN) ; il s'agit généralement d'un UPN ou d'un nom DNS. Le certificat est ensuite utilisé à la place d'un mot de passe pour l'authentification initiale. La référence technique pour cette authentification initiale est RFC4556 si vous souhaitez en savoir plus sur les détails.

Une fois qu'un certificat basé sur l'authentification a été émis, il peut être utilisé pour s'authentifier en tant que sujet jusqu'à ce qu'il soit révoqué ou expiré. Cela contournera les plans de réponse aux incidents qui reposent sur des stratégies telles que la réinitialisation du mot de passe de l'utilisateur pour expulser un attaquant ; l'attaquant peut avoir un accès persistant au compte à moins que les certificats ne soient également révoqués.

Paramètres de modèle à risque

Voici quelques-uns des paramètres de modèle de certificat qui peuvent conduire à des mauvaises configurations.

EKUs basés sur l'authentification

Tout d'abord, recherchez les Utilisations de clés améliorées (EKUs) qui permettent tout type d'authentification au niveau du domaine. Voici une liste succincte :

• Any Purpose (2.5.29.37.0)
• SubCA (Aucun)
• Authentification du client (1.3.6.1.5.5.7.3.2)
• Authentification client PKINIT (1.3.6.1.5.2.3.4)
• Smart Card Logon (1.3.6.1.4.1.311.20.2.2)

La manière la plus simple de trouver manuellement tous vos modèles de certificats qui permettent cela est d'ouvrir le composant logiciel enfichable MMC de l'Autorité de Certification, de se connecter à votre Autorité de Certification, de regarder la section Modèles de Certificat et de parcourir la colonne Objectif Prévu pour repérer l'un de ces EKUs d'authentification. Par exemple, la figure ci-dessous montre que les modèles Ordinateur, Copie de Connexion par Carte à Puce et les deux modèles de Contrôleur de Domaine contiennent au moins un des PKUs.

Après avoir traité les modèles que vous trouvez, assurez-vous de garder à l'esprit qu'il existe également des moyens d'abuser des certificats normaux. Par exemple, la fonction Get-SmartCardCertificate de PoshADCS peut modifier un modèle, demander des certificats pour celui-ci puis rétablir les modifications apportées au modèle.

Drapeau « Enrollee Supplies Subject »

Lorsque le drapeau CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT est présent dans la propriété mspki-certificate-name-flag, le demandeur du certificat peut fournir son propre nom de sujet alternatif dans la demande de signature de certificat. Cela signifie que tout utilisateur autorisé à s'inscrire à un certificat avec ce paramètre peut demander un certificat en tant que n'importe quel utilisateur dans le réseau, y compris un utilisateur privilégié.

Vous pouvez vérifier ce drapeau dans la console de modèle de certificat ; il se trouve sous l'onglet Nom du sujet comme l'option radio « Fournir dans la demande » :

Alternativement, vous pouvez utiliser une commande PowerShell comme la suivante pour obtenir les modèles depuis AD et vérifier si le drapeau est défini dans le certificat :

      Get-ADobject -Filter { ObjectClass -eq "PKIcertificateTemplate" } -SearchBase (Get-ADRootDSE).ConfigurationNamingContext -prop * | Select Name, mspki-certificate-name-flag, @{ Name = "SupplyInRequest" ; Expression = { $_.'mspki-certificate-name-flag' -band 0x00000001 } }
      

Réduire davantage les risques

En plus de corriger les mauvaises configurations de certificats, envisagez d'utiliser les options suivantes pour contrôler l'émission des certificats.

Approbation du gestionnaire de certificats CA ou signatures autorisées

Tout d'abord et probablement le plus important, consultez l'onglet Exigences d'émission sur chaque certificat pour voir s'il nécessite l'approbation du gestionnaire de l'Autorité de Certification (CA) ou d'une ou plusieurs personnes autorisées.

L'activation de l'un ou des deux de ces paramètres peut considérablement réduire les risques en exigeant des vérifications avant que les certificats ne soient délivrés. Si vous hésitez à exiger des signatures autorisées, exigez au moins l'approbation du gestionnaire de certificats de l'autorité de certification ; ainsi, chaque fois qu'un certificat est demandé, il sera envoyé à l'Autorité de Certification pour un examen manuel avant d'être émis.

Autorisations d'inscription

Deuxièmement, examinez les permissions d'inscription dans chaque modèle, qui peuvent être trouvées dans l'onglet Sécurité. De nombreuses mauvaises configurations sont critiques uniquement lorsque des principaux génériques ou de grands groupes ont ces permissions. En particulier, vérifiez pour les Utilisateurs Authentifiés, les Utilisateurs du Domaine et tout grand groupe d'utilisateurs qui ne devraient pas être en mesure de demander des certificats ; si vous les trouvez, envisagez de révoquer leurs permissions Enroll ou AutoEnroll.

Clé de registre EDITF_ATTRIBUTESUBJECTALTNAME2

En dernier lieu, vérifiez le paramètre de registre EDITF_ATTRIBUTESUBJECALTNAME2. Ce paramètre est l'un des plus intéressants : s'il est activé sur l'autorité de certification, alors toute attestation basée sur l'authentification émise (y compris les certificats où le sujet est automatiquement construit à partir d'Active Directory) peut comporter des valeurs définies par l'utilisateur dans le SAN.

Pour vérifier ce paramètre, vous pouvez exécuter cette commande :

      certutil –getreg policyEditFlags
      

Si EDITF_ATTRIBUTESUBJECALTNAME2 figure dans la liste de sortie, vous devriez le supprimer en utilisant cette commande :

      certutil -config "CA CONNECTION STRING" -setreg policyEditFlags - EDITF_ATTRIBUTESUBJECTALTNAME2
      

Des orientations supplémentaires sur ce paramètre peuvent être trouvées ici.

Vérification des paramètres à risque à l'aide de PSPKIAudit

The PSPKIAudit tool can help you audit your PKI infrastructure. To use PSPKIAudit, simply download the tool from GitHub, import the module and run the Invoke-PKIAudit command. This will enumerate the Certificate Authority from Active Directory and then query it for some of the default options.

Ci-dessous se trouvent quelques captures d'écran montrant le résultat de cet outil, qui révèle un certificat mal configuré et des erreurs de configuration sur l'AC. Si PSPKIAudit détecte des erreurs de configuration non mentionnées dans cet article, consultez le document de SpecterOps pour des conseils de remédiation.

Conclusion

Je m'attends à une augmentation du nombre d'attaques sur les services de certificats Active Directory. En fait, une attaque PetitPotam avec ADCS NTLM Relaying a déjà été signalée depuis la publication du document de SpecterOps, et SpecterOps va publier ForgeCert, le Golden Ticket des certificats, à BlackHat 2021. Par conséquent, il est urgent de vérifier les mauvaises configurations dans votre environnement et de les corriger rapidement, puis de répéter le processus régulièrement.

Pour une protection complète, envisagez la solution de sécurité Netwrix Active Directory. Cela vous aidera à :

• Identifiez de manière proactive les lacunes de sécurité grâce à une évaluation des risques approfondie.
• Minimisez les temps d'arrêt coûteux et les perturbations de l'activité.
• Repérez rapidement même les menaces avancées à temps et réagissez promptement.