[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.
Genau, XP Rechner raus aus dem AD, rein in eine FreeIPA Domäne (die exklusiv nur in der Industrial Zone verfügbar ist), SFTP Server in eine iDMZ (i für industrial), die XP Rechner holen sich die Daten via SFTP script und Scheduled Tasks. Der XP Rechner darf nicht in der Office Zone kommunizieren und schon gar nicht dürfen Office Zone Clients auf den XP Rechner zugreifen.
Hört sich danach an, dass dringend ein Dienstleister gebraucht wird der da Mal aufräumt in Richtung Industrial security.
Stichwort: Netzwerksegmentierung, Purdue Model, ICS security
In einem Großteil der Automatisierungstechnik läuft XP auf Siemens Touchpanels nur als Bedienpanel (HDI)
Die Systeme sind, wenn überhaupt, nur über einem separaten VPN zu erreichen.
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/
Ja wie lange die Karten halten macht mir auch sorgen, aber USB sticks trau ich noch weniger als Marken Karten for Kameraprofis.
Ich denke ich rüste das jetzt da es die Pi5 mit PCIe gibt gleich auf NVME SSD's die sind auch schön billig aber sollten doch richtig lange halten.
vLANs kenne ich aber irgendwie ist eine eigene NIC einfach deppensicherer, und eine 2te USB NIC kostet ja fast nix.
es gäbe da auch noch Industrial SD Cards, sind aber massiv teuer. Bei meinen Raspi Thin Clients habe ich mir angeschaut, wo ich überall unnötige Schreibvorgänge reduzieren kann um die "Alterung" der SD Cards zu reduzieren.
Tja, das Problem ist: Die meisten Firmen gehen davon aus, dass ihr Dienstleister oder Mitarbeiter gute Arbeit macht. Es ist schlicht nicht IHR Business. Also auch schwierig zu beurteilen. Ausbaden müssen Sie es dann trotzdem. Bis vor wenigen Jahren war das gelinde gesagt total egal, weil die Maschinen nicht im Netz eingebunden waren. Die Lernphase hat gerade erst begonnen!
Ein Bekannter hat z.B. gerade eine E-Mail von einer fähigen Sicherheits-Firma bekommen, dass sie die Zusammenarbeit einstellen weil die Firma zu klein sei und sie nur noch grössere bedienen aufgrund Fachkräftemangel. DAS ist die Realität. Für uns IT'ler ist es immer einfach mit dem Finger auf solche Betriebe zu zeigen die mangelhafte Konzepte haben. Aber ein eher kleienr Betrieb bekommt die Leute mit Erfahrungen schlichtweg nicht.
Der Spruch von wegen kein Mitleid und sollen sie Schaden nehmen geht mir daher immer wieder so richtig auf die Eier, nicht nur weil man grundsätzlich generell niemandem etwas schlechtes wünscht!
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.
"… Kommt das Ende für Windows XP im April 2025? …"
Microsoft lässt das gut funktionierende Betriebssystem Windows XP bereits im April 2025 im Stich? Wer Windows XP im Stich lässt, der lässt auch seine treuen Kunden im Stich.
Bußgelder, Bußgelder, Bußgelder
gegen Microsoft selbstverständlich
Aus der Hüfte geschossen würde ich sagen:
In die Netzwerkzone, wo die XP-Maschinensteuerungen liegen (die sollten ja nun wirklich in einem GUT abgeblocktem Bereich abgeschottet sein), einen Read-Only Domänencontroller aktueller Version reinsetzen, der das Enforcement-Update nicht bekommt. Und NUR der Rechner darf sich dann mit einem anderen DC verbinden und das AD aktuall halten.
Dateitransfer ähnlich: Eine Freigabe auf dem Read-Only DC für die XPs, die sich per DFS mit dem 'normalem' Bereich syncronisiert. Damit sollte man auf Netzwerkebene sauber sein, muss aber sicherstellen, dass man sich nicht per Datei was in den XP-Bereich einschleppt… Ich vermute aber mal, da schreiben die Steuerungen einfach nur Logs hin, die man dann am normalem Arbeitsplatz anschauen möchte. Da könnte man den Share-Partner im normalen Netz read-only machen, dann können die normalen User nix reinstellen und somit auch jnix einschleppen.