Es geht los: DNS im Angriff

Es ist noch keinen Monat her, als Dan Kaminsky in seinem Blog einen Beitrag verfasste und damit das Internet in einer seiner Grundstrukturen erschütterte: Ein schwerer Fehler im Design von DNS sei gefunden worden. Weil es kein Implementierungsfehler war, konnte man die Schwachsetelle auf nahezu jedem System und DNS-Implementierung ausnutzen.

Zunächst war man empört, denn er veröffentlichte nicht – wie es sonst bei Opensource und derartigen IT-Sicherheitsthemen emfehlenswert wäre – die Schwachstelle und wie man sie beheben sollte. Stattdessen wurden alle Betriebssystem-, Software- und Hardwarespezialisten zusammengerufen und Patches für alle Systeme entwickelt. Infolgedessen sammelten sich letzte Woche auch die Updates. Die Hersteller veröffentlichten entsprechende Advisories (siehe Link 2): Eine Patchwelle startete für Software wie BIND, aber auch Windows oder die Firmwares von CISCO-Systemen.

Mittlerweile ist klar, dass diese Handlung mit Sicherheit nicht verkehrt war. Das Potenzial zum Ausnutzen wäre eindeutig zu hoch gewesen. Ursprünglich wollte Dan Kaminksy die näheren Einzelheiten inklusive dem Patch und Exploit im nächsten Monat veröffentlichen.. aber Veröffentlichungen und Analysen der Patches sowie wohl einem “angeblichen Versehen” wurden die bereits geahnten Probleme nun veröffentlicht.

Tatasächlich ist (leider zum Teil Präsenz) es möglich, unter bestimmten Voraussetzungen DNS-Servern nicht nur eine falsche IP zu einem Domain unterschieben, sondern man kann sogar eine zeitliche Speicherung dieser Information veranlassen.

Der Designfehler besteht nach der nun veröffentlichen Spekulation seitens Flake Halvar und bereits bestätigt durch Dan Kaminksy besteht aus folgendem Schema:

Mallory fragt einen DNS-Server Bob nach, wie die IP von www.example.org ist.
DNS-Server Bob kennt diese Domain (noch) nicht und fragt weiter (DNS-Rekursion).
Direkt danach schickt Mallory dem DNS-Server Bob eine (gefälschte) Antwort. Dafür benötigt er eine Transaktions-ID (die nach dem Patch zufällig zwischen ungefähr 1 und 65535 ist). Mit einem sogenannten RR-“in-bailiwick” wird dem Nameserver mitgeliefert, dass Nachbardomains wie a.example.org oder b.example.org bestimmte IPs haben. Und das speichert Bob als DNS-Server nun auch brav in seinem Cache..
Danach eingehende Anfragen auf eine kompromitierte Domain werden nun vom DNS-Server falsch beantwortet. Als Anwender ist dies quasi ohne Kenntnis der echten IP nicht zu erkennen. Auch SSL-Zertifikate helfen hier erst nicht weiter, wenngleich ein Fake-Server kaum in Besitz des Original-Zertifikates sein kann. Allerdings kann er sich ein leichtes, normales auf die Domain erstellen.

Zusätzlich gibt es aber das neue Problem: Die eigentliche Lücke kann auch missbraucht werden: Dazu muss man zwar genügend Requests abschicken, bei einer Rate von 1/65535 ist dies bei einer guter Verbindung oder dem Nutzen eines Netzes (Stichwort E-Mails, Distrubuted Attackes) kein Problem.

Als Lösung für dieses Problem gibt es zwei Dinge:

Aktuelle Version der DNS-Software installieren, die zumindestens keine hervorsagbaren DNS-Anfragen, sondern zufällige nutzt.
Signierung der Antworten eines DNS-Servers, damit können unqualifizierte Antworten (Knackpunkt) vermieden werden.

Inbesondere für den zweiten Punkt muss man aber wissen, dass dies durch eine Softwarepatch NICHT gelöst ist.. dies muss jeweils beantragt und extra konfiguriert werden.

Ob ein Nameserver oder Nameserver einer IP/Domain bereits das signierte DNS-Antwort-System nutzt, kann man mit Link 3 testen.

Ob man selber einen Internet-Provider nutzt, der seine DNS-Server gepatched hat, kann man unter Link 4 ausprobieren. Funktioniert nur unter Unix/MacOSX; sollte ein GOOD oder wenigstens FAIR ausgeben. Mit Link 5 gibt es eine Alternative, läuft im Browser und benötigt werder Konsole noch dig.

Das ursprünglich herausgesickerte Posting beschreibt nochmal den genauen Hergang. Außerdem wird Bezug zu zwei Fehlern und zwei Fixes in der Vergangenheit genommen, weil diese nämlich in der neuen Lücke einen direkten Zusammenhang haben.

Sehr informativ ist auch der Bericht (Link 6) des RUS-CERT, der eine genaue Auflistung aller Systeme und Funktionen hat. Siehe auch folgendes Zitat:

Soll beispielsweise der Cache mit einer falschen IP-Adresse für www.denwillichfaelschen.de gefüttert werden, so wird ein Benutzer des anzugreifenden Resolvers z.B. durch eine entsprechende Webseite dazu gebracht, sehr viele Anfragen an den Name Server der Domain denwillichfaelschen.de zu stellen. Diese haben jedoch nicht www.denwillichfaelschen.de zum Thema sondern z.B. aaaaa.denwillichfaelschen.de, aaaab.denwillichfaelschen.de, … und so weiter. Dies kann z.B. durch das Platzieren tausender Ein-Pixel-Bilder in der Seite geschehen, die alle durch URIs referenziert werden, die diese (ausgedachten) Servernamen enthalten.
Existiert der entsprechende DNS-Name nicht, antwortet der zuständige Name Server ns1.denwillichfaelschen.de mit der Fehlermeldung NXDOMAIN. Falls er existiert, wird die für den Angriff irrelevante IP-Adresse ebendieser Maschine zurückgeliefert (jedoch nicht der für www.denwillichfaelschen.de). Im Cache sind nun die Auflösungsdaten für diesen einen (ausgedachten) DNS-Namen enthalten, jedoch nicht für das eigentliche Ziel. Zufällige Treffer beenden den Angriff also nicht vorzeitig.
Der Angreifer wird jedesmal versuchen, dem Resolver seine eigene Antwort mit einer geratenen Transaktionsnummer unterzuschieben. Bei ausreichend vielen Anfragen, wird es dem Angreifer irgendwann gelingen, einen Treffer zu erlangen und die eigenen Daten in den Cache zu platzieren. Die dabei gelieferte Auflösung, z.B. für cxpny.denwillichfaelschen.de ist jedoch nebensächlich, im mitgelieferten glue record ist nämlich die gefälschte Auflösung für www.denwillichfaelschen.de enthalten. Da sie sich auf dieselbe Domain denwillichfaelschen.de bezieht, ist sie in-bailiwick und wird daher vom Resolver akzeptiert. Der Cache des angegriffenen Resolvers ist damit erfolgreich mit eigenen Daten beschickt.

Weiterführende Links und Quellen