The Template You Locked Down Doesn't Matter If Someone Can Rewrite It: Understanding and Detecting ESC4Le modèle que vous avez verrouillé ne vaut rien si quelqu'un peut le réécrire : comprendre et détecter ESC4

Votre modèle WebServer est un citoyen modèle. « Fournir dans la demande » est désactivé; l'autorité de certification construit l'objet à partir d'Active Directory. L'approbation du gestionnaire est activée. L'inscription est restreinte à un seul groupe de sécurité comptant trois comptes de service. Vous l'avez révisé lors du dernier balayage ESC1, vous l'avez classé propre, et vous êtes passé à autre chose. Si quelqu'un exécutait la détection ESC1 dessus aujourd'hui, il passerait le test.

À 2 h du matin, un compte de service membre d'un groupe nommé App-Team-CertAdmins ouvre le descripteur de sécurité du modèle. Il possède le Contrôle total sur l'objet. Il bascule le paramètre Nom de l'objet vers « Fournir dans la demande », ajoute Authentification du client à la liste d'EKU, s'accorde l'inscription et efface l'indicateur d'approbation du gestionnaire. Le modèle est maintenant un ESC1 de manuel. Il demande un certificat en nommant Administrator@corp.local dans le SAN, le reçoit, s'authentifie auprès d'un contrôleur de domaine par PKINIT, et obtient un ticket Kerberos pour Administrator.

Puis il remet le modèle en place. Nom de l'objet à « Générer à partir d'Active Directory ». EKU restaurée. ACE d'inscription retirée. Approbation du gestionnaire réactivée. À 2 h 0 min 40 s, le modèle est de nouveau un citoyen modèle.

Si vous exécutez la détection ESC1 à 3 h, elle passe. Elle passait hier, elle passe aujourd'hui, elle passera demain. La configuration n'a jamais été mauvaise plus de quarante secondes, et elle l'a été selon un horaire choisi par l'attaquant. Ce qui était mauvais tout ce temps, ce n'était pas la configuration. C'était qui pouvait la modifier.

Voici ESC4. Il a été publié en 2021 dans la recherche Certified Pre-Owned de Will Schroeder et Lee Christensen chez SpecterOps, et c'est celui qui change votre façon de penser à tout ce qui précède. ESC1, c'est un modèle qui prétend être quelqu'un d'autre. ESC2, c'est un modèle qui peut tout faire. ESC3, c'est un certificat qui vous permet de vous inscrire pour n'importe qui d'autre. ESC4 ne porte pas du tout sur la configuration d'un modèle. Il porte sur l'accès en écriture à l'objet qui contient la configuration. Un attaquant disposant des bonnes permissions sur l'objet modèle n'a pas besoin de trouver un modèle mal configuré. Il en fabrique un, s'en sert, et le remet comme il était.

Cet article s'adresse au défenseur. Il couvre ce qu'est réellement ESC4, pourquoi le correctif d'ESC1 à ESC3 n'y touche pas, pourquoi chacun de vos contrôles de niveau configuration est nul sur un modèle dont la liste de contrôle d'accès est ouverte, et comment trouver et fermer le problème dans votre environnement.

Je présume que vous avez lu les articles ESC1, ESC2 et ESC3. L'outillage de détection, l'expansion des groupes imbriqués, la discipline « ne publier que ce que vous utilisez », le récit de la mise à l'échelle : tout est là et je ne vais pas le réécrire. Là où ESC4 réutilise cette machinerie, je renvoie plutôt que de dupliquer.

Je ne vais pas dérouler l'exploitation. SpecterOps la couvre, Certify et Certipy documentent l'outillage, et Certipy en particulier automatise si proprement le cycle réécrire-utiliser-restaurer que toute l'attaque tient dans une seule commande. Servez-vous-en quand vous devez démontrer l'attaque à votre direction. Servez-vous de ceci quand vous devez la trouver et la corriger.

Ce qu'est réellement ESC4

Chaque chemin ESC jusqu'ici était une propriété de la configuration du modèle : un indicateur de nom, une EKU, une condition d'émission, une EKU d'agent d'inscription. Les détecter, c'était lire des attributs. ESC4 est une propriété de la liste de contrôle d'accès de l'objet modèle, et le détecter, c'est lire la liste de contrôle d'accès et le propriétaire. La configuration du modèle n'a aucune importance pour déterminer s'il est une cible ESC4, parce que tout l'enjeu est que l'attaquant réécrit la configuration.

Un modèle constitue une découverte ESC4 lorsqu'un principal qui ne devrait pas l'avoir détient un droit qui lui permet de modifier l'objet modèle ou son descripteur de sécurité. En pratique, cela veut dire l'un des droits suivants, accordé à un principal peu privilégié directement ou par appartenance à un groupe imbriqué :

Contrôle total (GenericAll). L'ensemble complet. Inclut tout ce qui suit. C'est la découverte ESC4 la plus courante et la plus facile à créer par accident.

Écriture (GenericWrite). L'écriture sur les propriétés de l'objet. Suffisant pour changer l'indicateur de nom, la liste d'EKU, l'indicateur d'inscription et l'exigence de signature RA, ce qui suffit à fabriquer un modèle ESC1, ESC2 ou ESC3.

Écriture DACL (WriteDacl). Le droit de réécrire la liste de contrôle d'accès de l'objet. Un attaquant qui ne détient que WriteDacl s'accorde le Contrôle total et poursuit. Celui-ci est discret, parce que l'onglet Sécurité de base dans certtmpl.msc n'a aucune case à cocher qui dit « peut réécrire ces permissions »; ça vit dans la vue Avancé, et un réviseur pressé ne le voit jamais.

Écriture Propriétaire (WriteOwner). Le droit de devenir vous-même le propriétaire. Le propriétaire de tout objet sécurisable dans Windows peut toujours lire et écrire la DACL, peu importe ce que dit la DACL. WriteOwner est donc un chemin en deux temps vers le Contrôle total : prendre la propriété, puis réécrire la DACL. C'est la découverte la plus discrète de toutes, parce que la propriété n'apparaît nulle part dans l'onglet Sécurité de base et que la plupart des réviseurs ne la vérifient jamais.

Écriture sur des propriétés dangereuses précises (WriteProperty restreint aux bons attributs). Vous n'avez pas besoin d'un accès en écriture à l'objet entier. L'accès en écriture à msPKI-Certificate-Name-Flag seul permet d'activer « Fournir dans la demande ». L'accès en écriture à pKIExtendedKeyUsage ou à msPKI-Certificate-Application-Policy permet d'ajouter Authentification du client ou l'EKU Agent de demande de certificat. L'accès en écriture à nTSecurityDescriptor, c'est WriteDacl sous un autre nom. Une écriture restreinte à n'importe lequel de ces attributs suffit.

Et, distinct de la DACL : le propriétaire de l'objet. Le propriétaire n'est pas une ACE. C'est un champ du descripteur de sécurité, et il porte un WriteDacl et un ReadControl implicites qu'aucune ACE ne peut révoquer. Si un principal peu privilégié possède un objet modèle, ce modèle est ESC4 quelle que soit la propreté de sa liste de contrôle d'accès explicite. Vérifier la DACL et oublier de vérifier le propriétaire est la façon la plus courante pour une révision ESC4 de manquer une découverte réelle.

Dans le laboratoire BrkrOps, nous avons un modèle nommé ESC4 configuré pour paraître parfaitement bénin, avec un descripteur de sécurité qui accorde le Contrôle total à un groupe large. Les captures d'écran ci-dessous y font référence.

Pourquoi l'accès en écriture met en échec tous les contrôles qui le précèdent

Voici ce qui fait d'ESC4 la métavulnérabilité de la série plutôt que la quatrième entrée d'une liste.

Chaque remédiation des articles ESC1, ESC2 et ESC3 était un changement de configuration. Restreindre la permission d'inscription. Activer l'approbation du gestionnaire. Désactiver « Fournir dans la demande ». Exiger une signature autorisée. Retirer Any Purpose. Restreindre les agents d'inscription. Chacun de ces contrôles vit dans un attribut de l'objet modèle, et chacun de ces attributs est modifiable par un principal disposant de GenericWrite ou de GenericAll sur cet objet.

Donc, sur un modèle dont la liste de contrôle d'accès est ouverte :

• Vous l'avez durci contre ESC1 en désactivant « Fournir dans la demande ». L'attaquant le réactive.
• Vous l'avez durci contre ESC1 en restreignant l'inscription à un groupe dédié. L'attaquant ajoute une ACE d'inscription pour lui-même, parce que la permission d'inscription est stockée dans le même nTSecurityDescriptor que WriteDacl lui permet de réécrire.
• Vous l'avez durci contre ESC2 en retirant Any Purpose et en ajoutant des EKU précises. L'attaquant réécrit la liste d'EKU.
• Vous l'avez durci contre ESC1 et ESC2 en exigeant une signature d'agent d'inscription. L'attaquant remet msPKI-RA-Signature à zéro.
• Vous avez activé l'approbation du gestionnaire. L'attaquant efface CT_FLAG_PEND_ALL_REQUESTS.

Les contrôles de configuration sont réels, et ce sont les bons contrôles, contre un attaquant qui ne peut pas changer la configuration. Contre un attaquant qui le peut, ce sont des suggestions. Voilà pourquoi les permissions de modèle sont le contrôle qui sous-tend tous les autres. Un modèle parfaitement durci contre ESC1 mais dont WriteDacl est accordé à Utilisateurs du domaine est plus dangereux qu'un modèle non durci, pas moins, parce que le durcissement est une fiction qui fait passer au modèle chaque vérification de configuration tout en le laissant à une seule commande de l'escalade.

Le corollaire compte pour la façon dont vous priorisez. Quand vous trouvez un modèle qui est à la fois mal configuré (un ESC1 actif) et doté d'une liste de contrôle d'accès ouverte (ESC4), corriger la configuration sans corriger la liste de contrôle d'accès ne ferme rien. L'attaquant réintroduit la mauvaise configuration au moment où vous la retirez. ESC4 doit être corrigé en premier, sinon le correctif ESC1 ne tient pas.

Comment fonctionne l'attaque

La découverte est la même énumération que tout ce qui précède, dirigée vers un attribut différent. Au lieu de lire l'indicateur de nom et la liste d'EKU pour trouver un modèle mal configuré, l'attaquant lit le nTSecurityDescriptor et le propriétaire de chaque objet modèle pour en trouver un dans lequel il peut écrire. N'importe quel utilisateur authentifié peut les lire; l'annuaire les expose pour que les clients d'inscription puissent évaluer leur propre accès. L'attaquant cherche un modèle où un groupe auquel il appartient, ou un principal large bien connu, détient le Contrôle total, l'Écriture, WriteDacl, WriteOwner, une écriture restreinte dangereuse, ou la propriété.

Une fois qu'il en a trouvé un, l'attaque tient en trois étapes.

Réécrire. L'attaquant transforme le modèle dans la forme dont il a besoin. Le choix habituel est la forme ESC1, parce que c'est le chemin le plus court vers une ouverture de session d'administrateur de domaine : activer « Fournir dans la demande », s'assurer qu'une EKU d'authentification du client est présente, s'accorder l'inscription s'il ne l'a pas déjà, effacer l'approbation du gestionnaire. Si WriteDacl ou WriteOwner est le seul droit qu'il détient, le premier geste est de s'en servir pour s'accorder GenericAll, et tout le reste suit.

Utiliser. L'attaquant s'inscrit exactement comme dans ESC1 : demander un certificat au modèle désormais vulnérable, en nommant un compte privilégié dans le SAN, et le recevoir. Rien ne distingue cette inscription d'une légitime, parce que pendant les quarante secondes où le modèle est mal configuré, c'est réellement un modèle ESC1 et la demande est réellement valide contre lui.

Restaurer. L'attaquant remet le modèle dans sa configuration d'origine et, s'il a modifié la DACL ou le propriétaire, les restaure aussi. L'environnement revient à son état précédent. Un instantané de configuration pris avant ou après la fenêtre ne montre rien. Voilà ce qui fait qu'ESC4 échappe à la détection par configuration qui attrape ESC1 à ESC3 : la mauvaise configuration est transitoire et contrôlée par l'attaquant. Le mode ESC4 de Certipy fait la sauvegarde, la modification, la demande et la restauration en une seule opération, précisément pour que la fenêtre de vulnérabilité soit la plus courte possible et que le modèle soit laissé exactement comme il a été trouvé.

Pourquoi le mappage de certificat fort n'est pas votre filet de sécurité ici

Pour ESC1 et ESC2, je pouvais vous dire que le mappage de certificat fort de KB5014754, en mode d'application complet, atténue le gain d'authentification de domaine d'un certificat à SAN arbitraire. La tentation est de présumer que la même chose vaut pour ESC4, parce que la charge utile ESC4 la plus courante a la forme d'ESC1. Ce n'est pas le cas, et s'y fier est une erreur, pour deux raisons.

D'abord, si l'attaquant emprunte le chemin du SAN arbitraire et que votre autorité de certification est corrigée et en mode d'application, le mappage fort rejette bel et bien cette ouverture de session précise, comme il le fait pour ESC1. Mais l'attaquant disposant d'un accès en écriture n'est pas confiné à ce chemin. Il peut plutôt fabriquer une forme ESC2, en ajoutant Any Purpose pour émettre un certificat de signature de code ou de TLS mutuel que le mappage fort ne touche pas, parce que ces capacités ne passent jamais par Kerberos. Il peut fabriquer une forme ESC3, en ajoutant l'EKU Agent de demande de certificat et en s'inscrivant au nom d'un utilisateur privilégié, ce qui produit un certificat portant le vrai SID de la victime, que le mappage fort accepte. Le mappage fort contraint exactement une des formes qu'un attaquant disposant de l'écriture sur le modèle peut librement fabriquer. Quelle que soit la défense que vous avez, il écrit la forme qui la contourne, parce que vous lui avez remis le crayon.

Ensuite, et plus fondamentalement : un modèle de certificat régit l'authentification de domaine. L'accès en écriture à ce modèle, c'est l'accès en écriture à un objet adjacent au niveau zéro. La charge utile précise est presque hors de propos. Un compte qui peut réécrire le descripteur de sécurité d'un modèle détient déjà, en termes de sécurité, un morceau de votre infrastructure de niveau zéro. ESC4 n'est pas un problème de certificat que le mappage fort pourrait masquer. C'est un problème de contrôle d'accès sur un objet critique, et il doit être fermé au niveau de la liste de contrôle d'accès.

Pourquoi chaque étape fonctionne

Il n'y a pas de bogue. Les objets d'annuaire ont des propriétaires et des DACL parce que c'est ainsi qu'Active Directory délègue l'administration. Les modèles de certificat sont des objets d'annuaire, ils ont donc des propriétaires et des DACL comme tout le reste. Un administrateur qui veut permettre à une équipe de gérer son propre modèle accorde à cette équipe un accès en écriture, et l'annuaire l'honore fidèlement. L'autorité de certification émet ce que le modèle permet au moment de la demande, sans aucun souvenir de ce que le modèle permettait une minute plus tôt. Chaque composant fait ce pour quoi il a été conçu. L'exposition tient à l'octroi d'un accès en écriture à un objet modèle à un principal plus large ou moins fiable que le rayon d'impact du modèle, qui est l'authentification de domaine.

La prévention que vous auriez dû avoir

Le nettoyage ci-dessus est plus long que la prévention. Trois principes, et contrairement aux disciplines de configuration des articles précédents, ils portent sur l'objet, pas sur son contenu.

Traitez l'accès en écriture à un modèle comme une délégation de niveau zéro. La capacité de modifier un modèle de certificat, c'est la capacité de modifier la façon dont le domaine authentifie les gens. Elle appartient au même palier qu'Admin du domaine, pas au même palier que « l'équipe applicative gère ses propres affaires ». Écriture, Contrôle total, WriteDacl et WriteOwner sur tout objet modèle ne devraient être détenus que par les administrateurs de l'ICP et les groupes intégrés de niveau zéro (Admins du domaine, Administrateurs de l'entreprise) qui les détiennent déjà par défaut. Si une délégation exige réellement de laisser une équipe demander un certain type de certificat, c'est un octroi d'inscription, pas un octroi d'écriture, et les deux ne sont pas interchangeables.

Assumez la propriété de vos objets modèles délibérément. Le propriétaire de chaque objet modèle devrait être un groupe de niveau zéro, normalement Admins du domaine ou Administrateurs de l'entreprise, ce qui est le défaut. La propriété est invisible dans la console au quotidien, et c'est justement le champ qu'une délégation ou une migration change discrètement. Quand quelqu'un crée un modèle personnalisé, le créateur peut se retrouver propriétaire. Quand un modèle est créé par un compte de service ou un administrateur délégué, ce principal peut se retrouver propriétaire, portant un WriteDacl implicite qu'aucune ACE explicite ne reflète. Remettez la propriété au niveau zéro après toute création de modèle, et auditez-la, parce que c'est le seul champ que votre révision de DACL ne détectera pas.

Surveillez le conteneur, pas seulement les modèles. Les objets modèles de certificat vivent sous CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,<racine de forêt>. Si quelqu'un accorde un accès en écriture sur ce conteneur avec héritage activé, chaque modèle en dessous en hérite, et vous avez ESC4 sur chacun d'eux d'un coup, à partir d'une seule ACE. C'est aussi une découverte ESC5 sur le conteneur lui-même, et c'est la même cause racine portant deux étiquettes : l'octroi au niveau du conteneur est l'ESC5, l'ACE héritée sur chaque modèle est l'ESC4. Réviser les modèles un à un vous montrera un motif suspect d'ACE héritées identiques; le correctif est au conteneur, pas sur chaque modèle.

Pourquoi c'est partout

ESC4 apparaît moins souvent qu'ESC1, mais plus souvent qu'on ne le pense, et presque toujours pour l'une de ces raisons.

La délégation « laissons l'équipe applicative gérer son propre modèle ». Une équipe veut ajuster la période de validité ou la gestion du SAN sur son modèle sans ouvrir un billet chaque fois. Un administrateur accorde à leur groupe le Contrôle total sur l'objet, parce que le Contrôle total est la permission qui fait disparaître la question « peuvent-ils le changer ». Personne n'a présenté ça comme « nous accordons à cette équipe la capacité de s'émettre des certificats d'administrateur de domaine », parce que, depuis la console, ça ressemblait à accorder la capacité de modifier un modèle. Des années plus tard, l'appartenance du groupe a dérivé, le demandeur d'origine est parti, et le groupe se résout en une douzaine de comptes que personne n'a révisés.

Le modèle créé par le mauvais compte. Un modèle personnalisé est créé pendant un projet par un administrateur délégué ou un compte de service, et ce principal devient le propriétaire. La DACL explicite pourrait être parfaitement restreinte. Le propriétaire porte un WriteDacl implicite quoi qu'il arrive. Personne n'a remis le propriétaire au niveau zéro parce que personne n'a regardé le propriétaire.

Le modèle cloné qui a hérité d'une mauvaise DACL. Quelqu'un a dupliqué un modèle existant pour en faire une variante. Le doublon a hérité du descripteur de sécurité du modèle source, y compris toute ACE d'écriture trop large que la source avait accumulée. Maintenant, la découverte existe sur deux objets au lieu d'un, et corriger l'original ne corrige pas la copie.

La DACL de conteneur qui s'est desserrée. Lors d'un projet de délégation, quelqu'un a accordé à un groupe un accès en écriture sur le conteneur Certificate Templates avec héritage, dans l'intention de permettre à ce groupe de créer de nouveaux modèles. L'héritage a fait descendre l'ACE d'écriture sur chaque modèle existant. La capacité voulue était « créer des modèles »; la capacité livrée était « réécrire chaque modèle de la forêt ».

La migration ou l'outil qui a réinitialisé la propriété. Une migration entre autorités de certification, un script de modification de modèles en lot, ou un outil ICP tiers s'est exécuté sous un compte de service et, comme effet secondaire, est devenu le propriétaire des objets qu'il a touchés. Le compte de service est maintenant un WriteDacl permanent sur ces modèles en vertu de la propriété.

Pourquoi personne ne l'attrape : les droits dangereux ne sont pas sur l'onglet que les gens regardent. L'onglet Sécurité de base dans certtmpl.msc montre Lecture, Écriture, Inscription, Inscription automatique et Contrôle total sous forme de cases à cocher, mais un réviseur qui le balaie pour ESC1 regarde la colonne Inscription, pas la colonne Écriture ou Contrôle total, et l'onglet ne montre ni le propriétaire ni la distinction WriteDacl/WriteOwner. Ceux-là sont dans Avancé, que la plupart des révisions n'ouvrent jamais. Et la configuration est propre, alors chaque vérification par configuration passe, ce qui produit une fausse confiance : « on a révisé ce modèle, il est correct ».

Détecter ESC4 dans votre environnement

La détection d'ESC4 pose une question différente d'ESC1 à ESC3. Non pas « comment le modèle est-il configuré », mais « qui peut changer sa configuration ». Vous lisez deux choses sur chaque objet modèle : le propriétaire, et la DACL, à la recherche de droits dangereux détenus par des principaux qui ne devraient pas les avoir. Comme pour l'analyse d'inscription de l'article ESC1, la question de la DACL n'a de réponse réelle qu'après avoir développé les groupes imbriqués, parce qu'un nom de groupe d'apparence bénigne peut se résoudre en Utilisateurs du domaine.

Toutes les commandes ci-dessous sont en lecture seule. Un utilisateur de domaine standard peut lire les propriétaires et les DACL des modèles, ce qui est exactement la raison pour laquelle un attaquant peut énumérer ESC4 sans aucun accès spécial.

certutil pour un modèle connu

certutil -dstemplate déverse la configuration, mais pas le descripteur de sécurité de l'objet sous une forme qui fait ressortir clairement les droits dangereux. Pour la DACL sur un objet modèle précis, dsacls contre le nom unique de l'objet est l'outil intégré qui lit le propriétaire et les permissions :

dsacls "CN=WebServer-Custom,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=local"

La sortie liste le propriétaire en haut, puis chaque ACE. Ce que vous cherchez :

• La ligne Propriétaire. Si elle nomme autre chose qu'un groupe de niveau zéro, c'est une découverte en soi.
• Les ACE accordant FULL CONTROL, WRITE PROPERTY, WRITE PERMISSIONS (WriteDacl) ou WRITE OWNER à tout principal qui n'est pas un administrateur d'ICP ou de niveau zéro. WRITE PERMISSIONS et WRITE OWNER sont les deux qu'un lecteur pressé survole; ce sont les deux qui comptent le plus.

dsacls convient pour vérifier ponctuellement un modèle que vous soupçonnez déjà. Il ne développe pas les groupes imbriqués et il est impraticable sur cent vingt modèles. Pour ça, PowerShell.

Énumération PowerShell à l'échelle de la forêt

Ceci énumère chaque objet modèle, lit son propriétaire et sa DACL, et signale ceux où un droit dangereux est détenu par un principal large bien connu, ou dont le propriétaire est large. Pour les groupes nommés qui ne sont pas des SID bien connus, il fait remonter le principal pour que vous puissiez exécuter l'expansion récursive de l'article ESC1 contre lui. Le test de droits dangereux est l'équivalent ESC4 du test d'inscription d'ESC1 : même problème d'expansion récursive, axé sur les droits d'écriture au lieu du droit étendu d'inscription.

# Trouve les modeles candidats ESC4 dans la foret courante.
# Lit le proprietaire et la DACL de chaque objet modele; signale les droits
# d'ecriture dangereux et les proprietaires larges.
# Natif Server 2022. Lecture seule. Requiert le module ActiveDirectory (RSAT).

Set-StrictMode -Version Latest
$ErrorActionPreference = 'Stop'
Import-Module ActiveDirectory

$configNC      = (Get-ADRootDSE).configurationNamingContext
$templatesPath = "CN=Certificate Templates,CN=Public Key Services,CN=Services,$configNC"

# SID bien connus qui incluent largement des utilisateurs peu privilegies.
$broadSids = @{
    'S-1-1-0'      = 'Everyone'
    'S-1-5-11'     = 'Authenticated Users'
    'S-1-5-7'      = 'Anonymous Logon'
    'S-1-5-32-545' = 'BUILTIN\Users'
    'S-1-5-32-546' = 'BUILTIN\Guests'
}
# RID relatifs au domaine qui sont larges : Domain Users (513), Domain Computers
# (515), Domain Guests (514). Resolus par domaine ci-dessous.
$broadRids = @{ '513' = 'Domain Users'; '514' = 'Domain Guests'; '515' = 'Domain Computers' }
$domainSid = (Get-ADDomain).DomainSID.Value

# Droits dangereux : tout ce qui permet au detenteur de reecrire l'objet ou sa DACL.
$dangerous = [System.DirectoryServices.ActiveDirectoryRights]'GenericAll, GenericWrite, WriteDacl, WriteOwner, WriteProperty'
$emptyGuid = [Guid]::Empty

# Recupere le descripteur de securite avec le proprietaire. L'indicateur owner de
# la SDDL est requis pour que GetOwner() retourne une valeur.
$templates = Get-ADObject -SearchBase $templatesPath `
    -LDAPFilter '(objectClass=pKICertificateTemplate)' `
    -Properties name, displayName, nTSecurityDescriptor

function Test-BroadSid {
    param([string]$Sid)
    if ($broadSids.ContainsKey($Sid)) { return $broadSids[$Sid] }
    if ($Sid -like "$domainSid-*") {
        $rid = $Sid.Substring($domainSid.Length + 1)
        if ($broadRids.ContainsKey($rid)) { return $broadRids[$rid] }
    }
    return $null
}

$findings = New-Object System.Collections.Generic.List[object]

foreach ($t in $templates) {
    $sd = $t.nTSecurityDescriptor

    # 1. Verification du proprietaire. Le proprietaire porte un WriteDacl implicite
    #    quelle que soit la DACL.
    try {
        $ownerSid = $sd.GetOwner([System.Security.Principal.SecurityIdentifier]).Value
        $ownerBroad = Test-BroadSid $ownerSid
        if ($ownerBroad) {
            $findings.Add([PSCustomObject]@{
                Template = $t.name; Principal = $ownerBroad; Right = 'OWNER (WriteDacl implicite)'; Scope = 's.o.'
            })
        } else {
            # Un proprietaire non large vaut quand meme d'etre signale s'il n'est
            # pas un groupe de niveau zero.
            $ownerName = try { $sd.GetOwner([System.Security.Principal.NTAccount]).Value } catch { $ownerSid }
            if ($ownerName -notmatch 'Domain Admins|Enterprise Admins|Administrators$|Admins du domaine|Administrateurs de l.entreprise') {
                $findings.Add([PSCustomObject]@{
                    Template = $t.name; Principal = $ownerName; Right = 'OWNER (a revoir : pas niveau zero)'; Scope = 's.o.'
                })
            }
        }
    } catch {
        Write-Warning "Impossible de lire le proprietaire de $($t.name) : $_"
    }

    # 2. Verification de la DACL. Signale les ACE Allow avec droits dangereux.
    foreach ($ace in $sd.Access) {
        if ($ace.AccessControlType -ne 'Allow') { continue }
        if ((([int]$ace.ActiveDirectoryRights) -band ([int]$dangerous)) -eq 0) { continue }

        # Un WriteProperty restreint a un seul attribut n'est dangereux que pour
        # les attributs de securite; non restreint (ObjectType vide) il les touche tous.
        $isWritePropOnly = (([int]$ace.ActiveDirectoryRights) -band
            ([int][System.DirectoryServices.ActiveDirectoryRights]'GenericAll, GenericWrite, WriteDacl, WriteOwner')) -eq 0
        $scoped = ($ace.ObjectType -ne $emptyGuid)
        if ($isWritePropOnly -and $scoped) {
            $scopeNote = "WriteProperty restreint a $($ace.ObjectType) -- a revoir : dangereux seulement si attribut de securite"
        } else {
            $scopeNote = if ($scoped) { "restreint $($ace.ObjectType)" } else { 'toutes proprietes' }
        }

        $sid = try { ([System.Security.Principal.NTAccount]$ace.IdentityReference).Translate(
            [System.Security.Principal.SecurityIdentifier]).Value } catch { $ace.IdentityReference.Value }
        $broad = Test-BroadSid $sid

        $findings.Add([PSCustomObject]@{
            Template  = $t.name
            Principal = if ($broad) { "*** $broad ***" } else { $ace.IdentityReference.Value }
            Right     = $ace.ActiveDirectoryRights.ToString()
            Scope     = $scopeNote
        })
    }
}

if ($findings.Count) {
    Write-Host "Candidats ESC4 -- droits dangereux ou propriete large sur des objets modeles :" -ForegroundColor Yellow
    $findings | Format-Table -AutoSize -Wrap
    Write-Host ""
    Write-Host "Les entrees marquees *** sont des principaux larges bien connus et sont des decouvertes confirmees."
    Write-Host "Les groupes nommes exigent une expansion recursive (Expand-EnrollPrincipals de"
    Write-Host "l'article ESC1, axee sur l'ACE d'ecriture plutot que sur l'inscription) pour"
    Write-Host "confirmer s'ils se resolvent en comptes peu privilegies."
} else {
    Write-Host "Aucun objet modele de cette foret n'a de droits dangereux detenus par des principaux larges." -ForegroundColor Green
}

Deux choses à savoir sur la sortie. D'abord, un principal marqué *** est un SID large bien connu et constitue une découverte confirmée; un groupe nommé n'est une découverte que si son appartenance transitive inclut des comptes peu privilégiés, ce qui est le problème d'expansion récursive que couvre l'article ESC1 et qui ne devient pas plus facile ici. Ensuite, les entrées WriteProperty restreint à <GUID> exigent un jugement : une écriture restreinte à un attribut bénin comme le nom d'affichage n'est pas de l'ESC4, mais une écriture restreinte à msPKI-Certificate-Name-Flag, pKIExtendedKeyUsage, msPKI-Certificate-Application-Policy, msPKI-Enrollment-Flag, msPKI-RA-Signature ou nTSecurityDescriptor en est. Le script fait remonter le GUID plutôt que de deviner; résolvez-le contre le schéma (Get-ADObject sous CN=Schema,CN=Configuration en filtrant sur schemaIDGUID) si vous devez en avoir le cœur net, et traitez toute écriture restreinte non résolue vers un attribut msPKI-* comme une découverte jusqu'à preuve du contraire.

Vérifiez le conteneur, et vérifiez l'héritage

Exécutez dsacls contre le conteneur Certificate Templates lui-même :

dsacls "CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=local"

Une ACE d'écriture dangereuse ici, avec héritage, est une découverte ESC5 sur le conteneur et un ESC4 de masse sur chaque modèle. Dans la sortie par modèle ci-dessus, une ACE héritée du conteneur apparaît comme le même principal avec le même droit sur plusieurs modèles à la fois; ce motif est le signe révélateur, et le correctif est au conteneur.

Là où la détection manuelle s'effondre

Le même mur de mise à l'échelle multiforêt de l'article ESC1 s'applique, avec une dimension de plus. Pour ESC1, vous développiez les principaux d'inscription. Pour ESC4, vous développez les principaux d'écriture et vous devez aussi lire et raisonner sur la propriété de chaque objet, résoudre les GUID de WriteProperty restreints contre le schéma, et tenir compte des ACE héritées qui prennent leur origine au conteneur ou plus haut. Sur six forêts et deux cent quarante modèles, l'analyse propriétaire plus DACL plus héritage est un travail nettement plus lourd que l'analyse d'inscription, et c'est la même catégorie d'effort d'ingénierie de plusieurs semaines à faire correctement à la main.

Remédier à ESC4

ESC4 se corrige en corrigeant le contrôle d'accès de l'objet, et seulement en corrigeant le contrôle d'accès de l'objet. Aucun changement de configuration ne le ferme, parce que la configuration est justement ce que l'attaquant réécrit. C'est l'image miroir d'ESC1 à ESC3, dont les remédiations étaient toutes de la configuration et aucune de la liste de contrôle d'accès.

Retirez les droits dangereux. Pour chaque modèle où un principal peu privilégié détient le Contrôle total, l'Écriture, WriteDacl, WriteOwner ou une écriture restreinte dangereuse, retirez cette ACE. L'accès en écriture aux objets modèles ne devrait être détenu que par les administrateurs d'ICP et les groupes de niveau zéro qui le détiennent par défaut. Si une équipe a besoin de demander des certificats, accordez l'inscription, pas l'écriture. Si une équipe a réellement besoin de modifier les propriétés non liées à la sécurité d'un modèle, c'est un cas de délégation étroitement restreinte à évaluer au mérite, pas un octroi de Contrôle total, et c'est assez rare pour être l'exception que vous pouvez nommer et justifier.

Corrigez le propriétaire. Réglez le propriétaire de chaque objet modèle à un groupe de niveau zéro, normalement Admins du domaine ou Administrateurs de l'entreprise. C'est l'étape la plus susceptible d'être sautée parce que la propriété est invisible dans la console au quotidien, et c'est l'étape qui ferme le chemin du WriteDacl implicite qu'un nettoyage d'ACE explicites laisse grand ouvert.

# Reinitialise le proprietaire d'un objet modele a Admins du domaine.
$dn = "CN=WebServer-Custom,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=local"
$domAdmins = (Get-ADGroup 'Domain Admins').SID
$obj = [ADSI]"LDAP://$dn"
$obj.PSBase.ObjectSecurity.SetOwner($domAdmins)
$obj.PSBase.CommitChanges()

Corrigez le conteneur et l'héritage. Si la découverte est héritée du conteneur Certificate Templates, corrigez-la là. Retirez l'ACE d'écriture trop large du conteneur, et confirmez que les ACE héritées disparaissent des modèles en dessous. Ça ferme la découverte de masse à sa source plutôt qu'un modèle à la fois.

Activez l'audit pour que le prochain ne soit pas silencieux. Le trait qui définit ESC4 est que l'attaque se restaure elle-même, alors un instantané de configuration ne peut pas l'attraper. Ce qui l'attrape, c'est l'audit de la modification. Ajoutez une SACL aux objets modèles (ou au conteneur, hérité vers le bas) auditant les écritures réussies, et activez la sous-catégorie d'audit des modifications de service d'annuaire sur les contrôleurs de domaine. Alors la réécriture et la restauration génèrent toutes deux des événements, et la fenêtre transitoire qui se cache de la détection par instantané devient pleinement visible dans le journal d'audit. C'est un contrôle de détection, pas de prévention; il n'arrête pas ESC4, il s'assure que si une liste de contrôle d'accès que vous avez manquée est utilisée, vous l'apprenez. Corrigez d'abord les listes de contrôle d'accès, puis auditez en filet de sécurité.

Ne vous arrêtez pas à la configuration. Si un modèle est à la fois un ESC1 actif et un ESC4, corrigez la liste de contrôle d'accès et le propriétaire avant, ou en même temps que, la configuration. Retirer la mauvaise configuration ESC1 tout en laissant l'accès en écriture ouvert n'est pas une remédiation; l'attaquant la réintroduit à la demande. L'ordre n'est pas cosmétique.

Ce que le laboratoire a fini par avoir

Pour le modèle de laboratoire ESC4 :

• L'ACE de Contrôle total d'App-Team-CertAdmins retirée. Le besoin réel de l'équipe était de s'inscrire, alors elle a reçu l'inscription par un groupe dédié et restreint, et rien de plus.
• Propriétaire réinitialisé à Admins du domaine.
• Écriture, WriteDacl et WriteOwner sur l'objet confinés à Admins du domaine, Administrateurs de l'entreprise et le groupe des administrateurs d'ICP.
• Une SACL ajoutée auditant les écritures de propriétés et de DACL réussies, avec l'audit des modifications de service d'annuaire activé sur les contrôleurs de domaine, de sorte que toute modification future du modèle est journalisée.

La configuration du modèle était déjà propre et n'a pas changé. C'est toute la leçon d'ESC4 : la configuration n'a jamais été le problème.

Une configuration réelle : la gestion déléguée de modèles, et où se situe le résidu

La façon la plus nette de voir pourquoi l'accès en écriture est le contrôle qui sous-tend les autres est une délégation qui est légitime, raisonnable, et qui laisse quand même un résidu si vous l'accordez de la façon évidente.

Un grand environnement a une équipe applicative qui possède un modèle de certificat pour son maillage de services interne. Elle a légitimement besoin de l'ajuster : changer la période de validité à mesure que sa politique de rotation évolue, ajuster la construction du SAN à mesure que les services bougent. Ouvrir un billet d'ICP pour chaque changement est une friction réelle, et l'équipe d'ICP ne veut pas être un goulot d'étranglement pour un changement qui ne touche que le modèle de cette équipe. La demande de délégation est donc saine. La question, c'est comment l'accorder.

La façon évidente est le Contrôle total sur l'objet modèle pour le groupe de l'équipe applicative. Ça fonctionne, ça fait disparaître la friction, et c'est ESC4. Le Contrôle total inclut WriteDacl, ce qui veut dire que l'équipe applicative peut s'accorder l'inscription et activer « Fournir dans la demande », ce qui veut dire que tout membre de ce groupe peut s'émettre un certificat d'administrateur de domaine. La délégation voulait dire « gérer la période de validité ». La délégation a livré « escalader jusqu'à administrateur de domaine ». Personne n'a choisi la deuxième chose; elle est venue groupée avec la première.

Passez en revue les options plus sûres. Un WriteProperty restreint aux seuls attributs non liés à la sécurité que l'équipe change réellement est plus proche du bon, mais c'est délicat à exprimer, facile à mal faire, et une inclusion négligente d'un attribut de sécurité rouvre le chemin. La réponse honnête pour la plupart des environnements est que la modification de modèle n'est pas une délégation que vous distribuez du tout. C'est une action de niveau zéro. La friction que ressent l'équipe applicative est réelle, et le bon endroit pour la régler est le processus, une voie rapide pour les demandes de changement de modèle, pas les permissions, un octroi d'écriture permanent sur un objet d'authentification de domaine. Quand une équipe demande un accès en écriture à un modèle, la reformulation est : elle ne veut pas modifier le modèle, elle veut un certificat avec certaines propriétés, et c'est une question de conception d'inscription, pas une question de liste de contrôle d'accès.

Où se situe le résidu, si vous devez déléguer malgré tout : le plus petit octroi qui répond au besoin, sur le moins d'attributs, au plus petit groupe, avec le propriétaire toujours au niveau zéro et l'audit activé. Et même là, le résidu est réel, parce que tout accès en écriture à un modèle est un levier sur l'authentification de domaine, et la personne qui le détient est à l'intérieur de votre frontière de niveau zéro, que l'organigramme le dise ou non.

La réalité à grande échelle

L'article ESC1 couvre la réalité multiforêt, des centaines de modèles, programme continu, et elle tient ici avec un ajout qui rend ESC4 plus difficile à garder fermé que les autres. ESC1 à ESC3 sont des découvertes de configuration, et la configuration est relativement stable; un modèle que vous avez durci tend à rester durci jusqu'à ce que quelqu'un le change délibérément. ESC4 est une découverte de contrôle d'accès, et le contrôle d'accès dérive constamment par le fonctionnement normal de l'annuaire : les appartenances de groupes changent, des délégations s'ajoutent, des modèles sont clonés et héritent de DACL, des migrations réinitialisent des propriétaires, des permissions de conteneur se desserrent pour un projet et ne se resserrent jamais. Une forêt qui est propre d'ESC4 aujourd'hui l'acquiert par l'administration de routine, sans que personne ne touche à un modèle exprès.

Ça fait d'ESC4 la découverte qui a le plus besoin d'une évaluation continue plutôt que ponctuelle. Une révision manuelle trimestrielle des DACL et des propriétaires de modèles sur six forêts, avec expansion récursive des groupes et résolution des GUID de schéma sur chaque écriture restreinte, est exactement le genre d'analyse interobjet, de dérive de permissions, qui ne survit pas au fait d'être faite à la main selon un calendrier. La discipline « ne publier que ce que vous utilisez » aide ici aussi, pour la même raison qu'elle aide partout : moins de modèles publiés veut dire moins d'objets dont vous devez surveiller les DACL et les propriétaires en continu.

Comment Truvald gère ça

Truvald lit le propriétaire et la DACL complète de chaque objet modèle de certificat sur chaque forêt à laquelle il a accès, développe les droits d'écriture et la propriété à travers les groupes imbriqués et les approbations de forêt de la même façon qu'il développe l'inscription pour ESC1, résout les ACE WriteProperty restreintes contre le schéma pour distinguer une écriture d'attribut dangereuse d'une bénigne, et signale les modèles qu'un principal peu privilégié peut réécrire. Il distingue les ACE explicites de celles héritées du conteneur, de sorte qu'une découverte de masse est signalée comme une seule cause racine au conteneur plutôt que cent vingt lignes distinctes à corréler. Il exécute la même analyse pour ESC1, ESC2, ESC3 et ESC5 à ESC16, aux côtés de l'ensemble plus large de vérifications de configuration d'autorité de certification, de listes de contrôle d'accès d'objets ICP et de GPO.

Pour ESC4 en particulier, Truvald signale la découverte que l'outillage par instantané ne peut pas trouver : un modèle configuré proprement en ce moment mais modifiable par quelqu'un qui ne devrait pas pouvoir le modifier, avec le principal précis, le droit précis, l'état de la propriété, et si l'exposition est directe ou héritée. Il signale aussi la combinaison dangereuse dont l'article avertit, un modèle qui passe chaque vérification de configuration tout en portant une liste de contrôle d'accès ouverte, qui est précisément celui qu'une révision par configuration seule classe propre.

La sortie est un rapport d'évaluation écrit. Format Word. Chaque découverte, gravité, modèle précis, droit dangereux ou propriété précis, remédiation recommandée, risque résiduel. Convient à l'équipe technique et au sommaire exécutif que l'équipe technique doit rédiger.

Truvald s'exécute à l'intérieur du réseau du client. Aucun nuage, aucune télémétrie, aucune donnée ne sort. Les configurations de modèles, les listes de contrôle d'accès d'objets et la propriété évaluées comptent parmi les éléments les plus sensibles d'un environnement d'entreprise. Truvald est bâti pour que BrkrOps n'en voie jamais rien.

Évaluation gratuite de 30 jours à truvald.ca. Pour les organisations qui veulent le travail livré comme mandat, avec BrkrOps qui l'exécute dans votre environnement, produit le rapport et accompagne votre équipe dans la feuille de route de remédiation, le forfait Truvald + Évaluation combine la licence à trois jours de consultation.

Références

• Will Schroeder et Lee Christensen. Certified Pre-Owned: Abusing Active Directory Certificate Services. SpecterOps, juin 2021.
• Wiki GhostPack Certify, techniques d'escalade, ESC4.
• Documentation Certipy, attaque de modèle (commande template, sauvegarde et restauration de la configuration vulnérable).
• Microsoft [MS-CRTD] : Certificate Templates Structure. Les définitions d'attributs qu'un attaquant réécrit et qu'un défenseur protège.
• Microsoft [MS-ADTS] : Active Directory Technical Specification (propriété d'objet, WriteDacl/ReadControl implicites pour les propriétaires, et le modèle d'évaluation de DACL).
• Microsoft KB5014754 : Certificate-based authentication changes on Windows domain controllers. Pourquoi le mappage fort contraint une seule forme de charge utile ESC4 et pas les autres.
• Le guide du défenseur ESC1 (article compagnon). Outillage de détection, expansion des groupes imbriqués, mise à l'échelle.
• Le guide du défenseur ESC2 (article compagnon). Ne publier que ce que vous utilisez, l'exigence des signatures autorisées.
• Le guide du défenseur ESC3 (article compagnon). Agents d'inscription, inscription au nom d'autrui, pourquoi un durcissement à un endroit est une exposition à un autre.

À venir dans cette série : ESC5, quand la liste de contrôle d'accès dangereuse n'est pas sur le modèle mais sur les objets autour de lui. L'objet de l'autorité de certification, le compte d'ordinateur AD de l'autorité de certification, les conteneurs Certificate Templates et Enrollment Services, et NTAuthCertificates lui-même. Là où l'accès en écriture aux propres objets d'annuaire de l'ICP donne à un attaquant la capacité d'ajouter une autorité de certification malveillante, de republier un modèle, ou de faire confiance à un certificat qu'il a émis, et pourquoi ESC4 n'était que le coin en forme de modèle d'un problème de contrôle d'accès plus large.

Patrick Mercier écrit Truvald™ pour BrkrOps™ Inc. depuis Edmonton, Alberta. Truvald™ s'exécute entièrement à l'intérieur de votre environnement, aucune télémétrie, aucune composante infonuagique. Une Évaluation gratuite est disponible à truvald.ca/download.

Questions, corrections, ou envie de parler ICP ? admin@brkrops.ca