[English]Microsoft hat im April 2024 ein Update für die Schwachstellen CVE-2024-26248 und CVE-2024-29056 im Kerberos-Protokoll veröffentlicht. Im April 2025 soll die Absicherung zwangsweise aktiviert werden. Das schlägt auf ältere Betriebssysteme wie Windows XP durch, die keine Updates mehr bekommen, aber in Maschinensteuerungen verwendet werden. Es dürfte dann kein Zugriff auf das Active Directory mehr funktionieren, sobald die Domain Controller gepatcht und der Enforcement-Modus aktiviert wird.
Anzeige
Die Kerberos PAC-Schwachstellen
Im Kerberos-Protokoll wurden im Frühjahr 2024 Schwachstellen bekannt, die eine Erhöhung von Berechtigungen mit dem Kerberos PAC Validation Protocol ermöglichen. Mit den April 2024-Updates hat Microsoft auch am Privilege Attribute Certificate (PAC) Änderungen vorgenommen, um auf die Schwachstellen CVE-2024-26248 und CVE-2024-29056 zu reagieren. Das Privilege Attribute Certificate (PAC) ist eine Erweiterung der Kerberos-Diensttickets. Es enthält Informationen über den authentifizierenden Benutzer und seine Berechtigungen.
Microsoft hat im April 2024 dazu den Support-Beitrag KB5037754: How to manage PAC Validation changes related to CVE-2024-26248 and CVE-2024-29056 veröffentlicht. Mit den Updates vom 9. April 2024 werden die Schwachstellen aber nicht vollständig geschlossen. Dieser Schritt 1 bereitet Windows aber auf das Schließen der Schwachstellen vor. Im Support-Beitrag hat Microsoft entsprechende Hinweise für Administratoren hinterlassen, dass Windows-Domänencontroller und Windows-Clients mit einem Windows-Sicherheitsupdate aktualisiert werden müssen, das am oder nach dem 9. April 2024 veröffentlicht wurde.
Erst der Enforcement Modus schließt Schwachstellen
Um die Schwachstellen für alle Geräte vollständig zu entschärfen, müssen Administratoren den Enforcement Modus (erzwungener Modus) im Anschluss an die Update-Installation aktivieren. Wie das manuell geht, ist im Support-Beitrag beschrieben. Aber Microsoft beginnt 2025 mit dem Erzwingen der Absicherung.
Ab Januar 2025 aktivieren die Sicherheitsupdates bei allen Windows-Domänencontrollern und Clients den Enforcement Modus, in dem standardmäßig ein sicheres Verhalten für PAC erzwungen wird.
Anzeige
Diese Verhaltensänderung erfolgt, nachdem das Update die Registrierungsunterschlüssel-Einstellungen auf PacSignatureValidationLevel=3 und CrossDomainFilteringLevel=4 geändert hat. Der Enforcement Modus kann aber von einem Administrator noch außer Kraft gesetzt werden, um zum Kompatibilitätsmodus zurückzukehren. Die Details zu den entsprechenden Registrierungseinstellungen sind im oben verlinkten Microsoft Support-Beitrag beschrieben.
Die Windows-Sicherheitsupdates, die ab April 2025 veröffentlicht werden, entfernen die Unterstützung für den Kompatibilitätsmodus über die Registrierungsunterschlüssel PacSignatureValidationLevel und CrossDomainFilteringLevel und erzwingen das neue Sicherheitsverhalten. Nach der Installation des Updates vom April 2025 gibt es keine Unterstützung für den Kompatibilitätsmodus mehr.
Microsoft weist auf Probleme hin
Microsoft weist im Support-Beitrag darauf hin, dass potenziell Probleme mit der PAC-Härtung auftreten können. Dazu gehören beispielsweise die PAC-Validierung und Cross-Forest-Filterungsfehler. Daher enthielt das Sicherheitsupdate vom 9. April 2024 die oben beschriebene Fallback-Logik und Registrierungseinstellungen für den Kompatibilitätsmodus, um diese Probleme zu entschärfen.
Microsoft hat im Supportbeitrag zudem den Hinweis gegeben, dass Administratoren die Protokolle der Ereignisanzeige anschauen sollen. Denn auf dem Kerberos-Server, der die eingehende Kerberos-Authentifizierung akzeptiert, können Kerberos-Audit-Ereignisse erzeugt werden. Dieser Kerberos-Server führt die PAC-Validierung durch, die den neuen Netzwerkticket-Anmeldefluss verwendet.
Ich hatte im Blog-Beitrag Probleme mit Remote-Unterstützung nach April 2024-Update (PAC-Änderungen, KB5037754) auf entsprechende Probleme bei der Remote-Unterstützung hingewiesen.
Problem: Windows XP in Maschinensteuerungen
Blog-Leser Andy M. hatte mich bereits Mitte Oktober 2024 per Mail kontaktiert, weil das obige Thema ihm auf den Nägeln brennt. Er meinte dazu, dass sie im Unternehmen "letzte Woche" die Info bekommen haben, dass im April 2024 eine Lücke im Kerberos-Protokoll gepatcht wurde, aber nicht zwingend aktiv ist. Diese soll aber im April 2025 zwangsaktiviert werden – also genau das Szenario, das ich oben skizziert habe.
Von Kollegen anderer Firmen wurden die Administratoren im Umfeld des Lesers dann auf einen Gesichtspunkt hingewiesen, der massive Auswirkungen hat: Geräte, die noch mit Windows XP ausgestattet sind, sollen ab spätestens April 2025 nicht mehr funktionieren, nachdem der Enforcement Modus mit dem betreffenden Update zum April 2025-Patchday auf den Domain Controllern aktiviert wird.
Denn dann können die Clients nicht mehr über das Kerberos-Protokoll mit einem gepatchten Active Directory-Server kommunizieren (die Kerberos PAC-Validierung scheitert). Da lässt sich imho auch nichts machen, da für Windows XP die PAC-Patches nicht mehr bereitgestellt werden.
Der Leser schrieb, dass auch andere (ältere) Betriebssysteme, denen gewisse Patch-Level fehlen, dann nicht mehr funktionieren, sofern sie mit einem gepatchten Active Directory (AD) kommunizieren müssen.
Die Frage, die den Leser umtreibt: Ist die obige Annahme, dass Windows XP-Geräte ab April 2025 von der Kerberos-Authentifizierung am Active Directory ausgesperrt sind, zutreffend und was funktioniert dann nicht mehr?
Dazu schrieb der Leser: "Da wir leider immer noch gewisse XP-Clients im Einsatz haben (Maschinen in der Produktion – Ablösung nur durch sehr hohe Kosten möglich), haben wir vermutlich das Thema dass hier die Windows XP Clients und ggfs. auch Windows 7 aus dem Raster fliegt. Leider findet man nicht all zu viel über die Auswirkungen: Was funktioniert danach alles nicht mehr bei einem älteren Client? Findet die Kommunikation dann anstatt per Kerberos dann via NTLM statt? Ist das Lesen des Netlogon-Shares wenigstens noch möglich? "
In einer Ergänzungsmail von gestern schreibt er, dass die Administratoren in ihrer Umgebung die benötigten Registrierungseinträge gesetzt haben, um Eventlog-Einträge von der Kerberos-PAC-Authentifizierung zu bekommen. Es werden jedoch werden keine Einträge geschrieben.
Der Leser zieht den Schluss, dass danach keine entsprechenden Clients, die die Kerberos-PAC-Validierung nicht bestehen, existieren. Das kann eigentlich nicht sein, da er sich 100 % sicher ist, dass solche Clients im Netzwerk vorhanden und am Active Directory angebunden sind. Er meint, dass der Registrierungseintrag für das Eventlog nicht korrekt umgesetzt wird. Möglicherweise liegt es aber auch daran, dass der Enforcement Modus noch nicht aktiviert ist.
Ich gebe die Fragen des Lesers "Ist das Thema schon mal angesprochen worden und stehen auch andere vor dem Problem?" damit an die Leserschaft des Blogs weiter.
Ähnliche Artikel:
Microsoft Security Update Summary (9. April 2024)
Patchday: Windows 10-Updates (9. April 2024)
Patchday: Windows 11/Server 2022-Updates (9. April 2024)
Windows Server 2012 / R2 und Windows 7 (9. April 2024)
Windows Server: April 2024-Updates stören NTLM-Authentifizierung
Probleme mit Remote-Unterstützung nach April 2024-Update (PAC-Änderungen, KB5037754)
Anzeige
Es war und bleibt eine dumme Idee Maschinensteuerung in AD Domänen aufzunehmen. Insofern: kein Mitleid.
Und wenn die Maschine nicht im AD ist – funktioniert dann der Zugriff weiterhin auf ein Share eines Fileserver, welcher im AD ist? Oder muss man dann auf dem Fileserver ein lokales Konto für die Maschine erstellen und sich mit diesem Konto anmelden? Plattenfräsen, CNC-Bearbeitungscenter usf. holen ja im allgemeinen die NC-Programme, Kanterbilder usf. von einem Share. Das pushen der Datein vom Fileserver zur Maschine ist eher unüblich, weil die Maschine ja ausgeschaltet sein könnte.
Ich würde einen SFTP-Server (Linux Rolling Release damit man das regelmäßig aktualisieren kann ohne sich mit Releasesprüngen herumzuschlagen, autopatch) vorschlagen, der von beiden Seiten erreichbar ist. Die XP-Maschinen aus dem AD raus, vielleicht in ein eigenes AD mit einem final gepatchten Server 2012R2 als DC und alles in ein eigenes DMZ verschieben.
Das Anbinden von Maschinen-Steuerungen ist immer wieder ein Thema. Es gibt da eine Firma, die sich darauf spezialisiert hat in den vergangenen 20 Jahren.
Diese garantiert eine aus IT-Security Sicht sichere Lösung. Wir nutzen die Lösung auf fast allen Maschinen. Soll also keine Werbung sein, aber Hilfe für Kollegen, die vor diesem Problem stehen.
Google mal nach RWT München.
Ich als Admin bin überzeugt von der Lösung, die wir schon seit Jahren im Einsatz haben.
Die Software ist direkt in der Steuerung integriert und übernimmt die Kommunikation und Übertragung der Programme.
Wichtig: es läuft und macht keinen Ärger.
Schau auch mal bei den Referenzen. Viele Firmen setzen darauf.
Grüße
Oli
Einer meiner Kunden hat alte WinXP & Win7 Embedded sowie bis vor drei Jahren sogar noch NT4 für diverse Visus. Die Anlagen sind natürlich isoliert in jeweils eigenen vLANs und ohne Zugriffe auf irgendwas. Datenaustausch funktioniert via Robocopy Syncs einmal zu einem gehärteten und überwachten Linux Samba Host und von dort aus weiter von der anderen Seite auf einen im AD steckenden Fileserver, ebenfalls via Robocopy Sync aber Pull. Die Richtung ist immer in eine Seite, stets von den Anlagen ins AD, nicht umgekehrt. Die Techniker Notebooks zum programmieren der Anlagen mit der Siemens/Beckhoff Software sind komplett isoliert, WLAN per Bios deaktiviert.
Die OPC/BDE Daten laufen ebenfalls isoliert von den Windows Rechnern über eigene Segmente. Dafür wurden RS232/Ethernet Bridges an den Anlagen installiert, die dann über webbasierten REST APIs mit den jeweiligen Anwendungen reden können. Das passiert auf einigen virtuellen Linuxkisten. Ein interner Reverse-Proxy stellt dann die Brücke zum AD her.
Das wäre IMHO der Goldstandard. Mir ist ein anderes Unternehmen bekannt, das alles in einem Netzwerk hält, die Chefsekretärin greift quasi direkt via VNC auf die Anlage drauf um zu sehen, was gerade produziert wird. IT Security und sichere Konzepte haben keinen Stellenwert. "macht alles die Sophos/Fortinet Firewall" (oder was für Dreck denen von einem Systemhaus verkauft wurde) wird dann gesagt. Nun denn… da wünsche ich mir, dass diese schnell vom Markt weg-geransomwared werden und spüre keinen Mitleid.
Ich kann nur jedem raten, sein vergammeltes Windows Spielzeugs offline zu halten.
> Die OPC/BDE Daten laufen ebenfalls isoliert von den Windows Rechnern über eigene Segmente. Dafür wurden RS232/Ethernet Bridges an den Anlagen installiert, die dann über webbasierten REST APIs mit den jeweiligen Anwendungen reden können. Das passiert auf einigen virtuellen Linuxkisten. Ein interner Reverse-Proxy stellt dann die Brücke zum AD her.
>
Ja geil so ähnlich haben wir es in meinen labs and er uni mit diversen Geräten die noch XP haben, Oszi 2x, und ein Massen Spektrometer, auch gemacht.
Nur mit RasPI's Ethernet/Ethernet mit 2 NIC's die Geräte reden mit dem PI und können auf ein Folder auf der SD Karte zugreifen über eine NIC, und der RasPi sync den Folder dann mit einem samba Share über die andere. Wobei der sync normal nur SD Card -> Share geht will man von Share Daten auf die SD Karte muss man ein Knopf drücken für einmalige sync.
So können wir bequem Messdaten ablegen ohne das irgendwas aus dem LAN mit den alten Geräten direkt sprechen kann.
Top, freut mich:
Pro-Tip #1: Für die Uni ausreichend, in der Produktion willst Du nicht wirklich SD-Cards haben, die gehen IMHO alle paar Monate ex. Nimm da schon ein externes Medium für die Raspis.
Pro-Tip #2: Raspis verbaue ich nur noch mit POE Hats
Pro-Top #3: Ein Interface reicht aus, es muss nur sein Beinchen in zwei verschiedenen vLANs haben, Tagging heißt das Stichwort ;-)
Ansonsten sind Raspis in der Industrie schon echt geil, habe etliche der stromfressenden, riesigen und meist ungepatchten Windows-Dosen damit ersetzt:
https://blog.jakobs.systems/micro/20220511-ct-fachartikel-kiosk/
Maschinen, deren Betriebssystem seitens des Herstellers nicht aktuell gehalten werden will, hat im AD einfach nicht zu suchen.
Wie holt sich die Maschine denn aktuell die Dateien?
1. Authentifizierung (NTLM, Kerberos)
2. Übertragunsgprotokoll (FTP, SFTP, Samba SMB v1 v2 v3, HFS)
3. Verschlüsselung (SSL 2, SSL 3, TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3)
Ich vermute Kerberos, SMB 1.0, TLS 1.0.
Was fällt weg, was können alle Beteiligten hinterher immer noch?(Kerberos fällt weg).
Authentifizierung mit NTLM gilt als deprecated, ist aber in Windows Server 2025 immer noch enthalten und kann benutzt werden.
Zur Not schaltet man openSUSE Linux als Man-in-the-Middle Übersetzer dazwischen, das kann sich ins Active Directory einloggen und es kann der WinXP Maschine als Fileserver dienen (FTP, SFTP, Samba SMB).
Die Maschine muss selber gar nicht ins Active Directory und als Dateiserver ist Linux sowieso besser als Windows.
Windows XP kann maximal:
Übertragungs-Protokolle:
– SMB 1.0 (kein 2, kein 3)
– FTP (FileZilla)
– SFTP (WinSCP)
– HTTP File Server (HFS) nachrüstbar, Freeware
Verschlüsselung:
– SSL 2.0
– SSL 3.0
– TLS 1.0
– TLS 1.1 und TLS 1.2 mit Update KB4019276 (Windows Embedded POS Ready) und ein paar Registry-Einträgen
– kein TLS 1.3
Falls aktuell SMB 1.0 und TLS 1.0 benutzt werden, dann sollte man das auch mal ändern.
Bei uns sind die Maschinen-Rechner nicht direkt im AD, dazu gab es keine Notwendigkeit. Da ist mit meinem Kommentar weiter oben wohl ein Missverständis entstanden.
Im AD gibt es pro Maschine ein Benutzerkonto, dieses schränkt auch ein auf welche Rechner im AD zugegriffen werden darf. Die Credentials sind auf den Maschinen gespeichert NET USE … /SAVECRED. Pro Maschine ein Share auf dem Server, und maximal eingeschränkte NTFS-Rechte.
@Bolko: Da wird wohl oft SMB 1.0, TLS 1.0 laufen. Maschinenhersteller patchen nicht, und wenn man es selber macht, ist es nicht mehr supported.
Nehme aus den Kommentaren mit – die möglichst vollständige Isolierung der Maschinen muss das Ziel sein, nicht wie man den direkten Zugriff irgendwie noch hinbekommt. Danke für die verschiedenen Inputs dazu.
Noch eine – nicht ernst gemeinte Idee – zur Isolierung:
Industrieroboter pendelt mit USB-Stick zwischen Produktionsleitung und Maschinen hin und her
bringt Maschinenprogramme und holte BDE-Daten ab.
– Ziel Automtisierung: erreicht
– Ziel Digitalisierung: erreicht
– Ziel Isolierung: erreicht = "galvanische Trennnung" Fachgebiet Informatik.
Und der regelmässige, oft vernachlässigte Backup der Parameter-Dateien der Maschinen könnte er auch übernehmen.