Cert Logon Unsicherheit (KB5014754)

Eine Sicherheitslücke, die im Frühjahr 2022 entdeckt wurde, hat Microsoft im Mai 2022 mit einem Security Update korrigiert. Geschützt sind sie aber erst nach 18 Monaten, wenn Sie nicht aktiv werden. Diese Seite passt in die Windows Security Changes 2023 Serie.

Enforcetermin vom 2. Mai 2023 über 14. Nov 2023 auf 11. Feb 2025!!!! veschoben.
Siehe https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16

Risiko

Damit Sie besser einschätzen können, ob ihr Netzwerk betroffen ist, müssen Sie die Zusammenhänge verstehen. Die meisten Firmen nutzen ein Active Directory, an dem sich die Benutzer mit "Benutzername + Kennwort" anmelden. Allerdings unterstützt das Active Directory natürlich auch eine Anmeldung mit Smartcards und Zertifikate. Viele Firmen stellen in dem Zuge mit einer internen PKI automatisiert Computerzertifikate aus, damit sich diese dann mittels 802.1x am Switch oder auch per VPN authentifizieren. Das Verfahren ist im Grund sogar sicherer als Kennworte, zumindest wenn die Zertifikat nicht exportierbar z.B. im TPM-Chip liegen.

Die Domain Controller nutzen bei der Anmeldung mit einen Zertifikat z.B. den UPN oder andere Felder aus dem Zertifikat und vertrauen natürlich darauf, dass das Zertifikat von vertrauenswürdigen Issuing-CA ausgestellt wurde und die Inhalte korrekt sind. Aber genau da liegt nun das Problem.

Bei der Anforderung eines Zertifikats sollte die PKI prüfen, wer das Zertifikat anfordert und welche Werte enthalten sein dürfen. Es wäre ja gefährlich, wenn ich als Frank Carius ein Zertifikat für ein Admin-Konto anfordern könnte. Aber genau das könnte passiert sein. Dazu gibt es zwei Lücken. Eine ist "nur" eine Konfigurationseinstellung und die andere ein Fehler in der PKI, der durch ein Updates korrigiert wird:

  • EDITF_ATTRIBUTESUBJECTALTNAME2
    Normalerweise steuern Sie als Administrator über "Templates", welches Zertifikate eine PKI für entsprechend berechtigte Benutzer ausstellt. Wenn aber das Attribut "EDITF_ATTRIBUTESUBJECTALTNAME2" gesetzt ist, dann kann ein Anwender auch eigene "Alternative Namen" einreichen, die nicht im Template definiert sind und deren Legitimation nicht geprüft wird. Das Flag sollte also DISABLED sein.
  • Falscher Name im AD-Objekt
    Wenn die PKI die Werte des angeforderten Zertifikats aus dem AD-Objekt bezieht, dann müssen die Daten dort drin auch "trusted" sein. Das ist nicht immer sichergestellt.

Der weite Punkt beschreibt die Lücke sehr gut, denn mit einer internen PKI, einem passenden Template und einer Gruppenrichtlinie kann sich ein Computer ein Zertifikat für z.B.: 802.1x-Authentifizierung besorgen. HIer ist kein Mensch involviert, denn der Computer authentifiziert sich als "Domain Computer" und bekommt ein passendes Zertifikat. Soweit ist das noch sicher. Aber vielleicht wissen Sie auch, dass bei einer Standardinstallation einer Domain jeder Domain Benutzer bis zu 10 Computerkonten in die Domäne aufnehmen darf.

Der Benutzer ist dann aber auch zugleich "Besitzer" des entsprechenden AD-Objekts und dann per LDAP/ADSI auch Eigenschaften des Computers ändern, die für die Anmeldung ausgewertet werden. Was hindert mich nun beim Computerkonto den UPN eines Administrators zu addieren, um dann ein Zertifikat anzufordern und dann mit dem Zertifikat ein Kerberos-Ticket zu erhalten.

Lösung

Das Problem ist hier nicht, dass die PKI diese Felder in das Zertifikat übernimmt sondern dass der KDC bei einer Anmeldung mit einem Zertifikat diese nicht vertrauenswürdige Felder als Kriterium nutzt. Microsoft hat hier nun also zwei Dinge zu korrigieren:

  • Zuverlässiges Feld in Zertifikat
    Vom Benutzer oder auch Helpdesk veränderbare Felder im AD-Objekt eigenen sich nicht zur Authentifizierung. Der KDC sollte daher ein anderes Feld, z.B. die SID des Objekts nutzen.
  • PKI Template anpassen
    Damit der KDC so ein Feld nutzen kann muss die PKI dieses Feld addieren. Dafür sorgt das Update vom Mai 2022, welches auf der PKI diese Änderung durchführt.

Damit ist ihr System ab der Installation des Updates erst einmal sicherer aber noch nicht abgesichert. Wenn der KDC noch Zertifikaten vertraut, die von anderen PKIs ausgestellt wurden, dann bleibt ja das Restrisiko. Zudem kann der DC nicht sofort die Anmeldungsprüfung auf das neue SID-Feld anwenden, denn es gibt ja nach sehr viele Zertifikate, die vor dem Patch ausgestellt wurden und üblicherweise 365 Tage Gültigkeit haben.

Zeitplan

Daher muss auch hier der Rollout in mehreren Phasen erfolgen:

Die Zeitpunkte im Detail:

Datum Aktion

10. Mai 2022

Microsoft stellt das Mai 2022 Security Update bereit, welches das Standardverhalten der PKI anpasst. Ab sofort enthalten ausgestellte Zertifikat für Computer u.a. auch die SID des Objekts. Sie sehen das an der SID im Feld 1.3.6.1.4.1.311.25.2 des Zertifikats:

Denken Sie daran, dass die SID eines Computers bei einer Neuinstallation geändert wird. Auch bei einer Migration in einen anderen Forest oder andere Domain ändert sich die SID. Die frühere SID wird maximal als SID-History mitgeführt. Sie sollten daher immer neue Zertifikat ausrollen.

Achtung
Diese Änderung wird erst am der Installation des Updates auf der PKI aktiv. Wer Security Updates verzögert und viel später installiert, stellt noch eine lange Zeit Zertifikat ohne die SID aus.

Durch die Installation des Updates auf einem KDC ändert sich noch nichts, denn Microsoft hat das Enforcement zuerst auf den Mai 2023 terminiert. Alle ca. 365 Tage gültigen alten Zertifikate während bis dahin hoffentlich verlängert worden.

Q: Once the CA is updated, must all client authentication certificates be renewed?
A: No, renewal is not required. The CA will ship in Compatibility mode. If you want a strong mapping using the ObjectSID extension, you will need a new certificate.
https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16

9. Nov 2022

Als Microsoft im November Updates auch umfangreiche Änderungen bei RPC Sealing und PAC Signing vorgenommen hat, ist zumindest in meinem Tenant im Microsoft 365Message Center die folgende Warnung erschienen:


Quelle: https://admin.microsoft.com/#/MessageCenter/:/messages/MC465515

Ich finde es schon ungewöhnlich, dass auch im Microsoft 365 Tenant auf eine Situation hingewiesen wird, die eigentlich nur On-Premises eine direkte Auswirkung hat.

14. Feb 2023

Ursprünglich war geplant, dass an dem Tag der "Disabled-Mode" abgeschaltet werden sollte. Diesen Zeitpunkt hat Microsoft aber auf den 11. April verschoben

1/26/23: Changed removal of Disabled mode from February 14, 2023 to April 11, 2023
Quelle: https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16

11. Apr 2023

Auf diesen Tag wurde die Deaktivierung des "Disabled-Mode" verschoben.

9. Mai 2023

Nach der ursprünglichen Planung sollten die KDCs ab dem 9. Mai 2023 bei einer Anmeldung nicht mehr die "unsicheren" Fehler nutzen, sondern die SID. Allerdings war das keine gute Idee, denn wenn Computer-Zertifikate 365 Tage gültig sind, dann. ist dies zu früh. Auch wenn Security Updates wichtig sind, so werden Sie sicher nicht "sofort" installiert. Die meisten Firmen habe dazu "Patchdays" oder testen Abhängigkeiten in einem Labor, ehe Sie auf den produktiven DCs ein Update mal eben so installieren.

Das bedeutet aber auch dass aktualisierte Zertifikate erst später ausgestellt werden und ich kenne auch Kunden, die Computerzertifikate auf die erwartete Lebensdauer des Computers (3-5 Jahre) ausstellen.

In all diesen Fällen wird die "Enforcement"-Phase die Clients aussperren.

Microsoft hat mittlerweile diese Deadline um ca. 6 Monate nach hinten verschoben.

UPDATED 12/8/22 Changed Full Enforcement Mode date from May 9, 2023 to November 14, 2023, or later
Quelle https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16

Trotzdem sollten Sie ihre PKI prüfe, welche Zertifikat vor der Installation des Security Update erst nach diesem Zeitpunkt auslaufen.

30. Jun 2023

Microsoft hat den Enforcement Termin vom 14. Nov 2023 auf 11. Feb 2025 verschoben

14. Nov 2023

Erster verschobener Zieltrster Termin zur Aktivierung des Enforce-mode. Wurde am 30.6.2023 abgesagt

11. Feb 2025

Wenn sich nicht doch noch etwas ändert, dann ist dies die neue Deadline zur Aktivierung der strengen Prüfung. Alle Clients und Dienste , die sich per Zertifikat am KDC anmelden und noch kein aktualisiertes Zertifikat mit einer SID im Feld "1.3.6.1.4.1.311.25.2" haben, bekommen kein Kerberos Tickte mehr.

Hinweis: Die "Lücke" wurde Anfang 2022 "gefunden" und ist per Default erst im Feb 2025 gestopft. Wer früher "safe" sein will, muss die strenge Prüfung manuell aktivieren, wenn alle Voraussetzungen erfüllt sind.

Eventlog ID 39-41

Mit dem Mai 2022 Update für Windows hat Microsoft drei neue EventIDs addiert, die ihnen bei der Fehlersuche helfen können.

Obwohl Windows 2008SP2/R2SP1 schon lange "out of Support" ist, gibt es dort diese Meldungen ebenfalls aber mit einer anderen EventiD

Alle drei Meldungen zeigen an, dass das verwende User-Zertifikat sehr wohl gültig ist, aber bestimmte zusätzliche Voraussetzungen nicht erfüllt sind.

Eventlog Source Severity EventID Win2008 EventID Beschreibung

System

Kdcsrv

 Error
Warn

39

41

Das Userzertifikat entspricht nicht den Anforderungen an ein "Strong Mapping". Im Mode "Compatibility" ist es nur eine Warnung und wird angenommen. Beim Mode Enforce ist es ein Error und wird abgelehnt.

System

Kdcsrv

Error

40

48

Das Zertifikat is älter als der Benutzer. für den es behauptet zu sein. Es wurde abgelehnt.

System

Kdcsrv

Error

41

49

Die SID im Zertifikat passt nicht auf den User, für den das Zertifikat ausgestellt wurde. Es wurde abgelehnt.

Die Eventlog können Sie mit folgendem XPath einfach die Events der letzten 24h suchen:

Get-WinEvent `
   -LogName "System" `
   -FilterXPath "*[System[Provider[@Name='Kdcsvc'] 
              and (EventID=39 or EventID=40 or EventID=41) 
              and TimeCreated[timediff(@SystemTime) <= 86400000]]]"

Die Abfrage kann etwas länger dauern und sie sollten das Ergebnis vielleicht in eine Variable übernehmen, damit eine weitere Auswertung schnell möglich ist. Wer natürlich ein "Eventlog Management" hat, kann das Auftreten solcher Events aktiv überwachen und sofort melden lassen.

Eventlog ID 37

Zusätzlich habe ich auf meinem DC auch noch die EventID 37 gefunden, anhand der Sie auf dem KDC solche Clients erkennen können, die sich mit einem alten Zertifikat anmelden. Sie finden die Meldungen im System-Eventlog der KDC. Suchen Sie im System-Eventlog der Domaincontroller nach EventIDs 37 des "Kerberos-Key-Distribution Center".

Die Suche geht auch per PowerShell, was mit dem Parameter "-Computer" auch remote funktioniert:

Get-WinEvent `
   -LogName System `
   -FilterXPath "*[System[Provider[@Name='Microsoft-Windows-Kerberos-Key-Distribution-Center'] and (EventID=37)]]"

Ein Eventlog sieht dann wie folgt z.B. aus:

Log Name:      System
Source:        Microsoft-Windows-Kerberos-Key-Distribution-Center
Event ID:      37
Level:         Warning
Keywords:      Classic
Description: 
The Key Distribution Center (KDC) encountered a ticket that did not contain information about 
the account that requested the ticket while processing a request for another ticket. 
This prevented security checks from running and could open security vulnerabilities. 
See https://go.microsoft.com/fwlink/?linkid=2173051 to learn more.

  Ticket PAC constructed by: DC01
  Client: MSXFAQ.DE\\AdminUser
  Ticket for: krbtgt

altSecurityIdentities

Es ist gar nicht so einfach, auf hunderten oder tausenden Geräten die gültigen und bereits ausgestellten Zertifikate zu ersetzen. Aber das Risiko eines Missbrauchs ist natürlich groß. Für den Fall gibt es eine zweite Option, die für einzelne Clients aber auch für alle Zertifikate genutzt werden kann.

  • 1.3.6.1.4.1.311.25.2 ? SID
    Sobald das "Enforcement" auf dem KDC aktiviert wird, vertraut der KDC nicht mehr den generischen Feldern wie Subject, AlternateSubjectName, sondern matched den Inhalt des Feldes "1.3.6.1.4.1.311.25.2" auf die ObjectSID.
  • altSecurityIdentities = X.509 Zertifikat
    Als Administrator können Sie aber auch das Zertifikat in das Feld "altSecurityIdentities" des AD-Objekts übertragen und damit einen Treffer erreichen.

Der Weg über das Feld altSecurityIdentities kann den Wechsel in die Enforce-Mode stark beschleunigen, denn Sie könnte ja einfach alle von der PKI ausgestellten Zertifikat in das Feld "altSecurityIdentities" des dazu gehörigen Objekts eintragen und dann auf dem KDC das Enforcement aktivieren. Das ist durchaus interessant, wenn Sie viele Zertifikate ausgestellt haben und der Renewal-Prozess zu lange dauern würde.

Am einfachsten schreiben Sie das Zertifikat mittels Set-ADUser aber achten sie auf die "besondere" Schreibweise. Sie müssen den DN des Issuers in umgekehrter folge schreiben und auch die Seriennummer umdrehen.

Set-ADUuser `
   -Identity "username" `
   -Replace @{altSecurityIdentities= “X509:DC=NET,DC=msxfaq,CN=issername<SR>seriennummerrueckwaerts”}

Es gibt noch andere Schreibweisen, die unterschiedlich sicher/unsicher sind.


Quelle: https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16

Bislang habe ich noch kein Skript gefunden, welches die Zertifikat aus der PKI ausliest und in das AD-Objekt importiert.

Aber auch wenn Sie für einen Großteil der Client schnell genug ein neues kompatibles Zertifikat bekommen würde, wäre der Eintrag in "altSecurityIdentities" immer noch ein passender Weg für die nicht aktualisierten Clients.

CertificateMappingMethods

Bei einer Anmeldung per Zertifikat, sei es per Smartcard oder z.B. 802.1x/Radius muss der Security Provider entscheiden, welche Informationen er aus dem Zertifikat für die Suche nach dem dazugehörigen AD-Objekt heranzieht. Schannel geht die Felder von oben nach unten durch, wobei über eine Bit-Maske gesteuert werden kann, ob das Feld relevant ist.

Kriterium Sicherheit Bit Hex

Subject/Issuer certificate mapping

Schwach

1

0x01

Issuer certificate mapping

Schwach

2

0x02

UPN certificate mapping

Schwach

3

0x04

S4U2Self certificate mapping

Stark

4

0x08

S4U2Self explicit certificate mapping

Stark

5

0x10

Sie sehen aber auch, dass die schwachen Felder oben stehen und daher zuerst ausgewertet werden, wenn Sie denn aktiv sind. Für eine sichere Umgebung sollten Sie die unsicheren Felder daher ausschließen. Die folgende Einstellung deaktiviert die Auswertung der ersten drei Kriterien.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel]
"CertificateMappingMethods"=dword:00000018

Wenn das Feld nicht vorhanden ist, dann wirken die Standardeinstellungen von Windows, welche bis April 2022 auf "0x1F" stand und damit auch die schwachen Prüfungen erlaubt hat.

Mit dem Mai 2022-Update wurde der Default auf 0x18 umgestellt.

StrongCertificateBindingEnforcement

Zuletzt gibt es noch einen Registrierungsschlüssel, der erst mit dem Mai 2022 Update abgefragt wird und ebenfalls eine Auswirkung auf die Auswertung von Zertifikaten und deren Protokollierung hat. Wenn Sie die Lücke CVE-2022–26923 schließen wollen, müssen Sie neue Zertifikate mit SID ausrollen oder altSecurityIdentities setzen und dann den Enforce-Mode aktivieren. Allerdings möchten wir doch alle erst einmal sehen, was passieren würde. Daher kennt dieser Schlüssel drei Werte:

0 = Anmeldung mit Zertifikat ohne SID werden zugelassen und nicht protokolliert
1 = Anmeldung mit Zertifikat ohne SID werden zugelassen und protokolliert (Standard)
2 = Anmeldung mit Zertifikat ohne SID werden NICHT zugelassen und protokolliert

Setzen Sie den Schlüssel bitte nicht auf 0, sondern lassen Sie ihn einige Zeit auf 1 und überwachen das Eventlog auf Client, die sich ohne Anpassung später nicht mehr anmelden könnten.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc]
"StrongCertificateBindingEnforcement"=dword:0000001

Microsoft wollte den Default am 9. Mai 2023 auf "2" stellen aber hat den Termin auf den 14. Nov 2023 verschoben
Quelle: https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16

EDITF_ATTRIBUTESUBJECTALTNAME2

Bei der Recherche zu dem Thema mit Zertifikaten zur Anmeldung bin ich über eine weitere Funktion der Windows PKI gestoßen, die mich erschreckt hat, da sie auf meinen PKIs ebenfalls standardmäßig aktiv ist.

certutil -v -getreg Policy\Editflags
....
   EDITF_ATTRIBUTESUBJECTALTNAME2 -- 40000 (262144)
....

Dieses Flag weist die PKI an, dass eine Anforderung die Felder überschreiben kann, die durch die Zertifikatsvorlage durch den Administrator vorgegeben sind. Nicht nur theoretisch könnte damit ein Benutzer ein Zertifikat anfordern und die Inhalte von z.B. "SubjectAlternateName", "DNSName" o.ä. überschreiben oder ergänzen, obwohl sie in dem Template nicht vorhanden sind. Hierzu hat Uwe Gradenegger einen sehr schönen Blog-Artikel schon im Februar 2020 geschrieben:

Bitte prüfen Sie die aktuelle Einstellung ihrer Windows CA und ob dieses Flag wirklich erforderlich ist.

Wenn Sie die Funktion deaktivieren, dann muss eine Zertifikatsanforderung sich streng an das ausgewählte Zertifikats-Template halten und über Berechtigungen auf den Templates können Sie bestimmen, wer welches Template nutzen darf. Insofern sollten Sie sicher sein, dass nur die Templates ein "Autoenroll" erlauben, die die Daten aus einer vertrauenswürdigen Quelle, z.B. AD, beziehen oder nicht kritisch sind. Alle anderen Templates, um z.B. Webserver-Zertifikate mit weiteren SAN-Namen anzufordern, sollten dann ein manuelles Enrollment fordern oder auf vertrauenswürdige Personen beschränkt werden. Abschalten geht ebenfalls über certutil.exe auf der CA:

certutil -v -setreg Policy\Editflags -EDITF_ATTRIBUTESUBJECTALTNAME2

Danach muss der Zertifikatsdienst einmal neu gestartet werden.

Aktionsplan

Wer vor Überraschungen gefeit sein möchte, sollte daher sehr schnell...

Aktion Beschreibung Erledigt

Neue Zertifikate prüfen

Kontrollieren Sie, ob die PKI auch die SID in Zertifikate ausrollt. Das sollte Sie automatische machen, nachdem das Mai 2022 Update auf dem CA-Server installiert wurde.

Alte Zertifikate prüfen

Ermitteln Sie den Tag, an dem Sie auf der PKI das Mai 2022 Security Update installiert haben und generieren Sie dann eine Liste aller Zertifikate, die vorher ausgestellt und noch nicht erneuert oder zurückgezogen wurden. Hier besteh das Risiko, dass diese von Client auch noch genutzt werden, wenn der KDC in die Enforcement-Phase kommt.

Optional können Sie die alten Zertifikate in das Feld altSecurityIdentities des Objekte importieren.

Enforcement vorziehen

Wenn Sie nicht von der Aktivierung durch Microsoft überrascht werden wollen, dann würde ich das Enforcement vorziehen, sobald sie glauben alle Anforderungen zu erfüllen. Noch können Sie das Enforcement ja wieder deaktivieren, wen Sie etwas übersehen haben sollten.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc]
"StrongCertificateBindingEnforcement"=dword:00000002

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel]
"CertificateMappingMethods"=dword:00000018

Zwischenstand

Diese Update KB5008380 entfaltet nicht sofort seine Wirkung, sondern bereitet das Enforcement erst vor. Ehe ein KDC auf dem Domain Controller tatsächlich nur noch vertrauenswürdige, weil nicht durch Anwender fälschbaren Feldern vertraut, vergehen aber viele Monate, in der die Unsicherheit noch nicht beseitigt ist. Microsoft versucht hier den Spagat zwischen sicher und Massentauglich. Wer heute schon aktiv Anmeldungen per Zertifikat nutzt, weil die höhere Sicherheit gefordert ist, sollte ganz schnell nicht nur das Update auf der PKI ausrollen sondern entweder alle Zertifikate ersetzten oder eine strenge Bindung über das Feld "altSecurityIdentities " herstellen und dann das Enforce vorziehen.

Weitere Links