Dipl.-Inform. Carsten Eilers

Was kann ein Angreifer mit den bisher vorgestellten Funktionen erreichen? Er kann im lokalen Netz nach Webservern und Webanwendungen suchen und sowohl ihre Existenz als auch ihre Identität feststellen. Dabei könnte ein Angriff zum Beispiel in folgenden Schritten ablaufen:

• Ein Benutzer besucht eine vertrauenswürdige Webseite, in die über eine persistente Cross-Site-Scripting-Schwachstelle JavaScript-Schadcode eingeschleust wurde.
• Der Schadcode wird im Browser des Benutzers ausgeführt und ermittelt zuerst die lokale IP-Adresse.
  Wird dafür Java verwendet, wird der Benutzer gefragt, ob er das Java-Applet ausführen lassen möchte. Der Benutzer wird misstrauisch, lehnt ab und schließt die Seite.
• Nehmen wir mal an, dass die lokale Adresse mühsam über JavaScript ermittelt wird und der Benutzer nichts davon merkt. Ausgehend von dieser IP-Adresse wird ein JavaScript-Portscan in einem Teil des lokalen Netzes gestartet.
• Beim Portscan wird zum Beispiel der DSL-Router im lokalen Netz gefunden. Der ist aber meist über HTTP-Auth vor unbefugten Zugriffen geschützt, so dass sich das Eingabefenster für Benutzername und Passwort öffnet. Der Benutzer wird misstrauisch und schließt sowohl das Eingabefenster als auch die Seite.

So wird das nichts - also muss das Öffnen des HTTP-Auth-Popups verhindert werden.

HTTP-Auth-Popup verhindern

Möchte man das Öffnen des HTTP-Auth-Popups verhindern, muss man eine Datei anfordern, bei der der Browser auf die Abfrage der Authentifizierungsdaten beim Benutzer verzichtet. Das ist bei einigen Browsern zum Beispiel beim Laden des Favicons der Fall, bei Mozilla-Browsern auch beim Vorladen (Prefetching) von Seiten.

Da sich alle Browser beim Anzeigen des Popups unterschiedlich verhalten ist es am einfachsten, statt der Anzeige des Popups im Webbrowser schon die Anforderung der Authentifizierungsdaten durch den Webserver zu verhindern. Die Frage lautet also "Wann werden die Authentifizierungsdaten nicht angefordert?". Stefan Esser hat sich im November 2006 als erster in einem Eintrag im PHP Security Blog diesem Problem gewidmet (siehe Kopie auf archve.org).

Die einfachste Antwort lautet "Wenn der Request schon vor der eigentlichen Verarbeitung verworfen wird." Wird zum Beispiel eine syntaktisch falsche URL angefordert, bricht der Webserver deren Verarbeitung mit einem HTTP-Fehlercode 400 ("Bad Request") ab, bevor die Authentifizierungsdaten angefordert werden. Eine brauchbare URL ist zum Beispiel http://ip-adresse/% oder http://ip-adresse/%2e%2e, die manche Browser allerdings nicht absenden. Eine andere Möglichkeit, die Verarbeitung eines Requests zu verhindern, ist eine sehr lange URL. Die senden die Browser ab, und die Webserver reagieren darauf ebenfalls mit einem HTTP-Fehlercode 400.

Nachdem nun auch das Öffnen des HTTP-Auth-Popups verhindert werden kann steht einer erfolgreichen Suche nach lohnenden Zielen im lokalen Netz nichts mehr im Wege. Was ein Angreifer dort anrichten kann, ist Thema einer zukünftigen Folge. Jetzt werfen wir erst mal einen Blick auf die Möglichkeiten, die uns HTML5 mit seinen schönen JavaScript-APIs bietet. Denn bisher wurde ja nur ganz herkömmliches JavaScript verwendet, wie es schon fast von Anfang an Bestandteil der Browser war.

Ein JavaScript-API hilft bei der IP-Bestimmung

Sie erinnern sich sicher noch: In der vorherigen Folge ging es um die Frage, welche IP-Adresse der Rechner hat, auf dem der JavaScript-Portscanner läuft. Diese Frage ließ sich mit JavaScript nicht einfach beantworten, und wir mussten auf Java zurück greifen. Das heutzutage meist nicht mehr im Browser ausgeführt wird, und wenn, dann nur nach Rückfrage beim Benutzer. Womit der Angriff dem Benutzer wie oben schon geschrieben auffallen würde.

Die Alternative war eine mühsame Suche mit JavaScript, die aber auch nicht das berühmte "Gelbe vom Ei" ist. Zum einen ist sie etwas auffällig, zum anderen dauert sie womöglich zu lange und der Benutzer verlässt die infizierte Seite, bevor der Angriff richtig los geht. Was dem Angriff ein abruptes Ende beschert: Seite zu, JavaScript-Schädling tot. Jedenfalls wenn der keine Maßnahmen ergriffen hat, länger zu laufen, aber dazu komme ich später noch.

Nun gibt es ja seit einiger Zeit HTML5, und damit viele neue JavaScript-APIs. Eine davon ermöglicht es, die lokale IP-Adresse abzufragen. Zwar nicht sofort und direkt im Browser selbst, aber über den Umweg über einen externen Server. Zumindest, wenn der Browser WebRTC unterstützt. Bisher sind das Chrome, Firefox und Opera. Der Internet Explorer und Safari sind von diesem möglichen Missbrauch einer eigentlich sehr nützlichen Funktion also zumindest bisher nicht betroffen.

Mit WebRTC können Requests an STUN-Server gesendet werden, auf die der Server mit der lokalen und öffentlichen IP-Adresse des Rechners antwortet. Auf diese Antwort kann dann mit JavaScript zugegriffen werden, so dass auch eingeschleuster Schadcode sich die lokale IP-Adresse beschaffen kann. Daniel Roesler hat eine Implementierung des Verfahrens auf GitHub veröffentlicht. Die Demo dazu liefert natürlich nur unter Chrome, Firefox und Opera ein Ergebnis.

Diese Methode wird zur Zeit auch von einem Exploit-Kit für Router ausgenutzt: Präparierte Webseiten stellen wie oben beschrieben die lokale IP-Adresse fest, um dann über bekannte Schwachstellen oder mit Hilfe von Default-Zugangsdaten 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.

In der nächsten Folge geht es um Portscans im Zeitalter von HTML5, also mit Hilfe von WebSockets und Cross-Origin Requests.

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