DNS-Cache-Poisoning
Was ist DNS-Cache-Poisoning?
DNS-Cache-PoisoningEin Angriff, der gefälschte Einträge in den Cache eines DNS-Resolvers einschleust, sodass nachfolgende Anfragen bis zum Ablauf der TTL vom Angreifer gewählte Adressen zurückliefern.
DNS-Cache-Poisoning zielt auf rekursive Resolver ab, indem es sie dazu verleitet, eine gefälschte Antwort anzunehmen, die sie anschließend speichern und ausliefern. Damit sie geglaubt wird, muss eine gefälschte Antwort zum Anfragenamen passen, auf dem richtigen UDP-Port eintreffen und die korrekte 16-Bit-Transaktions-ID (TXID) tragen — klassische Angriffe laufen daher darauf hinaus, diese Felder zu erraten oder das Rennen um sie zu gewinnen, bevor die echte autoritative Antwort eintrifft.
Dan Kaminskys Offenlegung von 2008 (CVE-2008-1447) machte dies praktikabel: Indem er Anfragen für zufällige Subdomains erzwang und den Resolver mit Rateversuchen auf die 16-Bit-TXID überflutete, konnte ein Angreifer beliebig oft weiterversuchen, ohne auf eine zwischengespeicherte negative Antwort warten zu müssen, und so den NS-Eintrag der übergeordneten Domain vergiften. Die Notfallmaßnahme war die Zufallsauswahl des Quellports, die den Rateraum von 16 auf rund 32 Bit erweiterte. 2020 zeigten Forscher der UC Riverside und der Tsinghua-Universität SAD DNS (CVE-2020-25705): einen Seitenkanal im globalen ICMP-Ratelimit-Zähler von Linux, der es einem Off-Path-Angreifer erlaubt, den offenen ephemeren Quellport abzuleiten und diesen Vorteil zunichtezumachen. Linux behob dies durch Randomisierung des ICMP-Ratelimit-Zählers (Kernel 5.10+).
flowchart TD
A[Angreifer löst Anfrage für random.bank.com aus] --> R[Rekursiver Resolver]
R -->|"UDP-Anfrage, zufällige TXID + Quellport"| NS[Echter autoritativer NS]
A -.->|"flutet gefälschte Antworten: rät TXID + Port"| R
R --> M{Passt die gefälschte Antwort<br/>bei Name + Port + TXID<br/>vor der echten Antwort?}
M -->|Ja| P[Vergifteter Eintrag für gesamte TTL gecacht]
M -->|Nein| L[Legitime Antwort gecacht]
P --> V[Alle Resolver-Clients auf Angreifer-IP umgeleitet]Abwehrmaßnahmen: DNSSEC (RFC 4033–4035) signiert Einträge kryptografisch, sodass gefälschte Antworten die Validierung nicht bestehen; 0x20-Groß-/Kleinschreibungs-Randomisierung und Query-Name-Minimierung fügen Entropie hinzu; und verschlüsselte Transporte (DoH/DoT) beseitigen die UDP-Klartext-Angriffsfläche vollständig. Kurze, konservative TTLs begrenzen den Schadensradius, falls ein Poisoning doch gelingt.
● Beispiele
- 01
Der Kaminsky-Angriff von 2008 (CVE-2008-1447), der Schwächen in der Portvorhersagbarkeit großer Resolver ausnutzte.
- 02
SAD DNS (CVE-2020-25705), das Poisoning über einen Seitenkanal im ICMP-Ratelimit wiederbelebte.
● Häufige Fragen
Was ist DNS-Cache-Poisoning?
Ein Angriff, der gefälschte Einträge in den Cache eines DNS-Resolvers einschleust, sodass nachfolgende Anfragen bis zum Ablauf der TTL vom Angreifer gewählte Adressen zurückliefern. Es gehört zur Kategorie Angriffe und Bedrohungen der Cybersicherheit.
Was bedeutet DNS-Cache-Poisoning?
Ein Angriff, der gefälschte Einträge in den Cache eines DNS-Resolvers einschleust, sodass nachfolgende Anfragen bis zum Ablauf der TTL vom Angreifer gewählte Adressen zurückliefern.
Wie schützt man sich gegen DNS-Cache-Poisoning?
Schutzmaßnahmen gegen DNS-Cache-Poisoning kombinieren typischerweise technische Kontrollen und operative Praktiken, wie in der Definition oben beschrieben.
Welche anderen Bezeichnungen gibt es für DNS-Cache-Poisoning?
Übliche alternative Bezeichnungen: Cache-Vergiftung, DNS-Spoofing (Cache).