Kaminskys DNS-Lücke: Wie sich jede Domain kapern ließ

Am 8. Juli 2008 veröffentlichten Hersteller von DNS-Software in aller Welt am selben Tag Fixes für eine Sicherheitslücke, die der Sicherheitsforscher Dan Kaminsky entdeckt hatte. Das DNS, das Domain Name System, ist das Adressbuch des Internets: Es übersetzt Namen wie example.com in die numerischen Adressen, über die Computer einander erreichen. Durch die Lücke konnten Angreifer falsche Adressen für jede beliebige Domain im Speicher der Server ablegen, die diese Namen für Nutzer nachschlagen. Laut CERT.at, dem nationalen Computer-Notfallteam Österreichs, waren fast alle DNS-Server im Internet verwundbar.

So funktionierte der Angriff

Wenn du eine Website öffnest, fragt dein Gerät einen Resolver nach der Adresse. Ein Resolver ist ein DNS-Server, der für Nutzer Namen nachschlägt; meist betreibt ihn dein Internetanbieter oder deine Firma. Er fragt die Nameserver, die für die Domain zuständig sind, und hebt ihre Antwort eine Weile in seinem Cache auf, einem Zwischenspeicher, damit er dem nächsten Nutzer sofort antworten kann. Wer eine gefälschte Antwort in diesen Cache einschleust, schickt jeden Nutzer des Resolvers zum falschen Server. Das nennt man Cache-Poisoning, die Vergiftung des Zwischenspeichers.

Ein Resolver nahm eine Antwort an, wenn sie zu seiner Anfrage passte, vor allem über eine Abfrage-ID, eine Zahl zwischen 0 und 65.535. Die meisten Resolver schickten alle Anfragen vom selben Netzwerkport ab. Damit war diese Zahl das einzige Geheimnis, das ein Angreifer erraten musste: Jede gefälschte Antwort traf mit einer Wahrscheinlichkeit von 1 zu 65.536. Trotzdem war das Vergiften schwierig, denn die echte Antwort kam meist nach etwa 100 Millisekunden an. Lag sie erst im Cache, musste der Angreifer warten, bis sie ablief, oft tagelang.

Kaminskys Idee machte das Warten überflüssig. Der Angreifer lässt den Resolver Namen nachschlagen, die es nicht gibt, etwa random1.example.com, dann random2.example.com und so weiter. Solche Namen liegen nie im Cache, also ist jeder eine neue Chance. Die gefälschten Antworten enthalten einen zusätzlichen Eintrag, der behauptet, ein Server des Angreifers sei jetzt der Nameserver für ganz example.com. Sobald ein Rateversuch trifft, speichert der Resolver diese Angabe und fragt von da an den Angreifer nach jedem Namen der Domain. Laut einer Studie, die 2009 auf der Sicherheitskonferenz NDSS vorgestellt wurde, verkürzte die Technik die Dauer eines Angriffs von Wochen auf Sekunden.

Das US-CERT, das Computer-Notfallteam der US-Regierung, warnte, dass sich so Webverkehr, E-Mails und andere wichtige Netzwerkdaten auf Systeme umleiten ließen, die der Angreifer kontrolliert.

Reichweite und Angriffe

Die Schwachstelle lag im DNS-Protokoll selbst und nicht in einem einzelnen Produkt, schrieb ISC, der Hersteller der weit verbreiteten DNS-Software BIND. Das CERT/CC, die US-Koordinierungsstelle für Sicherheitslücken, führte 91 Hersteller auf; 37 davon waren betroffen, von Microsoft und Cisco bis zu Linux-Distributionen.

CERT.at wird von der Registrierungsstelle für die österreichischen .at-Domains betrieben und hat gemessen, wie schnell die Resolver in Österreich gepatcht wurden. Ein gepatchter Resolver wechselt mit jeder Anfrage seinen Port, und das konnte CERT.at in den Logdateien eines Nameservers der Registrierungsstelle sehen. Vor den Fixes taten das nur etwa 15 % der Resolver. Zwei Wochen nach den Fixes waren 66 % der aktiven Resolver, also jener, die an fast jedem Tag auftauchten, noch immer ungepatcht:

Studien zu Resolvern in aller Welt kamen zu unterschiedlichen Ergebnissen. Monate nach den Fixes testeten Forscher des Georgia Institute of Technology 0,9 Millionen offene Resolver, die Anfragen von jedem beantworten: Etwa 57 % schickten noch immer jede Anfrage vom selben Port ab. Eine Erhebung von The Measurement Factory im Auftrag des DNS-Herstellers Infoblox schätzte die Zahl der offenen Resolver im Oktober 2008 auf 4,3 Millionen und stellte bei 24 % der getesteten eine unzureichende Zufallswahl der Ports fest.

Die Einzelheiten des Angriffs sollten bis zu einem Vortrag auf der Sicherheitskonferenz Black Hat Anfang August geheim bleiben. Doch am 21. Juli sickerten sie durch, und am 23. Juli tauchte funktionierender Angriffscode auf, so DNS-OARC, ein Verband von DNS-Betreibern. Eine Woche später berichtete die Presse, dass ein DNS-Server des Providers AT&T in Texas vergiftet worden war: Wer über ihn google.com aufrief, landete auf einer gefälschten Seite, die automatisch Werbung anklickte. Auch das SANS Internet Storm Center meldete den vergifteten Server. Die Forscher aus Georgia fanden in den ersten beiden Augustwochen 2008 vergiftete Antworten für die Domains von Banken und großen Websites, allein 11.050 für die US-Bank Washington Mutual. Ihre Zahl stieg, nachdem die Angriffswerkzeuge erschienen waren, doch die Forscher konnten nicht nachweisen, welche Technik die Angreifer genutzt hatten. Keine Quelle beziffert den Schaden.

Der Fix und die Reaktion

Kaminsky hatte die Hersteller schon Monate vorher gewarnt: Am 31. März 2008 trafen sich Hersteller von DNS-Software bei Microsoft, um das Problem zu besprechen. Ihr gemeinsamer Fix heißt Source Port Randomization, die zufällige Wahl des Quellports. Ein gepatchter Resolver schickt jede Anfrage von einem zufällig gewählten Port ab und nimmt nur Antworten an, die genau an diesem Port ankommen. Laut CERT.at muss ein Angreifer dadurch bis zu 16 weitere Bits Zufall erraten. Nach dem Update von Microsoft etwa wählten Windows-DNS-Server ihre Ports aus 16.384 möglichen; zusammen mit der Abfrage-ID ergibt das rund eine Milliarde Kombinationen statt 65.536. Neu war die Idee nicht: CERT/CC schreibt sie dem Entwickler von djbdns zu, einem Resolver, der schon vorher zufällige Ports wählte.

Auf Betreiben von CERT/CC veröffentlichten fast alle Hersteller ihre Fixes am selben Tag, dem 8. Juli 2008, darunter Microsoft mit dem Update MS08-037 und ISC mit neuen BIND-Versionen. CERT.at nannte diese Abstimmung nahezu beispiellos. Apple folgte am 31. Juli mit einem Update für den BIND-Server, der in Mac OS X steckt. CERT/CC warnte außerdem, dass Router und Firewalls, die Adressen und Ports umschreiben, den Schutz wieder zunichtemachen könnten.

Zufällige Ports legen die Latte nur höher. Ohne Änderungen am Protokoll wie DNSSEC, die Sicherheitserweiterungen des DNS, mit denen Resolver digitale Signaturen auf Antworten prüfen, können die Fixes „Cache-Poisoning nicht vollständig verhindern“, schrieb CERT/CC. ISC nannte DNSSEC „die einzige endgültige Lösung“. Im Oktober 2008 bat das US-Handelsministerium um Stellungnahmen dazu, die Root-Zone, die oberste Ebene des DNS, mit DNSSEC zu signieren, und verwies dabei auf diese Sicherheitslücke. Seit dem 15. Juli 2010 können Resolver die signierte Root-Zone prüfen.

Die National Vulnerability Database bewertet die Lücke auf CVSS 3.1 mit 6,8 von 10, also als „mittel“: Ein Angreifer kann Antworten fälschen, aber weder Daten lesen noch einen Server lahmlegen, und der Angriff gilt als schwer durchführbar.