advanced-threat-research/cve-2020-16899CVE-2020-16899 - Microsoft Windows TCP/IP-Schwachstellenerkennungslogik und -Regel
Am 13. Oktober kündigte Microsoft eine kritische Sicherheitslücke im Windows IPv6-Stack an, die es einem Angreifer ermöglicht, manipulierte Pakete zu senden, die auf den neuesten Versionen von Windows 10 und Windows Server 2019 sofort einen BSOD (Blue Screen of Death) verursachen. Diese Sicherheitslücke scheint einem Angreifer zwar keine Codeausführung zu ermöglichen, könnte jedoch für massenhafte Denial-of-Service-Angriffe auf verwundbare Windows-Versionen genutzt werden. Erkennungslogiken für die schwerwiegendere RCE-Version dieser Sicherheitslücke finden Sie unter CVE-2020-16898: „Bad Neighbor“.
Dieses Dokument wurde von McAfee Advanced Threat Research erstellt. Es soll Netzwerkadministratoren und Sicherheitspersonal wertvolle Einblicke bieten, die diese Sicherheitslücke besser verstehen und sich vor Ausnutzung schützen möchten. Die hier erstellte Signatur sollte in Staging-Umgebungen gründlich geprüft und 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, ohne Gewährleistung oder Garantie für die Richtigkeit oder Anwendbarkeit der Informationen auf eine bestimmte Situation oder Gegebenheit und zur Nutzung auf eigenes Risiko bereitgestellt. Darüber hinaus können wir keine Leistungs- oder Wirksamkeitsbenchmarks für Signaturen garantieren.
Die Sicherheitslücke ist das Ergebnis eines Lesevorgangs außerhalb der Grenzen (Out-of-Bounds Read), der auftreten kann, wenn der Windows IPv6-Stack ICMPv6-Router-Advertisement-Pakete (Typ = 134) verarbeitet, die einen oder mehrere DNSSL-Option-Datensätze (Optionstyp = 31) enthalten. Der Zweck des DNSSL-Datensatzes besteht darin, eine Suchliste mit DNS-Namenssuffixen bereitzustellen, die in seinem letzten Feld enthalten sind. Da diese Suchliste mehrere nullterminierte DNS-Namen hintereinander enthalten kann, kann das Feld (und damit der gesamte Datensatz) stark in der Größe variieren. Um dies zu berücksichtigen, enthält der DNSSL-Option-Datensatz ein eigenes Längenfeld. Da die Länge jedoch in 8-Byte-Schritten gezählt wird, kann mindestens einer der Domainnamen in der Suchliste zusätzliche Null-Auffüllungen aufweisen, um die 8-Byte-Ausrichtung des Datensatzes zu erhalten. Bei der Verarbeitung dieser Nullbytes kann die Sicherheitslücke gefunden werden.
Für jeden Domainnamen in der Suchliste weist der Windows IPv6-Stack einen 256-Byte-Puffer zu. Da RFC 1035 Domainnamen auf 255 Bytes begrenzt, wäre dies normalerweise ausreichend, um einen Domainnamen plus seinen Nullterminator zu enthalten. Der Code, der für das Verarbeiten der nachgestellten Nullbytes am Ende jedes Domainnamens verantwortlich ist, hat jedoch eine Obergrenze, die den verbleibenden Bytes in der Option entspricht, was 256 Bytes überschreiten kann. Das Ergebnis ist, dass der nullverarbeitende Code fälschlicherweise mehr Bytes verbrauchen kann, als für den Puffer zugewiesen wurden, was zu einem Out-of-Bounds Read führt. Falls der Puffer am Ende einer Speicherseite liegt, kann dieser OOB-Read zu einem BSOD führen.
Die Suricata-Signatur für diese Sicherheitslücke befindet sich in cve-2020-16899.rules und enthält die folgende Logik:
alert icmp any any -> any any (msg:"Potential CVE-2020-16899 Exploit"; lua:cve-2020-16899.lua; sid:202016899; rev:1;)
Das entsprechende Lua-Skript befindet sich in cve-2020-16899.lua. Es enthält die Logik, die erforderlich ist, um die ICMPv6-Schicht korrekt zu parsen und eine potenzielle Ausnutzung von CVE-2020-16899 zu identifizieren, wie folgt:
Sobald wir den Anfang der ICMPv6-Schicht gefunden haben, testen wir das erste Byte der Schicht, um sicherzustellen, dass es sich um ein Router-Advertisement-ICMPv6-Paket handelt – wenn nicht, beenden wir.
Da Suricata-Primitiven nicht aktualisiert wurden, um die ICMPv6-Optionen zu parsen, springen wir einfach zum 17. Byte der ICMPv6-Schicht, da dort die Optionen beginnen sollten, falls vorhanden (die ersten 16 Bytes sind Felder mit statischer Länge, gemäß RFC 4443). Von dort durchlaufen wir jede Option, bis wir keine Bytes mehr im Paket haben. Für jede Option beginnen wir mit der Inspektion des ersten Bytes, das dem Feld Optionstyp entspricht. Während wir alle Optionen ignorieren, die nicht DNSSL sind, prüfen wir für Optionstyp = 31 (DNSSL), ob die Länge (zweites Byte in der Option) größer oder gleich 35 ist, der Mindestlänge, die erforderlich ist, um die Sicherheitslücke auszulösen:
