Update: DNS im Angriff (Tool inside)

Es sind wohl immer noch nicht alle DNS-Server gepatched; Sicherheitschecks hin und her, manche Provider scheinen das nicht ganz ernst zu nehmen. Der Dumme ist auf jeden Fall der Anwender.

Wie bereits im Heise-Artikel (Link siehe oben) erwähnt, gibt es nun auch ein paar Downloads zum „Selber-DNS-faken“ – wie praktisch!

Viel interessanter finde ich bei dem Exploit aber das begleitende Video – das ist schon erschrecken. Mit dem „Baukasten“ können auch Unversierte schnell viel Unfug bauen..

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:

  1. Mallory fragt einen DNS-Server Bob nach, wie die IP von www.example.org ist.
  2. DNS-Server Bob kennt diese Domain (noch) nicht und fragt weiter (DNS-Rekursion).
  3. 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..
  4. 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:

  1. Aktuelle Version der DNS-Software installieren, die zumindestens keine hervorsagbaren DNS-Anfragen, sondern zufällige nutzt.
  2. 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

  1. heise online: Massives DNS-Sicherheitsproblem gefährdet das Internet (09.07.08)
  2. heise online: Details zum DNS-Sicherheitsproblem veröffentlicht (22.07.08)
  3. Interaktive Demo der IKS GmbH: DNS(SEC)
  4. Blogbeitrag: „Check your dns resolver“
  5. Grafischer DNS-Resolver-Tool für Leute ohne Unix/dig o.ä.
  6. Meldung im RUS-CERT: Schwachstelle im DNS-Protokoll

Ausfall Webhoster

Wichtige Information

Sehr geehrte Kunden,

aufgrund einer unangekündigten Wartungsarbeit unseres Rechenzentrumsbetreibers Avaya-Tenovis kam es heute gegen 9.50 Uhr zu einem Stromausfall in einem Teil unserer Rechenzentrumsfläche in der Avaya Databurg in Frankfurt. Da ein Leistungsschalter bei der Wartung nicht wie erwartet ausgelöst hat, haben vorhandene USV-Anlagen und Diesel-Generatoren nicht gegriffen und ein Stromausfall entstand. Zwar hat dieser Stromausfall nur ca. 10 Minuten gedauert, aber dennoch dafür gesorgt, dass alle Systeme in dem betroffenen Bereich neu starten mussten. Betroffen sind ca. 20 % unserer Kunden.

Zurzeit arbeiten alle verfügbaren Mitarbeiter mit Hochdruck daran, dass Ihre Server schnellstmöglich wieder erreichbar sind.

Der Großteil der betroffenen vServer ist bereits jetzt wieder erreichbar. Alle verbleibenden vServer sollten im Laufe des Tages wieder verfügbar sein.

Wir können leider nicht ausschließen, dass es bis in die späten Abendstunden zu Beeinträchtigungen bei internen Systemen wie z.B. dem PowerPanel kommen kann.

Wir werden Sie jederzeit über den Stand der Dinge der Recovery-Maßnahmen auf dem Laufenden halten und Ihnen auch kurzfristige Rückmeldungen zu Ihrem Server-Status geben.

Wir möchten Sie bitten, die aus diesem Vorfall resultierenden Unannehmlichkeiten zu entschuldigen und versichern Ihnen nochmals, dass wir alles daran setzen, um zügig in den Normalzustand zurückzukehren. Darüber hinaus wird unser Rechenzentrumsbetreiber alle Leistungsschalter nochmals überprüfen, um derartige Vorfälle in Zukunft auszuschließen.

Mit freundlichen Grüßen

Ihr SERVER4YOU-Team

SERVER4YOU.DE.

Neues Sicherheitsfeature für GoogleMail

Bei GoogleMail gibt es ein neues Sicherheitsfeature: Es wird aufgezeichnet – oder man kann eher davon ausegehen, dass es schon vorher aufgezeichnet wird, aber den Benutzer jetzt angezeigt wird – welche Aktivitäten in dem Account in den letzten Stunden (Tagen?) stattfanden.

Es wird aufgeschlüsselt, welcher Art der Zugriff war: IMAP, POP3, Browser oder Mobil. Bei letzterem ist anzunehmen, dass die Java-Anwendungen für Handys entsprechende Informationen senden. Dazu kommt die Uhrzeit und – ganz wichtig – die zugehörige IP. Man kann sich also vergewissern, ob noch eine andere IP unwissentlich im eigenen Account zu schaffen macht – beispielsweise eine geöffnete iGoogle-Seite, die man vergessen hat..

Das nette Zusatzschmanckerl ist aber die Option, alle geöffneten Sessions mit einem Klick ungültig zu machen. Das Problem „Wieder Zuhause, beim Freund vergessen auszuloggen“ sehr schnell lösen.