Skip to content

Cross-Site Scripting im Überblick, Teil 2: Persistentes XSS

Eine Universal XSS Schwachstelle, wie sie im Internet Explorer gefunden wurde, ist für Angreifer natürlich das beste, was ihnen passieren kann. Denn darüber können sie jede Webseite über XSS angreifen, unabhängig davon ob es dort eine XSS-Schwachstelle gibt oder nicht.

Zum Glück sind solche Schwachstellen selten und die Cyberkriminellen daher auf herkömmliche XSS-Schwachstellen angewiesen. Der Klassiker sind dabei das in der vorherigen Folge vorgestellte reflektierte XSS und das auch als JavaScript-Injection bezeichnete persistente XSS, um das es im folgenden geht.

Persistentes XSS

Persistentes XSS funktioniert fast genauso wie reflektiertes XSS, nur das der Angreifer nun seinen JavaScript-Schadcode zum Beispiel in einem Kommentar unter einem Blogeintrag, in einem Eintrag im Gästebuch oder einer der vielen Möglichkeiten des "User Generated Content" im Web 2.0 speichert. Immer vorausgesetzt natürlich, dort gibt es eine entsprechende Schwachstelle und der XSS-Code kann eingeschleust werden.

Immer, wenn der manipulierte Eintrag aufgerufen wird, wird der darin gespeicherte JavaScript-Schadcode des Angreifers im Webbrowser des Benutzers im Kontext der betroffenen Webanwendung ausgeführt.

Dabei ist es egal, ob ein Benutzer gezielt auf diese Seite gelockt wird, sie während des normalen Besuchs der Website erreicht oder zum Beispiel von einer Suchmaschine kommt. Auch ist es prinzipiell egal, ob die Seite von einem normalen Benutzer aus dem Internet heraus ausgerufen wird, oder ob ein Administrator sie aus dem Backend der Webanwendung heraus öffnet. Jedenfalls, so lange die Seite im Browser gerendert wird. Öffnet der Admin sie zum Beispiel in einem Editor-Fenster des Backends, wird der enthaltene Code natürlich nicht ausgeführt, sondern dargestellt.

Den prinzipiellen Ablauf des Angriffs zeigt folgendes Bild:

Persistentes XSS
Abb. 1: Persistentes XSS

Persistentes XSS betrifft im allgemeinen nicht nur eine einzelne Seite einer Website, sondern alle der betroffenen Kategorie. Ist zum Beispiel eine Kommentarfunktion für XSS anfällig, betrifft das alle darüber eingegebenen Kommentare und nicht nur die eines bestimmten Eintrags oder was auch immer.

Dementsprechend kann ein Angreifer seinen Code auch auf mehreren Seiten eingeben. Oder eingeben lassen. Zum Beispiel vom Schadcode selbst: Der könnte zum Beispiel eine Funktion enthalten, über die er sich selbst bei jedem Aufruf im Namen des jeweiligen Benutzers als neuer Kommentar unter einem weiteren Artikel einträgt. Und schon haben wir sich selbst vervielfältigen Code und damit etwas, was man allgemein als (Computer-)Wurm bezeichnet. Oder genauer: Einen XSS- oder Web-Wurm.

Eigentlich geht es ja erst später um die möglichen Angriffe, XSS-Würmer beschreibe ich aber schon an dieser Stelle. Aus dem einfachen Grund, dass das einfache Verbreiten als Wurm die eine Sache ist (um die es hier geht). Denn was die Würmer sonst noch alles anstellen können, ist ganz einfach alles, was sich auch ganz allgemein über XSS erreichen lässt. Und das wird später beschrieben.

Ein Beispiel für einen XSS-Wurm: Der MySpace-Wurm Samy

Als Beispiel für einen XSS-Wurm verwende ich mal wieder mein Lieblingsbeispiel: Samy, den MySpace-Wurm. Das hat viele Gründe. Zum Beispiel war er der erste seiner Art. Auch ist er sehr gut dokumentiert. Er enthält keine weiteren Funktionen außer der Verbreitungsroutine und lenkt damit nicht vom wesentlichen ab. Und er hat den großen Vorteil, ein echter "In the Wild" entdeckter Wurm zu sein. Und sogar ein äußerst erfolgreicher.

Das Konzept eines Web-Wurms kann man natürlich an jeder Menge konstruierter Beispiele eben so gut beschreiben wie am Beispiel eines echten Wurms. Aber die bekommen immer schnell das "Das funktioniert ja nur unter Laborbedingungen"-Etikett angeheftet. Samy ist der erste und beste Beweis dafür, dass Web-Würmer möglich sind und Schaden anrichten können.

Entwickelt wurde Samy (der Wurm) von Samy Kamkar, der für diesen Angriff unter anderen mit 3 Jahren Computer-Verbot bestraft wurde, danach aber noch mehrmals erfolgreich als Sicherheitsforscher auf neue Gefahren aufmerksam gemacht hat.

Samy Kamkar war 2005 der Meinung, zu wenig Freunde auf MySpace zu haben. Samy (der Wurm) sollte das ändern. Und tat es so erfolgreich, dass MySpace seine Website abschalten musste, um die Freundesflut zu stoppen.

Ausgehend von Samy Kamkars Profilseite verbreitete sich der Wurm über eine persistente XSS-Schwachstelle in die Profilseiten der Besucher eines befallenen Profils. Über einen XMLHttpRequest wurde Samy zum Freund und 'Hero' des Besuchers gemacht und der Wurmcode in dessen Profilseite integriert. Innerhalb von 20 Stunden hatte Samy Kamkar mehr als 1 Million Freunde und Samy (der Wurm) entsprechend viele Profile verseucht. MySpace musste den Betrieb vorübergehend komplett einstellen, um den Wurm zu stoppen und alle befallenen Seiten zu reinigen.

Wie Samy (der Wurm) funktioniert, erfahren Sie in der nächsten Folge.

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 "Insecure Web Interface". Aber wenigstens sind wir beim zweiten