Dipl.-Inform. Carsten Eilers

Der Versuch, mit dem Default-Passwort Zugriff auf den Router zu erlangen, ist eigentlich immer einen Versuch wert. So ein Versuch fällt nicht weiter auf, während ein Brute-Force-Angriff Zeit kostet. Zeit, in der das Opfer womöglich die über XSS infizierte Seite verlässt, wodurch der Schadcode beendet wird. Außerdem kann die Router-Firmware Brute-Force-Angriffe erkennen und abwehren, während ein Zugriff mit den Default-Passwort problemlos möglich ist, sofern das nicht geändert wurde. Und leider wird es oft nicht geändert, weshalb heutzutage eigentlich jede Firmware und/oder Installationssoftware des Routers das Setzen eines sicheren Passworts während der Einrichtung des Routers erzwingen sollte. Leider halten viele Entwickler das immer noch nicht für nötig.

Wurde das Default-Passwort nicht geändert, kann der Angreifer sofort auf den Router und dessen Konfigurationsdaten zugreifen. Die Default-Passwörter findet man in der Dokumentation der Router, auf den Supportseiten der Hersteller - oder auch gesammelt im Netz, zum Beispiel in der früher bekanntesten, inzwischen veralteten Default Password List von Phenoelit. Aktuellere Versionen sind zum Beispiel RouterPasswords.com oder die Default Passwords auf CIRT.net, weitere liefert Ihnen die Suchmaschinen Ihres geringsten Misstrauens reichlich. Wie man an den Listen sehen kann, kommt man mit so phantasievollen Kombination wie admin/admin oder admin/leer (jeweils Benutzername/Passwort) bei ziemlich vielen Geräten ans Ziel.

Das Einloggen ist dabei zumindest mit der HTTP Basic Authentication extrem einfach, es muss nur ein Request an den Router geschickt werden, in dem Benutzername und Passwort mitgeschickt werden. Dafür kann zum Beispiel ein IMG-Tag dienen:

<img src="http://admin:pass@192.168.1.1/"></img>

Damit wird der Benutzer admin mit dem Passwort pass beim Rechner mit der IP-Adresse 192.168.1.1 angemeldet.

Erfolgt die Authentifizierung über ein Formular in der Weboberfläche des Routers muss ein entsprechender Request an den Router geschickt werden, zum Beispiel nach dem folgenden Muster:

<img src="http://192.168.1.1/login?user=admin&password=pass"></img>

Sind POST-Parameter nötig, muss der Angreifer nur ein entsprechendes (natürlich unsichtbares) Formular vorbereiten und über JavaScript abschicken.

So ein einfaches Einloggen ist für einen Angriff ein bisschen wenig, zumal das ja auch fehlschlagen kann. Der JavaScript-Schadcode muss daher die Reaktion des Routers auswerten und je nachdem, ob das Einloggen erfolgreich war oder nicht entweder die gewünschten Manipulationen durchführen oder einen neuen Anmeldeversuch starten.

Es gibt dabei nur ein kleines Problem: Waren die Zugangsdaten falsch, gibt der Router eine Fehlermeldung zurück. Die der Benutzer besser nicht zu sehen bekommen sollte. Dummerweise wird bei der HTTP Basic Authentication aber vom Browser eine Alertbox geöffnet, die nicht unterdrückt werden kann. Aber falls der Schadcode schnell genug ist, hat er sich erfolgreich authentifiziert, bevor der Benutzer auch nur auf die erste Meldung eines falschen Passworts reagiert. Und selbst wenn der Benutzer in der Alertbox auf "Abbruch" klickt ändert das nichts am Erfolg des Angriffs.

Beispielcode für das Ausprobieren von Passwörtern haben zum Beispiel Phil Purviance und Joshua Brashars auf der Black Hat USA 2012 in ihrem Vortrag "Blended Threats and JavaScript: A Plan for Permanent Network Compromise" präsentiert, auf den ich in der nächsten Folge noch zurück kommen werde.

Ein Brute-Force-Angriff auf die Authentifizierung

Ein Brute-Force- oder Wörterbuch-Angriff auf die Authentifizierung folgt dem obigen Muster, nur dass keine Default-Zugangsdaten ausprobiert werden, sondern entweder vom Schadcode erzeugte oder auf einer Liste enthaltene Zugangsdaten getestet werden.

Das Ausnutzen von Schwachstellen im Router

Die Router-Firmware enthält wie jede andere Software auch Fehler, und einige davon stellen Schwachstellen dar. Eine Übersicht über Router-Schwachstellen gibt zum Beispiel die Website Routerpwn, und auch das Metasploit Framework oder die Exploit Database enthalten Exploits für Router.

Ein Beispiel für eine Router-Schwachstelle ist CVE-2015-1187, für die es auch ein Metasploit-Modul gibt. Der NCC-Service verschiedener D-Link- und TRENDnet-Router enthält eine klassische Command-Injection-Schwachstelle im ping-Befehl: Eingeschleuste Shell-Befehle werden ausgeführt. Ein Angreifer kann diese Schwachstelle ausnutzen, um die Kontrolle über den Router zu übernehmen.

Angriffe "in the wild"

Dass derartige Angriffe auf Router keine graue Theorie sind, zeigt das hier bereits erwähnte "in the wild" entdeckte Exploit-Kit für Router. Präparierte Webseiten ermitteln erst die lokale IP-Adresse und danach die des Routers, um den dann anzugreifen. Dabei werden sowohl bekannte Schwachstellen wie zum Beispiel die oben erwähnte CVE-2015-1187 als auch Default-Zugangsdaten genutzt, um Zugriff auf den Router zu erlangen. Danach werden dessen DNS-Einstellungen manipuliert, so dass die DNS-Abfragen an einen Server der Cyberkriminellen gehen. Die dann den Netzwerkverkehr ihrer Opfer beliebig umleiten können.

Die Manipulation der DNS-Einstellungen ist dabei fast noch die einfachste, wenn auch nicht gerade ungefährlichste Möglichkeit für einen Angriff. Der Angreifer könnte auch die Router-Firmware gegen eine manipulierte Version mit beliebigen Schadfunktionen austauschen. Während sich die DNS-Einstellungen leicht erkennen und auch wieder ändern lassen, wird man eine manipulierte Firmware nicht so einfach wieder los. Mehr dazu in der nächsten Folge.

Carsten Eilers

Übersicht über alle Artikel zum Thema

Cross-Site Scripting im Überblick, Teil 1: Reflektiertes XSS

Cross-Site Scripting im Überblick, Teil 2: Persistentes XSS

Cross-Site Scripting im Überblick, Teil 3: Der MySpace-Wurm Samy

Angriffe über Cross-Site Scripting: Der Sourcecode des MySpace-Wurms Samy

Cross-Site Scripting im Überblick, Teil 4: DOM-basiertes XSS

Cross-Site Scripting im Überblick, Teil 5: Resident XSS

XSS-Angriffe, Teil 1: Informationen einschleusen

XSS-Angriffe, Teil 2: Cookies und Tastendrücke ausspähen

XSS-Angriffe, Teil 3: Zugangsdaten ausspähen

XSS-Angriffe, Teil 4: Ein Blick in die History, und dann auf ins LAN!

XSS-Angriffe, Teil 5: Ein Portscan (nicht nur) im LAN

XSS-Angriffe, Teil 6: Ein verbesserter Portscanner

XSS-Angriffe, Teil 7: Hindernisse beim JavaScript-Portscan beseitigen

XSS-Angriffe, Teil 8: Ein Portscan mit WebSockets oder Cross-Origin Requests

XSS-Angriffe, Teil 9: Der Router im Visier

XSS-Angriffe, Teil 10: Weitere Angriffe auf den Router

XSS-Angriffe, Teil 11: Unerwünschtes Firmware-Update für den Router

XSS-Angriffe, Teil 12: Browser-basierte Botnets

XSS-Angriffe, Teil 13: Fortgeschrittene Angriffe

XSS-Angriffe, Teil 14: Das Browser Exploitation Framework BeEF