Zusammenfassung

  • Kaminsky-artiges Cache Poisoning erzwang Abfragen für neue Namen und eröffnete das Off-Path-Rennen immer wieder: Eine Fälschung musste die Parameter der offenen Anfrage erraten und die echte Antwort zeitlich schlagen.
  • Die koordinierten Patches von 2008 authentisierten DNS-Daten nicht. Sie erweiterten die lokale Annahmegrenze um unvorhersehbare Transaktions-IDs und Quellports, deren Entropie Firewall und NAT überstehen und am Draht geprüft werden musste.

Der erste passende Kandidat galt als Antwort

Ein rekursiver Resolver fragte typischerweise per unsigniertem UDP. Die gewöhnliche Antwort enthielt keinen kryptografischen Herkunftsnachweis. Der Resolver prüfte deshalb, ob das Paket zu einer tatsächlich ausstehenden Arbeit gehörte.

RFC 5452 formulierte die Grenze: Frageteil und ID mussten übereinstimmen; die Antwort musste von der abgefragten Adresse zu der Adresse und dem Port zurückkehren, von denen die Anfrage gesendet worden war. Im Allgemeinen wurde die erste Antwort angenommen, die diese Bedingungen erfüllte.

Ein Angreifer außerhalb des Pfads sah die Anfrage nicht, konnte aber die Adresse eines autoritativen Servers vortäuschen und viele Kandidaten senden. Ein Treffer in der richtigen Kombination, der vor dem legitimen Paket ankam, reichte aus. Der Cache verbreitete die falschen Daten danach selbst an seine Nutzer.

Die Macht blieb begrenzt: ein Cache, bestimmte Namen und eine endliche Lebensdauer. Sie war keine Übernahme des gesamten DNS. Darum sind Rekursionszugang, Antwortabgleich, Bailiwick, Zufall und Signaturprüfung getrennte Kontrollflächen.

Der Angriff erzeugte seine nächste Chance selbst

ID-Raten und Cache Poisoning waren 2008 nicht neu. RFC 3833 dokumentierte sie bereits 2004. Die Transaktions-ID besitzt 16 Bit; schwache Generatoren boten weniger wirksame Unsicherheit; ein fester UDP-Port fügte kein Geheimnis hinzu.

Dan Kaminsky zeigte die praktische Kombination. Ein Angreifer ließ den Resolver nach einem nie zuvor gesehenen Zufallslabel unter der Zieldomain fragen. Weil es nicht im Cache lag, musste eine neue autoritative Anfrage hinausgehen. Gefälschte Antworten traten gegen die echte an. Nach einem Fehlschlag öffnete ein anderes Label sofort das nächste Fenster.

Das Wegwerflabel war Auslöser, nicht zwingend Ziel. Eine Fälschung konnte versuchen, Delegationsdaten für die übergeordnete Zieldomain einzufügen, soweit Relevanz- und Bailiwick-Regeln dies zuließen. Auf das Ablaufen eines attraktiven Cacheeintrags musste der Angreifer nicht mehr warten.

RFC 5452 behandelt die effektive TTL bei bestimmten Wiederholungsvarianten als nahezu null. In seinem Modell mit 7.000 gefälschten Paketen pro Sekunde und einem Quellport liegt die 50-Prozent-Marke bei ungefähr sieben Sekunden. Das ist keine allgemeine Angriffsdauer, sondern zeigt, wie billige Wiederholung eine kleine Einzelchance operationalisiert.

Der Quellport wurde zum zweiten Bezeichner

Die Notfallmaßnahme vergrößerte die zu erratende Menge. Gepatchte Resolver wählten pro Anfrage einen unvorhersehbaren Quellport und stärkere IDs, statt einen stabilen Port wiederzuverwenden.

RFC 5452 rechnete mit etwa 64.000 nutzbaren Ports und damit einem entsprechend größeren Suchraum. Im selben Modell verschob sich die 50-Prozent-Marke von sieben Sekunden auf rund 116 Stunden. CERT/CC sprach grundsätzlich von nahezu 16 zusätzlichen Bits, wies aber auf reservierte und belegte Ports hin.

Der Drahtstandard musste sich dafür nicht ändern. Autoritative Server antworteten ohnehin an den Quellport. Anbieter konnten Implementierungen ausliefern und Betreiber unabhängig aktualisieren.

Kosten blieben. ISC warnte beim ersten BIND-Patch vor merklicher Leistungseinbuße oberhalb von ungefähr 10.000 Anfragen pro Sekunde und stellte optimierte Beta-Zweige bereit. Firewalls mit festem DNS-Ausgangsport mussten angepasst werden; Stateful-Geräte benötigten mehr Zuordnungen.

Der Patch beseitigte Ingenieursarbeit nicht. Er tauschte eine vorhersagbare Annahmetupel gegen anspruchsvollere Socket- und Zustandsverwaltung. Dieser Tausch war lokal messbar und reversibel.

Ein Übersetzer konnte die Entropie wieder zusammenfalten

Eine Paketliste konnte „gepatcht“ melden, obwohl außen nur wenige Ports sichtbar waren. NAT/PAT schreibt Quellports um. CERT/CC warnte vor Verminderung oder Verlust des Gewinns; RFC 5452 nennt Geräte, die Ports serialisieren oder stark begrenzen.

Nicht jedes NAT schadet. Manche Geräte bewahren die Auswahl, andere verändern die sichtbare Streuung. Entscheidend ist die Zahl der Optionen nach Betriebssystem, Firewall und Übersetzung – genau dort, wo der Angreifer rät.

DNS-OARC machte dies durch Port- und ID-Tests von der autoritativen Seite sichtbar. Der Betreiber erhielt die Werteverteilung, die tatsächlich am entfernten Endpunkt ankam, statt aus einer Versionsnummer auf Schutz zu schließen.

Running-Code Primacy wird hier überprüfbar: Ein Bulletin beschreibt Absicht, ein Inventar eine Installation, aber erst laufender Verkehr beweist, dass die Umgebung den Schutz nicht wieder entfernt hat.

Koordinierte Veröffentlichung war keine zentrale Ausführung

DNS-OARC verzeichnet am 31. März 2008 einen DNS-Gipfel bei Microsoft. Am 8. Juli erschienen CERT/CC VU#800113 und Updates vieler Anbieter. ISC patchte BIND; Microsoft änderte IDs, UDP-Sockets und Cachelogik.

Die Vertraulichkeit hielt nicht bis zur geplanten Erklärung. Die Zeitleiste nennt eine faktische Offenlegung am 21. Juli, funktionierenden Exploitcode am 23. und weitere Implementierungen am 24. Juli. Microsoft erklärte am 25. Juli, das Risiko sei durch öffentliches Wissen gestiegen. Zugleich waren dem Unternehmen damals keine aktiven Angriffe oder Kundenauswirkungen bekannt; der getestete Exploit wirkte nicht gegen Systeme mit MS08-037.

Das ist kein globaler Nichtangriffsnachweis. Öffentlicher Code erhöhte Fähigkeiten; ein Hersteller sah nur seinen Ausschnitt; ein erfolgreicher Test zertifizierte nicht jede Resolver-Netz-Kombination.

Kaminsky präsentierte am 7. August bei Black Hat. RFC 5452 folgte im Januar 2009. Zuerst lieferte ein kompatibler Patch reale Abwehr, danach schrieb der Standards-Track-Text die gemeinsamen Regeln fest. Das Dokument erklärte die Lektion, installierte aber kein Juli-Update.

Ein teureres Raten ist noch keine Herkunftsprüfung

Portzufall machte Off-Path-Fälschung erheblich teurer. Er bewies nicht, dass unsignierte Daten vom delegierten Zoneninhaber stammten. Geleakter Zustand, ein verengendes NAT, genügend Versuche oder ein Platz auf dem Pfad änderten die Voraussetzungen.

ISC bezeichnete deshalb DNSSEC als endgültige Lösung und erkannte zugleich an, dass sofortige Vollausrollung unrealistisch war. DNSSEC prüft Ursprung und Integrität mittels Signaturen und Vertrauenskette. Das ist eine andere Eigenschaft als ein schwerer zu gewinnendes Rennen.

Die Schichten ergänzen sich. Strenger Abgleich und Entropie verwerfen billige Fälschungen, DNSSEC bewertet die Autorität der Daten. Keine der beiden Kontrollen sollte die Aufgabe der anderen beanspruchen.

Heng Lus Minimum Initial Specification legt die gemeinsame Grenze klein fest: vollständiger Abgleich und ausreichende Unvorhersagbarkeit. Sie erhebt weder Zufallsgenerator noch Socket-Allocator oder Rollout-Zeitplan eines Anbieters zum globalen Befehl. Spätere Entscheidungen bleiben lokal; Adoption zeigt sich in betriebenem und messbarem Verhalten.

Grenzen der Belege

Die Quellen belegen eine herstellerübergreifende Exposition und eine deutlich praktischere Technik. Sie belegen nicht denselben Fehler in jedem Resolver, universelle Installation am 8. Juli oder allgemeingültige sieben Sekunden beziehungsweise 116 Stunden. Portzufall härtete unter benannten Annahmen, beseitigte aber nicht jedes Poisoning. DNSSEC auf Papier ist kein Nachweis aktiver Validierung.

Die belastbare Folgerung genügt: Ein Teil des DNS-Vertrauens hing an einem kleinen Rennen, dessen Unsicherheit viele Systeme ungewollt verkleinerten. Der Fix vergrößerte und messbar machte diesen Raum; Authentisierung blieb ein separates Deploymentproblem.

Quellen