State of the art: Sandboxing

Transkript

1 State of the art: Sandboxing Artur Sterz Philipps-Universität Marburg, Deutschland Fachbereich Mathematik und Informatik, Arbeitsgruppe Verteilte Systeme Abstract Die Sicherheit der eigenen, persönlichen Daten ist in Zeiten steigender Internetnutzung immer wichtiger. Eine Technik, sich vor schadhafter Software zu schützen oder Software auf ihre Wirkung zu analysieren, bevor sie Schaden anrichten kann, ist die Sandbox. Welche Vorteile und Nachteile sie hat und ihre Einsatzmöglichkeiten werden in dieser Arbeit vorgestellt und diskutiert. Programm/ Prozess I. EINLEITUNG Jeder kennt folgendes Szenario: man erhält eine mit einer Datei von einer Quelle, bei der man nicht sicher ist, ob man ihr vertrauen kann. Was macht man in dieser Situation? Ignorieren? Aber vielleicht ist etwas wichtiges in dieser Datei. Man könnte auch auf die Firewall und das Anti-Virus-Programm vertrauen. Eine weitere Methode ist auch, die Datei mit einem Programm zu öffnen, dass sich in einer Umgebubung befindet, die strengen Sicherheitsmechanismen unterliegt und nicht auf Recoursen außerhalb dieser Umgebung zugreifen kann. Tatsächlich ist das eine gängige Methode, um sich vor Schadsoftware zu schützen. Diese Techniken reichen vom Einschränken der Nutzungsrechte bis Programm/ hin zur totalen Virtualisierung des Betriebssystem. Beide Techniken Prozess werden unter dem Begriff Sandboxing zusammengefasst. Im Unterschied zur virtuellen Maschine wird ein Programm beziehungsweise ein Prozess in der Sandbox nativ auf dem Host-Betriebssystem ausgeführt. Die virtuelle Maschine hingegen simuliert ein vollständig eigenes Betriebssystem, uneingeschränkter dass alle Ressourcen und Libraries zur Verfügung stellt, aberzugriff dennoch vom Host-Betriebssystem getrennt ist. Alle Zu Beginn Alle Daten soll die Frage geklärt werden, Systemresso was eine Sandbox überhaupt ist. Für Sandboxes gibt es je nach urcen Ebene mehrere Definitionen. Eine mögliche ist folgende: Eine Sandbox ist eine ohne Umgebung, Sanbox in der alle Aktionen eines Prozesses Sicherheitsmaßnahmen unterliegen. [1] Das bedeutet also, dass Programme, bei denen man nicht genau weiß, wie sie arbeiten (zum Beispiel beim Testen von neuer Software) oder denen man nicht vertraut (unverlässliche Internetquellen) in ihren Zugriffsrechten beschränkt werden, damit diese nicht auf beliebige Daten zugreifen können, um Schaden anzurichten. Alle Daten Alle Daten uneingeschränkter Zugriff Benötigte Daten ohne Sandbox ohne Sanbox Programm /Prozess uneingeschränkter Zugriff kein Zugriff mit Sandbox mit Sanbox Benötigte Systemre ssourcen Alle Systemresso urcen Alle Systemresso urcen Abbildung 1. Allgemeine Sandboxindidee II. VERSCHIEDENE EINSATZMÖGLICHKEITEN Sandboxes können unterschiedlich eingesetzt werden. Zum einen können sie dazu genutzt werden, um sich selbst beziehungsweise den Computer vor Schaden zu bewahren, indem man zum Beispiel seinen Browser in einer Sandbox einbettet

2 und wie üblich im Internet surft. Zum anderen kann man Sandboxes auch gezielt dazu einsetzen, um eventuell Schadhafte Software zu analysieren. A. Schutz Generell gibt es bei Sandboxes auf Softwareebene verschieden Möglichkeiten der Implementierung. Zum Beispiel kann ein Programm nur teilweise in eine Sandbox eingebettet sein, um besonders kritische Prozesse und Abläufe zu kapseln, da der Rest des Programms oder der Prozesse des gesandboxten Programms keinerlei Bedrohung für das System oder die Daten des Nutzers darstellen. Ein Beispiel dafür ist Googles Browser Chrome. Allgemein gilt bei Browsern, dass die größten Schwachstellen innerhalb der Rendering-Enginge zu finden sind. Deshalb wird diese bei Chrome in eine Sandbox gebettet, um die Schwächen der Engine auszugleichen. Abbildung 3. Sandboxing mit Hilfe von Sandboxie [3] Sandbox Rendering Engine HTML, JavaScript, etc. gerenderte Bitmap Chrome Kernel Abbildung 2. Sandboxing der Rendering Engine [2] Dabei werden Schreibzugriffe auf Bereiche, die nicht für den eigentlichen Rendering Prozess erforderlich sind, unterbunden. Lesezugriffe sind weiterhin erlaubt. Problematisch hingegen bleiben Systemfunktionen, die nicht in der Sandbox sind und von innerhalb der Sandbox aufgerufen werden, da diese unter Umständen Ereignisse auslösen können, die es ermöglicht, Rechte zu bekommen, die einem Aufgrund der Sandbox verwehrt bleiben sollten. Dies geschah zum Beispiel im Jahr 2010 bei Microsofts Internet Explorer, der im Protection Mode ebenfalls den Renderprozess in einer Sandbox ausführt. [2] Dabei gelang es den Angreifern mit Hilfe von Calls zu Kernel-Mode-Treibern aus der Sandbox auszubrechen. Eine andere Möglichkeit ist, ein Programm komplett in eine Sandbox einzubetten. Hier kann man das unter Windows populäre Programm Sandboxie [3] nennen. Führt man ein Programm in Sandboxie aus, werden alle Schreibzugriffe, die dieses Programm ausführt, auf einen bestimmten Ordner umgeleitet. Dadurch bleibt das eigentliche System unverändert. Ähnliches geschieht auch mit lesenden Zugriffen. Existiert die Datei bereits im Sandboxie-Ordner, wird von dieser gelesen. Nur im Fall, dass diese Datei noch nicht existiert, benutzt Sandboxie die Originaldatei. Um sich vor Spähprogrammen zu schützen, kann man Bereiche definieren, die unter keinen Umständen gelesen werden dürfen. Beim Schließen von Sandboxie werden alle angelegten Daten gelöscht. Der Nutzer hat jedoch die Möglichkeit diese Daten vor dem Beenden von Sandboxie auf das eigentliche System zu übertragen. Dennoch bleibt ein Problem: Sandboxie schützt zwar davor, dass zum Beispiel trojanische Pferde auf Daten außerhalb der Sandbox zugreifen, die inneren Daten haben aber keinen Schutz. Nutzt man Sandboxie zum Beispiel für einen Browser, lädt man eventuell schützenswerte Daten aus dem Internet. Schafft es jedoch ein Trojaner in der selben Session in die Sandbox, kann dieser die vorher runtergeladenen Datein auslesen und auch ohne Probleme verändern. B. Softwareanalyse Wie oben bereits erwähnt, können Sandboxes auch zur Analyse von Software eingesetzt werden, um herauszufinden, ob und welche Schäden diese anrichtet. Ein Beispiel dafür ist das Programm Cuckoo [4], welches Windowssoftware auf Unix-Systemen (vor allem Linux) testet. Dabei nutzt man eine Virtuelle Maschine, welche ebenfalls eine Form der Sandbox darstellen. Die Funktionsweise von Cuckoo soll hier kurz erläutert werden. Der folgende Abschnitt basiert auf einem Vortrag der Cuckoo-Entwickler auf der SIGINT-Konferenz 2013 und der Cuckoo Hompage [5]. a) Installieren: 1) Cuckoo: Erst muss Cuckoo installiert werden. Dazu wird ein neuer Nutzer angelegt und das Cuckoopackage darin entpackt. Damit Cuckoo richtig funktioniert, muss es noch konfiguriert werden, das heißt, dass zum Beispiel die Virtuelle Maschine, die genutzt wird, eingestellt werden muss. 2) Virtuelle Maschine: Anschließden benötigt eine Virtuelle Maschine. Cuckoo unterstützt verschiedene VMs, zum Beispiel VirtualBox oder libvirt. Diese wird installiert, anschließend wird darin eine Windowsversion installiert.

3 Außerdem benötigt Cuckoo Python. Dieses muss ebendalls inerhalb der Virtuellen Maschine installiert werden. Damit die VM und der Host miteinander kommunizieren können, nutzt Cuckoo einen gemeinsamen Ordner und das Netzwerk, welches auf dem Gast eingerichtet werden muss. Nun muss Cuckoo auch auf dem Gastbetriebssystem installiert werden. Zum Schluss wird ein Snapshot der Virtuellen Maschine erstellt und diese pausiert. b) Analysieren: Nachdem alles installiert und eingerichtet ist, kann potenzielle Schadsoftware analysiert werden. Dazu startet man Cuckoo im eigenen Rootverzeichnis. Alle Dateien, die sich ebenfalls in diesem Verzeichnis befinden, werden an das Gastbetriebssystem gesendet. Um die Analyse nun zu startet, muss spezifiziert werden, welche Art von Software analysiert werden soll. Man kann zum Beispiel sagen, dass.dll- oder.exe-dateien analysiert werden sollen. Nun beginnt Cuckoo mit der Analyse. Dabei wird die angegeben Software inerhalb der Virtuellen Maschien gestartet und versucht, möglichst viele Anwendungsfälle abzudecken. Es werden zum Beispiel auch Maus- und Tastatureingaben simuliert oder Internetverbindungen aufgebaut. Allerdings kann der Anwender auch eigenes Verhalten definieren, das getestet und simuliert wird. c) Resultate: Alles, was die potenzielle Schadsoftware auf dem Gastbetriebssystem tut, wird in logfiles gespeichert. Netzwerkverkehr, Speichernutzung, angelegte, veränderte und gelöschte Daten und Screenshots werden gespeichert, die später vom Nutzer eingesehen und verarbeitet werden. d) Probleme: Damit hat man in vielen Fällen herausgefunden, ob die analysierte Software gefährlich ist oder nicht. Allerdings garantiert Cuckoo nicht, dass die analysierte Software tatsächlich harmlos ist. Zum Beispiel kann es sein, dass das Programm nur dan Schaden anrichtet, wenn es von einem bestimmten Event angetriggert wird, das während der Analyse nicht eintritt. Außerdem gibt es Schadsoftware, die gegen Analyseprogramme wie Cuckoo gesichert sind, indem sie bemerken, dass sie grade analysiert werden und ihr schädliches Verhalten dann nicht ausführen. III. BEISPIEL EINER SANDBOX In diesem Abschnitt wird ein Beispiel zu einer Sandbox gezeigt. Es handelt sich dabei um SafeJS [6], eine Möglichkeit, JavaScript in einer Sandbox auszuführen. Hier muss erwähnt werden, dass SafeJS vom Entwickler einer Webseite in den Quellcode implementiert werden muss und nicht vom Nutzer installiert werden kann. A. Probleme von JavaScript JavaScript hat oft mit Sicherheitslücken zu kämpfen. Ein Beispiel ist der Cross-Site Angriff. Bei einem Cross-Site Angriff wird schadhafter Code (zum Beispiel JavaScript) in eine Website eingeschleust. Dies geschieht zum Beispiel durch Nutzereingaben, wie bei Suchfeldern. Wird diese Eingabe nicht überprüft, ist es möglich Code einzuschleusen. Wird in die Suche schadhafter JavaScript- Code eingegeben, würde dieser ausgeführt, wenn die Eingabe noch einmal ausgegeben werden würde. <p>sie suchten nach: Suchbegriff</p> Ist der Suchbegriff nun <script type="text/javascript">alert("xss ");</script> würde folgender HTML-Code erzeugt werden. <p>sie suchten nach: <script type="text/ javascript">alert("xss");</script></p> Verbirgt sich nun in dem Skript schadhafter Code, würde dieser ausgeführt werden. B. DOM und Worker Um das Beispiel zu verstehen, ist es wichtig das DOMund Worker-Prinzip zu kennen. Diese werden hier erklärt. 1) DOM: DOM ist eine Schnittstelle für HTML und XML Dokumente. Die Idee ist, dass HTML-Dokumente als Objekte repräsentiert werden, um damit in gewissem Sinne objektorientiert arbeiten zu können. Diese einzelnen Objekte können als Bäume dargestellt werden. Dabei werden vom W3C vier Ebenen definiert, die aufeinander aufbauen. 1) Ebene 0 wurde nie genau spezifiziert. Als Ebene 0 werden alle Techniken bezeichnet, die mittels JavaScript auf HTML und XML zugreifen können. 2) Ebene 1 bietet die Möglichkeit, Elemente zu einem DOM hinzuzufügen, zu ändern und zu löschen. Die Möglichkeiten beziehen sich auf die Knoten des Objekt-Baumes. 3) In Ebene 2 wurden die Möglichkeiten hinzugefügt, auf Mouseevents zu reagieren oder andere Teile einer Webseite zu bearbeiten, wie zum Beispiel CSS-Dateien. 4) Die höchste Ebene stellt Ebene 3 dar. Hier wurde zum Beispiel das Reagieren auf Tastatureingaben hinzugefügt. Außerdem wurde eine Möglichkeit zur Abstraktion hinzugefügt. 2) Worker: Worker sind eine Möglichkeit eine Art Threading für Skripte zu ermöglichen. Wird auf einer Website zum Beispiel eine lange JavaScript-Berechnung durchgeführt, müsste der Nutzer warten, bis diese fertig ist und könnte die Seite in dieser Zeit nicht nutzen. Durch einen Worker kann diese Berechnung im Hintergrund geschehen und der Nutzer kann die Seite weiter nutzen. C. SafeJS nutzen Auf den folgenden Seiten wird genau dargelegt, wie man SafeJS nutzt, um JavaScript sicher auszuführen. Als erstes muss SafeJS mit Hilfe von RequireJS eingebunden werden. <script type= text/javascript data-main= "safe" src= js/require.js />

4 Dabei wird durch data-main RequireJS angewiesen, SafeJS zu laden. Als nächstes muss das unsichere Skript geladen und ausgeführt werden. <script type= text/safe-javascript src= js/spy.js node= #unsafediv policy= read-write /> Durch den type-parameter wird der Browser angewiesen, das Skript js/spy.js nicht im main-worker auszuführen. Im node-parameter wird der Bereich des DOM angegeben, auf das das Skript zugreifen will. Für das gesandboxte Skript ist anschließend nur diese eine Node sichtbar. Der letzte Parameter zeigt an, welche Rechte das Skript hat. In diesem Fall darf es lesen und schreiben. Schließlich muss die Node, auf der das Skript arbeitet, durch das passende Div gekennzeichnet werden. In diesem Fall durch folgende Zeile: <div id="unsafediv"></div> D. Die einzelnen Schritte für SafeJS Web document 8. update Main JavaScript thread DOM SafeJS library 7. update if safe 1. create message queue 6. read message Worker SafeJS VDOM 5. write message Figure 1: High-level architecture of SafeJS Abbildung 4. Arbeitsweise von SafeJS [6] 2. create Unsafe script 4. update 3. load read from the SafeJS VDOM. The unsafe script can also update the SafeJS VDOM (step 4.). When this happens, the SafeJS VDOM writes a message to the message queue (step 5.). The SafeJS library then reads the message at the other end of the queue (step 6.). When SafeJS detects a forbidden update, SafeJS will eitherignorethe request or kill the worker and its malicious script; this choice depends on the SafeJS configuration. If the update is authorized, SafeJS performs the equivalent update on the real DOM (step 7.). The web browser finally updates the web page (step 8.). We now detail each step. 1) Worker: Sobald SafeJS geladen wird, wird ein neuer Worker erstellt, in dem das unsichere Skript ausgeführt wird. Dabei wird auch für jedes durch SafeJS geladene Skript ein eigener Worker erstellt. Zwischen dem Mainworker und dem von SafeJS erstellten Workern gibt es keine Kommunikation. Auch zwischen den einzelnen Workern selbst wird die Step 0. Initializing SafeJS Kommunikation beschränkt. The web developer must first load the SafeJS library through RequireJS: 4 <script type= text/javascript data-main="safe" src= js/require.js /> 2) virtuelle DOM: Die gekennzeichnete Node (im obigen Beispiel The data-main node= #unsafediv ) declaration instructs RequireJS towird load SafeJS. nunthekopiert, next step for the damit web developer is to pass each unsafe script to SafeJS: es keinerlei Zugriff auf echte Daten und Informationen gibt. <script type= text/safe-javascript src= js/spy.js node= #unsafediv policy= read-write /> 3) Laden: In diesem Schritt wird das unsichere Skript wie üblich geladen. This declaration instructs SafeJS to load the unsafe js/spy.js script. This script can be any JavaScript code compatible with client-side usage. The type parameter value must be set to text/safe-javascript: thispreventsthewebbrowserfromloadingthescript in the main thread and this indicates to SafeJS that the script mustbesandboxed.the node parameter indicates the HTML target node which will be made accessible from the unsafe script: in this case, the HTML node with the unsafediv id. This target node will become the only node visible from the spy.js unsafe script. The policy parameter indicatesthe kind of operationsthe unsafe scriptcan applyon the target node. A read-only policy only grants reading capabilities of the target node to theunsafescriptwhereas a read-write policy grants full privileges to this node. Finally, the web developer must include the HTML target node that the unsafe script will read and update: 4) Ausführen: Jetzt kann das Skript als normales JavaScript ausgeführt werden. Allerdings arbeitet dieses auf dem VDOM in einem seperaten Worker. Die Änderungen der Node haben also zu diesem Zeitpunkt keinen Einfluss auf die realen Daten oder den Mainworker. <div id="unsafediv"></div> 4 5) Schreiben: Damit die Änderungen, die das Skript macht auch in der richtigen DOM angewendet werden können, 3 müssen alle Änderungen in eine Queue geschrieben werden. 6) Überprüfen: Bevor die Änderungen jedoch auf das reale DOM angewendet werden, müssen diese verifiziert werden. Ist eine der ausgeführten Operationen nicht erlaubt, weil gegen Regeln verstoßen wurde, wird entweder der Worker komplett gestoppt oder die nicht erlaubte Operation wird ignoriert. 7) DOM ändern: Wurde eine Operation auf ihre Gültigkeit geprüft und wurden keine Regelverstöße festgestellt, wird diese Operation auf das reale DOM angewendet. Außerdem werden die Änderungen dann in das VDOM des Workers geupdated, damit das Skript so weiterarbeiten kann, wie es vom Entwickler implementiert wurde. 8) Dokument ändern: Wenn das reale DOM geändert wird, wird das Aktualisieren des Dokuments und der Website vom Browser erledigt. IV. ANGRIFFE AUF SANDBOXES UND WEITERE PROBLEME Sandboxes gelten im Allgemeinen als sicher. Ein Programm, das in einer Sandbox ist, kann nur begrenzten Schaden auf dem System anrichten. Dennoch gibt es Möglichkeiten, aus einer Sandbox auszubrechen. Dabei geht es in der Regel darum, Rechte zu bekommen, die ein Programm oder ein Prozess nicht hat. A. Nutzernachlässigkeit Beim Programmieren einer App für Googles Betriebssystem Android definiert der Entwickler, welche Rechte seine App benötigt. Diese Rechte werden der App jedoch nicht einfach eingeräumt. Bei der Installation der App wird erfragt, ob diese App die vom Entwickler geforderten Rechte haben darf. Abbildung 5. Android App Permissions [7] Hier ist auch der erste Angriff auf Sandboxes versteckt. Möchte man beispielsweise seine privaten Fotos schützen

5 und es vermeiden, dass diese im Internet landen, könnte ein Angreifer durch die Tatsache, dass viele Nutzer die Rechte gendankenlos an alle Programme geben, ausnutzen und so seinem Programm die Rechte geben auf die Fotos zuzugreifen und eine Internetverbindung herzustellen, obwohl das Programm diese garnicht benötigt, weil es zum Beispiel nur ein Taschenrechner ist. B. Privilege Escalation Eine weitere Möglichkeit ist die Privilege Escalation. Dabei wird versucht, einem Programm oder Prozess Rechte zu geben, die es eigentlich nicht haben darf. Dafür wird nicht die Nachlässigkeit des Nutzer ausgenutzt, sondern Bugs innerhalb der Sandboximplementierung. Dabei werden zwei Varianten unterschieden: i) Vertikal: Es werden einem Programm oder Prozess höhere Rechte (zum Beispiel Administrator- oder Root- Rechte) gegeben ii) Horizontal: Hier werden einem Programm oder Prozess Rechte eines anderen Nutzers oder einer anderen Nutzergruppe gegeben. Ein bekanntes Beispiel ist der Jailbreak, der in der ios- Community großen Anklang findet. Apple hat viele Einschränkungen und Restriktionen vorgenommen, um das System und den Nutzer vor Angriffen zu schützen. Durch den Jailbreak bekommt der Nutzer jedoch Root-Rechte und kann auf alle Funktionen des System zugreifen. Als folge dieses Jailbreaks kann unter Umständen auch die Sandbox umgangen werden, sodass Apps sowohl höhere Rechte (vertikal) als auch Rechte anderer Apps (horizontal) nutzen können. C. Permission Re-Delegation Ebenfalls eine beliebte Methode ist die Permission Re- Delegation. Dabei werden Schwachstellen von Programmen ausgenutzt. Die Implementierung der Sandbox wird jedoch nicht direkt angegriffen. Diese Attacke setzt jedoch eine Privilege Escalation voraus. Manche Programme haben viele oder tiefgreifende Rechte. Zum Beispiel hat ein Browser Rechte, eine Internetverbindung aufzubauen und zu nutzen. Andere Programme haben diese unter Umständen nicht. Ist eine Sandbox zum Beispiel gut gegen vertikale Privilege Escalation geschützt, kann man versuchen eine horizontale Privilege Escalation zu erreichen, um dem Schadprogramm transitiv die Internetrechte des Browsers zu geben. D. Weitere Probleme Außerdem haben Sandboxes oft mit weiteren Problemen zu kämpfen. 1) Overhead: Ein großes Problem ist der Overhead, der bei einer Implementierung entsteht. i Der Overhead, der zur Laufzeit entsteht hängt stark von der Implementierung ab. So muss zum Beispiel bei einer FreeBSD Jail erst eine vollkommen neue Umgebung erstellt werden, da diese zu Beginn leer ist. Bei Sandboxes auf Betriebssystemebene muss außerdem für jeden Prozess eine eigene Umgebung gestartet werden und jede Anfrage muss auf Sicherheitspolicies überprüft werden. Bei einfachen Anwendungen wird das kaum Einfluss auf die Performace haben, bei komplexen Systemen ist allerdings mit Performanceeinbußen zu rechnen. ii Der Overhead beim Programmieren ist jedoch unter Umständen größer als zur Laufzeit. Wie das SafeJS- Beispiel, das auf den folgenden Seite vorgestellt wird, zeigt, muss der Webentwickler zusätzliche Zeilen Code einfügen, damit die Sandbox korrekt funktioniert. Das Beispiel eines Angriffs, ebenfalls auf den folgenden Seite zu finden, zeigt, dass Fehler auch fatal sein können, da man sonst aus der Sandbox ausbrechen kann. 2) Kommunikation: Ebenfalls ein Problem ist die Kommunikation von a) Prozessen untereinander und b) verschiedenen Komponenten einzelner Prozesse. Hier gibt es zwei Möglichkeiten. i völlige Abschottung ii kontrollierte Kommunikation Als Beispiel für die Möglichkeiten kann man zum einen ios als Beispiel der Abschottung und Android als Beispiel der kontrollierten Kommunikation anbringen. Während unter Android Apps zum Beispiel mit Hilfe von sogenannten intents miteinander kommunizieren können, ist unter ios keinerlei Kommunikation möglich. Diese Kommunikation wie bei Android kann aber problematisch werden. V. BEISPIEL EINES ANGRIFFS In diesem Beispiel wird gezeigt, wie man aus der Sandbox in Googles Android ausbricht [8]. Dabei wird die oben erklärte Permission Re-Delegation ausgenutzt, um Rechte zu bekommen, die einem aufgrund der Sandbox im Normalfall verwehrt bleiben würden. Außerdem muss angemerkt werden, dass dieser Angriff aus dem Jahr 2010 ist und eine Schwachstelle von Android ausnutzt. Dabei muss ein App-Entwickler sicherstellen, dass niemand versucht, die Rechte, die sein Programm hat, nutzt. Die Permission Re-Delegation muss also vom App-Entwickler selbst verhindert werden und wird nicht vom System blockiert. Hierbei handelt es sich um ein Implementierungsoverhead, wie oben beschrieben. Folgende Grafik verdeutlicht, wie eine App A auf eine App C transitiv über B zugreifen kann. App A hat keine Rechte, darf also nur auf Komponenten anderer Apps zugreifen, wenn diese keine Einschränkungen haben. Deshalb darf A auf das Objekt B zugreifen. Allerdings ist Objekt C durch die Policy p geschützt. Daher darf A nicht auf Objekt C zugreifen. App B hingegen hat das Recht, auf Objekte mit Policy p zuzugreifen. Daher wäre es transitiv möglich, dass App A auf Obkejt C zugreift, wenn der Entwickler der App B keine Maßnahmen getroffen hat, diesen Fall zu unterbinden.

6 Sandbox Sandbox Sandbox App A Rechte: keine Objekt A Darf zugreifen App B Rechte: p Objekt B Darf nicht zugreifen Darf zugreifen Abbildung 6. Permission Re-Delegation [8] App C Rechte: keine Objekt C geschützt durch Policy p Googles Designentscheidung App-Entwickler auf Rechte und Einschränkungen ihrer Apps achten zu lassen, wird als Fehler angesehen. Nicht jeder App-Entwickler ist Experte darin, Sicherheitsmaßnahmen zu implementieren. A. Voraussetzungen Um diesen Angriff erfolgreich anzuwenden, müssen einige Bedingungen erfüllt sein. Zum Einen darf das betroffene Gerät nicht gerooted 2 sein. Des Weiteren muss das Android Scriping Environment (ASE) 3 in der Version 2.0 gemeinsam mit einem Tcl Script Interpreter installiert sein. Die ASE erlaubt es Skriptsprachen unter Android auszuführen und wird oft von anderen Apps vorausgesetzt. Außerdem muss eine App installiert sein, die eine Buffer- Overflow-Vulnerability hat. B. Die Architektur von Android Android basiert auf einem Linux-Kernel, der lowlevel-dienste bereitstellt, wie zum Beispiel Speicher- und Prozessmanagement. Zusätzlich besteht Android aus einer Middleware-Ebene, die in C und C++ geschrieben wurde. Außerdem wird unter Android nicht die standard Java Virtuelle Maschine genutzt, sondern eine für mobile Systeme und die ARM-Architektur angepasste, die Dalvik Virtual Machine (DVM) genannt wird. Um die Kommunikation zwischen verschiedenen Komponenten zu ermöglichen, gibt es zusätzlich Module, die diese Kommunikation, die Inter-Component-Communication (ICC), ermöglichen. Da Android Apps in Java geschrieben werden, sind diese im Normalfall gegen Buffer-Overflows geschützt, da Java zum Beispiel über ein implizietes Bound-Checking verfügt. Eine Schwachstelle, aber gleichermaßen ein Vorteil von Android ist die Möglichkeit C- und C++-Code über das Java Native Interface einzubinden. Ein Vorteil ist es dann, wenn man es zum Beispiel aus 2 Das Äquivalent zum oben beschriebenen Jailbreak unter ios heißt unter Android Rooting. Wie der Name schon impliziert, bekommt der Nutzer dadurch Root-Rechte. 3 Performancegründen einbindet. Eine Schwachstelle hingegen ist es, da das oben genannte Bound-Checking von Java nicht mehr greift. Aus diesem Grund ist es möglich, dass Android-Apps über eine Buffer-Overflow-Vulnerability verfügen. C. Vorbereitungen 1) ASE: Um diesen Angriff auf Abbildung 6 zu übertragen, kann man annehmen, dass App C das Senden von Nachrichten (SMS) ist, App B ist das ASE und App A ist die App mit der Buffer-Overflow-Vulnerability. Das ASE hat viele Rechte. Zum Beispiel darf es Anrufe tätigen, auf Kontakte zugreifen, Bluetooth und Kamera anschalten und Nachrichten senden. Außerdem ist ASE als Client-Server-App realisiert. Während der Client das Frontend für den Anwender ist, werden die Skripte auf einem Server ausgeführt. Dafür benötigt die App, die ein Skript ausführen will, Internetrechte, damit die Verbindung zum Server zu Stande kommen kann. An dieser Stelle zeigt die Fehlentscheidung von Google, die App-Entwickler auf die Sicherheit achten zu lassen, ihre Wirkung. Wie oben beschrieben, müsste ASE überprüfen, ob die App, die zum Beispiel über ein Skript eine Nachricht senden will, überhaupt die Rechte hat eine Nachricht zu senden. Genau das tut ASE aber nicht. 2) Zusätzliche Techniken: Um diesen Angriff erfolgreich anzuwenden, wird hier, wie oben beschrieben, eine Buffer- Overflow-Vulnerability von App A ausgenutzt. Dazu benötigt man das häufig angewandte Return-Oriented Programming (ROP) ohne Returns. Im Normalfall wird das ROP durch sogenannte Canaries verhindert. Durch ROP ohne Returns kann dieser Mechanismus jedoch umgangen werden, da keine Returnadressen verwendet werden, um in den Schadcode zu springen, sondern Jumps. Angreifer 1. Kontrollstrukturen Jumpadresse Buffer Daten Bibliotheken (lib) Anweisungen sonstiger Code 2. Jump Abbildung 7. ROP without Returns [8] Trampolin Wie in Abbildung 9 zu sehen, startet der Angreifer eine Buffer- Overflow-Attacke (1.) und überschreibt eine Jump-Adresse (2.). Anstatt das Programm wie gewünscht auszuführen, wird eine andere Sequenz von Anweisungen ausgeführt (3.). Durch ein sogenanntes Trampolin kann der Angreifer so viele Befehle ausführen lassen, bis er einen gewünschten Zustand erreicht hat (4.).

7 D. Der Angriff 1) Angriffsumgebung: Der Angriff wurde zum Einen auf einem Android-Emulator mit Android 2.0 ausgeführt und zum Anderen auf einem Smartphone mit Android 1.6 Die präsentierte Version ist die auf dem Emulator gefahrene. 2) ROP: Die App, die unter einer Buffer-Overflow- Vulnerablility leidet ist eine normale Android-App, die in Java geschrieben wurde. Zusätzlich bindet diese App das JNI ein, um C- und C++- Libraries zu nutzen. Folgender Code ist Bestandteil der angreifbaren App: Update-Load-Branch ADDS r6, #4 LDR r5, [r6, #124] BLX r5 r6 sp Jumpadresse 3 Jumpadresse 2 Jumpadresse 1 Update-Load-Branch-Adresse expo system() ADDS r0, r4, #0 BLX r3 LDR r3, [sp, #0] BLX r struct foo { char buffer[460]; jmp_buf jb; }; 1. Angreifer rt A clsh jint Java_com_example_hellojni_HelloJni_doMapFile (JNIEnv* env, jobject thiz) { //... struct foo *f = malloc(sizeof *f); i = setjmp (f->jb); if (i!= 0) return 0; fgets (f->buffer, sb.st_size, sfile); longjmp (f->jb, 2); } In diesem Code sieht man, das es einen setjmp-fehler gibt. setjmp und longjmp sind Systemcalls, die nicht-lokale Kontrolltransfers erlauben. Hier erstellt setjmp eine Struktur, die einen Buffer jmp_buf beinhaltet. Wird setjmp aufgerufen, werden die Werte, die in den Registern r4 und r14 stehen, in jmp_buf gespeichert. An dieser Stelle ist der Angriff möglich. Schafft es der Angreifer jmp_buf zu ändern, bevor longjmp aufgerufen wird, kann er beliebigen Code ausführen lassen, ohne eine einzige Returnaddresse zu verletzen. Die Funktion fgets lädt Daten in die Struktur foo, die in einer Binary-Datei gespeichert sind, ohne darauf zu achten, ob über die Buffergrenze hinaus geschrieben wird. Wird nun eine Datei geladen, die größer als 460 Byte ist, wird der jmp_buf überschrieben. 3) Ausbrechen aus der Sandbox: Um den Angriff erfolgreich durchzuführen, muss erst die angreifbare App gestartet werden. Wenn der oben gezeigte Code durch das JNI aufgerufen wird, wird die setjmp-schwachstelle wie oben beschrieben exploited. Danach wird mit Hilfe des Buffer-Overflows der Tcl-Client mit einem Kommando aufgerufen, sodass das Gerät eine bestimmte Anzahl (in diesem Beispiel 50) SMS sendet. Konkret werden dafür die in Abbildung 8 gezeigten Befehlssequenzen genutzt: Erst wird das untensehende Kommando und die benötigten Jumpadressen in den Speicher geladen (1.). Als nächstes wird das Register r6 initialisiert, sodass es auf die erste RAM Abbildung 8. genutzte Befehle [8] Jumpadresse zeigt, welche anschließend ausgeführt wird. Für die Schritte 1 und 2 wird der ROP-Angriff genutzt. Als nächstes wird durch BLX r3 das Register r3 auf die Update-Load-Branch (ULB) Sequenz gesetzt (3.), welches dazu genutzt wird, um die nächste Befehlssequenz (4.) auszuführen. Nachdem Sequenz 2 fertig ist, wird r3 wieder auf die ULB Sequenz gesetzt (5.). Als letzter Schritt (6.) wird die Sequenz 3 ausgeführt, welche die libc Systemfunktion aufruft. Es wird eine Verbindung zum Tcl Server hergestellt und das Kommando wird nun im Auftrag der angreifbaren App ausgeführt. Der Tcl Server überprüft an dieser Stelle nicht, ob die App, die ein Kommando ausführen lassen will, die Rechte hat dieses Kommando auszuführen. Abbildung 9 zeigt dieses Vorgehen, bei dem 1. die ROP- Attacke genutzt wird, um dann 2. dem Tcl Client das Kommando zu Senden, damit die SMS gesendet werden. Bei 3. wird die Verbindung zum Tcl Server hergestellt, welcher dann 4. die SMS versendet. ROP-Angiff 1. Sandbox Angreifbare App C-Code 2. Tcl-Client 3. Sandbox ASE Tcl-Server Abbildung 9. Konkreter Angriff [8] SMS 4.

8 Die ROP-Attacke ist also primär dazu da, um eine Tcl-Shell zu öffnen. Dazu wird eine standard libc Systemfunktion genutzt, die das Binary tclsh ausführt. Das Kommando, welches den Tcl-Server dazu auffordert die SMS zu verschicken, setzt sich aus zwei einzelnen Kommandos zusammen. Im ersten Teil wird die AP PORT Variable gesetzt und im zweiten Teil wird der den Tcl- Interpreter dazu auffordert, die SMS zu versenden. Das gesamte Kommando sieht folgendermaßen aus: export AP_PORT= ; echo -e package require android \n set android [ android new]\n set num "\ 5556\ " \n set message "Test" \n fpr {set x 0} { $x < 50} {incr x} {$android sendtextmessage $num $message} /data /data/com.google.ase/tclsh/tclsh Das zweite Kommando, welches für das Senden der Nachrichten genutzt wird, setzt sich folgendermaßen zusammen. Erst wird die Nummer gesetzt, an die die Nachrichten gesendet werden sollen. In diesem Fall Als nächstes wird der Inhalt der Nachrichten gesetzt. Bei diesem Angriff wird also 50 mal Test an 5556 gesendet. Um auch 50 Nachrichten zu senden und nicht nur eine, wird erst eine Variable x auf 0 gesetzt und dann so lange um 1 erhöht, bis 50 Nachrichten versandt wurden. VI. FAZIT Erst habe ich vorgestellt, welche Möglichkeiten es gibt Sandboxes zu verwenden. Die erste dient dem Schutz während der Ausführung eines Prgrammes oder eines Prozesses. Die zweite wiederrum ist dazu da Software auf ihr Verhalten zu analysieren, um Schadsoftware zu entdecken. Außerdem habe ich eine Beispielhafte Sandbox gezeigt, die es ermöglicht JavaScript in einer sicheren Umgebung auszuführen. Dazu habe ich erst Probleme von JavaScript genannt. Anschließend habe ich die Konzepte DOM und Worker vorgestellt, auf denen SafeJS basiert. Zum Schluss habe ich schrittweise erklärt, wie SafeJS genutzt wird. Dazu muss erst ein Worker und ein virtuelles DOM erstellt werden, auf dem das geladene, unter Umständen schadhafte Skript, ausgeführt wird. Die Änderungen, die auf dem virtuellen DOM gemacht wurden, werden schließlich noch auf den realen DOM angewendet. Laufzeit. Als letztes habe ich einen beispielhaften Angriff auf eine Sandbox, konkret die Android-Sandbox, gezeigt. Dabei habe ich erst die Konzepte vorgestellt, die für diesen Angriff notwendig sind. Anschließend habe ich die Voraussetzungen für diesen Angriff vorgestellt. Danach bin ich kurz auf die Architektur von Android eingegangen, um dann ASE und weitere Techniken vorzustellen. Zum Schluss habe ich den konkreten Angriff gezeigt, bei dem erst ein problematischer Code gezeigt wurde. Durch das vorgestellte ROP konnte ein Buffer-Overflow provoziert werden, wodurch letztendlich die Sandbox verlassen werden konnte. Ein Shellbefehl genügte letztendlich, um ohne die Erlaubnis des Nutzers 50 SMS zu versenden. Zusammenfassend kann ich sagen, dass das Sandboxing eine sehr mächtige Möglichkeit ist, um Angreifer, Viren, Würmer und sonstige schadhafte Software davon abzuhalten, Schaden auf dem eigenen PC anzurichten. Das Sandboxing kann diese Software jedoch nicht vom PC fernhalten. Es ist keine Technik, die verhindert, dass sich diese Software auf dem Rechner einnistet. Lediglich der Schaden, den diese Software anrichtet, bleibt innerhalb der Sandbox und hat selten Einfluss auf Nutzerdaten. Letztendlich muss ich festhalten, dass Sandboxes kein Allheilmittel sind. Wie oben zu sehen ist, gibt es Möglichkeiten aus einer Sandbox auszubrechen. Egal, ob der Nutzer hintergangen wird oder Bugs innerhalb der Implementierung genutzt werden. Schafft es ein Angreifer aus der Sandbox zu entkommen, kann er den gleichen Schaden anrichten, wie ohne Sandbox. QUELLEN [1] Matt Bishop, Computer Security: Art and Science, Addison-Wesley, p. 444, [2] Chris Greamo, Anup Ghosh, Sandboxing and Virtualization: Modern Tools for Combating Malware, Security & Privacy, IEEE, vol. 9, no. 2, pp , [3] [4] [5] [6] Damien Cassou, Stephane Ducasse, Nicolas Petton, SafeJS: Hermetic Sandboxing for JavaScript, Acces Online via dblp.org, [7] /permissions.jpg, [8] Lucas Davi, Alexandra Dmitrienko, Ahmad-Reza Sadeghi, Marcel Winandy, Privilege Escalation Attacks on Android, Acces Online via dblp.org, Danach habe ich einige Angriffe auf Sandboxes vorgestellt, wie die Privilege Escalation oder Permission Re-Delegating, die jeweils Bugs in Implementierungen ausnutzen. Ich habe aber auch gezeigt, dass man in machen Fällen auch an Rechte kommt, indem man darauf vertraut, dass Nutzer nachlässig sind und jeder App einfach alle Rechte geben, die sie verlangt. Auch weitere Probleme von Sandboxes habe ich vorgestellt, wie der Overhead beim Programmieren oder zur