Dipl.-Inform. Carsten Eilers

Das Browser Exploitation Framework besteht aus zwei Teilen: Dem Client-Code, der zum Beispiel über eine XSS-Schwachstelle in den Webbrowser eingeschleust wird, und dem in Ruby geschriebenen Server, mit dem der infizierte Client (genannt Zombie) sich verbindet und von dem aus die Angriffe dann gestartet werden. Der Server wiederum besteht aus dem User Interface und dem Communication Server, der für die Kommunikation mit den Zombies zuständig ist.

Der Server-Teil von BeEF kann sowohl auf einem Server installiert als auch von einer Live-CD gestartet werden. Dazu steht sowohl eine auf Ubuntu basierende BeEF-eigene Live CD als auch Kali Linux (Anleitung) zur Verfügung. Kali Linux als auf Penetration-Tests spezialisierte Live-CD enthält viele weitere nützliche Tools für Schwachstellentests, die unter anderem bei der Suche nach XSS-Schwachstellen nützlich sind.

In der Benutzeroberfläche des BeEF-Servers werden die mit dem Server verbundenen Browser angezeigt, nach Auswahl des gewünschten Opfers gibt es eine Auflistung der zur Verfügung stehenden Angriffe. Dabei wird auch angezeigt, ob

• ein Exploit mit dem ausgewählten Browser funktioniert,
• ob er funktioniert, aber vom Benutzer bemerkt wird (was in manchen Fällen wie zum Beispiel bei Social-Engineering-Angriffen sogar gewollt ist) oder
• ob er nicht funktioniert.

Ausprobieren kann man ihn natürlich in jedem Fall. Das bereits erwähnte JS-Recon läuft offiziell auch nur unter Windows, funktioniert aber auch unter Mac OS X völlig problemlos.

Der Funktionsumfang des BeEF

Der Funktionsumfang des BeEF ist äußerst umfangreich. Daher gibt es hier nur eine kleine Auswahl möglicher Angriffe.

Angriffe im Browser

Mit HTML5 wurden lokale Speichermöglichkeiten wie der Session Storage und der Local Storage eingeführt. Im Browser gespeicherte Daten lassen sich natürlich besonders gut von im Browser laufender Schadsoftware ausspähen, was im BeEF durch die Module "Get Local Storage" und "Get Session Storage" realisiert wird. Auf Grund der Same Origin Policy kann damit aber nur auf die Daten der von der BeEF-Infektion betroffenen Domain zugegriffen werden.

Auf eine vorhandene Webcam kann sowohl über Flash als auch über HTML5 WebRTC zugegriffen werden. Und wenn der Angreifer nicht weiß, wo auf der Welt der angegriffene Rechner steht, verrät ihm das Modul "Get Geolocation" dessen Standort mit Hilfe des Geolocation API von HTML5.

Angriffe im lokalen Netz

Mögliche Ziele im lokalen Netz können zum Beispiel mit dem natürlich ebenfalls vorhandenen Modul "Port Scanner" gesucht werden, das wie bereits beschrieben CORS und WebSockets zur Suche nach Rechnern im lokalen Netz nutzt. Oder auch mit dem nur auf CORS setzenden "Cross-Origin Scanner". Die interne IP-Adresse kann mittels WebRTC ermittelt werden, so dass gezielt der passenden IP-Bereich durchsucht werden kann.

Wie sich der lokale Router manipulieren lässt wurde hier bereits beschrieben. Auch das Browser Exploitation Framework enthält natürlich einige Module für Angriffe auf Router. Und weil das ja nicht die einzige interessante Netzwerkhardware im lokalen Netz ist gibt es auch Module für Angriffe auf Netzwerkkameras oder NAS.

Der Schadcode ist sehr hartnäckig

Je länger der Schadcode im Browser erhalten bleibt, desto besser für den Angreifer, und sowohl das Rootkit im Webclient als auch Browser-basierte Botnets sind sogar darauf angewiesen, dass der Schadcode möglichst dauerhaft im Webbrowser erhalten bleibt. Das BeEF enthält für diesen Zweck mehrere Module:

• Das Modul "Create Pop Under" ist für das klassische Öffnen eines neuen Fensters im Hintergrund mit dem BeEF-Code darin zuständig.
• Ebenso altbewährt ist der Einsatz eines unsichtbaren iframes mit dem BeEF-Code darin, wie er vom Modul "Create Invisible Iframe" implementiert wird.
• Das Modul "Create Foreground iFrame" lädt alle Links auf der Website in einen iframe im Vordergrund. Da der iframe die gesamte Seite überdeckt, merkt der Benutzer nicht, dass die Ursprungsseite im Hintergrund geladen bleibt. Verräterisch ist allerdings, dass sich die Adresszeile nicht ändert, und das wird dem Benutzer spätestens auffallen, wenn er eine HTTPS-Seite lädt und dabei die URL-Zeile prüft.
• Vom Modul "Man In The Browser" wird ein "Man in the Browser" implementiert. Das Modul übernimmt das Öffnen jedes angeklickten Links:
  • Links zur gleichen Domain werden über einen Ajax-Request an Stelle der vorhandenen Seite geladen und in der History eingetragen, so dass es keinen Unterschied zum normalen Verhalten gibt.
  • Links zu anderen Domains werden in einem neuen Tab geladen, da das Laden im gleichen Fenster über Ajax durch die Same Origin Policy verhindert wird.
  Das Modul bleibt so lange aktiv, bis der Benutzer die URL in der Adresszeile manuell ändert.
• Das Modul "Confirm Close Tab" fordert beim Schließen des Tabs mit dem BeEF-Code in einer Endlosschleife eine Bestätigung an. Diese Methode ist ebenso brutal wie auffällig und wird meist dazu führen, dass der Benutzer irgendwann genervt den ganzen Browser abschießt.

Einige weitere Beispiele

BeEF erlaubt zum Beispiel DoS-Angriffe auf beliebige Websites, die über WebWorker vor dem Benutzer verborgen werden. Und auch ShellShock-Angriffe sind mit BeEF möglich. Oder wie wäre es mit der Kompromittierung des lokalen Rechners, zum Beispiel über eine per Social Engineering eingeschleuste bösartige HTML Application (HTA) unter Windows? Oder Angriffe auf Cross-Plattform-Lösungen wie das PhoneGap API?

Und um die Frage, wie das BeEF in die Seiten einer Website ohne XSS-Schwachstelle einschleusen lässt kümmert sich das Wireless Attack Toolkit (WAT): Sofern das Opfer WLAN genutzt und auf einem Rogue Access Point herein fällt kann darüber der Client-Code von BeEF als Man-in-the-Middle in beliebige Seiten eingefügt werden.

Und damit ist das Thema "XSS-Angriffe" vorerst beendet. Das Thema der nächsten Woche steht noch nicht endgültig fest. Eigentlich wollte ich als nächstes die Suche nach XSS-Schwachstellen beschreiben, um das Thema XSS dann abzuschließen. Aktuelle Entwicklungen wie zum Beispiel der neue Angriff auf RC4 oder der Angriff auf den Spyware-Hersteller Hacking Tool und die dadurch bekannt gewordenen Tools der Cyber-Spione schreien eigentlich nach einer Behandlung hier im Blog. Mal sehen, wofür ich mich entscheide. Wenn es weiter so heiß bleibt haben die XSS-Artikel den Vorteil, dass sie bereits fertig sind.

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