DNS-Spoofing ist eine Form von Cyberangriff, bei der die Zuordnung der IP-Adresse zu einer Domain manipuliert bzw. gefälscht wird. Ziel ist es, den Datenverkehr auf den Computer des Angreifers zu leiten bzw. den Benutzer anstatt auf die eigentliche Website auf eine falsche, meist schädliche Website zu leiten. DNS-Spoofing wird häufig eingesetzt, um Phishing-Angriffe durchzuführen, Schadsoftware zu verbreiten oder vertrauliche Daten abzugreifen.

Es gibt verschiedene Möglichkeiten DNS-Spoofing durchzuführen: Durch Nutzung von Schwachstellen im DNS-Protokoll, mittels IP-Spoofing oder lokal, etwa durch manipulierte Hosts-Dateien.

Eine häufige Variante ist DNS-Cache-Poisoning, bei der gefälschte Einträge in den Cache (Zwischenspeicher) des DNS-Servers eingeschleust werden. Dadurch gibt der DNS-Server eine falsche Antwort zurück, z. B. eine gefälschte IP-Adresse. Die direkte Übersetzung von DNS-Cache-Poisoning ist „DNS-Zwischenspeicher-Vergiftung“.

Das DNS funktioniert ähnlich wie eine Telefonauskunft. Der Benutzer kennt die Domain (den für Menschen merkbaren Namen eines Rechners im Internet) – zum Beispiel example.org. Diese sendet er als Anfrage in das Internet. Die Domain wird dann dort vom DNS in die zugehörige IP-Adresse (die „Anschlussnummer“ im Internet) umgewandelt – zum Beispiel eine IPv4-Adresse der Form 192.0.2.42 oder eine IPv6-Adresse wie 2001:db8:85a3:8d3:1319:8a2e:370:7347 – und führt so zum richtigen Rechner. Wenn der DNS-Server die angeforderte Übersetzung nicht kennt, fragt er einen anderen Server. Der Prozess geht also rekursiv weiter. Um die Performance zu erhöhen, merken sich die Server die Übersetzungen für eine bestimmte Zeit in ihrem Zwischenspeicher. Das heißt, wenn der Server die gleiche Anfrage für eine Übersetzung erhält, wird er, solange der Zwischenspeicher nicht abläuft, die Anfrage ausführen können, ohne einen anderen Server zu kontaktieren.

Wenn der DNS-Server eine falsche Übersetzung erhält und diese aufgrund der Leistungsoptimierung zwischenspeichert, spricht man von einem vergifteten Zwischenspeicher (poisoned cache). Der Server gibt die Falschinformation auch an andere Benutzer weiter, welche dann an an einen anderen Computer, beispielsweise den des Angreifers, umgeleitet werden.^[1]

Beim dieser Variante des DNS-Spoofing gibt sich der Angreifer mittels IP-Spoofing als legitimer DNS-Server aus und sendet eine gefälschte Antwort auf eine DNS-Anfrage des Opfers. Damit der Angriff erfolgreich ist, muss die gefälschte Antwort entweder vor der legitimen Antwort beim angegriffenen Resolver eintreffen, oder der zuständige Nameserver wird durch einen Denial-of-Service-Angriff daran gehindert eine Antwort zu senden. Des Weiteren müssen die Parameter der Antwort zu der Anfrage passen, unter anderem die 16 Bit lange Transaktionsnummer. Befindet sich der Angreifer im lokalen Rechnernetz, kann er die Transaktionsnummer mit einem Sniffer im Netz beobachten. Andernfalls muss die Transaktionsnummer erraten werden, wozu im Durchschnitt ${\displaystyle \textstyle {\frac {2^{16}}{2}}=32.768}$ Versuche notwendig sind. Der Angreifer kann mehrere gefälschte Antworten gleichzeitig senden, um die Erfolgswahrscheinlichkeit bei einem Angriffsversuch zu erhöhen, was jedoch den Ressourcenaufwand erhöht.

Durch verschiedene Schwachstellen kann die Transaktionsnummer einfacher erraten werden. Bei BIND 8 war der Pseudozufallszahlengenerator unsicher, sodass die Transaktionsnummer mit geringem Aufwand vorhergesagt werden konnte. Sendet der angegriffene Resolver eine identische DNS-Anfrage mehrfach mit verschiedenen Transaktionsnummern, erhöht sich die Erfolgswahrscheinlichkeit aufgrund des Geburtstagsparadoxons erheblich.

Normalerweise verwendet ein an das Internet angeschlossener Computer den DNS-Server seines Internetdienstanbieters (ISP) oder ein DNS des Unternehmensnetzwerks. DNS-Server werden in Unternehmensnetzwerken für die schnellere Namensauflösung verwendet, insbesondere da sie vorherige Anfragen zwischenspeichern. Angriffe unter Verwendung des DNS-Cache-Poisoning auf einen einzelnen DNS-Server können direkt vom betroffenen Server aus geschehen oder indirekt von dessen nachgelagerten Servern, wo weiter nach der Namensauflösung gefragt wird.

Um einen Angriff mit DNS-Cache-Poisoning auszuführen, verwendet der Angreifer normalerweise Schwachstellen in der DNS-Software, sogenannte Exploits. Ein DNS-Server sollte eigentlich die Korrektheit der DNS-Auflösung validieren, um sicherzustellen, dass die Daten von einer autorisierten Quelle stammen. Dies kann z. B. durch die Verwendung von DNSSEC geschehen; andernfalls kann der Server die falschen Daten lokal zwischenspeichern und sogar neue Anfragen von anderen Usern mit falschen Daten beantworten.

Bei den folgenden Varianten, werden die Einträge für den Server ns.target.example mittels DNS-Cache-Poisoning geändert und der Benutzer auf den Server des Angreifers umgeleitet w.x.y.z. Diese Angriffe setzen voraus, dass der DNS-Server für target.example dem Server ns.target.example entspricht.

Um den Angriff erfolgreich durchzuführen, muss der Angreifer den DNS-Server dazu bringen, eine Anfrage für eine Domain zu tätigen, die der Angreifer kontrolliert.

Die erste Variante des DNS-Cache-Poisoning besteht darin, den DNS-Server der Angreifer-Domäne auf den DNS-Server der Zieldomäne umzuleiten und diesem DNS-Server dann eine vom Angreifer ausgewählte IP-Adresse zuzuweisen.

Anfrage des DNS-Servers: Was sind die Adressen von subdomain.attacker.example?

subdomain.attacker.example. IN A

Antwort des Angreifers:

Answer:
(no response)

Authority section:
attacker.example. 3600 IN NS ns.target.example.

Additional section:
ns.target.example. IN A w.x.y.z

Ein verwundbarer DNS-Server würde den zusätzlichen A-Eintrag (IP-Adresse) für ns.target.example zwischenspeichern, so dass der Angreifer Anfragen an die gesamte Domäne target.example auflösen kann.

Die zweite Variante der DNS-Cache-Poisoning besteht darin, den Nameserver einer anderen Domain, der nichts mit der Anfrage des Benutzers zu tun hat, an eine vom Angreifer ausgewählte IP-Adresse umzuleiten.

Anfrage des DNS-Servers: Was sind die Adressen von subdomain.attacker.example?

subdomain.attacker.example. IN A

Antwort des Angreifers:

Answer:
(no response)

Authority section:
target.example. 3600 IN NS ns.attacker.example.

Additional section:
ns.attacker.example. IN A w.x.y.z

Ein anfälliger Server würde die nicht zugehörigen autoritativen Informationen für den NS-Eintrag von target.example (Nameserver-Eintrag) zwischenspeichern, so dass der Angreifer Anfragen an die gesamte Domäne target.example auflösen kann.

Eine historische DNS-Cache-Poisoning-Angriffsmethode ist das Hinzufügen von zusätzlichen, gefälschten DNS-Einträgen in legitime DNS-Antworten. Übernimmt der Anfragende ungeprüft Resource Records aus der Antwort, so können ihm gefälschte Resource Records für beliebige Domainnamen in den DNS-Cache eingespeist werden.

Im öffentlichen DNS sind einzelne DNS-Server nur für Teilbereiche des gesamten DNS autoritativ. Bekommt ein DNS-Server eine Anfrage für einen Bereich, in dem er nicht autoritativ ist, kann er die Anfrage an den nächsten DNS-Server weiterleiten. Um unnötige Last zu vermeiden, können DNS-Server die Antworten anderer Server auf Anfragen lokal in einem Cache speichern. In diesem Fall könnte die Weiterleitung der oben genannten Anfrage an einen weiteren Server wegfallen und sofort eine Antwort gesendet werden. Ein DNS-Teilnehmer, der an einen Nameserver eine Anfrage sendet, übernimmt die erhaltene Antwort ungeprüft eine vorgegebene Zeit lang in seinen Cache. Neben der eigentlichen Antwort werden oft auch zusätzliche (legitime) Daten (Glue Records) übermittelt, die ebenfalls im Cache gespeichert werden. Das Cache Poisoning beruht darauf, in diesen zusätzlichen Daten ein oder mehrere gefälschte Resource Records zu verstecken.

Genauer formuliert: In der Authority Section des Antwortpakets wird der umzuleitende Name (zum Beispiel de.teknopedia.teknokrat.ac.id) als angeblicher DNS-Server eingetragen und in der Additional Section die IP-Adresse (zum Beispiel 1.2.3.4) eines vom Angreifer kontrollierten Servers.

1. Ein Angreifer bringt den Nameserver XX unter seine Kontrolle. Er manipuliert diesen derart, dass jedes Mal, wenn nach einem Namen aus der Domain example.com gefragt wird, ungefragt der gefälschte Record de.teknopedia.teknokrat.ac.id 192.0.2.1 mitgeliefert wird.
2. Der öffentliche Nameserver YY möchte den Namen test.example.com auflösen. Er sendet eine entsprechende Anfrage an den zuständigen (vom Angreifer kontrollierten) Nameserver XX. Dieser manipulierte Nameserver antwortet mit der korrekten IP-Adresse, liefert aber zusätzlich den gefälschten Record de.teknopedia.teknokrat.ac.id 192.0.2.1 mit. Dieser wird vom anfragenden Server YY ungeprüft in den Cache übernommen.
3. Zu einem späteren Zeitpunkt versucht ein User, den Namen de.teknopedia.teknokrat.ac.id aufzulösen und wendet sich an den öffentlichen Nameserver YY. Der Nameserver findet den (gefälschten) Record in seinem Cache und sendet dem User gutgläubig die IP-Adresse 192.0.2.1 zurück.
4. Der User möchte auf de.teknopedia.teknokrat.ac.id zugreifen, wird aber – für ihn nicht erkennbar – auf eine falsche Web-Seite mit der IP-Adresse 192.0.2.1 geleitet.

Die Sicherheitslücke wurde beim BIND-Nameserver im Juni 1997 behoben, indem ungefragt mitgelieferte Resource Records ignoriert werden. Akzeptiert werden nur Resource Records aus der tatsächlich angefragten Domain (in-bailiwick ‚im Verwaltungsbezirk‘). Alle heute gebräuchlichen Nameserver führen diese Prüfung vor der Übernahme in den Cache durch.

Kurz nach Bekanntwerden der Lücke führte Eugene Kashpureff einen großflächigen Cache-Poisoning-Angriff gegen noch anfällige BIND-Nameserver durch, für den er später zu einer Bewährungsstrafe verurteilt wurde.

Im Juli 2008 stellte Dan Kaminsky eine Angriffsvariante vor, die das oben beschriebene Caching gültiger Antworten umgeht und damit den Zeitaufwand erheblich reduziert.^[2] Durch Abfrage von nicht existierenden Domainnamen kann ein Fälschungsversuch beliebige Male wiederholt werden, wenn in einer Menge von gefälschten Antwortpaketen nicht die richtige Transaktionsnummer erraten wurde. Die gefälschte Antwort enthält eine Delegation bestehend aus einem NS Resource Record und einem Glue Record, der auf einen Host des Angreifers zeigt. So wird erreicht, dass untergeschobene Glue Records in-bailiwick sind und die gesamte Domain auf den Angreifer umgebogen wird.^[3]

In verschiedenen Ländern wird DNS-Spoofing zur Zensur im Internet verwendet. Geben DNS-Resolver gefälschte Antworten zurück, so spricht man auch von DNS-Hijacking. Dies war die vorgesehene Methode für das diskutierte Zugangserschwerungsgesetz zur Sperrung von Webseiten in Deutschland.

Einen Man-in-the-Middle-Angriff durch einen Netzbetreiber nennt man auch DNS-Injection. Der Netzbetreiber liest per Deep Packet Inspection die Domainnamen aus allen DNS-Anfragen aus und vergleicht diese gegen eine Sperrliste. Ist der Domainname gesperrt, wird per DNS-Spoofing eine gefälschte DNS-Antwort an den Absender gesendet. Da bei dieser Methode sämtliche DNS-Anfragen im Netz begutachtet werden, funktioniert die Sperrung auch dann, wenn der Nutzer nicht die DNS-Server des Netzbetreibers verwendet.

DNS-Injection wird in der Volksrepublik China im Rahmen des Projektes Goldener Schild angewandt. Hierbei können auch Dritte aus anderen Ländern gefälschte Antworten erhalten, wenn deren DNS-Anfrage durch chinesische Netze geleitet wird.^[4]

Maßnahmen zum Schutz gegen DNS-Spoofing zielen entweder darauf ab, mehr zufällige Informationen in die DNS-Nachricht aufzunehmen, die der Angreifer erraten muss, oder die Nachricht mit kryptographischen Verfahren zu schützen.

Viele DNS-Cache-Poisoning-Angriffe können verhindert werden, indem man den Informationen von anderen DNS-Servern weniger vertraut und Datensätze, die nichts direkt mit der Anfrage zu tun haben, ignoriert. Zum Beispiel führen BIND-Versionen über 9.5.0-P1 Überprüfungen durch: ein zufälliger Port für DNS-Anfragen des Anfrageservers, kombiniert mit kryptografisch sicheren Zufallszahlen, um den Quellport und die Nonce auszuwählen. Das kann die Wahrscheinlichkeit von Anfragen an DNS-Server („race condition“) stark reduzieren.

Wenn Router, Firewalls, Proxys und andere Gateways jedoch eine Netzwerkadressübersetzung (NAT) durchführen, oder genauer eine Netzwerkportübersetzung, müssen sie den Quellport umschreiben, um den Verbindungsstatus zu monitoren. Dadurch kann es passieren, dass durch PAT diese Zufälligkeit wieder ausgehebelt wird.

Secure DNS (DNSSEC) sichert die Übertragung von Resource Records durch digitale Signaturen ab. DNSSEC kann DNS-Cache-Poisoning-Angriffen widerstehen.

Diese Art von Angriff kann auf der Transportschicht oder Anwendungsschicht durch eine End-to-End-Validierung nach dem Verbindungsaufbau gekontert werden. Ein häufiges Beispiel dafür ist die Verwendung von Transport Layer Security und Digitaler Signaturen. Ein weiteres ist das Verwenden von HTTPS. Damit können Benutzer überprüfen, ob das digitale Zertifikat des Servers gültig ist und dem eigentlichen Eigentümer der Website gehört.

Seit Bekanntwerden des Kaminsky-Angriffs setzen alle gebräuchlichen Nameserver Source Port Randomization ein (djbdns und PowerDNS schon zuvor^[5]). Hierbei wird neben der Transaktionsnummer auch der Quellport einer DNS-Anfrage im UDP-Header zufällig gewählt. Je nach Implementation ergeben sich hierdurch weitere etwa 11–16 Bit, die der Angreifer ebenfalls richtig erraten muss. Demnach sind bei voller Ausschöpfung der möglichen Ports im Durchschnitt ${\displaystyle \textstyle {\frac {2^{16}\cdot 2^{16}}{2}}=2.147.483.648}$ Versuche notwendig.

Eine weitere Methode ist 0x20-Bit Encoding, bei der Buchstaben im angefragten Domainnamen zufällig in Groß- und Kleinbuchstaben gesetzt werden, zum Beispiel dE.WiKiPedia.ORG. Bei der Namensauflösung sind Groß- und Kleinbuchstaben grundsätzlich äquivalent, wobei laut RFC 1034^[6] die Schreibweise bei der Antwort dem Anfragenamen entsprechen soll. Die Länge des zusätzlichen Zufalls hängt von der Anzahl Buchstaben im Domainnamen ab, im Beispiel de.teknopedia.teknokrat.ac.id sind es 14 Bit.

Die genannten Verfahren haben gemein, dass das Nachrichtenformat nicht angepasst werden muss und die Verfahren daher mit der bestehenden DNS-Infrastruktur weitgehend kompatibel sind. DNS-Spoofing ist prinzipiell weiterhin durchführbar, aber durch den vergrößerten Raum der zu erratenden Parameter sinkt die Erfolgswahrscheinlichkeit eines entfernten Angreifers. Keines der Verfahren zur Erhöhung der Zufälligkeit schützt vor einem Angreifer, der die DNS-Anfrage mitlesen kann (on-path attacker).

Eine andere Kategorie von Schutzmaßnahmen besteht darin, das DNS-Nachrichtenformat um digitale Signaturen oder Message Authentication Codes zu erweitern, die mit kryptographischen Verfahren erzeugt und überprüft werden. Ein Angreifer kann zwar gefälschte DNS-Antworten erzeugen, ohne Kenntnis des geheimen Schlüssels jedoch keine dazu passende Signatur erzeugen.

Ein bekanntes Verfahren ist DNSSEC, bei dem Resource Records mit asymmetrischen Kryptosystemen signiert werden. DNSSEC wird zum Teil in der Praxis eingesetzt, der Großteil des DNS-Internetverkehrs ist jedoch nicht damit geschützt.^[7]

Ein zu DNSSEC alternatives Verfahren ist DNSCurve, bei dem nicht Resource Records, sondern der Kommunikationskanal zwischen Resolver und Nameserver kryptographisch geschützt wird. Es setzt eine Kombination aus asymmetrischen und symmetrischen Kryptosystemen ein. Eine Adaption von DNSCurve ist DNSCrypt, das OpenDNS zur Sicherung der Kommunikation zwischen Endnutzer und Resolver einsetzt.

TSIG sichert ähnlich wie DNSCurve oder DNSCrypt die Kommunikation zwischen zwei DNS-Teilnehmern. Es verwendet hierzu HMAC mit symmetrischen Schlüsseln, die händisch konfiguriert werden müssen.

Eine weitere Methode ist DNS over HTTPS, bei der DNS-Abfragen verschlüsselt über das HTTPS-Protokoll übertragen werden.

• Cache Poisoning

• Steve Friedl: An Illustrated Guide to the Kaminsky DNS Vulnerability, 7. August 2008.

1. ↑ Sooel Son, Vitaly Shmatikov: The Hitchhiker’s Guide to DNS Cache Poisoning, Cornell University. Abgerufen am 3. April 2017 (englisch). 
2. ↑ Jürgen Schmidt: Massives DNS-Sicherheitsproblem gefährdet das Internet. In: Heise.de. 9. Juli 2008, abgerufen am 16. Juli 2021. 
3. ↑ RUS-CERT-Meldung#1476: (Generic/DNS) Schwachstelle im DNS-Protokoll vereinfacht cache poisoning. In: cert.uni-stuttgart.de. 8. Juli 2008, abgerufen am 16. Juli 2021. 
4. ↑ The Collateral Damage of Internet Censorship by DNS Injection. In: ACM SIGCOMM Computer Communication Review. Band 42, Nr. 3, 2012, S. 21–27, doi:10.1145/2317307.2317311 (englisch, älterer Entwurf [PDF]). 
5. ↑ cr.yp.to
6. ↑ RFC: 1034 – Domain Names – Concepts and Facilities. November 1987 (englisch).
7. ↑ Matthäus Wander, Torben Weis: Measuring Occurrence of DNSSEC Validation. In: Passive and Active Measurement. 2013, ISBN 978-3-642-36516-4, S. 125–134, doi:10.1007/978-3-642-36516-4_13 (englisch, uni-due.de [PDF]).