Bei Aufträgen mit Schwerpunkt auf Penetration Testing werden wir, salopp gesagt, dafür bezahlt wie ein Angreifer zu denken. Es geht darum herauszufinden, was für eine Person mit böswilligen Absichten als Ziel interessant erscheint, wie er dieses Ziel in der Folge erreichen kann und was der Auftraggeber tun kann, um dieses Szenario nicht zur Realität werden zu lassen. Je nach Einsatzzweck einer Applikation fordert es mehr oder weniger Kreativität einen Angriffsvektor zu erarbeiten.

Im Falle eines vor einigen Monaten durchgeführten Tests eines grossen Online-Versandhauses entschloss ich mich den Verkaufszahlen von Marcs Buch mittels einer Cross Site Request Forgery Attacke etwas auf die Sprünge zu helfen: Besuchte ein beliebiger Benutzer eine vorgängig präparierte Seite, so löste der darin enthaltene JavaScript Payload automatisiert die Bestellung von 200 Exemplaren des besagten Werkes aus und gab als Rechnungs- und Versandadresse jeweils eine zufällige Adresse aus einem vorgängig sorgfältig zusammengestellten Adresspool des Schweizer Telefonbuches an. Im Testszenario wurde diese Bestellung natürlich lediglich einmal ausgeführt und umgehend storniert – schliesslich war ja zu diesem Zeitpunkt klar, dass hier Handlungsbedarf besteht.

Nehmen wir aber an, diese Attacke hätte in der Realität stattgefunden: Der Payload hätte zum Beispiel auf einer hochfrequentierten MySpace-Seite oder einem entsprechenden Forum seinen Platz finden können, am besten mittels einer XSS-Schwachstelle, die es erlaubte ohne Interaktion des Benutzers direkt zur Tat zu schreiten – verwundbare Seiten gibt es dazu mehr als genug. Nehmen wir an, dass dort der Code ca. 10x pro Minute ausgeführt worden wäre – von verschiedenen Benutzern. Bereits nach 10 Minuten, wären in gut 100 Einzelbestellungen 20’000 Bücher bestellt worden, mit einem Gesamtwert von läppischen 1’402’000 Schweizer Franken und mit Empfängeradressen versehen, deren Eigentümer nichts von ihrem Glück ahnten. Wenn man nun davon ausgeht, dass die meisten Firmen nicht in der Lage sein dürften, den genutzten Fehler innerhalb von zwei Stunden zu korrigieren, lassen sich diese Zahlen entsprechend skalieren. Alleine die Ressourcen, die ein betroffener Händler aufwenden müsste, alle falschen Bestellungen aus den meist automatisierten Warenwirtschaftssystemen zu löschen, würden einen enormen finanziellen Aufwand bedeuten – von den Kosten für wirklich ausgeführte Fehlsendungen ganz zu schweigen. Sicherlich eine nette Art und Weise, einem allfälligen Konkurrenten das Wochenende zu versüssen.

Ein solches Szenario auszuarbeiten bedeutet verhältnismässig viel Arbeit, wenn man bedenkt, dass die zugrundeliegende Schwachstelle oftmals sehr simpel ist. Meist handelt es sich um eine Cross-Site-Scripting oder Cross-Site-Request-Forgery Schwachstelle, die es erlaubt einen Angriff aufzubauen. Die Simplizität dieser Angriffsvektoren ist auch der Grund, warum solche komplexen und detailierten Angriffsszenarien erst Sinn machen. Gerade die genannten Probleme werden oftmals kaum als solche ernstgenommen – warum auch, wenn sie in den meisten Fällen damit demonstriert werden, dass ein Angreifer in der Lage ist mittels Javascript eine Alert Box mit der Meldung “XSS” einzublenden, ohne dabei zu erklären, was eben noch alles möglich wäre. Und verglichen mit dem, was technisch im Bereich des Möglichen liegt, ist auch der obenstehende Angriff sehr trival.

Andere Dimensionen

Seit letztem Sommer arbeite ich an einer Applikation mit dem Projektnamen SWARM. Im Grunde genommen handelt es sich dabei um eine Sammlung einzelner Module, die dem Zweck dienen Angriffe auf Webapplikationen schneller und effizienter zu gestalten, um die Gefahren entsprechender Lücken besser illustrieren zu können. SWARM erlaubt es, mehrere Schwachstellen zu bündeln und für einen oder mehrere von der initialen Ladestelle unabhängigen Angriff zu verwenden.

Part 1: Infect

Unterhaltsame Videos, schlüpfrige Bilder und witzige Spielereien – im Internet wird heute in der Welt des Web 2.0 bestimmt niemandem mehr langweilig. Überall gibt es multimedialen Content, was unterhält verbreitet sich mittels Digg, Yigg, MySpace und Konsorten in Windeseile um die ganze Welt. Das bunte Treiben ist in technologischer und soziologischer Hinsicht spannend zu beobachten und auch kritische Zeitgenossen können sich ein Schmunzeln ob des jüngsten Hypes oftmals nur schwerlich verkneifen.

SWARM initiiert sich selber, indem ein Script Tag aus einer infizierten Seite geladen wird. Damit diese Tags ihren Weg in die entsprechenden Seiten finden, gibt es zwei Varianten:

• die Seite ist verwundbar für irgendeine Art der Script Injection oder
• die Seite obliegt der Kontrolle des Angreifers. So würde sich zum Beispiel eine rasch zusammengestellte Seite mit einigen Episoden einer populären Sitcom, die online angesehen werden können sicherlich gut als Ausgangspunkt eignen.

Lädt ein Benutzer den entsprechenden Code, so meldet er sich beim SWARM-0, dem zentralen Verwaltungsserver an und erhält eine eindeutige ID, der aus einem Fingerprint seiner Eigenschaften (Auflösung, User-Agent, Sprachen, IP-Bereich des Hostsystems etc.) generiert wird. Anhand dessen wird der Client auch wieder erkannt, wenn er eine andere Seite mit SWARM Loader ansprechen würde. Das ist notwendig, weil SWARM ansonsten die Kontrolle jedes Mal ohne Restore-Möglichkeit verlieren würde, wenn der Benutzer die Seite wechselt. Ist der Benutzer erst einmal registriert, so holt er in regulären Abständen Befehle von SWARM-0 ab, die er im Hintergrund ausführt. Als ersten Befehl erhält er vom SWARM den Befehl ein unsichtbares Flash-Objekt in die eben aufgerufene Seite zu laden, das zur Ausführung bestimmter Befehle verwendet wird.

Part 2: Maintain

Der Angreifer kontrolliert die aktiven SWARM-Clients mittels der zentralen Konsole SWARM-0. Hier kann er verschiedene Aktionen zuweisen, die daraufhin von den selektieren Clients ausgeführt werden. Nehmen wir nun z.B. an, der Angreifer möchte einen Angriff wie den eingangs beschriebenen starten, so könnte er direkt den entsprechend Payload zu Ausführung an die Clients schicken ohne dabei die Kontrolle über allfällige weitere Aktionen zu verlieren. Er kontrolliert quasi ein flüchtiges Botnet auf Webbasis, dessen Knotenpunkte bei entsprechend gut besuchten, infizierten Seiten in relativ rascher Folge rotieren.

Es werde Licht

Wie vorher beschrieben, steht dem Angreifer zu diesem Zeitpunkt ein Pool von Maschinen zur Verfügung, die z.B. eine gewisse Anfrage auf Befehl ausführen können. Er kann beliebige Daten mittels GET und POST an beliebige Orte senden. Nur das Problem ist: Er sieht die Antworten nicht. Das Problem hierbei ist die sogenannte same-origin Policy. Ein Beispiel: Lädt die Seite http://www.scip.ch/load.html die Seite http://banking.whiterabbitcircle.org/ in einem iframe, so wird diese zwar in die Seite auf www.scip.ch eingebunden, allerdings kann diese nicht lesend auf deren Inhalt zugreifen. Der Browser erkennt, dass es sich um eine andere Seite handelt und verwehrt den entsprechenden Zugriff. Würde die Seite http://www.scip.ch/load.html aber http://bank.scip.ch/ in sein iframe laden, so wäre ein Zugriff möglich – schliesslich handelt es sich ja um die selbe Domain. Er könnte entsprechend den kompletten DOM Tree auslesen und manipulieren.

SWARM enthält zu diesem Zweck einen kleinen Pseudo-Nameserver, der als Teil von SWARM-0 als Nameserver der entsprechenden Domain dient. Als Beispiel verwenden wir hier die Domäne swarmtest.local. Der Loader unter http://swarmtest.local/load/ kann theoretisch auf alle Ressourcen der Domäne swarmtest.local zugreifen. Nehmen wir nun als Beispiel einmal an, der Angreifer möchte die Seite www.ebay.ch aufrufen lassen und den Mitgliedernamen eines eingeloggten Mitgliedes an das Management Center zurücksenden, so wandelt SWARM die Adresse www.ebay.ch in www.ebay.ch.R.swarmtest.local um. Der Browser des Opfers kennt diese Adresse nicht und startet eine DNS Anfrage. Diese landet aufgrund der Domäne swarmtest.local bei unserem Pseudonameserver, der die gewünschte Domain oder IP-Adresse aus der Anfrage extrahiert, gegebenenfalls auflöst und zurückgibt. Der Browser des Opfers denkt nun, dass die IP-Adresse – die ja auf ebay.ch zeigt – zur Adresse www.ebay.ch.R.swarmtest.local gehört und gewährt dem Loader vollen Zugriff auf die entsprechenden Inhalte. Die Möglichkeiten, die sich dem Angreifer hier in Kombination mit geschicktem Scripting bieten sind fast unlimitiert: Zum Beispiel kann er automatisiert feststellen, welche der momentanen SWARM-Clients über eine aktive ebay-Session verfügen und automatisiert Gebote für von ihm definierte Auktionen abgeben oder die entsprechenden Passwörter verändern.

Diese Angriffsart, im allgemeinen DNS Rebinding genannt, ist übrigens nicht neu. Im Gegenteil, sie ist relativ alt: Sie wurde bereits im Februar 1997 vom Department of Computer Science der Princeton University im Dokument Secure Internet Programming: DNS Attack Scenario besprochen. Dabei wurde aufgezeigt, wie nicht vertrauenswürdige Java Applets eine Verbindung zu einem beliebigen Host aufbauen können. Heute, zehn Jahre später stehen uns neue Technologien zur Verfügung, die Lücke jedoch ist immer noch die selbe. Die Universität Stanford bewies indes 2007, dass es durchaus möglich ist mit Infrastruktur im Wert von lediglich 100$ über 100’000 IP Adressen temporär in einer Art zu nutzen, die der von SWARM ähnelt. Das grundlegende Design des Domain Name Systems lässt es kaum zu, diesem Problem entgegenzuwirken. Zumindest nicht, ohne gleichzeitig möglicherweise noch weit grössere Probleme damit zu verursachen. Zwar wurde mit dem sogenannten DNS Pinning eine Gegenmassnahme in Browsern implementiert, bedingt durch die heutige Verwendung einer Vielzahl von Plugins allerdings keinen wirklichen Schutz mehr bieten kann. Bedigt dadurch, dass die meisten Applikationen eigenständige Pin-Listen führen, bleiben derartige Angriffe dennoch problemlos möglich.

Interessant wird der Einsatz von DNS Rebinding dann, wenn man bedenkt dass der Angreifer im Prinzip stets mit den Augen des Opfers auf die aufzurufenden Seiten sieht. Der Browser des Opfers ruft die Seite auf und leitet ihm den Inhalt weiter. Das heisst auch, dass er unabhängig allfälliger Firewalls Zugriff auf die lokalen Netzwerkressourcen des Opfers hat. Oder – im Falle eines aktiven SWARM-Netzes – auf alle lokalen Netzwerkressourcen aller aktiven Clients. Somit steht es einem Angreifer theoretisch offen, zum Beispiel einen Portscan des lokalen Netzwerkbereiches vorzunehmen und interessante Ressourcen wie z.B. Netzwerkgeräte (Router, Switches, Access Points) mit Standardcredentials an das zentrale Management zu melden. Damit steht es dem Angreifer theoretisch offen, seinen Zugang zu einem einzelnen Netzwerk auszuweiten und so mehr Kontrolle zu erlangen.

Gut oder Böse?

SWARM ist mehr ein Proof of Concept als eine produktive Applikation. Defakto wird sie nie öffentlich erhältlich, geschweige denn käuflich zu erwerben sein. Im Gegenteil: SWARM soll zu eigenen Gedankenspielen anregen und das Bewusstsein und auch das Verständnis für teils als banal geltende, teils designbedingte Schwachstellen in der aktuellen Implementation von Webbrowsern fördern. Somit wäre es wohl sinnlos, SWARM überhaupt als gut oder böse taxieren zu wollen. Letzten Endes bleibt es ein Werkzeug, dessen Zweck von dem bestimmt wird, der es führt. Fakt ist aber, dass ähnliche Produkte bereits heute von Spammern und ähnlichem Klientel aktiv genutzt wird – Grund genug für die gute Seite, sich intensiver mit solchen Mechanismen zu beschäftigten.

Zusammenfassung

SWARM ist eine zentralisiert funktionierende Steuerzentrale, die mittels Javascript und/oder Flash eine Vielzahl von Clients in Form regulären bis zu einem gewissen Mass fernsteuern kann. Durch den Einsatz verschiedener Techniken (u.A. DNS Rebinding) kann der Angreifer damit lesend und schreibend auf alle Ressourcen zugreifen, die dem Webbrowser des jeweiligen Opfers zugänglich sind. Dies umschliesst interne/externe Netzwerkressourcen sowie beliebige Webseiten. SWARM befindet sich derzeit noch in Entwicklung und ist nicht öffentlich verfügbar. Eine Veröffentlichung der Applikation ist nicht geplant, das zur Verfügung stellen der technischen Dokumentation ist dagegen vorgesehen.

Über den Autor

Stefan Friedli gehört zu den bekannten Gesichtern der Infosec Community. Als Referent an internationalen Konferenzen, Mitbegründer des Penetration Testing Execution Standard (PTES) und Vorstandsmitglied des Schweizer DEFCON Group Chapters trägt er aktiv zum Fortschritt des Segmentes bei.