Evgeniy Polyakov hat einen Exploit für einen erfolgreichen Cache-Poisoning-Angriff gegen eine gepatchte BIND-Version veröffentlicht (Kopie davon auf Milw0rm). Werfen wir einen Blick auf die Fakten und Hintergründe.
Die Hintergründe
Dan Kaminsky hat am 6. August Details zur von ihm entdeckten Design-Schwachstelle in der DNS-Spezifikation veröffentlicht. Am 8. August hat Evgeniy Polyakov seinen Exploit veröffentlicht. Daran ist eigentlich nichts Besonderes, das war eigentlich zu erwarten. Schließlich waren ja schon vor Dan Kaminskys Vortrag Exploits veröffentlicht worden, und wenn eine Schwachstelle erst einmal bekannt ist, erscheinen Exploits ja allgemein eher früher als später. Das Besondere an Evgeniy Polyakovs Exploit: Er richtet sich nicht gegen das fehlerhafte Programm, sondern gegen die gepatchte Version, BIND 9.5.0-P2.
Angriff auf gepatchte Version
Ein Exploit gegen eine gepatchte Version ist erst einmal relativ ungewöhnlich, schließlich sollte der Patch ja die Schwachstelle beheben. Diesmal ist das aber etwas anders: der Patch, d.h. die zufällig vergebenen Quellports für DNS-Abfragen, verhindern einen Angriff nicht, sondern erschweren ihn nur. Dazu ein Zitat von Dan Kaminsky: "What was once possible via 32,769 packets, is still possible via between 134,217,728 and 4,294,967,296 packets." Darauf hatten auch schon die BIND-Entwickler in ihrem Security-Advisory hingewiesen: Der Einzige zurzeit bekannte wirklich wirksame Schutz besteht in der Verwendung von DNSSEC.
Die Folgen
Dass ein Angriff theoretisch möglich ist, war also schon von Anfang an klar. Dass so schnell ein Exploit auftaucht, ist auch nicht weiter verwunderlich: Während für einen Angriff gegen einen ungepatchten Nameserver nur die richtige Transaction-ID erraten werden muss, muss für einen Angriff gegen einen gepatchten Nameserver zusätzlich der richtige Source-Port erraten werden. Für einen Brute-Force-Angriff muss also nicht nur ein Parameter variiert werden, sondern zwei. Das ist programmiertechnisch weiter kein Problem. Und wie Evgeniy Polyakov bewiesen hat, ist ein erfolgreicher Angriff unter Laborbedingungen möglich. Aber ist so ein Angriff praktisch von Bedeutung?
Dazu ein Zitat aus dem Blog-Eintrag zum Exploit:
BIND used fully randomized source port range, i.e. around 64000 ports. Two attacking servers, connected to the attacked one via GigE link, were used, each one attacked 1-2 ports with full ID range. Usually attacking server is able to send about 40-50 thousands fake replies before remote server returns the correct one, so if port was matched probability of the successful poisoning is more than 60%.
Attack took about half of the day, i.e. a bit less than 10 hours.
So, if you have a GigE lan, any trojaned machine can poison your DNS during one night...
Der Angreifer braucht also eine gute Anbindung an den Nameserver und einige Stunden Zeit. Beides ist nicht immer auszuschließen. Außerdem: Wer sagt denn, dass ein Angreifer nicht eine Art "Distributed Cache Poisoning"-Angriff starten kann? Was für DoS-Angriffe gilt, gilt theoretisch genauso für Cache-Poisoning-Angriffe. Die Masse der gefälschten DNS-Antworten machts - ob die von einem, zwei oder viel mehr Rechnern kommen, ist egal.
Wer ist gefährdet?
Lassen wir die hypothetischen "Distributed Cache Poisoning"-Angriffe mal außen vor - wer ist dann gefährdet? Prinzipiell jeder, der einen Nameserver betreibt, den ein potenzieller Angreifer mit Anfragen und vor allem ausreichend vielen falschen Antworten bombardieren kann. Das muss nicht zwingend über einen Trojaner passieren. Ein Angreifer, der bereits einen Trojaner im lokalen Netz hat, dürfte sowieso lohnendere Ziele vor Augen haben als einen vergifteten DNS-Cache. Aber was ist z.B. mit Hosting-Providern? Ein bösartiger Benutzer könnte sicher einen lokalen Nameserver angreifen, wenn es einen gibt. Genauso in Unternehmen: Ein bösartiger Mitarbeiter könnte den lokalen Nameserver des Unternehmens angreifen. Das sind nur zwei Beispiele, es gibt sicher noch mehr Gelegenheiten, bei denen ein Angreifer eine ausreichend dimensionierte Verbindung zu einem Nameserver hat.
Theoretisch ließe sich der Angriff wahrscheinlich auch in JavaScript realisieren und dann über Cross-Site-Scripting verbreiten, aber praktisch scheitert das dann einfach an der Laufzeit - das Browserfenster mit dem eingeschleusten Code wird kaum lange genug geöffnet bleiben, um auch nur einen Bruchteil der möglichen Kombinationen durchzuprobieren.
Was kann man tun?
Hat ein Angreifer eine ausreichend leistungsfähige Verbindung zu einem Nameserver, ist ein erfolgreicher Angriff nur eine Frage der Zeit. Und genau diese Zeit ist der beste Verbündete zur Abwehr dieser Angriffe: Der Nameserver wird stundenlang mit Anfragen nach Subdomains einer Domain und noch viel mehr Antworten darauf bombardiert, das schlägt sich natürlich auch in den Logfiles nieder und kann von einem IDS erkannt werden. Die Schutzmaßnahmen, die ich am 29. Juli erwähnt habe, wirken noch immer. Dem dort erwähnten Tool CacheAudit wurde inzwischen übrigens eine eigene Webseite spendiert. Sehr praktisch, denn die normale Flash-(verseuchte) Website des Herstellers lässt ja keinen Link zu. Für das Intrusion-Detection-System Snort gibt es neue Entwicklungen: Ein Whitepaper mit Informationen und Regeln (PDF) und einen neuen DNS Preprocessor, für den Tester gesucht werden.
Die weiteren Aussichten: Trübe
Wie ich schon im Standpunkt Sicherheit schrieb: So, wie es derzeit aussieht, wird die DNS-Schwachstelle uns direkt oder indirekt noch einige Zeit beschäftigen. Bisher sind weder alle möglichen Folgen noch alle möglichen Angriffe bekannt. Und da der bisherige Patch wirklich nur ein Notflicken ist, steht auch noch die endgültige Behebung der Schwachstelle aus. Ob das DNSSEC sein wird oder ob noch eine andere Lösung gefunden wird, steht noch in den Sternen.
Carsten Eilers
Weiterführende Links:
- Design-Schwachstelle in der DNS-Spezifikation gefährdet Internet
- Details zur DNS-Schwachstelle durchgesickert
- Exploits für DNS-Schwachstelle veröffentlicht
- DNS-Angriffe laufen, Gegenmaßnahmen notwendig!
- DNS-Schwachstelle - Aktuelle Entwicklungen
- DNS-Schwachstelle - Die Auflösung aller Rätsel
- Security aktuell: Design-Schwachstelle im DNS-Protokoll erlaubt DNS-Cache-Poisoning
Kommentare