DNS-Cache-Angriffe: Patches in Firmennetzen meist wirkungslos

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 fand jedoch Anfang des Jahres eine Möglichkeit, die Wahrscheinlichkeit einer gelungenen Attacke 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). 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.

Bildergalerie

So einfach funktionieren DNS-Attacken

zur Bildergalerie

Die Lösung für diese Sicherheitslücke erarbeitete Kaminsky zusammen mit dem Bind-Entwickler-Team vom ISC, Microsoft, Sun und Cisco. So konnten die Hersteller von DNS-Servern reagieren, bevor Kaminsky seine Erkenntnisse auf der BlackHat-Konferenz 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.