Channel Security

Der in About Security #134 vorgestellte JavaScript Portscan funktioniert so wie beschrieben bereits zufriedenstellend. Was noch fehlt, ist der Startpunkt: Welche IP-Adressen sollen gescannt werden? Der Angreifer kann dabei 'blind' arbeiten und sein Script verschiedene, typische Adressbereiche für lokale Netze durchprobieren. Die meisten in Home Offices und kleinen Unternehmen eingesetzten DSL-Router verwenden in der Default-Einstellung Adressen aus dem Bereich 192.168.0.* oder 192.168.1.*, und bekanntlich werden Default-Einstellungen äußerst selten geändert. Auch bei größeren Unternehmen kann ein Versuch in diesem Bereich oder in den anderen privaten Bereichen nicht schaden, und falls das Unternehmen einen eigenen IP-Adressbereich reserviert hat, wird der natürlich auch durchsucht. Wobei ein Durchsuchen aller möglichen Bereiche am entstehenden Aufwand scheitert: Der Scan dauert schlicht zu lange, um erfolgreich abgeschlossen zu werden. Möchte der Angreifer nicht 'blind' arbeiten, muss er die aktuelle IP des Rechners ermitteln, auf dem der eingeschleuste Skriptcode läuft. Das geht nicht mit JavaScript, dafür aber mit Java.

Diese Möglichkeit wurde bereits 2003 auf der Mailingliste NT-Bugtraq erwähnt: 'Using Java from Javascript'. Eine aktuelle Beispielimplementierung gibt es bei GNUCITIZEN, der entsprechende Code ist auch Bestandteil der bereits in About Security #134 erwähnten AttackAPI. Daraus stammt auch der folgende Ausschnitt:

AttackAPI.dom.getInternalIP = function () {
 try {
 var sock = new java.net.Socket();

 sock.bind(new java.net.InetSocketAddress('0.0.0.0', 0));
 sock.connect(new java.net.InetSocketAddress(document.domain,
(!document.location.port)?80:document.location.port));

 return sock.getLocalAddress().getHostAddress(); 
 } catch (e) {}

 return '127.0.0.1';
};

Es wird eine Java-Socket-Verbindung zwischen Client und Webserver aufgebaut. Nach einem erfolgreichen Verbindungsaufbau wird die Socket-Struktur mit Informationen über die Verbindung gefüllt – darunter auch die lokale IP-Adresse, die dann nur noch abgefragt werden muss.

Zusammenfassung

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 z.B. in folgenden Schritten ablaufen:

• Ein Benutzer besucht eine vertrauenswürdige Webseite, in die über eine persistente Cross-Site-Scripting-Schwachstelle Schadcode eingeschleust wurde.
• Der Schadcode wird im Browser des Benutzers ausgeführt und ermittelt zuerst die lokale IP-Adresse.
• Ausgehend von dieser IP-Adresse wird ein JavaScript Portscan in einem Teil des lokalen Netzes gestartet.
• Beim Portscan wird z.B. der DSL-Router im lokalen Netz gefunden. Der ist aber meist über HTTP-Auth vor unbefugten Zugriffen geschützt, sodass 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 z.B. 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 als erster in einem Eintrag im PHP Security Blog diesem Problem gewidmet. Die einfachste Antwort lautet "Wenn der Request schon vor der eigentlichen Verarbeitung verworfen wird." Wird z.B. einen syntaktisch falschen URL angefordert, bricht der Webserver dessen Verarbeitung mit einem HTTP-Fehlercode 400 ("Bad Request") ab, bevor die Authentifizierungsdaten angefordert werden. Ein brauchbarer URL ist z.B. http://ip-adresse/% oder http://ip-adresse/%2e%2e, den der Internet Explorer 7 allerdings nicht absendet. Eine andere Möglichkeit, die Verarbeitung eines Requests zu verhindern, ist ein sehr langer URL. Den sendet auch der Internet Explorer 7 ab, und die Webserver reagieren darauf ebenfalls mit einem HTTP-Fehlercode 400.

Ziel erkannt – Attacke!

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 Weg. Das können je nach Größe des lokalen Netzes z.B. DSL-Router, Firewalls oder lokale Server mit für den Angreifer interessanten Daten sein. Schon ein DSL-Router enthält für einen Angreifer interessante Informationen: Die Zugangsdaten für den Internetzugang. Wie ein Angreifer die ausspähen kann, wird neben weiteren möglichen Angriffen in der nächsten Folge beschrieben.

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Sichere Webanwendungen – Cross-Site Scripting"

• About Security #14: Cross-Site Scripting
• About Security #15: Cross-Site Scripting verhindern
• About Security #129: Cross-Site Scripting, reloaded
• About Security #130: DOM-basiertes XSS abwehren
• About Security #131: XSS-Angriffe (1)
• About Security #132: XSS-Angriffe (2)
• About Security #133: XSS-Angriffe (3): JavaScript Ping & Co.
• About Security #134: XSS-Angriffe (4): JavaScript Portscan
• About Security #135: XSS-Angriffe (5): JavaScript Portscan vorbereiten
• About Security #136: XSS-Angriffe (6): DSL-Router ausspähen
• About Security #137: XSS-Angriffe (7): Weitere Ziele