Erkennung von Schadsoftware auf Androidgeräten

Georg-August-Universität Göttingen Projektarbeit Erkennung von Schadsoftware auf Androidgeräten Malte Hübner 20.01.2013 Betreut durch Prof. Dr. Rieck Lehrstuhl für Computer Sicherheit Georg-August-Universität Göttingen

Mein besonderer Dank für die stets gute Betreuung gilt Daniel Arp, Prof. Dr. Konrad Rieck sowie Fabian Yamaguchi. 2

Inhaltsverzeichnis 1. Einleitung 5 2. Zielsetzung 7 3. Android - Grundlagen 9 3.1. Übersicht des Betriebssystems........................... 9 3.2. Programmieren in Android............................ 11 3.3. Bestehende Sicherheitsmechanismen gegen Malware............... 13 4. Ansätze zur Merkmalsgenerierung 15 4.1. Dynamische generierte Merkmale......................... 15 4.1.1. strace.................................... 16 4.1.2. Kernelauditing............................... 17 4.2. Statisch generierte Merkmale........................... 18 4.2.1. Merkmale aus dem Android Manifest................... 19 4.2.2. Merkmale aus DEX-Bytecode....................... 20 4.3. Diskussion der Ansätze............................... 21 5. App zur Erkennung von Malware auf Android 23 5.1. App-Checkers Benutzeroberfläche......................... 23 5.2. Aufbau und Struktur der App........................... 26 5.2.1. Funktionsweise einer einfachen Analyse.................. 26 5.2.2. Funktionsweise der mehrfachen Analyse................. 29 6. Zusammenfassung und Ausblick 30 Literaturverzeichnis 32 Abbildungsverzeichnis 35 Tabellenverzeichnis 35 A. Anmerkungen zum Icon 36 3

Inhaltsverzeichnis B. dexdump Beispiel 37 C. Detailinformationen über die App 38 D. Neuerungen / Änderungen 40 4

1. Einleitung Aus aktuellen Marktforschungsergebnissen kann entnommen werden, dass Smartphones inzwischen zu den begehrtesten Endgeräten der Informations- und Telekommunikationstechnologie zählen [1]. Der stets wachsende Funktionsumfang und die oft nahtlose Integration dieser Funktionen in die Lebensgewohnheiten der Anwender bedingen dieses Wachstum und somit auch den steigenden Marktteil des unter der Federführung von Google entwickelten mobilen Betriebssystems Android [2, 3]. Dass gerade der Marktanteil von Androidgeräten für Deutschland auf über 50% angestiegen ist, ist - unter anderem - auf die (Quell-) Offenheit von Android zurückzuführen [2, 4]. Da diese Offenheit für Nutzer die Möglichkeit bietet Software - also Apps - aus unbekannten Quellen zu installieren, kann auch Schadsoftware auf die Smartphones gelangen. Angreifer können leicht ihre böswillige Software über die zahlreichen, ungeprüften Drittanbieter-App- Märkte verbreiten. Jedoch beinhalten nicht nur die App-Märkte der Drittanbieter - die im Folgenden auch als Malware bezeichnete - Schadsoftware, sondern auch der offizielle Google Play Store [5]. Da gerade die Erweiterbarkeit der Funktionen durch Apps ein essenzieller Bestandteil von Smartphones ist und sich auf diesen alltäglich genutzten Geräten gebündelt, schützenswerte Personendaten befinden, ist das Smartphone ein besonders begehrenswertes Angriffsziel. Ein Indiz dafür, dass Angriffe auf Smartphones keine theoretischen Überlegungen sind, zeigt sich mitunter in der neusten Androidversion (4.2), in welcher der Versuch unternommen wurde, Apps von unbekannten Quellen auf Böswilligkeit hin überprüfen zu können [6]. Da dieser, sowie andere Ansätze zur Schadsoftwareerkennung in Android unzufriedenstellend sind, befasst sich die vorliegende Arbeit mit dieser Thematik. Dazu werden zunächst aus der zu analysierenden App Merkmale extrahiert, die dann anhand eines automatisch erstellten Modells auf ihre Böswilligkeit hin überprüft werden. Weiterhin ist die Motivation dieser Projektarbeit dadurch gegeben, dass die stetig steigende Anzahl der unterschiedlichsten Apps und die Diversität der Malware unter ihnen ohne automatisierte Mechanismen nur noch schwer zu bewältigen sind oder in Zukunft sein werden. Diese Arbeit untergliedert sich in die folgenden Abschnitte: Im nächsten Kapitel wird das Ziel dieser Projektarbeit detailliert dargestellt. Im daran anschließenden Kapitel sollen Grundlagen zum Betriebssystem Android und den bestehenden 5

1. Einleitung Mechanismen zur Erkennung von Schadsoftware beschrieben werden. Im vierten Kapitel werden Wege und Möglichkeiten zur Extrahierung von Merkmalen aufgezeigt. Dabei wird die Gewinnung von Merkmalen durch dynamische Ansätze - zum Beispiel mittels strace oder Kernelauditing - statischen Ansätzen gegenübergestellt. Im fünften Kapitel wird die entstandene App mit der Malware auf dem Androidgerät erkannt werden kann beschrieben. Abschließend soll das letzte Kapitel eine Zusammenfassung geben und einen Ausblick auf weitere Arbeiten in diesem Zusammenhang aufzeigen. 6

2. Zielsetzung Um die Zielsetzung dieser Arbeit verständlicher zu machen, soll zunächst eine Definition gegeben werden: Def. Merkmal: Als Merkmal bzw. engl. Feature wird im Rahmen dieser Arbeit eine Zeichenkette bezeichnet, die eine bestimmte Eigenschaft oder Funktionalität einer App identifiziert. Insbesondere gehören dazu Systemaufrufe, angeforderte Android-Rechte (wie z. B.: android.permission.internet), benutzte Hard- und Software und verwendete Android-Komponenten, sowie IP-Adressen und URLs. Das primäre Ziel dieser Projektarbeit ist die Entwicklung einer App, mit der ein Benutzer in der Lage ist, sich auf dem mobilen Endgerät befindliche Apps, auf ihre Bösartigkeit hin zu überprüfen. Sekundärziel ist dazu zunächst herauszufinden, welche Möglichkeiten es gibt, Merkmale aus einer App zu extrahieren. Dazu wurde grob in dynamische und statische Erzeugung bzw. Extrahierung von Merkmalen eingeteilt. Die Grundidee die Böswilligkeit einer App aufgrund ihrer Merkmale festzustellen wird anschaulichkeitshalber anhand des folgenden sehr einfach gehaltenen Beispiels erklärt: Beispiel Eine App fordert die Rechte zum SMS verschicken und SMS lesen an. Außerdem wird aus dem Quelltext der App einer der Systemaufrufe zum Verschicken von SMS als Merkmal extrahiert, was bedeutet, dass die App tatsächlich SMS verschickt. Die Rechte und der Systemaufruf in Kombination geben der App somit die Möglichkeit ohne Wissen des Benutzers SMS - auch an mögliche kostenpflichtige Dienste - zu verschicken. Dieses Beispiel soll nicht vermitteln, dass jede App mit dieser Kombination an Merkmalen die bösartige Absicht hat kostenpflichtige SMS zu verschicken, sondern soll den Mechanismus erläutern, dass bestimmte Kombinationen von Merkmalen eher bösartigen Apps zugeschrieben werden können und andere Kombinationen eher für gutartige Apps stehen. Damit die - im Rahmen dieser Arbeit - programmierte App eine Entscheidung über Gut oder Böse treffen kann, nutzt sie ein durch eine Support-Vektor-Maschine erstelltes Modell. Der Inhalt dieses Modells ist im Kern eine Liste von Merkmalen mit einem dazugehörigen Zahlenwert, der angibt wie häufig dieses Merkmale in bösartiger Software verwendet wird. Es könnte also sein, dass eine URL oder eine IP-Adresse ein stark identifizierendes Merkmal für eine 7

2. Zielsetzung Schadsoftware ist, die Kontakt nach hause aufnimmt, da diese Adressen nur in Apps vorkommen die bösartig sind. Wurde aus der App eine Menge von Merkmalen extrahiert, kann diese mit den Merkmalen aus dem Modell geschnitten werden, sodass alle Merkmale übrig bleiben, zu denen ein Wert durch die SVM ermittelt wurde. Aus dieser Menge an Merkmalen wird dann anhand der folgenden Formel ein Zahlenwert errechnet, der die Bös- bzw. Gutartigkeit der App angibt. score(x) = φ Φ(x) ( dbl(φ) ) (2.1) Φ für x = der analysierten App, dbl(φ) dem zum Merkmal zugehörigen Wert und Φ(x) der Menge der im Modell enthaltenen Features aus x, gibt score(x) die Gutartigkeit bzw. Bösartigkeit der App x an. 8

3. Android - Grundlagen In diesem Kapitel werden die notwendigen Grundlagen für das Verständnis dieser Arbeit gegeben. Dazu wird zunächst das Betriebssystem Android detaillierter vorgestellt. Im zweiten Teil dieses Kapitels werden die zum Verständnis dieser Arbeit notwenigen Grundlagen bei der Entwicklung von Apps für Android bereitgestellt. Der letzte Abschnitt gibt einen kurzen Überblick über bestehende Mechanismen zur Erkennung von Android-Schadsoftware. Die Abbildung 3.1 zeigt den Aufbau von Android als Betriebssystem und ist am leichtesten von unten nach oben zu verstehen. 3.1. Übersicht des Betriebssystems Abbildung 3.1.: Android Systemarchitektur [7] Android ist ein auf einem angepassten Linuxkern (bzw. -kernel) aufbauendes quelloffenes Betriebssystem für mobile Geräte [8]. Der Kern ist für die Gerätetreiber, die Netz- 9

3. Android - Grundlagen werkkommunikation und Multimediaeinrichtungen, sowie für die Speicher-, Benutzer- und Prozessverwaltung zuständig (vgl. Abbildung 3.1). Die zusätzlich installierbaren Anwendungen - Apps - für Android werden in Java programmiert. Die Laufzeitumgebung für eine Android-App besteht aus der - später genauer beschriebenen - DalvikVM und den zugehörigen Bibliotheken (in Abbildung 3.1 gelb-gold hinterlegt). Hinzu kommen eine Reihe von (in Abbildung 3.1 in grün hinterlegten) nativen Bibliotheken, die für geschwindigkeitskritische Bereiche zuständig sind. Für jede neu installierte App legt Android eine eigene Sandbox an, in der zunächst nur die DalvikVM gestartet wird, die dann wiederum den App-Code ausführt. Sandbox -Umgebung in Android heißt, das Prozesse und Daten einer App von anderen Apps abgeschottet sind [9]. Um das zu erreichen, wird für jede installierte App ein eigener Betriebssystembenutzer (mit zugehöriger User-ID ) angelegt und jede App in einem eigenen Prozess gestartet. Zu diesem Prozess gehört ein reservierter Speicherbereich im Hauptspeicher, sowie auf dem Dateisystem [10]. Der zu der App zugehörige Benutzer kann sich auf dem System nur in den Bereichen bewegen, für die seine ID zulässig sind. Diese Überprüfung der Berechtigungen funktioniert nur auf Dateisystemen, die auch das Linuxrechtesystem unterstützen, was für zusätzlich installierte und oft mit FAT -formatierte SD-Karten nicht der Fall ist. Definierte Ausnahmen zur Inter-Prozess-Kommunikation sind vorgesehen und werden schon im Kern durch einen speziellen Treiber - den Binder - unterstützt (vgl. Abbildung 3.1). Aufbau einer App Android Apps sind komprimierte (zip-)archive mit der Endung.apk. In ihrem Wurzelverzeichnis muss sich das Manifest der App mit dem Namen AndroidManifest.xml befinden, dessen Inhalt die Absichten der App darstellt [11]. Zudem sind in der *.apk-datei sämtliche verwendete Ressourcen, also Bilder, Texte, Layouts und andere Ressourcen, wie beispielsweise Binärdatein enthalten. Der Quelltext (Byte-Code) für die DalvikVM befindet sich in der Datei classes.dex, die sich auch im Wurzelverzeichnis des Archivs befinden muss. Im Gegensatz zu Java ist der gesamte Byte-Code in dieser einen Datei enthalten und nicht über mehrere *.class-dateien verteilt. Allerdings ist der Java-Byte-Code aus den *.class-dateien ein Zwischenschritt beim Kompilieren von Android-Apps. AndroidManifest.xml [11] Damit das Androidsystem eine App installieren kann, muss sie das Android Manifest kennen. Bei der Installation wird der Benutzer der App gefragt, ob er der App die angeforderten Rechte erteilen möchte. Diese Rechte werden vom Entwickler im Android Manifest angefordert. Außerdem wird im Android Manifest festgelegt, welche Android Komponenten (siehe dazu den nächsten Teilabschnitt) die App benutzt und wie diese von fremden Apps, für eine mögliche Inter-Prozess-Kommunukation (IPC), zu gebrauchen sind. Somit ist der Entwickler in der Lage, die IPC zu erlauben und zu definieren, was die Komponenten der App können bzw. anbieten. Eine detailreiche Erklärung über das Android 10

3. Android - Grundlagen Manifest und dessen mögliche Inhalte findet sich unter [11]. Dalvik-VM [12] Die Dalvik Virtual Machine kurz Dalvik VM ist das eigentliche Herzstück des Androidsystems. Sie wurde von dem Googlemitarbeiter Dan Bornstein entwickelt und ähnelt in ihrer Funktionsweise der JavaVM, führt demnach ebenfalls Byte-Code aus. Der Byte-Code aus der classes.dex-datei enthält nach dem Kompilieren alle Optimierungen für die DalvikVM. Technisch ist die DalvikVM aber kein Kellerautomat - wie die JavaVM - sondern eine Registermaschine. Der Entwickler Dan Bornstein nennt die folgenden Vorteile der DalvikVM gegenüber der JavaVM. Die DalvikVM...... kann auch auf langsamen Prozessoren effizient laufen.... braucht relativ wenig RAM.... kommt ohne SWAP-Speicher aus bzw. läuft auf Betriebssystemen ohne SWAP.... läuft auf batteriebetriebenen Geräten (Effizienz). Apps die in der DalvikVM laufen, können auf die verschiedenen Systemkomponenten über die jeweiligen Bibliotheken zugreifen (vgl. Abbildung 3.1). Dazu zählen auch die in Abbildung 3.1 in grün dargestellten - nicht in Java implementierten - Bibliotheken, wie z. B. für SQLite. Ebenso ist die spezielle Hardware, wie z. B. die ggf. vorhandene Kamera inkl. ihrer Treiber, in C bzw. C++ implementiert und lässt sich über die Bibliotheken nutzen. Die in Abbildung 3.1 großen, blau hinterlegten Bereiche werden im nächsten Abschnitt genauer beschrieben. 3.2. Programmieren in Android Android Apps bauen auf dem Konzept der losen Kopplung von Komponenten auf, es gibt also für eine App keine typische main-(...)methode, denn der Einstiegspunkt in eine Android-App ist in der Regel eine (oder mehrere) sogenannte Activity(s). Für Android werden vier Grundtypen von Komponenten definiert: Activity Eine Activity ist eine einzelne Bildschirmseite, für die Anzeige von Inhalt und der Interaktion mit dem Benutzer. Die entwickelte App hat zum Beispiel je eine Activity zum Starten der Analyse und zum Betrachten der Ergebnisse (vgl. Abbildung 5.1-5.6). Service Ein Service in Android ist eine Komponente, die lang laufende Operationen im Hintergrund ausführt. Allerdings wird allein durch die Instanziierung der Klasse kein neuer Prozess oder Thread gestartet. Um die Ausführung der Operation aus dem Haupt-Thread zu lösen, muss ein neuer Thread erstellt werden. Diese Dienste bieten keine Benutzerinteraktionen an, sodass die Dienste durch andere Komponenten 11

3. Android - Grundlagen (Activities) gesteuert werden müssen. Hat ein Service seine Arbeit verrichtet, teilt er in der Regel dem Benutzer dies mit. Dafür kann er eine Meldung (Notification) direkt an den Nutzer absenden oder er verwendet einen Broadcast, der dann von einem BroadcastReceiver empfangen wird und sich um die Benutzerinteraktion kümmert. In der im Rahmen dieser Arbeit entwickelten App laufen die App-Analysen in solchen Diensten (Services) und informieren den Benutzer über den Analysestatus selbst, sofern der Benutzer die App im Hintergrund laufen hat. Diese Art der Benutzerinteraktion nennt sich Ongoing-Notification 1 und ist in Abbildung 3.2 zu sehen. Ongoing bedeutet in diesem Zusammenhang, dass sich die Meldung unter dem Bereich Aktuell befindet und das Androidsystem einen Service im Vordergrund bzw. mit einer Ongoing-Notification nicht aus Speicherplatznot stoppen sollte. BroadcastReceiver Das Android-System verschickt systemweite Nachrichten - sogenannte Broadcasts - wenn bestimmte Statusänderungen eintreten. Dazu gehört zum Beispiel, wenn sich die Ausrichtung des Telefons ändert oder der Akku zuneige geht. Jede App kann dann mittels eines BroadcastReceivers die für sich relevanten Nachrichten empfangen und entsprechend darauf reagieren. Hinzukommt, dass der Entwickler einer App auch selbst Broadcasts verschicken kann. In der hier beschriebenen App werden Broadcasts versand, wenn einer der Teildienste seine Arbeit abgeschlossen hat. ContentProvider Die vierte Komponente ist der ContentProvider, der hier nur vollständigkeitshalber genannt wird. Diese Komponente bietet die Möglichkeit Daten über App-Grenzen hinweg zu ändern und zu nutzen. Damit das Konzept der losen Kopplung funktioniert, verschicken und empfangen die drei erstgenannten Komponenten gegenseitig die gewünschten Absichten des zu Erledigenden über asynchrone Nachrichten, mithilfe der sogenannten Klasse Intent. Der ContentProvider bildet unter den vier Android-Komponenten die diesbezüglich Ausnahme. Intents werden zur Laufzeit von einer Komponente mit Daten oder Nachrichten erzeugt und einer anderen Komponente überreicht. Dabei wird zwischen expliziten Intents, bei denen der Empfänger vorher feststeht, und impliziten Intents unterschieden, die Abbildung 3.2.: Ongoing -Notification als Broadcast-Intent an das System gereicht werden und diejenigen Apps darauf ansprechen, dessen Filter zur Absicht passt. Ein Entwickler muss somit beispielsweise keinen Browser implementierten, um eine Webseite anzuzeigen, er kann 1 Eine Ongoing-Notification wird immer angelegt, wenn der Entwickler den Service im Vordergrund startet. 12

3. Android - Grundlagen dafür einen sogenannten Intent mit der gewünschten Webseite an das Androidsystem schicken. Eine App, die Webseiten anzeigen kann (in der Regel einer der installierten Browser), dessen intent-filter demnach auf diese Art von Intents abspricht wird ihn entgegennehmen, verarbeiten und schließlich die Webseite öffnen. Der in Abbildung 3.1 dargestellte untere blaue Bereich stellt den Anwendungsrahmen einer App dar. Entwickler können über die dort vorhandenen Klassen und Bibliotheken die systemspezifischen Funktionen benutzen und so z. B. - mittels eines Intents - einen Telefonanruf einleiten. Weitere Details zum Aufbau und der Funktionsweise von Android und dessen Sicherheitseinrichtungen sind unter [13] zu finden. 3.3. Bestehende Sicherheitsmechanismen gegen Malware Das Sicherheitssystem von Android ist schichtweise vom Kern bis zur Anwendungsebene aufgebaut und steckt unter anderem in den eben beschriebenen Abläufen zum Anlegen einer Sandbox mit beschränkten Zugriffsrechten. Es gibt allerdings auch eine Reihe von Kritikern bzgl. der Sicherheit von Android [14]. Eine zusammenfassende Würdigung der Sicherheit in Android bietet eine im Internet frei verfügbare Diplomarbeit aus 2011 von Stefan Klement, die an der Uni Bremen verfasst wurde [15]. Da der Fokus dieser Projektarbeit auf Malwarererkennung liegt wird hier im Weiteren nur auf die Mechanismen zur Schadsoftwareerkennung eingegangen. Seit der neusten Androidversion 4.2 haben die Benutzer die Möglichkeit des App Verifizierens [6]. Allerdings wurde diese Funktion stark kritisiert, sodass sie bisher nicht zu mehr dient als - wie eingangs beschrieben - zu zeigen dass Andoridmalware auch bei den Entwicklern von Android ein aktuelles Thema ist [6]. Die Idee ist, dass Apps aus unbekannten Quellen wie Drittmärkten an Google verschickt werden können um im Ergebnis einen Wert der Böswilligkeit zurückzuliefern. Außer der abschaltbaren Installationssperre von Drittanbieter-Apps bietet Android von Haus aus keinen Schutz vor Schadsoftware aus externen Quellen. Hilfreich für den Nutzer um Angriffe über Malware zu vermeiden ist die, in der Regel vorhandene Kommentar- und Bewertungsfunktion in den App-Märkten. Je mehr Benutzer diese App heruntergeladen haben desto größer ist die Wahrscheinlichkeit, dass einem Benutzer Fehlverhalten aufgefallen wäre und dieses auch mitgeteilt hätte. Um Apps im Google Play Store zu veröffentlichen muss ein Entwickler zunächst ein Entwicklerkonto anlegen, das 25 US-$ kostet. Jede in den Store eingestellte App wird signiert, sodass sie dem Entwicklerkonto zuzuordnen ist. Beim Einstellen der App in den offiziellen 13

3. Android - Grundlagen Google Play Store überprüft Google - mit dem sogenannten Google Bouncer - die eingestellten Apps auf Schädlichkeit. Dennoch ist der Store nicht frei von Malware [5]. Möchte sich ein Benutzer vor Malware schützen, gibt es inzwischen diverse Ansätze von namenhaften Antivirenherstellern, wobei zusammenfassend gesagt werden kann, dass Erkennung von Malware auf Android dennoch nicht zufriedenstellend gelöst ist und vor allem mit dem wachsenden Bestand an Apps eine Herausforderung bleibt. 14

4. Ansätze zur Merkmalsgenerierung Dieses Kapitel befasst sich mit der Gewinnung von Merkmalen aus laufenden Apps (dynamisch) und aus den vorliegenden *.apk-dateien (statisch). Am Ende dieses Kapitels werden die verschiedenen Ansätze diskutiert. Die Tabelle 4.1 fasst stichpunktartig allgemein die Vorund Nachteile von statischer und dynamischer Merkmalsgewinnung in diesem Kontext zusammen. 4.1. Dynamische generierte Merkmale Schädliche Software in Android kann nur ihre Arbeit verrichten, wenn sie entweder root- Zugriff hat und so die Sandbox umgeht, oder die vorhandenen Bibliotheken und die darin enthaltenen Systemaufrufe nutzt. Eine App, die lediglich läuft aber kein Gebrauch von Systemfunktionen macht, kann den Akku belasten und stören aber kaum nachhaltigen Schaden anrichten - hier greift das Sandboxprinzip. Deshalb wird für den dynamischen Ansatz versucht, die Systemaufrufe eines Prozesses abzufangen und daraus Merkmale der App zu generieren. Wie bereits beschrieben, laufen Apps in Android in einer virtuellen Maschine (der DalvikVM), die in einer Sandboxumgebung gestartet wird. Insofern sollte es zunächst nicht möglich sein, mit einer parallel laufenden App dynamische erzeugte Merkmale abzugreifen, da die App keinen unerlaubten Zugriff auf die zu analysierende App haben darf. Es ist daher notwendig sich auf die Systemebene des Gerätes zu begeben und die Analyse-App mit root-rechten auszustatten, um die notwendige Freiheit zum Starten von Prozessen und Analysewerkzeugen auf Systemebene zu haben. Im Folgenden wird detaillierter auf die Ansätze mit strace und Kernelauditing eingegangen. Hinweis Auf dem für diese Arbeit verwendeten Androidgerät ist root-zugriff möglich und es wurden vorab die folgenden Apps installiert: Root-Explorer[16] Die Root-Expolorer App bietet einige Möglichkeiten, die unter normalen Umständen von der Oberfläche aus nicht möglich sind wie das Ändern von Rechten an Dateien, das Dateisystem als schreibbar einbinden, u. v. m. 15

4. Ansätze zur Merkmalsgenerierung statisch dynamisch Vorteile Schneller und einfacher zu erzeugen; ungefährlicher, da kein Code ausgeführt wird Erkennung von nachgeladenem Code zur Laufzeit; Es kann auch Schadcode aus nativen Bibliotheken erkannt werden Nachteile Erkennt keinen dynamisch nachgeladenen oder versteckten Schadcode z. B. in nativem Quelltext App könnte mit der Ausführung von Schadcode warten bis die dynamische Analyse vorbei ist; Sandox notwendig (aufwendig): Ohne Einschränkung der Laufzeitumgebung kann die App - trotz Monitor - ihre böswilligen Absichten ausführen Tabelle 4.1.: Vor- und Nachteile von statischen und dynamischen Analysen BusyBox[17] Die App BusyBox installiert nach dem Start einige Kommandozeilenprogramme, die es sonst auf dem Gerät nicht verfügbar wären. Dazu zählen unter anderem: grep und cp. 4.1.1. strace Das Kommandozeilenprogramm strace ist meist in den Linuxdistributionen zum Debuggen und Optimieren von Programmen enthalten [18]. Bei Android wurde dieses Werkzeug entfernt, sodass es nachträglich wieder hinzugefügt werden muss. Für ARM-Prozessoren gibt es strace - mittels Cross-Compiler fertig kompiliert - zum Download, sodass es schnell auf dem Androidgerät installiert ist, sofern man die zuvor genannten Vorbereitungen getroffen hat [19]. Befindet man sich nach der Installation von strace auf der Kommandozeile des Androiden, kann man strace wie gewohnt benutzen. Listing 4.1 zeigt, wie man eine App startet - hier die Einstellungen von Android - und mittels strace beobachtet. Allerdings lassen sich nicht alle Apps auf diese Weise starten und beobachten. Der Grund dafür konnte bis jetzt nicht ermittelt werden, könnte aber mit den beschränkten Rechten durch die Sandboxumgebung von Android zusammenhängen. Listing 4.1: Befehl zum Starten von Android-Einstellungen auf der Komandozeile mit strace 16

4. Ansätze zur Merkmalsgenerierung strace am start -a android. intent. action. MAIN -n com. android. settings /. Settings Schlägt man in der man-page von strace nach, findet man die Option -p, mit der sich strace in laufende Prozesse einklinkt. process status - ps ist auch ohne BusyBox auf den Geräten verfügbar, sodass sich leicht die ProzessID herausfinden lässt und man sich mittels strace die Vorgänge anzeigen lassen kann. Prinzipiell ließe sich strace auch aus einer App heraus starten, allerdings produziert strace sehr viel Ausgabe, die aufgrund des beschränkten Speichers sofort verarbeitet werden muss. 4.1.2. Kernelauditing Der für Android verwendete Kern unterstützt im Normalfall kein Audit - wurde also ohne die Option CONFIG_ AUDITSYSCALL =y kompiliert und enthält somit auch nicht die notwendigen Programme. Um das Auditsystem vom Kern zu benutzen, muss zunächst mindestens der Kern des Systems ausgetauscht - und die notwenigen Kommandozeilenprogramme nachinstalliert werden. Der Kern ist unter [20] mit einer Beschreibung zum Herunterladen und Kompilieren verfügbar. Die notwenigen Kommandozeilenprogramme liefert das Projekt unter [21], welches sich dazu entschlossen hat, Audit für Android zu reimplementieren bzw. zu portieren. Folgt man den Beschreibungen auf der Projektseite und hat einen entsprechenden Kern, ist es möglich, mit dem Kommandozeilenprogramm auditctl Regeln für das Auditsystem zu setzen. Anstatt die Informationen in eine Log-Datei zu schreiben, werden diese an den Socket /dev/audit geschickt. Exkurs: Android kompilieren Zu Beginn des Projektes bestand die Überlegung, ein vollständiges Android mit auditierbarem Kern und entsprechenden Werkzeugen zu kompilieren und auf dem Testgerät oder in der VirtualBox laufen zu lassen. Möchte man ein komplettes Android kompilieren, sollte man beachten, dass hierfür ausreichend Ressourcen zur Verfügung stehen müssen. Unter [8] wird beschrieben, wie man die Android-Quelldateien erhält und kompiliert. Dort findet man auch die notwenigen Voraussetzungen an Ressourcen und eine Anleitung zum Aufsetzten des Hostsystems. Nach einigen Versuchen auf dem aktuellen Mac OS X als Hostsystem, kann man abschließend feststellen, dass man auf dieses Betriebsystem als Host für einen erfolgreichen Kompiliervorgang von Android verzichten sollte. Der Hauptgrund dafür besteht darin, dass die in XCode vorhandenen Kompilerversionen falsch sind und sich nur schwer austauschen lassen. Unter Linux ist ein System zum Kompilieren 17

4. Ansätze zur Merkmalsgenerierung von Android schneller aufgesetzt und funktionsfähig. Android für eine x86-architektur zu kompilieren ist, abhängig von der jeweiligen Androidversion zwar möglich, jedoch liefen die fertigen Systeme instabil. Zum Testen des Kernelauditing wurde aus den genannten Gründen auf den vorhandenen Emulator zurückgegriffen. Damit die notwendigen Werkzeuge für das Audit im Emulator zur Verfügung stehen, kann man das Android-Systemimage inklusive der hinzugefügten Werkzeuge erneut packen. 4.2. Statisch generierte Merkmale Im nun folgenden Abschnitt wird auf die Möglichkeiten eingegangen, Merkmale aus der (statischen) *.apk-datei der zu analysierenden App zu gewinnen. Vorweggenommen werden muss hier, dass dieser Ansatz im Folgenden auch in der entstandenen App umgesetzt wurde und deshalb die hier vorgestellten Überlegungen - im Gegensatz zum vorherigen Abschnitt - weitaus konkreter sind. Ferner wurden aus gleichem Grund im vorangestellten Abschnitt Fragen offen gelassen. Für eine statische Analyse bieten sich die Dateien AndroidManifest.xml und classes.dex aus der *.apk-datei an, da diese die meisten der - für die angestrebte Analyse - relevanten Daten enthalten. Weitere interessante bzw. relevante Zeichenketten könnten als vorkompilierte Ressourcen in der *.apk-datei vorhanden sein, die bisher aber nicht analysiert werden. Bei der Erstellung des in Kapitel 2 erwähnten Modells wurden Daten vom Webservice Mobile Sandbox 1 genutzt, welcher ebenso - wie im Folgenden beschrieben - hauptsächlich statisch Merkmale gewinnt [22, 4]. Die Mobile Sandbox teilt die gefundenen statischen Merkmale dabei in die folgenden 11 Kategorien ein: Used Features ; Requested Permissions from Android Manifest ; Used Permissions ; Responsible API calls for used Permissions ; Used Intents ; Used Activities ; Potentially dangerous Calls ; Used Services and Receiver ; Used Providers ; Used Networks ; Found URLs Angelehnt an diese Einteilung wurden für die statische Analyse die in Tabelle 4.2 dargestellten zwölf Gruppen von Merkmalen festgelegt, die sich entweder aus dem Android Manifest oder aus der classes.dex-datei extrahieren lassen. Die nächsten beiden Teilabschnitte befassen sich damit, wie die Merkmale aus dem Android Manifest bzw. der classes.dex gewonnen werden können. 1 http://mobilesandbox.org 18

4. Ansätze zur Merkmalsgenerierung Android Manifest Requested hardware software features Requested permissions Requested Intents Requested Activites Requested Services Requested ContentProvider Requested BroadcastReceiver classes.dex Used responsible API-Calls Used permissions Used potentially dangerous calls Used networks Used URLs Tabelle 4.2.: Die zwölf Merkmalsgruppen aus der statischen Analyse 4.2.1. Merkmale aus dem Android Manifest Das Android Manifest in der *.apk-datei liegt im Binärformat vor und ist somit ohne Konvertierung nicht brauchbar für diese Analyse. Jedoch enthält die Entwicklungsumgebung von Android ein Kommandozeilenprogramm mit dem Namen Android Asset Packaging Tool kurz aapt, mit dem man *.apk-datei erstellen, ändern und lesen kann. Für den Android- Entwickler taucht aapt meist nur im Hintergrund auf, da es von der Entwicklungsumgebung (i. d. R. Eclipse) beim Kompilieren der App automatisch ausgeführt wird. aapt ist in C++ geschrieben und muss somit für die Verwendung auf dem Androidgerät auf dieses portiert werden. Als Android-Entwickler kann man ressourcenintensive Prozesse über das Java Native Interface, kurz JNI in die nativen Programmiersprachen C und C++ auslagern. Für Android benötigt man dazu das sogenannte Native Development Kit - NDK [23]. Diese Möglichkeit C bzw. C++ zu nutzen wurde für aapt zweckentfremdet und anstatt aapt auf Androidsystemebene - ähnlich wie strace - nachträglich zu installieren wurde es auf diese Weise in die private Bibliothek der App aufgenommen, was den Vorteil hat, dass es leicht zugänglich ist. Exkurs: aapt für Android Damit man letztendlich aapt auf dem Androiden aus einer App heraus starten kann, muss man zunächst den Sourcecode zu aapt aus dem Android Open Source Project - AOSP [8] extrahieren. 2. Für Android - IceCreamSandwich liegen die aapt-quell-dateien nach dem Kopieren aus dem Repository in frameworks/base/tools/aapt/. Zusätzlich braucht aapt noch die Bibliotheken expat, libcutils, libhost, liblog, libpng, libutils und materials. Sind alle Quelldateien vorhanden, müssen die Makefiles angepasst werden, wobei das Projekt unter [24] - von Thomas Arn - sehr hilfreich ist, da es zeigt wie aapt unter Android eingebunden werden kann. Konnte man aapt mittels ndk-build 2 Zum auschecken aus dem Repository siehe ebenfalls [8]. 19

4. Ansätze zur Merkmalsgenerierung übersetzten, muss noch die Schnittstelle zum Java-Quelltext geschrieben werden, die neben dem korrekten Aufruf von aapt auch für die Umwandlung der Ausgabe in ein für Java verarbeitbares Format zuständig ist. Auch hierbei gibt das Projekt von Thomas Arn eine gute Hilfestellung [24]. Wurde aapt wie eben beschrieben für Android-Apps verfügbar gemacht, kann man mit den Parametern aapt dump xmltree <*. apk - File > AndroidManifest. xml das Android Manifest aus der *.apk-datei auslesen, ohne dieses zu extrahieren. Die auf diese Art und Weise erhaltenen Informationen sind zwar nicht mehr im XML-Format, aber dennoch so strukturiert dargestellt, dass für das Extrahieren der Merkmale nach Zeichenketten gesucht werden kann, die als Merkmale dienen. Da im Android Manifest angeforderte Hard- und Software, die angeforderten Rechte von der App, benutzte intent-filter, sowie benutzte Activity-, Service-, ContentProvider und BroadcastReceiver-Komponenten enthalten sind, können die in der Tabelle 4.2 aufgelisteten Merkmalsgruppen für das Android Manifest vollständig mit aapt gewonnen werden [11]. 4.2.2. Merkmale aus DEX-Bytecode dexdump ist ein Disassembler für Android-dex-Quelltext, der in der Android- Entwicklungsumgebung enthalten, aber auch auf jedem Androiden verfügbar ist. Er liefert lesbaren Assembler, der sowohl statische Zeichenketten als auch die Systemaufrufe enthält, und bietet sich deshalb als Werkzeug an um diese Merkmale aus der classes.dex-datei zu extrahieren. Im Anhang befindet sich ein Stück beispielhafter von dexdump erzeugter Assembler (vgl. B.1). Die Tabelle 4.2 zeigt fünf Merkmalsgruppen, die aus der classes.dex extrahiert werden können. Die Gruppe Used responsible API-Calls soll die tatsächlich benutzten Systemaufrufe enthalten, für die Android-Rechte angefordert werden müssen. Als Beispiel dient hier der Aufruf sendtextmessage(), für den das Android-Recht android.permission.send_sms vonnöten ist. Eine Liste mit Android-Systemaufrufen und den dazugehörigen notwendigen Rechten, stammt ebenfalls aus der Quelle [4]. Die Gruppe der Used permissions werden aus den tatsächlich benutzen Systemaufrufen abgeleitet. URLs und Netzwerkadressen können mit regulären Ausdrücken aus dem Ergebnis von dexdump gewonnen werden, während gefährliche Systemaufrufe eine vorab definierte Teilmenge der Systemaufrufe ebenfalls aus der Quelle [4] sind. 20

4. Ansätze zur Merkmalsgenerierung 4.3. Diskussion der Ansätze Eingeteilt in dynamisch und statisch gewonnene Merkmale, wurden je zwei Wege vorgestellt, diese zu gewinnen. Im Folgenden wird nun erläutert, warum die entwickelte App ausschließlich auf den statischen Merkmalen arbeitet und weshalb die dynamischen Ansätze bisher nicht weiter verfolgt wurden. Kritische Würdigung Kernelauditing zu verwenden Wie im Teilabschnitt 4.1.2 bereits erwähnt wurde, muss für jedes Androidgerät auf dem Kernelauditing benutzt werden soll, der Kern ausgetauscht werden gegen einen Kern, der Audit unterstützt. Nicht explizit in der Zielsetzung dieser Projektarbeit erwähnt, aber dennoch ein wichtiger Aspekt, ist die Benutzerfreundlichkeit der App und weitere Attribute, die für gute Software - auch im experimentellen Umfeld - stehen, wie: Robustheit, Zuverlässigkeit und Effizienz. Würde man dem Benutzer der App auftragen den Kern seines Gerätes auszutauschen, wäre das mit der Benutzerfreundlichkeit nicht zu vereinbaren. Des Weiteren ist das Projekt [21] nur im experimentellen Status und somit nicht mit Zuverlässigkeit übereinzubringen. Auch aus technischer Sicht ist Kernelauditing für diesen Anwendungsfall sehr komplex, da selbst nach erfolgreichem Austausch des Kerns und Installation der notwendigen Software nicht die Daten - wie unter einem Desktop-Linux - in einer Log-Datei zur Verfügung stehen. Der Grund ist der beschränkte Speicher auf den Endgeräten. Ein schneller Versuch mittels eines C-Programmes die Daten aus dem Socket auszulesen schlug fehl. Das Programm erzeugte keine Ausgaben. Kritische Würdigung strace zu verwenden Der dynamische Ansatz mit strace wäre bzgl. Benutzerfreundlichkeit und Zuverlässigkeit leichter umzusetzen. Doch genau wie Kernelauditing auch, produziert strace eine große Menge an Ausgaben, die das Gerät verarbeiten muss. Die erforderliche Rechenleistung ist auf einem mit einem Akku betriebenen Gerät störend. Ferner ist die Ausgabe - im Gegensatz zu den statisch erzeugten Merkmalen - kryptischer und müsste entweder erst in passende Merkmale übersetzt werden, oder das Modell der SVM muss auf diesen Merkmalen lernen. In Teilabschnitt 4.1.1 wurde zudem das Problem aufgezeigt, dass manche Apps sich nicht über den dort genannten Befehl ausführen lassen. Außerdem wäre es - abgesehen von diesem Problem - dann notwendig, alle zur Analyse relevanten Prozessaufrufe über strace zu starten. Um dies zu erreichen, wäre wiederum ein tieferer Eingriff ins System notwendig. Die weitere Variante mit dem ebenso erwähnten Parameter -p birgt dagegen den Nachteil, dass bis zum Einstieg von strace in den Prozess die potenzielle Schadsoftware schon relevante Schritte getätigt haben könnte. Zu berücksichtigen ist dann noch, dass die Sandbox in Android der zur Analyse entwickelten App verbietet andere Prozesse zu beeinflussen. Damit die 21

4. Ansätze zur Merkmalsgenerierung zu entwickelnde Analyse-App strace benutzen kann wird wahrscheinlichkeit root-zugriff in der App vonnöten sein. Vorher zu testen bliebe noch ob es möglich ist über die mittels ps gewonnene Prozess-ID strace -p auf die Prozesse anderer Apps anzusetzen, was die Sandbox auch verhindern sollte. Ist dies nicht möglich, muss die App vom Benutzer root-rechte erhalten, um derartige Vorgänge anzustoßen. In wieweit die Erzeugung von dynamischen Merkmalen mittels strace umsetzbar und brauchbar ist, bleibt somit noch abschließen zu klären. Zuletzt kann noch festgehalten werden, dass unter der Nutzung von root-rechten eine Analyse mittels strace zumindest machbar zu sein scheint. Kritische Würdigung statische Merkmale zu verwenden Da Kernelauditing und strace sich als die deutlich komplizierter zu beschreitenden Wege herausgestellt haben, und die Ergebnisse für eine serverseitige Schadsoftwareerkennung mit statisch gewonnenen Merkmalen an dem Zeitpunkt der Entscheidung schon gut waren, wurde nur der statische Ansatz in der App umgesetzt. Der größte Vorteil ist in der Benutzerfreundlichkeit zu sehen, denn für die beiden Programme aapt und dexdump hat sich herausgestellt, dass sie sich - ohne root- Rechte - mit einer App ausliefern und benutzen lassen. Dennoch bietet der statische Ansatz nicht nur Vorteile, denn ist es auch in Android möglich, Quelltext zur Laufzeit zu laden (vgl. Tabelle 4.1). Lediglich die Systemaufrufe zum Laden von Quelltext sind erkennbar. Hinzu kommt, dass die genanten Methoden nicht die nativen C- und C++-Programme analysieren. Darüber hinaus ist die kompilierte Bibliothek für aapt nur auf ARM-Prozessoren lauffähig und kann somit auf anderen Architekturen, wie dem Intel Atom nicht funktionieren. Gleiches gilt für die, auf die notwenigen Ausgaben beschränkte, Version von dexdump. Für letzteres Problem lässt sich allerdings ein Fallback-Mechanismus einbauen, der im Problemfall die auf dem Gerät vorhandene aber langsamere Version verwendet. 22

5. App zur Erkennung von Malware auf Android Nachdem nun erläutert wurde, welche der beschriebenen Ansätze umgesetzt werden sollen, geht es in diesem Kapitel um die Beschreibung der entstandenen App. Dabei werden keine Details zur Implementierung gegeben, sondern wird einen Überblick über den generellen Aufbau und die Funktionsweise der App geschaffen. Für tief greifende Informationen und einen detaillierten Einblick in einzelne Komponenten steht die JavaDoc-Dokumentation zur Verfügung. 5.1. App-Checkers Benutzeroberfläche Dieser Abschnitt stellt die Benutzeroberfläche und die möglichen Funktionen der App vor, bevor dann im nächsten Abschnitt auf den Aufbau und die Funktionsweise eingegangen wird. Abbildung 5.1 zeigt die App nach dem Start - also den Hauptbildschirm. Der Benutzer hat die Option zum Mehrfachanalyse-Startbildschirm zu wechseln oder die Analyse einer einzelnen App zu starten. Dazu muss er im vorhandenen Textfeld zunächst den Pfad zu der *.apk-datei eintragen. Als Bedienerhilfe zum Ersuchen des Pfades kann der Benutzer vom Dateibrowser Gebrauch machen, den er über den Dateiordner in der grünen Titelleiste öffnen kann. Abbildung 5.2 zeigt diesen Dateibrowser nachdem der Benutzer eine Datei ausgewählt hat. Mit dem Klick auf OK kehrt die App zum Hauptbildschirm zurück und der Benutzer kann dort mittels des entsprechenden Knopfes die Analyse starten. Hat der Benutzer dies getan, sieht er den Ergebnisbildschirm aus Abbildung 5.3. Hier ist der Ablauf jedes einzelnen Analyseschrittes zunächst durch ein Wartesymbol gekennzeichnet und wird nach Beendigung des jeweiligen Schrittes durch das Symbol mit dem grünen Haken ersetzt. Ist die Berechnung - wie in Abbildung 5.3 - ohne Fehler durchlaufen, wird der Score - also der Grad der Böswilligkeit, als Zahlenwert dargestellt und der Benutzer über die Fertigstellung seiner Berechnungen informiert, sofern er die App nicht im Vordergrund hatte. Über den Detailknopf in der Titelleiste gelangt der Benutzer zur - in Abbildung 5.4 dargestellten - Detailansicht. Diese Ansicht zeigt für die analysierte App alle gefundenen Merkmale. 23

5. App zur Erkennung von Malware auf Android Abbildung 5.1.: Startbildschirm App- Checker Abbildung 5.2.: Dateibrowser mit Auswahldialog 24

5. App zur Erkennung von Malware auf Android Abbildung 5.3.: Einfachanalyse - Ergebnis-/ Fortschrittsanzeige Abbildung 5.4.: Einfachanalyse - Detailansicht der Merkmale 25

5. App zur Erkennung von Malware auf Android Wechselt der Benutzer vom Hauptbildschirm zum Mehrfachanalyse-Startbildschirm, sieht er in etwa den Bildschirm aus Abbildung 5.5. Dort hat er ebenfalls über den Dateibrowser - der in diesem Bereich aber nur als Ordnerbrowser dient - die Option denjenigen Ordner auszuwählen, in dem sich alle Apps befinden, die er analysiert haben möchte. Nachdem er den Ordner bestätigt hat, wird - wie in der Abbildung 5.5 zu sehen - eine Liste mit zu analysierenden Apps dargestellt. Wenn der Benutzer die Analyse gestartet hat, wechselt die App automatisch zum Bildschirm aus Abbildung 5.6, der zunächst allerdings ohne Knöpfe nur die Anzahl der fertig analysierten Apps mit ihrem zugehörigen Scores bzw.werten anzeigt. Da die Analyse von mehreren Apps einige Zeit dauern kann, wird dem Benutzer in der Android-Statusleiste der Fortschritt der Analyse angezeigt (siehe Abbildung 3.2). Der Benutzer kann die App in den Hintergrund legen und warten, bis die Analyse fertig ist, was ihm über Vibration mitgeteilt wird. Sind alle Apps analysiert - und gegebenenfalls der Benutzer zur App zurückgekehrt - kann er die Ergebnisse einsehen und über die in Abbildung 5.6 gezeigten Knöpfe die Ergebnisse zum Server schicken oder die App in den Ausgangszustand zurücksetzen. Die errechneten Ergebnisse befinden sich dann als einfache Textdatei auf dem Dateisystem in dem zu der App gehörigen Ordner /data/data/<package-name>/files, wobei <package-name> aktuell de.izeland.app_checker ist. Dieser Ordner ist für den Benutzer nur unter root-zugriff zu erreichen, weshalb er angehalten ist, die Daten an den Server zu verschicken, sofern sie für weitere Verwendungen zur Verfügung stehen sollen. 5.2. Aufbau und Struktur der App Nachdem nun die verfügbaren Funktionen der App dargelegt wurden, soll im Folgenden auf die Funktionsweise und den Ablauf der Analysen genauer eingegangen werden. Um die Funktionsweise zu verdeutlichen, dient die Abbildung 5.7, die alle wichtigen Komponenten und dessen Zusammenhang zueinander zeigt. Da die Mehrfachanalyse von der einfachen Analyse Gebrauch macht, wird zunächst auf den Ablauf und die verwendeten Komponenten der einfachen Analyse eingegangen. Es ist somit für den folgenden Teilabschnitt in Abbildung 5.7 zunächst nur der obere Kasten - mit der Beschriftung Komponenten: einfache Analyse - zu beachten. Für die einfache, sowie für die Mehrfachanalyse, gilt gleichermaßen, dass die zu analysierende(n) *.apk-datei(n) nach dem Druck auf den Startknopf an den jeweiligen Analysedienst übergeben werden und dieser seine Arbeit autark verrichtet (vgl. Abbilung 5.7). Die im vorherigen Abschnitt dargestellten Ergebnisbildschirme werden ebenso automatisch nach dem Start der Analyse vom jeweiligen Startbildschirm aufgerufen. 5.2.1. Funktionsweise einer einfachen Analyse Wurde der Analysedienst - wie in Abbildung 5.7 dargestellt - gestartet, wird zunächst festgestellt, ob er Teil einer Mehrfachanalyse ist. Falls dies der Fall ist, wird verhindert, dass das Symbol einer laufenden (einfachen) Berechnung in der Android-Statusleiste angezeigt wird. 26

5. App zur Erkennung von Malware auf Android Abbildung 5.5.: Mehrfachanalyse - Startbildschirm Abbildung 5.6.: Mehrfachanalyse - Fortschrittsanzeige 27

5. App zur Erkennung von Malware auf Android Komponenten: einfache Analyse Hauptbildschirm [5.1] aapt-service Analysedienst (einfach) Ergebnisbildschirm (einfach)[5.3] dexdump-service Komponenten: Mehrfachanalyse Mehrfachanalysedienst Mehrfachanalyse Startbildschirm[5.5] Ergebnisbildschirm (mehrfach)[5.6] startet benutzt aktualisiert Abbildung 5.7.: Überblick über die vorhandenen Komponenten und dessen Zusammenhang [ in eckigen Klammern die Abbildung zu der - durch diese Komponente erzeugten - Bildschirmseite ] 28

5. App zur Erkennung von Malware auf Android Im Anschluss daran werden die Dienste für aapt und dexdump gestartet, die für die Extrahierung der jeweiligen Merkmale aus der übergebenen *.apk-datei zuständig sind. Dazu starten beide Dienste das jeweilig in Kapitel 4.2 vorgestellte Kommandozeilenprogramm aapt bzw. dexdump und sorgen dafür, dass aus den Ergebnissen dieser, die Merkmale in eine dafür vorgesehene Datenstruktur abgelegt werden. Sobald einer der beiden Dienste seine Aufgaben beendet hat, setzt er das ihm zugeteilte Status-Flag auf Fertig bzw. Error. Die Änderung im Status wird vom Analysedienst erkannt, der dann eine Nachricht (Broadcast für einen BroadcastReceiver) mit dem aktuellen Status und ggf. einer Fehlermeldung versendet. Waren beide Dienste mit ihren Berechnungen erfolgreich, stehen in der Datenstruktur alle aus der App extrahierten Merkmale zur Verfügung. Der Analysedienst beauftragt die Datenstruktur dann, die Rechenvorschrift 2.1 anzuwerden. Dazu muss zunächst die Schnittmenge der Merkmale aus der App mit den Merkmalen aus dem - in Kapitel 2 beschriebenen - Modell gebildet werden. Nachdem der Wert berechnet oder die Analyse abschließend fehlgeschlagen ist, wird wieder eine Nachricht mit der entsprechenden Information über Erfolg oder Misserfolg der Analyse versendet. Die versendeten Nachrichten sorgen - abhängig davon, ob eine einfache oder eine Mehranalyse läuft - dafür, dass die benutzten Komponenten entsprechend auf die neuen Informationen reagieren können. Für den Fall der einfachen Analyse empfängt - wie in Abbildung 5.7 zu sehen - der Ergebnisbildschirm die Nachrichten und wird so aktualisiert. Dazu registriert sich der Ergebnisbildschirm nach seinem Start beim Andoridsystem als BroadcastReceiver. Da die Activity Ergebisbildschirm nur bei der einfachen Analyse gestartet wird, kann der Nutzer auch nur während einer einfachen Analyse die detaillierten Abläufe erkennen. 5.2.2. Funktionsweise der mehrfachen Analyse Im unteren Kasten der Abbildung 5.7 sind die notwenigen Komponenten für die Mehrfachanalyse dargestellt. Die drei Pfeile vom Mehrfachanalysedienst zum Analysedienst deuten darauf hin, dass der Analysedienst für jede zu analysierende *.apk-datei vom Mehrfachanalysedienst vielfach genutzt wird. Im Kern ist im Mehrfachanalysedienst eine for-each-schleife über alle Apps, die für jede App den Analysedienst startet und dann auf dessen (Broadcast-) Nachrichten wartet. Der Mehrfachanalysedienst wird ebenso, wie im vorherigen Teilabschnitt der Ergebnisbildschirm, als BroadcastReceiver registriert und empfängt so für jede App den aktuellen Status. Anhand der entsprechenden Status wird entschieden, ob die Schleife die nächste App in die Berechnung gibt und wann der Ergebnisbildschirm für die Mehrfachanalyse aktualisiert werden muss. Die Aktualisierungen für diesen Ergebnisbildschirm werden ebenfalls über Nachrichten gesteuert, die allerdings ausschließlich für diesen einen Anwendungsfall verschickt werden. 29

6. Zusammenfassung und Ausblick Im Rahmen dieser Projektarbeit wurde Ansätzen gesucht, um Merkmale - d. h. Zeichenketten mit Systemaufrufen, URLs, Netzwerkadressen oder Rechten vom Androidsystem - aus einer laufenden App oder aus dem Quelltext der App zu gewinnen. Die Menge der gefundenen Merkmale bildet eine gute Basis um anhand dieser mögliche, böswillige Absichten der analysierten App zu erkennen. Nachdem die dynamischen Ansätze zur Analyse einer laufenden App sich als kompliziert herausgestellt haben und der Weg der statischen Merkmale gute Ergebnisse versprach, wurde eine App entwickelt, mit der ein Benutzer in der Lage ist, *.apk-dateien von seinem Android-Smartphone auf ihre Böswilligkeit zu überprüfen. Als Ergebnis erhält der Nutzer einen Zahlenwert über den Grad der Böswilligkeit. Wie dieser Wert zu interpretieren ist hängt vom zugrunde liegenden Modell ab. Das benutzte Modell war für diese Arbeit vorgegeben und wurde mit einer Support-Vektor-Maschine aus einer großen Menge an analysieren Apps (von der MobileSandbox) erstellt [4]. Weitere Fragestellungen, die sich aus dieser Projektarbeit ergeben sind: App root-rechte Bringt root-zugriff in der App einen beachtlichen Vorteil und wäre es möglich die App so zu gestalten, dass sie - falls root-zugriff vorhanden ist - dem Nutzer mehr Freiheiten bei der Analyse gewährt? Ein Vorteil von root-rechten in der App wäre, dass man mit dem Dateibrowser sämtliche Ordner durchsuchen kann und nicht auf die jenigen beschränkt ist, die mit den Rechten der App erreichbar sind. Außerdem könnte man einen Mechanismus einbauen, bei dem der App-Checker sich automatisch anbietet, sobald der Smartphonenutzer eine neue App installiert. Android versendet im Fall einer Neuinstallation eine Systemnachricht. App - Zeichenketten Eingangs wurde erwähnt, dass in dem Archiv der App Zeichenketten als Binärdatein enthalten sein können. Es ist also zu klären, ob es lohnenswert ist diese in die Betrachtung mit einzubeziehen, falls der Programmierer der Schadsoftware versucht dort Zeichenketten wie system/bin/su zu verstecken. strace Da strace eine verhältnismäßig einfache Möglichkeit ist laufende Apps zu analysieren, stellt sich die Frage, ob es sich lohnt, dort weitere Arbeit zu investieren und dem Benutzer der App die Möglichkeit zu bieten, laufende Apps zu untersuchen. Dabei sind die unter 4.1.1 aufgetretenen Probleme zu beachten. 30

6. Zusammenfassung und Ausblick Google hat versucht mit seinem Ansatz des App verifizieren schädliche Apps zu erkennen und dem Nutzer zu melden [6]. Dabei verschickt Google Apps aus unbekannten Quellen an einen Server, der dem Benutzer als Antwort die Schädlichkeit der App einschätzt, was bislang nicht zuverlässig funktioniert [6]. Mit dieser Projektarbeit wurde gezeigt, dass ein solcher Ansatz bei entsprechender Umsetzung sogar ohne Netzwerkverkehr möglich ist. Es muss lediglich das aktuelle Modell auf dem Smartphone vorhanden sein. Eine weitere Idee, um dynamische Merkmale zu erzeugen - die im Rahmen dieser Arbeit nicht näher beachtet wurde - ist, sich mit einer Art strace in die DalvikVM einzuklinken und dort die Systemaufrufe abzufangen. Zu implementieren ist noch eine weitere Bildschirmseite, mit der ein Benutzer in der Lage ist nachzuvollziehen, welche Merkmale der App zu dem erhaltenen Ergebnis geführt haben. Dies würde die Vertrauenswürdigkeit der App erhöhen. Darüber hinaus kann der Benutzer so ein Gefühl dafür entwickeln, welche Eigenschaften einer Software ihr die Möglichkeit gewähren, bösartig zu sein. Der beste Schutz vor Schadsoftware bleibt - auch mit der hier vorgestellten Entwicklung - der geschulte Benutzer. 31

Literaturverzeichnis [1] Brandt, Mathias: Absatzprognosen für Smartphones, Tablets & Co 2013. http://de.statista.com/themen/647/itk-branche/infografik/711 /prognosen-zum-weltweiten-absatz-von-itk-geraeten/. Version: November 2012, Abruf: 14.12.2012 [2] jkj: Android-Marktanteil in Deutschland steigt auf über 50 Prozent. http://www.heise.de/newsticker/meldung/android-marktanteil-in-deutschland -steigt-auf-ueber-50-prozent-1742851.html. Version: November 2012, Abruf: 14.12.2012 [3] vbr: Marktforscher: Über 100 Millionen Androiden ausgeliefert. http://www.heise.de/newsticker/meldung/marktforscher-ueber-100-millionen -Androiden-ausgeliefert-1659638.html. Version: August 2012, Abruf: 5.1.2013 [4] Spreitzenbarth, Michael: Mobile-Sandbox: Having a Deeper Look into Android Applications. In: SAC 13 (2013) [5] Luo, Symphony: 1730 Malicious Apps Still Available on Popular Android App Providers. http://blog.trendmicro.com/trendlabs-securityintelligence/1730-malicious-apps-still-available-on-popular-android-app-providers/. http://blog.trendmicro.com/trendlabs-security-intelligence/1730-malicious -apps-still-available-on-popular-android-app-providers/. Version: Dezember 2012, Abruf: 15.01.2013 [6] rei: Virenbremse von Android versagt. In: c t 2 (2013), Dezember, S. 42 [7] Android Developers: What is Android? http://developer.android.com/guide/basics/what-is-android.html. http://developer.android.com/guide/basics/what-is-android.html, Abruf: 1.1.2011 [8] android open source project. http://source.android.com, Abruf: 15.01.2013 [9] Isohara, Takamasa ; Takemori, Keisuke ; Kubota, Ayumu: Kernel-based Behavior Analysis for Android Malware Detection. In: 2010 International Conference on Computational Intelligence and Security 0 (2011), S. 1011 1015 32

Literaturverzeichnis [10] Arno Becker, Marcus P.: Android 2 - Grundlagen und Programmierung. Bd. 2. dpunkt.verlag, 2010 [11] The AndroidManifest.xml File. http://developer.android.com/guide/topics/ manifest/manifest-intro.html. Version: Januar 2013, Abruf: 07.01.2013 [12] Bornstein, Dan: Dalvik VM Internals. http://fiona.dmcs.pl/podyplomowe_smtm/smob3/presentation-of-dalvik-vm- Internals.pdf, Abruf: 16.01.2013 [13] Application Fundamentals. http://developer.android.com/guide/components/ fundamentals.html. Version: Januar 2013, Abruf: 5.1.2013 [14] Oberheide, Jon: Androix Hax. http://jon.oberheide.org/files/summercon10- androidhax-jonoberheide.pdf. Version: Juni 2012, Abruf: 14.01.2013 [15] Klement, Stefan: Sicherheitsaspekte der Google Android Plattform, Universität Bremen, Diplomarbeit, April 2011 [16] Software, Speed: RootExplorer. https://play.google.com/store/apps/details?id=com.speedsoftware.rootexplorer&hl=de. Version: August 2012, Abruf: 14.01.2013 [17] Rob, Denys Bernhard: BusyBox. http://www.busybox.net. Version: Oktober 2011, Abruf: 15.01.2013 [18] Damato, Joe: strace: for fun, profit, and debugging. http://timetobleed.com/hello-world/. Version: November 2008, Abruf: 05.01.2013 [19] rtm: Create google android strace tool. http://discuz-android.blogspot.de/2008/01/create-google-android-strace-tool.html, Abruf: 07.01.2013 [20] Building Kernels. http://source.android.com/source/building-kernels.html, Abruf: 07.01.2013 [21] AuditdAndroid. https://github.com/nwhusted/auditdandroid. Version: August 2012, Abruf: 07.01.2013 [22] Spreitzenbarth, Michael: Mobile-Sandbox. http://mobilesandbox.org. Version: Januar 2012, Abruf: 07.01.2013 [23] Android NDK. http://developer.android.com/tools/sdk/ndk/index.html, Abruf: 15.01.2013 33

Literaturverzeichnis [24] Arn, Tom: JavaIDEdroid. http://code.google.com/p/java-ide-droid/. Version: Dezember 2012, Abruf: 15.01.2013 34

Abbildungsverzeichnis 3.1. Android Systemarchitektur............................ 9 3.2. Ongoing -Notification............................... 12 5.1. Startbildschirm App-Checker........................... 24 5.2. Dateibrowser mit Auswahldialog......................... 24 5.3. Einfachanalyse - Ergebnis-/ Fortschrittsanzeige................. 25 5.4. Einfachanalyse - Detailansicht der Merkmale................... 25 5.5. Mehrfachanalyse - Startbildschirm........................ 27 5.6. Mehrfachanalyse - Fortschrittsanzeige...................... 27 5.7. Überblick über die vorhandenen Komponenten und dessen Zusammenhang. 28 C.1. Übersicht der wichtigsten Klassen- bzw. Komponentennamen......... 39 D.1. Übersichtsbildschirm Analyseergebnisse..................... 41 Tabellenverzeichnis 4.1. Vor- und Nachteile von statischen und dynamischen Analysen......... 16 4.2. Die zwölf Merkmalsgruppen aus der statischen Analyse............. 19 35

A. Anmerkungen zum Icon Die im Rahmen dieser Projektarbeit entstandene App (der App-Checker) extrahiert Merkmale aus der jeweils analysierten App. Die Menge der Merkmale die eine App besitzt ist gewissermaßen ihr Fingerabdruck, der sich je nach Inhalt des Quelltextes in Gut und Böse unterscheidet lässt. Der App-Checker untersucht diesen Fingerabdruck. An dieser Stelle nochmals vielen Dank für die Idee und die Ausarbeitung dieses Icons an: Sandrina & Marcia Pein. 36

B. dexdump Beispiel Listing B.1: Auszug aus dem dexdump einer bösartigen App 000 f78 : 1 a0c 5 f00 0106: const - string v12, " android. intent. action. NEW_ OUTGOING_ CALL " // string@ 005f 000 f88 : 1 a0b 6000 010 e: const - string v11, " android. intent. extra. PHONE_ NUMBER " // string@ 0060... #5 : (in Lorg / android / system / SMSReceiver ;) name : sendviasms type : ( Ljava / lang / String ; Ljava / lang / String ; Ljava / lang / String ;)V access : 0 x0002 ( PRIVATE ) code - registers : 10 ins : 4 outs : 6 insns size : 54 16 - bit code units 000 cd4 : [000 cd4 ] org. android. system. SMSReceiver. sendviasms :( Ljava / lang / String ; Ljava / lang / String ; Ljava / lang / String ;)V 000 ce4 : 2835 0000: goto 0035 // +0035... 000 d42 : 7406 0 c00 0000 002 f: invoke - virtual / range { v0, v1, v2, v3, v4, v5}, Landroid / telephony / SmsManager ;. sendtextmessage :( Ljava / lang / String ; Ljava / lang / String ; Ljava / lang / String ; Landroid / app / PendingIntent ; Landroid / app / PendingIntent ;) V // method@ 000c 000 d48 : 0 e00 0032: return - void 37

C. Detailinformationen über die App Da in der Projektarbeit weitgehend auf die Verwendung von Klassennamen verzichtet wurde, bietet dieser Abschnitt - für den Leser der JavaDoc - ein paar Zusatzinformationen um leichter den Zusammenhang zwischen der Dokumentation und dieser Projektarbeit zu verstehen. Die App besteht außer aus den zuvor genannten Komponenten noch aus einer Reihe von Schnittstellen unter weiteren Klassen. Damit der Leser die in dieser Projektarbeit beschrieben Komponenten zuordnen kann, wird an dieser Stelle ein Überblick in Form einer Tabelle geschaffen (siehe C.1). Hinzu kommt die Klasse FeatureAnalyzer, die sich um die Speicherung der Merkmale (oben als Datenstruktur bezeichnet) und die Berechnung des Wertes kümmert. Die...Binder-Schnittstellen dienen zur Kommunikation von Komponenten mit den Services. Eine detaillierte Erklärung findet sich auf der Entwicklerseite von Android. Wie unter 3 erwähnt hat jede App ihren eigenen Ordner auf dem internen Speicher. Der App-Checker legt in diesem Ordner die Daten für die Mehrfachanalyse ab. Außer diesen Dateien befinden sich dort noch die - in Dateien geschriebenen - Ausgaben des stderr- sowie stdout-stroms von aapt und die angepasste dexdump-binärdatei für schnellere Analysen. 38

C. Detailinformationen über die App Komponenten: einfache Analyse Hauptbildschirm [5.1] aapt-service Analysedienst (einfach) Ergebnisbildschirm (einfach)[5.3] dexdump-service Komponenten: Mehrfachanalyse Mehrfachanalysedienst Mehrfachanalyse Startbildschirm[5.5] Ergebnisbildschirm (mehrfach)[5.6] Abbildung Hauptbildschirm Ergebnisbildschirm (einfach) Analysedienst aapt-serivce dexdump-service Mehrfachanalysedienst Ergebnisbildschirm (mehrfach) Mehrfachanalyse-Startbildschirm Klassenname MainActivity AnalysisObserveActivity AnalyzeApkService AnalyzeAaptService AnalyzeDexDumpService MultiAnalysisService MultiAnalysisObserveActivity MultiAnalysisStartActivity Abbildung C.1.: Übersicht der wichtigsten Klassen- bzw. Komponentennamen 39

D. Neuerungen / Änderungen Im Folgenden werden Änderungen bzw. Neuerungen an der App dargestellt, die nach der Fertigstellung dieser Projektarbeit eingebaut worden. 23.01.2013 Es ist ein neuer Bildschirm hinzugekommen, der neben der Laufzeit und dem Ergebniswert der analysierten App auch die Zusammensetzung des berechneten Wertes darstellt (vgl. Abbildung D.1). Dieser wird statt des bisherigen Detailbildschirmes aus Abbildung 5.4 nach dem Fortschrittsanzeige-Bildschirm aus Abbildung 5.3 gezeigt (Zugang über den Detailknopf in der Titelleiste). Der bisherige Detailbildschirm aus Abbildung 5.4 ist vom neuen Bildschirm aus - über dessen Detailknopf - weiterhin verfügbar, um alle auch nicht in den Wert eingegangenen Merkmale sichtbar zu machen. In Zukunft soll nach dem Fortschrittsbildschirm automatisch dieser neue Bildschirm gezeigt werden. 25.01.2013 Die Normierung der Vektoren entfällt, sodass lediglich die einzelnen Werte aus dem Modell aufsummiert werden: score(x) = φ Φ(x) dbl(φ) (D.1) für x = der analysierten App, dbl(φ) dem zum Merkmal zugehörigen Wert und Φ(x) der Menge der im Modell enthaltenen Features aus x, gibt score(x) die Gutartigkeit bzw. Bösartigkeit der App x an. 25.01.2013 Die App lässt sich aus jedem Bildschirm über das App-Logo in der Titelleiste beenden. Dabei werden nun auch alle Hintergrundprozesse geschlossen, sodass beim erneuten Start der App keine Seiteneffekte mehr eintreten. 09.10.2013 Mit diesem Update erkennt die App den API-Aufruf javax/crypto/cipher/getinstance und extrahiert aus der darüberliegenden dexdump-zeile den benutzen Verschlüsselungsalgorithmus, sofern er dort vorhanden ist. Dieser wird dann in die Liste der gefährlichen Aufrufe zugefügt und vom Modell erkannt. 40

D. Neuerungen / Änderungen Abbildung D.1.: Übersichtsbildschirm Analyseergebnisse 41