Unnoticed Takeover – Warum man XSS nicht unterschätzen sollte

Unnoticed Takeover – Warum man XSS nicht unterschätzen sollte

Leider erlebt man es immer häufiger, dass XSS (Cross-Site-Scripting) Schwachstellen von vermeintlichen Sicherheitsexperten belächelt und als harmlos abgefertigt werden. Gerade wenn es sich um nicht-persistentes bzw. reflektiertes Cross-Site-Scripting handelt, wird die Schwachstelle in der Regel als harmlos bezeichnet. In diesem Beitrag möchte ich die Kollegen aus der Branche wachrütteln und auf die enorme Gefahr solcher Sicherheitsprobleme hinweisen. XSS ist durchaus keine harmlose Sache, die man einfach vom Tisch schieben sollte. Glauben Sie nicht?

In der häufigsten Theorie und Praxis ist XSS eine Manipulation der Seitenausgabe, verursacht durch ein Ausbrechen aus der eigentlichen Funktion. Dabei dient zum Beispiel ein Suchbegriff – überliefert durch Parameter der Suchfunktion – zum Einschleusen von zusätzlichem Code. So kann ein Angreifer zum Beispiel den Suchbegriff mit HTML-Code erweitern und damit externen Inhalt ausgeben lassen. Ich demonstriere dies meist durch die Einbindung eines Videos oder meiner Kollegin „Nyan Cat“.

Handelt es sich um eine nicht-persistente XSS-Schwachstelle, so geht man meist davon aus, dass die Lücke absolut harmlos ist, da die Manipulation schließlich nicht gespeichert wird und ein Besucher gezielt auf die manipulierte Seite gelockt werden muss, um den Angriff durchführen zu können. Tatsächlich ist es so, dass ein Angreifer seine Opfer gezielt locken muss, sofern die Manipulation nicht dauerhaft gespeichert wird (wie es zum Beispiel bei Lücken in einem Gästebuch, Forum oder bei ähnlichen Funktionen möglich wäre). Aber gerade der Fakt, dass die Manipulation nur temporär auftritt, macht gerade diesen Angriff besonders attraktiv.

1. Der Angreifer kann theoretisch nicht belangt werden, da es nicht notwendig ist, die Manipulation direkt durchzuführen und die Lücke zum Speichern der manipulierten Inhalte zu nutzen. Wird einem Angreifer eine derartige Lücke bekannt, so kann er vom betreffenden System entfernt einen indirekten Angriff starten. Der Angreifer kann selbst über Logfiles nicht entdeckt werden, wenn er weiß was er tut.

2. Kann der Angriff über POST durchgeführt werden, bleibt er in der Regel sogar komplett unentdeckt. In typischen Logfiles tauchen die Parameter eines POST-Requests nicht auf. Der Betreiber sieht also nur, dass Aufrufe einer Seite erfolgten, jedoch nicht, dass die Parameter manipuliert waren. Anders verhält es sich bei GET-Requests, in denen die Parameter für den Admin sichtbar sind. Hierbei lässt sich ein Angriff meist schnell aufdecken und die dadurch bekannte Schwachstelle beseitigen.

Was ich in den vergangenen Jahren sehr häufig festgestellt habe ist, dass Betreiber nach meinen Hinweisen die Schwachstellen beseitigen wollten, indem lediglich die Verarbeitung der GET-Parameter unterbunden wurde. Man ging davon aus, dass POST-Parameter eine sichere Sache sind, wenn es um XSS geht. Das ist leider komplett falsch und sollte auf gar keinen Fall so gehandhabt werden. XSS über POST schüttelt zwar die Kiddies unter den Angreifern ab, da die Kompetenzen fehlen das Ausnutzen derartiger Schwachstellen über POST durchzuführen, allerdings hält dies nicht den Wissenden davon ab. XSS über POST macht es dem Angreifer zwar schwieriger, seine Opfer auf die manipulierten Seiten zu locken und dabei komplett unentdeckt zu bleiben, aber es schützt nicht grundsätzlich vor Übergriffen.

Die einfachste Möglichkeit für einen Angreifer, XSS über POST-Parameter durchzuführen ist, ein automatisch ausgeführtes Formular via Javascript, auf einer externen Seite abzulegen. Das Opfer ruft also zunächst die Seite mit dem präparierten Formular auf und wird dann automatisch – zusammen mit dem mitgegebenen POST-Request, an das Ziel geleitet, wo dann die XSS-Schwachstelle über POST ausgenutzt wird. Hierzu kann der Angreifer nun das präparierte Formular irgendwo im Netz ablegen oder gar – wenn er Fuchs genug ist – eine weitere XSS-Schwachstelle bei einer anderen Seite nutzen und dort das Formular einschleusen. So bleibt er weiterhin unerkannt und kann – selbst bei ausführlichen Recherchen – nicht ermittelt werden (wenn er es richtig anstellt).

Was viele Administratoren und Sicherheitsexperten leider bis zum heutigen Tag nicht verstanden haben ist, dass sich XSS meist in jede Richtung ausnutzen lässt. Die meisten Ansprechpartner die ich bisher hatte gingen davon aus, dass man bei XSS lediglich Text ändern, eine Messagebox öffnen, oder Bilder einfügen könnte. Das ist aber leider nur ein kleines Stück vom großen Kuchen. Durch XSS lassen sich meist beliebige Inhalte einfügen, extern angelegtes Script einbinden, die Besucher direkt umleiten – ohne dabei den Inhalt der Browserzeile zu verändern – und Vieles mehr. Anders als bei einer SQL-Injection oder anderen Schwachstellen, bietet XSS eine Art Schweizer Taschenmesser für einen Angreifer. Er kann sich quasi aussuchen, wie er seine Opfer angreifen möchte.

Halten wir also zunächst fest, dass:

1. ein Angreifer bei XSS-Schwachstellen unerkannt bleiben kann.
2. es egal ist, ob GET- oder POST-Request – das Potential bleibt gleich.
3. jegliche Manipulation stattfinden kann – der Angreifer also ein starkes Werkzeug erhält.

Um die geballte Gefahr bei XSS-Schwachstellen einmal zu verdeutlichen, möchte ich die Problematik in folgendem Beispiel genauer definieren und dabei mögliche Auswirkungen eines solchen Angriffs verdeutlichen.

Als Beispiel nehme ich die gängige Problematik der meisten Webanwendungen. Die Entwickler der meisten Webanwendungen legen zwar viel Wert auf die Sicherheit der Systeme, jedoch meist nur im Frontend – also der Ebene, die für den Besucher zugänglich ist. Die Administrationsbereiche sind für den Besucher nicht zugänglich, darum ignoriert man hier meist gravierende Schwachstellen, weil man davon ausgeht, dass ein Angreifer ja gar nicht erst dort Zugriff erlangt. Kennt der Angreifer aber XSS-Schwachstellen im Backend, kann das Ganze durchaus eine interessante Sache werden.

Gehen wir einmal davon aus, dass ein Angreifer Kenntnis von einer SQL-Schwachstelle im Administrationsbereich eines Shopsystems hat. Er kann sie nicht direkt ausnutzen, weil er keinen Zugang zum Zielsystem hat, kennt aber eine XSS-Schwachstelle im Frontend oder auch im Backend des Shopsystems. Was würden Sie denken, wenn ich Ihnen jetzt sage, dass dies der Schlüssel zum erfolgreichen Takeover sein wird? Sie werden sicher schmunzeln. Der Angreifer kann sich durch eine XSS-Schwachstelle im Frontend oder auch Backend, Zugriff auf höhere Ebenen verschaffen und dann seinen eigentlichen Angriff durchführen, ohne dass Sie als Admin/Shopbetreiber/Mitarbeiter Kenntnis davon haben werden. Der Angreifer wird dadurch sogar komplett unerkannt bleiben. Wie das funktionieren soll?

Der kombinierte Angriff mit 99% Erfolgsquote

Ein Angreifer könnte die XSS-Schwachstelle nutzen und Ihnen als Betreiber/Admin/Mitarbeiter über das Kontaktformular des Shopsystems – welches ja in der Regel zur Standardausrüstung gehört – den Link zur manipulierten Seite schicken. Dabei wird beim Seitenaufruf ein Iframe eingebunden, welches in seinen Dimensionen nahezu unsichtbar erscheint und gleichzeitig ein Iframe, welches die sichtbaren Inhalte liefert. Sie sehen die bekannte Seite Ihres Onlineshops, während sich im anderen – nicht sichtbaren – Iframe der eigentliche Angriff abspielt. Der Angreifer könnte nun bei seinem Angriff eine automatisierte Abfolge und Ihre eigene – aktive Session – im Administrationsbereich nutzen, um die SQL Injection im Backend durchzuführen und durch eingebundenes Javascript die Ausgabe weiterleiten zu lassen. Alternativ – sollten Sie nicht in der Administration angemeldet sein – kann er Ihnen ein manipuliertes Login-Formular präsentieren und so an Ihre Logindaten gelangen. Durch das Verschleiern der Parameter bzw. der Inhalte in der Browserleiste, werden Sie als Opfer in der Regel keinen Wind davon bekommen, dass der Angreifer sich gerade an Ihrem System austobt. Zudem ermöglicht das Iframe, dass Sie im Shop navigieren können und trotzdem der Angriff stattfinden kann. Sie navigieren dann im Iframe – ändern also nicht die URL der Hauptseite – und bieten daher genügend Zeit für das Script, den Angriff durchzuführen.

Sollte ein Angreifer auf diesem Weg in Ihr Leben treten, dann können Sie sicher sein, dass er seine Möglichkeiten ausnutzen wird. Im beschriebenen Beispiel hat er nun entsprechende Informationen aus Ihrer Datenbank gelesen und ggf. noch Ihre Logindaten, um sich selbst in der Administrationsoberfläche anmelden zu können. Selbst wenn Sie kurze Zeit später Verdacht schöpfen, kann es bereits zu spät sein.

Was man hierzu noch anmerken sollte: Sie werden den Angreifer in der Regel nicht ausfindig machen können – anders als bei gewöhnlichen Angriffen mit einer SQL Injection. Denn in diesem Fall haben ja Sie als Opfer den Angriff erst angestoßen. In den Logfiles wird also nicht der Angreifer mit seiner SQL Injection auftauchen, sondern Sie als Opfer.

Was ich hier nun beschrieben habe, ist ebenfalls nur ein kleiner Teil des Möglichen. Grundsätzlich kann man über XSS-Schwachstellen so einigen Unfug treiben. In den vergangenen Jahren war es hauptsächlich das Verbreiten von Malware und das Ausnutzen von Schwachstellen im Webbrowser des Besuchers, was XSS sehr attraktiv gemacht hat. Gerade durch die schnelle Verbreitung von manipulierten Links, über „Lockmittel“ in sozialen Netzwerken, wird die Gefahr und Wahrscheinlichkeit für einen Angriff immer größer.

Sind Sie nun also weiterhin der Meinung, dass XSS absolut harmlos ist?