Nachdem mein Blog leider viel zu lange eingeschlafen war, gibt es jetzt einen unvermuteten aktuellen Anlass, die eben so lange gehegten guten Vorsätze in die Tat umzusetzen und es wieder aufleben zu lassen.
Von den meisten Windows Schwachstellen und monatlichen Cumulative Updates sind die Active Directory Certificate Services (a.k.a. Microsoft PKI) allenfalls indirekt betroffen. Das ist bei dem am 18.07.2021 unter dem Namen "PetitPotam" publizierten Angriff nun anders.
Exkurs in die Weiten der Windows-Landschaft
PetitPotam ist ein Angriff auf eine eigentlich altbekannte Schwachstelle im NTLM-Authentifikationsmechanismus von Windows, der einem Angreifer ggf. die Übernahme der kompletten AD Domäne ermöglichen kann.
Viele Schwachstellen in Windows rühren aus dem -vermeintlichen oder echten- Zwang zur Rückwärtskompatibilität mit bestehenden alten bis uralten Systemen und Anwendungen. Der Rückwärtskompatibilität ist geschuldet, dass eingentlich überholte, längst ersetzte Verfahren und Schnittstellen immer noch nicht nur unterstützt werden, sondern standardmäßig aktiviert sind. So auch das NTLM Authentifikationsverfahren, das, wie der Name namelegt, auf das Windows NT der 90er Jahre zurück geht und für das seit der Einführung des Active Directory (für die jüngeren Leser: mit Windows 2000) mit Kerberos eigentlich ein sichererer Ersatz zur Verfügung steht. Aber anscheinend ist es für Entwickler bis heute manchmal bequemer, statt Kerberos noch noch NTLM zu verwenden.
Bei NTLM sind sogenannte Relay-Angriffe möglich. Wenn ein AD-Benutzer oder AD-Computer sich -beispielsweise über die Integrierte Windows-Authentifikation (IWA) eines Browsers, bei der standardmaßig ausgehandelt wird, ob Kerberos oder NTLM verwendet werden soll- per NTLM an einem System des Angreifers anmeldet, kann der sich hinterrücks, ebenfalls per NTLM, mit dem Konto des Opfers an anderen Systemen anmelden. Das Prinzip ist seit ca. 2001 bekannt und z. B. in OWASP Vortragsfolien aus dem Jahr 2008 oder einem Microsoft Advisory aus dem Jahr 2009 beschrieben.
Zurück zur PKI
PetitPotam kann nun u. a. die Certificate Authority Web Enrollment und Certifcate Enrollment Web Service (CES) Features der AD Certificate Services für einen NTLM-Relay-Angriff ausnutzen.
Update: Zur Klarstellung: den CES kann man in bis zu drei Varianten installieren - mit zertifikatsbasierter Authentifikation, mit Kerbreros-Authentifikation und mit Username/Passwort. Betroffen und nachfolgend stets gemeint ist die Variante mit Kerberos-Authentifikation (die in Wirklichkeit standardmäßig nicht nur Kerberos, sondern alternativ Kerberos oder NTLM unterstützt, leider etwas irreführend bezeichnet).
Dabei ist -zumindest im einfachsten Fall für den Angreifer- das Opfer der Computer-Account eines Domain Controllers und die PKI das System auf das hinterrücks zugegriffen wird. Benjamin Delpy, der Autor des bekannten Analyse-Tools (böse Zungen sagen auch: Hackertools) Mimikatz hat das in einem kurzen Video demonstriert:
- Der Angreifer installiert auf seinem System (das muss kein Windows System sein, im Beispielvideo ist es ein Linux-Rechner) ein NTLM-Relay-Tool, das die NTLM-Credentials der Gegenseite beispielsweise bei Zugriffen per Enrypted File System (EFS) abgreifen kann. Auch dabei wird nämlich IWA mit NTLM-vs.-Kerberos Negotiaton genutzt. (Gesegnet, wer vollständig weiß, wo überall noch.)
- Er versucht, auf ein EFS Share bei einem Domain Controller zuzugreifen. Ob dieser Zugriff erfolgreich ist oder nicht, spielt keine Rolle, solange der Angreifer dabei die NTLM-Credentials des Domain Controllers in die Finger bekommt. (Dass bei einem Zugriffsversuch nicht nur der Client, sondern immer auch der Server sich authentifiziert ist ja gute Praxis. Aber dass der Server bei beliebigen Clients seine Credentials abliefert, darüber sollte man noch einmal nachdenken.)
- Hinterrücks holt das NTLM-Relay des Angreifers sich über das Web-Enrollment der CA (alternativ ginge auch der CES, daher ist dieser ebenfalls betroffen) mit den abgegriffenen NTLM-Credentials ein Domain Controller Zertifikat auf den Namen des angegriffenen Domain Controllers. Natürlich für ein Schlüsselpaar, das der Angreifer gerade generiert hat.
- Mit diesem erschlichenen Zertifikat besorgt sich der Angreifer beim Kerberos Dienst eines Domain Controllers -im Zweifel dem, der gerade angegriffen wurde- ganz regulär ein Kerberos-Ticket (für Leser, die Kerberosisch sprechen: ein TGT) für den nominellen Zertifikatsinhaber, also den Domain Controller.
- Mit diesem Ticket hat der Angreifer die Rechte eines Domain Controllers in der Hand. Et voilà...
Eigentlich halb so schlimm, aber...
Damit der Angriff wie beispielhaft von Delpy vorgeführt funktioniert, müssen neben dem aktivierten Web-Enrollment (oder CES) noch weitere Voraussetzungen gegeben sein:
- Das CA-Zertifikat der CA, bei der das Domain Controller zertifikat erschlichen wurde muss im "NTAuth" Container des Active Directory eingestellt sein. Eine Microsoft Enterprise CA macht das beim Setup ohne Rückfrage automatisch.
Tatsächlich könnte man überlegen, ob man ein Issuing-CA Zertifikat nach der Installation explizit wieder aus dem NTAuth Container löscht, sofern man als PKI-Betreiber sicher ist, dass sich nie ein Zertifikatsinhaber mit seinem Zertifikat bei AD-integrierten Windows-Diensten anmelden wird. Dies betrifft nicht nur die Kerberos-Anmeldung, sondern bspw. auch den Network Policy Server (NPS), Microsofts Implementierung eines RADIUS-Servers. (Aber dann sollte man sich später nicht wundern, wenn z. B. Smartcard-Logon oder WPA2-Enterprise Anmeldung mit Zertifikat nicht spontan nach den gängigen Anleitungen funktioniert.) - Die "Domain Controller" Zertifikatsvorlage muss in der CA aktiviert sein. Alternativ könnte der Angreifer auch die neueren "Domain Controller Authentication" oder "Kerberos Authentication" Zertifikatvorlagen nutzen. Auch hier ist bei Microsoft Enterprise-CAs praktisch immer eine dieser Vorlagen aktiviert, alleine schon, damit das heimische AD auch per LDAPS (LDAP über TLS) angesprochen werden kann.
Alle drei von Microsoft vordefinierten Templates sind Schema-Version 1 oder 2, so dass auch das seit Jahren nicht mehr aktualisierte Web-Enrollment damit zurecht kommt. Eine selbst erstellte, von "Kerberos Authentication" abgeleitete v3-Zertifikatvorlage könnte über Web-Enrollment nicht mehr angesprochen werden - wohl aber über den CES.
Und selbst wenn im Ausnahmefall eine dieser beiden Voraussetzungen nicht gegeben ist, kann man schwerlich die Hand dafür ins Feuer legen, dass clevere Angreifer nicht doch einen Weg finden, diese Voraussetzungen zu schaffen oder zu umgehen. Daher müssen wir davon ausgehen, dass wir ein Problem haben könnten.
Was tun, sprach Zeus...
Microsoft hat inzwischen auf die PetitPotam-Anfälligkeit der AD Certificate Services reagiert und den Knowledge Base Artikel KB5005413 veröffentlicht. Die darin bevorzugt empfohlene Gegenmaßnahmen, nämlich das Deaktivieren der NTLM Authentifikation auf den Windows Domain Controllern (Hallo Microsoft, wieso habt Ihr das nicht schon längst in der Standardinstallation als Vorgabe getan?) oder vielleicht gleich im ganzen AD (um spontan aufkeimende Bedenken zu zerstreuen: einzelne Ausnahmen für Legacy-Systeme oder -Anwendungen sind möglich), sind sicherlich die sauberste Lösung gegen diesen und ähnliche Angriffe. Aber leider übersteigen sie oft den direkten Zuständigkeitsbereich von PKI-Verantwortlichen.
Im Hinblick auf die betroffenen CA-Server einer Microsoft ADCS-basierten PKI empfehle ich daher folgendes:
- Falls in einer Microsoft-basierten PKI auf allen CAs (insbesondere AD-integrierten Enterprise-CAs, aber wir wollen Root-CAs auf stand-alone Windows Servern ja nicht vergessen) weder das Certificate Authority Web Enrollment (bei deutsch lokalisiertem Server 2016/2019: "Zertifizierungsstellen-Webregistrierung") noch der Certifcate Web Enrollment Service ("Zertifikatsregistrierungs-Webdienst") als Rollenfeature installiert sind, ist keine weitere Aktion erforderlich.
Ob dies auf einem CA-Server der Fall ist, kann man z. B. über folgenden Befehl in einer lokalen PowerShell (auch ohne Administrator-Rechte) nachprüfen:Get-WindowsFeature -Name ('ADCS-Web-Enrollment', 'ADCS-Enroll-Web-Svc')Bei einem "[X]" in der Ausgabe ist das betreffende Feature installiert, bei "[ ]" nicht. - Falls in der PKI das Web Enrollment und/oder der Certifcate Web Enrollment Service als Rollenfeature installiert sind, aber nicht (oder nicht mehr) genutzt werden, kann man das oder die betreffenden Rollenfeatures entfernen.
Das Entfernen geht z. B. über den Server-Manager, aber alternativ natürlich auch per lokaler PowerShell (in diesem Fall mit Administrator-Rechten):Remove-WindowsFeature -Name 'ASCS-Web-Enrollment'
Beim Entfernen des Web Enrollment Features ist noch zu beachten, dass möglicherweise in der betreffenden PKI der IIS einer CA zugleich als (interner) HTTP CRL-Verteilungspunkt fungiert . Typischerweise hat dann eine der in der CRL-DistributionPoint (CDP) Erweiterung aufgeführten URLs ungefähr die Form "http://<CA-Servername_oder_Alias>/CertEnroll/<CRL-Dateiname>.crl".
Remove-WindowsFeature -Name 'ADCS-Enroll-Web-Svc'
In diesem Fall muss nach dem Entfernen des Web Enrollment das lokale Verzeichnis, in dem CRLs und Zertifikate als Dateien abgelegt werden (üblicherweise C:\Windows\System32\CertSrv\CertEnroll), im IIS Manager wieder als virtuelles Verzeichnis mit dem korrekten Pfad-Alias (wie in der CDP-URL angegeben, auf aktuellen Windows-Server Versionen per Default "CertEnroll") der Default Web Site hinzugefügt werden.
Natürlich (hatte ich schon erwähnt, dass ich PowerShell-Fanboy bin?) geht auch das alternativ per PowerShell (mit Administrator-Rechten):New-WebVirtualDirectory -Site 'Default Web Site' -Name 'CertEnroll' -PhysicalPath 'C:\Windows\System32\CertSrv\CertEnroll'
- Falls eines oder mehrere dieser Rollenfeatures benötigt werden, sollte man -sofern noch nicht geschehen- wie in KB5005413 im ersten Aufzählungspunkt unter den Überschriften "Mitigation/Other Mitigations" beschrieben über die lokale Group Policy des CA-Servers die NTLM Authentifikation auf diesem Server deaktivieren.
(Ja, das ginge auch per PowerShell, bräuchte aber Zusatzmodule, daher belassen wir es hier beim Klicken.)