Ä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 den "StrongCertificateBindingEnforcement" Registry-Schlüssel (Typ DWORD) möglich, den neuen Verarbeitungs-Modus zu verwenden, bei welchem eine (nach Ansicht von Microsoft) "starke" Bindung hergestellt wird.

Der Schlüssel befindet sich an folgendem Ort:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc

Der Schlüssel kann folgende Werte annehmen:

WertBeschreibung
0 Anmeldungen mit Zertifikaten ohne SID-Attribut werden nicht protokolliert und zugelassen.
1Anmeldungen mit Zertifikaten ohne SID-Attribut werden protokolliert und zugelassen. (Standardeinstellung)
2Anmeldungen mit Zertifikaten ohne SID-Attribut werden protokolliert und nicht zugelassen.

Ändert man den Wert auf "2", werden entsprechende Anmeldungen abgelehnt und entsprechend auf dem Domänencontroller protokolliert.

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 explizites 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.

Common Name reicht offenbar auch nicht mehr…

Microsoft verschweigt offenbar des Weiteren, dass es seit dem Patch ab sofort auch erforderlich ist, die entsprechenden Zertifikat-Attribute userPrincipalName bzw. dNSName mit den Werten des entsprechend zugehörigen Active Directory Kontos zu befüllen, das alleinige Verwenden des commonName also nicht mehr ausreicht.

Hier gab es Verwirrung, da einige Blogger schreiben, es müsse unbedingt das userPrincpialName Attribut befüllt und entsprechend in der Zertifikatvorlage aktiviert sein. Dies verleitete einige Administratoren dazu, dies offenbar auch für Computer-Zertifikate zu aktivieren, was natürlich nicht notwendig ist. Vielmehr kommt es darauf an, was durch das Zertifikat identifiziert werden soll. Bei Computer-Zertifikaten muss ein Subject Alternative Name vom Typ "dNSName" vorhanden sein, bei Benutzer-Zertifikaten vom typ "userPrincipalName".

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 proprietä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.

Das Problem tritt offenbar nur dann auf, wenn die NPS-Rolle auf einem Domänencontroller installiert ist.

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 offenbar nicht. Erst das Out-of-Band Update vom 27.05.2022 behebt das Problem offenbar.

Stand 05. August 2022 kann ich bestätigen, dass ein Domänencontroller mit Patchlevel Juli 2022 (StrongCertificateBindingEnforcement ist mit Wert 1 konfiguriert oder nicht gesetzt) und installierter Netzwerkrichtlinienserver-Rolle sich exakt wie dokumentiert verhält, sprich die RADIUS-Anmeldungen annimmt und auch dann genehmigt, wenn die SID-Zertifikaterweiterung im Zertifikate nicht vorhanden ist. Das Ereignis mit ID 39 wird als Warnung protokolliert.

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-only 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 für die Identität Benutzer ausgestellt, welcher 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 Möglichkeit 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?

Mittlerweile wird diese Annahme unter Anderen von der US-Regierung geteilt, ohne dass es hierfür eine Lösung gäbe:

Important Note: Microsoft plans to remove ‘Compatibility Mode’ and move all Windows Server devices to ‘Full Enforcement’ mode in May 2023. This change will break authentication if agencies have not created a strong mapping or added SIDs to certificates. CISA and the interagency working group are in active discussions with Microsoft for an improved path forward. At this time, CISA does not recommend agencies pursue migration to a strong mapping.

GUIDANCE ON APPLYING JUNE MICROSOFT PATCH TUESDAY UPDATE FOR CVE-2022-26925 (Cybersecurity & Infrastructure Security Agency)

Hier kann man durchaus von einer tickenden Zeitbombe sprechen.

Alternative Möglichkeiten für eine "starke" Bindung

Microsoft weist darauf hin, dass – sofern man keine Zertifikate mit der neuen Zertifikaterweiterung ausstellen kann oder möchte – auch manuell eine "starke" Bindung an ein Zertifikat über das altSecurityIdentities Attribut für Active Directory Objekte einrichten kann.

Dieser Schritt muss jedoch manuell oder mit einem Script erfolgen. Eine brauchbare Automatisierungslösung bietet Microsoft nicht an. Unklar ist hierbei auch, wie diese Liste dauerhaft gepflegt werden kann.

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.

Generell ist ein starkes Stück, eine derart weitreichende Änderung einzuführen, ohne die Auswirkungen abschätzen zu können oder sich wenigstens mit den wichtigsten Partnern im Vorfeld abzustimmen. Eine (für PKI Lebenszyklen) derart kurze Vorlaufzeit von gerade einmal einem Jahr kann eigentlich schon als fahrlässig bezeichnet werden.

Weiterführende Links:

Externe Quellen