Signer des certificats en contournant l'autorité de certification

Dans les discussions sur la sécurité d'une autorité de certification, on entend régulièrement qu'un abus de l'autorité de certification pourrait être endigué par ses paramètres de sécurité.

Il n'est toutefois pas évident à première vue que l'intégrité d'une autorité de certification soit directement liée à son matériel de clé et qu'elle puisse donc être compromise par ce dernier.

Il faut se représenter le logiciel d'autorité de certification comme une sorte de gestion autour du matériel clé. Le logiciel offre par exemple une Interface en ligne pour la demande de certificat s'occupe de l'authentification des demandeurs, de l'exécution automatisée des opérations de signature (délivrance de certificats et de Listes de blocage) et leur enregistrement (Base de données des organismes de certification, Protocole d'audit, Journal des événements).

Or, les opérations de signature ne nécessitent rien d'autre que la clé privée de l'autorité de certification. L'exemple suivant montre comment un attaquant peut, s'il a accès à la clé privée de l'autorité de certification, générer et émettre des certificats sans que le logiciel de l'autorité de certification et ses mécanismes de sécurité ne le sachent.

Avec un tel certificat, ce serait même possible dans le pire des cas, de reprendre la structure globale d'Active Directory sans être détecté.

Les étapes suivantes ne doivent jamais être effectuées dans un environnement de production. La démonstration effectuée ici est la suivante pas Il ne s'agit pas d'un guide sur la manière de pénétrer dans les systèmes informatiques, mais plutôt de mettre en évidence le risque de sécurité afin de pouvoir prendre des contre-mesures.

Pour la démonstration, nous utilisons le PSCertificateEnrollment module PowerShell. Il peut être utilisé via Galerie PowerShell et être ensuite chargés.

Veuillez noter que le module PSCertificateEnrollment n'est pas un outil de piratage, mais un logiciel parfaitement légitime destiné à faciliter l'utilisation d'une infrastructure à clé publique dans l'écosystème Windows. L'attaque illustrée ici serait également possible avec d'autres outils de la même manière. En outre, cet exemple ne concerne pas l'exploitation d'une faille de sécurité dans le produit de l'autorité de certification, mais montre plutôt les liens conceptuels et comment ceux-ci peuvent être utilisés à mauvais escient si la sécurité n'est pas renforcée.

Install-Module -Name PSCertificateEnrollment
Import-Module -Name PSCertificateEnrollment

Pour pouvoir signer le certificat généré, le certificat de l'autorité de certification, y compris la clé privée, est nécessaire.

Dans l'exemple, nous supposons l'un des deux cas suivants :

• L'attaquant est en possession (par exemple en volant l'une des sécurités) d'une copie de la clé privée de l'autorité de certification, car celle-ci n'a pas été protégée par un module de sécurité matériel (HSM). Dans ce cas, l'attaque fonctionne à partir de n'importe quel système Windows.
• L'attaquant s'est procuré des droits système sur l'autorité de certification et effectue l'opération directement sur celle-ci. Dans ce cas, l'attaque fonctionne même si la clé privée a été protégée par un module de sécurité matériel.

Le certificat d'autorité de certification doit d'abord être identifié dans un magasin de certificats local.

Get-ChildItem -Path Cert:\LocalMachine\My

Ensuite, il est lu dans une variable.

$CaCert = Get-ChildItem -Path Cert:\LocalMachine\My\A40E27C70460D0CD0AF7DE4088105869AD90AF60

Il est ensuite possible de générer une demande de certificat qui sera directement signée avec le certificat de l'autorité de certification.

Connaissez-vous TameMyCerts? TameMyCerts est un add-on pour l'autorité de certification Microsoft (Active Directory Certificate Services). Il étend la fonction de l'autorité de certification et permet de Application de la réglementationIl s'agit d'un logiciel de gestion des certificats qui permet d'automatiser l'émission de certificats en toute sécurité. TameMyCerts est unique dans l'écosystème Microsoft, a déjà fait ses preuves dans d'innombrables entreprises du monde entier et est disponible sous une licence libre. Il peut téléchargé via GitHub et être utilisé gratuitement. Une maintenance professionnelle est également proposée.

Dans l'exemple

• le certificat résultant est généré dans le magasin de certificats de l'utilisateur (paramètre par défaut du module).
• le fournisseur de stockage de clés logicielles Microsoft est utilisé (paramètre par défaut du module).
• la clé privée est marquée comme exportable (de sorte qu'elle puisse ensuite être utilisée sur un autre système ou sur un autre ordinateur). peut être importé dans une carte à puce).
• le certificat qui en résulte contient le nom principal de l'utilisateur (UPN) du compte administrateur de l'ensemble de la structure.
• le certificat qui en résulte contient les Extended Key Usages pour l'authentification des clients et la connexion par carte à puce.
• le certificat résultant contient un point de distribution de liste de révocation qui fait référence à une liste de révocation valide de l'autorité de certification (condition préalable pour que le certificat soit accepté par un contrôleur de domaine).
• le certificat qui en résulte contient un numéro de série prédéfini par l'attaquant.

New-CertificateRequest `
-Exportable `
-Upn "administrator@intra.adcslabor.de" `
-EnhancedKeyUsage ClientAuthentication,SmartcardLogon `
-Cdp "http://pki.adcslabor.de/CertData/ADCS Labor Issuing CA 1.crl" `
-SerialNumber "deadbeef1337" `
-SigningCert $CaCert

Après l'exécution de la commande, un certificat correspondant devrait se trouver dans le magasin de certificats de l'utilisateur connecté.

Un coup d'œil dans les propriétés du certificat montre que le numéro de série indiqué a été repris. Cela doit montrer que l'attaquant a un contrôle complet sur le contenu du certificat - y compris sur le numéro de série. Il est donc pratiquement impossible de bloquer un tel certificat, car le numéro de série n'est généralement pas connu.

Le Subject Alternative Name (SAN) contient le nom d'utilisateur principal du compte d'administrateur. L'attaquant peut y inscrire des identités quelconques.

Le site utilisation étendue de la clé (Extended Key Usage, EKU) contient les entrées nécessaires pour une inscription par carte à puce.

Enfin, on peut constater que le certificat a manifestement été délivré par l'autorité de certification - la Chaîne de certificats peut être fabriqué avec succès.

Comme la clé privée a été directement visée, il n'y aura pas de certificat correspondant dans la base de données de l'autorité de certification. De même, aucun certificat n'a été trouvé sur l'autorité de certification. Événement d'audit est généré.

Si l'attaquant importe un tel certificat dans une carte à puce, il peut s'en servir pour se connecter à la structure globale d'Active Directory avec l'identité contenue dans le certificat, à condition que la Conditions préalables dans l'infrastructure sont remplies. Il reçoit alors les autorisations de l'utilisateur correspondant - dans l'exemple, donc, „Enterprise Administrator“. Une super-GAU pour la sécurité informatique.

Entre-temps, il existe avec kekeo également un outil qui permet de demander directement un Ticket Granting Ticket (TGT) avec un certificat - donc sans carte à puce ni présence dans le réseau local - ce qui rend l'attaque encore plus dangereuse.

Contre-mesures

Les mesures suivantes peuvent aider à atténuer les dangers émanant d'une telle attaque, ou à détecter une telle attaque :

• En général : durcir les systèmes d'exploitation des serveurs et appliquer le modèle administratif en couches.
• Utiliser des modules de sécurité matériels (HSM) pour protéger les clés privées.
• Utiliser la subordination qualifiée pour pouvoir empêcher la formation d'une chaîne de certificats avec des extended key usages non autorisés (voir l'article „Principes de base : limiter l'utilisation de la clé étendue (Extended Key Usage, EKU) dans les certificats d'autorité de certification„). AttentionIci, une clé de registre doit également être activée sur les contrôleurs de domaine afin que les restrictions soient également prises en compte (voir l'article „Les contrôleurs de domaine ne vérifient pas Extended Key Usages lors de la connexion par carte à puce„).
• Configurer les certificats de contrôleur de domaine qui ne permettent pas l'ouverture de session par carte à puce (voir l'article „Modèles de certificats de contrôleur de domaine et inscription par carte à puce„), si celle-ci n'est pas utilisée.
• Supprimer le certificat d'autorité de certification de l'objet NTAuthCertificates dans Active Directory (voir l'article „Modifier l'objet NTAuthCertificates dans Active Directory„).
• Pour les clés logicielles : éviter la virtualisation afin d'empêcher le détournement de la clé privée par des instantanés du système de fichiers et de la mémoire de travail.
• Pour les clés logicielles : Surveiller l'utilisation de la clé privée par des comptes atypiques (voir les détails des événements 5058 et 5059).
• Configurer le „bon“ déterministe pour les répondeurs en ligne (voir l'article „Configurer le "bon" déterministe pour le répondeur en ligne (OCSP)„) et forcer les contrôleurs de domaine à les utiliser (voir l'article „forcer les contrôleurs de domaine (ou autres participants) à utiliser un répondeur en ligne (OCSP)„). Évaluation des événements d'audit (événement 5125) et surveillance des réponses „inconnues“ et des numéros de série atypiques (voir l'article „Comment est formé le numéro de série d'un certificat ?„).

Liens complémentaires :

• Vecteur d'attaque sur le service d'annuaire Active Directory via le mécanisme de connexion par carte à puce
• Mise en danger de la structure globale d'Active Directory par le drapeau EDITF_ATTRIBUTESUBJECTALTNAME2