Comprendre l'importance cruciale de la sécurité de l'ICP

L'infrastructure à clé publique (ICP) est l'épine dorsale invisible de la confiance dans presque toutes les interactions numériques, depuis le cryptage du trafic Web et la signature des versions de logiciels jusqu'à l'authentification des utilisateurs et des appareils via les cartes à puce ou les certificats de sécurité de la couche de transport (TLS). La sécurité d'une entreprise entière dépend de l'intégrité de ses autorités de certification (ACs). Si une seule racine de l'ICP s'effondre, le modèle de confiance s'effondre. Les attaquants peuvent forger des jetons d'authentification, déchiffrer des communications sensibles ou signer un code malveillant avec l'autorité de l'organisation.

Définition des tests de pénétration de l'ICP : au-delà des vérifications de base

Les tests de pénétration de l'ICP sont une discipline de sécurité offensive spécialisée qui vise à évaluer la posture de sécurité de l'ensemble du cycle de vie du certificat. Cela comprend les autorités de certification, les autorités d'enregistrement, le matériel cryptographique (HSM), les modèles de certificat, les mécanismes de révocation et les applications qui reposent sur l'authentification fondée sur le certificat.

La différenciation de la vulnérabilité au balayage

Un scanner de vulnérabilité automatisé peut identifier les correctifs manquants sur un serveur CA ou vérifier les suites de chiffrement faibles. Cependant, un testeur de pénétration qualifié va beaucoup plus loin. Ils examinent la configuration logique des modèles de certificat, testent les permissions d'inscription non sécurisées, analysent la randomité cryptographique, et tentent de chaîner plusieurs erreurs mineures dans une prise en charge complète du domaine.

Pré-engagement : Échelle et règles d'engagement

Avant de commencer un essai technique, il faut établir une portée claire. Les composants de l'ICP sont souvent les systèmes les plus sensibles d'une organisation.

  • Identifiez les CA cibles :[ Déterminer si vous testez une CA interne, une CA publique ou une ICP gérée par un nuage (p. ex., AWS Private CA, Azure Key Vault Integrated CA).Chaque CA possède une surface d'attaque différente.
  • Définition des limites des essais:[ L'équipe d'évaluation peut-elle interagir directement avec l'AC racine, ou est-elle testée uniquement avec les CA subordonnées et les serveurs émetteurs?
  • Active vs. Passive Testing:[ Établir des règles pour les tentatives d'inscription au certificat. L'inscription active contre une CA de production peut remplir la base de données du certificat ou déclencher des alertes de sécurité. Certains tests (comme les attaques de relais ESC8) nécessitent un accès au niveau du réseau et des configurations de protocole spécifiques.
  • Gestion des données: Les clés privées et les certificats CA générés lors des essais doivent être traités avec un soin extrême.

La méthodologie d'essai de pénétration de l'ICP

Une approche méthodique garantit qu'aucun élément n'est négligé. Les phases suivantes représentent un flux de travail standard d'évaluation de la sécurité de l'ICP.

1. Collecte d'informations et reconnaissance

La première étape consiste à cartographier le paysage de l'ICP, ce qui implique d'identifier toutes les AC, les modèles de certificat et les parties qui se fient à l'environnement.

  • AD CS Discovery:[ Dans un environnement Active Directory, des outils comme Certipy[ ou Certify[ peuvent énumérer tous les objets PKI via des requêtes LDAP. Ceci révèle les serveurs CA, les modèles de certificat, les droits d'inscription et les listes de contrôle d'accès (LAC).
  • Certificat Transparence (CT) Logs: Pour les AC faisant face au public, la recherche de registres de CT (par l'intermédiaire d'outils comme ) peut révéler tous les certificats délivrés.
  • Sondes réseau:[ La numérisation des ports ouverts sur les serveurs CA (typiquement TCP 443 pour l'inscription sur le Web ou TCP 445 pour RPC/DCOM) révèle des surfaces d'attaque potentielles pour les attaques par relais (ESC8).

2. Examen de la configuration des autorités de certification

Une fois découverte, la configuration de l'AC elle-même est examinée de près.

  • Contrôles d'accès: Qui a des droits administratifs ou d'inscription sur l'AC? Les entrées trop permises (p. ex., « Utilisateurs principaux » autorisés à s'inscrire dans des modèles sensibles) sont une constatation classique.
  • Politiques de délivrance:[ Vérifiez que les modèles avec l'approbation du gestionnaire ne sont pas valides et que les signatures autorisées ne sont pas requises.
  • Provideur de cryptographie:[ Assurez-vous que l'AC utilise un fournisseur de services cryptographiques (CSP) ou un fournisseur de stockage de clés (KSP) solide et approuvé.

3. La matrice d'attaque CS AD (Vulnérabilités ESC)

La partie la plus critique des tests internes modernes de l'ICP tourne autour des vulnérabilités « ESC » (Escalation of Privilege) documentées en détail par l'équipe de recherche SpecterOps dans leur livre blanc certifié d'occasion ](Lire la recherche originale SpecterOps certifié d'occasion). Ce sont des erreurs de configuration qui permettent aux attaquants de forger des certificats pour des comptes hautement privilégiés.

  • ESC1:[ La mauvaise configuration la plus courante et dangereuse.Cela se produit lorsqu'un modèle de certificat a Les droits d'inscription[ accordés aux utilisateurs à faible revenu, L'approbation du gestionnaire[ est désactivée, Les signatures autorisées[ ne sont pas requises, et le modèle permet de spécifier un Nom alternatif de sujet (SAN) dans la demande.
  • ESC2: Comme ESC1, mais le modèle utilise «Toute fin» (modèle de CA subordonné).Ceci peut être utilisé pour signer des demandes de certificat pour n'importe quel utilisateur, créant ainsi une CA voyou.
  • ESC3:[ Il s'agit de modèles d'agent d'inscription mal configurés. Si un utilisateur a des droits d'agent d'inscription et que la politique de CA permet l'inscription croisée de forêts ou de domaines, un attaquant peut demander des certificats pour le compte de n'importe quel utilisateur.
  • ESC4: Faible ACL sur l'objet du modèle de certificat lui-même. Un attaquant ayant accès par écrit au modèle peut modifier ses descripteurs de sécurité pour introduire des conditions ESC1 ou ESC2, même si le modèle de base est sécurisé.
  • ESC8: Une attaque de relais qui ne nécessite pas de modèle mal configuré. Elle se fonde sur le paramètre d'inscription Web (NDES ou CA Web Proxy) pour relayer l'authentification NTLM. Un attaquant oblige un contrôleur de domaine ou un autre serveur de haute valeur à authentifier à leur relais, qui transmet ensuite le hachage NTLM à l'AC pour enrôler un certificat pour cette machine. Cela peut conduire au compromis de domaine ou serveur.

4. Évaluation de la force cryptographique

L'analyse des algorithmes spécifiques et des pratiques de gestion clés est essentielle pour la sécurité à long terme.

  • Longueur de la clé: Vérifier que les clés CA sont au moins 2048 bits RSA (4096 bits recommandés pour les CA racine). Identifier tout algorithme de hachage SHA-1 ou MD5, qui sont cassés cryptographiquement et vulnérables aux attaques de collision.
  • Hardware Security Modules:[ Évaluer si les clés CA sont stockées dans un HSM. Stocker les clés uniquement dans un logiciel (sur disque) les rend vulnérables à l'exfiltration si le serveur est compromis.
  • Random Number Generation: Des générateurs de nombres aléatoires faibles (RNGs) peuvent conduire à des clés prévisibles. Ceci a été infâmement exploité dans l'incident Debian OpenSSL. Les testeurs peuvent analyser un échantillon de certificats délivrés pour une mauvaise entropie (bien que cela nécessite souvent une analyse statistique de grands échantillons).

5. Man-in-the-Middle (MITM) et le contournement de validation

L'ICP n'est efficace que si les parties qui se fient à la validation des certificats sont bien établies.

  • Certificate Pinning:[ Les applications sont-elles mises en œuvre pour accepter tout certificat signé par une CA de confiance, ou sont-elles pins des clés spécifiques?
  • Revocation Checking:[ Les listes de révocation de certificat (LCR) et le protocole d'état des certificats en ligne (OCSP) sont-elles appliquées? Les demandes mal configurées font souvent l'objet de vérifications de révocation, permettant aux attaquants d'utiliser des certificats volés mais révoqués.
  • Protocole Degrade:[ Un client peut-il être trompé pour accepter un certificat de résistance inférieure ou un protocole hérité? L'essai d'attaques de bandes sur les connexions TLS/SSL peut révéler des vulnérabilités dans les applications d'entreprise.

Outils essentiels pour les évaluations de sécurité de l'ICP

Building a dedicated toolkit for PKI testing enables efficient and thorough assessments.

  • Certipy: Un outil Python moderne conçu explicitement pour l'exploitation et l'audit AD CS. Il automatise la découverte des vulnérabilités ESC1-ESC8 et peut demander des certificats, spécifier les NAS dans les requêtes, et même effectuer la partie relais NTLM d'ESC8.
  • OpenSSL: Le couteau suisse de cryptographie. Utilisé pour inspecter les détails du certificat (), générer des certificats d'essai, vérifier les chaînes et tester les connexions TLS (. Le site officiel du projet OpenSSL offre une documentation exhaustive pour ces commandes ][OpenSSL Documentation].
  • Burg Suite: Essentiel pour tester la logique de validation TLS dans les applications web. Un testeur peut proxy le trafic via Burp et introduire un certificat CA autosigné ou non fiable pour voir si la demande le rejette correctement ou si elle valide correctement la chaîne de certificats.
  • testssl.sh: Un outil inestimable pour évaluer la configuration TLS/SSL de tout service. Il vérifie les suites de chiffrement faibles, la validité du certificat, le support du protocole (TLS 1.2 vs 1.3) et les défauts communs de mise en œuvre.
  • PowerShell (PSPKIAudit/ADCS Audit): Les modules Native PowerShell sont excellents pour l'audit rapide de grands domaines. Le module (fourni par Microsoft ou la galerie PowerShell) peut énumérer tous les modèles et leur configuration.

Analyser les constatations et établir l'ordre de priorité des risques

La présentation de rapports est la phase la plus critique de la mission. Les constatations techniques doivent être traduites en risques opérationnels.

  • Risque critique: La vulnérabilité ESC1 permet des privilèges immédiats d'Admin de domaine. Un attaquant avec un accès standard de l'utilisateur peut devenir un contrôleur de domaine en quelques minutes.
  • Risque élevé:[ Faible stockage cryptographique des clés (clé logicielle seulement) ou des chemins de relais ESC8 qui nécessitent une coordination supplémentaire (coercing authentification) mais qui conduisent toujours au compromis serveur.
  • Risque moyen :[ Manque de vérifications de révocation dans les demandes de clients ou utilisation de signatures basées sur SHA-1 sur des AC internes. Bien que exploitable dans des conditions précises, l'impact immédiat est plus faible.
  • Information: Registres CT exposant les noms d'hôte internes, ou détails de configuration de transparence du certificat.

Chaque constatation doit comprendre une description claire, les étapes techniques nécessaires pour la reproduire, l'incidence potentielle sur les activités et une recommandation d'assainissement prioritaire.

Remédiation et durcissement des pratiques exemplaires

L'identification des faiblesses n'est que la moitié du parcours. La mise en place de contrôles efficaces est essentielle pour la résilience à long terme de l'ICP.

durcissant l'autorité de certification

  • Isolez l'AC: L'AC racine devrait rester hors ligne et être équipée d'un système de contrôle aérien pour une sécurité maximale.
  • Utilisez les modules HSM: Déployez des modules de sécurité matérielle pour toutes les CA de niveau 3+. Cela protège les clés privées de l'exfiltration même si le serveur est compromis.
  • Patch Regularly: Les CA sont des cibles de grande valeur. Assurez-vous que le serveur sous-jacent OS et l'application CA sont corrigés pour les vulnérabilités connues dès que possible.

Sécurisation des modèles de certificat

  • Disable SAN Request for Sensitive Templates:[ Les modèles de comptes à haut niveau de privilèges (Domain Admins, Administrators) doivent exiger explicitement des signatures autorisées et l'approbation du gestionnaire. Le drapeau SAN du schéma doit être défini comme « Ceci est une extension critique » pour empêcher toute modification.
  • Enforcez le schéma Version 2:[ Les modèles de la version 2 fournissent des paramètres de sécurité granulaires, y compris la capacité de restreindre la construction du nom de sujet et nécessitent une signature officielle.
  • Permissions d'inscription restreintes:[ Permet seulement à des groupes de sécurité spécifiques (p. ex., "Helpdesk" pour les certificats d'utilisateur, "Domain Admins" pour les certificats d'administration) de s'inscrire dans des modèles sensibles.

Renforcement du réseau et du protocole

  • Disable NTLM Relay Paths:[ Activer la signature LDAP et la liaison de canal LDAP sur les contrôleurs de domaine pour empêcher les attaques de relais ESC8. Désactiver l'authentification NTLM sur les serveurs CA sauf si cela est absolument nécessaire pour les clients existants.
  • Monitor CRL Points de distribution (CDP) et OCSP Répondeurs :[ S'assurer qu'ils sont très disponibles et correctement configurés. Une défaillance dans la vérification de révocation peut forcer les applications à accepter des certificats invalides.

Conclusion : Vigilance continue de l'ICP

Les évaluations régulières – au moins une fois par année ou après tout changement majeur d'infrastructure, combinées à une surveillance automatisée de la dérive de configuration – constituent la meilleure défense contre les attaques basées sur l'ICP. En adoptant une méthodologie rigoureuse et axée sur l'adversaire et en priorisant le durcissement des services de certificat, les organisations peuvent s'assurer que leur infrastructure de confiance numérique demeure impénétrable. Les directives fondamentales fournies par les organismes de normalisation comme le NIST sur la gestion des clés peuvent servir de feuille de route à long terme pour les opérations sécurisées ](NIST SP 800-57 Recommandation pour la gestion des clés).