Änderungen an der Zertifikatausstellung und an der zertifikatbasierten Anmeldung am Active Directory mit dem Patch für Windows Server vom 10. Mai 2022 (KB5014754)

Mit dem Patch vom 10. Mai 2022 versucht Microsoft, eine Sicherheitslücke im Active Directory zu schließen, in welcher die zertifikatbasierte Anmeldung (im Allgemeinen bekannt als Smartcard Logon) zu schließen.

Das Update ändert sowohl das Verhalten der Zertifizierungsstelle als auch das Verhalten des Active Directory beim Verarbeiten von zertifikatbasierten Anmeldungen.

Hintergründe

Die gesamte Funktionsweise des Angriffs kann detailliert beim Entdecker der Sicherheitslücke nachgelesen werden.

Zertifikatbasierte Anmeldung wird nicht nur beim offensichtlichen bekannten "Smartcard Logon" eingesetzt, sondern auch beim Active Directory Clientzertifikat-Mapping des Internet Information Service (IIS).

Nicht nur Benutzerkonten können sich mit einem Zertifikat an der Domäne anmelden. Auch für Computerkonten ist dies möglich.

Bei Benutzerkonten wird das userPrincipalName Attribut des zugehörigen Active Directory Kontos in das ausgestellte Zertifikat eingetragen und vom Active Directory bei Anmeldung wieder auf das dazugehörige Objekt verbunden.

Bei Computerkonten ist die Funktionsweise prinzipiell die gleiche, jedoch wird hier das dNSHostName Attribut in das Zertifikat eingetragen und vom Active Directory bei Anmeldung ausgewertet.

Siehe auch Artikel "Zur Option "Build this from Active Directory information" bei Zertifikatvorlagen".

Der Angriff basiert darauf, dass der Besitzer eines Computerobjektes (derjenige, der die Maschine in die Domäne aufgenommen hat – dieses Recht hat in der Standardeinstellung jeder Benutzer) dessen dNSHostName Attribut eigenständig auf einen beliebigen Wert setzen kann. Kollisionen mit anderen Objekten (also ob der gleiche Wert bereits auf einem anderen Computerobjekt gesetzt ist), werden bei dNSHostName nicht erkannt.

Entsprechend ist es möglich, Zertifikate für Identitäten anderer Computer, auch Domänencontroller, zu beantragen, mit denen dann eine Identifikation unter der Identiät des gefälschten Computerobjektes möglich ist, was wiederum das Auslesen aller Anmeldedaten der Domäne zur Folge haben kann.

Das Update

Die Änderungen sind detailliert im Microsoft Knowledge Base Artikel KB5014754 beschrieben.

Neue Zertifikaterweiterung

Das Update führt eine neue Zertifikaterweiterung namens szOID_NTDS_CA_SECURITY_EXT mit Objektidentifizierer (OID) 1.3.6.1.4.1.311.25.2 ein.

Enterprise Certificate Authorities (CA) will start adding a new non-critical extension with Object Identifier (OID) (1.3.6.1.4.1.311.25.2) by default in all the certificates issued against online templates after you install the May 10, 2022 Windows update.

KB5014754—Certificate-based authentication changes on Windows domain controllers (Microsoft Corporation)

Alle Zertifikate, die von "Online" Zertifikatvorlagen, also solche, bei denen der Identitätsanteil im Zertifikat durch das Active Directory gebildet wird, ausgestellt werden, beinhalten ab Zeitpunkt der Installation des Updates auf der Zertifizierungsstelle diese Zertifikaterweiterung.

Die Zertifikaterweiterung beinhaltet das objectSid ("Security Identifier") Active Directory Attribut des zugehörigen Kontos. Die Eintragung des Zertifikatattributs wird durch das Windows Default Policy Modul vorgenommen, welches ein entsprechende Update erhalten hat.

Mit dem Patch wurde somit eine neue Version des Windows Default Policy Moduls installiert, um die entsprechenden Änderungen bei der Zertifikatausstellung abzubilden.

Siehe Versionsummer vor dem Patch…

… und nach Installation des Patch.

Auf die Verwendung des TameMyCerts Policy Moduls hat die Änderung keine Auswirkungen, da dieses das Windows Default Policy Modul einfach nachlädt. Das neue Zertifikatattribut wird entsprechend auf die gleiche Weise ausgestellt.

Änderungen am Active Directory

Anstatt die grundlegende Problematik (Besitzer von Computerkonten können deren dNSHostName Attribut selbst verändern und es ist kein uniqueness Constraint auf dieses gesetzt) anzugehen, ist Microsoft ab sofort der Meinung, dass das dNSHostName Attribut nun nicht mehr als "starke" Verbindung zum entsprechenden Active Directory Konto zu bewerten ist.

Entweder soll die Verbindung zwischen Active Directory Konto und Zertifikat nun manuell über das altSecurityIdentities Attribut des Kontos erfolgen, oder ein Zertifikat muss die neue Zertifikaterweiterung mit dem entsprechenden Security Identifier des Kontos vorweisen.

Entsprechend werden bei der Verarbeitung von zertifikatbasierten Anmeldungen nach dem "alten" Schema nun Warnmeldungen protokolliert. Es ist über Registry-Schlüssel möglich, den neuen Verarbeitungs-Modus zu verwenden, bei welchem eine (nach Ansicht von Microsoft) "starke" Bindung hergestellt wird.

Microsoft plant, den "neuen" Mechanismus exakt ein Jahr nach Release des Updates, also am 09. Mai 2023 hart zu erzwingen. Die entsprechende Logik ist bereits im Patch enthalten. Die im Artikel genannten Registry-Schlüssel werden ab dann nicht mehr verwendbar sein.

Wenn kein explizities Mapping von Zertifikat nach Konto gewünscht ist, also die neue Zertifikaterweiterung verwendet werden soll, müssen bis zum Stichtag alle Zertifikate neu ausgestellt werden.

Umgang mit der neuen Situation

Offline-Zertifikatvorlagen wurden anscheinend vergessen

Ich habe die Änderung zum Anlass genommen, das PSCertificateEnrollment PowerShell Modul zu erweitern, sodass die neue Zertifikaterweiterung in einen "offline" Zertifikatantrag eingetragen werden kann.

Import-Module PSCertificateEnrollment
New-CertificateRequest -Subject "CN=test" -Sid "lol"

Wie sich zeigt, reicht das Windows Default Policy Modul bei Offline-Zertifikatvorlagen (also solchen, bei denen der Antragsteller den Identitätsinhalt des Zertifikats selbst bestimmen kann – dies ist beispielsweise der Fall, wenn der Registrierungsdienst für Netzwerkgeräte (NDES) oder ein Mobile Device Management System wie AirWatch oder Microsoft InTune verwendet wird) die Zertifikaterweiterung mit beliebigem Inhalt an das ausgestellte Zertifikat durch.

Gelingt es einem Angreifer nun, Zugriff auf eine solche Zertifikatvorlage zu erhalten, ist die vermeintlich "starke" Bindung an ein Active Directory Objekt hinfällig (sofern man auf die neue Zertifikaterweiterung anstatt explizitem Mapping für die Authentisierung setzt).

Darüber hinaus bin ich der Meinung, dass die Verwendung einer prorietären Zertifikaterweiterung hier sogar gefährlich sein kann, da dieser Identitätstyp von gängigen Lösungen nicht als Identität erkannt und in einer (sofern vorhanden) Datenbank erfasst würde.

Auch das TameMyCerts Policy Modul benötigt einen Patch, um die neue Zertifikaterweiterung verarbeiten zu können, bzw. entsprechende "offline" Zertifikatanforderungen zunächst wenigstens erkennen zu können.

Auch erstaunt es, dass eine Steuerung, ob diese Zertifikaterweiterung für offline-Zertifikatanforderungen verwendet werden darf, über den dafür vorgesehenen EnableEnrolleeRequestExtensionList Registry Schlüssel leider nicht möglich ist, da sie offenbar hart in das Policy Modul kodiert ist und entsprechend nicht in der Liste auftaucht (und dennoch aktiv ist).

Probleme mit dem Patch, bei der Anmeldung am Network Policy Service (NPS)

Relativ schnell nach Installation des Patch zeigte sich, dass Unternehmen, die den Network Policy Service (NPS) einsetzen, um Remote Access (RAS) oder Network Access Control (NAC) Szenarien wie Anmeldungen am verkabelten oder drahtlosen Netzwerk mit Zertifikaten zu ermöglichen, sich mit einem Ausfall genau dieser Services befassen mussten.

Offenbar wurde seitens Microsoft übersehen, dass verschiedenste Anmeldungen im Active Directory auf dem gleichen Verfahren – so auch der NPS – basieren. Und dort wurde offenbar der "neue" Betriebsmodus bereits erzwungen. Auch der am 19. Mai 2022 nachgeschobene Patch für den Patch behebt das Problem nicht.

Angeblich tritt das Problem nur auf, wenn der NPS direkt auf einem Domänencontroller installiert ist. Dies wurde bislang aber noch nicht belastbar bestätigt.

Aktuell gibt es hier nur den Workaround, zuerst die Zertifizierungsstelle zu patchen, dann alle Zertifikate (mit der neuen Zertifikaterweiterung) neu auszustellen und anschließend die Domänencontroller zu patchen – was in der Praxis nicht praktikabel sein wird, da eine typische Zertifikaterneuerung durchaus mehrere Monate in Anspruch nehmen kann, bis sie flächendeckend erfolgt ist.

Eine Deinstallation des Patch kann auch nicht die Lösung sein, da man hierdurch gegen etliche Sicherheitslücken ungeschützt bleibt (auch wenn die US-Behörde CISA zwischenzeitlich vor der Installation der Patches gewarnt hat).

Angeblich funktioniert der Patch darüber hinaus auch nicht mit Ready-onle Domänencontrollern (RODCs).

Was ist eigentlich mit gewollten Offline-Szenarien?

Des Weiteren stellt sich mir die Frage, wie Microsoft gedenkt, mit Szenarien umzugehen, die offline-Zertifikatvorlagen gewollt nutzen. Nehmen wir als Beispiel mit einem Mobile Device Management (MDM) System (z.B. das Microsoft-eigene Intune/MEM oder VMwares AirWatch) verwaltete Endgeräte wie Smartphones. Diese können durchaus Zertifikate besitzen, welche für eine Anmeldung via RAS oder NAC verwendet werden (üblicherweise werden diese auf den Benutzer ausgestellt, der das Gerät verwendet).

Wird nun im Unternehmen im Backend der Network Policy Service (NPS) eingesetzt, stellt sich mir die Frage (sofern das NPS-Problem zwischenzeitlich durch einen Patch behoben werden sollte), was wohl am 09. Mai 2023 passieren wird, wenn Microsoft wie geplant die Erzwingung der neuen Zertifikaterweiterung aktiviert (die "Zeitbombe" ist ja schließlich bereits enthalten), und das ohne Option der Abschaltung. Werden alle MDM-Hersteller bis zu diesem Datum dafür Sorge getragen haben, dass ihre Produkte die neue Zertifikaterweiterung beantragen werden und dass ihre Kunden alle Zertifikate bis dahin erneuert haben werden?

Deaktivieren der Erweiterung

Die Deaktivierung der neuen Zertifikaterweiterung kann dann Sinn machen, wenn eine zertifikatbasierte Anmeldung in der Umgebung ohnehin nicht vorgesehen ist.

Bitte diesen Schritt bitte nur mit Sinn und Verstand vornehmen, und nur wenn es einen triftigen Grund gibt. Die Änderung ist als "nicht kritisch" markiert und sollte daher keine negativen Auswirkungen z.B. in Hinsicht auf Anwendungskompatibilität haben.

Auf Ebene der jeweiligen Zertifikatvorlage kann die Erweiterung mit folgendem Befehl deaktiviert werden:

certutil -dstemplate user msPKI-Enrollment-Flag +0x00080000

Das Flag heißt CT_FLAG_NO_SECURITY_EXTENSION, wird derzeit vom Betriebssystem aber noch nicht aufgelöst.

Added a new enrollment-attribute flag CT_FLAG_NO_SECURITY_EXTENSION to the msPKI-Enrollment-Flag Attribute table, that when applied, instructs the CA to not include the security extension szOID_NTDS_CA_SECURITY_EXT (OID:1.3.6.1.4.1.311.25.2), as specified in [MS-WCCE] sections 2.2.2.7.7.4 and 3.2.2.6.2.1.4.5.9, in the issued certificate. A behavior note is added to indicate that this enrollment flag is supported by the operating systems specified in [MSFT-CVE-2022-26931], each with its related KB article download installed.

Windows protocols: What’s New and Changed (Microsoft Corporation)

Auf Zertifizierungsstellen-Ebene kann die Erweiterung ebenfalls deaktiviert werden. Somit trägt die entsprechend konfigurierte Zertifizierungsstelle die Erweiterung in keines der veröffentlichten Zertifikate ein. Mit folgendem Befehl kann die Einstellung vorgenommen werden:

certutil -setreg policy\DisableExtensionList +1.3.6.1.4.1.311.25.2

Fazit/Bewertung

Der Patch wirkt sehr überhastet:

  • Das eigentliche Problem, dass ein Compterkonto einige seiner eigenen Attribute beliebig setzen kann, wird offenbar nicht adressiert.
  • Die neue Zertifikaterweiterung wird bei "offline" Zertifikatvorlagen nicht überprüft, entsprechend kann nicht wirklich die Rede von einer "starken" Bindung an das Active Directoy Objekt die Rede sein. Sie ist im Windows Default Policy Modul hart einkodiert und taucht nicht in den eigentlich dafür vorgesehenen Registrierungsschlüsseln des Policy Moduls für Offline-Zertifikatanforderungen auf, d.h. man ist hier zu seinem eigenen Design inkonsistent und baut offenbar hierdurch sogar einen neuen Bug ein. Dies entspricht aber effektiv dem Grad der Pflege, den das Produkt derzeit noch von Microsoft erwarten kann, nämlich gerade nur das allernötigste mit dem geringstmöglichen Aufwand umzusetzen.
  • Mit Einführung des Updates hat Microsoft eine offenbar nicht enden wollende Kette an neuen Problemen geschaffen (besteht hier eventuell ein Problem mit der Qualitätskontrolle)?
  • Offenbar hat Microsoft auch vergessen, dass es in der PKI auch noch eine Welt abseits des Active Directory gibt, hier aber nicht Sorge getragen, dass alle betroffenen Zertifikate bis zum Stichtag über die neue Zertifikaterweiterung verfügen können.

Darüber hinaus sind essentielle Themen weiterhin nicht angegangen worden. Beispielsweise werden Extended Key Usages von Domänencontrollern in der Standardeinstellung immer noch nicht geprüft.

Meine Empfehlung lautet daher weiterhin, die (wenn sie ohnehin nicht verwendet wird) Smartcard-Anmeldung und artverwandte Fälle komplett zu verhindern und alle Zertifizierungsstellen (bei denen dies gefahrlos möglich ist) aus NTAuthCertificates zu entfernen, welche keine Zertifikate für die entsprechenden Anmeldemechanismen ausstellen sollen. Der Network Policy Service sollte man meiner Meinung nach nicht mehr einsetzen, da er aufgrund seiner Abhängigkeit vom Active Directory verschiedenste Sicherheits- und wie man sieht nun auch Verfügbarkeitsprobleme schafft.

Weiterführende Links:

Externe Quellen