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. Entdeckt hatte sie der Sicherheitsforscher Dan Kaminsky. Das DNS, das Domain Name System, ist das Adressbuch des Internets. Es übersetzt Namen wie example.com in die numerischen Adressen, die Computer nutzen. 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. Ihre Antwort hebt er eine Weile in seinem Cache auf, einem Zwischenspeicher. So kann er dem nächsten Nutzer sofort antworten. 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. Er 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. 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. Bei 24 % der getesteten Resolver war die Zufallswahl der Ports unzureichend.

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. Am 23. Juli tauchte laut DNS-OARC, einem Verband von DNS-Betreibern, funktionierender Angriffscode auf. 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. In den ersten beiden Augustwochen 2008 fanden die Forscher aus Georgia vergiftete Antworten für die Domains von Banken und großen Websites. Allein für die US-Bank Washington Mutual waren es 11.050. Ihre Zahl stieg, nachdem die Angriffswerkzeuge erschienen waren. Welche Technik die Angreifer genutzt hatten, konnten die Forscher aber nicht nachweisen. 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 waren 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: Router und Firewalls, die Adressen und Ports umschreiben, könnten den Schutz wieder zunichtemachen.

Zufällige Ports legen die Latte nur höher. Mit DNSSEC, den Sicherheitserweiterungen des DNS, können Resolver digitale Signaturen auf Antworten prüfen. Ohne solche Änderungen am Protokoll 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. Dabei verwies es 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. Außerdem gilt der Angriff als schwer durchführbar.