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 (veraltet. Inhalt auf drei weitere Seiten aufgeteilt)
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.

Es gab auch schon früher solche Updates mit "Zeitzünder", z.B.

Im Jahr 2023 weiß von folgenden kritischen Updates, die im Laufe des Jahres erst ihre Wirkung entfalten.

  • CVE-2022-34691 Strenge Prüfung von Zertifikaten bei der Anmeldung
    Cert Logon Unsicherheit (KB5014754)
    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 erst auf 14. Nov 23 und mittlerweile auf Feb 2024 verzögert.
  • CVE-2022-37967 PAC Signing
    PAC Signing mit Kerberos
    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
    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:


Am 8.5 wurde im Microsoft 365 Tenant Message Center unter MC552226 noch einmal darauf hingewiesen:

Die Zeitachse für CVE-2022-38023 wurde geändert. Ab 11. Apr 2023 ist nun nur das Logging aktiv und erst am 13. Jun 2023 wird RPCSealing aktiviert und kann bis 11. Jul 23 temporär deaktiviert werden
https://support.microsoft.com/de-de/topic/kb5021130-so-verwalten-sie-die-netlogon-protokoll%C3%A4nderungen-im-zusammenhang-mit-cve-2022-38023-46ea3067-3989-4d40-963c-680fd9e8ee25

Alle zukünftigen Termine können von Microsoft auch wieder verschoben werden und einige wurden schon verschoben.

Zeitpunkt Netlogon RPCSeal
KB5021130
CVE-2022-38023		 CertBasedAuth
KB5014754 		Kerberos PAC Signatures
KB5020805
CVE-2022-37967		 KB5008383

Nov 21

 

Update verteilt

 

Update verteilt. Protokoll im Eventlog

Mai 22

 

Update verteilt

 

 

Nov 22

Update verteilt

 

Update verteilt, Signierung Default:ON

 

Dez 23

 

 

Logging nicht signierter Anfragen

 

Apr 23

Phase2: Compatibility

Phase2: Deaktivierung entfällt

 

 

Jun 23

Phase3: Enforce aber auf Compat setzbar

 

Phase3: Signature aktiv aber nicht verifiziert

 

Jul 23

Phase4: Enforce

 

Phase4: Verifizierung erzwungen aber abschaltbar

 

Okt 23

 

 

Phase5: Verifizierung erzwungen

 

Nov 23

 

Phase3: Enforce

 

 

Jan 24

 

 

 

Enforve

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 (Kerberos RC4 Abschaltung, RC4 - Nein Danke)
    Seit Windows 2008/Vista ist AES128/AES256 möglich und mittlerweile sollte jeder auf RC4 verzichten können. Ich erwarte, dass Microsoft RC4 bald deaktiviert, 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

Der Inhalte wurde mittlerweile in eine eigene Seite ausgelagert

Siehe dazu Cert Logon Unsicherheit (KB5014754)

Weckruf 2: CVE-2022-37967 PAC Signing

Der Inhalte wurde mittlerweile in eine eigene Seite ausgelagert.

Das Enforcement von CVE-202237967 am 11. April wurde auf 13. Jun 2023 verschoben. Siehe Office 365 Message Center Post MC541054 "Changes to the deployment phase for CVE-2022-37967"
https://admin.microsoft.com/AdminPortal/home?#/MessageCenter/:/messages/MC541054

Siehe dazu die eigene Seite PAC Signing

Weckruf 3: CVE-2022-38023 RPC Sealing

Der Inhalte wurde mittlerweile in eine eigene Seite ausgelagert

Die Timelime für CVE-2022-38023 wurde geändert. Ab 11. Apr 2023 ist nun nur das Logging aktiv und erst am 13. Jun 2023 wird RPCSealing aktiviert und kann bis 11. Jul 23 temporär deaktiviert werden
https://support.microsoft.com/de-de/topic/kb5021130-so-verwalten-sie-die-netlogon-protokoll%C3%A4nderungen-im-zusammenhang-mit-cve-2022-38023-46ea3067-3989-4d40-963c-680fd9e8ee25

Siehe dazu die eigene Seite RPC Sealing

Weckruf 4: CVE-2021-42291 AD dSHeuristics

Der Inhalte wurde mittlerweile in eine eigene Seite ausgelagert.

Siehe dazu die eigene Seite AD dsHeuristics

Enforcement aktivieren

Wenn Sie die drei ersten Optionen vorzeitig auf "sicher" stellen wollen, dann können Sie die folgende Reg-Datei importieren:

Achtung: KrbtgtFullPacSignature=2 erfordert den Forest functional Level Windows 2012+, damit das KRBGT-Konto auch AES nutzt.

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

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

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

Die aktiviert PAC Signing und RPC-Sealing auf Enforce und schaltet die Akzeptanz von Zertifikaten ohne SID ab.

KB5004442 - CVE-2021-26414

Eine Lücke, die laut CVE den Status "Exploitation Less Likely" hat und noch nicht ausgenutzt wird, wurde ebenfalls durch dein Updates vorbereitet aber wird erst im Jahr 2022 und 2023 letztlich wirksam.

08. Jun 2021  Bereitstellung des Update
14. Jun 2022  Aktualisiertes Update, damit ein Admin das Enforcement per RegKey "RequireIntegrityActivationAuthenticationLevel " aktivieren kann
08. Nov 2022  Ab nun fordert der Client "RPC_C_AUTHN_LEVEL_PKT_INTEGRITY" für anonyme Requests an
              HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\AppCompat\RequireIntegrityActivationAuthenticationLevel:Dword=0x00000001
14. Mrz 2023  DCOM Hardening wird aktiviert und kann nicht mehr deaktiviert werden

Dieses Fix dürfte auch von den meisten Administratoren unbemerkt erfolgt sein.

Einschätzung

Als ich diese Beschreibung erstellt habe, war es Februar 2023, d.h. der MAi2022-Patch war sicher verteilte aber noch nicht aktiv und die November 2022 Updates haben nur den Wechsel von RC4 auf AES für Kerberos Tickets mitgebracht. Bis auf ein paar Blog-Artikel im Internet über Störungen hat man davon aber nicht viel gehört. Ist das Thema denn so kritisch?

Wenn alle Firmen aktuelle unterstützte und aktualisierte Betriebssysteme einsetzen, dann sollte es auch tatsächlich keine Probleme geben. Es sind ja immer die Sonderfälle, Ausnahmen, Altlasten, die bei Störungen aber dann gleich richtig weh tun können. Insbesondere wenn es nicht um den Schreibtischrechner mit Office sondern um Produktionssteuerungen in Betrieben geht.

Leider habe ich im November 2022 bei einigen Firmen genau hier haushelfen dürfen und auch im Januar/Februar gab es gleich mehrere Anrufe, Kontakte und Meetings mit aktueller Hilfe aber vor allem auch Risikoabschätzungen, was denn passieren könnte. Sonst hätte ich diese und ein paar andere Seiten (Siehe Alte Clients und Altclient Windows 2008 aber auch TLS 1.2 Enforcement, RPC Sealing, PAC Signing und Kerberos RC4 Abschaltung wohl nicht geschrieben.

Die phasenweise Einführung neuer Standardwerte kann ich z.B. für das Mai 2022 Update verstehen. Hier wird zuerst die PKI angepasst und nach einem Jahr sollten alle Clients im Rahmen eines AutoRollout durch die Windows PKI dann neue Zertifikate haben, ehe dann der unsicherere Weg abgeschaltet wird. Das geht bei ganz vielen gut und wer eine eigene PKI betreibt, kann sich ja behelfen, wenn er es weiß. Auch die Meldungen im Eventlog geben frühzeitig hinweise, wenn Sie denn überwacht werden.

Auf der anderen Seite hätte ich aber Änderungen wie „AES als neuer Default“, RPC Sealing, PAC Signing mit einem Patchtag vorbereitet und im nächsten Monate direkt aktiviert, damit ein Großteil der Kunden "sicher" ist. Als Hilfe für die Administratoren, die es nicht besser gewusst haben, hätte ich einfach auf den Desktop eine Textdatei mit Hinweisen zum Reaktivierten der unsicheren Einstellungen gelegt. Aktuell hat Microsoft leider keinen „gesicherten Kommunikationskanal“ zu den Administratoren der Welt, um sie zu informieren. Für den Mai 2022-Patch hat Microsoft zumindest das Microsoft 365 Message-Center genutzt.

Da dem aber nicht so ist, werden wir wohl in 2023 noch die ein oder andere Überraschung durch schrittweise Änderungen der Standards erleben.

Weitere Links