RPC Sealing

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

Was ist RPC Sealing?

Das Protokoll RPC kommt an sehr vielen Stellen vor. Es wurde ursprünglich sogar von Xeros entwickelt, von SUN intensiv genutzt und von verschiedenen Herstellern adaptiert. Da auch bei TCP/IP ja maximal 65535 Zielports zu Verfügung stehen, wurde ein alternativer Weg gesucht. Bei RPC verbindet sich der Client über Port 135/TCP (Portmapper) um den Port zu erfahren, hinter dem sich der gewünschte Dienst befindet. Die Windows Admins kennen das aus NETLOGON, EVENTLOG, SERVICE, MSExchangeIS, MSExchangeDS und andere Dienste.

Die Herausforderung bei RPC ist natürlich auch hier die Sicherheit des RPC-Protokolls selbst, die Authentifizierung und Verschlüsselung und für Firewalls die ggfls. dynamischen Port, wenn der Administrator diese nicht festzurren kann. Ende 2022 ist auch hier eine Lücke von Microsoft behandelt worden:

Angreifer konnten auch hier über das NETLOGON-Protokoll mit veränderten Paketen einen Angriff ausführen und mehr Berechtigungen erlangen. Microsoft sichert die Domain Controller bzw. das "NETLOGON"-Protokoll dadurch ab, dass die RPC-Paket nun zwingend signiert werden müssen und damit nicht mehr unbemerkt geändert werden können.

Timeline

Diese Umstellung kann aber nicht zu einem Zeitpunkt erfolgen, denn zuerst müssen wieder alle beteiligten Systeme entsprechend aktualisiert wurden. Ehe ein Domain Controller die Signierung erzwingt und prüft, muss ja erst einmal sichergestellt, sein, dass alle Clients die NETLOGON-Anfragen signiert. Daher gibt es hier auch eine zeitlich gestaffelte Einführung:

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

Das bedeutet aber auch hier, dass erst nach dem 11 Juli die Lücke gestopft ist, wenn Sie nicht schon vorher die Erzwingung manuell aktivieren.

Details

Die Aktivierung der verschiedenen Einstellungen ist natürlich abhängig von der Installation der Security Updates. Analog zu PAC Signing mit Kerberos können Sie aber auch bei RPC Sealing über die Registrierung das Verhalten zumindest temporär steuern.

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

Wenn Sie RequireSeal so abschalten, dann werden Sie aber auch im Eventlog keine Protokollierung sehen.

Dies ist also wirklich nur ein "Quickfix", wenn ein kritisches System nach dem Nov 2022 Update nicht funktioniert und Sie Zeit gewinnen müssen.

11. Apr 2023

Durch das April 2023 Update wird die Deaktivierung von RPC Sealing über den Registrierungsschlüssel "RequireSeal=0" entfernt. Der neue Default Wert ist dann "Kompatibilitätsmode".

Windows Registry Editor Version 5.00

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

Clients müssen nun noch kein RPC Sealing nutzen aber die Domain Controller untereinander schon. Jetzt werden Trusts brechen, wenn ein DC kein "RPC Sealing" kann.

13. Jun 2023

Ab dem Update ist der Default ein "RequireSeal = 2" aber sie können es immer noch auf "1" zurückstellen, wenn etwas bricht.

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. Ab jetzt ist der "Enforce"-Mode aktiv und nicht deaktivierbar.

Das bedeute aber auch hier, dass der Schutz gegen die im Herbst 2022 entdeckte Lücke erst im Juli 2023 aktiv ist, wenn Sie nicht vorher schon manuell den "Enforce-Mode" einschalten.

Tipp:
Sie sollten auf den DCs so früh wie möglich "RequireSeal" auf "2" stellen und prüfen, welche Systeme nicht mehr funktionieren, ehe die Einstellung nach dem 11. Jul 2023 irreversibel aktiv wird.

Eventlog

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 Netlogon-Dienst hat einen Client gefunden, der RPC-Signatur anstelle einer RPC-Versiegelung verwendet.

System

Error

Netlogon

5839

Der Netlogon-Dienst hat eine Vertrauensstellung gefunden, die RPC-Signatur anstelle von RPC-Versiegelung verwendet hat.

System

Errror

Netlogon

5840

Der Netlogon-Dienst hat einen sicheren Kanal mit einem Client mit RC4 erstellt.

System

Error

Netlogon

5841

Der Netlogon-Dienst hat einen Client mit RC4 aufgrund der Einstellung "RejectMd5Clients" abgelehnt.

Wohl dem, der heute schon zumindest die Eventlogs der Server zentralisiert und über Queries einfach abfragen kann. Hier ein Beispiel eines Windows XP Clients, der kein AES kann.

Ein 5840-Fehler ist nicht zwingend kritisch, zumindest sie keine Kerberos RC4 Abschaltung vorhaben. Dennoch sollten Sie die Meldungen betrachten, denn mit den Updates von Nov 2022 (Siehe Windows Security Changes 2023) wurde AES als neuer Default eingerichtet und das kann dazu führen, dass z.B. ein Windows XP Client, der nur RC4 kann, zwar weiter mit einem neueren Windows Server kommunizieren kann, der neben AES auch RC$ versteht. Wenn Sie aber vom Server dann z.B. auf eine Freigabe des Windows XP-Systems zu greifen wollen, dann versteh der XP-Client nicht das AES-codierte KerberosToken.

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

Weitere Links