DNS-Spoofing

Der Angriff zielt nicht auf die Verbindung, sondern auf die Wegfindung davor. Wer bestimmt, welche IP-Adresse hinter einem Namen steckt, bestimmt, mit wem das Opfer spricht — ganz ohne Eingriff in die eigentliche Datenübertragung.

Warum das überhaupt geht

Eine DNS-Abfrage läuft klassisch über UDP, ohne Verbindungsaufbau und ohne kryptografische Prüfung. Eine Antwort gilt als gültig, wenn vier Dinge stimmen: Sie kommt von der befragten Adresse, trifft auf dem richtigen Port ein, trägt die passende Transaktionskennung und enthält die gestellte Frage.

Alle vier lassen sich fälschen. Die Absenderadresse eines UDP-Pakets kann frei eingetragen werden, die Frage kennt der Angreifer, und die Kennung ist 16 Bit lang — 65.536 Möglichkeiten. Gewinnt die gefälschte Antwort das Rennen gegen die echte, wird sie angenommen und die echte verworfen.

Die Spielarten

Cache Poisoning. Angegriffen wird nicht der Nutzer, sondern der Resolver seines Anbieters. Eine einmal eingeschleuste Antwort liegt dort für die Dauer ihrer Gültigkeit und wird an alle Nutzer dieses Resolvers ausgeliefert. Ein Treffer, viele Opfer — der wirksamste Weg.

Antwort im lokalen Netz. Im selben Netzsegment, etwa in einem offenen WLAN, muss der Angreifer nicht raten: Er sieht die Anfrage und antwortet schneller als der echte Server.

Manipulierter Resolver. Schadsoftware ändert die konfigurierten DNS-Server des Geräts oder des Routers. Technisch kein Spoofing mehr, in der Wirkung dasselbe — und in der Praxis der häufigste Fall.

Umschreiben auf dem Weg. Netzbetreiber, die DNS-Antworten verändern, um Sperren umzusetzen oder Fehlerseiten auszuliefern, nutzen dieselbe Mechanik mit anderer Absicht.

Kaminsky

2008 wurde der Angriff grundlegend verschärft. Bis dahin galt: Wer eine Antwort fälschen will, muss im engen Zeitfenster einer laufenden Anfrage treffen, und bei Misserfolg sperrt der Zwischenspeicher mit dem echten Eintrag weitere Versuche für Stunden.

Dan Kaminskys Verfahren umgeht die Sperre, indem es nach nicht existierenden Namen fragt — a1.example.net, a2.example.net und so weiter. Für die gibt es keinen Eintrag im Zwischenspeicher, also lässt sich beliebig oft neu versuchen. Und die gefälschte Antwort enthält nicht die Adresse des erfragten Namens, sondern einen Verweis auf einen neuen Namensserver für die ganze Zone.

Damit wurde aus einem Glücksspiel mit einem Versuch je Stunde ein Angriff von Minuten.

Die Gegenmaßnahmen

Zufall bei der Quellportwahl. Die unmittelbare Antwort auf Kaminsky: Zusätzlich zur 16 Bit langen Kennung wird der Quellport zufällig gewählt. Zusammen ergibt das etwa 32 Bit zu erratender Werte statt 16 — der Aufwand steigt um das Zehntausendfache. Das ist seither Pflicht für Resolver, aber nur eine Erschwerung, kein Beweis.

Zufällige Groß- und Kleinschreibung. Der Resolver variiert die Schreibweise des angefragten Namens und erwartet sie in der Antwort unverändert zurück. Da DNS-Namen bei der Auflösung nicht zwischen Groß- und Kleinschreibung unterscheiden, kostet das nichts und bringt einige zusätzliche Bits Entropie.

DNS-Cookies. Ein Kennzeichen, das Client und Server austauschen und das ein Angreifer ohne Mitlesen nicht kennt.

DNSSEC. Die einzige Maßnahme, die den Angriff nicht erschwert, sondern beendet. Eine gefälschte Antwort trägt keine gültige Signatur, und ein validierender Resolver verwirft sie unabhängig davon, wie geschickt sie eingeschleust wurde. Das gilt allerdings nur, wenn die Zone signiert und der Resolver validierend ist.

Verschlüsselter Transport. DNS over HTTPS und DNS over TLS verhindern, dass ein Dritter auf dem Weg die Antwort ersetzt. Gegen einen manipulierten oder böswilligen Resolver helfen sie nicht — der Angriff verlagert sich dann nur auf dessen Betreiber.

Warum TLS den Schaden begrenzt

Eine erfolgreich gefälschte Antwort liefert dem Angreifer den Verkehr, aber nicht automatisch den Inhalt. Für eine HTTPS-Seite bräuchte er zusätzlich ein gültiges Zertifikat für den Namen — und das bekommt er nicht, weil er den Namen nicht kontrolliert.

Praktisch bedeutet das: Beim Aufruf einer HTTPS-Seite endet der Angriff in einer Zertifikatswarnung. Mit HSTS endet er ohne Warnung in einem Abbruch, weil der Nutzer gar nicht weiterklicken kann.

Umgekehrt zeigt das, wo DNS-Spoofing weiterhin wirkt: bei unverschlüsselten Protokollen, bei Software, die Zertifikate nicht prüft, bei automatischen Aktualisierungen ohne Signaturprüfung — und bei der Ausstellung von Zertifikaten selbst, denn die Prüfung der Domaininhaberschaft läuft ihrerseits über DNS.