Dienstag, 7. September 2010


Topthema

Donnerstag, 13. Dezember 2007 | Topthema

About Security #135: XSS-Angriffe (5): JavaScript Portscan vorbereiten

(Link zum Artikel: http://www.entwickler.de/php/kolumnen/040125)

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.

N E U ! Security aktuell
T�glich aktuelle Security-Infos!

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:

About Security: Die komplette Serie
  • 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.

Wenn Sie Fragen oder Themenvorschl�ge haben, k�nnen Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

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

Kommentare

Folgende Links könnten Sie auch interessieren