DNS-Spoofing und Cache-Poisoning

DNS-Spoofing bezeichnet das Bereitstellen einer gefälschten DNS-Antwort, sodass das Opfer einen Namen in eine vom Angreifer kontrollierte IP-Adresse auflöst. Cache-Poisoning ist eine spezielle Form davon: Die gefälschte Antwort wird von einem rekursiven Resolver akzeptiert und gespeichert, wodurch jeder Client infiziert wird, der ihn verwendet.

Das Ziel ist meist die Umleitung des Datenverkehrs: Benutzer werden auf Phishing-Seiten, Malware-Downloads oder Man-in-the-Middle-Proxys geleitet.

Wenn ein Resolver eine Anfrage sendet, versucht ein Angreifer, eine gefälschte Antwort einzuschleusen, bevor der legitime autoritative Server antwortet. Trifft die Fälschung zuerst ein und stimmen die erwarteten Felder überein, gewinnt sie die Race Condition und wird im Cache gespeichert.

Deshalb sind Latenz, Paketreihenfolge und der ausgehende Port des Resolvers für Angriff und Abwehr von großer Bedeutung.

Damit eine gefälschte UDP-Antwort akzeptiert wird, muss der Angreifer Folgendes korrekt erraten:

• Die Quell-IP-Adresse (des autoritativen Servers).
• Den Zielport (den ausgehenden Port des Resolvers).
• Den Abfragenamen und den Abfragetyp.
• Die 16-Bit-Transaktions-ID (TXID).

Ohne Schutzmechanismen ist nur die TXID wirklich geheim, was pro Paket einer Wahrscheinlichkeit von ungefähr 1 zu 65.536 entspricht.

Die Veröffentlichung von Dan Kaminsky aus dem Jahr 2008 zeigte, dass Poisoning deutlich einfacher war als angenommen. Statt eine Race Condition pro Record auszulösen, fragt der Angreifer viele nicht existierende Subdomains ab (aaa.bank.com, aab.bank.com ...) und überflutet das Ziel mit gefälschten Antworten, die einen bösartigen NS- oder Glue-Record für die gesamte Domain enthalten.

Jeder Versuch ist eine neue Race Condition, und ein nicht erfolgreicher Lookup wird nicht gecacht. Daher kann der Angreifer den Vorgang so lange wiederholen, bis ein Treffer gelingt und die gesamte Zone vergiftet wird.

Die wichtigste Gegenmaßnahme nach Kaminsky war die Randomisierung des Quellports. Statt einen festen ausgehenden Port zu verwenden, wählt der Resolver für jede Anfrage einen zufälligen ephemeren Port.

Nun muss der Angreifer sowohl die TXID (16 Bit) als auch den Quellport (etwa 16 Bit) erraten, wodurch sich der Suchraum auf ungefähr 2^32 erweitert. Das macht blindes Off-Path-Poisoning praktisch undurchführbar, wenn auch nicht bei Implementierungen mit schwacher Entropie unmöglich.

Ein Off-Path-Angreifer kann die Anfrage nicht sehen und muss TXID und Port blind erraten. Ein On-Path-Angreifer (manipuliertes WLAN, kompromittierter Router oder Internetanbieter) kann die Anfrage direkt mitlesen und problemlos eine passende Antwort erstellen.

On-Path-Spoofing setzt die Port-Randomisierung vollständig außer Kraft. Deshalb sind verschlüsselter Transport und DNSSEC-Validierung erforderlich, um eine starke Absicherung zu erreichen, nicht nur zusätzliche Entropie.

Angreifer fälschen nicht immer Pakete. Ein nicht autorisierter DHCP-Server kann Clients die Adresse eines bösartigen DNS-Resolvers übergeben, sodass jede Auflösung vom Angreifer beantwortet wird. Auch Malware schreibt /etc/resolv.conf oder Routereinstellungen um.

Historische Bedrohungen wie die Malware DNSChanger leiteten den DNS-Verkehr der Opfer jahrelang unbemerkt auf betrügerische Server um. Prüfen Sie, welche Resolver Ihre Geräteflotte tatsächlich verwendet.

Resolver setzen Bailiwick-Regeln durch: Eine Antwort darf nur Datensätze für Namen innerhalb der Zone liefern, für die der Server autoritativ ist. Eine Antwort für bank.com kann keinen Datensatz für unrelated.com einschleusen.

Dadurch werden Injektionen nach dem Kaminsky-Muster auf die abgefragte Domain beschränkt und wird verhindert, dass eine vergiftete Antwort unabhängige Zonen verunreinigt. Überprüfen Sie, ob Ihr Resolver eine strikte Bailiwick-Filterung durchsetzt.

Anzeichen für ein laufendes oder erfolgreiches Poisoning:

• Ein sprunghafter Anstieg von Abfragen für zufällige, nicht existierende Subdomains.
• Doppelte oder nicht in der richtigen Reihenfolge eintreffende DNS-Antworten für dieselbe TXID.
• Aufgelöste IP-Adressen, die plötzlich auf unerwartete ASNs oder geografische Regionen verweisen.
• Abweichungen zwischen den Antworten des Resolvers und einer vertrauenswürdigen Abfrage über einen unabhängigen Kanal.

Keine einzelne Maßnahme reicht aus. Kombinieren Sie:

• Randomisierung von Quellport und TXID, um den Aufwand für Off-Path-Angreifer zu erhöhen.
• DNSSEC-Validierung, damit gefälschte Antworten die Signaturprüfung nicht bestehen.
• DoT/DoH, um On-Path-Angreifern Einblick und Manipulation zu verwehren.
• 0x20-Kodierung (zufällige Groß- und Kleinschreibung in Abfragenamen) für zusätzliche Entropie.
• Überwachung auf NXDOMAIN-Floods und Anomalien in Antworten.

In der Praxis ist blindes Off-Path-Cache-Poisoning bei gepatchten Resolvern heute selten, tritt aber über Seitenkanäle wieder auf, beispielsweise durch UDP-Fragmentierung und ICMP-basierte Angriffe zur Port-Inferenz wie SAD DNS. Halten Sie Resolver durchgehend gepatcht und bevorzugen Sie validierende, verschlüsselte Resolver.

Denken Sie daran: Die DNS-Kompromittierung mit den größten Auswirkungen ist oft kein ausgeklügelter Poisoning-Angriff, sondern ein gestohlenes Registrar-Konto. Schützen Sie beide Seiten.

DNS-Spoofing fälscht Antworten; Cache-Poisoning sorgt dafür, dass sie in einem Resolver bestehen bleiben. Akzeptiert wird eine Antwort nur, wenn Quell-IP, Port, Abfragename und TXID übereinstimmen. Die Randomisierung des Quellports und Bailiwick-Prüfungen haben die Hürde für Off-Path-Angreifer erhöht, doch On-Path-Angreifer und Seitenkanäle bleiben relevant.

Eine mehrschichtige Verteidigung (Entropie, DNSSEC-Validierung, verschlüsselter Transport und Überwachung) ist unerlässlich. Als Nächstes sehen wir uns an, wie Angreifer DNS missbrauchen, um Daten zu übertragen: Tunneling und Datenexfiltration.