AD-CS-Härtung: Fehlkonfigurationen ESC1–ESC8 beheben
Active Directory-Zertifikatdienste gegen die Fehlkonfigurationen ESC1–ESC8 härten: mit Vorlagenkontrollen, EPA und Überwachung der Zertifikatregistrierung.
Die Active Directory-Zertifikatdienste (AD CS) sind Tier-0-Infrastruktur, gleichrangig mit Domänencontrollern, denn ein von der CA ausgestelltes Zertifikat kann sich als jedes Konto authentifizieren, das der Antragsteller angibt — und umgeht damit die Schutzmechanismen der Domänencontroller vollständig. Die von der Sicherheitsforschung dokumentierten Fehlkonfigurationsklassen ESC1 bis ESC8 beschreiben unterschiedliche Wege, auf denen eine zu freizügige CA Zertifikate ausgibt, die sie nicht ausgeben sollte. Dieser Leitfaden behandelt jede Klasse aus Verteidigersicht — wie die Fehlkonfiguration aussieht und wie man sie schließt — sowie Prüfbefehle und die Überwachung, mit der Missbrauchsversuche erkannt werden.
Warum AD CS Tier 0 ist
Die Aufgabe einer CA ist es, eine Identität an einen öffentlichen Schlüssel zu binden. Kann ein Benutzer mit geringen Rechten ein Zertifikat für einen Domänenadministrator anfordern — oder für ein beliebiges Konto mit Client Authentication-EKU —, kann er sich mit diesem Zertifikat per PKINIT als dieses Konto authentifizieren, ohne je dessen Kennwort zu kennen und ohne den Authentifizierungsstack eines Domänencontrollers direkt anzutasten. Der CA-Server selbst und der private Schlüssel des Stamm- oder ausstellenden CA-Zertifikats müssen mit derselben Tiering-Disziplin behandelt werden wie ein Domänencontroller: kein Surfen auf der CA, keine Anmeldungen außer durch PKI-Administratoren, dedizierte gehärtete Verwaltungsarbeitsstationen für die CA-Verwaltung.
Die Klassen ESC1–ESC8 aus Verteidigersicht
Sie werden hier konzeptionell beschrieben — Fehlkonfiguration und Behebung —, nicht als Ausnutzungsschritte.
ESC1: Antragsteller liefert den Antragstellernamen + Client Authentication-EKU
Eine Zertifikatvorlage, die dem Antragsteller erlaubt, einen beliebigen alternativen Antragstellernamen (SAN) anzugeben, kombiniert mit einer EKU, die Client-Authentifizierung zulässt (Client Authentication, Smart Card Logon oder Ähnliches), ermöglicht es jedem registrierungsberechtigten Benutzer, ein Zertifikat anzufordern, das sich als ein anderes Konto ausgibt — auch als privilegiertes.
Behebung: Prüfen Sie jede Vorlage auf das Flag „Enrollee supplies subject“. Entfernen Sie es, sofern kein konkreter, dokumentierter geschäftlicher Bedarf besteht (manche Szenarien der automatischen Registrierung benötigen es legitimerweise — kombinieren Sie diese stattdessen mit streng beschränkten Registrierungsberechtigungen).
# Vorlagen auflisten und "Enrollee supplies subject" kennzeichnen
Get-ADObject -SearchBase (Get-ADRootDSE).ConfigurationNamingContext `
-LDAPFilter "(objectClass=pKICertificateTemplate)" -Properties msPKI-Certificate-Name-Flag, pKIExtendedKeyUsage |
Select-Object Name, msPKI-Certificate-Name-Flag, pKIExtendedKeyUsagemsPKI-Certificate-Name-Flag ist eine Bitmaske: Riskant sind Vorlagen, bei denen Bit 0x1 (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT) gesetzt ist. Gleichen Sie das mit den pKIExtendedKeyUsage-OIDs für Client-Authentifizierung (1.3.6.1.5.5.7.3.2) oder Smartcard-Anmeldung (1.3.6.1.4.1.311.20.2.2) ab.
ESC2: Vorlagen mit Any Purpose oder ohne EKU
Eine Vorlage ohne EKU-Beschränkung oder mit der EKU Any Purpose lässt sich auf dieselbe Weise wie ESC1 missbrauchen, sobald Kontrolle über den Antragstellernamen oder ein anfälliger Registrierungs-Agent hinzukommt. Nehmen Sie Vorlagen mit Any Purpose oder ohne EKU aus der allgemeinen Registrierung heraus; beschränken Sie sie eng oder legen Sie sie still.
ESC3: Anfälliger Registrierungs-Agent
Vorlagen für Registrierungs-Agenten (Enrollment Agent) erlauben dem Inhaber, Zertifikate im Namen anderer Benutzer anzufordern. Eine zu weit gefasste Enrollment-Agent-Vorlage (an eine große Gruppe ausgestellt, ohne Einschränkung, für welche Vorlagen/Benutzer der Agent registrieren darf) wird zu einem Identitätswechsel-Pfad. Beschränken Sie die Ausstellung von Enrollment-Agent-Zertifikaten und kombinieren Sie sie mit den „Certificate Managers Restrictions“ der CA (Einschränkungen pro Agent, pro Vorlage und pro Zielbenutzer).
ESC4: Schwache Zugriffssteuerung auf Vorlagen
Besitzt eine Gruppe mit geringen Rechten Write-/WriteDacl-/WriteOwner-Rechte auf dem AD-Objekt einer sensiblen Vorlage, kann sie diese umschreiben und selbst ESC1-artige Flags einführen. Prüfen Sie die ACLs der Vorlagen, nicht nur deren Einstellungen.
$templates = Get-ADObject -SearchBase (Get-ADRootDSE).ConfigurationNamingContext `
-LDAPFilter "(objectClass=pKICertificateTemplate)"
foreach ($t in $templates) {
(Get-Acl -Path "AD:\$($t.DistinguishedName)").Access |
Where-Object { $_.ActiveDirectoryRights -match "WriteProperty|WriteDacl|WriteOwner|GenericAll" } |
Select-Object @{n='Template';e={$t.Name}}, IdentityReference, ActiveDirectoryRights
}ESC5: Schwache Zugriffssteuerung auf PKI-Objekte
Dasselbe Prinzip wie bei ESC4, angewendet auf das CA-Objekt, das Objekt NTAuthCertificates oder die Container Certificate Templates bzw. den CA-Container selbst. Wer Schreibzugriff auf diese AD-Objekte hat, kann eine bösartige CA zu den vertrauenswürdigen Ausstellern der Gesamtstruktur hinzufügen.
ESC6: EDITF_ATTRIBUTESUBJECTALTNAME2
Dieses CA-weite Flag erlaubt die Angabe eines SAN in der Anforderung für jede Vorlage, unabhängig von deren eigenen Antragsteller-Flags — womit faktisch jede aktivierte Vorlage zu einem ESC1-Risiko wird. Prüfen und entfernen Sie es:
certutil -config "<CAHostName>\<CAName>" -getreg policy\EditFlagsSuchen Sie in der Ausgabe nach EDITF_ATTRIBUTESUBJECTALTNAME2. Entfernen Sie es:
certutil -config "<CAHostName>\<CAName>" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc; net start certsvcESC7: Anfällige Zugriffssteuerung auf die CA
Zu weit gefasste Berechtigungen auf CA-Ebene (Manage CA, Manage Certificates) für Gruppen außerhalb der PKI-Administration erlauben es den Inhabern, ausstehende Anforderungen zu genehmigen oder Einstellungen auf CA-Ebene zu ändern — einschließlich der Ausstellung von Zertifikaten, die sonst abgelehnt würden. Prüfen Sie das mit certutil -getreg CA\Security oder auf der Registerkarte „Sicherheit“ im CA-MMC-Snap-in und beschränken Sie die Rechte ausschließlich auf die PKI-Administratorgruppe.
ESC8: NTLM-Relay auf die CA-Webregistrierung
Der HTTP/HTTPS-Webregistrierungsendpunkt der CA (certsrv oder CES/CEP für die automatische Registrierung) akzeptiert NTLM-Authentifizierung über einen Kanal, der ohne Extended Protection for Authentication (EPA) eine anderswo im Netzwerk erzwungene oder abgefangene NTLM-Authentifizierung per Relay entgegennehmen kann — was ein Zertifikat für die weitergeleitete Identität liefert. Das ist die AD-CS-spezifische Ausprägung des allgemeinen NTLM-Relay-Problems, das in NTLM-Relay stoppen behandelt wird.
Behebung: Erzwingen Sie HTTPS auf allen Webregistrierungsendpunkten und aktivieren Sie Extended Protection for Authentication in IIS für die virtuellen Verzeichnisse CertSrv/CES/CEP. Wird die Webregistrierung nicht aktiv genutzt, deaktivieren Sie den Rollendienst vollständig.
# SSL verlangen und EPA für das virtuelle Verzeichnis CertSrv aktivieren (auf dem CA-/Webregistrierungsserver ausführen).
# Diese Abschnitte sind auf Serverebene gesperrt, daher mit -Location in applicationHost.config schreiben.
Import-Module WebAdministration
$loc = 'Default Web Site/CertSrv'
Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Location $loc `
-Filter 'system.webServer/security/access' -Name sslFlags -Value 'Ssl'
Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Location $loc `
-Filter 'system.webServer/security/authentication/windowsAuthentication' `
-Name 'extendedProtection.tokenChecking' -Value 'Require'Checkliste allgemeiner Abhilfemaßnahmen
| Maßnahme | Vorgehen |
|---|---|
| Genehmigung durch Zertifikatverwaltung | Genehmigung für Vorlagen mit sensiblen EKUs verlangen: auf der Registerkarte „Ausstellungsvoraussetzungen“ der Vorlage „CA certificate manager approval“ aktivieren (setzt CT_FLAG_PEND_ALL_REQUESTS, 0x2, in msPKI-Enrollment-Flag) |
| SAN-Flag | CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT aus Vorlagen entfernen, die es nicht benötigen |
| Registrierungsrechte | Enroll-/AutoEnroll-Berechtigungen auf die kleinstmögliche benötigte Gruppe beschränken; Domänenbenutzer/Authentifizierte Benutzer von sensiblen Vorlagen entfernen, wo vorhanden |
| Webregistrierung | HTTPS + EPA erzwingen oder bei Nichtnutzung deaktivieren |
| Überwachung | CA-Überwachung aktivieren und Protokolle ausgestellter Zertifikate auswerten |
Überwachung und Erkennung
Aktivieren Sie die CA-Überwachung, damit jede Ausstellung, Ablehnung und Vorlagenänderung protokolliert wird:
certutil -setreg CA\AuditFilter 127
auditpol /set /subcategory:"Certification Services" /success:enable /failure:enableWerten Sie im Sicherheitsprotokoll der CA die Ereignis-IDs 4886 (Anforderung übermittelt), 4887 (Zertifikat ausgestellt), 4888 (abgelehnt) und 4899 (Vorlage geändert) aus. Legen Sie pro Vorlage eine Ausgangsbasis der erwarteten Antragsteller fest und alarmieren Sie bei Ausstellungen an unerwartete Konten oder mit unerwarteten SANs:
Get-WinEvent -LogName Security | Where-Object { $_.Id -in 4886,4887,4888,4899 } |
Select-Object TimeCreated, Id, MessageExportieren Sie außerdem regelmäßig die Vorlagenkonfiguration, um Abweichungen zu erkennen:
certutil -v -Template "<TemplateName>" > template-audit.txtWas dabei ausfallen kann
- SAN-Flags entfernen / Registrierung verschärfen: Jeder Arbeitsablauf, der auf Self-Service-Zertifikatanforderungen mit benutzerdefinierten Antragstellern beruht (manche Bereitstellungen von VPN-Clients, Registrierungsskripte für IoT/Geräte), muss auf eine dedizierte, eng begrenzte Vorlage umgestellt werden.
- Genehmigung durch Zertifikatverwaltung: Macht aus der automatischen Registrierung für die betroffenen Vorlagen einen Ablauf mit ausstehenden Anforderungen und verzögert die Ausstellung für Endbenutzer, bis ein Genehmiger handelt — beschränken Sie das auf sensible Vorlagen, nicht auf die gesamte CA.
- EPA auf der Webregistrierung: Legt Clients oder Load Balancer lahm, die TLS vor IIS so terminieren, dass das Channel-Binding-Token verloren geht; prüfen Sie Ihren TLS-Terminierungspfad vor der Aktivierung.
- Webregistrierung deaktivieren: Legt jeden Prozess lahm, der noch von den alten
certsrv-Seiten oder von CES/CEP für die automatische Registrierung über HTTP abhängt — migrieren Sie diese zuerst auf die automatische Registrierung per Gruppenrichtlinie.
Siehe auch Härtung der Domänencontroller und Kerberos-Härtung für angrenzende Tier-0-Maßnahmen sowie ESC1 für einen genaueren Blick auf diese spezielle Fehlkonfigurationsklasse.
Häufige Fragen
Warum gilt AD CS als Tier 0?
Eine kompromittierte Zertifizierungsstelle kann ein Zertifikat ausstellen, mit dem man sich als beliebiger Benutzer authentifiziert, auch als Domänenadministrator, ohne den Domänencontroller direkt anzutasten. Wer ein solches Zertifikat anfordern kann — oder den CA-Server selbst kontrolliert —, hat einen Weg zur vollständigen Domänenkompromittierung, und genau das definiert Tier 0.
Was ist die schnellste Lösung für ESC1?
Prüfen Sie jede Zertifikatvorlage mit Client Authentication- oder Smart Card Logon-EKU auf das Flag „Enrollee supplies subject“ in Kombination mit weit gefassten Registrierungsberechtigungen. Entfernen Sie das Flag oder beschränken Sie die Registrierung auf eine eng umrissene Gruppe — je nachdem, was den legitimen Arbeitsablauf erhält.
Brauche ich Extended Protection for Authentication auf jeder CA?
Ja, auf jeder CA, die HTTP- oder HTTPS-Endpunkte für die Webregistrierung bereitstellt (CES/CEP, die älteren Webregistrierungsseiten). EPA koppelt die NTLM-/Kerberos-Authentifizierung an den TLS-Kanal und schließt damit den bei ESC8 genutzten Relay-Pfad. Wird die Webregistrierung nicht verwendet, deaktivieren Sie sie stattdessen.
AD-CS-Härtung: Fehlkonfigurationen ESC1–ESC8 beheben