Die von Dan Kaminsky gezeigte Attacke knackt einen DNS-Server in wenigen Sekunden. ZDNet erläutert diesen und andere Angriffe, zeigt, dass selbst neueste Patches keinerlei Schutz für Firmennetze bieten, und hilft bei der Lösung.
1983 entwickelte Paul Mockapetris[1] das Domain Name System[2] (DNS). Das wurde notwendig, weil das Internet rasant anwuchs und sich niemand mehr Knotennamen in Form einer IPv4-Adresse wie 110.64.51.187 merken konnte. Sechs Jahre vorher hatte das Internet noch recht übersichtlich ausgesehen. Bild 1[3] zeigt eine Karte, in der alle Rechner des Internets im Jahre 1977 eingezeichnet sind.
Auch im Jahr 1983 bestand der Internet-Vorgänger ARPANET[4] nach der Abtrennung des MILNET[5] offiziell nur aus 113 Rechnern. Die National Science Foundation[6] (NSF) finanzierte jedoch amerikanischen Universitäten einen Zugang zu damaligen Supercomputern, die sich vor allem an Universitäten mit ARPANET-Anschluss befanden. Dazu realisierte die NSF das CSNET[6] (später NSFNET[7]) mit TCP/IP-Protokoll und bezahlte X.25[8]-Anschlüsse für Universitäten, die keine eigenen Supercomputer besaßen.
Diese Verbindung von mehreren TCP/IP-Netzen nannte man Internet. Da im Endeffekt alle TCP/IP-Netze miteinander verbunden waren, konnte jeder Rechner erreicht werden. Damit keine IP-Adresskonflikte auftraten, fragten die Netzbetreiber einfach den Verwalter der RFC-Dokumente, Jon Postel[9], welche IP-Adressen sie verwenden sollten.
Als Jon Postels Liste immer größer wurde, erkannte er frühzeitig, dass IP-Nummern auf Dauer keine Lösung für eine Benennung von Netzknoten sein konnten, und beauftrage Paul Mockapetris mit einer Lösung. Zum einen sollte die Unabhängigkeit der einzelnen Netze gewahrt bleiben, zum anderen konnte er keine zentrale Verwaltung für jeden Knoten aufbauen, da er keine Mitarbeiter hatte.
So entstand die verteilte Datenbank DNS. Postel konnte ganze IP-Adressbereiche an den Verwalter eines Netzes vergeben. Ebenso delegierte er einen Namen, eine sogenannte Domain, an den Netzverwalter. Innerhalb eines Netzes konnte der Verwalter die Namen frei verteilen. Dieses System der dezentralen Verwaltung ermöglichte ihm, die IANA[10] lange Jahre als Ein-Mann-Unternehmen zu führen. Er leitete die IANA bis zu seinem Tod 1998. Zu diesem Zeitpunkt hatte er weniger als zehn Mitarbeiter.
DNS funktionierte, allen Unkenrufen zum Trotz, prächtig. Ein dezentrales weltweites Datennetz, das von einer "One-Man-Show" verwaltet wird, hielt man damals für unmöglich. Jon Postel und Paul Mockapetris zeigten, dass es trotzdem geht, was vielen Leuten beim CCITT[11] (heute ITU-T[12]) nicht gefiel.
Damit die verteilte Datenbank DNS funktioniert, gibt es mehrere Root-Server. Deren Namen und IP-Adressen muss jeder DNS-Server kennen. Diese Information, siehe Bild 2[13], erhält ein DNS-Server über eine Konfigurationsdatei. Diese Datei ändert sich nur äußerst selten, so dass DNS-Betreiber sich keine Sorgen um ihre Aktualität machen müssen. Neue Versionen kommen über den Update-Service des Betriebssystems.
Die Root-Server wissen nur recht wenig über das Internet. Fragt man einen der Root-Server nach www.example.com, so antwortet er in natürliche Sprache übersetzt wie ein deutscher Beamter mit "Das weiß ich nicht, dafür bin ich nicht zuständig". Allerdings gibt er als weitere Information eine Liste mit DNS-Servern und deren IP-Adressen heraus, die für alle Domains, die mit .com enden. zuständig sind.
Doch auch die für .com verantwortlichen Server antworten nur, dass für die Domain .example.com andere Server zuständig sind. Erst diese Server beantworten die Frage des geduldigen Clients mit: "Die IP-Adresse von www.example.com ist 192.0.34.43".
Bildergalerie
So einfach funktionieren DNS-Attacken[14]
» zur Bildergalerie ...[14]Aus diesem Grund wurde DNS mit einem Caching-Protokoll[15] ausgestattet, das dafür sorgt, dass immer wiederkehrende Anfragen, beispielsweise nach www.google.de[16], nicht jedes Mal neu über die Root-Server angefragt werden. Die Dauer, wie lange ein Eintrag im Cache verbleiben darf, bestimmt der für Zone zuständige DNS-Server, indem er zu jeder Antwort einen Time-to-live-Wert (TTL) übermittelt.
Dieser TTL-Wert kann sehr lang sein, beispielsweise für die Root- und Top-Level-Server. Die IP-Adressen der Root-Server haben eine TTL von 1000 Stunden oder mehr als 41 Tagen. Ein DNS-Server, der die IP-Adresse eines Root-Servers abgefragt hat, wird daher in den nächsten 41 Tagen keine erneute Anfrage stellen, sondern seinen Clients aus dem Cache antworten. Die Clients erhalten dabei die "Restlaufzeit" des Caches als TTL, so dass auch sie nicht immer wieder ihren DNS-Server befragen müssen.
Meist ist die TTL wesentlich geringer als 41 Tage. Domains unterhalb der .com-Zone werden beispielsweise 48 Stunden gecacht. Wird eine Domain zu einem anderen Provider umgezogen oder ein Inhaberwechsel durchgeführt, so liefern DNS-Server bis zu 48 Stunden lang noch die alten und damit meist falschen Antworten aus dem Cache.
Anbieter von dynamischen DNS-Diensten, die oft von DSL-Anschlussinhabern genutzt werden, verwenden meist eine TTL von 60 Sekunden. Ein solcher Wert wäre für eine häufig angefragte Domain zu gering. Da jedoch Domains wie www.Erika-Musterfrau.dyndns.org nicht besonders häufig aufgerufen werden, kommt es zu keiner großen Belastung der Bandbreite. Dafür ist die Domain nach dem täglichen Adresswechsel innerhalb von einer Minute wieder erreichbar.
Da das DNS-Protokoll über wenig Security und keinerlei Verschlüsselung verfügt, liegt es nahe, Angriffe auf den Cache vorzunehmen. Schiebt man einem DNS-Server eine falsche Antwort unter, so wird er diese falsche Antwort den Clients weiterleiten. Wie lange er das macht, bestimmt der Angreifer, indem er dem DNS-Server eine falsche TTL übermittelt.
Die einfachste Form eines Angriffs ist die Nutzung von sogenannten Additional-Records. DNS-Server geben in einigen Fällen Antworten auf Fragen, die man ihnen gar nicht gestellt hat. Die korrekte Antwort auf die Frage "Welche DNS-Server sind zuständig für example.com?" lautet "Zuständig für example.com sind a.iana-servers.net oder b.iana-servers.net". Da sich ein DNS-Server jedoch "denken" kann, dass die nächste Frage des Clients lautet: "Wie sind die IP-Adressen von a.iana-servers.net und b.iana-servers.net?", liefert er die Antwort darauf gleich mit, siehe Bild 3[17].
Ältere Versionen von DNS-Servern cachen auch Antworten auf Fragen, die niemals gestellt wurden. Dazu gehören unter anderem die Microsoft-DNS-Server bis Windows NT 4.0 und Windows 2000. Ab Windows 2003 ist die Option "Secure against cache pollution" standardmäßig gesetzt, siehe Bild 4[18].
Ein Angreifer, der weiß, dass am Arbeitsplatz noch Server-Versionen vor Windows 2003 eingesetzt werden und dessen Administrator die Hinweise von Microsoft[19] möglicherweise nicht beachtet hat, kann eine sehr einfache Attacke ausführen, die dazu führt, dass bestimmte Adressen zu einem Server seiner Wahl umgeleitet werden.
Dazu muss er lediglich eine Domain registrieren. Es reicht eine kostenlose Third-Level-Domain, für die man eigene DNS-Server konfigurieren kann, wie das beispielsweise DtDns.com[20] anbietet, siehe Bild 5[21]. Dabei leitet man beide DNS-Einträge auf eigene DNS-Server um, die man so modifiziert hat, dass sie grundsätzlich in der Additional Section "www.google.de. 86400 IN A 1.2.3.4" zurückliefern, siehe Bild 6[22]. Daraufhin wird ein alter Server für 24 Stunden (86.400 Sekunden) jede Anfrage für www.google.de[16] mit der IP-Adresse 1.2.3.4 beantworten.
Der Angreifer muss nur von seinem Arbeitsplatz einmal seine eigene Domain abfragen, etwa mit dem Kommandozeilen-Befehl "Ping meine.kostenlose-domain.example.com", schon ist der Cache eines DNS-Servers verseucht. Werden im Intranet mehrere DNS-Server verwendet, so kann er unter Windows und Unix nsloopkup[23] verwenden, um alle DNS-Server zu verseuchen. Aktuelle Unix-Derivate bieten zusätzlich die moderneren Tools dig[24] und host, die man sich auch für Windows downloaden[25] kann.
Bei einem Open-Source-DNS-Server wie Bind[26] muss der Angreifer lediglich ein paar Zeilen Code ändern und das Programm neu kompilieren, damit gefälschte Antworten wie in Bild 6[22] gesendet werden. Bind kann für Windows und Unix kompiliert werden. Der gefälschte DNS-Server kann zuhause stehen, wenn man TCP- und UDP-Port 53 per NAT[27] weiterleitet.
Neuere Versionen von DNS-Servern kann man nicht ganz so einfach austricksen. Doch auch hier gibt es Möglichkeiten. Mit geeigneten Angriffen kann man die DNS-Server des eigenen Internetproviders verseuchen. Ein Angreifer kann somit wesentlich mehr Benutzern falsche Adressen unterjubeln. Das ist beispielsweise geeignet, um Phishing-Attacken besser zu verschleiern.
Bei einer Standard-Phishing-Attacke kann der Benutzer an der URL des Browsers erkennen, dass er nicht auf der echten Seite seiner Bank ist. Wird der DNS-Cache eines Internet-Providers verseucht, erkennt man an der URL nichts. Ferner muss der Phisher seine Opfer nicht mit Spam auf die gefälschten Seiten locken. Ein ahnungsloser Homebanker, der die Original-URL seiner Bank im Browser eintippt, landet auf der Phishing-Seite.
Um den DNS-Server seines eigenen Providers zu überlisten, muss man eine kleine Security-Hürde in Form der Sicherheit einer 16 Bit langen "Query-ID" überwinden. Ein DNS-Server muss nämlich mit derselben Query-ID antworten, mit der die Anfrage gestellt wurde. Ein Angreifer hat damit eine Chance von 1 zu 65.536, um eine gefälschte Antwort zu senden.
Da der Angreifer bei einigermaßen aktuellen DNS-Servern keine gefälschten Antworten mehr über die Additional Section einschleusen kann, muss er eine Anfrage, die der DNS-Server an einen anderen stellt, nicht nur mit der richtigen "Query-ID", sondern auch schneller beantworten als der gefragte DNS-Server, jedoch nicht, bevor der Server überhaupt seine Query abgesetzt hat.
Dies kann er nur dadurch erreichen, dass er den Server mit gefälschten Antworten geradezu bombardiert und innerhalb der Zeitspanne die richtige Query-ID errät. Das wiederum sollte jede Firewall als DoS-Attacke erkennen und den Angreifer ausperren.
Sicherheitsexperte Dan Kaminsky[28] fand jedoch Anfang des Jahres eine Möglichkeit, die Wahrscheinlichkeit einer gelungenen Attacke[29] zu erhöhen, so dass er in wenigen Sekunden die meisten DNS-Server mit gefälschten Cache-Einträgen verseuchen konnte. Dabei fragt er einfach immer wieder nicht existierende Subdomains ab. Um beispielsweise die Domain example.com zu kapern, lässt er den DNS-Server seines Providers oder seiner Firma hintereinander a.example.com, b.example und so weiter auflösen.
Bisherige Angriffe erfolgten immer durch Abfrage von existierenden Subdomains, beispielsweise www.example.com. Da immer die gleiche Domain abgefragt wurde, stellte der angegriffene Server keine weiteren Anfragen, da er www.example.com nicht erneut anfragt, solange noch eine Antwort aussteht. Kommt die echte Antwort an, was mit einer Wahrscheinlichkeit von 65.536 zu eins der Fall ist, kann der Angreifer erst wieder einen neuen Versuch starten, wenn die TTL abgelaufen ist, was meist mehrere Stunden dauert.
Durch Kaminskys einfache Idee, nicht existierende Domains abzufragen, veranlasst ein Angreifer den DNS-Server, immer wieder Queries in schneller Abfolge zu stellen. Diese Anfragen haben jeweils eine zufällig generierte Query-ID. Der Angreifer, der gefälschte Antworten schickt, kann damit rechnen, dass er eine dieser Query-IDs trifft.
Außerdem kann er darauf hoffen, dass die Firewall des zuständigen DNS-Server für example.com die vielen Anfragen des angegriffenen Servers als DoS-Attacke einstuft und Antworten verweigert oder stark verlangsamt (Teergrubenprinzip[30]). Damit erhöht sich die Wahrscheinlichkeit, dass die gefälschten Pakete durchkommen. Die gefälschten Pakete werden einfach in der Authority Section mit falschen DNS-Servern ausgestattet, die der angegriffene Server daraufhin in seinen Cache übernimmt.
Die Lösung für diese Sicherheitslücke erarbeitete Kaminsky zusammen mit dem Bind-Entwickler-Team vom ISC[31], Microsoft, Sun und Cisco. So konnten die Hersteller von DNS-Servern reagieren, bevor Kaminsky seine Erkenntnisse auf der BlackHat-Konferenz[32] veröffentlichte.
Doch die Hersteller waren zunächst ratlos. Die große DNS-Server-Patchwelle, die die DNS-Server-Hersteller als Antwort auf und Sieg über den sogenannten Kaminsky-Bug präsentierten, ist alles andere als wirklich sicher.
Der Fix besteht darin, dass DNS-Server nun nicht mehr immer wieder denselben Source-UDP-Port benutzen, den sie einmal reserviert haben, sondern für jede Anfrage einen neuen verwenden. Ein Angreifer muss nun nicht nur die richtige Query-ID erraten, sondern zusätzlich den richtigen Port. Der DNS-Server akzeptiert nur noch Antworten, die auf dem Port eingehen, von dem die Query gestellt wurde.
Da der UDP-Port wie die Query-ID eine 16 Bit lange Zahl ist, kommt man auf etwas mehr als vier Milliarden Möglichkeiten. Mit einem einzelnem Rechner dürfte es schwer werden, einen DNS-Server zu kompromittieren. Ein Botnetz, das Rechner bei vielen Internetprovidern weltweit hat, kann jedoch eine Chance haben, per Zufall einen DNS-Server eines großen Providers zu verseuchen, wovon alle Nutzer betroffen wären, denen derselbe DNS-Server zugeteilt ist. Gänzlich untauglich ist der Patch gegen die Kaminsky-Attacke für viele Firmennetzwerke, die ihren Intranet-DNS-Server in einem privaten Netzwerk hinter einem NAT-Router betreiben. Da sich viele Benutzer über das NAT-Routing eine öffentliche IP-Adresse teilen, kann der NAT-Router logischerweise nicht einem einzelnen Rechner, nämlich dem DNS-Server, alle 65.536 Ports zur Verfügung stellen, die pro öffentlicher IP-Adresse möglich sind.
Intelligente Enterprise-Level-NAT-Router begrenzen daher die Anzahl der Ports pro interner IP-Adresse von vornherein, um zu verhindern, dass ein Rechner sich alle Ports "abgreift" und alle anderen Mitbenutzer der öffentlichen IP-Adresse so lange keinen Internet-Zugang haben, bis der betreffende Rechner seine Ports freiwillig freigibt.
Die meisten Tests, ob ein stets mit Updates versorgter DNS-Server wirklich sicher ist, taugen für DNS-Server im Intranet nicht viel. Rühmliche Ausnahme ist der Test von dns-oarc.net[33]. Er testet nicht nur, ob für verschiedene Anfragen auch verschiedene Source-Ports verwendet werden, sondern auch die statistische Standardabweichung der Ports. Ist sie gering, so kann man davon ausgehen, dass von den 65.536 möglichen Ports nur ein Bruchteil über die öffentliche IP-Adresse genutzt wird.
Ein Kaminsky-Angriff ist dann meist nicht innerhalb von Sekunden, jedoch innerhalb von wenigen Minuten möglich. Ein Nutzer, der sich eine Malware eingefangen hat, kann so für das ganze Unternehmen versehentlich zum "Phishing-Provider" werden.
Den Test kann man einfach von der Windows-Kommandozeile oder einer Unix-Shell durchführen. Dazu gibt man "nslookup -type=txt -timeout=30 porttest.dns-oarc.net 1.2.3.4" ein, wobei 1.2.3.4 der zu testende DNS-Server ist. Steht nslookup nicht zur Verfügung, so lautet die Syntax für dig "dig +short porttest.dns-oarc.net TXT @1.2.3.4".
Bekommt man eine Antwort wie in Bild 7[34], so handelt es sich um einen ungepatchten Server. Man sieht, dass alle Anfragen vom selben Port ausgehen. Relativ sicher ist der Server aus Bild 8[35], der eine aktuelle Bind-Version verwendet. Mit einem Consumer-DSL-Router ergibt sich auch eine sichere Situation, wie Bild 9[36] zeigt. Zu beachten ist, dass der Intranet-DNS Server 192.168.0.1 abgefragt wurde. dns-oarc.net meldet das Ergebnis für die öffentliche IP-Adresse dieses Servers.
Ein anderes Ergebnis sieht man in Bild 10[37]. Hier wird ein Enterprise-Level-Gateway von Cisco eingesetzt. dns-oarc.net kommt zu dem richtigen Ergebnis, dass der Server aus dem Intranet leicht kompromittiert werden kann.
Zwar werden alle 26 Queries von verschiedenen Ports gestellt, jedoch liegt die Standardabweichung der Ports nur bei 18, so dass man davon ausgehen kann, dass das Gateway die öffentlichen UDP-Ports im NAT-Prozess auf einen engen Bereich begrenzt. Die Kaminsky-Attacke kann zwar nicht innerhalb von Sekunden, jedoch in einigen Minuten erfolgreich ausgeführt werden.
Firmennetze lassen sich wirksam schützen, ohne auf eine Fritzbox als Router umsteigen zu müssen, die es einem einzelnen User ermöglicht, die NAT-Verbindung ins Internet für alle anderen zu unterbinden. Wichtig ist jedoch zu wissen, dass ein Update auf die aktuelle Version des DNS-Servers allein nicht ausreicht.
Ein Methode ist der Einsatz von Forwarding. Dabei konfiguriert man seinen Intranet-Server so, dass er alle Anfragen außerhalb der eigenen Domain an die DNS-Server des Interproviders weiterleitet. Voraussetzung ist natürlich, das man diese Server vorher mit nslookup oder dig testet.
Beim Microsoft-DNS-Server klickt man dazu in der Mangement Console des DNS-Server auf den eigenen Server und wählt "Eigenschaften" (Properties). Anschließend geht man auf den Reiter "Forwarders". Die DNS-Server trägt man ein, wie in Bild 11[38] gezeigt.
Bei Bind-Servern muss man die Config-Datei, meist /etc/named.conf, anpassen. Dies geschieht im Abschnitt "Options", siehe Bild 12[39]. Mit der beschrieben Methode reduziert man die Wahrscheinlichkeit eines erfolgreichen Angriff auf dieselbe Wahrscheinlichkeit, wie sie die DNS-Server des Providers besitzen.
Noch sicherer ist es, im Internet mindestens zwei Server anzumieten. Meist reicht dabei ein virtueller Server. Verwendet man diese als Forwarder, reduziert man die Wahrscheinlichkeit eines Angriffs, weil die eigenen Forwarder im Gegensatz zu DNS-Servern großer Provider dem Angreifer unbekannt sind.
Bild 12 zeigt außerdem, dass die Version verschleiert wird. Dies ist wichtig, damit ein Angreifer keine Versionsabfragen durchführen kann und so versionsspezifische Schwachstellen ausnutzt. Microsoft-DNS-Server lassen grundsätzlich keine Versions-Abfrage mit einem Befehl wie "host -a -c CH version.bind [IP-Adresse]" zu.
Als grundsätzlich sicher wird der Einsatz der Domain Name System Security Extensions (DNSSEC[40]) betrachtet. Das ist allerdings organisatorisch schwierig. Neben den Root-Servern und allen Top-Level-Domains muss beachtet werden, dass einige Länder Third-Level-Domains einsetzen, etwa .com.au oder .co.uk. Hinzu kommt die geplante Einführung beliebiger Top-Level-Domains seitens der ICANN. Bis DNSSEC tatsächlich verfügbar ist, werden vermutlich noch einige Jahre verstreichen.
DNS als historisch gewachsene, verteilte Datenbank ohne ernsthafte Sicherheitsfeatures führt naturgemäß zu Problemen. Ohne DNS hätte allerdings das Internet in seinen Anfängen nicht so schnell wachsen können. Die damalige Administration des Vorläufers ARPANET war darauf angewiesen, dass jeder seinen kleinen Teil des großen Internet selbst verwalten kann.
Größter Angriffspunkt ist das DNS-Caching. Gelingt es, den Cache zu verseuchen, geben DNS-Server, denen man vertraut, über einen Zeitraum von Stunden und Tagen falsche Antworten. Dies können Phisher nutzen, um Anwender von jedem Phishing-Filter unbemerkt auf falsche Websites zu locken.
Sehr gefährlich ist die Kaminsky-Attacke. Aktuelle Versionen aller relevanten DNS-Server sind gegen diesen Angriff gesichert, in dem die Wahrscheinlichkeit eines Erfolges von etwa eins zu 65.000 auf unter eins zu vier Milliarden gesenkt wird.
Insbesondere für Firmenanwender reicht es nicht aus, einen DNS-Server auf den aktuellen Stand zu bringen. Enterprise-NAT-Router reduzieren den Nutzen des Patches gegen die Kaminsky-Attacke erheblich. Consumer-NAT-Router haben dieses Problem nicht.
Bis zur Entdeckung der nächsten Angriffsmöglichkeit können sich Betreiber von Intranet-DNS-Servern gut schützen, indem sie Forwarding einsetzen. Einen hundertprozentigen Schutz gibt es allerdings nicht. Die Wahrscheinlichkeit eines erfolgreichen Angriffs ist jedoch sehr gering.
URLs in diesem Artikel:[1] = http:/
[2] = http:/
[3] = http:/
[4] = http:/
[5] = http:/
[6] = http:/
[7] = http:/
[8] = http:/
[9] = http:/
[10] = http:/
[11] = http:/
[12] = http:/
[13] = http:/
[14] = http:/
[15] = http:/
[16] = http:/
[17] = http:/
[18] = http:/
[19] = http:/
[20] = http:/
[21] = http:/
[22] = http:/
[23] = http:/
[24] = http:/
[25] = http:/
[26] = http:/
[27] = http:/
[28] = http:/
[29] = http:/
[30] = http:/
[31] = https:/
[32] = http:/
[33] = https:/
[34] = http:/
[35] = http:/
[36] = http:/
[37] = http:/
[38] = http:/
[39] = http:/
[40] = http:/