03.02.2022 16:00

Special Report: Die Tücken von Active Directory Certificate Services (AD CS)

04. Februar 2022

Dokumenthistorie

Version	Datum	Beschreibung
1.0	04.02.2022 16:00	Initiale Fassung

TL;DR:

Active Directory Certificate Services (ADCS) ist anfällig für Fehlkonfigurationen, mit denen eine komplette Kompromittierung des Netzes trivial möglich ist.
Publiziert wurde das Problem im Sommer 2021, jetzt wird diese Methode bei APT-Angriffen benutzt.
Kontrollieren Sie mit den bereitgestellten Tools ihr Setup.
Stellen Sie mit den angeführten Präventiv-Maßnahmen höhere Sichtbarkeit her.
Überprüfen Sie mit den vorgestellen Tools, ob eine Fehlkonfiguration bereits ausgenutzt wurde.

Um einen schnellen Überblick über potenzielle verwundbare Konfigurationen zu bekommen, können Sie das PSPKI-Audit Tool nutzen.

Einführung

Active Directory Certificate Services (AD CS) heißt die Public Key Infrastructure (PKI) Implementierung von Microsoft für Active Directory (AD). Als solches, ist dieses eine zentrale Komponente in AD Umgebungen. Für ein Höchstmaß an Flexibilität und Sicherheit, setzt AD CS auf ein sehr umfangreiches Set an Konfigurationsmöglichkeiten. Die dadurch bedingte Komplexität kann sich bei unvorteilhaften Konfigurationen im Worst-Case jedoch soweit auswirken, dass einem sich bereits lokal befindlichen Angreifer Persistenz, Rechte-Eskalation und damit einhergehendes Lateral Movement, erheblich erleichtert wird.

Mitte 2021 wurden auf der Black Hat Sicherheitskonferenz diverse derartige Fehlkonfigurationen und darauf basierende Angriffe auf AD CS vorgestellt.

Dringlichkeit!

Schon damals wurde von den Sicherheitsforschern die Vermutung aufgestellt, dass aufgrund erwähnter Komplexität, das Potential an fehlkonfigurierten und dementsprechend "verwundbaren" AD CS-Instanzen als äußerst hoch einzustufen sei. In dieser Hinsicht wurden zuletzt Erfahrungswerte und Berichte aus der Pentest Community laut, die diese Vermutungen nun bestätigen. Dieser Angriffsansatz gehörte laut deren Aussage mittlerweile zum fixen Arsenal und sei so gut wie immer erfolgreich.

Darüber hinaus wurden kürzlich auch größere Angriffe evident, die auf die aktive Ausnützung von dieser speziellen Thematik zurückzuführen sind.

Dieses Special

Orientierend an dem originalen Whitepaper der Sicherheitsforscher, soll dieses Special das Wesen und die Relevanz dieser Thematik näher aus Sicht des Verteidigers/Betreibers von AD CS beleuchten, einen Einblick in richtige bzw. nicht verwundbare Konfigurationen darlegen und darüber hinaus auch Herangehensweisen zur Detektion bereits erfolgter Angriffe aufzeigen.

Hintergrund

AD CS lässt sich, abseits von entsprechend notwendigen Protokollen, grundsätzlich als eine Art Container verstehen. Ein Container für Zertifikate, Zertifikatsanfragen, aber auch sogenannte Zertifikatstemplates.

Quelle: https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf

Jedes Zertifikat wird üblicherweise für einen speziellen Zweck eingesetzt - zum Beispiel als Basis für TLS, als Logon Credential oder für Code-Signing. Tatsächlich gibt es eine ganze Liste an derartigen Einsatzzwecken, die nebenbei auch kombiniert werden können. Darüber hinaus gibt es auch noch den generischen Verwendungszweck "any purpose" über den ein solches Zertifikat auf jedwede Art zum Einsatz kommen kann. Wofür ein Zertifikat letzten Endes eingesetzt werden kann, ergibt sich aus dessen Konfiguration, die für sich gesehen recht komplex sein kann. Hier kommen die bereits namentlich erwähnten Zertifikatstemplates (Zertifikatsvorlagen) ins Spiel. Diese fungieren als Blaupausen für die im betreffenden Infrastrukturumfeld klassischerweise benötigten Zertifikate, anhand deren neue Zertifikate abgeleitet werden können.

Die Entstehung eines neuen Zertifikates folgt einem speziellen mehrstufigen Prozess, auch Certificate Enrollment genannt. Kernaspekt dieses Prozesses ist der Certificate Signing Request (CSR), der an die Enterprise CA geschickt wird und alle wichtigen Parameter, darunter auch das zu verwendende Zertifikatstemplate und das Bindungssubjekt (z.B. bei TLS die Domain), enthält. Die CA prüft und verifiziert die Anfrage hinsichtlich Zulässigkeit, erzeugt im positiven Falle das neu zu erstellende Zertifikatsobjekt, signiert es und retourniert es an den Antragsteller.

Quelle: https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf

Je nach Konfiguration des Templates, erlaubt dieses über Subject Alternative Names (SANs) auch die Angabe von alternativen Bindungssubjekten, also Aliases. Dieses Feature findet klassischerweise bei Multi-Domain TLS Zertifikaten Verwendung.

Das eigentliche Problem

Das eigentliche, von den Sicherheitsforschern aufgezeigte Problem, ist keine Verwundbarkeit im klassischen Sinne, sondern vielmehr ungünstige Kombinationen von Konfigurationsparametern in besagten Zertifikatstemplates, aufgrund derer im Worst-Case Zertifikatsanträge sehr freizügig bzw. uneingeschränkt gemacht werden können. Da für den generellen Zertifikatsantrag keine erhöhten Rechte auf Seiten des Antragstellers von Nöten sind, stellt dieses Szenario eine äußerst attraktive Methode für Angreifer dar, an erhöhte Rechte zu gelangen.

Abseits des Rechteeskalationsszenarios haben die Sicherheitsforscher aber auch noch andere Angriffsmöglichkeiten aufgezeigt. In ihrem Whitepaper thematisieren Sie eine Liste an möglichen und praktisch erprobten Angriffsszenarien, die sie mit einem eigens geschaffenen Namensschema in die entsprechenden Kategorien THEFTn (Datendiebstahl), PERSISTn/DPERSISTn (Persistenz) und ESCn (Rechteeskalation) gliedern. Hier eine Gesamtübersicht über das offensive Ausmaß ...

Offensive Technique ID	Description
THEFT1	Exporting certificates and their private keys using Window's Crypto APIs
THEFT2	Extracting user certificates and private keys using DPAPI
THEFT3	Extracting machine certificates and private keys using DPAPI
THEFT4	Theft of existing certificates via file/directory triage
THEFT5	Using the Kerberos PKINIT protocol to retrieve an account's NTLM hash
PERSIST1	Account persistence via requests for new authentication certificates for a user
PERSIST2	Account persistence via requests for new authentication certificates for a computer
PERSIST3	Account persistence via renewal of authentication certificates for a user/computer
ESC1	Domain escalation via No Issuance Requirements + Enrollable Client Authentication/Smart Card Logon OID templates + CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT
ESC2	Domain escalation via No Issuance Requirements + Enrollable Any Purpose EKU orno EKU
ESC3	Domain escalation via No Issuance Requirements + Certificate Request Agent EKU + no enrollment agent restrictions
ESC4	Domain escalation via misconfigured certificate template access control
ESC5	Domain escalation via vulnerable PKI AD Object Access Control
ESC6	Domain escalation via the EDITF_ATTRIBUTESUBJECTALTNAME2 setting on CAs + No Manager Approval + Enrollable Client Authentication/Smart Card Logon OID templates
ESC7	Vulnerable Certificate Authority Access Control
ESC8	NTLM Relay to AD CS HTTP Endpoints
DPERSIST1	Domain persistence via certificate forgery with stolen CA private keys
DPERSIST2	Domain persistence via certificate forgery from maliciously added root/intermediate/NTAuth CA certificates
DPERSIST3	Domain persistence via malicious misconfigurations that can later cause a domain escalation

Was nun?

Da AD CS eine zentrale Komponente in AD-Umgebungen darstellt empfiehlt es sich, diese Server-Rolle entsprechend abzusichern.

Neben der Vielzahl an Angriffsszenarien haben die Sicherheitsforscher auch defensive und detektive Ansätze erarbeitet, auf die in den nächsten Abschnitten eingegangen wird.

Darüber hinaus bieten sich diverse Guides von Microsoft zum Baseline-Hardening von AD CS an:

Detektion

Zur Detektion der Ausnutzung diverser Fehlkonfigurationen in AD CS haben Systemadministratoren, je nach Angriffsklasse, unterschiedliche Indikatoren auf die bewusst geachtet werden sollte.

Zertifikate überwachen

Beispielsweise löst das Generieren eines neues Zertifikats, respektive das Anfordern eines solchen, zwei Events im Windows-Event-Log aus ( Event-ID 4887: AD CS Zertifikatsausstellung, Event-ID 4886: AD CS - CSR empfangen). Diese beiden Events werden aufeinander folgend ausgelöst und enthalten den Hostnamen des anfragenden Systems sowie den Zeitpunkt der Zertifikatserstellung. Zusätzlich lassen sich weitere Informationen direkt auf dem AD CS System, aus der Zertifikatsdatenbank abfragen. Dadurch kann neben dem Prozess-Namen des anfragenden Hosts auch festgestellt werden, ob das angeforderte Zertifikat Subject Alternative Names (SANs) enthielt und welche Zertifikatsvorlage zur Erstellung des Zertifikats genutzt wurde.

Nutzen Sie dazu den Befehl certutil.exe -v -view.

Mithilfe des -restrict-Parameters lässt sich die Suchanfrage zusätzlich einschränken/granular filtern.

Zertifikatsauthentifizerungen überwachen

Schannel und Kerberos stellen zwei Authentifizierungsmechanismen dar, die in AD-Umgebungen in verschiedensten Konfigurationen verfügbar sind. Eine Authentifizierung mithilfe eines Zertifikats löst im Fall einer Kerberos-Authentifizierung im Windows Event-Log die Event-ID 4768 (Kerberos Authentication Ticket requested TGT) aus. Ob eine Fehlkonfiguration ausgenutzt wurde, lässt sich beispielweise durch den Vergleich einer Liste bekannter Seriennummern der Zertifikate ("known goods") mit den im Event-Log enthaltenen Seriennummern feststellen. Auch Schannel-Authentifizerungen lassen sich über den Windows-Log auditieren - sie lösen drei aufeinander folgende Event-IDs aus:

1. 4769 “A Kerberos service ticket was requested”
2. 4648 “A logon was attempted using explicit credentials”
3. 4624 “An account successfully logged on”

CA Backup-Events überwachen

Die beschriebenen Fehlkonfigurationen können unter anderem zum vollständigen Verlust der Integrität der betriebenen CA führen. Dies kann durch CA Backups geschehen, welche ein Angreifer aufgrund bereits durchgeführter Privilege Escalation anstoßen kann. Ein vollständiges CA Backup löst im Windows-Event-Log bei Beginn des Sicherungsprozesses die Event-ID 4876 aus, respektive nach erfolgreicher Fertigstellung die Event-ID 4877. Versucht ein Angreifer lediglich das CA-Zertifikat und den dazugehörigen Private Key zu exportieren, werden diese Events nicht ausgelöst. Da ein Exportieren des CA-Zertifikats und des Private Keys jedoch andere Event-Logs auslösen, lässt sich auch dieser Vorgang überwachen (Event-IDs: 5058 - Key File Operation, 5061 - Cryptographic operation, 5059 - Key migration operation).

Zertifikatsvorlagen überwachen

Ein signifikanter Teil der Probleme in AD CS wird durch Zertifikatsvorlagen ausgelöst, dementsprechend sollten diverse Überwachungsmechanismen für die genutzten Vorlagen gesetzt werden. Beispielsweise können Änderungen einer Vorlage, beziehungsweise Änderungen an deren Berechtigungen, über die Event-IDs 4899 (Vorlage wurde geändert) und 4900 (Cert Permissions wurden geändert) nachvollzogen werden. Dieser Detektionsmechanismus eignet sich jedoch nicht zur Echtzeit-Erkennung, da diese Events nur auf dem jeweils genutzten AD CS Host ausgelöst werden. Eine granularere Überwachung lässt sich mithilfe von System Access Control Lists (SACLs) umsetzen, indem diese auf die genutzten Template-Vorlagen angewendet werden, wodurch bei Veränderungen dieses Objekts die Event-ID 4662 ("Operation on an object was performed") mitgeloggt wird.

DPAPI Detektionen

Die Data Protection API (DPAPI) stellt eine Windows-Komponente dar, welche zum Schutz diverser, meistens kryptographischer, Daten genutzt werden kann. Beim Auslesen solcher Dateien entstehen jedoch Artefakte, welche zur Detektion von missbräuchlicher Nutzung der DPAPI herangezogen werden können. Dies kann entweder über maßgeschneiderte SACLs passieren, oder über die integrierte Audit-Funktionalität.

Köderzertifikate

Eine weitere Möglichkeit, die missbräuchliche Nutzung von Zertifikaten in AD-Umgebungen zu erkennen, besteht im Erstellen eines "Köder-Zertifikats". Hierbei wird ein legitimer Benutzer-Account inklusive eines Authentifizierungs-Zertifikats erstellt, welches anschließend als Köder auf einem Netzwerklaufwerk oder an diversen Systempfaden abgelegt wird. Versucht ein Angreifer dieses Zertifikat zur Authentifizierung zu nutzen, alarmiert eine zusätzlich angelegte SACL über die Nutzung des Zertifikats (vgl. Canary-Tokens).

Konfigurationsänderungen überwachen

Während einige der Detektions-Mechanismen auf der Nutzung diverser Zertifikate oder speziellen Logs aufbauen, empfiehlt es sich ebenfalls Änderungen an der AD CS-Komponente selbst zu überwachen. Die Event-IDs 4890 und 4892 werden genutzt, um Einstellungsänderungen in AD CS zu loggen. Event-ID 4882 protokolliert Modifikationen in AD CS zugehörigen ACLs.

Prävention

Die vorangegangen Abschnitte haben die Detektion und Ausnutzung der beschriebenen Fehlkonfigurationen behandelt. Es lassen sich jedoch auch präventive Maßnahmen setzen, um die Ausnutzung der beschriebenen Fehlkonfigurationen zu verhindern.

Admin-Tiering

Als grundsätzliche Maßnahme empfiehlt es sich, AD CS-Komponenten hinsichtlich ihrer Kritikalität exakt wie Domain Controller in einer AD Umgebung einzustufen. Hierzu zählen auch sogenannte "subordinate" oder Intermediate-CAs. Weitere Details bezüglich Fehlkonfigurationen lassen sich aus dem Whitepaper entnehmen. Die Umsetzung liefert der durch Microsoft bereitgestellte "Tiering-Guide".

Hardening: AD CS

Im vorliegenden Fall wird durch das Fälschen des SANs, im Zuge der Erstellung einer CSR, eine Rechteausweitung erreicht. Ist es für den Betrieb einer Domäne nicht erforderlich, das eigenständige Definieren des SANs zuzulassen, sollte diese Funktionalität deaktiviert werden (ist dies nicht umsetzbar, sollte das "Manager Approval"-Feature aktiviert werden; dadurch müssen erstellte Zertifikate vor der Nutzung dezidiert zugelassen werden). Dies kann entweder durch das präventive Setzen des SANs im Zertifikatstemplate erreicht, oder mithilfe dem EDITF_ATTRIBUTESUBJECTALTNAME2-Flag komponentenübergreifend umgesetzt werden (Anmerkung: Nutzen Sie hierzu das Kommando certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2). Eine weitere Hardening-Maßnahme stellt das Entfernen der "Enroll"-Berechtigungen dar, die benötigt werden, um von AD CS Zertifikate anzufordern.

Zertifikatsvorlagen regelmäßig sichten

Das Auditieren der momentan im Einsatz befindlichen Zertifikatsvorlagen stellt eine simple Maßnahme dar, welche regelmäßig durchgeführt werden sollte. Falls im Zuge des Audits ungenutzte Vorlagen identifiziert werden, sollten diese gelöscht werden. Eine Liste sämtlicher Vorlagen lässt sich mithilfe des Kommandos certutil.exe -TCAInfo [DC=COMPANY,DC=COM] abrufen/erzeugen.

Hardening: Zertifikatsvorlagen

Eine weitere Maßnahme, um eine Ausnutzung diverser Fehlkonfigurationen zu verhindern, befindet sich in den "Write"-Berechtigungen von Zertifikats-Templates. Wer diese Berechtigungen besitzt, kann Änderungen an Vorlagen vornehmen, welche eine Rechteausweitung erlauben. Zusätzlich empfiehlt es sich, den Abschnitt "Controlling Users added SANs" aus der Hardening-Guideline zu AD CS zu beherzigen.

AD-Objekt "NTAuthCertificates"

Über das AD-Objekt NTAuthCertificates wird gesteuert, welche CA-Zertifikate der AD CS-Komponente genutzt werden, um CSRs zu signieren die eine Domain-Authentifzierung ermöglichen. Mithilfe des Kommandos certutil -viewstore "ldap:///CN=NtAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC=?cACertificate?base?objectclass=certificationAuthority" lassen sich die zugeordneten Zertifikate auflisten. Sollte eine Smart-Card oder Zertifikats-basierte Authentifizierung in einer Domäne nicht benötigt werden, können sämtliche Zertifikate aus dem NTAuthCertificates-AD-Objekt entfernt werden (Anmerkung: Führen Sie hierzu das Kommando certutil -viewdelstore "ldap:///CN=NtAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC=?cACertificate?base?objectclass=certificationAuthority" mit erhöhten Rechten aus).

Hardening: Private-Keys

Grundsätzlich empfiehlt es sich, kryptografisches Material durch sogenannte Hardware-Security-Modules (HSM) zu schützen, anstatt auf die DPAPI zurückzugreifen. AD CS stellt zusätzlich die Sicherheitsoption "TPM-Attestation" zur Verfügung, womit die Nutzung von Zertifikaten, welche nicht durch ein HSM gesichert sind, vollständig unterbunden wird.

Strikte Benutzerzuordnung

Die Rechteausweitung mithilfe der Manipulation des SANs entsteht durch die Annahme, dass der SAN einer CSR den UserPrincipalName (UPN) des anfragenden AD-Objekts enthält. AD CS kann jedoch darauf konfiguriert werden, dieses explizite Mapping nicht vorzunehmen. Dazu muss auf jedem DC der Domäne der Registry-Key UseSubjectAltNames=0 (DWORD) im Pfad HKLM\SYSTEM\CurrentControlSet\Services\Kdc gesetzt werden. Die Umsetzung dieser Maßnahme führt jedoch auch dazu, dass eine Authentifizierung via Zertifikat über Kerberos nicht mehr möglich ist (vgl. "Error 75 - KDC_ERR_CLIENT_NAME_MISMATCH"). Parallel dazu lassen sich Zertifikats-Authentifizierungen via Schannel ebenfalls blockieren (Setzen des Registry-Keys CertificateMappingMethods=0x1 oder CertificateMappingMethods=0x2 im Verzeichnis HKLM\CurrentControlSet\Control\SecurityProviders\SCHANNEL).

Hardening: AD CS Http-Endpunkte

Einige der beschriebenen Fehlkonfigurationen lassen sich über die durch AD CS zur Verfügung gestellten HTTP-Endpunkte ausnutzen, welche per Standardeinstellung aktiviert sind. Da diese Endpunkte durch einen IIS-Webserver bereitgestellt werden, lassen sich auch dessen Logs für weitere Analysen heranziehen (standardmäßig zu finden unter C:\inetpub\logs\LogFiles\). Werden diese nicht benötigt, empfiehlt sich das vollständige Deaktivieren der HTTP-Endpunkte (sollte dies nicht umsetzbar sein, kann die Nutzung von HTTPS für AD CS erzwungen werden, wodurch die Verbindung zwischen AD CS und einem System zusätzlich abgesichert werden kann).

Zusätzliche Resourcen

Im Artikel führt CERT.at bewusst lediglich Kommandos an, welche nativ unter Windows verfügbar sind. Die Autoren der Studie verweisen jedoch zusätzlich auf Tools, welche frei auf Github verfügbar sind:

Das PSPKIAudit-Tool kann genutzt werden, um die angeführten Fehlkonfigurationen in eigenen AD-Umgebungen teilweise automatisiert zu testen. Die beiden Tools Certify und ForgeCert setzen auf der offensiven Seite an und ermöglichen das Ausnutzen diverser Fehlkonfigurationen über präparierte Zertifikate und CSRs.

Informationsquelle(n):

Disclaimer

Die hier angeführten Skripte und Lösungen wurden seitens CERT.at getestet. Dennoch liegt die alleinige Verantwortung der Nutzung der hier angeführten Informationen beim Nutzer/Nutzerin. Jegliche Haftung der CERT.at ist explizit ausgeschlossen.

03.02.2022 16:00 Special Report: Die Tücken von Active Directory Certificate Services (AD CS)