Birthday-Attacke gegen DNS?

Interessante Meldung, es gebe angeblich eine ernsthafe bedrohliche Schwäche im DNS und dessen meisten Implementierungen. Heute nacht noch auf dem Heise Newsticker entdeckt. Geht auf eine Meldung des US-Cert zurück. Genaues will man noch nicht sagen, die Katze wird erst nach einer Reaktionszeit für die Hersteller auf der Black-Hat im August rausgelassen.

Setzt man allerdings die verschiedenen vagen Hinweise, die sich so finden, zusammen, und schaut sich an, was an den DNS-Servern gepatcht wurde, dann ergibt sich schon ein gewisses Bild, was da das Problem ist, und wie man es in den Griff zu bekommen versucht.

Wenn ein DNS-Server Adressen auflöst, für die er nicht selbst zuständig ist, dann schickt er per UDP eine Anfrage an einen anderen Server und erwartet von diesem eine Antwort. Dies wäre leicht zu fälschen, indem ein Angreifer einfach schneller als der echte Server eine falsche Antwort schickt. Damit das nicht passiert, wird mit der Anfrage eine 16-Bit-Zufallszahl mitgeschickt. (Kryptographisch quasi eine Nonce, aber viel zu schmal um den Begriff zu rechtfertigen.) In der Antwort muß die Zahl dann auch drin stehen. Es gab mal vor ein paar Jahren Schwächen in DNS-Servern, die diese Zahlen nicht zufällig zogen, sondern immer um eins erhöhten. Die konnte der Angreifer dann raten, indem er kurz hintereinander eine Anfrage an den Server an seine eigene Domain und dann an die anzugreifende Domain sandte. Durch die erste Anfrage wußte der Angreifer, wo der interne Zähler gerade steht und konnte auf Verdacht 2 oder 3 falsche Antworten schicken, die der Server dann akzeptiert hat. Und schwups waren falsche Antworten im Cache. Cache-Poisoning eben. Soweit ich mich erinnern kann, gab es auch welche, die immer mit denselben Pseudo-Zufallszahlen begannen und so ebenso vorhersagbar waren. Man dachte, das Problem gelöst zu haben, indem man halbwegs ordentliche Zufallszahlen verwendete.

Nun scheint es aber einen neuen interessanten Angriff zu geben. Aus den Hinweis-Bröckchen, die ich mir so gesammelt habe, vermute ich folgendes:

Wenn man Anfragen an den Server stellen kann und sie in kurzer Zeit als Bündel mehrerer ähnlicher Anfragen schickt, könnte es wohl sein, daß der Server dann auch ein Bündel verschiedener Anfragen an den nächsten Server weiterschickt. Sendet der Angreifer dann ein Bündel falscher Antworten mit zufällig gewählten Prüfzahlen drin, könnte das Birthday-Paradoxon zuschlagen: Die Wahrscheinlichkeit, daß sich in einem Bündel Anfragen und einem Bündel Antworten die gleiche Zahl findet, ist sehr viel höher als daß man eine bestimmte 16-Bit-Zahl mit 1:65536 triff. Das könnte in ziemlich reale Trefferwahrscheinlichkeiten fallen.

Für Firmen mit eigenem DNS-Server am Internet dürfte die Gefahr relativ klein sein, wenn sie ihr Zeugs ordentlich konfiguriert haben und Anfragen nur von innen zulassen. Anders sieht es für Privatkunden aus, die am DNS-Server ihres Providers hängen, wenn es auch noch andere Kunden gibt, die sich einen Bot eingefangen haben. Das wäre die Parade-Konstellation und die Folgen wären weitreichend.

Was man nun als Gegenmaßnahme zu versuchen scheint, wirkt aber ziemlich verzweifelt: Man versucht offenbar, durch stärkere Randomisierung des UDP-Ports, von dem der angegriffene DNS-Server die Anfrage schickt, quasi zusätzliche Entropie in die Nonce zu packen. Statt der 16 Bit in der Zahl muß der Angreifer nun noch ein paar zusätzliche Bit im UDP-Port raten. Was man halt so als Mittel versucht, wenn man das Protokoll selbst nicht ändern kann und in der Rückwärtskompatibilitätsklemme steckt. Schön ist es nicht.

Das wirklich Ärgerliche daran ist, daß bei der IETF schon seit Jahren die Erkenntnis vorliegt, daß solche Uralt-Protokolle wie DNS oder SMTP voller Sicherheitslücken sind und die Kompatibilitätsproblematik jede Verbesserung unmöglich oder zumindest sehr schwer macht. Eigentlich wäre wegschmeißen und neu schreiben angesagt.

Es gibt aber zu viele Murks-Pragmatiker und Firmen-Interessen-Vertreter da draußen, die jegliche grundlegende Änderung und Verbesserung an Protokollen torpedieren. Das ist mir damals bei RMX sehr stark aufgefallen. Was immer man vorschlägt, es geht sofort der Chor der Stimmen an, daß man auf gar keinen Fall irgendetwas an den eingeschliffenen Protokollen ändern dürfe. Sicherheit interessiert da kaum.

Also Kopf in den Sand und einfach weiter mit unsicheren Protokollen gearbeitet. Es ist seit Jahren bekannt, daß DNS faul ist, es gibt sogar eine Erweiterung DNSSEC, aber es tut sich einfach nichts. Auch gegen SMTP-Schwächen und SPAM wird nicht wirklich was unternommen. Es gibt noch mehr solche Beispiele. Immer weiter mit dem Status Quo, bis der Zusammenbruch kommt.

Noch ein Nachtrag: Als fatal könnte sich dabei die Eigenschaft mancher DNS-Server erweisen, auch Antworten zu akzeptieren, nach denen sie nicht gefragt hatten, und die huckepack mit einer anderne Antwort mitkamen. Ist bei manchen konfigurierbar. Es wäre mal experimentell zu eruieren ob man beispielsweise durch DNS-Anfragen der Art 1.www.beispiel.de, 2.www.beispiel.de usw. das besagte Phänomen provozieren und dabei Anworten für www.beispiel.de huckepack mitschicken kann.