Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
CVE-2020-16898 — CVE-2020-16898 (Bad Neighbor) Microsoft Windows TCP/IP-Schwachstellenerkennungslogik und -regel | Kitploit
Tools/GitHubGitHub/advanced-threat-research/cve-2020-16898
SchwachstellenanalyseExploitationNetzwerksicherheitEinbruchserkennung
GitHubadvanced-threat-research/cve-2020-16898

CVE-2020-16898

CVE-2020-16898 (Bad Neighbor) Microsoft Windows TCP/IP-Schwachstellenerkennungslogik und -regel

Repository anzeigen

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen
Webseite
20930vor 5 JahrenVon Kitploit geprüft

CVE-2020-16898: „Böser Nachbar“

CVSS Score: 8.8

CVSS Vector: CVSS3.0/AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H/E:P/RL:O/RC:C

Überblick

Am 13. Oktober hat Microsoft eine außergewöhnlich kritische Sicherheitslücke im Windows IPv6-Stack bekannt gegeben, die es einem Angreifer ermöglicht, böswillig präparierte Pakete zu senden, um potenziell beliebigen Code auf einem entfernten System auszuführen. Der Proof-of-Concept, der mit MAPP-Mitgliedern geteilt wurde, ist sowohl extrem einfach als auch perfekt zuverlässig. Er führt zu einem sofortigen BSOD (Blue Screen of Death), deutet aber vor allem auf die Wahrscheinlichkeit einer Ausnutzung für diejenigen hin, denen es gelingt, die Schutzmaßnahmen von Windows 10 und Windows Server 2019 zu umgehen. Die Auswirkungen eines Exploits, der Remotecodeausführung ermöglichen würde, wären weitreichend und hochgradig folgenreich, da es sich um eine Art von Bug handelt, der sich wie ein Wurm verbreiten könnte. Der Einfachheit halber haben wir die Schwachstelle „Böser Nachbar“ genannt, da sie sich innerhalb eines ICMPv6-Nachbarschaftsfindungs-„Protokolls“ mit dem Router-Advertisement-Typ befindet.

Dieses Dokument wurde von McAfee Advanced Threat Research erstellt. Es soll Netzwerkadministratoren und Sicherheitspersonal wertvolle Einblicke bieten, die diese Schwachstelle besser verstehen und sich vor einer Ausnutzung schützen möchten. Die hier erstellte Signatur sollte gründlich geprüft und in Staging-Umgebungen getestet werden, bevor sie in der Produktion eingesetzt wird, und kann von einer spezifischen Anpassung an die Zielumgebung profitieren.

Die hier bereitgestellten Informationen können ohne vorherige Ankündigung geändert werden und werden „WIE BESEHEN“ mit allen Fehlern bereitgestellt, ohne Garantie oder Gewährleistung für die Richtigkeit oder Anwendbarkeit der Informationen auf eine bestimmte Situation oder einen bestimmten Umstand und werden auf eigenes Risiko verwendet. Darüber hinaus können wir keine Leistungs- oder Wirksamkeitsgarantien für Signaturen übernehmen.

Signatur

Die Suricata-Signatur für diese Schwachstelle befindet sich in cve-2020-16898.rules und enthält die folgende Logik:

alert icmp any any -> any any (msg:"Potential CVE-2020-16898 Exploit"; lua:cve-2020-16898.lua; sid:202016898; rev:1;)

Das entsprechende Lua-Skript befindet sich in cve-2020-16898.lua. Es enthält die notwendige Logik, um die ICMPv6-Ebene korrekt zu parsen und eine mögliche Ausnutzung des Bösen Nachbarn zu identifizieren, wie folgt:

Sobald der Beginn der ICMPv6-Ebene gefunden wurde, wird das erste Byte der Ebene getestet, um sicherzustellen, dass es sich um ein Router-Advertisement-ICMPv6-Paket handelt (Typ = 134) – wenn nicht, wird abgebrochen.

Da die Suricata-Primitiven nicht aktualisiert wurden, um die ICMPv6-Optionen zu parsen, springen wir einfach zum 17. Byte der ICMPv6-Ebene, da dort die Optionen beginnen sollten, falls vorhanden (die ersten 16 Bytes sind statische Felder, gemäß RFC 4443). Von dort iterieren wir über jede Option, bis keine Bytes mehr im Paket übrig sind. Für jede Option sind wir nur an den ersten zwei Bytes interessiert: den Feldern für Optionstyp und -länge. Während wir alle Optionen ignorieren, die nicht RDNSS sind, überprüfen wir bei Optionstyp = 25 (RDNSS), ob die Länge (zweites Byte in der Option) eine gerade Zahl ist. Wenn ja, wird es markiert. Wenn nicht, wird fortgesetzt. Da die Länge in Schritten von 8 Bytes gezählt wird, multiplizieren wir die Länge mit 8 und springen diese Anzahl Bytes vorwärts, um zum Beginn der nächsten Option zu gelangen (abzüglich 1, um das bereits verarbeitete Längenbyte zu berücksichtigen).

Mit dieser Regel überprüfen wir auch, ob die Länge mindestens 3 beträgt, da RFC 8106 dies erfordert, aber letztendlich kann diese Überprüfung überflüssig sein, da wir uns nur darum kümmern, ob die Länge gerade ist oder nicht.

Tool herunterladen