Dipl.-Inform. Carsten Eilers

Die Aktionen, die so ein Botnet ausführen kann, sind vielfältig: DDoS-Angriffe, die Verbreitung von Spam, das Generieren von Bitcoins, Phishing-Angriffe, Angriffe auf das lokale Netz, der Missbrauch als Proxy für weitere Angriffe und das Verbreiten des eigenen Codes werden von Robert McArdle aufgezählt. Im Ernstfall sind die Cyberkriminellen sicher noch viel kreativer, wenn es darum geht, Schaden anzurichten. 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.

Das Konzept unter der Lupe

Jeremiah Grossman und Matt Johansen haben auf der Black Hat USA 2013 Angriffe über Browser-basierte Botnets vorgestellt: "Million Browser Botnet".

JavaScript-Schadsoftware im Browser hat viele Vorteile: Es gibt keine verräterische Schadsoftware auf dem Rechner, es werden keine Exploits zum Ausnutzen von Schwachstellen 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. Oder kennen Sie noch viele Websites, die sich ohne JavaScript nutzen lassen? Meist gilt doch "JavaScript aus, Website aus".

Vor der Realisierung eines Browser-basierten Botnets müssen aber zwei Fragen geklärt werden: Wie kommt der JavaScript-Schadcode in den Browser, und was soll er anrichten?

In den Browser gelangt er zum Beispiel auf Websites der Cyberkriminellen, kompromittierten harmlosen Websites, über präparierte Werbeanzeigen, 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 Logindaten oder Session-Cookies im Browser ausspähen, Cross-Site-Request-Forgery- und Clickjacking-Angriffe durchführen, DDoS-Angriffe starten oder Klickbetrug begehen.

Theoretisch könnte auch klassische Schadsoftware über eine Drive-by-Infektion installiert werden, aber das wäre eine Verschwendung des Botnets. Wozu sollte man verräterische Schadsoftware auf dem Rechner installieren, so lange der unauffällige JavaScript-Bot läuft? Das wäre höchstens sinnvoll, wenn kurz vor dem Beenden des JavaScript-Codes der Rechner mit Windows-Schädlingen infiziert wird, damit man ihn weiter missbrauchen kann.

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 10.000 mal ein Bild von der anzugreifenden Website lädt. Diese 10.000 Requests würde ein Webserver ja noch verkraften, wenn diese 10.000 Requests aber parallel von ein paar Tausend Webbrowsern abgeschickt werden, wird es schon enger.

Ein Browser-Botnet für verteiltes Rechnen

Auf der Black Hat Europe 2013 hat Marc Blanchou beschrieben, wie ein Browser-basiertes Botnet permanent Code ausführen und den Grafikprozesssor (die GPU) für Berechnungen missbrauchen kann: "Harnessing GP²Us - Building Better Browser Based Botnets".

Der Schadcode wird im lokalen Speicher (zum Beispiel im HTML5 Web Storage, einer Client-seitigen Datenbank oder einer Browser-Erweiterung) gespeichert und zum Beispiel über Cross-Frame-Scripting am Laufen gehalten. In sofern gleicht dieser Teil des Angriffs einem Angriff mit Resident XSS.

Ü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 zur Zeit noch vor einigen Schwierigkeiten, die aber durch die Integration von OpenGL ES 3.0 und WebCL in die Browser weniger werden.

Ein Browser-Botnet aus dem Proxy

Auf der Black Hat USA 2012 haben Chema Alonso und Manu "The Sur" einen weiteren Ansatz für die Nutzung von Browser-basierten Botnets vorgestellt: "Owning Bad Guys {and mafia} With Javascript Botnets". Sie wollen mit ihrem Botnet Cyberkriminellen auf die Spur kommen.

Sie gehen 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 dafür verantwortliche TOR-Node blockiert. Die beiden Forscher haben daher für ihre Versuche einen anonymen Proxy-Server verwendet. An alle über den Proxy übertragenen JavaScript-Dateien wurde Code zum Laden des Browser Exploitation Framework BeEF angehängt.

Die Adresse des präparierten Proxy-Servers wurde dann an entsprechenden Stellen im Internet veröffentlicht, danach mussten die beiden nur noch warten, wie viele "böse Buben" ihren Proxy nutzen. Tatsächlich wurden einige Cyberkriminelle erwischt.

Da das BeEF verwendet wurde, waren grundsätzliche 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 URL 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 den Browser angegriffen werden können)

BeFF ist auch in der Lage, sich persistent im Browser zu installieren, eine für ein Botnet äußerst nützliche Fähigkeit.

Insgesamt bleibt als Fazit nur die Feststellung, das Browser-basierte Botnets in den Händen von Cyberkriminellen eine ziemlich große Gefahr darstellen, gegen die man sich nur schwer schützen kann. Der einzige 100%ige Schutz bestünde im Ausschalten von JavaScript, und damit dürften die allermeisten Websites nicht mehr zu benutzen sein. Wir haben also bisher wirklich Glück gehabt, dass die Cyberkriminellen mit ihren herkömmlichen Schädlingen so zufrieden sind, dass sie die Browser als Plattform ignorieren und nur als Einfallstor für Drive-by-Infektionen nutzen.

In der nächsten Folge werden noch einige weitere Möglichkeiten vorgestellt, über XSS Schaden anzurichten.

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