DNS-Fragment-Angriffe – Zeit für DNSSEC

Abstract

Ein neuer Angriff auf das DNS ermöglicht Angreifern, die im Sommer 2008 hinzugefügten Verbesserungen einer damals bekannt gewordenen Schwachstelle zu umgehen. Ein Angreifer kann so DNS-Cache-Einträge mit relativ wenig Aufwand fälschen. In meinem Artikel gehe ich auf die Hintergründe und das aktuelle Bedrohungspotential ein.

DNS-Fragment-Angriffe

Der ein oder andere erinnert sich vielleicht noch an den Sommer 2008 – in DNS-Fachkreisen auch als "Summer of Fear" bekannt. Der Sicherheitsexperte Dan Kaminski hatte eine erschreckende Sicherheitslücke im Domain Name System (DNS) gefunden: mittels eines statistischen Effekts und klug gewählter DNS-Antwort-Pakete war es Angreifern möglich, innerhalb sehr kurzer Zeit (in der Regel unter einer Minute) DNS-Antworten eines Caching-DNS-Servers zu fälschen.

Grund für die Sicherheitslücke ist die unzureichende Authentisierung von DNS-Antworten gegenüber dem empfangenden DNS-Server – eine 16-Bit-Anfrage-ID (Query-ID, QID) wird verwendet, um DNS-Antworten den DNS-Anfragen zuzuordnen. Angreifer können diese Anfrage-ID "erraten" und damit gefälschte Daten senden. Als Resultat erhalten Client-Maschinen des Caching-DNS-Servers die falschen Daten und verbinden sich mit den falschen Servern im Internet. Über diesen Weg kann der Angreifer private Daten abgreifen oder Sicherheitslücken ausnutzen, um Schadsoftware auf dem Client-System zu installieren.

Im Sommer 2008 waren alle Hersteller von DNS-Software vorab über die Sicherheitslücke informiert und konnten sofort neue Versionen der DNS-Server-Software bereitstellen, welche das Ausnutzen der Sicherheitslücke erschwert (aber nicht verhindert). Die neuen Versionen der DNS-Server erhöhen per UDP Port Randomization die Anzahl der vom Angreifer zu erratenden Bits. Damit muss ein Angreifer heute über mehr als 10 Stunden gefälschte DNS-Daten senden, um einen Angriff erfolgreich durchzuführen (und das fällt ja auf, weil wir unsere DNS Server überwachen...).

Und wieder zurück auf Start...

Im August 2013, als die IETF 87 in Berlin stattfand, wurde ein neuer Angriff auf das DNS-System einer breiteren Öffentlichkeit vorgestellt. Dieser Angriff ermöglicht Angreifern, die im Sommer 2008 den DNS-Servern hinzugefügten Verbesserungen zu umgehen und DNS-Cache-Einträge mit relativ wenig Aufwand zu fälschen.

Der neue Angriff macht sich das Zusammenspiel von DNS mit dem unterliegenden Transportprotokoll UDP zunutze. Um den Angriff zu verstehen, schauen wir uns eine Besonderheit des DNS-Protokolls an: Ein DNS-Server kann eine Antwort auf eine Anfrage immer nur atomar – als einzelnes Antwortpaket – versenden (auf der Applikationsebene). Das heißt, der DNS Server kann nicht mehrere Antwortpakete für eine Anfrage versenden.

DNS ist simpel: ein Anfrage-Paket – ein Antwort-Paket.

Das Internet besteht aus einem Zusammenschluss von mehreren unabhängigen Netzwerken, die auf unterschiedlichen physischen Netzwerktechnologien basieren. Diese physischen Netzwerke haben unterschiedliche Beschränkungen für die maximale Paketgröße (Maximum Transfer Unit, MTU). Für IPv4 sind maximal 576 Byte garantiert (1280 Byte für IPv6). Sendet die Applikationsschicht ein größeres Datenpaket, so werden die Daten in der Transportschicht aufgeteilt (Fragmentierung).

DNS und Fragmentierung

Um Fragmentierung bei DNS-Daten zu verhindern, galt für DNS-Pakete lange Zeit eine Größenbeschränkung von 512 Byte (576 minus IPv4 Kopfdaten (Header) = 512 DNS Nutzdaten). Für etliche DNS-Anwendungen ist diese Beschränkung heute zu groß, daher wurde 1998 mit EDNS0 (RFC 2671) eine Erweiterung zum DNS-Protokoll spezifiziert, die DNS-Pakete bis 4096 Byte erlaubt (wenn beide Kommunikationspartner die EDNS0-Erweiterungen unterstützen). Für die DNS-Sicherheitserweiterung DNSSEC ist EDNS0 zwingend vorgeschrieben, jeder DNS-Server, der DNSSEC unterstützt, kann große DNS-Pakete verarbeiten.

DNS-Antwort-Pakete größer 512 Byte können daher zu Fragmentierung der Pakete in der Transportschicht führen. Und hier setzt der neue Angriff an. Der Angreifer veranlasst einen DNS-Server, eine spezielle DNS-Anfrage abzusetzen, bei der bekannt ist, dass die Antwort groß genug ist, um in der IP-Transportschicht die Fragmentierung auszulösen.

Dem Angreifer ist auch der Inhalt (und damit die Größe) des Antwortpaketes bekannt (DNS-Daten im Internet sind öffentlich). Der Angreifer, wissend dass der DNS-Server nun auf eine DNS-Antwort wartet, sendet das zweite Fragment der Antwort mit gefälschten Daten an den DNS-Server. Dabei ist unerheblich, ob das zweite Fragment vor dem ersten Fragment beim DNS-Server ankommt, da die TCP/IP-Netzwerkschicht die Fragmente in die korrekte Reihenfolge bringt. Das erste Fragment kommt also von der Original-Quelle der DNS-Daten, das zweite Fragment mit den gefälschten Daten kommt vom Angreifer.

Alle Informationen, welche die DNS-Antwort gegenüber dem Caching-DNS-Server authentisieren können, befinden sich im DNS-Header im ersten Fragment und müssen daher vom Angreifer nicht gefälscht werden. Das zweite Fragment wird nur über die Fragment-ID (ein 16-Bit-Wert) geschützt. Diesen Wert muss der Angreifer erraten. Da einige Betriebssysteme aufsteigende Fragment-IDs verwenden, ist das aber trivial. Um das Zeitfenster für den Angriff zu seinen Gunsten zu verschieben, setzt der Angreifer den autoritativen DNS-Server der Original-Daten unter einen Denial-of-Service-Angriff, so dass dieser Server die Fragmente der Antwort nur mit verminderter Geschwindigkeit senden kann.

Der Angriff im Detail

  1. der Angreifer veranlasst eine DNS-Anfrage, bei der eine große DNS-Antwort bekannt ist.
  2. Der Caching-Server folgt der Delegation, um den autoritativen Server für die Anfrage zu finden.
  3. Der autoritative DNS-Server sendet das erste Fragment der Antwort.

4a. der Angreifer sendet gefälschte Fragmente für die Delegationsinformationen. Die gefälschten Daten landen im Cache des anfragenden DNS-Servers.

4b. Der autoritative Server sendet das zweite Fragment (Original).

  1. Ein interner DNS-Client fragt Daten innerhalb der angegriffenen Domain an.
  2. Die Anfrage wird an die DNS-Server des Angreifers umgeleitet, nicht an den autoritativen Server der Domain. Der Angreifer hat nun die volle Kontrolle über die Domain.

Dieser neue Angriff funktioniert dort gut, wo große DNS-Anwortpakete vorkommen und der empfangende DNS-Server keine Validierung der Daten per DNSSEC vornimmt. Große Antwortpakete kommen bei allen DNSSEC-signierten Domains vor, auch bei den Top-Level-Domains wie .com, .net, .org, .de, .at, .ch und auch allen neuen Top-Level-Domains wie .koeln und .berlin (bei nTLDs ist DNSSEC vorgeschrieben).

Jedoch auch ohne DNSSEC können große DNS-Antworten vorkommen, etwa bei SPF Einträgen oder DKIM-Schlüsseldaten. Unser eigener DKIM-Pubkey zeigt anschaulich, das Antwortpaket fällt groß aus:

mail201205._domainkey.sys4.de.        3600 TXT (
  "v=DKIM1; p="
  "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPygLkm4TJTkdSJoXmU0CSLlEH"
  "fNojsepskRlhKVFFTNrcFdk29FXyUtcg+K0TX3V1zySA1yJMUEiOLMD/y7fsaHZ8"
  "mQhY4gFECgwqCBd3rCoCX3tpOpeltMedJyC0wiLiUmhR3l+vOK4l6TZ2FQZ796yC"
  "ycquQvQL0Yb0x7tdWQIDAQAB")

Wie real ist die Bedrohung?

Im Mai 2012 wurde der Angriff in Fragmentation Considered Poisonous erstmalig beschrieben und im August 2013 auf der IETF '87 in DNS Poisioning einem größeren Publikum bekannt gemacht. Anfang Oktober 2013 haben zwei unabhängige "Proof-of-Concept"-Implementierungen (IP fragmentation attack on DNS) bewiesen, dass der Angriff im Internet erfolgreich durchgeführt werden kann. Heute, Mitte Oktober, sind noch keine Angriffe bekannt, aber es ist damit zu rechnen, denn der Angriff ist gut dokumentiert.

Wie auch mit der 2008 von Dan Kaminski gefundenen Angriffsart lassen sich mit dem DNS-Fragment-Angriff die sogenannten Delegation Glue Records einer Top-Level-Domain fälschen, und damit ganze Domains (und nicht nur einzelne Domain-Daten). Dabei werden die Delegation-Informationen im Caching-DNS-Server für die Ziel-Domain gefälscht, wodurch alle weiteren Anfragen innerhalb der Domain an DNS-Server unter der Kontrolle des Angreifers gesendet werden. Ziel dieser Angriffe sind oft Top-Level-Domain-Namen, wie auch "bekannte" Internetdienste wie Google oder Facebook.

Was tun?

Nach heutigem Wissensstand ist DNSSEC die einzige wirkungsvolle Gegenmaßnahme, um diesen Angriff abzuwehren. Dazu muss DNSSEC-Validierung auf dem Caching-DNS-Server angeschaltet werden. DNSSEC-Validierung ist heute mit den meisten DNS-Servern (BIND 9.7+, Windows 2012, Unbound 1.4.x) ohne großen Aufwand möglich (siehe SURFnet - "Deploying DNSSEC Validation on recursive caching name servers").

Als kurzfristige Gegenmaßnahme kann der EDNS0-Buffer des Caching-Servers auf den garantierten MTU-Wert (512 Byte) gesetzt werden; damit wird EDNS0 ausgeschaltet und der DNS-Verkehr wird vermehrt über TCP (statt UDP) abgewickelt. Bei der Benutzung von TCP als Transportprotokoll ist dieser Angriff so nicht möglich, jedoch ist DNS über TCP langsamer (ca. um den Faktor 3) und verbraucht mehr Ressourcen.

Note

Über die Probleme und Grenzen von "DNS über TCP" werde ich in Kürze einen weiteren Blog-Artikel schreiben.

Carsten Strotmann, 14. October 2013

   DNS    Bind    DNSSEC    Angriffe