Windows Security Changes 2023

Das Jahr 2023 kann den ein oder anderen Administrator "überraschen", wenn er seine Umgebung nicht vorbereitet hat, denn drei kritische Sicherheitslücken, die schon im Jahr 2022 gefixt wurden, werden im Laufe des Jahres 2023 ohne weitere Rückfrage und unumkehrbar "scharf" geschaltet. Einige Dinge fallen auf:

Die Änderungen kommen durch Windows Security Updates und die Zeitpunkt sind nicht im zuerst verteilten Code hinterlegt, sondern neuere Security Updates setzen die angefangenen Veränderungen fort. Microsoft kann damit die Zeitpunkte auch noch verändern.

Diese Seite als YouTube Video
https://youtu.be/kZ8Q0kmGUxs

Kurzfassung

In 2022 sind einige Sicherheitslücken bekannt und von Microsoft behandelt worden, die aber nicht einfach durch einen Fix auf dem Server zu lösen sind, sondern auch auf dem Client eine Anpassung erforderlich machen. Daher reicht es nicht einfach den Fix auf dem Server zu installieren. Damit ist noch keine Sicherheit geschaffen. Erst wenn auch alle Clients mitspielen und die Einstellungen "erzwungen" werden, ist das System gesichert. Die Umsetzung erstreckt sich je nach Fix über mehrere Monate. Für den Administrator bedeutet das:

  • Wenn Sie früher "sicher" sein wollen...
    ...müssen sie die Updates installieren und per Konfiguration die höhere Sicherheit "erzwingen". Ansonsten bleibt ihr System unsicher, bis Microsoft den Zwang aktiviert
  • Wenn alles funktionieren soll...
    ...dann sollten Sie nach der Installation prüfen und testen, damit die sichere Einstellung in ihrer Umgebung möglich ist.

Sie können die Aktivierung der hohen Sicherheit durch Microsoft nur kurze Zeit verzögern. Im Jahr 2023 weiß von folgenden kritischen Updates, die im Laufe des Jahres erst ihre Wirkung entfalten.

  • CVE-2022-34691 Stenge Prüfung von Zertifikaten bei der Anmeldung
    Das betrifft alle, die bislang Benutzerzertifikate oder Computerzertifikate bei der Anmeldung per Smartcard oder am VPN oder RDP o.ä. genutzt haben und insbesondere die Zertifikate länger als 1 Jahr laufen und daher noch nicht seit einem Windows Updates im Mai 2022 getauscht wurden. Deadline war der 9. Mai 23 aber wurde wohl auf 14. Nov 23 verzögert.
  • CVE-2022-37967 PAC Signing
    Schrittweise wird hier das Signing erst ermöglicht, dann aktiviert und zuletzt erzwungen. Wer nicht mitspielt, ist am 11. Jun 2023 raus.
  • CVE-2022-38023 RPC Sealing
    Auch das passiert schleichend aber sollte nicht weh tun, da die Server Sealing erzwingen und es eigentlich alle (Windows-) Clients können

Die Installation dieser Updates erfolgte in 2022 aber erst in 2023 entfalten Sie ihre Wirkung:

Wenn Sie sich schon mit den drei Anforderungen beschäftigen, dann können Sie als Bonus noch zwei andere Absicherungen umsetzen, von denen die RC4-Abschaltung vielleicht auch bald von Microsoft erzwungen wird.

  • Bonus1: Zertifikattemplate erzwingen
    Wenn ihre PKI nicht "sicher" ist, dann könnte ein Anwender ein Zertifikat mit selbst vorgegeben Feldern anfordern und das durch den Admin vorgegebene Template außer Kraft setzen
  • Bonus2: RC4 auf Kerberos abschalten
    Seit Windows 2008/Vista ist AES128/AES256 möglich und mittlerweile sollte jeder auf RC4 verzichten können. Ich erwarte, dass Microsoft RC4 bald deaktiiert, wie es mit Win2008/Vista schon DES gesperrt hat.

Höchste Zeit, die Änderungen anzuschauen, ehe Sie in ihrem Netzwerk etwas behindern oder brechen:

Warum ist das so?

Ich möchte es mal "nicht technisch" erklären. Sie sind Besitzer eines Mehrfamilienhauses mit mehreren Mietern und das Haus ist durch eine Schließanlage abgesichert. Nun wird bekannt, dass die Schließanlage eine Sicherheitslücke hat und schnellstens ausgetauscht werden sollte.

Natürlich könnten Sie nun neue Schlösser und Schlüssel kaufen und direkt verbauen lassen. Dumm nur, dass die Bewohner bei der Rückkehr nicht mehr in ihre Wohnung kommen und einige Bewohner sind sogar länger weg. Sie können Sie dann ja nicht die ganze Zeit im Flur aufhalten.

Also legen Sie die neuen Schlösser bereit und verteilen die neuen Schlüssel zusätzlich zu den bisherigen Schlüsseln. Erst wenn alle Nutzer einen neuen Schlüssel haben, können die die Schlösser mit der höheren Absicherung versehen.

Weckruf 1: MC465515 / KB5014754

Betrifft alle, die Zertifikate zur Anmeldung nutzen, d.h. Smartcard, 802.1x, Browser, RDP, VPN etc.

Wer einen Microsoft 365 Tenant betreibt und das Microsoft 365 Message Center regelmäßig liest, sollte im November 2022 schon einmal alarmiert worden sein:


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

Im Mai 2022 hat Microsoft eine Lücke gemeldet bekommen, über die ein Angreifer sich höhere Rechte beschaffen kann, indem er die schwache Überprüfung bei einer Anmeldung mit Zertifikaten dazu nutzt, sich ein Kerberos-Ticket für ein anderes Konto, z.B. DomainAdmin oder DomainController zu beschaffen. Microsoft hat diese Lücke dann gefixt aber musste schnell wieder zurückrudern, da es z.B. NPS-Server gestört hat.

Der Fix korrigiert leider nicht die Ursache, dass ein Computerkonto oder der Besitzer eines Computerkontos nicht mehr einfach die Felder ändern kann, die von der Windows PKI zur Ausstellung des Zertifikats genutzt werden, sonderd sorgt dafür, dass der Domain Controller nun ein anderes Feld prüft, welches der Anwender oder Computer nicht ändern kann. Allerdings funktioniert das erst, wenn das Update auf der PKI installiert wurde und die legitimen Zertifikate durch neue Zertifikate ersetzt wurden, in denen die SID in der Erweiterung 1.3.6.1.4.1.311.25.2 eingetragen wurde.

Microsoft hat dann eine Einstellmöglichkeit geschaffen, damit der Domain Controller noch die schwache Prüfung durchführt, bis alle Clients ein neues Zertifikat bekommen haben sollten. Diese Schwächung sollte aber am 9. Mai 2023 deaktiviert werden. Dies wurde nun wohl auf den 14. Nov 2023 verschoben:

Datum Aktion

10. Mai 2022

Verteilung der aktualisierten Codebasis zur strengen Prüfung der Zertifikate im Mai 2022 Security Update. Der Code verändert auf der Windows PKI auch die Templates um die SID ins Zertifikat mit zu addieren. Alle ab jetzt ausgestellten Zertifikaten sollten entsprechend "angereichert" sein. Sie sehen das an der SID im Zertifikat:

Achtung
Wer seine PKI später aktualisiert hat oder die Zertifikate länger als 365 Tage laufen, bekommt ein Problem.

9. Mai 2023

Ursprünglich geplantes Datum, wann die strenge Prüfung aktiv wird.

Wenn alle Computerzertifikate maximal 365 Tage gültig sind und die PKI direkt aktualisiert wurde, dann sollten alle Computer schon

14. Nov 2023

Neue Deadline zur Aktivierung der strengen Prüfung. Siehe auch:

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

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

Sie können die strenge Prüfung aktivieren, wenn Sie alle Zertifikate getauscht haben oder die bestehenden Zertifikate in das Feld "altSecurityIdentities" der jeweiligen AD-Objekts hinterlegt haben.

Windows Registry Editor Version 5.00

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

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

Das Update aktiviert aber auch ein Eventlog, über welches Sie die Clients und Anwender ausfindig machen können, die noch mit so einem alten Zertifikat unterwegs sind. Suchen Sie im System-Eventlog der Domaincontroller nach EventIDs 37 des "Kerberos-Key-Distribution Center".

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

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)]]"

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

  • ... prüfen, 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.
  • ... bereits ausgestellte Zertifikate prüfen
    Nach dem Update ausgestellte Zertifikate sollten die SID enthalten, und früher bisher ausgestellten Zertifikate müssen ersetzt werden, wenn Sie nicht "Plan B" nutzen.
  • Plan B: "altSecurityIdentities"
    Alternativ können Sie die bisher genutzten Zertifikate auch im Feld "altSecurityIdentities" des AD-Objekts importieren. Hier schaut der Domaincontroller auch nach, um einen "Match" zu erhalten.
  • Enforcement rechtzeitig vor der Deadline aktivieren
    Dann können Sie selbst bei unbekannten Problemen das Enforcement temporär wieder abschalten, nacharbeiten und erneut testen.

Bonus 1: 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.

Weckruf 2: CVE-2022-37967 PAC Signing

Wenn wir gerade dabei sind, habe ich noch einen weiteren CVE-Fix, der im Laufe von 2023 scharf geschaltet wird. Mit der Installation der Nov 2022 Security Updates wurde dieser Code eingebaut, um die Sicherheit von Kerberos-Tickets durch die Signierung des "Privilege Attribute Certificate (PAC)" zu verbessern.

The November 8, 2022 Windows updates address security bypass and elevation of privilege vulnerabilities with Privilege Attribute Certificate (PAC) signatures. This security update addresses Kerberos vulnerabilities where an attacker could digitally alter PAC signatures, raising their privileges.
Quelle: https://support.microsoft.com/en-gb/topic/kb5020805-how-to-manage-kerberos-protocol-changes-related-to-cve-2022-37967-997e9acc-67c5-48e1-8d0d-190269bf4efb

Auch hier erfolgt der Rollout in mehrere Phasen und sie sind erst sicher, wenn am 11. Jul das "Enforce" aktiviert wird.

Datum Aktion

8. Nov 2022

Installation der Security Updates addiert die Funktion ,so dass PAC Signing genutzt aber nicht erzwungen wird. Sollte dies schon stören, können Sie die Signaturen über folgenden RegKey noch deaktivieren. Der Standardwert ist 1 für "Add Signature, but not verify"

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\kdc]
"KrbtgtFullPacSignature"=dword:00000000

Auch das Auditing ist noch nicht angeschaltet, da sonst alle noch nicht aktualisierten Clients eine Meldung generieren würde. Das könnten Sie aber aktivieren:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\kdc]
"KrbtgtFullPacSignature"=dword:00000002

Die Aktivierung des Auditing aktiviert auch immer die Signierung mit. Sonst gäbe es ja nichts zu vermelden.

13. Dez 202

Nun sollten alle Clients aktualisiert sein und das Update aktiviert die "Audit"-Funktion, Nun finden sie Fehler im Audit-Log, wenn es noch Clients gibt, die ohne PAC-Signierung arbeiten.

11. April 2023

Die Option die Signaturen über den RegKey "KrbtgtFullPacSignature=0" abzuschalten wird deaktiviert. Ab jetzt wird immer signiert. Wer bis dahin die Server-Systeme mit Problemen aufgrund von "Full PAC Signature" nicht angepasst hat, kann darauf nicht mehr zugreifen.

11. Jul 2023

An dem Tag soll die Signierung per Default auch geprüft (enforce) und die Anforderung bei einem Fehler als ungültig verworfen werden. Nun kommen Clients nicht mehr an die Server, wenn die "Full PAC Signature" fehlt. Sie können aber noch diesen Zwang für einige Wochen abschalten:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\kdc]
"KrbtgtFullPacSignature"=dword:00000002

10. Okt 2023

Nun fällt auch die Abschaltoption weg. Alle Clients signieren und die Server erzwingen PAC Signatur, was dem Wert "KrbtgtFullPacSignature"=dword:00000003" entspricht.

Auf der einen Seite ist dies ein fixer Zeitplan, der speziell Firmen mit inkompatiblen Geräten in Zeitnot bringen kann. Auf der anderen Seite sind ihre Systeme erst ab dem 11. Jul 2023 ihr System wirklich abgesichert, wenn Sie nicht schon vorher per Konfiguration die strenge Prüfung vorziehen. Sie sollten aber auf jeden Fall das Eventlog überwachen:

Eventlog

Type

Source

EventID

Bedeutung

System

Warning

Kdcsvc

43

Die Überprüfung der "Full PAC Signature" ist fehlgeschlagen, d.h. der DC/Server/Client scheint das noch nicht richtig zu senden und wird ab dem 10 Okt 2023 ein Problem bekommen.

System

Warning

Kdcsvc

44

Das Ticket enthält noch keine "Full PAC Signature", d.h. der DC/Server/Client scheint das noch nicht zu senden und wird ab dem 10 Okt 2023 ein Problem bekommen.

In beiden Fällen sollten sie prüfen, warum das Ticket keine gültige "Full PAC Signature" enthält. Wenn Sie keine Events auf aktualisierten DC finden, dann können und sollten Sie schon vorher die KrbtgtFullPacSignature erzwingen, denn bis zum 10 Okt 2023 noch könnten Sie es auch wieder abschalten.

Weckruf 3: CVE-2022-38023 RPC Sealing

Zeitgleich zum PAC-Signing mit Kerberos hat Microsoft auch eine Härtung für eine vergleichbare Lücke bei RPC vorbereitet. Die Windows Domain Controller werden in ansehbarer Zeit ein RPC Sealing erfordern und nicht mehr nur einem RPC Signing vertrauen. Aber auch diese Änderung kann Microsoft nicht einfach umsetzen, da die Installation der Updates auf allen Servern und Clients abgeschlossen sein muss. Daher sind auch hier Stufen geplant und Microsoft den Zeitplan vor. Wer also nichts macht, wird am Ende "sicher" sein aber inkompatible Dienste sind dann auch "sicher" abgehängt.

Datum Aktion

8. Nov 2022

Installation der Security Updates sorgt dafür, dass RPC Sealing immer genutzt wird.

Sollte es Probleme geben, können Sie über den Registrierungsschlüssel "RequireSeal=0" das Sealing temporär deaktivieren.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters]
„RequireSeal"=dword:00000000

11. Apr 2023

Geplant ist, das durch das April 2023 Update die Akzeptanz von "RequireSeal=0" entfernt wird. Der Wert kann dann also nur noch 1 oder 2 sein

11. Jul 2023

In dem Security Updates will dann auch die Möglichkeit entfallen, dass Sie mit "RequireSeal=1" den Kompatibilitätsmode betreiben können.

Die meisten Firmen mit reinen Windows Umgebungen und ohne Trusts zu anderen Systemen werden von der Umstellung vermutlich gar nichts mitbekommen. Für komplexere Umgebungen sollten Sie aber die bereitgestellten Eventlogs prüfen, die auf Client ohne RPC Sealing hinweisen. Sie sollten diese Events im SystemEventlog finden:

Eventlog

Type

Source

EventID

Bedeutung

System

Error

Netlogon

5838

Der Client nutzt noch RPC Signing anstatt RPC Sealing

System

Error

Netlogon

5839

Der Client nutzt noch RC4

System

Error

Netlogon

5841

Der Client nutzt noch RC4, weil "RejectMD5Clients=True"

Wohl dem, der heute schon zumindest die Eventlogs der Server zentralisiert und über Queries einfach abfragen kann.

Meine Empfehlung: Prüfen Sie das Eventlog, lösen Sie die Warnungen auf und erzwingen Sie "RPC Sealing" schon ehe es Microsoft für sie machen. Sie sind früher abgesichert und könnten noch zurück

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters]
„RequireSeal"=dword:00000002

Bonus 2:Kerberos RC4/DES Abschaltung

Ich habe den Abschnitt in deutlich erweiterter Form auf eine eigene Seite ausgelagert:

Weitere Links