Dipl.-Inform. Carsten Eilers

Craig Heffner hat zur Demonstration des Angriff das Tool Rebind (.tar.gz) entwickelt. Es führt nicht nur den DNS-Rebinding-Angriff durch, sondern agiert im Browser des Opfers auch als Proxy, über den der Angreifer dann auf den Router zugreifen kann. Dadurch muss der eingeschleuste Schadcode die Antworten des Routers nicht verarbeiten, das kann der Angreifer persönlich erledigen. Für den Angriff wird dann nur noch ein registrierter Domainname benötigt, außerdem muss der Server des Angreifers auch als Nameserver für diese Domain dienen. Das klingt einfach? Das ist einfach!

Los gehts...

Zuerst registriert der Angreifer bei einem beliebige Domain-Registrar seine Domain, dass soll für das Beispiel angreifer.example sein. Außerdem registriert er einen Nameserver, ns.angreifer.example, der auf die IP-Adresse seines Servers zeigt. angreifer.example und ns.angreifer.example sind also der selbe Server. Dieser Nameserver ist der primäre Nameserver für angreifer.example.

Schritt 1:
Die IP-Adresse des Servers des Angreifers, auf dem Rebind läuft, ist 1.2.3.4 (=angreifer.example=ns.angreifer.example), die öffentliche IP-Adresse des Opfers 9.8.7.6.

Schritt 2:
Das Opfer wird auf die Seite http://angreifer.example/init gelockt, woraufhin der Webbrowser des Opfers eine DNS-Abfrage für die Domain angreifer.example sendet.

Schritt 3:
Der Nameserver ns.angreifer.example, auf dem ja Rebind läuft, antwortet darauf mit der IP-Adresse 1.2.3.4.

Schritt 4:
Der Browser des Opfers ruft die Seite /init vom Server angreifer.example auf.

Schritt 5:
Rebind empfängt den Request, protokolliert die öffentliche IP-Adresse des Webbrowsers (d.h. die seines Routers) und sendet den Benutzer über einen Redirect zu http://foobar.angreifer.example/exec.

Schritt 6:
Der Browser stellt eine DNS-Abfrage nach der Subdomain foobar.angreifer.example von angreifer.example.

Schritt 7:
Der Nameserver empfängt die Abfrage und antwortet mit seiner IP-Adresse und der öffentlichen IP-Adresse des Routers des Opfers, die in Schritt 5 protokolliert wurde: 1.2.3.4 und 9.8.7.6.

Schritt 8:
Der Browser des Opfers ruft die Seite /exec vom Server foobar.angreifer.example auf.

Schritt 9:
Rebind sendet den JavaScript-Schadcode und blockt weitere Verbindungsversuche von der IP-Adresse des Opfers zum HTTP-Port 80 des Servers des Angreifers ab.

Schritt 10:
Der JavaScript-Schadcode sendet einen XMLHttpRequest an foobar.angreifer.example.

Schritt 11:
Da Rebind alle weiteren Verbindungsversuche blockiert, wird die Anfrage mit einem TCP-RST-Paket (Reset) beantwortet.

Schritt 12:
Der Browser des Opfers probiert automatisch die zweite ihm bekannte IP-Adresse für foobar.angreifer.example aus, die mit der öffentlichen IP-Adresse seines Routers identisch ist. Der Router akzeptiert diesen Verbindungsaufbau, obwohl er an einem für diese IP-Adresse nicht zuständigen Interface eintrifft.

Schritt 13:
Da die Subdomain foobar.angreifer.example des Angreifers nun mit der öffentlichen IP-Adresse des Routers verbunden ist, kann der Angreifer über den in Rebind enthaltenen HTTP-Proxy Requests an den Router des Opfers schicken, die von Rebind gecached werden.

Schritt 14:
Der JavaScript-Schadcode im Browser des Opfers lädt nun Anweisungen von Rebind nach. Da foobar.angreifer.example mit der öffentlichen IP-Adresse des Routers verknüpft ist, werden die Anweisungen von angreifer.example geladen, statt Port 80 (der weiterhin blockiert ist) wird Port 81 verwendet.

Schritt 15:
Rebind antwortet mit den Requests des Angreifers, die in seinem Cache gespeichert sind.

Schritt 16:
Der Schadcode im Browser des Opfers sendet die Requests des Angreifers über XMLHttpRequests an foobar.angreifer.example, d.h. den Router des Opfers.

Schritt 17:
Die Antworten des Routers werden an den Server des Angreifers gesendet.

Schritt 18:
Rebind leitet die Antwort des Browsers des Opfers an den Angreifer weiter. Der Angreifer kann die Weboberfläche des Routers nun so bedienen, als befände er sich im lokalen Netz des Opfers.

Einschränkungen

Ein kleines Problem gibt es bei diesem Angriff: Wieso kann der Angreifer auf den Router zugreifen, er kennt doch die Zugangsdaten gar nicht? In vielen Fällen braucht er das auch nicht bzw. er kennt sie eben doch. Ist das Opfer gerade im Administrations-Interface des Routers eingeloggt, kann der Angreifer diese laufende Session nutzen, es handelt sich also quasi um eine Art von Cross-Site Request Forgery. Das heißt nicht ohne Grund auch "Session Riding". Wenn der Benutzer nicht eingeloggt ist, bekommt der Angreifer die Login-Seite des Routers angezeigt und kann die Default-Zugangsdaten ausprobieren oder einen Brute-Force-Angriff starten.

Gegenmaßnahmen

Gegen den Missbrauch einer laufenden Session schützt man sich am einfachsten, indem man für die Nutzung des Administrations-Interfaces ein neues Fenster öffnet, vorher alle anderen schließt und während der Nutzung des Interfaces nicht im Internet surft. Außerdem muss man sich natürlich beim Router abmelden, wenn man fertig ist. Dass man die Default-Zugangsdaten schon bei der Installation durch sichere Zugangsdaten ersetzt, sollte selbstverständlich sein.

Ein Restrisiko bleibt: Sollte man Opfer eines Angriffs werden, kann der Angreifer zwar keine laufende Session übernehmen und bekommt nur die Login-Seite des Routers angezeigt, dessen sicher gewählten Zugangsdaten er nicht erraten kann, er könnte aber evtl. eine im Router vorhandene Schwachstelle ausnutzen. Und dagegen ist man als Benutzer i.A. machtlos. Sofern möglich, sollte man natürlich veröffentlichte Firmware-Updates zum Beheben von Schwachstellen immer installieren. Aber meist interessieren sich die Router-Hersteller gar nicht für veröffentlichte Schwachstellen, so dass diese ungepatcht bleiben.

Außerdem gibt es weitere für den Angreifer interessante Angriffspunkte wie z.B. UPnP (Universal Plug and Play) oder HNAP (Home Network Administration Protocol). Alles, was man nicht braucht, sollte man natürlich sowieso im Router deaktivieren, aber oft lassen zumindest die Administrations-Interfaces das gar nicht zu.

Craig Heffner schlägt für Benutzer folgende Gegenmaßnahmen zum Schutz vor Angriffen vor, die aber alle nicht besonders praktikabel sind:

• Mit einer Firewall-Regel auf dem Router kann Netzwerkverkehr an die öffentliche IP-Adresse, die an einem internen Interface ankommt, blockiert werden. Da diese Regel bei jeder Änderung der öffentlichen Adresse angepasst werden muss, ist sie wohl nur für Netze mit fester öffentlicher IP-Adresse interessant.
• Mit einer Firewall-Regel auf jedem Rechner im lokalen Netz kann Netzwerkverkehr an die öffentliche IP-Adresse des Routers blockiert werden. Auch diese Regel muss bei jeder Änderung der öffentlichen Adresse angepasst werden, außerdem müssen wirklich alle lokalen Rechner damit ausgestattet werden.
• Wenn möglich, können die Dienste des Routers nur an die jeweils zuständigen Interfaces gebunden werden. I.A. braucht man am Interface für das WAN/Internet keinen Webserver, aber viele Router lassen diese Konfigurationsänderung gar nicht zu.
• Der Zugriff auf das Administrations-Interface sollte über HTTPS erfolgen, sofern der Router dies unterstützt. Oft bleibt aber HTTP trotzdem aktiviert, so dass man nichts gewonnen hat.
• Man kann das Webbasierte Administrations-Interface deaktivieren

Soviel zumindest vorerst zu diesem äußerst trickreichen Einsatz altbekannter Angriffe. In der nächsten Folge geht es um einen neuen Angriff auf Ciscos WPA Migration Mode, durch den der WEP-Schlüssel ermittelt werden kann.

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