DNS ist eines der ältesten Protokolle des Internets. Im Gegensatz zu vielen anderen, die zum Teil mittlerweile verschwunden sind, ist es aber noch immer aktuell. Dazu beigetragen haben vor allem die vielen Absicherungen und Erweiterungen von DNS selbst. Unabhängig vom zugrundeliegenden Protokoll ist die Namensauflösung heute noch immer notwendig für die Verwendung des Internets, da sie die IP-Adressen abstrahiert und das Internet für den Menschen damit erst nutzbar ist. Leider ist die Namensauflösung (vor allem mit DNS) immer wieder auch Mittel zum Zweck für Angreifer.

Auch wenn wir klassische DNS-Angriffe wie Cache Poisoning heute nicht mehr fürchten müssen, ist es notwendig, DNS in unserer Netzwerkinfrastruktur zu managen und zu beobachten. Tatsächlich lässt sich das Protokoll von Angreifern nämlich einsetzen, um Inhalte in unsere Systeme einzuschleusen. Die empfangene DNS-Antwort enthält ja vor allem die IP-Adresse eines im späteren Ablauf anzufragenden Hostsystems. Dabei kann ein Angreifer aber auch gefälschte IP-Adressen über DNS ausliefern – und so Zugriff auf interne Systeme eines Netzwerks erhalten.

Das Konzept des als DNS Rebinding bezeichneten Angriffs ist bemerkenswert einfach. Das Ziel ist der Zugriff auf Ressourcen des internen Netzwerks des Opfers. Üblicherweise verhindern moderne Browser den direkten Zugriff auf die Ressourcen anderer Domains, das Stichwort an dieser Stelle lautet Cross-origin Resource Sharing (CORS). Um diese Sperre zu umgehen, verfährt der Angreifer wie folgt: Ein ausgewähltes Opfer landet auf einer manipulierten Webseite. Mittels DNS fragt der Browser die IP-Adresse der Domain ab. Die Antwort enthält die IP-Adresse eines Webservers und eine sehr kurze Lebensdauer (TTL) der Antwort.

Der Webserver liefert nun dynamische, vom Angreifer kontrollierte Inhalte aus. Bei der Ausführung fragt der Browser zu einem späteren Zeitpunkt weitere Inhalte von derselben Domain ab. Da die TTL der DNS-Antwort zu diesem Zeitpunkt bereits abgelaufen ist, führt der Browser eine weitere Abfrage durch. Doch dieses Mal enthält die Antwort die IP-Adresse eines Servers im internen Netzwerk des Opfers. Der Browser führt dann beliebige Kommandos durch oder fragt interne Ressourcen ab – alles unter der Domain oder einer Subdomain des Angreifers und damit ohne weitere (CORS-)Überprüfung durch den Browser.

Wenn Sie das Verfahren unter Linux einmal (gefahrlos) ausprobieren möchten, laden Sie sich die von uns vorbereitete HTML-Webseite unter [1] herunter und speichern diese in einem temporären Verzeichnis. Anschließend starten Sie innerhalb dieses Ordners mit Python den eingebauten Webserver auf Port 80. Führen Sie dazu die folgenden Kommandos aus:

Um die DNS-Abfragen zu simulieren, verwenden wir in diesem Beispiel die Datei "/etc/hosts" für die Namensauflösung. Fügen Sie dort Folgendes hinzu:

Anschließend öffnen Sie die Seite unter "http://dnsrebind.it-administrator.de/rebinding.html" in Ihrem Browser (in diesem Beispiel verwenden wir Firefox). Sie sehen nun die einfach gehaltene Testseite in Ihrem Browser. Öffnen Sie über das Menü unter "Tools / Browser Tools" den "Developer Modus" und wählen den "Console"-Reiter. Geben Sie nun in das Textfeld die IP-Adresse eines internen Diensts (etwa Ihres Routers) ein und klicken Sie einmal auf "CORS testen". Sie erhalten nun eine Fehlermeldung, dass der Cross-Origin-Request blockiert wurde. In Google Chrome sieht das Ergebnis in den Entwicklertools ähnlich aus.

Lassen Sie die Webseite im Browser geöffnet und ändern Sie nun den Eintrag in der "/etc/hosts"-Datei. Geben Sie statt 127.0.0.1 die IP-Adresse Ihres internen Dienstes ein. Nach dem Speichern wechseln Sie wieder in Ihren Browser, ändern die IP-Adresse im Eingabefeld zu "dnsrebind.it-administrator.de" und klicken nun auf den Text "Dynamisch Inhalte nachladen". Wenn Sie ein Verzeichnislisting mit der Datei "rebinding.html" sehen, dann hat der Browser die IP-Adresse noch nicht aktualisiert und Sie sehen noch die Ausgabe des Python-Webservers. Warten Sie einen kurzen Moment und versuchen Sie es nochmal. Nach kurzer Zeit (in unseren Versuchen ein bis zwei Sekunden) wird die Anfrage nun an die andere IP umgeleitet und Sie sollten den Inhalt einer anderen Webseite – nämlich Ihres ausgewählten internen Dienstes – sehen können.

Es ist möglich, dass Ihnen eine Fehlermeldung angezeigt wird. Dann hat der von Ihnen gewählte Dienst bereits Schutzmechanismen gegen DNS Rebinding umgesetzt. Wenn Sie die Webseite des Dienstes aber ohne Fehlermeldung sehen können, ist dieser für entsprechende Angriffe anfällig. In beiden Fällen erkennen Sie die Möglichkeiten eines solchen Angriffs: Während der normale Zugriff über die IP-Adresse des internen Diensts durch den Browser blockiert wurde, ist dies bei der Anfrage mittels DNS Rebinding nicht der Fall.

Es ist offensichtlich, dass die so erhaltenen Daten nun im Hintergrund an Server des Angreifers übertragen werden können. Mit etwas größerem Aufwand und vor allem Zeit kann der Angreifer natürlich einfach alle IP-Adressen in Ihrem internen Netzwerk absuchen und so Zugang zu sensiblen Informationen und Geschäftsgeheimnissen erhalten.

Bestenfalls konnten Sie auf den internen Dienst nicht zugreifen, weil dieser bereits Schutzmechanismen umgesetzt hat. Allein das Abschalten von JavaScript in den Browsern Ihrer Mitarbeiter würde zwar den hier exemplarisch durchgeführten Angriff verhindern, das Problem aber nicht aus der Welt schaffen. Unabhängig davon ist der Verzicht auf JavaScript heute so gut wie nicht mehr möglich.

Eine effektive Möglichkeit zum Schutz vor DNS Rebinding ist tatsächlich die strikte Auswertung der Host-Header im Webserver. Zugriff über unbekannte Domains (wie in diesem Fall "dnsrebind.it-administrator.de") sollte bei Ihren Diensten nicht möglich sein. Bestenfalls sollte auch keine "Default"-Webseite angezeigt werden, über die der Angreifer weitere Informationen erhalten könnte, sondern der Zugriff mit einem Fehler stoppen.

Natürlich sind Maßnahmen zum Schutz vor sogenanntem Cross Site Request Forgery (CSRF) sinnvoll und glücklicherweise sind CSRF-Token mittlerweile in fast allen Web-Frameworks ein Standard. Allerdings helfen diese zunächst nur vor schadhaften Aktionen, die in aktive Benutzersitzungen eingeschleust werden. Informationsverlust durch das reine Auslesen von Daten auf internen Webseiten verhindern diese Maßnahmen nicht.

Die richtige Verwendung von TLS und der Verzicht auf unverschlüsselte Verbindungen, auch für interne Dienste, können an dieser Stelle ebenfalls einen erfolgreichen Angriff verhindern. Wenn die vom Angreifer genutzte Domain nicht Teil des Zertifikats Ihres internen Webservers ist, dann wird die Abfrage über TLS scheitern und der Angreifer keinen Zugriff auf die internen Ressourcen erhalten. Hier sollten Sie vor allem bei selbst betriebenen CAs in Kombination mit der dynamischen Erstellung von TLS-Zertifikaten (etwa in HTTPS-Proxys) vorsichtig sein.

In Unternehmensnetzwerken mit eigenem auflösendem Nameserver können Sie die Antworten mit internen IP-Adressen natürlich einfach filtern. Dabei sollten Sie sich überlegen, ob Sie neben Ihren möglicherweise öffentlich gerouteten internen Adressen einfach alle als privat markierten IP-Adressen filtern. Beachten Sie, dass es neben dem RFC 1918 weitere relevante RFCs geben kann. Wenn Sie etwa Bind9 zur Namensauflösung einsetzen, können Sie mit folgender Option externe DNS-Antworten mit IPs im Bereich 10/8 herausfiltern. Natürlich sollten Sie eigene Antworten (eventuell auch von anderen autoritativen Nameservern in Ihrem Netzwerk) erlauben:

Wenn sich Ihre Clients über VPN in das Unternehmensnetzwerk einwählen, haben Sie je nach Konfiguration des VPN-Netzwerks keinen Einfluss auf die Namensauflösung. Das sollten Sie überprüfen und falls möglich ändern. Viele Router im privaten Umfeld verbieten zwar selbst interne Adressen in DNS-Antworten, das umfasst aber eben nicht die internen Adressen Ihrer Organisation.

Ähnlich verhält es sich, wenn Ihre Clients selbst den DNS-Server wählen dürfen oder diese einfach ohne Ihr Wissen konfigurieren – Stichwort: DNS-over-HTTPS im Webbrowser. Dann bleibt Ihnen noch die Möglichkeit, mit IDS und klassischer Deep Packet Inspection in die ausgetauschten DNS-Nachrichten zu sehen und diese zu unterdrücken, falls bei externen Domains interne IP-Adressen verwendet werden.

Der Weg von Hackern in das interne Netzwerk führt nur allzu oft über den Browser, auch im Fall von DNS Rebinding. Da Benutzer derartige Attacken nur schwer erkennen können, sind sie beim Schutz auf technische Unterstützung angewiesen. Neben den Möglichkeiten zum Angriff mittels DNS Rebinding gibt es auch durchaus effektive Abwehrmaßnahmen, um sich vor derartigen Angriffen zu schützen – wobei das Filtern auf DNS-Ebene vermutlich am wirkungsvollsten ist.