Details zum DNS-Sicherheitsproblem veröffentlicht

Offenbar sind die näheren Hintergründe zu den verbesserten Cache-Poisoning-Angriffen aus Versehen veröffentlicht worden. Auch das bislang fehlende Puzzle-Teil wurde beschrieben. Mit Angriffen dürfte in Kürze zu rechnen sein.

In Pocket speichern vorlesen Druckansicht 186 Kommentare lesen
Lesezeit: 3 Min.
Von
  • Daniel Bachfeld

Jetzt ist die Katze aus dem Sack: Mehr oder minder aus Versehen wurden erhellende Details zum DNS-Sicherheitsproblem publik, bevor Dan Kaminsky sie selbst auf der kommenden Black-Hat-Konferenz veröffentlichen konnte. Das Stichwort des vereinfachten Cache-Poisoning-Angriffs heißt offenbar "in-bailiwick-Records". Mit Bailiwick Checking akzeptiert ein Caching Nameserver in einer Antwort eines anderen Servers keine ungefragt mitgelieferten Additional Resource Records mehr, wenn sie nicht aus der angefragten Domain stammen (out-of-bailiwick). Somit verhindert der Server, dass ihm bei Anfragen für www.example.com ein Eintrag für www.noexample.com untergeschoben wird.

In Kombination mit der DNS-Geburtstagsattacke gelingt es einem Angreifer aber dennoch, den Cache erfolgreich zu manipulieren. Dazu bringt er den Server seines Opfers etwa mit Links in Mails an Anwender dazu, bestimmte Adresse abzufragen, etwa aaa.example.com, aab.example.com, aac.example.com und so weiter. Für jede dieser Anfragen benutzt der Nameserver des Opfers eine eigene Transaktions-ID. Je mehr Transaktions-IDs verbraucht sind, desto großer ist die Chance für den Angreifer, mit einer gefälschten Antwort und einer erratenen ID eine richtige ID zu treffen. Zwar ist die Wahrscheinlichkeit, einen Treffer für www.example.com zu landen, immer noch recht gering, trägt der Angreifer aber in jede Antwort den Additional Resource Record (RR) für www.example.com mit der IP des von ihm kontrollierten Servers ein, so kann er den Cache trotzdem manipulieren – denn der RR ist "in-bailiwick".

Laut Matasano Security, die die Details zu der Lücke kurzzeitig in ihrem Blog veröffentlicht hatten, benötigt ein Angreifer für solch eine Attacke über eine schnelle Internet-Verbindung nur 10 Sekunden. Mittlerweile ist der Eintrag wieder aus dem Blog entfernt – selbst aus dem Google-Cache. Im Pastebin auf amd.co.at ist aber noch eine Kopie zu finden. Matasano hatte die Details aufgrund einer Spekulation im Blog des Sicherheitsspezialisten Thomas Dullien (aka Halvar Flake) veröffentlicht. Warum Matasano dann aber vorpreschte und alle Details ausplauderte, ist unklar. Schließlich waren die von Dullien geäußerten Vermutungen bereits am Tage der Veröffentlichungen der Lücke in der Warnung des US-CERTs skizziert. Dan Kaminsky bestätigte inzwischen per Twitter, dass Halvar Flake mit seiner Vermutung richtig lag: "Ihr müsst patchen oder zu OpenDNS wechseln, und zwar SOFORT".

Damit ist ein weiteres Stichwort geliefert. Administratoren sollen nun nicht mehr zögern und die für ihren Nameserver verfügbaren Patches installieren. Die sorgen dafür, dass durch die Zufälligkeit des Source-Ports einer DNS-Anfrage der Angreifer nicht nur die Transaktion-ID erraten muss, sondern zusätzlich den UDP-Port. Letztlich löst dies das Problem nicht wirklich, sondern sorgt nur für einen Aufschub. In der Diskussion ist daher die flächendeckende Einführung von DNSSEC, weil dabei die Authentizität des antwortenden Servers per PKI-Schlüsselabgleich überprüft wird.

Eine Demo, wie DNS funktioniert, wie man es angreifen kann und wann DNSSEC schützt, ist auf den Seiten der IKS-Jena zu finden.

Siehe dazu auch:

(dab)