© saicle/Shutterstock.com
Wie sieht es derzeit mit der Sicherheit von HTML5 und JavaScript aus?

Angriffsziel Webbrowser


Zuletzt haben wir 2012 über die Sicherheit von HTML5 gesprochen [1], [2]. Da drängt sich doch die Frage auf, wie es denn aktuell um die Sicherheit von HTML5 und JavaScript bestellt ist. Gibt es neue Angriffe?

Die gute Nachricht vorweg: Neue Angriffe „in the wild“ gab es nicht, im Wesentlichen haben sich die Cyberkriminellen auf das Likejacking [3], also Clickjacking-Angriffe auf Facebooks Like-Button, beschränkt. Dafür waren die Sicherheitsforscher deutlich aktiver. Das Folgende ist ein kleiner Überblick über die aktuellen Forschungsergebnisse.

Botnet im Webbrowser ...

Die Idee, dass man ein Botnet aus Webbrowsern aufbauen könnte, ist schon etwas älter. Eine gute Beschreibung hat zum Beispiel Robert McArdle von TrendMicro 2011 veröffentlicht [4]. Bisher ist es zum Glück bei der Idee geblieben, noch haben die Cyberkriminellen die Möglichkeiten der Browser nicht für diesen Zweck genutzt. Dafür haben die Sicherheitsforscher die Möglichkeiten so eines Botnets immer weiter ausgelotet.

... dank Werbung

Auf der Sicherheitskonferenz Black Hat USA 2013 haben Jeremiah Grossman und Matt Johansen Ende Juli 2013 Angriffe über browserbasierte Botnets vorgestellt [5]. JavaScript-Schadsoftware im Browser hat viele Vorteile: Es gibt keine verräterische Schadsoftware auf dem Rechner, es werden keine Exploits zum Ausnutzen von Schadsoftware gebraucht, und 0-Day-Schwachstellen sind auch nicht nötig. Dazu kommt, dass der Missbrauch des Browsers keine Spuren hinterlässt: Nachdem der Benutzer die Webseite mit dem JavaScript-Schadcode verlassen hat, ist sie verschwunden (vorausgesetzt ihr Cachen wird verhindert). Das besonders Unschöne daran: Das ist kein Fehler, sondern ein Feature – das Web, vor allem das Web 2.0, ist darauf angewiesen, dass JavaScript-Code im Browser ausgeführt werden kann.

Jetzt stellen sich natürlich zwei Fragen: Wie kommt der JavaScript-Schadcode in den Browser, und was kann er anrichten? In den Browser gelangt er zum Beispiel auf Websites der Cyberkriminellen, kompromittierten harmlosen Websites, über präparierte Werbeanzeigen (dazu gleich noch mehr), Man-in-the-Middle-Angriffe in WLANs, Widgets, ... – wo ein Wille ist, ist auch ein Weg. Und nachdem der Schadcode erst mal in möglichst viele Browser eingeschleust wurde, kann er zum Beispiel Informationen wie Login-Daten oder Session-Cookies im Browser ausspähen, Cross-Site-Request-Forgery- und Clickjacking-Angriffe starten, klassische Schadsoftware über eine Drive-by-Infektion installieren [6], DDoS-Angriffe starten oder Klickbetrug begehen.

Als Beispiel für einen Angriff haben Jeremiah Grossman und Matt Johansen beschrieben, wie über präparierte Werbeanzeigen verbreiteter JavaScript-Schadcode DDoS-Angriffe durchführen kann. Der Schadcode dafür besteht lediglich aus einer FOR-Schleife, die zehntausend Mal ein Bild von der anzugreifenden Website lädt. Diese 10 000 Requests würde ein Webserver ja noch verkraften, wenn sie aber parallel von ein paar Tausend Webbrowsern abgeschickt werden, wird es schon enger.

... für verteiltes Rechnen

Jeremiah Grossmans und Matt Johansens Vortrag war nicht der erste zum Thema „Botnets im Webbrowser“. Auf der Black Hat Europe 2013 im März hatte Marc Blanchou beschrieben, wie ein browserbasiertes Botnet permanent Code ausführen und den Grafikprozesssor (die GPU) für Berechnungen missbrauchen kann [7]. Der Schadcode im lokalen Speicher (zum Beispiel im HTML5 Web Storage, einer cientseitigen Datenbank oder einer Browsererweiterung) gespeichert und zum Beispiel über Cross-Frame-Scripting am Laufen gehalten. Über WebGL, NaCL oder Flash wird OpenGL ES und darüber dann die GPU angesteuert, um zum Beispiel ausgespähte Passwort-Hashes zu knacken oder Bitcoins zu berechnen. Marc Blanchous Fazit: Browser-Botnets für verteiltes Rechnen stehen derzeit noch vor einigen Schwierigkeiten, die aber durch die Integration von OpenGL ES 3.0 und WebCL in die Browser weniger werden.

... aus dem Proxy

Noch vor diesen beiden Vorträgen haben Chema Alonso und Manu „The Sur“ auf der Black Hat USA 2012 einen Ansatz für die Nutzung von browserbasierten Botnets vorgestellt [8]. Dieser geht davon aus, dass der Botnet-JavaScript-Code von einem Man-in-the-Middle eingeschleust wird. Diese Situation ist zum Beispiel gegeben, wenn die Benutzer TOR oder Proxy-Server verwenden. Allerdings wird die Gefahr eines solchen Angriffs im Fall von TOR durch dessen Sicherheitssysteme reduziert, die regelmäßig zufällige Tests durchführen, deren Antwort bekannt ist. Ist die Antwort manipuliert, wird der verantwortliche TOR-Node blockiert. Die beiden Forscher haben daher für ihre Versuche einen anonymen Proxyserver verwendet. An alle über den Proxy übertragenen JavaScript-Dateien wurde Code zum Laden des Browser Exploitation Framework BeEF [9] angehängt.

Die Adresse des präparierten Proxyservers wurde dann an entsprechenden Stellen im Internet veröffentlicht, danach mussten die beiden nur noch warten, wie viele „böse Buben“ ihren Proxy nutzen. Denn das war einer der Gründe für die Experimente: Das browserbasierte Botnet sollte gegen Cyberkriminelle eingesetzt werden, von denen auch einige erwischt wurden.

Da das BeEF verwendet wurde, waren grundsätzlich alle Aktionen möglich, die dieses umfangreiche Tool unterstützt, wie zum Beispiel:

  • Informationen sammeln (Fingerprinting des Browsers, Informationen über das System und den Benutzer (werden Social Netzworks oder TOR genutzt, wurden bestimmte URLs besucht))

  • Social Engineering (Abphishen von Zugangsdaten, Umleiten zu anderen Seiten, Einschleusen von Chrome-/­Firefox-Erweiterungen, Clickjacking)

  • Erkundung des lokalen Netzwerks (Ermitteln der internen IP-Adresse, Ping an Server senden, DNS-Enumeration, Portscans, CSRF-Angriffe auf Router etc.)

  • Nutzung des Exploit-Frameworks Metasploit zum Ausnutzen von Schwachstellen

  • Nutzung als HTTP-Proxy

  • Suche nach XSS-Schwachstellen im lokalen Netz (die natürlich auch über d...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang