Alte Clients Windows XP

Durch die Windows Security Changes 2023 hatten mich mehrere Kunden gefragt, was mit alten Clients passiert, die vielleicht mit Kerberos RC4 Abschaltung, RPC Sealing, PAC Signing mit Kerberos, SMB1 Abschaltung oder TLS 1.2 Enforcement ein Problem haben. Daher habe ich nicht nur den Alte Clients Windows 2008 sondern auch Windows XP getestet.

Diese Seite ist eine Momentaufnahme Feb 2023 und gibt keine Garantien. Der Betrieb von Systemen ohne Security Updates ist vielleicht nicht strafrechtlich relevant aber dennoch nicht empfohlen.

Selbst die C't hat in ihrer April 2023 Ausgabe geschrieben, dass Sie bei Messsystemen auch noch Windows XP nutzen sie befinden sich damit in guter Gesellschaft. XP siebst wurde ja Jahrelang mit Lücken genutzt, die aber bei Bekanntwerden auch gestopft wurden. Das ist heute nicht mehr so. Aber Sie können auch unsichere Systeme problemlos einsetzen, wenn Sie die Ausnutzung der Lücken anderweitig unterbunden haben, z.B. durch Separierung in eigene Netzwerke mit Filterung und kontrollierten Zugriffen.

Status Windows XP

Über Windows XP gibt es nicht mehr viel zu schreiben. Diese Seite besteht primäre dafür, um die Links zu sammeln, die neben dem Support-Ende auch beschreiben, warum Windows XP z.B.: mit Office 365 nicht mehr funktioniert.

Ich habe auch fast 10 Jahre mit Windows XP gearbeitet, habe Windows Vista übersprungen und mit Windows 7/10/11 immer brav aktualisiert.

After April 8, 2014, Microsoft will no longer provide security updates or technical support for Windows XP. Security updates patch vulnerabilities that may be exploited by malware and help keep Users and their data safer. PCs running Windows XP after April 8, 2014, should not be considered to be protected
Quelle: https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support

With regard to Office 365, Windows XP support will end on January 1, 2014.  Here is a link that discusses this as well: http://onlinehelp.microsoft.com/office365-enterprises/ff652534.aspx This means, that you have less than eight months to retire and/or upgrade these systems before support is no longer available for them.

DC: Windows 2016

Wie beim Alte Clients Windows 2008 habe ich auch hier einen nicht gerade neuesten Windows 2016 DC genutzt, der aber im Feb 2023 durchaus im Support war und wird mit Security Updates versehen wurde, wie ihn auch 2023 immer noch viele Firmen einsetzen. Der Server war einfach als Domain Controller installiert aber wurde zusätzlich abgesichert:

  • Windows Update Stand Jan 2023
    Der Server wurde über Windows Update mit allen Servicepacks und Security Updates versehen, die Microsoft bereit gestellt hat. Damit sind auch alle Änderungen implementiert, die insbesondere durch die Mai 2022 Updates (Anmeldung per Zertifikat) und November 2022 bereitgestellt wurden und durchaus zu den ein oder anderen Problemen geführt haben.

Allein die Updates sind es aber nicht, denn diverse Änderungen werden erst im Laufe des Jahres 2023 durch weitere Updates in Wellen aktiviert. Diese Einstellungen habe ich durch ein "Enforcement" vorgezogen.

  • RPC Sealing
    Der Windows 2016 DC erzwingt nun RPC Sealing
  • PAC Signing mit Kerberos
    Der Windows 2016 DC erzwingt PAC-Signing
  • SMB1 Abschaltung
    Auf dem Windows 2016DC ist kein SMB1 aktiv. Sowohl das Windows Feature als auch die Server Konfiguration wurden abgeschaltet

    Das dürfte zwar Windows 2003/XP/2000 blockieren, aber für die Tests mit Windows 7/2008 habe ich erst einmal darauf verzichtet.
  • TLS 1.2 Zwang
    Habe ich nicht umgesetzt. Hierzu gibt es aber genug Dokumentationen, welche Systeme TLS 1.2 unterstützen. Siehe auch TLS 1.2 Enforcement

Diese Einstellung entspricht aber eine hohen Sicherheit im Jahre 2023, der von Microsoft erst im Laufe von 2023 auf allen unterstützten Systemen erzwingt-

Client: Windows XP SP3

Aus meinem VM-Archiv habe ich eine Windows XP SP3 reaktiviert, der nur in einer Arbeitsgruppe war.

Leider kommt er natürlich nicht mehr an Windows Updates, denn der IE6 spricht kein TLS 1.2 (TLS 1.2 Enforcement), was seitens Microsoft aber mittlerweile erzwungen wird. Dazu müsste ich den IE8 nutzen. Der Patchstand war damit "Service Pack 3". Allerdings gibt es von Microsoft manchmal eine "Security Update DVD" und für Windows XP habe ich eine vom Februar 2010 gefunden.

February 2010 Security Release ISO Image
https://www.microsoft.com/en-us/download/details.aspx?id=8128

Windows XP kann eigentlich kein SMB 2.0. Aber ich bin später einmal gespannt, ob Updates etwas bringen. Zuerst habe ich aber mal den Windows XP SP3-Client durchgespielt: 

Schon die Probleme bei einer "Neuinstallation" nach einem Verlust sind ein Grund keine alten Systeme mehr zu nutzen

Natürlich habe ich dem Client den Windows 2016DC als DNS-Server gegeben und auch die Zeit wurde korrekt bezogen. Aber der Versucht ihn in die Domain aufzunehmen, ist kläglich gescheitert:

Das auf dem DC mitgeschnittene Protokoll zeigt gut, dass der Client bei Paket 1 noch vor jeglicher DNS-Anfrage erst mal per Subnetz-Broadcast auf 192.168.178.255 ein alter "SAM LOGON"-Request startet, auf die der DC im Paket 2 mit einem Fehler "user unknown" antwortet.

Das versucht der Client in Paket 3 und 6 noch mal mit der gleichen Antwort in 7. Der Server scheint auch nicht auf jedes Paket zu antworten. Es sind allesamt UDP-Pakete, so dass durchaus mal eins verloren gehen kann, ohne dass hier ein Retransmit erscheint.

Ich finde es schon erstaunlich, dass Windows 2016 überhaupt reagiert, wenn der Client nur LMNT und LM20 anbietet. Danach stellt der Windows XP Client in Paket 10 eine Anfrage mit seinem Computername als "User" aber immer noch LMNT und LM20, die vom Server im Paket 11 beantwortet wird um dann im Paket 12 eine Anfrage nach dem PDC zu stellen.

Das Paket 13 liefert dann für eine anonyme Anfrage schon durchaus umfangreiche Daten:

Allerdings scheint dies den Windows XP Client nicht zu überzeugen, denn er erfragt dann schon den DNS-Namen per DNS:

Der Client wechselt dann von 138/UDP auf 139/TCP (Paket 23/24) und startet einen NetBIOS Session Service (NBSS) der aber mit dem Negotiate in Paket 29 vom Server direkt im Paket 30 mit einem RESET beendet wird. Wer will es ihm verdenken, wenn er doch keinen der angebotenen Dialekte unterstützten will.

Es fehlt SMB2. Damit kann ich mich alle die anderen Tests wie "Kerberos", SMB Signing und Sealing, LDAP" und TLS 1.2 sparen.

Security Update DVD

Wir habe gesehen, dass Windows XP SP3 schon am SMB-Protokoll scheitert. Ich könnte nun natürlich SMB 1.0 auf dem Windows 2016 Server reaktivieren aber es gibt zu viele Gründe dies nicht zu tun und auf SMB1 Abschaltung habe ich weitere Informationen bereit gestellt.

Aber wenn sie im Internet nach Windows XP und SMB2 suchen, dann stoßen Sie auf eine "Security Update DVD" und für Windows XP habe ich eine vom Februar 2010 gefunden.

February 2010 Security Release ISO Image
https://www.microsoft.com/en-us/download/details.aspx?id=8128

In den kleineren ISO-Datei ist das Update KB978251 enthalten, welches ein SMB-Update mitbringen soll. Die große DVD enthält nur das Update KB978207 MS10-002: Cumulative security update for Internet Explorer. Das Update stopft Lücken im SMB-Client für Windows 2000, XP, Windows 2003, Windows Vista, Windows 7 und Windows 2008. Alles Systeme, die eigentlich nicht mehr supportet werden.

Leider gibt es keinen Installer, der einfach alle fehlenden Updates installiert. Sie müssen quasi selbst jedes Update installieren.

Ich habe alle Updates installiert aber dennoch hat der Client entgegen vieler anderer Aussagen kein SMB2 gesprochen. Aber die Fehlermeldung hat sich verändert:

im Wireshark ist dann zu sehen, was WindowsXP versucht.

Da hat Windows XP wohl den Netbios--Namen als DNS-Namen genutzt. Das kann ich auf dem Join-Bildschirm schnell ändern. Der nächste versucht zeigte dann wieder das übliche Fehlerbild

Allerdings hat sich ein deutlich anderes Verhalten in Wireshark gezeigt. Die Updates haben also schon etwas verändert. Auf einmal gibt es viele LDAP-Verbindungen, die aber anonym und ohne Authentifizierung erfolgt sind.

Das ist dann wohl der LDAP-Ping des DC Locators, über den der Client einen "nächsten" DC finden kann. Hier die ausführlich Antwort.

Hier kommt aber keine Authentifizierung und daher auch keine Verschlüsselung zustande. Danach geht es wieder mit SMB1 und den für Windows 2016 nicht mehr tolerierbaren Dialekten weiter.

So wird das nichts mit Servern, die kein SMB1 mehr sprechen, sondern SMB2.0 oder höher erfordern.

Achtung:
Im Internet finden Sie Artikel wie z.B. https://droidrant.com/can-windows-xp-use-smb2/, die anscheinend maschinell (ChatGPT lässt grüßen?) erstellt sind. Sie sind wirr und irreführend und versuchen durch passende Schlagworte die Besucher über Suchmaschinen auf die Seite zu locken und Werbung anzuzeigen. Nach dieser Seite könnte Windows XP sogar SMB3 und vieles mehr, wobei die Beschreibung der Einstellungen ganz klar auf Windows 10 bezogen ist.

SMB2+

Nur zur Sicherheit daher hier ein Auszug eines SMB Handshake zwischen zwei Windows 2016 Servern, bei denen der anfragende Server SMB1 gar nicht mehr anbietet.

Sie sehen es am SMB2-Version beim Server Message Block und bei den Dialekten.

SMB1-Test

Zur Gegenprobe und entgegen jeder Vernunft habe ich nun doch noch einmal SMB1 auf dem Windows 2016 Server aktiviert:

Set-SMBServerConfiguration -enableSMB1Protocol $true
Add-WindowsFeature FS-SMB1
# Neustart erforderlich

Danach konnte ich den Windows XP Client tatsächlich in die Domain aufnehmen

Eine parallele Kontrolle mit Wireshark hat aber ergeben

  • Kein SMB2-Paket
    Die komplette Kommunikation erfolgt mit SMB1. Wenn Sie also SMB1 in ihrem Netzwerk verbannen, dann kann Windows XP nicht genutzt werden. Mit SMB1 gibt es auch kein SMB-Signing, so dass die Aktivierung von SMB1 den Zwang zur gesicherten SMB2-Kommunikation durch den Server so umgangen werden kann. Noch ein Grund kein SMB1 mehr zuzulassen.
  • Kerberos per UDP mit "KRB5KRB_ERR_RESPONSE_TOO_BIG
    Anders als die neueren Windows Versionen sehe ich hier durchaus noch Kerberos-Anfragen per UDP, die aber vom Server dann mit einem "zu Groß" abgelehnt werden, so dass der Windows XP Client danach per TCP eine Anfrage stellt. Windows XP bietet neben DES auch RC4 an:

    Der Windows 2016 Server war zu der Zeit so konfiguriert, dass RC4 nicht möglich war.
  • LDAP per NTLM
    Ohne passendes Kerberos-Ticket ist natürlich auch LDAP nur per NTLM möglich

Ich habe dann auch hier noch einmal RC4 zu gelassen, denn noch ist RC4 ja nicht "abgekündigt". (Siehe Kerberos RC4 Abschaltung). Wenn der Windows 2016 DC noch RC4 zulässt, dann kann der Client auch ein KDCTGT und Service-Token erhalten. Interessanterweise nutzt der AS-REQ zwar RC4 aber das darin enthaltene Kerberos Token ist AES256 verschlüsselt.

Der Windows XP Client hat dann etwas später eine LDAP-Verbindung zum DC aufgebaut und hier kam dann ebenfalls LDAP mit Kerberos mit dem AES265-Token zum Einsatz:

Das hatte ich nun nicht erwartet dass Windows XP mit AES265-Tokens umgehen kann und nur im Kerberos-Protokoll selbst kein AES anbietet. Für Firmen, die aber noch Windows XP in Verbindung mit einem Windows 2016 DC nutzen wollen, bedeutet dies, dass Sie AES nicht erzwingen dürften aber vor allem SMB1 öffnen müssen.

Der Verzicht auf den AES-Zwang kann man noch abwägen und vielleicht noch einige Zeit in die Zukunft verschieben. Die Reaktivierung von SMB1 ist aber definitiv nicht mehr zeitgemäß und ein zu großes Risiko für einen sicheren Betrieb.

Die Gegenrichtung funktioniert mit AES aber selbst dann nicht, wenn Sie auf dem Windows XP-Computerobjekt im Active Directory mittels msds-supportedEncryptionType=4 die Nutzung von RC4 vorgeben. Wenn z.B. ein Administrator auf den Windows XP-Client per Kerberos zugreifen will, bekommt er ein RC4-Ticket, in dem aber ein AES Session Key enthalten ist.

Damit kann ein Windows XP-System als Server nicht umgehen und die Verbindung kommt nicht zustande. Dieses Problem können Sie nur lösen, indem Sie auf RC4 als Default zurückstellen.

Leider kann man unter Windows den Zugriff per SMB nicht auf bestimmte Source-IP-Adressen oder Ports beschränken, SMB1 und SMB2 nutzen 139/TCP und 445/TCP. Es mag wohl Firewalls geben, die das Protokoll genauer filtern können, aber dann müssten Sie ihre Server hinter so einer Firewall erreichbar machen. Das mag alles möglich sein aber sicherer wird es nicht. Ich habe bei mir wieder SMB1 abgeschaltet und den AES-Zwang reaktiviert.

Set-SMBServerConfiguration -enableSMB1Protocol $false
Remove-WindowsFeature FS-SMB1
# Neustart erforderlich

Danach konnte wie erwartet der Windows XP nicht mehr auf \NETLOGON u.a. Dienste zugreifen und auch keine Kerberos-Tickets mehr erhalten. Es "sah" natürlich noch einige Zeit gut aus, da bisher am Client angemeldete Benutzer sicher unter Nutzung des gecachten Profils auch weiterhin anmelden konnten. Aber eine sinnvolle Nutzung ist so natürlich ausgeschlossen.

Legacy Update

Mein Windows XP konnte keine Updates mehr von Microsoft beziehen. Ursache dürfte vermutlich das TLS 1.2 Enforcement bei Microsoft sein, welches Windows XP nicht kann. Unter der URL https://legacyupdate.net/ habe ich erst später einen Community-Service gefunden, die anscheinend einen WSUS-Server mit TLS 1.1 betreibt und damit ein Update von XP-Clients erlaubt.

Achtung: Sie vertrauen damit natürlich darauf, dass die Updates auf dem WSUS-Server "vertrauenswürdig" sind.

Die kleine EXE-Datei konfiguriert den Service als WSUS-Server, der auch per TLS 1.0 /1.1 für Windows XP erreichbar ist.

Wer es wagen möchte, könnten sogar das XP zu einer "Point of Sale"-Version umstellen

Das ist aber ein "inoffizieller" Weg, wie auch Windows XP eine TLS 12 Verbindung aufbauen kann, aber der ist eigentlich nur für "Windows PoS" supported ist

Aber auch ohne PoS-Schalter liefert Windows dann deutlich mehr Updates als allein über die Security DVD gekommen sind.

Der DNS-Name löst auf Systeme bei Cloudflare auf. Mit diesen Einstellungen hat mein Windows XP Testlab-Client noch drei Reboots gebraucht, bis alle angebotenen Updates auch installiert waren

Ein Update zur Nutzung von SMB2 oder TLS 1.2 hat sich aber nicht darunter befunden.

Ergebnis

Meine Testserie in Kurzfassung:

  • Windows XP spricht nur SMB1
    Wer Windows XP in einer Domain betreiben will, muss SMB1 zulassen. Auch die letzten Security Updates von Februar 2020, die einen Fix für den SMB-Client mitliefern, rüsten nicht SMB 2.0 nach. Ich warne aber ausdrücklich davor, SMB1 auf einem Server zu aktivieren. Auf der Seite Alte Clients habe ich aber Alternativen aufgezeigt, z.B. einfach andere Protokolle zu nutzen oder den SMB1-Client mit einem Linux in eine eigenes Subnetz zu verbannen, wobei das Linux-System seinerseits dann die Freigabe per SMB2/3 durch die Firewall mounted und intern per SMB1 wieder freigeben kann.
  • Windows XP unterstützt Kerberos nur mit RC4
    Neben DES werden nur RC4-Optionen angeboten aber kein AES. Wer eine Kerberos RC4 Abschaltung betreibt, sperrt Windows XP aus
  • Windows XP Client Kerberos mit AES-Sessionencryptionkey
    Windows XP kann in einem RC4-Ticket durchaus einen AES-Authenticator bekommen und damit auch auf einen entfernten Dienst zugreifen
  • Windows XP als Server mit AES-Sessionencryptionkey
    Allerdings versteht Windows XP den AES-Authenticator im Ticket nicht, wenn andere Dienste auf Windows XP als "Server" per Kerberos zugreifen. Hier bleibt dann nur die Wahl auf AES zu verzichten oder NTLM zu nutzen
  • Windows XP und PAC-Signing
    Fordert Windows XP ein Kerberos-Ticket an, dann bietet meine SP3-Version den PAC-Support an.
  • Windows XP und RPC-Sealing
    Bislang konnte ich noch keine Warnungen zu RPC Sealing sehen, wenn der Server dies erzwingt und ein Windows XP-Client mit SMB1 kommuniziert. Ich nehme an, dass mit SMB1 kein RPC- Sealing definiert ist und damit dieses Enforcement nicht greift.

Auch wenn ich viele Tests gemacht habe und Windows XP trotz des Alters noch mitspielen kann, solange noch RC4 und SMB1 zugelassen sind, kann dies keine Garantie sein, dass es in jeder Umgebung so funktioniert.

Weitere Links