AD CS : lire les scénarios ESC1 à ESC8 sans être expert PKI

Une PKI oubliée, un raccourci vers le domaine

Les services de certificats Active Directory sont souvent installés une fois, pour le Wi-Fi ou le VPN, puis oubliés. Or un certificat qui permet l'authentification client vaut un mot de passe : celui qui obtient un certificat au nom d'un administrateur du domaine peut s'authentifier comme lui. Les travaux publiés en 2021 sous le titre « Certified Pre-Owned » ont classé ces abus en scénarios numérotés ESC1, ESC2… Voici comment les lire sans être spécialiste.

ESC1 : le demandeur choisit l'identité

Le scénario le plus fréquent. Un modèle de certificat réunit quatre conditions : il permet l'authentification client, les utilisateurs du domaine peuvent s'y inscrire, aucune approbation n'est requise, et le demandeur peut fournir lui-même le nom du sujet (option « Fournir dans la demande »). N'importe quel utilisateur peut alors demander un certificat au nom de l'administrateur de son choix.

ESC2 et ESC3 : des usages trop larges

ESC2 concerne les modèles autorisant « tout usage », ou dépourvus de restriction d'usage : le certificat peut alors servir à s'authentifier. ESC3 concerne les modèles d'agent d'inscription, qui permettent de demander des certificats au nom d'autres utilisateurs. Accessibles à trop de monde, ils mènent au même résultat qu'ESC1.

ESC4 et ESC7 : des droits sur la PKI elle-même

ESC4 : un groupe non privilégié dispose de droits d'écriture sur un modèle de certificat. Il peut le reconfigurer pour le rendre vulnérable à ESC1, l'utiliser, puis le remettre en état. ESC7 : des droits de gestion sur l'autorité de certification elle-même (« Gérer l'autorité de certification », « Gérer les certificats ») permettent d'approuver des demandes en attente ou de modifier sa configuration.

ESC6 et ESC8 : la configuration de l'autorité

ESC6 : l'indicateur EDITF_ATTRIBUTESUBJECTALTNAME2 activé sur l'autorité permet d'ajouter un nom alternatif à n'importe quelle demande, et donc de transformer tout modèle d'authentification en ESC1. ESC8 : l'inscription web HTTP de l'autorité accepte l'authentification NTLM ; un attaquant qui force un contrôleur de domaine à s'authentifier vers lui peut relayer cette authentification et obtenir un certificat au nom du contrôleur.

Auditer et corriger

• Inventorier les modèles publiés et, pour chacun : l'usage, les droits d'inscription, l'approbation, l'origine du nom du sujet.
• Retirer l'option « Fournir dans la demande » des modèles d'authentification, ou exiger l'approbation d'un gestionnaire de certificats.
• Réserver les droits d'écriture sur les modèles et les droits de gestion de l'autorité au Tier 0.
• Désactiver l'indicateur EDITF_ATTRIBUTESUBJECTALTNAME2 s'il est présent.
• Protéger l'inscription web : HTTPS avec protection étendue de l'authentification, ou désactivation si elle est inutile.
• Appliquer le mappage fort des certificats, désormais imposé par Microsoft sur les contrôleurs de domaine à jour.

Des outils libres comme Locksmith ou Certify dressent cet inventaire en quelques minutes. L'autorité de certification, elle, doit être traitée pour ce qu'elle est : un actif Tier 0.