Channel Security

Dan Kaminskys hat in seinem Vortrag auf der Sicherheitskonferenz Black Hat die bisher fehlenden Details zur von ihm entdeckten Design-Schwachstelle im DNS-Protokoll veröffentlicht. Die Präsentation des Vortrags steht in seinem Blog zum Download bereit (PowerPoint-Datei).

Gemeinsame Anstrengungen lohnen sich

Zuerst liefert Dan Kaminsky einige Informationen darüber, wie viele Server inzwischen gepatcht wurden. Die nackten Zahlen sind beeindruckend, die dazugehörige Animation erst recht:

Rot - Ungepatcht
Gelb - Gepatcht, aber der Patch wird durch NAT ausgehebelt
Grün - OK

Früher hatte die Landkarte weiße Flecke, heute schwarze - die ohne Internet. Nur mal so als Nebengedanke.

Die Details

Im wesentlichen wurden die schon bekannt gewordenen Details bestätigt:

Um in einem Nameserver den Eintrag für www.opfer.example mit der IP-Adresse 1.2.3.4 zu vergiften, geht der Angreifer vereinfacht folgendermaßen vor:

1. Er fragt den Nameserver nach $irgendwas.opfer.example, wobei $irgendwas eine beliebige Zeichenkette ist
2. Er sendet viele gefälschte Antworten mit unterschiedlichen Transaction-IDs an den Nameserver, in denen er behauptet, dass der für $irgendwas.opfer.example zuständige Nameserver www.opfer.example ist und die IP-Adresse 1.2.3.4 hat.
3. Schlägt der Angriff fehl, weil der für opfer.example zuständige Nameserver schneller war oder nicht die richtige Transaction-ID erraten wurde, wird er sofort mit einem neuen Wert für $irgendwas wiederholt.

In diesem Zusammenhang kommt dem Angreifer eine inzwischen behobene Schwachstelle in PowerDNS entgegen: Arbeitet PowerDNS als authoritiver Nameserver, beantwortet er bestimmte falsch formatierte Anfragen nach Domains in seiner Zone nicht. Der Angreifer muss sich also kein Rennen mit dem zuständigen Nameserver liefern, sondern nur die richtige Transaction-ID treffen.

Auch Nameserver hinter einer Firewall können angegriffen werden:

1. Der Angreifer erzwingt eine Anfrage beim zu vergiftenden Nameserver nach einem Server in seiner Domain, z.B. 1.angreifer.example. Das geht z.B. über präparierte Webseiten, Requests an Mailserver, Web-Bugs in E-Mails, ...
2. Der Nameserver fragt den Nameserver des Angreifers nach der Adresse von 1.angreifer.example, der antwortet mit einem Verweis auf 1.opfer.example, woraufhin der Nameserver sofort einen Request an den Nameserver für opfer.example sendet
3. Der Angreifer sendet sofort eine Reihe gefälschter Antworten, wie oben beschrieben.

Gehts schlimmer?

Klar, denn: Schlimmer geht immer. Laut Dan Kaminsky können auch die Einträge für Top Level Domains wie .com, .net, .org, .de, ... vergiftet werden.

Vergiftet ein Angreifer z.B. den Eintrag für .de, erhält er alle DNS-Abfragen nach .de-Domains, die an den vergifteten Nameserver gesendet werden.
Er kann dann entscheiden, ob er den betreffenden Eintrag für eine bestimmte Zeit vergiften will (er antwortet mit einer falschen IP-Adresse mit einer Lebenszeit (TTL, Time to Life) seiner Wahl) oder ob ihn dieser Server nicht interessiert (er antwortet mit einem Verweis auf den zuständigen Nameserver).

Angriffsziele

Dan Kaminsky hat nicht nur den Angriff beschrieben, sondern auch mögliche Angriffsziele aufgezeigt. Alles, was auf DNS-Abfragen angewiesen ist, ist angreifbar. Und das ist im Internet (fast?) jeder Dienst. Betroffen sind also nicht nur Webserver, sondern z.B. auch

• Mailserver: Der Angreifer kann Mails über seinen Server umleiten und lesen oder manipulieren, ...
• Das gleiche gilt für IP-Telefonie: Auch SIP ist auf DNS angewiesen
• Update-Downloads können auf bösartige Server umgeleitet werden, indem die Adresse des Update-Servers vergiftet wird (siehe Evilgrade, ein Tool, mit dem sich über Cache-Poisoning Anfragen an bekannte Update-Server auf Server der Angreifer umleiten lassen).

SSL ist nicht sicher

SSL (Secure Socket Layer) wurde bisher als optimaler Schutz für alle Arten von Verbindungen betrachtet. Mit der jetzt bekannt gewordenen Schwachstelle sind Man-in-the-Middle-Angriffe sehr viel leichter möglich. Zum Beispiel verwenden viele Websites SSL, d.h. in diesem Fall HTTPS, nur für die Übertragung von z.B. Zugangs- oder Kreditkartendaten, während alle anderen Daten über das normale HTTP-Protokoll übertragen werden. Ein Man-in-the-Middle-Angreifer kann also seinen Schadcode vorher einschleusen und die eingetippten Daten vor der Übertragung ausspähen.

SSL ist außerdem nur sicher, wenn die verwendeten Zertifikate auch geprüft werden. Abgesehen von Benutzern, die sich wenig dafür interessieren, was für eine Meldung sie da gerade weggeklickt haben, damit sie endlich mit dem Online-Banking beginnen können, gibt es da weitere Probleme. So gibt es nach dem Debakel mit Debians OpenSSL-Bibliothek immer noch jede Menge gültige unsichere Zertifikate, die auch noch einige Zeit gültig bleiben werden - Revocation, d.h. der Rückruf ungültig gewordener Zertifikate, funktioniert nur in der Theorie. Die meisten Browser ignorieren die entsprechenden Listen. Ein weiterer Punkt in Dan Kaminskys Präsentation: Oft nutzen die Herausgeber der Zertifikate, die Certificate Authorities (CA), DNS-basierte Dienste, um die zu zertifizierenden Angaben zu prüfen: Abfragen der Domain mit whois, Senden einer E-Mail an eine angegebene Adresse, Besuch einer Website - alles Dienste, die über DNS-Poisoning angegriffen werden können. Das Erschleichen eines Zertifikats ist damit deutlich leichter als zuvor. Damit nicht genug: Für die Verwaltung bereits ausgestellter Zertifikate stellen die CAs Weboberflächen bereit, in die sich der Benutzer einloggen muss. Die können wieder über Man-in-the-Middle-Angriffe angegriffen werden - oder die "Passwort vergessen"-Funktion wird ausgenutzt, um sich Zugang zu verschaffen

Passwort vergessen - vergessen Sie ihr Passwort...

Für die "Passwort vergessen"-Funktion gibt es im wesentlichen drei Ansätze:

1. Das aktuelle Passwort wird dem Benutzer per Mail zugeschickt
2. Dem Benutzer wird eine Mail mit einem Link zugeschickt, der das Passwort zurücksetzt
3. Dem Benutzer wird eine Mail mit einem Link zugeschickt, der das Passwort zurücksetzt, zusätzlich gibt es weitere Hürden

Mit DNS-Poisoning lassen sich die ersten beiden leicht Ansätze aushebeln. Siehe oben: Auch Mailserver nutzen das DNS. Beim dritten kommt es auf die zusätzlichen Hürden an...

Fazit

Welche Auswirkungen die DNS-Schwachstelle hat, kann man eigentlich immer noch nicht vollständig übersehen, auch wenn inzwischen alle Details bekannt sind. Es sind zu viele Dienste auf das DNS angewiesen, um jetzt schon alle möglichen Folgeangriffe erkennen zu können. Eines sollte auf jedem Fall klar sein: Die dringenden Aufforderungen zum Patchen sind kein Scherz.

Carsten Eilers