Skip to content

Angriffe auf TCP/IP (6) - DNS Cache Pollution

Geschrieben von Carsten Eilers am um 08:52

Das in der vorherigen Folge vorgestellte DNS-Spoofing ist nicht die einzige Möglichkeit, den DNS-Cache eines Rechners zu manipulieren. Eine weitere ist die sog.

(DNS) Cache Pollution

Beim 'Cache Pollution'-Angriff wird ausgenutzt, dass manche Nameserver beliebige empfangene Daten in ihren Cache speichern. Ursprünglich wurde das Verfahren zur Effizienzsteigerung verwendet: Wenn nach einem bestimmten DNS-Eintrag, z.B. dem Mailserver einer Domain, gefragt wird, ist die Wahrscheinlichkeit hoch, das danach auch z.B. ihre IP-Adresse benötigt wird. Um diese Anfrage einzusparen, werden bei der Antwort außer der angeforderten Information auch weitere zur betroffenen Domain gehörende Daten in so genannten Additional Resource Records (RR) mitgeschickt. Ein Angreifer kann dies ausnutzen, um über einen unter seiner Kontrolle stehenden Nameserver zusätzlich falsche Daten mitzuschicken.

Beim Beispiel aus der vorherigen Folge schickt der Angreifer bei der Antwort auf die Frage nach total.unwichtig.example ungefragt zusätzlich die Information www.spoof.example = e.f.g.h mit, siehe Abb. 1.

Der Nameserver des Opfers, dns.opfer.example, speichert die Daten in seinem Cache und verwendet sie später, um die Anfrage des Opfers damit beantworten.

DNS-Spoofing: Cache Pollution
Abb. 1: DNS-Spoofing: Cache Pollution (Klick für großes Bild in neuem Fenster/Tab)

Inzwischen prüfen die meisten Nameserver zur Verhinderung derartige Angriffe zusätzlich übertragene Daten. Informationen, die weder zur Anfrage gehören noch von einem zuständigen Nameserver stammen, werden verworfen. Diese Prüfungen werden 'Bailiwick Checking' genannt: Zusätzliche Informationen werden immer nur für die abgefragte Domain akzeptiert ('in-bailiwick'). Damit wird verhindert, dass dem Server bei der Anfrage nach www.server.example in der Antwort zusätzlich noch Informationen über www.anderer-server.example untergeschoben werden - diese RRs sind 'out-bailiwick' und werden ignoriert.

Statt nur den Eintrag für einen normalen Server zu fälschen, könnte der Angreifer sich auch als zuständiger Nameserver für eine ganze Top Level Domain (z.B. .com) ausgeben. Danach würden alle Anfragen nach Domains aus diesem Bereich an den Angreifer gesendet, der sie nach Belieben mit richtigen oder falschen Daten beantworten könnte. Der letzte großangelegte Angriff dieser Art fand im Frühjahr 2005 statt. Ziel war die Verbreitung von Schadsoftware: Anwender wurden auf Webseiten umgeleitet, die Windows-Rechner über Schwachstellen im Internet Explorer mit Spyware infizierten.

Eigentlich dachte man 2005 schon, dass das Problem "DNS Cache Poisoning" seit langem gelöst war - der Angriff auf .com bewies das Gegenteil. Die Angreifer mussten nur ein passende Schwachstelle bzw. angreifbare Clients oder Server finden, und schon war ein Angriff wieder möglich.

2008: Der Angriff von Dan Kaminsky

Anfang Juli 2008 wurde eine von Dan Kaminsky entdeckte Design-Schwachstelle in der DNS-Spezifikation bekannt, die Cache-Poisoning-Angriffe sehr einfach möglich macht (CVE-2008-1447). Gleichzeitig wurden Patches für verbreitete Nameserver bereit gestellt. Eigentlich sollten Details zur Schwachstelle erst im August auf der Black Hat USA 2008 veröffentlicht werden, durch unglückliche Umstände wurden sie jedoch bereits Ende Juli bekannt.

Halvar Flake hatte in seinem Blog über die Ursache der Schwachstelle spekuliert und dabei ziemlich nah ans Schwarze getroffen. Im Blog von Matasano wurden daraufhin Details zur Schwachstelle veröffentlicht, aber sehr schnell wieder gelöscht.

Nun gibt es zwischen "Daten im Internet veröffentlichen" und "Diese Daten wieder löschen" einen grundsätzlichen Widerspruch - was einmal veröffentlicht wurde, lässt sich nicht wieder unbekannt machen. Schon kurze Zeit später waren die Informationen an etlichen Stellen im Internet abrufbar.

Thomas Ptacek von Matasano veröffentlichte kurz darauf eine Entschuldigung: Nachdem Dan Kaminsky ihm die Schwachstelle erläutert hatte, wurde ein entsprechender Text vorbereitet und auf dem Server gespeichert. Er sollte entweder nach der bereits angekündigten Veröffentlichung der Schwachstelle durch Dan Kaminsky auf der Black Hat oder nach einer anderen offiziellen Veröffentlichung erscheinen.

Was schon mal umgeschickt ist, eigentlich sollte damals schon allgemein bekannt gewesen sein, dass man nichts, was (noch) nicht zur Veröffentlichung vorgesehen ist, auf dem Webserver speichert. Noch schlimmer wurde das Ganze dadurch, dass dieser vorbereitete Text dann aus Versehen automatisch veröffentlicht wurde.

Wenige Tage später wurden erste Exploits veröffentlicht, z.B.:

Und kurze Zeit später begannen die ersten Angriffe.

Der Kaminsky-Angriff im Überblick

Dan Kaminsky hat die Details zur Design-Schwachstelle in einem Vortrag auf der Black Hat USA 2008 präsentiert (Audio/Video). Die Präsentation des Vortrags steht in seinem Blog zum Download bereit .

Um in einem Nameserver den Eintrag für www.opfer.example mit der IP-Adresse 1.2.3.4 zu vergiften, geht der Angreifer vereinfacht folgendermaßen vor:

  1. Er fragt den Nameserver nach $irgendwas.opfer.example, wobei $irgendwas eine beliebige Zeichenkette ist
  2. Er sendet sofort danach viele gefälschte Antworten mit unterschiedlichen IDs an den Nameserver, in denen er behauptet, dass der für $irgendwas.opfer.example zuständige Nameserver www.opfer.example ist und die IP-Adresse 1.2.3.4 hat.
  3. Schlägt der Angriff fehl, weil der für opfer.example zuständige Nameserver schneller war oder nicht die richtige ID erraten wurde, wird er sofort mit einem neuen Wert für $irgendwas wiederholt.

Versucht der Angreifer, den DNS-Eintrag für www.opfer.example direkt zu vergiften, muss er schneller als der zuständige Nameserver antworten und die richtige ID erraten. Ist er zu langsam, ist der nächste Angriff erst wieder möglich, wenn die Lebensdauer (TTL, Time to Life) des Eintrags abgelaufen ist. Durch die Verwendung unsinniger Domains und das sofortige Senden der Antworten hat er im Wettlauf mit dem zuständigen Nameserver einen Vorteil und muss 'nur noch' die richtige ID erraten, von denen es nur 65536 gibt - seine Chancen stehen also 1 zu 65535.

Um diese Angriffe zu erschweren, wird nun zusätzlich auch der Quell-Port für die DNS-Abfragen zufällig gewählt. Der Angreifer muss also für einen erfolgreichen Angriff ID und Quell-Port richtig erraten. Damit sinkt die Wahrscheinlichkeit für einen erfolgreichen Angriff auf 1 zu 163.840.000 bis 1 zu 2.147.483.648.

Ein effektiver Schutz des DNS wird durch den Einsatz von Kryptographie erreicht: Die "Domain Name System Security Extensions" (DNSSEC) erweitern das DNS um Mechanismen zur Gewährleistung der Authentizität und Integrität der Daten.

DNSSEC werde ich in einer späteren Folge beschreiben, in der nächsten Folge geht es um einen weiteren Angriff auf TCP/IP: HTTP-Hijacking.

Carsten Eilers

> </div> <footer class= Kategorien: Grundlagen

Trackbacks

Keine Trackbacks