Mit dem vergangenen „Patch Tuesday“ wurden durch Microsoft 123 Bugs gefixt, darunter 20 mit der Kategorie „Kritisch“.
Einer dieser Bugs, eine Sicherheitslücke in Windows DNS Server, hat besonderes Aufsehen erregt. Nach Einschätzungen Microsofts handelt es sich hierbei um eine Schwachstelle, die es Malware erlaubt sich ohne Benutzerinteraktion wurmartig im Netzwerk zu verbreiten. Da DNS eine fundamentale Netzwerkkomponente darstellt und häufig auf Active Directory-Systemen installiert ist, kann diese Schwachstelle dazu führen, dass Services signifikant eingeschränkt und High Level Domain Accounts kompromittiert werden.
Bei der Schwachstelle handelt es sich um einen lang bestehenden Bug, der in jeder von Microsoft unterstützten Version von Windows Server gefixt werden muss, und betrifft damit alle Systeme beginnend mit Windows Server 2008 und aufwärts.
Der offizielle Name der Schwachstelle lautet CVE-2020-1350 und hat eine CVSS-Gefahrenwertung von 10.0, die absolute Höchstwertung. Das Update auf die neueste Version wird also dringend empfohlen.
Eine entsprechende IPS-Signatur wurde auf XG v18 Firewalls ausgerollt. Eine entsprechende IPS-Signatur für Intercept X Advanced für Server steht in Kürze bereit.
Folgende Bereiche werden beschrieben:
- Der Bug und wo er zu finden ist
- Workaround
- Technischer Hintergrund
Der Bug und wo er zu finden ist
Bei DNS (Domain Name System) handelt es sich um eine globale, verteilte Datenbank, die dazu dient Hostnamen in ihre zugehörigen IP-Adressen umzuwandeln. Kann ein DNS-Server diese Namensauflösung nicht lokal vornehmen, leitet er die Anfrage an andere DNS-Server weiter und empfängt von diesen die entsprechenden Daten.
CVE-2020-1350 existiert in dem Teil der Windows DNS Software, die auf diese DNS-Antworten lauscht, statt in dem Teil, der auf die eigentlichen DNS-Anfragen lauscht. Da die Windows DNS Server und die DNS-Clientprogramme sich keinen Code teilen, betrifft der Fehler ausschließlich die Server.
Workaround
Für den Fall, dass sie ihre Windows Server nicht updaten können, weil sie beispielsweise auf ein Wartungsfenster warten müssen, hat Microsoft einen Workaround veröffentlicht der den Bug unterdrückt
- In der Registry, navigieren sie zu dem Schlüssel
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters
- Suchen bzw. Erstellen sie den DWORD-Wert
TcpReceivePacketSize
- Setzen sie den Wert auf: FF00 (hexadezimal) oder 65280 (dezimal)
- Starten sie den DNS-Server neu.
Hierdurch wird verhindert, dass die DNS-Antwort nach Dekompression zu einem Integer Overflow führt, da DNS-Pakete mit entsprechenden Größen nicht zugelassen werden.
Technischer Hintergrund
DNS-Netzwerkverkehr nutzt ein altes und datensparsames Format, welches in den frühen 80er Jahren entstanden ist. Da Speicherplatz und Netzwerk-Bandbreite knappe Güter waren, wurden Daten nicht mitausdrucksstarken, selbst-dokumentierenden Formaten wie beispielsweise JSON, sondern als dicht gepackte binäre Pakete versandt. Der Mepfänger musst vorab wissen, welches Byte an Daten mit welchen Einstellungen in Verbindung stand um diese Pakete korrekt zu interpretieren.
Während heutzutage während der Dekodierung der Daten der entsprechend benötigte Speicherplatz zugewiesen wird und der Empfänger die finale Größe des Paketes selbst ausarbeitet, wurde DNS unter der Annahme designed, dass fast alle normalen Anfragen und Antworten in 512 Byte gefasst werden können, abzüglich eines 12 Byte großen Headers. Für längere Antworten gibt es eine besondere, aber langsamere Übertragungsmethode, formatiert als zwei Bytes die die Länge der Daten bestimmen, gefolgt von genau dieser Menge an Daten in Bytes. Die größte mit zwei Bytes darstellbare Zahl ist 65535.
Es existieren viele Arten von DNS-Antworten,alternativ bekannt als Resource Records oder RRs, welche wiederum unterschiedlichste Datenfelder enthalten. Ein häufig vorkommendes Datenfeld ist NAME, ein Text-String, der aus einem Byte zur Bestimmung der Stringlänge und exakt dieser Menge an Bytes besteht.
Um zu verhindern, dass gefälschte Anfragen oder Antworten in das System injiziert werden , wurde in den 90er Jahren Unterstützung für Digitale Signaturen implementiert und ein neuer RR-Typ namens SIG (kurz für Signature) definiert. Nicht lang nach seiner Implementierung wurde der SIG-Typ durch den neuen RRSIG-Typ ersetzt. RRSIG folgt dem selben Format, wie SIG, unterliegt aber anderen Formatierungsregeln.
Es wird davon ausgegangen, dass der Code für SIG als Grundlage genutzt wurde, um RRSIG zu implementieren und im folgenden geupdatet, gefixt und verbessert wurde, während der ursprüngliche SIG zwar weiterhin vorhanden, aber keinen Änderungen unterworfen war.
Dieser Code trifft die folgenden Annahmen
- die größte Datenmenge in einer DNS-Antwort ist 65535 Bytes
- Dia maximale Menge an Speicher, die für eine DNS-Antwort benötigt wird ist 65535 Bytes
- Daher bietet ein „unsigned short int“ (eine 16-bit Zahl) genug Präzision für die Berechnungen
SIG-Records enthalten jedoch ein NAME-Feld, das, mithilfe von DNSs rudimentären Kompressions-Algorithmus, in komprimierter Form übermittelt werden kann, sodass ein NAME-String mit einer Größe von 255 Byte extrahiert, auf bis zu zwei Bytes in einer DNS-Anfrage herunterkomprimiert werden kann.
Wird mithilfe dieser Komprimierung eine DNS-Antwort gesendet, die die maximale Größe von 65535 Bytes hat, kann diese nach dem extrahieren des Namensfeldes eine Größe von 65535+x Bytes erreichen und führt in dem „unsigned short int“ zu einem Integer Overflow. Hierdurch wird für die DNS-Antwort lediglich Speicherplatz im Wert von x-1 Bytes freigegeben, der zugewiesene Speicher läuft über und der DNS-Server stürzt ab.
Hintergrund für die lange Lebensdauer dieses Bugs ist, dass SIG im DNS-Verkehr schlicht nicht mehr genutzt wird, wodurch es auch keine Gelegenheit gab, in den Bug zu laufen.
Sowohl Check Point, die diesen Bug entdeckt haben, als auch Microsoft selbst, gehen davon aus, dass diese Sicherheitslücke genutzt werden kann, um beliebigen Code im Kontext des Lokalen System Accounts auszuführen.