[English]Noch eine kleine Nachlese vom August 2024 Patchday (Blog-Leser haben angeregt, das mal in einem separaten Beitrag aufzubereiten). Zum 13. August 2024 wurde die 0-day-Schwachstelle CVE-2024-38063 in Windows bekannt. Es handelt sich um eine Remote-Code-Execution-Schwachstelle in der TCP/IP-Implementierung von Windows steckt. Angreifer können über IPv6-Pakete einen Host kompromittieren und dort Code ausführen. Weben der Bewertung mit dem CVEv3 Score 9.8 (critical, „Exploitation More Likely“) empfiehlt Redmond Administratoren momentan IPv6 zu deaktivieren, hat aber auch Sicherheitsupdates für Windows bereitgestellt. Hier sollten Administratoren also reagieren.
TCP-IP-Schwachstelle CVE-2024-38063
Ich hatte die 0-day-Schwachstelle CVE-2024-38063 in Windows nach einem Hinweis von Tenable kurz im Blog-Beitrag Microsoft Security Update Summary (9. Juli 2024) aufgegriffen. Es handelt sich um eine Remote Code Execution-Schwachstelle (RCE) in der Windows TCP/IPv6-Implementierung, verursacht durch einen Integer Underflow-Fehler. Diese RCE-Schwachstelle wurde mit einem CVEv3 Score 9.8 als äußerst kritisch und die als „Exploitation More Likely“ eingestuft.
Das Problem: Ein Angreifer kann diese Sicherheitslücke ohne Authentifizierung und ohne Benutzeraktion remote ausnutzen, indem er wiederholt speziell gestaltete IPv6-Pakete an einen Windows Host sendet. Microsoft hat in CVE-2024-38063 ausgeführt, dass nur nur IPv6-Pakete zur Ausnutzung dieser Sicherheitslücke missbraucht werden können und empfiehlt IPv6 zu deaktivieren.
Die Schwachstelle wurde von XiaoWei vom Kunlun-Labor entdeckt (Tweet auf x) und dann an Microsoft gemeldet. Details zu dieser Schwachstelle wurden bisher nicht veröffentlicht. Die Kollegen von Bleeping Computer haben noch ein Statement von Dustin Childs, Head of Threat Awareness bei der Zero Day Initiative von Trend Micro, zitiert. Dustin Childs bezeichnet die Schwachstelle als „wormable“, ein Angreifer könnte also seinen Schadcode im Netzwerk auf weitere Rechner verbreiten.
Proof of Concept verfügbar
Ergänzung: Robel Campbell, Principal Security Researcher at Blackpoint Cyber, hat auf X einen Tweet abgesetzt, in dem er angibt, durch Lektüre der RFCs und der Teile über optionale Header in IPv6-Paketen einen PoC entwickeln konnte. Der Proof of Concept-Exploit (POC) verursacht einen Absturz.
Die Fehlerprüfung sei im PoC-Fall nicht sehr detailliert. Im Wesentlichen erzeugt der Unterlauf (Integer Underflow) einen großen Wert, der in einer Schleife verwendet wird, die schließlich Daten außerhalb der Grenzen schreibt und einen Absturz verursacht. Campbell kann sich vorstellen, dass dies durch Heap-Massagetechniken und die Beschädigung benachbarter Objekte im Heap für Angriffe eingesetzt werden kann. Der PoC ist aber quick-n-dirty, und Campbell gibt an, dass er den Absturz nur einmal auslösen konnte. Der Crash Dump habe ihm nicht wirklich nicht viel zur Analyse geholfen. Administratoren sollten also zügig reagieren.
Updates von Microsoft
Microsoft hat zum 13. August 2024 eine Reihe von Sicherheitsupdates für betroffene Windows-Systeme bereitgestellt. Nachfolgend habe ich mal die betreffenden Pakete herausgezogen, die unter CVE-2024-38063 gelistet werden.
- KB5041571 : Windows 11 Version 24H2 (diese Windows-Version gibt es nur für Windows Insider und ist noch nicht allgemein verfügbar)
- KB5041585: Windows 11 Version 22H2 – 23H2
- KB5041573: Windows Server 2022 Version 23H2
- KB5041160: Windows Server 2022
- KB5041592: Windows 11 Version 21H2
- KB5041580: Windows 10 Version 21H2 – 22H2
- KB5041578: Windows Server 2019, Windows 10 Version 1809 (2019)
- KB5041773: Windows Server 2016, Windows 10 Version 1607 LTSC
- KB5041782: Windows 10 RTM LTSC
- KB5041828: Windows Server 2012 R2
- KB5041851: Windows Server 2012
- KB5041838, KB5041823: Windows Server 2008 R
- KB504185, KB5041847: Windows Server 2008
Ich habe mal in die Supportartikel für die obigen Beiträge geschaut, in keinem Knowledge-Base-Artikel ist die Schwachstelle CVE-2024-38063 erwähnt. Es ist also unklar, ob die Schwachstelle geschlossen ist, sobald die obigen genannten Update-Pakete installiert sind.
Weitere Handlungsanweisungen
In den Kommentaren hier im Blog sowie im Beitrag Windows Server 2019/Windows 10 Enterprise 2019 LTSC: Performance-Probleme mit Update KB5041578 deutet sich ja an, dass August 2024-Updates u.U. wegen Problemen nicht installiert werden können. Von Microsoft gibt es daher die Empfehlung, IPv6 zu deaktivieren, um den Angriffsvektor zu entschärfen. Hier bin ich ad-hoc etwas unsicher ob der Folgen, denn im Supportbeitrag hier schreibt Microsoft:
Internet Protocol version 6 (IPv6) is a mandatory part of Windows Vista and Windows Server 2008 and newer versions. We do not recommend that you disable IPv6 or its components. If you do, some Windows components may not function. We recommend using Prefer IPv4 over IPv6 in prefix policies instead of disabling IPV6.
Oder in ganz kurz: IPv6 wird ab Windows Vista bzw. den Server-Varianten gebraucht. Bei abgeschaltetem IPv6 ist mit Fehlfunktionen zu rechnen. Muss ich so im Raum stehen lassen.
An dieser Stelle noch einige weitere Hinweise zu dieser Thematik. Es gibt Administratoren, die messerscharf geschlossen haben „gut, dann deaktiviere ich IPv6 in der Firewall, und Ruhe ist“. In einem Tweet auf X antwortet der Entdecker der Schwachstelle auf eine entsprechende Frage, dass Fehler ausgelöst wird, bevor die Firewall das Paket filtert. Das ist also schon mal nichts.
Hier im Blog gibt es diese Diskussion zur Abschaltung von IPv6, wo jemand fragt, ob das Entfernen der Markierung des Kontrollkästchens für IPv6 bei der Protokollbindung der Netzwerkkarte reicht. Die Kommentarlage ist so, dass dies wohl nicht ausreichend sein soll. Um den IPv6-Stack abzuschalten, lässt sich im Registrierungsschlüsse:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
der DWORD-Wert DisabledComponents auf den Wert REG_DWORD 0x000000ff (255) setzen, um IPv6 in Windows zu deaktivieren. Alternativ kann man die Protokollbindung für IPv6 per Gruppenrichtlinie deaktivieren. Mark Heitbrink hat auf gruppenrichtlinien.de diesen Beitrag mit ausführlichen Erklärungen zum Thema veröffentlicht. Vielleicht hilft es etwas weiter.
Ähnliche Artikel:
Microsoft Security Update Summary (9. Juli 2024)
Patchday: Windows 10/Server-Updates (13. August 2024)
Windows Server 2019/Windows 10 Enterprise 2019 LTSC: Performance-Probleme mit Update KB5041578
es sind mir nur 2 Dinge bekannt, die bei komplett deaktiviertem IPv6 nicht gehen:
– direct access, logisch da es ipsec über v6 macht, legacy seit 2004?
– Beitritt zur Heimnetzgruppe, abgeschafft in 1709
ich schalte es seit Jahren auf Domänen Ebene per GPO aus, mit dem Argument, das ich es sofort wieder einschalte, wenn es gebraucht wird. Wurde es bislang nie ;-)
Bei uns ist IPv6 seit Jahren per GPO deaktiviert. Habe noch keine Probleme feststellen können.
Dann ist der Fehler wohl in der Verarbeitung der Extension Header. Das Thema ist etwas komplexer und macht(e) auch bei manchen Sicherheitsprodukten Probleme. Inzwischen ist es nicht mehr so arg. Z.B. konnte man mit vielen EHs oder bestimmten Anordnungen von EHs die eine oder andere Firewall überwinden. Manche Hersteller haben daraufhin einfach die Anzahl und/oder die Typen der EHs beschränkt (quick ’n dirty Lösung). Das Thema wurde vor über 10 Jahren von Netzwerk-Sicherheitsexperten durchdiskutiert und getestet. Daß es jetzt bei Windows plötzlich auftaucht, hat Unterhaltungswert.
Das mit der Firewall scheint missverständlich zu sein, bezieht sich die Aussage eventuell auf die Windows Firewall?
Wenn IPv6 via hardware firewall aus dem Internet nicht zugelassen wird, kann der Exploit nicht klappen:
The vulnerability can be mitigated by turning off IPv6 on vulnerable machines or blocking incoming IPv6 traffic in the firewall.
Ich habe es so verstanden, dass sich das auf die Windows Firewall bezieht.
Nach meinem Kenntnissstand führt die komplette Deaktivierung von IPv6 zu Problemen bei Servern mit installiertem Exchange.
Gruß,
Werner
der ist dann dahin, das ist fix. keine gute Idee.
nein.
Was man so liest, soll man IP6 in Domänen auch auf Clients nicht hart deaktivieren. Nächstes mal ist dann eh IP4 dran :-) Per GPO kann man aber – vergessen wo – IP4 den Vorrang – oder so was – vor IP6 einräumen – das habe ich eingestellt. Ich erlebe es wohl nicht mehr, daß das mit IP6 irgendwann noch breiter eingeführt wird – im Intranet werden die IT-Dienstleister immer bleich im Gesicht, frägt man nach IP6.
es gibt keine Richtlinie. es ist ein Registry Wert „DisabledComponents“ der die Parameter im TCPIP Treiber steuert.
es gibt ein Admx, nicht von MS das die preference/Einstellung setzen kann.
https://www.gruppenrichtlinien.de/artikel/ipv6-deaktivieren-das-protokoll-nicht-die-bindung
das mit der Reihenfolge ist seit Win10/Server2016 anders
Get-NetIPInterface
ifIndex InterfaceAlias AddressFamily NlMtu(Bytes) InterfaceMetric Dhcp ConnectionState PolicyStore
——- ————– ————- ———— ————— —- ————— ———–
12 Ethernet IPv6 1500 25 Enabled Connected ActiveStore
3 net7 IPv6 65535 5 Disabled Disconnected ActiveStore
1 Loopback Pseudo-Interface 1 IPv6 4294967295 75 Disabled Connected ActiveStore
12 Ethernet IPv4 1500 25 Enabled Connected ActiveStore
3 net7 IPv4 1420 5 Disabled Disconnected ActiveStore
1 Loopback Pseudo-Interface 1 IPv4 4294967295 75 Disabled Connected ActiveStore
——-
diese InterfaceMetric ist normalerweise automatisch konfiguriert, kann aber angepasst werden. Höher ist teuerer.
„KB5041838, KB5041823: Windows Server 2008 R“
Korrektur:
„KB5041838, KB5041823: Windows Server 2008 R2“
(R2 stattR)
—
Dieses Update gilt auch für Windows 7.
Ist bit-identisch mit dem Update für „Windows Embedded Standard 7“, dass man auch auf Windows 7 installieren kann.
—
In den Eigenschaften der LAN-Verbindung hatte ich schon immer seit es Win7 oder WinXP gibt dieses „TCP/IPv6 “ abgehakt (ausgeschaltet).
In der Registry hatte ich seit mehreren Jahren dieses DisabledComponents auf ff stehen und keine Probleme damit gehabt.
„Heimnetzwerk“ würde mit IPv4 zwar nicht mehr funktionieren, aber das „Arbeitsplatznetzwerk“ funktioniert weiter.
In den erweiterten Eigenschaften des IPv4 im Reiter WINS habe ich auch noch NETBIOS und LMHOSTS-Abfrage abgeschaltet.
NETBIOS braucht man nur, wenn Windows-Systeme VOR Windows 2000 (also sowas antikes wie MS-DOS oder Win98) im Netzwerk vorhanden sind, weil diese uralten Systeme noch WINS statt DNS für die Namensauflösung benutzen.
LMHOSTS dient wie WINS auch der Namensauflösung in NETBIOS-Netzen.
Wenn NETBIOS aus ist, dann braucht man weder LMHOSTS noch WINS.
—
Im Gerätemanager habe ich auch diesen „Microsoft-6zu4-Adapter „, „ISATAP “ und den „Teredo-Tunnel“ abgeschaltet, denn wenn man sowieso kein IPv6 einsetzt, dann braucht man diese Übersetzer und Wrapper auch nicht mehr.
Also alles aus, was man nicht braucht, damit man die Angriffsfläche verringert.
Gut, aber dafür muss der Rechner ja übers Internet via IPv6 erreichbar sein, oder der Angreifer sich im LAN/WLAN befinden? oder verstehe ich das falsch?
für mich liest sich das so, dass das in den genannten KBs gefixt ist:
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-38063
Hallo,
ich mag das ja oben übersehen haben…als ich heute Morgen anfing zu arbeiten, ging nach den Microsoft Updates von gestern praktisch nichts mehr in der Domäne. Ich konnte relativ schnell herausfinden, dass es an der Namensauflösung liegt und dass wohl nur noch der letzte verbliebene Win2016 DC/DNS funktioniert (der übrigens heute hätte gegen Win2022 getauscht werden sollen).
Aufgrund der IPv6-Geschichte habe ich einfach den Haken in der Netzwerkbindung der Adapter entfernt, erst dann lief die Domäne wieder einwandfrei – ist jetzt bei allen 8 DCs entfernt, der Tausch ist auf Mitte der Woche verschoben.
Was mich wundert: oben und in den Kommentaren konnte ich jedoch nichts über dieses gravierende Problem lesen – bin ich hier der einzige?
Hallo zusammen, bei mir sieht es aktuell so aus:
KB5041585: Windows 11 Version 22H2 – 23H2
– ca. 50 Clients – keine Probleme
KB5041160: Windows Server 2022
– nicht auf DCs installiert wegen den GPO Problemen
– Ansonsten keine Probleme mit HyperV etc. installiert auf 30 Servern
KB5041580: Windows 10 Version 21H2 – 22H2
– ca. 175 Clients – keine Probleme
KB5041578: Windows Server 2019, Windows 10 Version 1809 (2019)
– Installiert auf ca. 30 Servern bis auf die DCs – sonst keine Probleme
KB5041773: Windows Server 2016, Windows 10 Version 1607 LTSC
– 13 Server – keine Probleme, darunter aktueller Exchange