DNS Cache Poisoning - Kaminsky-Angriff und DNS-Spoofing - Definition & Erklärung

DNS Cache Poisoning (DNS-Spoofing) ist ein Angriff bei dem gefälschte DNS-Antworten in den Cache eines rekursiven Resolvers eingeschleust werden. Alle Nutzer die diesen Resolver verwenden, erhalten daraufhin falsche IP-Adressen und werden auf Server des Angreifers umgeleitet - ohne sichtbare Warnung im Browser (da der Domain-Name korrekt erscheint).

DNS-Grundprinzip und Angriffsfläche

Normaler DNS-Ablauf

Wenn ein Browser die IP-Adresse einer Domain benötigt, läuft folgende Kette ab: Der Browser fragt den lokalen Resolver (z.B. 8.8.8.8), dieser - falls kein Cache-Treffer - den Root-Nameserver, dann den .de-Nameserver und schließlich den Authoritative-Nameserver von bank.de. Die Antwort (z.B. 203.0.113.1) wird zurückgegeben und vom Resolver für die Dauer der TTL (z.B. 300 Sekunden) gecacht. Der Browser öffnet daraufhin die erhaltene IP-Adresse.

Die Angriffsfläche

Der Resolver cached Antworten für spätere Anfragen. Wenn es einem Angreifer gelingt, eine gefälschte Antwort vor der echten einzuschleusen, cached der Resolver für die gesamte TTL-Dauer die falsche IP. Alle Nutzer werden dann für TTL-Sekunden zum Angreifer-Server umgeleitet.

Klassischer Birthday-Attack-Ansatz (vor Kaminsky)

Der ursprüngliche Angriff basierte auf dem Raten der 16-Bit Transaction-ID (65.536 mögliche Werte) von DNS. Da ein Resolver jedoch pro Name nur einmal fragt, gab es zu wenig Versuche für einen praktikablen Angriff - bis Dan Kaminsky 2008 den entscheidenden Durchbruch erzielte.

Kaminsky-Angriff (2008)

Die clevere Idee (CVE-2008-1447)

Dan Kaminsky erkannte: Anstatt auf die Antwort für bank.de zu warten, fragt man nach zufälligen Subdomains. Der Resolver hat keine gecachten Antworten für xyz123.bank.de und muss den Nameserver von bank.de anfragen - was beliebig oft wiederholbar ist.

Der Angriff in drei Schritten

Schritt 1: Der Angreifer sendet Anfragen für ZUFAELLIG.bank.de, NOCHZUFAELLIG.bank.de usw. Da es sich um zufällige Subdomains handelt, gibt es keine Cache-Treffer - der Resolver muss den Nameserver von bank.de befragen.

Schritt 2: Gleichzeitig sendet der Angreifer tausende gefälschte Antworten - nicht nur für die angefragte Subdomain, sondern mit einem entscheidenden Zusatz in der ADDITIONAL-Sektion:

Gefälschte Antwort für: xyz123.bank.de = 198.51.100.99
ADDITIONAL-Sektion:     bank.de Nameserver = ns.attacker.com
                        ns.attacker.com    = 198.51.100.99

Schritt 3: Wenn eine gefälschte Antwort akzeptiert wird, cached der Resolver nicht nur die Subdomain - er cached den gesamten Nameserver für bank.de als Angreifer-Server. Alle zukünftigen bank.de-Anfragen werden dann zu ns.attacker.com geleitet.

Warum so gefährlich?

Mit einer schnellen Verbindung lassen sich Millionen gefälschter Pakete pro Sekunde senden. Die 16-Bit Transaction-ID (65.536 Werte) kombiniert mit dem bekannten Source-Port 53 ergibt nur 65.536 mögliche Kombinationen - bei gezielten Versuchen dauerte der Angriff etwa 30 Sekunden bis zum Treffer. Betroffen waren nahezu alle rekursiven Resolver weltweit.

Patch (RFC 5452)

Die Gegenmaßnahme war Query Source Port Randomisierung: Statt immer Port 53 als Source-Port zu verwenden, wird ein zufälliger Port zwischen 1024 und 65535 gewählt. Damit ergibt sich eine 32-Bit-Entropie (16-Bit TxID × 16-Bit Port = 4 Milliarden Kombinationen). Der Angriff dauert nun Wochen statt Sekunden.

Moderne Angriffsvarianten

Variante 1 - On-Path Angriff (klassisches MITM)

Ein Angreifer im gleichen Netzwerk (WLAN, kompromittierter ISP) setzt ARP-Spoofing auf dem Gateway ein und positioniert sich zwischen Client und Resolver. Da er DNS-Anfragen sehen kann, kennt er die Transaction-ID und antwortet sofort mit einer gefälschten IP - kein Raten notwendig.

Schutz: DNS-over-HTTPS (DoH) oder DNS-over-TLS (DoT) verschlüsseln den DNS-Traffic und verhindern das Mitlesen.

Variante 2 - SAD DNS (2020, CVE-2020-25705)

Dieser Side-Channel-Angriff nutzt ICMP-Fehlermeldungen: Der Angreifer sendet UDP-Pakete an den Resolver. ICMP “Port Unreachable”-Antworten verraten, ob ein bestimmter Source-Port vom Resolver verwendet wird. Damit lässt sich der Source-Port in unter 30.000 Versuchen ermitteln, was Cache-Poisoning wieder praktikabel macht.

Patch: ICMP-Rate-Limiting und nichtlineare Port-Randomisierung.

Variante 3 - Resolver-zu-Nameserver-Kanal angreifen

Klassisches DNS zwischen Resolver und Nameserver ist unverschlüsselt. BGP-Hijacking kann das Routing von Nameserver-Anfragen umleiten. Ein Angreifer auf dem BGP-Pfad antwortet dann als gefälschter Nameserver.

Schutz: DNSSEC schützt durch kryptografische Signierung der DNS-Antworten.

Variante 4 - TTL-Manipulation

Der Angreifer injiziert eine gefälschte Antwort mit hoher TTL (z.B. 86400 Sekunden = 1 Tag). Selbst wenn der Angriff entdeckt wird, bleibt der Schaden einen Tag lang bestehen. Gegenmaßnahme: Minimale TTLs nach Erkennung setzen und Caches flushen.

DNSSEC als Schutzmaßnahme

Wie DNSSEC funktioniert

DNSSEC fügt kryptografische Signaturen zu DNS-Antworten hinzu:

Die DNS-Zone wird mit einem privaten Schlüssel signiert: Jeder A-Record erhält einen RRSIG-Record
Der öffentliche Schlüssel wird im DNSKEY-Record published
Eine Vertrauenskette läuft via DS-Records bis zur Root-Zone

Der Resolver prüft die Signatur (RRSIG), die Authentizität des Schlüssels (DS-Record im übergeordneten Nameserver) und NSEC/NSEC3 für die nachweisbare Nicht-Existenz von Records. Eine gefälschte Antwort ohne gültige Signatur führt zu SERVFAIL - kein Cache-Poisoning möglich.

DNSSEC-Verifikation prüfen

dig +dnssec bank.de A
# RRSIG-Record in der Antwort zeigt die Signatur
# "ad" Flag (Authenticated Data) bedeutet: DNSSEC validiert!

DNSSEC-Schwächen

DNSSEC schützt nicht alles: Ohne NSEC3 ist Zone-Enumeration möglich (NSEC3 als Schutz einsetzen). Der Inhalt der DNS-Kommunikation ist nicht verschlüsselt, nur die Herkunft wird authentifiziert. Der Betrieb ist operationell komplex durch Key-Rollover und Signing-Prozesse. DNSSEC-Antworten sind deutlich größer als normale DNS-Antworten, was das Amplification-Potential bei DDoS-Angriffen erhöht.

Implementierungsstand in Deutschland (2024)

Etwa 60% der .de-Domains haben DS-Records (DNSSEC-signiert). DNSSEC schützt aber nur, wenn auch ein validierender Resolver genutzt wird. Google (8.8.8.8) und Cloudflare (1.1.1.1) validieren DNSSEC. Viele ISP-Resolver validieren DNSSEC hingegen nicht - wer auf solche Resolver angewiesen ist, hat keinen DNSSEC-Schutz.

Erkennungsmethoden

Monitoring von DNS-Antworten

Durch Vergleich von DNS-Antworten mehrerer unabhängiger Resolver lassen sich Abweichungen erkennen, die auf Cache-Poisoning hindeuten:

# IP für bank.de von 5 verschiedenen Resolvern abfragen:
for resolver in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222 4.2.2.1; do
    echo -n "$resolver: "
    dig @$resolver bank.de A +short
done
# Unterschiedliche IPs → Anomalie!

Passive DNS Monitoring

Sicherheitsanbieter wie Farsight DNSDB und PassiveTotal sammeln historische DNS-Antworten. Wenn die IP einer Domain plötzlich wechselt, wird ein Alert ausgelöst. Dieser Ansatz hilft auch bei der nachträglichen Forensik.

Client-seitige Erkennung via DANE

DANE (DNS-based Authentication of Named Entities) verankert den TLS-Zertifikat-Hash in einem TLSA-Record im DNS. Der Browser prüft, ob das Server-Zertifikat mit dem TLSA-Record übereinstimmt. Bei einer gefälschten IP würde ein falsches Zertifikat präsentiert, was einen TLSA-Mismatch und eine Warnung auslöst.

Schutzmaßnahmen

Für DNS-Betreiber (Nameserver-Administratoren)

DNSSEC implementieren (Zone signieren)
Key-Rollover-Prozesse einplanen (typisch: 5-Jahres-Zyklen)
Minimale TTLs bei Verdacht setzen (schnelles Recovery)
Rate-Limiting auf ICMP (SAD DNS Mitigation)

Für Resolver-Betreiber (Unternehmen mit eigenem DNS)

Query Source Port Randomisierung aktivieren
DNSSEC-Validierung aktivieren (BIND: dnssec-validation auto;)
DNS-over-TLS (DoT) für Upstream-Queries nutzen
0x20-Encoding: Anfragen mit zufälliger Groß-/Kleinschreibung randomisieren
Response Rate Limiting (RRL) aktivieren

Für Endnutzer und Unternehmen

DNS-over-HTTPS (DoH): Verschlüsselung verhindert On-Path-Angriffe. In Firefox und Chrome aktivierbar, Cloudflare (1.1.1.1) und Quad9 (9.9.9.9) unterstützen DoH.
Einen validierenden DNSSEC-Resolver nutzen (nicht alle ISP-Resolver validieren)
Im Unternehmen einen eigenen validierenden Resolver mit DNSSEC betreiben

Für Entwickler und Applikationsebene

HSTS und HSTS-Preloading: HTTPS erzwingen, auch wenn die IP falsch ist
Certificate Pinning: Zertifikat des echten Servers im Client verankern
DANE/TLSA-Records: TLS-Zertifikat im DNS verankern