Die kritische Bedeutung von PKI Security verstehen

Public Key Infrastructure (PKI) ist das unsichtbare Rückgrat des Vertrauens in fast jeder digitalen Interaktion, von der Verschlüsselung von Web-Datenverkehr und der Unterzeichnung von Software-Releases bis hin zur Authentifizierung von Benutzern und Geräten über Smart Cards oder Transport Layer Security (TLS)-Zertifikate. Die Sicherheit eines ganzen Unternehmens hängt von der Integrität seiner Zertifizierungsstellen ab. Wenn eine einzelne Root-CAs kompromittiert wird, bricht das Vertrauensmodell zusammen. Angreifer können Authentifizierungstokens fälschen, sensible Kommunikation entschlüsseln oder bösartigen Code mit der vollen Autorität des Unternehmens signieren. Angesichts dieser hohen Einsätze ist generisches Schwachstellen-Scannen unzureichend. Umfassende PKI-Penetrationstests sind eine absolute Notwendigkeit für jede sicherheitsbewusste Organisation. Dieser Artikel bietet eine umfassende, prozedurale Anleitung zur Durchführung gründlicher PKI-Sicherheitsbewertungen, um Konfigurationsfehler, kryptographische Schwächen und logische Angriffspfade aufzudecken, die Gegner aktiv ausnutzen.

Definition von PKI Penetration Testing: Über Basic Audits hinaus

PKI Penetration Testing ist eine spezialisierte offensive Sicherheitsdisziplin, die sich auf die Bewertung der Sicherheitslage des gesamten Zertifikatlebenszyklus konzentriert. Dazu gehören die Zertifizierungsstellen, Registrierungsbehörden, kryptographische Hardware (HSMs), Zertifikatsvorlagen, Widerrufsmechanismen und die Anwendungen, die auf zertifikatsbasierter Authentifizierung angewiesen sind. Im Gegensatz zu einer Standard-Compliance-Überprüfung versucht ein Penetrationstest aktiv, Sicherheitskontrollen zu umgehen, Privilegien zu erhöhen und die Auswirkungen auf die reale Welt zu demonstrieren. In modernen Umgebungen, insbesondere in denen, die Microsoft Active Directory Certificate Services (AD CS) nutzen, sind diese Tests zu einem Kernbestandteil jeder umfassenden Active Directory-Sicherheitsbewertung geworden.

Unterschied zum Scannen von Vulnerability

Ein automatisierter Schwachstellenscanner kann fehlende Patches auf einem CA-Server identifizieren oder nach schwachen Chiffriersuiten suchen. Ein erfahrener Penetrationstester geht jedoch noch viel weiter. Sie untersuchen die logische Konfiguration von Zertifikatsvorlagen, testen auf unsichere Registrierungsberechtigungen, analysieren kryptographische Zufälligkeiten und versuchen, mehrere kleinere Fehlkonfigurationen in eine vollständige Domänenübernahme zu verketten. Diese manuelle, logische Analyse ist der Kernwert von dedizierten PKI-Penetrationstests.

Pre-Engagement: Scoping und Regeln des Engagements

Bevor eine technische Prüfung beginnt, muss ein klarer Rahmen festgelegt werden. PKI-Komponenten sind oft die empfindlichsten Systeme in einer Organisation. Tests müssen Gründlichkeit und Betriebsstabilität in Einklang bringen.

  • Identifizieren Sie die Ziel-CAs: Bestimmen Sie, ob Sie eine interne Unternehmens-CA, eine öffentlich zugängliche CA oder eine Cloud-verwaltete PKI (z. B. AWS Private CA, Azure Key Vault Integrated CA) testen.
  • Define Testing Boundaries: Kann das Assessment-Team direkt mit der Root-CA interagieren oder ist das Testen auf untergeordnete CAs und ausstellende Server beschränkt?
  • Aktiv vs. Passive Testing: Legen Sie Regeln für Zertifikatsregistrierungsversuche fest.Aktiv gegen eine Produktions-CA kann die Zertifikatsdatenbank füllen oder Sicherheitswarnungen auslösen. Einige Tests (wie ESC8-Relay-Angriffe) erfordern Zugriff auf Netzwerkebene und spezifische Protokollkonfigurationen.
  • Datenverarbeitung: Private Schlüssel und CA-Zertifikate, die während des Tests generiert werden, müssen mit äußerster Sorgfalt behandelt werden.

Die PKI Penetration Testing Methodology

Ein methodischer Ansatz stellt sicher, dass keine Komponente übersehen wird. Die folgenden Phasen stellen einen Standard-PKI-Sicherheitsbewertungsworkflow dar.

1. Informationssammlung und Aufklärung

Der erste Schritt ist die Kartierung der PKI-Landschaft, bei der alle CAs, Zertifikatsvorlagen und vertrauensvollen Parteien in der Umgebung identifiziert werden.

  • AD CS Discovery: In einer Active Directory-Umgebung können Tools wie Certipy oder Certify alle PKI-Objekte über LDAP-Abfragen aufzählen.
  • Certificate Transparency (CT) Logs: Für CAs mit öffentlichem Blick kann die Suche nach CT-Logs (über Tools wie ) alle ausgestellten Zertifikate offenlegen.
  • Network Probes: Das Scannen nach offenen Ports auf CA-Servern (typischerweise TCP 443 für Web Enrollment oder TCP 445 für RPC/DCOM) zeigt potenzielle Angriffsflächen für Relay-Angriffe (ESC8).

2. Überprüfung der Konfiguration der Zertifizierungsstelle

Einmal entdeckt, wird die Konfiguration der CA selbst überprüft.

  • Zugriffskontrollen: Wer hat administrative oder Registrierungsrechte an der CA? Zu weit gehende Einträge (z. B. "Domain-Benutzer", die sich in sensiblen Vorlagen anmelden dürfen) sind ein klassisches Ergebnis.
  • Ausgaberichtlinien: Überprüfen Sie nach Vorlagen mit deaktivierter Manager-Zulassung und nicht benötigten autorisierten Signaturen.
  • Kryptografischer Anbieter: Stellen Sie sicher, dass die CA einen starken, zugelassenen kryptographischen Dienstleister (CSP) oder Key Storage Provider (KSP) verwendet.

3. Die AD CS Attack Matrix (ESC Vulnerabilities)

Der kritischste Teil des modernen internen PKI-Tests dreht sich um die Sicherheitslücken "ESC" (Escalation of Privilege), die vom SpecterOps-Forschungsteam in seinem Certified Pre-Owned-Whitepaper [Lesen Sie die ursprüngliche SpecterOps Certified Pre-Owned-Forschung] ausführlich dokumentiert wurden.

  • ESC1: Die häufigste und gefährlichste Fehlkonfiguration. Dies tritt auf, wenn eine Zertifikatsvorlage Registrierungsrechte für niedrig privilegierte Benutzer hat, Manager-Genehmigung deaktiviert ist, Authorized Signatures ist nicht erforderlich, und die Vorlage erlaubt die Spezifikation eines Subject Alternative Name (SAN) in der Anforderung. Ein Angreifer kann ein Zertifikat für "Administrator" oder "Domain Controller" anfordern und sich als dieses Konto authentifizieren.
  • ESC2: Ähnlich wie ESC1, aber die Vorlage verwendet "Any Purpose" (untergeordnete CA-Vorlage).
  • ESC3: Enthält falsch konfigurierte Vorlagen für Registrierungsagenten. Wenn ein Benutzer Rechte für Registrierungsagenten hat und die CA-Richtlinie eine wald- oder domänenübergreifende Registrierung ermöglicht, kann ein Angreifer Zertifikate im Namen eines Benutzers anfordern.
  • ESC4: Schwache ACL auf dem Zertifikatsvorlagenobjekt selbst. Ein Angreifer mit Schreibzugriff auf die Vorlage kann seine Sicherheitsdeskriptoren ändern, um ESC1- oder ESC2-Bedingungen einzuführen, selbst wenn die Basisvorlage sicher ist.
  • ESC8: Ein Relay-Angriff, der keine falsch konfigurierte Vorlage benötigt. Er stützt sich auf den Web Enrollment-Endpunkt (NDES oder CA Web Proxy), um die NTLM-Authentifizierung weiterzuleiten. Ein Angreifer zwingt einen Domänencontroller oder einen anderen hochwertigen Server, sich bei seinem Relay zu authentifizieren, der dann den NTLM-Hash an die CA weiterleitet, um ein Zertifikat für diese Maschine zu registrieren. Dies kann zu einem Domänencontroller oder Server-Kompromittierung führen.

4. Kryptografische Festigkeitsbewertung

Die Analyse der spezifischen Algorithmen und Schlüsselmanagementpraktiken ist für die langfristige Sicherheit von entscheidender Bedeutung.

  • Key Length: Überprüfen Sie, ob CA-Schlüssel mindestens 2048-Bit RSA (4096-Bit für Root-CAs empfohlen) sind. Identifizieren Sie alle anhaltenden SHA-1 oder MD5-Hashing-Algorithmen, die kryptographisch gebrochen und anfällig für Kollisionsangriffe sind.
  • Hardware-Sicherheitsmodule: Beurteilen Sie, ob die CA-Schlüssel in einem HSM gespeichert sind. Das Speichern von Schlüsseln rein in Software (auf Festplatte) macht sie anfällig für Exfiltration, wenn der Server kompromittiert wird. HSMs bieten manipulationsresistente Schlüsselspeicherung und kryptographisches Abladen.
  • ]Zufällige Zahlengenerierung: Schwache Zufallszahlengeneratoren (RNGs) können zu vorhersagbaren Schlüsseln führen. Dies wurde in dem Debian OpenSSL-Vorfall berüchtigt ausgenutzt. Tester können eine Stichprobe von ausgestellten Zertifikaten auf schlechte Entropie analysieren (obwohl dies oft eine statistische Analyse großer Stichproben erfordert).

5. Man-in-the-Middle (MITM) und Validierungs-Bypass

Die PKI ist nur dann wirksam, wenn die Zertifikate von den Vertrauensparteien ordnungsgemäß validiert werden.

  • Certificate Pinning: Werden Anwendungen implementiert, um jedes von einer vertrauenswürdigen CA signierte Zertifikat zu akzeptieren, oder werden bestimmte Schlüssel angehängt?
  • Revocation Checking: Werden Zertifikats-Revocation Lists (CRLs) und Online Certificate Status Protocol (OCSP)-Checks durchgesetzt? Fehlkonfigurierte Anwendungen überspringen häufig die Widerrufsprüfungen vollständig, so dass Angreifer gestohlene, aber widerrufene Zertifikate verwenden können.
  • Protokoll Downgrade: Kann ein Client dazu verleitet werden, ein Zertifikat mit niedrigerer Stärke oder ein Legacy-Protokoll zu akzeptieren? Das Testen auf Strip-Angriffe auf TLS/SSL-Verbindungen kann Schwachstellen in Unternehmensanwendungen aufdecken.

Wesentliche Tools für PKI Security Assessments

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

  • Certipy: Ein modernes Python-Tool, das explizit für die AD CS-Exploitation und Auditierung entwickelt wurde. Es automatisiert die Erkennung von ESC1-ESC8-Schwachstellen und kann Zertifikate anfordern, SANs in Anfragen angeben und sogar den NTLM-Relay-Teil von ESC8 ausführen.
  • OpenSSL: ] Das Schweizer Taschenmesser der Kryptographie. Wird verwendet, um Zertifikatsdetails zu prüfen (), Testzertifikate zu erstellen, Ketten zu verifizieren und TLS-Verbindungen zu testen (). Die offizielle OpenSSL-Projektseite bietet umfangreiche Dokumentationen für diese Befehle [OpenSSL Dokumentation]
  • Burp Suite: Unverzichtbar für das Testen der TLS-Validierungslogik in Webanwendungen. Ein Tester kann den Datenverkehr über Burp proxyn und ein selbstsigniertes oder nicht vertrauenswürdiges CA-Zertifikat einführen, um zu sehen, ob die Anwendung es ordnungsgemäß ablehnt oder ob es die Zertifikatskette korrekt validiert.
  • testsl.sh: Ein unschätzbares Tool zur Beurteilung der TLS/SSL-Konfiguration eines beliebigen Dienstes. Es prüft auf schwache Chiffriersuiten, Gültigkeit des Zertifikats, Protokollunterstützung (TLS 1.2 vs. 1.3) und häufige Implementierungsfehler.
  • PowerShell (PSPKIAudit/ADCS Audit): Native PowerShell Module eignen sich hervorragend für die schnelle Überprüfung großer Domains. Das Modul (von Microsoft oder der PowerShell Gallery bereitgestellt) kann alle Vorlagen und deren Konfiguration aufzählen.

Analyse von Ergebnissen und Priorisierung von Risiken

Die Berichterstattung ist die kritischste Phase des Engagements, technische Erkenntnisse müssen in Geschäftsrisiken umgesetzt werden.

  • Kritisches Risiko: ESC1-Schwachstelle ermöglicht sofortige Domain-Admin-Privilegien. Ein Angreifer mit Standard-Benutzerzugriff kann innerhalb von Minuten zum Domänencontroller werden.
  • Hochrisiko: Schwache kryptographische Schlüsselspeicherung (nur Software-Schlüssel) oder ESC8-Relay-Pfade, die zusätzliche Koordination erfordern (zwangsbasierte Authentifizierung), aber dennoch zu Server-Kompromittierungen führen.
  • Mittelwertrisiko: Fehlende Widerrufsprüfungen in Clientanwendungen oder die Verwendung von SHA-1-basierten Signaturen auf internen CAs. Obwohl sie unter bestimmten Bedingungen ausnutzbar sind, sind die unmittelbaren Auswirkungen geringer.
  • Informational: CT-Protokolle, die interne Hostnamen oder Details zur Zertifikattransparenz-Konfiguration ausstellen.

Jede Feststellung sollte eine klare Beschreibung, die technischen Schritte, die erforderlich sind, um sie zu reproduzieren, die potenziellen geschäftlichen Auswirkungen und eine priorisierte Sanierungsempfehlung enthalten.

Abhilfe und Härten Best Practices

Die Identifizierung von Schwachstellen ist nur die halbe Reise, die Umsetzung wirksamer Kontrollen ist für eine langfristige Widerstandsfähigkeit der PKI unerlässlich.

Abhärtung der Zertifizierungsbehörde

  • Die Root-CA sollte offline bleiben und für maximale Sicherheit ausgeblendet werden. Untergeordnete CAs sollten in einem sicheren Netzwerksegment mit strengen Firewall-Regeln und minimalem administrativen Zugriff platziert werden.
  • Verwenden Sie HSMs: Deploy Hardware Security Modules for all Level 3+ CAs. Dies schützt private Schlüssel vor Exfiltration, selbst wenn der Server kompromittiert ist.
  • Patch Regularly: CAs sind hochwertige Ziele. Stellen Sie sicher, dass das zugrunde liegende Server-Betriebssystem und die CA-Anwendung so schnell wie möglich auf bekannte Schwachstellen gepatcht werden.

Muster für Sicherheitsbescheinigungen

  • SAN Request for Sensitive Templates deaktivieren: Templates für hochprivilegierte Accounts (Domain Admins, Administratoren) sollten ausdrücklich autorisierte Signaturen und Manager-Genehmigung erfordern.
  • Erzwingen Sie Schema Version 2: Version 2-Vorlagen bieten granulare Sicherheitseinstellungen, einschließlich der Möglichkeit, die Erstellung von Subjektnamen einzuschränken und eine offizielle Unterzeichnung zu erfordern.
  • Registrierungsberechtigungen einschränken: Nur bestimmte Sicherheitsgruppen (z.B. "Helpdesk" für Benutzerzertifikate, "Domain Admins" für Admin-Zertifikate) erlauben, sich in sensiblen Vorlagen anzumelden.

Netzwerk- und Protokollhärtung

  • Deaktivieren Sie NTLM-Relay-Pfade: Aktivieren Sie LDAP-Signierung und LDAP-Kanalbindung auf Domänencontrollern, um ESC8-Relay-Angriffe zu verhindern. Deaktivieren Sie die NTLM-Authentifizierung auf CA-Servern, es sei denn, dies ist für Legacy-Clients unbedingt erforderlich.
  • Monitor CRL Distribution Points (CDPs) und OCSP Responders: Stellen Sie sicher, dass diese hochverfügbar und ordnungsgemäß konfiguriert sind.

Fazit: Continuous PKI Vigilance

PKI-Penetrationstests sind keine einmalige Box, um auf Compliance zu überprüfen. Es ist eine kontinuierliche Sicherheitspraxis, die sich neben Bedrohungen und Veränderungen in Ihrer Umgebung entwickeln muss. Wenn Unternehmen in die Cloud migrieren und Zero-Trust-Architekturen übernehmen, erweitert sich die Rolle der PKI und auch die Angriffsoberfläche. Regelmäßig geplante Bewertungen - mindestens jährlich oder nach größeren Infrastrukturänderungen in Kombination mit einer automatisierten Überwachung der Konfigurationsdrift - sind die beste Verteidigung gegen PKI-basierte Angriffe. Durch die Einführung einer strengen, gegnerischen Testmethodik und die Priorisierung der Härtung von Zertifikatsdiensten können Unternehmen sicherstellen, dass ihre digitale Vertrauensinfrastruktur undurchdringlich bleibt. Die grundlegenden Leitlinien von Standardisierungsgremien wie NIST zum Schlüsselmanagement können als langfristiger Fahrplan für sichere Operationen dienen.(NIST SP 800-57 Recommendation for Key Management)