Skip to content

DNS-Rebinding - Ein altbekannter Angriff kompromittiert Router

Ein externer Angreifer, der auf das Web-basierte Administrations-Interface des lokalen Routers zugreifen kann, und das womöglich auch noch interaktiv - das klingt eigentlich ziemlich unmöglich. Genau das hat aber Craig Heffner auf der Konferenz "Black Hat USA 2010" gezeigt. Besonders erstaunlich ist, dass es sich dabei eigentlich nur um die Kombination einiger altbekannter Angriffe und Schwachstellen, insbesondere DNS-Rebinding, handelt. Auch eigentlich längst als erledigt geglaubte Angriffe oder Schwachstellen sind also immer noch für eine Überraschung gut (Paper und Präsentation als PDF).

In dieser Folge gibt es eine Beschreibung der Grundlagen des Angriffs, d.h. der alten Angriffe und Schwachstellen, in der nächsten Folge dann die des eigentlichen Angriffs sowie mögliche Gegenmaßnahmen.

Wieso, weshalb, warum

Angriffe auf Router der "SOHO-Klasse" (Small Office, Home Office) gibt es schon seit einiger Zeit, und es gibt sogar schon Trojaner, z.B. Zlob.P, die den Router im lokalen Netz eines infizierten Windows-Rechners manipulieren. Im Allgemeinen kann ein externer Angreifer diese Router aber nur indirekt angreifen, indem er den Angriff über einen lokalen Client leitet, z.B. bei einem Cross-Site-Request-Forgery-Angriff. Ihre Nachteile für den Angreifer: Sie müssen an den jeweiligen Router angepasst werden, der Angreifer muss zumindest den Routertyp sowie die interne IP-Adresse raten. Außerdem bekommt er die Ergebnisse seines Angriffs aufgrund der Same-Origin-Policy der Webbrowser nicht zu sehen.

All diese Einschränkungen lassen sich mit einem DNS-Rebinding-Angriff umgehen, der vereinfacht so abläuft: Ein Benutzer wird dazu gebracht, JavaScript-Code vom Webserver des Angreifers zu laden. Nach dem Laden wird über DNS-Rebinding der Domainname des Angreifer-Servers mit der IP-Adresse des lokalen Routers verknüpft. Danach kann der JavaScript-Code ungehindert von der Same-Origin-Policy XMLHttpRequests an den Router senden, der dazu über den Domainnamen des Angreifers angesprochen wird. Die Requests werden von der Same-Origin-Policy erlaubt, da für die Zuordnung der Origin der Domainname verwendet wird und der JavaScript-Code für den Webbrowser von der Domain stammt, auf die er zugreift.

DNS-Rebinding allgemein: Eine Domain wechselt die IP-Adresse

DNS-Rebinding lässt sich am besten an einem Beispiel erklären. Angegriffen wird der Server www.opfer.example mit der IP-Adresse 1.2.3.4.

  1. Der Benutzer ruft aus irgendeinem Grund, z.B. aufgrund eines Cross-Site-Scripting-Angriffs, die Domain das Angreifers www.angreifer.example auf. Dafür muss der Browser dessen IP-Adresse erfragen und bekommt vom zuständigen DNS-Server die IP-Adresse 9.8.7.6 mit einem DNS-Time-to-live-Timeout (TTL) von einer Sekunde mitgeteilt.
  2. Die geladene Seite enthält einen Refresh-Aufruf nach mehr als einer Sekunde, z.B. zwei Sekunden. Der Refresh kann z.B. über das Refresh-Meta-Tag oder JavaScript-Code erfolgen.
  3. Der DNS-Eintrag ist inzwischen ungültig, da die TTL abgelaufen ist. Die IP-Adresse von www.angreifer.example wird erneut beim DNS-Server angefordert. Der DNS-Server des Angreifers kann jetzt eine beliebige gefälschte IP-Adresse zurückliefern, z.B. die Adresse 1.2.3.4 von www.opfer.example.
  4. Wenn der Webbrowser dann die IP-Adresse 1.2.3.4 aufruft, denkt er, dass er sich auf www.angreifer.example befindet, obwohl er auf www.opfer.example landet. Dadurch kann z.B. von www.angreifer.example geladener Schadcode auf die Daten von www.opfer.example zugreifen.

DNS-Pinning verhindert erschwert DNS-Rebinding

DNS-Rebinding ist ein altbekanntes Problem, dem die Webbrowser auf verschiedene Arten zu begegnen versuchen. Der verbreitetste Ansatz dafür ist das DNS-Pinning: Die Antwort auf die erste vom Browser für einen Domainnamen durchgeführte DNS-Abfrage wird für einen bestimmten Zeitraum in einem Cache gespeichert. Für weitere Zugriffe auf diese Domain wird dann die gespeicherte IP-Adresse verwendet, es finden keine weiteren DNS-Abfragen statt. Eine neue DNS-Abfrage wird erst durchgeführt, wenn die Speicherzeit abgelaufen ist oder der Browser neu gestartet wurde.

Mit DNS-Pinning funktioniert der oben beschriebene DNS-Rebinding-Angriff nicht, da der Webbrowser die Zuordnung der IP-Adressen zu den Domainnamen unabhängig von der DNS-TTL-Einstellung in seinem Cache speichert.

Gegen das DNS-Pinning setzen die Angreifer Anti-DNS-Pinning-Angriffe ein, bei denen versucht wird, das cachen zu verhindern und eine zweite DNS-Abfrage zu erzwingen, bei der dann der Domainname des Angreifers mit einer anderen IP-Adresse verknüpft wird.

DNS-Rebinding-Angriff mit doppelten Adressen

Ein weiterer altbekannter DNS-Rebinding-Angriff arbeitet mit zwei "A-Records". Die Antwort des DNS-Servers des Angreifers in Punkt 2 des Beispiels enthält dann zwei IP-Adressen: Die tatsächliche Adresse von www.angreifer.example, 9.8.7.6, und die Adresse, mit der der Angreifer seinen Domainnamen verknüpfen möchte, 1.2.3.4. Der Browser des Opfers verbindet sich mit der ersten angegebenen IP-Adresse und lädt von dort z.B eine HTML-Seite mit bösartigen JavaScript-Code. Nachdem die Seite geladen wurde, verhindert der Angreifer z.B. durch Anpassung der Firewall-Regeln weitere Zugriffe von der IP-Adresse des Opfers. Sendet der eingeschleuste Schadcode einen XMLHttpRequest an www.angreifer.example, ist der Server über die erste dem Browser bekannte IP-Adresse nicht erreichbar und er verwendet die zweite ihm bekannte Adresse 1.2.3.4, die aber zu www.opfer.example gehört - das DNS-Rebinding war erfolgreich.

Bei diesem Angriff können keine internen IP-Adressen wie die des Routers verwendet werden, da diese nicht-routbaren Adressen vom Browser bevorzugt verwendet werden. Auch wenn die interne Adresse erst an zweiter Stelle der DNS-Antwort steht, wird sie vom Browser zuerst verwendet. Schon der erste Request würde also an die interne IP-Adresse gesendet, so dass der Schadcode des Angreifers gar nicht erst geladen wird.

Was innen nicht geht, geht außen

Craig Heffner hat eine Lösung für dieses Problem gefunden: Er verwendet als zweite IP-Adresse die externe, öffentliche IP-Adresse des Routers, d.h. die, über die er im Internet erreichbar ist. Viele TCP/IP-Implementierungen akzeptieren alle einkommenden Pakete, sofern sie an irgend eine der eigenen IP-Adressen gerichtet sind. Die IP-Adresse muss nicht zu dem Interface gehören, über das das Paket empfangen wird. Insbesondere werden Pakete an die externe IP-Adresse auch am internen Interface entgegen genommen und sofort verarbeitet, sie gelangen also gar nicht bis zum externen Interface. Betroffen von dieser unsicheren Konfiguration sind u.a. Linux und viele SOHO-Router.

Die Verwendung der öffentlichen IP-Adresse hat für den Angreife einen weiteren Vorteil: Er muss die interne IP-Adresse des Routers nicht kennen. Und die öffentliche erfährt er ja beim Zugriff auf seinen Server.

Und noch ein Baustein...

Noch ein weiterer Schwachpunkt trägt dazu bei, dass der von Craig Heffner entwickelte Angriff möglich ist: Häufig sind alle Dienste des Routers, insbesondere auch der Webserver für die Administrationsoberfläche, an alle Interfaces gebunden. Eingehende Verbindungen auf dem öffentlichen (WAN) Interface werden meist über Firewallregeln abgeblockt, so dass von außen kein Zugriff auf die Administrationsoberfläche möglich ist. Dass der Netzwerkverkehr dabei anhand des Interfaces und nicht der IP-Adresse identifiziert wird, ist ungünstig, aber kaum zu ändern, da die externe Adresse meist vom ISP dynamische vergeben wird und sich daher jederzeit ändern kann.

Was bedeutet dass nun für den Fall, dass ein interner Client über das interne Interface auf die externe IP-Adresse zugreifen möchte? Der Zugriff ist möglich, da die Daten schon vom internen Interface verarbeitet werden und das externe, von dem sie nicht akzeptiert würden, nie erreichen.

Wie man aus diesen Angriffen und Schwachstellen den Angriff auf das Web-basierte Administrations-Interface zusammenstellt, erfahren Sie in der nächsten Folge.

Carsten Eilers


Übersicht über alle Artikel zum Thema

WEP, WPA, WPA2 - WLAN-Schutz, aber richtig!
"Hole196" - Eine neue Schwachstelle in WPA2
DNS-Rebinding - Ein altbekannter Angriff kompromittiert Router
Von außen durch den Client in den Router
Ciscos "WPA Migration Mode" öffnet den Weg ins WLAN
NAT-Pinning, Angriffe auf Cisco-WLANs und ein Tool
Angriffe auf den WLAN-Client
BEAST - Ein neuer Angriff auf SSL und TLS 1.0
Konfigurationsänderungen am Router per UPnP - aus dem Internet
WLAN-Sicherheit - Stand der Dinge
WPS-Schwachstelle gefährdet WLANs

Trackbacks

Dipl.-Inform. Carsten Eilers am : Filet-o-Firewall - ein neuer browserbasierter Angriff auf die Firewall

Vorschau anzeigen
Jetzt habe ich gestern doch glatt vergessen, den Text online zu stellen. Also mit kurzer Verzögerung: Wie angekündigt geht es ab dieser Folge erst mal wieder um aktuellere Themen. Den Anfang machen Schwachstellen in und Angriffe au

Dipl.-Inform. Carsten Eilers am : Drucksache: PHP Magazin 2.19 - Docker-Sicherheit

Vorschau anzeigen
Im PHP Magazin 2.2019 ist ein Artikel über die Sicherheit von Docker erschienen - als Titelthema! Eine Leseprobe des Artikels gibt es auf entwickler.de. Eine Webanwendung in einen Docker-Container zu verpacken hat viele Vorteile