Mobile-Sandbox: Ein Analyse-Framework für Android Applikationen

Transkript

1 Mobile-Sandbox: Ein Analyse-Framework für Android Applikationen Michael Spreitzenbarth 1, Johannes Hoffmann 2, Hanno Lemoine 3, Thomas Schreck 4, Florian Echtler 5 Kurzfassung: Da sich Mobiltelefone immer größerer Beliebtheit erfreuen, rücken sie auch immer weiter in den Fokus von Kriminellen. Waren vor ein bis zwei Jahren nur einige hundert bösartige Applikationen in der freien Wildbahn verbreitet, sind es heutzutage mehr als Applikationen und es kommen monatlich mehr als neue Applikationen hinzu [13]. Dies macht es notwendig, dass die Anzahl und vor Allem die Qualität der Analysetools gesteigert werden sollte. Dabei sollte der Fokus auf automatisierbaren Tools liegen, damit die rasant ansteigende Zahl an neuer Schadsoftware überhaupt bewältigt werden kann. In diesem Artikel wird ein Analyse-Framework für Android vorgestellt, das verschiedene statische und dynamische Analysen übersichtlich über ein Webinterface unter zur Verfügung stellt. Folgende Punkte zeichnen dieses System aus: (1) Ein gutes Zusammenspiel aus statischer und dynamischer Analyse; (2) eine dynamische Analyse, die auf der am weitest verbreiteten Version von Android aufsetzt und (3) native Bibliotheken überwachen kann; (4) ein statisches Program Slicing, welches Konstanten aus Funktionsaufrufen auslesen kann, sowie (5) die Entdeckung von über- und unterprivilegierten Applikationen. Zusätzlich wird ein alternativer Ansatz für die dynamische Analyse vorgestellt. Darüber hinaus wurde bei der Evaluation von über Applikationen aus diversen asiatischen und russischen Drittmärkten sowie aus dem offiziellen Google-Play Store zwei schädliche Applikationen entdeckt, die zum Zeitpunkt der Entdeckung durch die Mobile- Sandbox noch von keinem Antivirenscanner erkannt wurden. Stichworte: Android, Mobile, Malware, statische und dynamische Analyse, Program Slicing, statische Instrumentierung 1. Einführung In den vergangenen Jahren ist die Anzahl an verkauften Mobiltelefonen stark gestiegen. Dieses Wachstum hat auch die Aufmerksamkeit von Kriminellen erregt, die versuchen, den Nutzer dazu zu bringen, schädliche Software auf ihrem Gerät zu installieren. Google s Smartphone Plattform Android ist das beliebteste Betriebssystem und hat kürzlich Symbian und ios-basierte Geräte überholt. Höchst wahrscheinlich ist dieses Wachstum der Offenheit der Plattform geschuldet, die es Nutzern erlaubt, zusätzliche Software zu installieren. Gleichzeitig nutzen Angreifer jedoch diese Offenheit aus, um schädliche Applikationen über so genannte App Stores zu verteilen. 1 Friedrich-Alexander-Universität Erlangen-Nürnberg; michael.spreitzenbarth@cs.fau.de 2 Ruhr-Universität Bochum; johannes.hoffmann@rub.de 3 G Data Software AG Bochum; hanno.lemoine@gdata.de 4 SIEMENS CERT München; t.schreck@siemens.com 5 SIEMENS CERT München; florian.echtler@siemens.com 13. Deutscher IT-Sicherheitskongress des BSI 1

2 Im Rahmen vergangener Projekte [25, 26] wurden etwa schädliche Apps analysiert und in 115 Malware Familien zusammengefasst. Für diese Klassifizierung wurde die VirusTotal API [16] verwendet. Rund 60% der analysierten Malware Familien haben versucht, persönliche Informationen wie Adressbucheinträge, die IMEI oder GPS-Koordinaten zu stehlen. Zusätzlich wurden bei 30% SMS Nachrichten an Premiumnummern versendet, um als Autor direkt Einkünfte zu generieren. Die letzte charakteristische Schadfunktion, die bei 24% aller Apps gefunden wurde, war die Fähigkeit, sich mit einem Server im Internet zu verbinden, um Kommandos zu erhalten und auszuführen. Mit Hilfe dieser Technik wird es dann einfach möglich, ein mobiles Botnetz zu konstruieren. Ein sehr detaillierter Überblick aller existierenden Malware Familien ist ebenfalls von Zhou et al. [32] verfügbar. Um dieser bedenklichen Entwicklung entgegenzuwirken ist es nötig, Analysesysteme zu schaffen, die frühzeitig schadhafte Applikationen erkennen und so deren Verbreitung eindämmen. Aus diesem Grund wurde im Rahmen des vom BMBF geförderten Forschungsprojektes MobWorm unter Führung der Universität Erlangen-Nürnberg die Mobile-Sandbox entwickelt, deren verschiedene Komponenten in diesem Beitrag vorgestellt werden. 2. Architektur der Mobile-Sandbox Um festzustellen, ob eine Applikation gut- oder bösartig ist, muss diese mit großem Aufwand analysiert werden. Bei einer solchen Analyse müssen alle Attribute und Funktionsweisen dokumentiert werden. Innerhalb der folgenden Abschnitte werden die einzelnen Komponenten der Mobile-Sandbox vorgestellt und der Funktionsumfang beschrieben. Die automatisierte Analyse besteht aktuell aus drei Hauptteilen: statische und dynamische Analyse sowie Program Slicing, eine spezielle Art der Datenflussanalyse. Besonders ist hierbei, dass die Ergebnisse der statischen Analyse verwendet werden, um bestimmte Ereignisse oder Benutzerinteraktionen in der dynamischen Analyse auszulösen. Hierbei wird die Applikation automatisiert in einem modifizierten Android System installiert und ausgeführt. Während der Laufzeit der Applikation werden dann die Ergebnisse von vorherigen Analysen verwendet, um mit möglichst vielen Bereichen der Applikation zu interagieren. Die Ergebnisse aller Analysen werden dem Benutzer im Anschluss in der Weboberfläche der Mobile-Sandbox angezeigt (siehe Abbildung 1). Abbildung 1: Ansicht einer analysierten Applikation im Webinterface der Mobile- Sandbox mit Verweis auf alle verfügbaren Berichte der einzelnen Komponenten Deutscher IT-Sicherheitskongress des BSI

3 2.1 Statische Analyse mit Hilfe des Droidlyzer Die implementierte statische Analyse besteht aus mehreren Modulen. Um einen ersten Eindruck zu erhalten, ob es sich bei der zu analysierenden Applikation um eine bekannte bösartige Anwendung handelt, wird deren Hash-Wert berechnet und mit der VirusTotal-Datenbank [16] verglichen. Die dabei resultierende Erkennungsrate wird für den Bericht gespeichert, allerdings während der weiteren Analyse nicht weiter verwendet. Im Anschluss daran werden alle Komponenten der Applikation entpackt und das Android-Manifest nach benötigten Berechtigungen und Intents durchsucht. Um diesen Schritt durchführen zu können, wird das Werkzeug aapt aus dem Android SDK [14] verwendet. Des Weiteren wird auch die SDK-Version der Applikation ausgelesen um sicherzustellen, dass sie während der dynamischen Analyse in einer konformen Umgebung ausgeführt wird. Im darauf folgenden Schritt wird der Dalvik-Bytecode in Smali-Code [12] umgewandelt indem die Datei classes.dex dekompiliert wird. Während dieses Schritts werden alle Dateien der integrierten Werbenetzwerke extrahiert und aus der eigentlichen Analyse ausgeklammert. Dies geschieht um sicherzustellen, dass die Analyse der eigentlichen Applikation nicht durch aggressive Werbenetzwerke, die z.b. Benutzerdaten oder Identifikationsnummern des Telefons an ihre Betreiber versenden, verfälscht wird. Darauf folgend wird der komplette Smali-Code nach potentiell gefährlichen Funktionen und Methoden durchsucht. Hierbei wird speziell auf Funktionsaufrufe geachtet, die vermehrt in bösartigen Applikationen verwendet werden. Dazu zählen zum Beispiel: sendtextmessage(): Mit Hilfe dieses Aufrufs werden SMS-Nachrichten versendet. getpackageinfo(): Hiermit sucht Malware häufig nach bereits installierten Applikationen (z.b. AV-Produkte). getsimcountryiso(): Dieser Aufruf liefert die Landeskennung der eingelegten SIM-Karte. Hierdurch kann der Autor der Malware sicherstellen, dass seine Applikation nur in bestimmten Ländern das gewünschte Verhalten ausführt. java/lang/runtime;->exec(): Dieser Funktionsaufruf führt den übergebenen Befehl in einem eigenständigen Prozess aus. Im Falle von Malware sind das häufig die Befehle su oder chmod. Des Weiteren wird nach Aufrufen von bekannten Kryptographie-Bibliotheken wie AES oder Base64 gesucht, um Verschleierung durch Verschlüsselung zu erkennen. Eine zuverlässige Malwareerkennung lässt sich hiermit nicht realisieren, da es sowohl schädliche als auch berechtigte Verwendung der gesuchten Funktionsaufrufen gibt. Die statische Analyse liefert dem Analysten aber entscheidende Hinweise auf die kritischen Stellen für eine spätere manuelle Analyse. Zusätzlich wird bei jeder gefundene Methode verglichen, ob hierfür eine Berechtigung notwendig ist. So kann am Ende der Analyse auch Auskunft darüber erteilt werden, ob die Applikation unter- oder überprivilegiert ist. Hierzu wird ein Vorgehen verwendet, dass von Felt et al. [10] bekannt ist. 13. Deutscher IT-Sicherheitskongress des BSI 3

4 Im Anschluss daran wird versucht statisch implementierte URLs und IP-Adressen zu extrahieren. Um die dynamische Analyse aus Abschnitt 2.3 zu steuern und somit möglichst viele Aktionen der Applikation auszulösen, werden zusätzlich Timer und Broadcasts herausgefiltert. Mit diesem Schritt wird sichergestellt, dass die Applikation im Analysesystem so lange läuft, bis alle Timer abgelaufen sind. Das Setzen von Timern ist eine beliebte Vorgehensweise, um bösartiges Verhalten zu verstecken [28]. Am Ende der statischen Analyse wird eine XML-Datei mit allen wichtigen Ergebnissen erzeugt und in der Weboberfläche bereitgestellt. 2.2 Statische Analyse mit Hilfe von SAAF Das Static Android Analysis Framework (SAAF) ist ein Tool zur statischen Analyse von Android Software und ermöglicht es, einem Analysten eine App besser zu verstehen. Das Tool bietet eine grafische Benutzeroberfläche, in der alle Operationen ausgeführt werden können sowie wichtige Informationen, wie der Smali-Code oder der Kontrollflussgraph, angezeigt werden können. Die Kernkomponente von SAAF stellt jedoch die Möglichkeit dar, eine spezielle Technik der Datenflussanalyse namens Program Slicing [1, 4, 11] auf die zu untersuchende App anzuwenden. Mit dieser Technik wird es dem Analysten ermöglicht, beispielsweise nach Konstanten in einem Programm zu suchen, welche als Telefonnummer oder Text für eine Kurznachricht verwendet werden. Somit können unter anderem Premiumnummern in Programmen gefunden werden. Diese Suche wird im Rahmen von SAAF als static backtracking bezeichnet. Des Weiteren bietet das Tool einen Konsolenmodus zur automatischen Analyse von mehreren Apps. Die gefundenen Ergebnisse werden anschließend in einer Datenbank abgespeichert und können so auch in anderen Analyseschritten benutzt werden. Die folgenden Ausführungen gehen näher auf die Technik des static backtracking ein eine detailliertere Beschreibung sowie Analyseergebnisse sind in einer Arbeit von Hoffmann et al. [17] zu finden. SAAF ist in Java geschrieben und kann online [24] bezogen werden. Die Analyseergebnisse werden von der Mobile-Sandbox ebenfalls zur Verfügung gestellt Statisches Backtracking Die Möglichkeit eine statische Datenflussanalyse durchzuführen stellt die Kernkomponente von SAAF dar. Sie ermöglicht einem Analysten zu entscheiden, welche Apps einer präziseren manuellen Analyse unterzogen werden sollten. Hierzu definiert dieser eine Methode und mit Hilfe des Program Slicing werden alle Konstanten in der App gesucht, welche als Parameter in die gewählte Methode übergeben werden können. Versendet eine Applikation beispielsweise Kurznachrichten mit Hilfe der sendtext- Message() Methode an eine fest kodierte Telefonnummer, so deutet dies auf eine ungewünschte bzw. bösartige Aktivität hin. Da manuelle Analysen jedoch sehr aufwändig sind, kann SAAF eine Vorsortierung von vielen Apps vornehmen Deutscher IT-Sicherheitskongress des BSI

5 Um die statische Analyse durchzuführen, muss die zu analysierende App zunächst entpackt werden und die einzelnen Programmteile ausgelesen werden. Dabei wird wie folgt vorgegangen: Der Analyst lädt die App (APK Datei). SAAF entpackt das APK und generiert mit Hilfe des apktools [30] Smali-Code aus dem Bytecode der App. Die Manifest-Datei sowie der Smali-Code werden anschließend analysiert und alle Klassen, Methoden, Felder usw. werden als spezielle Java-Objekte im Speicher vorgehalten. Nachdem diese Schritte durchgeführt sind, kann die eigentliche Analysephase beginnen sobald der Analyst Methoden und zugehörige Parameter definiert hat, zu welchen Konstanten gesucht werden sollen. Um Konstanten mit Hilfe der Kontrollflussanalyse zu finden, muss zunächst ein Startpunkt ausgewählt werden das sogenannte Slicing-Kriterium. In unserem Fall muss dieses Kriterium die folgenden Informationen enthalten: Den Methoden- und den vollen Klassennamen der entsprechenden Klasse, die Methodensignatur und den Index des Methodenparameters, welcher untersucht werden soll. Das Kriterium beschreibt exakt alle Befehle, welche die entsprechende Methode aufrufen und ermöglicht es, nach sogenannten use-def chains zu suchen: Zunächst werden alle im Programm enthaltenen Methodenaufrufe (invoke Anweisungen) gesucht und überprüft, ob sie die definierte Methode aufrufen. Nachdem alle relevanten Aufrufe bekannt sind, wird für all diese Aufrufe wie folgt vorgegangen. Es wird das Register r bestimmt, welches an der entsprechenden Codestelle als Parameter verwendet wird (use Information). Anschließend werden alle vorherigen Befehle in allen vorherigen Basisblöcken untersucht, ob sie mit r Operationen ausführen. Eine Kombination aus verschiedenen Techniken aus dem Bereich der Programmanalyse (sog. forward und backward slicing) ermöglicht es, alle Operationen wie Arrayzugriffe oder Erzeugungen zu analysieren. Die Suche ist beendet, wenn eine Konstante gefunden wurde (def Information) oder r von einer Objektreferenz überschrieben wird, für welches dann eine neue Suche gestartet wird (siehe Abschnitt 3.2). Allgemein gesprochen werden alle Operationen gesucht, welche den Wert von r verändern oder verwenden und diese Operationen werden ebenso nach demselben Prinzip analysiert, bis eine Konstante gefunden wird. Als Konstante bzw. Suchergebnis werden neben den offensichtlichen Konstanten wie Strings oder Integerwerten auch folgende Eigenschaften des Programms als solche gehandelt, wenn sie mit dem beobachteten Register r in Verbindung stehen: Felder und Arrays mit deren Typ, Namen, initialen und zugewiesenen Werten, falls diese in r kopiert werden. 13. Deutscher IT-Sicherheitskongress des BSI 5

6 Unbekannte (API) Methodenaufrufe wenn diese einen Wert bzw. ein Objekt zurückgeben, welcher nach r kopiert wird. Bekannte Methoden sind Teil der usedef chains und alle dort zurückgegebene Werte werden entsprechend analysiert. Operationen, die r mit Werten überschreiben, welche nicht direkt Teil des Programms sind, z.b. Exceptions. Alle gefundenen Suchergebnisse werden mit zusätzlichen Metainformationen wie Variablenname und -werte, Opcode sowie Zeilennummer in einer Datenbank persistent gespeichert. 2.3 Dynamische Analyse durch modifiziertes DroidBox und ltrace Während viele bösartige oder schädliche Verhaltensmuster schon bei einer statischen Analyse erkannt werden können, ist es bei weiter entwickelter Schadsoftware nötig, diese während der Laufzeit zu analysieren, um so ihr komplettes Verhalten zu erkennen. Dieser Schritt kann einen zusätzlichen Mehrwert bei der Klassifizierung in gutoder bösartig bringen, da hier erkannt wird, welche Daten vom System abfließen und welche nur intern verwendet werden Systemaufbau Um die dynamische Analyse einer Applikation vorzunehmen, wird bei der Mobile- Sandbox auf den Android Emulator [3] gesetzt. Diese Software simuliert ein vollwertiges ARMv7 Gerät mit allen wichtigen Hardware-Erweiterungen wie ein GSM Modul oder einen Touchscreen. Zudem gewährleistet der Emulator eine sichere Umgebung zum Ausführen von schadhaften Applikationen auf einem Hostcomputer. In Abbildung 2 wird gezeigt, welche Rolle der Emulator im gesamten Analyse- Framework spielt. Hier ist ebenfalls zu erkennen, wie die eingesetzten Module (die im Weiteren beschrieben werden) zusammenarbeiten und an welchen Punkten sie ansetzen. Da der von Google bereitgestellte Emulator nur eingeschränkte Logging-Funktionalität besitzt wird in dem hier beschriebenen Ansatz auf die bekannten Erweiterungen TaintDroid bzw. DroidBox [8, 20] als Basis der dynamischen Analyse zurückgegriffen. Während Taint- Droid Applikationen bis zu Version 4.1 des Android Betriebssystems unterstützt, werden von DroidBox nur die Versionen bis 2.1 abgedeckt. Um mit der Mobile-Sandbox Abbildung 2: Übersicht der einzelnen Komponenten der dynamischen Analyse Deutscher IT-Sicherheitskongress des BSI

7 den Großteil der Applikationen analysieren zu können, wurden die Funktionen von TaintDroid mit DroidBox verschmolzen und um weitere Module ergänzt Überwachung von nativen Code Die im vorherigen Absatz erwähnten Werkzeuge haben trotz aller Vorteile auch einen gravierenden Nachteil: Sie können keine Aufrufe von Methoden oder Funktionen aus nativem Code aufzeichnen. Seit es in Android möglich ist, wichtige Programmteile in native Bibliotheken auszulagern und per Java Native Interface (JNI) anzusprechen, ist es sehr einfach möglich, schadhafte Bestandteile dorthin auszulagern. Um diese Programmfragmente und die zugehörigen Aufrufe überwachen zu können, wird im hier vorgestellten Framework auf eine angepasste Variante von ltrace [6] gesetzt (siehe Abbildung 2). Dieses Werkzeug ist bekannt aus dem Bereich des Linux- Debugging und kann sich in Bibliotheksaufrufe einklinken und sie überwachen. Nachdem die Applikation im Emulator gestartet wurde, wird eine Instanz von ltrace an die Dalvik VM mit der laufenden Applikation angekoppelt. Durch diesen Schritt werden alle nativen Aufrufe einer dynamisch nachgeladenen Bibliothek und die übergebenen Werte in eine separate Log-Datei gesichert Netzwerkverkehr Als weiteres Log-Modul wird der komplette Netzwerkverkehr als PCAP-Datei aufgezeichnet. Dieses weit verbreitete Dateiformat kann in späteren Analysen mit Tools wie WireShark oder Derrick [29, 22] ausgewertet werden Zusammengefasster Ablauf Die Mobile-Sandbox generiert drei separate Log-Dateien mit allen Einzelheiten zum Verhalten der Applikation (siehe Abbildung 2): Die DroidBox Log-Datei enthält alle wichtigen Java Methodenaufrufe und Daten aus der Dalvik VM. Die ltrace Log-Datei enthält alle Aufrufe und Daten der nativen Komponenten einer Applikation welche mit JNI eingebunden wurden. Die PCAP-Datei enthält alle Netzwerkdaten, die über das mobile Datennetz oder WLAN gesendet bzw. empfangen wurden. Um all diese Log-Dateien generieren zu können, werden die folgenden Schritte bei der Analyse einer Applikation abgearbeitet: Der Emulator wird auf einen vordefinierten Zustand zurückgesetzt. Der Emulator wird im Anschluss gestartet. Installation der verdächtigen Applikation mit Hilfe von adb. Start der Applikation in einer eigenen Dalvik VM. ltrace an den laufenden VM Prozess anbinden. MonkeyRunner ausführen um Benutzerinteraktion zu simulieren. Sammeln und auswerten der erzeugten Log-Dateien und der PCAP-Datei. 13. Deutscher IT-Sicherheitskongress des BSI 7

8 Alle erzeugten Berichte und Log-Dateien werden in einer globalen Datenbank abgelegt, damit Analysten diese Daten über die Weboberfläche abrufen können. 2.4 Dynamisches Android Analyse Framework Das Dynamische Android Analyse Framework (DyAnA Framework), ist aus einer Masterarbeit [21] an der Ruhr-Universität Bochum Anfang 2012 hervorgegangen. Mit Hilfe von statischer Instrumentation protokolliert DyAnA jeden Java-Funktionsaufruf einer Applikation, inkl. der Parameter und Rückgabewerte. Native Funktionsaufrufe werden dabei nicht berücksichtigt, da es dafür bereits zahlreiche Programme aus der Linux-Welt (vgl. Abschnitt 2.3) gibt. DyAnA stellt somit eine Alternative zu Droid- Box [20] dar Konzept Dem DyAnA Framework liegt das Konzept der statischen Instrumentierung zugrunde. Die Instrumentierung von Binaries ist ein schon lange bekanntes Feld der Informatik. Bereits in den neunziger Jahren wurden Tools wie ATOM [27] und Etch [23] entwickelt, wobei das PIN-Tool [5, 9] das bekannteste ist. Es verwendet eine dynamische Instrumentierung und es steht neben einer Version für x86 auch eine für ARM- Prozessoren zur Verfügung. Es existierte jedoch bisher kein nutzbares Tool, das den Bytecode auf der Ebene der DalvikVM, dem Äquivalent zur Java Virtual Maschine (JVM) im Android Betriebssystem, instrumentiert. Der Ansatz der statischen Instrumentierung bringt folgende Vorteile mit sich: Das gesamte Android Betriebssystem in der Analyseumgebung kann unverändert bleiben, lediglich das APK wird verändert. Die Analyse kann auch auf echten Mobilgeräten stattfinden, ohne diese rooten oder flashen zu müssen. DyAnA muss nicht für jede neue Android Version angepasst werden, es läuft per Design auf allen Android Versionen. Es kann, spezifisch für jedes APK, die Menge der zu protokollierenden Funktionsaufrufe angepasst werden. Dagegen bestehen folgende Nachteile gegenüber anderen dynamischen Methoden: Nachgeladener Programmcode kann nicht instrumentiert werden. Nativer Code wird nicht instrumentiert (Alternativen vgl. Abschnitt 2.3.2). Darüber hinaus gibt es folgende Nachteile gegenüber statischen Methoden: Das Abarbeiten eines möglichst großen Teils der Programmpfade ist sehr aufwendig und zeitintensiv. Bei der Ausführung der potentiellen Malware hat diese die Möglichkeit, eine Analyseumgebung zu erkennen und auf diese zu reagieren Deutscher IT-Sicherheitskongress des BSI

9 2.4.2 Implementierung Abbildung 3: Ablauf einer Analyse mit DyAnA Das DyAnA Framework greift auf einige bestehende Tools zurück, wie dem apktool [30] und dem Android Emulator [3], deren Einsatz im Folgenden erklärt wird. Abbildung 3 veranschaulicht zunächst den Ablauf einer Analyse. Zuerst wird das APK- Sample durch das apktool entpackt. Dabei werden die Dalvik-Klassen mit Hilfe des Disassemblers Baksmali [12] disassembliert, sodass DyAnA auf dem Smali-Bytecode arbeiten kann. Anschließend wird Bytecode vor und nach den Funktionsaufrufen zum Protokollieren eingefügt, um anschließend den gesamten Code wieder zu assemblieren und zu einem APK zu packen. Um dieses modifizierte APK nun auszuführen, wird wieder der Emulator genutzt (vgl. Abschnitt 2.3.1). Alternativ kann dieses aber auch auf einem Android Mobilgerät ausgeführt werden. Dabei wird durch DyAnA keine Android OS Version fest vorgeschrieben, relevant ist nur noch die im Manifest der APK definierte Mindest-SDK- Version. Die Interaktion mit der Applikation kann dabei entweder manuell von dem Analysten oder automatisch von dem Monkey aus dem Android SDK durchgeführt werden. Die durch den modifizierten Bytecode aufgezeichneten Informationen werden über Androids eigene Logfunktion ausgegeben und von DyAnA in einer Textdatei gespeichert. Dieses Log, genannt DyAnA-Protokoll, wird in Abschnitt 3.4 anhand von zwei Beispielen vorgestellt Anwendungsmöglichkeiten Das DyAnA Framework wurde für die dynamische Analyse von Android Malware entwickelt, so wie aktuell noch DroidBox in der Mobile-Sandbox eingesetzt wird (vgl. Abschnitt 2.3). Es bieten sich aber noch weitere Einsatzmöglichkeiten an: DyAnA kann eine manuelle statische Analyse des Bytecodes mit Informationen über die Abfolge der Funktionsaufrufe, über Parameter und über Rückgabewerte stark vereinfachen. Dies nützt z.b. Datenschützern oder CERT-Mitarbeitern, um Android Applikationen für den Firmengebrauch zu überprüfen und freizugeben. DyAnA könnte, spezialisiert für den Einsatzzweck, bestimmte Informationen herausfiltern. So wäre es für die Strafverfolgungsbehörden mitunter interessant, genutzte Premium-SMS-Nummern und dazugehörige Texte automatisiert von allen schädlichen Applikationen zu bestimmen, um so den Betrügern einen 13. Deutscher IT-Sicherheitskongress des BSI 9

10 Schritt voraus zu sein und deren Einnahmen durch Betrugs-Apps in Deutschland zu unterbinden. Das DyAnA-Modul zur Instrumentation kann automatisiert aus allen Applikationen bestimmte Funktionsaufrufe herauspatchen. Damit könnte z.b. sichergestellt werden, dass eine Applikation keine SMS mehr verschicken kann. 3 Evaluation Im Rahmen der Evaluation der einzelnen Mobile-Sandbox Komponenten wurden je nach Komponente zwischen bis kostenfreie Applikationen aus dem offiziellen Google Play-Market und mehreren inoffiziellen Märkten aus Russland und China analysiert. Unter diesen Applikationen befanden sich ca Applikationen, die durch VirusTotal eindeutig als schadhaft identifiziert wurden und etwa Applikationen aus den erwähnten inoffiziellen Märkten. 3.1 Performance Bei der steigenden Anzahl an neuen Schaddateien für Android ist es extrem wichtig, schnelle und aussagekräftige Analysen zu erhalten. Aus diesem Grund werden alle Komponenten der Mobile-Sandbox fortlaufend auf eine minimale Laufzeit und gleichzeitig auf einen Mehrwert an Ergebnissen optimiert. Der Abgleich mit der VirusTotal Datenbank geschieht im Durchschnitt innerhalb von 3 Sekunden. Die statischen Analysen brauchen typischerweise zwischen 8 und 15 Sekunden. Die dynamischen Analysen benötigen bis zu 14 Minuten, dabei werden abhängig von eventuellen Timern und Broadcasts 6 bis 10 Minuten für die Ausführung der Applikation im Emulator benötigt. Durch Multithreading und parallel betriebene Instanzen kann der Gesamtdurchsatz bei der Analyse noch deutlich gesteigert werden. 3.2 Beispiel zu Program Slicing Die Vorgehensweise zum Auffinden von Konstanten anhand von use-def chains wird in diesem Abschnitt mit einem Beispiel verdeutlicht. Abbildung 4 zeigt ein Programm, nachdem aus dem Dex-Code der App Smali-Code erzeugt wurde. Der Code ist vereinfacht dargestellt, enthält jedoch alle wesentlichen Befehle und Parameter. Das Programm ruft aus der work() Methode die Methode sendmsg() auf und verschickt dort eine SMS-Nachricht. Wenn für dieses Beispielprogramm zwei Slicing Kriterien spezifiziert sind, die jeweils nach der Methode sendtextmessage() aus der Android API den Parameter 1 (Telefonnummer) und 3 (Text) zurückverfolgen, dann werden folgende Konstanten gefunden: Die Nummer für den ersten Parameter und die Methode a.t.t.getdeviceid() und der String imei = für den dritten Parameter. Zusätzlich werden die Aufrufe von getsystemservice() und tostring() sowie der String phone gefunden. Die Telefonnummer wird wie folgt beschrieben durch den Analyseprozess gefunden: SAAF übersetzt den ersten Parameter zu Register v1 in Zeile 33 und startet den Such Deutscher IT-Sicherheitskongress des BSI

11 prozess, welcher sofort ein Feld findet, wessen Wert in Zeile 29 in dieses Register kopiert wird. Daraufhin werden mögliche Werte für dieses Feld gesucht, indem alle Befehle gesucht werden, welche einen Wert in dieses Feld schreiben. Diese werden im Konstruktor in Zeile 4 5 gefunden. Das Register für den Text wird in Zeile 33 zu v3 aufgelöst. Das Slicing zeigt dann, dass Register p1 in Zeile 30 in v3 kopiert wird, welches dem Methodenparameter in Zeile 25 entspricht. In einem weiteren Schritt durchsucht SAAF alle Aufrufe der sendmsg() Methode mit der entsprechenden Signatur. Der Slicing-Prozess wird daher in Zeile 22 mit Register v4 fortgesetzt. Diesem Register wird ein unbekannter Rückgabewert durch den Aufruf der Methode tostring() auf dem StringBuilder Objekt zugewiesen, welches selbst in v2 liegt (Z ). Da der zurückgegeben Wert nicht bekannt ist, behandelt SAAF diese Methode als Konstante und sucht ebenfalls nach allen Operationen, die mit dem Objekt in v2 interferieren. So wird Register v0 gefunden, welches als Parameter der append() Methode dem StringBuilder in v2 übergeben wird. Dadurch wird in den Zeilen v0 analysiert, welches zum Aufruf von a.t.t.getdeviceid() führt da der Rückgabewert in v0 geschrieben wird. In diesem Fall handelt es sich um die IMEI des Gerätes. v3 wird daraufhin ebenfalls analysiert, da getdeviceid() auf diesem Objekt aufgerufen wurde. Da v2 weiterhin analysiert wird, werden die Strings imei = und phone auf eine ähnliche Weise gefunden. Das Beispiel verdeutlicht, das SAAF Register von Methodenaufrufen analysiert, selbst wenn kein Smali-Code dafür vorliegt (z. B. StringBuilder.append() oben). Dieses Verhalten kann zu unerwünschten Ergebnissen führen, da nicht bekannt ist, welche Register relevant sind. Trotzdem ist dieses Vorgehen von Interesse, da so beispielsweise alle Strings gefunden werden, welche einem StringBuilder übergeben werden. Es ist jedoch darauf zu achten, dass nicht die Instanz der aktuell analysierten Klasse ( this ) zurückverfolgt wird, ansonsten würden alle verwendeten Register von allen Instanzmethoden analysiert werden. 13. Deutscher IT-Sicherheitskongress des BSI 11 Abbildung 4: Beispielprogramm zum Versenden einer SMS Nachricht in Smali-Code

12 3.3 Fallstudie zur Analyse von nativem Code In diesem Abschnitt wird exemplarisch eine der gefundenen neuen Schadsoftware- Instanzen beschrieben. Der schadhafte Code der Applikation findet sich zu einem großen Anteil in einer nativen Bibliothek, die zusammen mit der Applikation auf dem Smartphone installiert wird. Ein Abgleich mit der VirusTotal Datenbank ergab eine Erkennungsrate von 0% bei 24 Tests. Während der dynamischen Analyse ist allerdings aufgefallen, dass die Applikation sehr viele persönliche Daten des Benutzers mit Hilfe des NDK verarbeitet. Zudem ist bei der statischen Analyse bereits aufgefallen, dass die Applikation eine ungewöhnlich hohe Anzahl an Berechtigungen benötigt. Zieht man in Betracht, dass die Applikation sich als Social-Networking-App ausgibt, sind viele der Berechtigungen plausibel. Jedoch gibt es immer noch eine hohe Anzahl an Berechtigungen, die in Kombination fragwürdig sind. Dazu zählen unter anderem READ_PHONE_STATE und CHANGE_NETWORK_STATE. Nachdem im Rahmen der statischen Analyse die Codebasis mit den geforderten Berechtigungen verglichen wurde, fiel auf, dass die Applikation massiv überprivilegiert ist, sie also deutlich mehr Berechtigungen vom Benutzer fordert, als sie durch Aufrufe im Java-Code benötigt. Im weiteren Verlauf der Analyse ist aufgefallen, dass die Applikation die IMEI durch einen regulären Java API Aufruf getdeviceid() ausgelesen hat und zugleich noch mit Hilfe einer nativen Funktion getimeinumev(). Diese native Funktion ist nicht Bestandteil der offiziellen Android API, sie wurde vielmehr durch eine Bibliothek bereitgestellt, die sich im Paket der Applikation befindet. Ein identisches Vorgehen war beim Auslesen der IMSI zu beobachten. Beim Analysieren der Codebasis mit Hilfe von Smali fanden sich noch mehr fragwürdige Fragmente. Darunter waren zum Beispiel: android/net/wifi/wifimanager;->startscan(), android/app/activitymanager;->getrunningtasks(), android/media/mediarecorder;->setaudiosource() und android/telephony/smsmanager;->sendtextmessage(). Bei der dynamischen Analyse ist weiterhin aufgefallen, dass die Applikation zu einem mobilen Werbenetzwerk und mehreren inhaltlich fragwürdigen Webseiten Verbindungen per HTTP und HTTPS aufbaut. Nach genauerer Betrachtung des Netzwerkverkehrs fanden sich sehr viele Pakete, die IMEI, IMSI und aktuelle GPS-Koordinaten des Telefons enthielten. Zusätzlich wartet die Applikation auf den Event BOOT_COMPLETED um einen Hintergrunddienst zu starten, der konstant die GPS- Koordinaten ausliest und an diverse Webseiten weiterleitet. Auf Grund all dieser Ergebnisse wurde diese Applikation von uns als schadhaft klassifiziert. 3.4 Beispiele zu DyAnA Einer der größten Vorteile von DyAnA ist die Detailtiefe an Informationen, die das DyAnA-Protokoll enthält. Dies wird nachfolgend anhand zweier schädlicher Applikationen gezeigt: Deutscher IT-Sicherheitskongress des BSI

13 Bei der Malware SuiConFu (md5sum= 1a3fb120e5a4bd51cb999a43e2d06d88 ) produziert DyAnA ein kurzes Protokoll von 29 Zeilen (vgl. Abbildung 5). In Zeile ist zu erkennen, wie eine Zeichenkette mit dem Ländercode de erfolgreich verglichen wird. Im Code wird nachfolgend ein SmsManager Objekt geholt (Z ) um eine SMS-Nachricht an die Premiumnummer mit dem Text SP 462 (Z. 26) zu verschicken. Schon bei Applikationen von mittlerer Komplexität erzeugt DyAnA Protokolle von mehreren tausend Zeilen, da jeder Java-Funktionsaufruf mitgeschnitten wird. Damit der Analyst bei großen Protokollen die Übersicht behält, wurde der Methoden-Aufruf- Graph (vgl. Abbildung 6) entwickelt. Auf der linken Y-Achse sind die verschiedenen lokalen Methoden der Applikation, in der Reihenfolge wie sie in der classes.dex gespeichert wurden, aufgeführt. Auf der rechten Y-Achse ist die Aufteilung der Methoden in Klassen dargestellt. Im Graph sind die Aufrufe der lokalen Methoden mit dem jeweiligen Zeitpunkt festgehalten und durch eine Linie verbunden. Dabei werden die einzelnen Threads auf farblich unterschiedlichen Kurven dargestellt. Zur besseren Referenzierung sind einzelne Methodenaufrufe beschriftet. Abbildung 6: Methoden-Aufruf-Graph für die Applikation RuFakeInstaller Ein Beispiel für eine Applikation mit mittlerer Komplexität ist die Malware RuFake- Installer (md5sum= f056ee7f8d4931c905157ebd2cc4a795 ). Dieser sogenannte Fake Installer täuscht vor eine legitime Installationshilfe für eine meist bekannte Applikation zu sein, wobei im Hintergrund kostenpflichtige Premium-SMS verschickt Abbildung 5: Ausschnitt aus einem DyAnA Protokoll für SuiConFo 13. Deutscher IT-Sicherheitskongress des BSI 13

14 werden. Dabei zeigt diese Applikation dem Nutzer zuerst einen Link auf AGBs und fordert ihn auf, diese zu bestätigen. Danach verschickt die Applikation drei Premium- SMS-Nachrichten abhängig vom Land in dem es sich befindet. Zum Schluss öffnet es den Browser um das gewünschte APK vermeintlich legal herunterzuladen. Abbildung 6 zeigt nun, dass die Applikation nach dem Start durch die oncreate()-methode (m40) regelmäßig dieselben Funktionen aufruft (m2, m14, m15, ). Ein Blick in den Bytecode verifiziert, dass es sich um eine Zustandsmaschine handelt, die regelmäßig bestimmte Events abfragt und darauf reagiert. Ein verändertes Verhalten erkennt man nach dem Aufruf der onclick()-methode (m6), der zuvor beschriebenen Bestätigung der angezeigten AGBs durch den Benutzer, woraufhin die Methode sendsms() (m34) dreimal ausgeführt wird, die den Versand der erwähnten Premium-SMS entspricht. Das Öffnen des Browsers übernimmt (m41) nach einer erneuten Bestätigung des Benutzers (m6). 4 Vergleichbare Arbeiten Für die Android Malware Analyse gibt es einige interessante statische und dynamische Ansätze, wie DroidRanger [33], RiskRanker [15], ScanDal [19] und DroidMoss [31], die aber nicht frei zugänglich sind. Daneben gibt es einige Open Source Tools wie das statisch arbeitende Androguard [7] und die beiden dynamischen Analysetools Taint- Droid [8] und DroidBox [20]. Die zuletzt genannten Tools haben aber sowohl einen hohen Installations- und Einarbeitungsaufwand als auch keine gute Bedienoberfläche. Im Android Web-Sandbox-Bereich gibt es zurzeit nur Anubis [18] mit der Andrubis- Komponente als Konkurrenz. Diese Komponente von Anubis existiert seit Juni 2012 und basiert genau wie Teile des hier präsentierten Systems auf Droidbox. Dabei verwendet Anubis jedoch noch die veraltete Android Version 2.2, die laut aktuellen Zahlen nur noch auf ca. 20% aller aktiven Geräte läuft [2]. Im Vergleich dazu ist die Mobile-Sandbox mit der Portierung von DroidBox auf Android 2.3.x mit mindestens 72,6% der Geräte kompatibel [2]. Andrubis nutzt zusätzlich noch Androguard um statische Informationen herauszufiltern und beispielsweise benutzte Rechte und URLs zu finden. Die Mobile-Sandbox bietet dagegen komplexe statische Analysen und zusätzliche dynamische Analysen von nativen Bibliotheken. DyAnA bietet im Vergleich zu DroidBox den Vorteil, dass mit minimalem Aufwand jegliche Java-Funktionsaufrufe inklusive der Parameter und Rückgabewerte protokolliert werden können. DroidBox schneidet dagegen nur an etwa 50 Stellen im Betriebssystem Funktion mit. Diese Flexibilität von DyAnA kann sogar dafür genutzt werden, mit Informationen aus den statischen Analysen (vgl. Abschnitt 2.1 und 2.2) ein individuelles Log-Profil für jede APK-Datei zu definieren. Des Weiteren ist DyAnA nicht auf Android 2.3 beschränkt, sondern ist per Konzept ohne weitere Anpassung auch kompatibel zu künftigen Android Betriebssystemen. 5 Zusammenfassung In diesem Beitrag wurde die Mobile-Sandbox vorgestellt, die in der Lage ist Applikationen statisch und dynamisch zu analysieren um einem Analysten bei der Entscheidung zu helfen, ob eine Applikation schadhaft ist, oder nicht. Während der statischen Deutscher IT-Sicherheitskongress des BSI

15 Analyse wird die Applikation entpackt und der Smali-Code sowie das Manifest werden analysiert. Bei diesem Schritt wird nach verdächtigen Berechtigungen und Intents gesucht. In einem weiteren Schritt wird eine dynamische Analyse durchgeführt. Bei dieser Analyse werden alle Methoden und Funktionsaufrufe, auch native, überwacht. Mit all diesen Fähigkeiten stellt die Mobile-Sandbox aktuell ein einzigartiges Analyse- Framework für Android unter öffentlich zur Verfügung und ist dabei für aktuelle und zukünftige Malware bestens gerüstet. Trotz all dieser Entwicklungsschritte gibt es noch Punkte zur Optimierung. Zum aktuellen Zeitpunkt ist die Performance der Analysen zu gering um größere Datenmengen in angemessener Zeit zu analysieren. Dieser Schritt wird in der Zukunft durch Parallelisierung der dynamischen Analyse verbessert. Ebenfalls wird auch eine Applikation für Android Mobiltelefone veröffentlicht, die eine direkte Interaktion mit der Mobile-Sandbox zulässt und so dem Benutzer bei der komplizierten Entscheidung, ob eine Applikation gutartig oder schadhaft ist, unterstützt. Für die nähere Zukunft sind weitere Verbesserungen geplant. So soll zum Beispiel das hier vorgestellte DyAnA Framework in die Mobile-Sandbox integriert werden, so dass eine weitere dynamische Analyse zur Verfügung steht. Das aktuell eingesetzte Droid- Box soll um die Kompatibilität zu Android 4.1 erweitert werden, um auch zukünftig verlässliche Informationen zu liefern. Als weiteres Modul wird eine Analyse eingefügt, die durch maschinelles Lernen in der Lage ist, schadhafte Applikationen zu erkennen. Dieser Schritt soll die Erkennungsrate verbessern und die Abhängigkeit von Antivirusprodukten verringern. Danksagungen Diese Arbeit wurde im Rahmen des Projekts MobWorm durch das Bundesministerium für Bildung und Forschung (BMBF) gefördert. Des Weiteren möchten wir Felix Freiling und Thorsten Holz für ihre zahlreichen Kommentare und konstruktive Diskussionen danken. Literaturhinweise [1] F. E. Allen and J. Cocke. A program data flow analysis procedure. Commun. ACM, 19(3), March [2] Android Developers. Platform Versions, October [3] Android Developers. Using the Android Emulator, January devices/emulator.html [4] H. Agrawal and J. R. Horgan. Dynamic Program Slicing. SIGPLAN Not., 25(6), June [5] A dynamic binary instrumentation tool., Feb [6] The Debian Project. ltrace, Januar [7] A. Desnos. Androguard, Januar [8] W. Enck, P. Gilbert, B. gon Chun, L. P. Cox, J. Jung, P. McDaniel, and A. N. Sheth. TaintDroid: An Information-Flow Tracking System for Realtime Privacy Monitoring on Smartphones. 13. Deutscher IT-Sicherheitskongress des BSI 15

16 In USENIX Symposium on Operating Systems Design and Implementation (OSDI), October [9] C. K. Luk, R. Cohn, R. Muth, H. Patil, A. Klauser, G. Lowney, S. Wallace, V. J. Reddi, and K. Hazelwood. Pin: building customized program analysis tools with dynamic instrumentation. SIGPLAN Not., 40(6): , June [10] A. P. Felt, E. Chin, S. Hanna, D. Song, and D. Wagner. Android permissions demystified. In Proc. of the 18th ACM conference on Computer and communications security, [11] L. D. Fosdick and L. J. Osterweil. Data flow analysis in software reliability. ACM Comput. Surv., 8(3), Sept [12] J. Freke. smali - an assembler/disassembler for android s dex format, September [13] G Data. G Data MalwareReport Halbjahresbericht 2012, September [14] Google Inc. Android SDK, October [15] M. Grace, Y. Zhou, Q. Zhang, S. Zou, and X. Jiang. RiskRanker: Scalable and Accurate Zero-day Android Malware Detection. International Conference on Mobile Systems, Applications and Services, [16] Hispasec Sistemas S.L. VirusTotal Public API, March [17] J. Hoffmann, M. Ussath, M.Spreitzenbarth, T. Holz. Slicing Droids: Program Slicing for Smali Code. 28th International ACM Symposium on Applied Computing (SAC 2013). [18] International Secure Systems Lab, Anubis: Analyzing Unknown Binaries, June [19] J. Kim, Y. Yoon, and K. Yi. ScanDal: Static Analyzer for Detecting Privacy Leaks in Android Applications. Workshop on Mobile Security Technologies (MoST), [20] P. Lantz. droidbox - Android Application Sandbox, February [21] H. Lemoine. Dynamic Analysis of Mobile Malware for Android, February Master thesis, Ruhr-University Bochum, Germany. [22] K. Rieck. Derrick, January [23] T. Romer, G. Voelker, D. Lee, A. Wolman, W. Wong, H. Levy, B. Bershad, and B. Chen. Instrumentation and optimization of win32/intel executables using etch. In Proceedings of the USENIX Windows NT Workshop on The USENIX Windows NT Workshop 1997, Berkeley, CA, USA, USENIX Association. [24] SAAF, January [25] M. Spreitzenbarth. The Evil Inside a Droid - Android Malware: Past, Present and Future. In Proceedings of the 1st Baltic Conference on Network Security & Forensics, April [26] M. Spreitzenbarth. Our Android Malware Summary for the Year 2012, January [27] A. Srivastava and A. Eustace. Atom: A system for building customized program analysis tools. pages ACM SIGPLAN 94 Conference on Programming Language Design and Implementation, Deutscher IT-Sicherheitskongress des BSI

17 [28] C. Willems, T. Holz, and F. C. Freiling. Toward automated dynamic malware analysis using CWSandbox. IEEE Security & Privacy, 5(2):32 39, [29] Wireshark Foundation. Wireshark, March [30] R. Wiśniewski. android-apktool - a tool for reverse engineering android apk files, February [31] W. Zhou, Y. Zhou, X. Jiang, and P. Ning. Droidmoss: Detecting repackaged smartphone applications in third-party android marketplaces. ACM Conference on Data and Application Security and Privacy, [32] Y. Zhou and X. Jiang. Dissecting android malware: Characterization and evolution. In Proc. of the 33rd IEEE Symposium on Security and Privacy (Oakland 2012), May [33] Y. Zhou, Z. Wang, W. Zhou, and X. Jiang. Hey, You, Get Off of My Market: Detecting Malicious Apps in Official and Alternative Android Markets. Symposium on Network and Distributed System Security, Deutscher IT-Sicherheitskongress des BSI 17