Seminararbeit

TaintDroid: An Information-FlowTracking System for Realtime

Privacy Monitoring onSmartphones

Florian Treinat26. Januar 2014

Gutachter: Dipl. Inf. Daniel Poggenpohl

Prof. Dr. Jan Jurjens Lehrstuhl 14 Software EngineeringFakultat InformatikTechnische Universitat DortmundOtto-Hahn-Straße 1444227 Dortmundhttp://www-jj.cs.uni-dortmund.de/secse

Florian Treinatflorian.treinat@udo.edu.deMatrikelnummer: 136678Studiengang: Master Informatik

Sicherheit und SoftwareengineeringThema: TaintDroid: An Information-Flow Tracking System for Realtime PrivacyMonitoring on Smartphones

Eingereicht: 26. Januar 2014

Betreuer: Daniel Poggenpohl

Prof. Dr. Jan Jurjens Lehrstuhl 14 Software EngineeringFakultat InformatikTechnische Universitat DortmundOtto-Hahn-Straße 1444227 Dortmund

i

ii

iii

Ehrenwortliche Erklarung

Ich erklare hiermit ehrenwortlich, dass ich die vorliegende Arbeit selbststandig ange-fertigt habe; die aus fremden Quellen direkt oder indirekt ubernommenen Gedankensind als solche kenntlich gemacht.

Die Arbeit wurde bisher keiner anderen Prufungsbehorde vorgelegt und auch nochnicht veroffentlicht.

Dortmund, den 26. Januar 2014

Florian Treinat

iv

INHALTSVERZEICHNIS v

Inhaltsverzeichnis

Abbildungsverzeichnis vii

1 Einleitung 11.1 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Das Smartphonebetriebssystem Android 52.1 Android Sicherheitskonzept: Permissions . . . . . . . . . . . . . . . . 52.2 Dalvik VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Dynamic Taint Tracking 9

4 TaintDroid 134.1 Implementierungsansatz von TaintDroid . . . . . . . . . . . . . . . . 134.2 Architektur von TaintDroid . . . . . . . . . . . . . . . . . . . . . . . 15

4.2.1 Taint propagation von interpretiertem Code (Variable-leveltracking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.2.2 Taint propagation von nativem Code (Method-level tracking) . 184.2.3 Taint propagation bei IPC (Message-level tracking) . . . . . . 184.2.4 Sekundarspeicher taint propagation (File-level tracking) . . . . 18

4.3 Benchmark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.4 Fallstudie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5 Related Work 23

6 Fazit 25

Literaturverzeichnis 27

vi INHALTSVERZEICHNIS

ABBILDUNGSVERZEICHNIS vii

Abbildungsverzeichnis

2.1 Ubersicht uber die Systemarchitektur von Android [Gooa]. . . . . . . 6

4.1 Der Implementierungsansatz von TaintDroid mit seinen vier unter-schiedlichen tracking-level. (Bild aus [Enc+10]) . . . . . . . . . . . . 14

4.2 Die Architektur von TaintDroid [Enc+10] . . . . . . . . . . . . . . . 164.3 Speicherung der taint tags im Stack fur interpretierte Programme in

der Dalvik VM (Interpreted Targets), sowie fur nativ ausgefuhrtenProgrammcode (Native Targets). [Enc+10] . . . . . . . . . . . . . . . 17

4.4 Overhead von TaintDroid bei einzelnen Operationen in Android. . . . 194.5 Die in der Fallstudie aus [Enc+10] mit TaintDroid untersuchten Apps

und ihre angeforderten Permissions.(L = Standort, C = Kamera, A = Audiosignal aufnehmen, P = Te-lefonstatus) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.6 Von TaintDroid festgesteller Missbrauch von privaten Daten [Enc+10].. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

viii ABBILDUNGSVERZEICHNIS

KAPITEL 1. EINLEITUNG 1

1 Einleitung

Smartphones nehmen heutzutage immer mehr die Rolle eines standigen Begleiters inunserem Alltag ein. Dies ist deutlich an der weltweit stetig wachsenden Verbreitungvon Smartphones zu erkennen. Laut [Bit] wurden im Jahr 2013 allein in Deutschland26 Millionen Smartphones im Handel abgesetzt. Dies entspricht einer Steigerung ge-genuber dem Vorjahr um ganze 23 Prozent. Damit sind bereits zwei Drittel aller 14bis 29-jahrigen in Deutschland im Besitz eines Smartphones. Nach [Bit] wird dieserTrend weiter zunehmen.

Betriebssystem Verkaufte Einheiten Marktanteil

Android 205.022.000 81,9%iOS 30.330.000 12,1%Windows Mobile Phone 8.912.000 3,6%Andere 5.965.000 2,4%

Tabelle 1.1: Verkaufte Smartphones hinsichtlich ihres Betriebssystems weltweit im drittenQuartal 2013 [Gar]

Kauflich zu erwerbende Smartphones erscheinen mit einem mobilen Betriebssystemvorinstalliert. Es existieren eine Vielzahl unterschiedlicher Betriebssysteme von ver-schiedenen Herstellern. Das am meisten verbreitete mobile Betriebssystem ist Andro-id und stammt von der Open Handset Alliance [Allb], deren Hauptmitglied Googleist. Android besitzt einen weltweiten Marktanteil von 81,9% im dritten Quartal desJahres 2013. Die nachsten beiden Platze nehmen das Betriebssystem iOS von Apple[App] sowie Windows Phone von Microsoft [Mic] ein (siehe Tabelle 1.1). Getriebendurch die große Verbreitung von Smartphones mit Android Betriebssystem zusam-men mit der Eigenschaft, dass Smartphones fur Nutzer immer mehr allgegenwartigwerden, ist Android ein beliebtes Ziel von bosartiger Software. Nach [Fel+11a] kannman diese in drei unterschiedliche Kategorien unterteilen:

• MalwareDie Kategorie Malware umfasst Software wie Trojaner, Wurmer, Viren undweitere. Meist zielt Malware-Software darauf ab gespeicherte Daten des Smart-phone Nutzers zu stehlen oder das Smartphones zu beschadigen. Malware ver-schafft sich in der Regel unautorisierten Zugriff auf ein Smartphone Systemdurch das Ausnutzen von Sicherheitslucken in der Software [VVC11].

• SpywareAls Spyware wird meist (kommerzielle) Software bezeichnet, die sich auf das

2 1.1. AUFBAU DER ARBEIT

Sammeln von personlichen Daten des Smartphone-Nutzers uber einen be-stimmten Zeitraum beschrankt. Zur Installation von Spyware benotigt der An-greifer physischen Zugriff auf das Smartphone. Die gesammelten Daten werdenversteckt vor dem Benutzer an den Angreifer gesendet.

• GraywareUnter Grayware versteht man legitime Software, die einen sinnvollen Zweckfur den Nutzer darstellt. Im Hintergrund sammelt die Software, nicht sicht-bar fur den Nutzer, personliche Daten des selbigen und schickt diese an denEntwickler. Manchmal kommt es vor, dass dieses Verhalten der Software demNutzer gegenuber innerhalb einer EULA verstandlich gemacht wird [Fel+11a].

Um den Nutzer eines Android Smartphones vor solch bosartiger Software zu schut-zen setzt Android ein eigenes Sicherheitskonzept um. Ein genauer Uberblick uberdas Sicherheitskonzept und dessen umfassende Punkte ist unter [Alla] zu finden. Einwichtiger Bestandteil dieses Sicherheitskonzeptes sind die App Permissions [Gooa].Mit Hilfe der Permissions kann sich der Nutzer bei der Installation von Applikatio-nen1 daruber informieren, auf welche Funktionen und Daten des Smartphones die zuinstallierende App Zugriff haben mochten. Ist der Benutzer mit den Zugriffen nichteinverstanden, kann dieser die Installation der App ablehnen. Nach der Installationhat der Nutzer jedoch keinen weiteren Einfluss auf die Zugriffe der App. Der Nutzerist nun darauf angewiesen der App zu vertrauen, dass diese die ihr zugewiesenenRechte nur dafur einsetzt um ihren Zweck zu erfullen und nicht um beispielsweiseden Nutzer und seine Daten auszuspionieren. Dies ist ein großes sicherheitsrelevantesProblem, gerade hinsichtlich der Verbreitung von bosartiger Software wie Grayware[Enc+11].

Die Android Erweiterung TaintDroid [Enc+10] greift dieses Problem auf und ver-setzt den Nutzer in die Lage das Verhalten von installierten Apps auf seinem An-droid Smartphone zu uberwachen. Dazu implementiert TaintDroid ein, an Androidangepasstes, Dynamic Taint Tracking- Verfahren. Mit Hilfe von TaintDroid ist derNutzer in der Lage bosartiges Verhalten von Apps, wie beispielsweise das von Gray-ware praktizierte Verschicken von personlichen Information des Nutzers, in Echtzeitfestzustellen.

Diese Arbeit gibt eine Ubersicht uber die Funktionen von TaintDroid, sowie dessenImplementierung innerhalb des Smartphonebetriebssystems Android. Des Weiterenzeigt sie die Vor- und Nachteile, die durch die Nutzung von TaintDroid entstehen.

1.1 Aufbau der Arbeit

Zu Beginn wird die Motivation hinter der Android Erweiterung TaintDroid vorge-stellt. Das Kapitel 2 gibt einen groben Uberblick uber den internen Aufbau desmobilen Betriebssystems Android, sowie uber die Permissions, die Bestandteil des

1Applikation sind Programme, oft auch von Drittanbietern, die auf dem Android Betriebssystemausgefuhrt werden. Im Folgenden dieser Ausarbeitung werden sie synonym als Apps bezeichnet.

KAPITEL 1. EINLEITUNG 3

Sicherheitskonzeptes von Android sind. Daraufhin wird im folgenden dritten Kapiteldie Funktionsweise des Dynamic Taint Tracking-Verfahrens vorgestellt. In Kapitel 4wird die Architektur von TaintDroid, sowie die Implementierung des Dynamic TaintTracking-Verfahrens unter Android beschrieben. Das Kapitel schließt mit der Vor-stellung einer Fallstudie von TaintDroid, welche das Potential dieses Ansatzes zeigt.Weitere Ansatze, die ahnlich zu TaintDroid und teilweise auch fur andere mobileBetriebssysteme zuganglich sind, werden im funften Kapitel aufgezeigt. Die Arbeitschließt mit einem Fazit in Kapitel 6.

4 1.1. AUFBAU DER ARBEIT

KAPITEL 2. DAS SMARTPHONEBETRIEBSSYSTEM ANDROID 5

2 Das Smartphonebetriebssystem Android

Bei TaintDroid [Enc+10] handelt es sich um eine spezielle Erweiterung von An-droid und ist daher auch nur fur dieses Smartphonebetriebssystem verfugbar. DasBetriebssystem Android wurde erstmalig im November 2007 von der Open HandsetAlliance (OHA), einem Zusammenschluss von aktuell 83 verschiedenen Firmen, derOffentlichkeit vorgestellt. Die OHA wurde ebenfalls im November 2007 von Googlemit der Intention gegrundet, offene Standards fur mobile Gerate zu entwickeln. Daserste Smartphone mit Android als Betriebssystem erschien im Oktober 2008. Aktu-ell erschien Android im November 2013 in der neuesten Version 4.4.

Android als Betriebssystem beschrankt sich nicht nur auf Smartphones, sondernwird auch von anderen mobilen Geraten wie Tablets oder Netbooks eingesetzt. DieArchitektur von Android baut auf einem Linux Kernel in der Version 3.x auf1. Nebeneiner Middleware und verschiedenen Systembibliotheken, die in den Programmier-sprachen C und C++ geschrieben sind, setzt Android eine eigens entwickelte Lauf-zeitumgebung ein. In dieser kommen die Apps und das Application Framework zurAusfuhrung. Das Bild 2.1 gibt einen Uberblick uber die Architektur von Android.Auf eine ausfuhrliche Darstellung der Architektur von Android wird in dieser Aus-arbeitung aufgrund des vorgegebenen Umfanges verzichtet. Stattdessen werden indiesem Kapitel zwei Aspekte von Android vorgestellt, welche fur TaintDroid vonhoher Bedeutung sind. Es handelt sich dabei um die Permissions von Apps, als Teildes Sicherheitskonzeptes von Android, sowie um die virtuelle Maschine Dalvik VM,die Bestandteil der Laufzeitumgebung von Android ist.

2.1 Android Sicherheitskonzept: Permissions

Smartphones wandeln sich heutzutage immer mehr zu einem alltaglichen Begleiterfur seine Nutzer (siehe Kapitel 1). Auf ihnen speichern die Nutzer viele personlicheDaten, wie beispielsweise Kontaktdaten von Freunden und Familie. Des Weiterensind aktuelle Smartphones mit einer Vielzahl an unterschiedlichen Sensoren ausge-stattet mit denen personenbezogene Daten generiert werden konnen. Ein Beispiel fursolch einen Sensor ist das GPS-Modul, womit der aktuelle Standort des Smartpho-nes und damit auch des Nutzers bestimmt werden kann. Solche Informationen sindsicherheitsrelevant und haben einen besonderen Schutzbedarf. Um zu verhindern,dass jede beliebige installierte App auf einem androidfahigen Smartphone solchekritischen Daten auslesen kann, wird in Android ein Berechtigungskonzept einge-

1Die Android Versionen vor Version 4.x basieren alle auf einem Linux Kernel in den Versionen2.6.x.

6 2.1. ANDROID SICHERHEITSKONZEPT: PERMISSIONS

Abbildung 2.1: Ubersicht uber die Systemarchitektur von Android [Gooa].

setzt, die Permissions.Das Sicherheitskonzept von Android sieht vor, dass jede installierte App standard-maßig Zugriff nur auf eigene Daten hat. Um dies zu garantieren, wird jede App ineiner eigenen Sandbox ausgefuhrt. Alle Zugriffe der Apps auf Daten die außerhalbdieser Sandbox liegen werden zuerst gegen die Permissions gepruft, die der Appzugewiesenen worden sind. Besitzt eine App beispielsweise die Permission andro-id.permission.ACCESS FINE LOCATION, so ist es ihr erlaubt den aktuellenStandort des Smartphones abzufragen. Fehlt diese Permission wird der Zugriff derApp vom Androidsystem verwehrt.Android besitzt uber 130 verschiedene Permissions [Gooa], die eine App anfordernkann. Dies erlaubt eine feine Einteilung von Zugriffsrechten beziehungsweise Zu-griffsbeschrankungen. Trotz dieser Moglichkeit wird viel Kritik an dem PermissionKonzept von Android geubt (siehe [VCC11] und [Fel+11b]). Die meisten Kritikenteilen sich dabei zwei Hauptkritikpunkte.

1. Apps fordern unnotige Permissions an:Der Entwickler der App muss bei der Entwicklung festlegen, welche Permis-sions seine App benotigt. Die benotigten Permissions sind abhangig von denSchnittstellen der API, welche die App nutzt. Als Hilfestellung kann der Ent-wickler den Android Developer Guide [Gooa] konsultieren. Dieser ist in man-chen Fallen jedoch nur unzureichend dokumentiert, was dazu fuhrt, dass derEntwickler App Permissions anfragt, die unnotig sind [VCC11].

2. Bestatigung von Permissions sind nur als Ganzes moglich:Bei der Installation von Apps auf einem Smartphone mit Android Betriebssys-

KAPITEL 2. DAS SMARTPHONEBETRIEBSSYSTEM ANDROID 7

tem wird der Nutzer uber die angeforderten Permissions der Apps informiert.Ist der Nutzer mit den angeforderten Zugriffsrechten einverstanden, kann die-ser die Installation bestatigen oder im anderen Fall abbrechen. Der Nutzerist dabei nur in der Lage die Permissions von Apps im Ganzen anzunehmenoder im Ganzen abzulehnen. Eine feinere Einstellung, wie das Zulassen vonlediglich einer Teilmenge der Permissions, ist nicht moglich. Trotz der Exis-tenz von uber 130 verschiedenen Permissions, die theoretisch eine feinkornigeEinteilung von Zugriffsrechten ermoglichen, wird dies von Android an dieserStelle nicht genutzt.

Daruber hinaus zeigt eine Studie aus [Fel+12], dass nur 17% der befragten AndroidNutzern die App Permissions bei der Installation einer App beachten. Des Weite-ren wurden den Befragten dieser Studie Verstandnisfragen zu den Permissions vonAndroid gestellt. So sollten auf Erwahnung einer Permission die Befragten erklaren,welche Zugriffsrechte durch diese Permission der App eingeraumt werden. Lediglich3% der Befragten waren in der Lage alle Fragen korrekt zu beantworten. Dies zeigteine unnotige Komplexitat im Verstandis der verfugbaren unterschiedlichen Permis-sions.

Die genannten Punkte zeigen, dass das Permission Konzept von Android nicht denidealen Schutz von privaten Daten auf Smartphones bietet, sondern auch Nachteilebesitzt. Gerade die Moglichkeit Permissions von Apps nur als Ganzes entweder anzu-nehmen oder abzulehnen birgt ein sicherheitsrelevantes Risiko bezuglich Grayware,wie ein aktueller Fall [Onl] zeigt. In [Onl] fordert eine Android App eine Vielzahl ver-schiedener Permissions vom Benutzer an, um eine simple Funktionalitat zu bieten.Die eingeraumten Permissions nutzt die App im Hintergrund aus, um den Nutzerauszuspionieren. Jegliche von der App gesammelten Daten werden von dieser, ohneKenntnis des Nutzers, an ein Werbenetzwerk geschickt.

2.2 Dalvik VM

In Android werden Apps innerhalb einer eigenen Laufzeitumgebung ausgefuhrt.Wichtiger Bestandteil dieser Laufzeitumgebung ist die Dalvik VM. Jede Andro-id App wird in einer eigenen Instanz der Dalvik VM ausgefuhrt. Bei der DalvikVM handelt es sich um eine register-basierte virtuelle Maschine. Sie ist eine Ei-genentwicklung von Google [Bor08] und interpretiert Programme die als Bytecodeim DEX-Format (Dalvik EXecutable Format) vorliegen. Da Android Apps in derProgrammiersprache JAVA geschrieben werden, mussen die erzeugten Class-Dateienvon JAVA mittels eines Tools, welches von dem Android SDK bereitgestellt wird,in das DEX-Format uberfuhrt werden. Die Interpretation des Bytecodes im DEX-Format geschieht dann in der Dalvik VM mittels verschiedenen virtuellen Register,mit denen Berechnungen durchgefuhrt werden. Dies unterscheidet die Dalvik VMvon der JVM (JAVA Virtual Machine), die auf einem Stack operiert.

Neben der Ausfuhrung der Applikation innerhalb einer Dalvik VM, kann eine Ap-plikation aber auch nativen Code, wie Systembibliotheken aufrufen und ausfuhren.

8 2.2. DALVIK VM

Dies geschieht uber einen Aufruf der spezifischen Bibliothek uber das JNI (JavaNative Interface). Die entsprechende Bibliothek wird dann außerhalb der DalvikVM Instanz geladen und ausgefuhrt.

KAPITEL 3. DYNAMIC TAINT TRACKING 9

3 Dynamic Taint Tracking

Das Dynamic Taint Tracking oder oft auch als Dynamic Taint Analysis bezeich-nete Verfahren gehort zu den Techniken der dynamischen Analyse.

”Die dynami-

sche Analyse ermoglicht es Code bei Ausfuhrung zu uberwachen und ist zu einemgrundlegenden Vorgehen in der Sicherheitsforschung geworden“ [SAB10]. Eine wei-tere Technik, die ebenfalls zu den dynamischen Analyseverfahren gehort, ist dieForward Symbolic Execution. Hierbei werden logische Formeln generiert, die eineProgrammausfuhrung beschreiben [SAB10] [Cos+07]. Diese konnen dann mit LogicResolver analyisiert werden. Oft wird auch eine Kombination der beiden TechnikenDynamic Taint Tracking und Forward Symbolic Execution eingesetzt. Die Andro-id Erweiterung TaintDroid verwendet als dynamische Analyse das Dynamic TaintTracking um Verhalten von Apps in Ausfuhrung zu beobachten. Daher beschranktsich dieses Kapitel auf das Dynamic Taint Tracking Verfahren.

Zu Dynamic Taint Tracking gibt es bisher keine einheitliche formale Definition, ob-wohl schon eine Vielzahl von unterschiedlichen Anwendungen existieren, die diesesVerfahren implementieren [SAB10]. In [SAB10] wird ein erster Versuch unternom-men die beiden Techniken Dynamic Taint Tracking sowie Forward Symbolic Execu-tion zu formalisieren und Vor- sowie Nachteile der beiden Verfahren zu analysieren.Die Beschreibung des Dynamic Taint Tracking Verfahrens in diesem Kapitel orien-tiert sich daher an [SAB10]. Erstmalig vorgestellt wurde die Technik in [NS06].

Dynamic Taint Tracking ermoglicht es das Verhalten von Programmen bei der Aus-fuhrung zu verfolgen und zu analysieren. Das Verfahren funktioniert ohne Zugriffauf den Quellcode des Programmes. Bei anderen Techniken wie der statischen CodeAnalyse ist das Vorhandensein des Quellcodes dagegen notwendig. Dynamic TaintTracking analysiert den Informationsfluss innerhalb des Programms zwischen taintsources und taint sinks. Die Analyse des Informationsfluss wird durch die Verfol-gung von speziell markierten Daten (tainted data oder auch taint tags) realisiert.Daten werden in dem Moment markiert, in welchem sie in Kontakt mit Daten auseiner taint source kommen, d.h. wenn Berechnungen mit Daten aus taint sourcesvorgenommen werden.Im Folgenden werden die wichtigsten Aspekte von Dynamic Taint Tracking vorge-stellt.

10

Taint sources und taint sinks

Wie Eingangs bereits erwahnt wird der Informationsfluss zwischen taint sources undtaint sinks beobachtet. Dazu werden Daten, die aus taint sources stammen, markiertund verfolgt. Erreichen markierte Daten ein taint sink, wird dies erkannt und bei-spielsweise notiert. Die Definition von taint source sowie taint sink ist dabei je nachAnwendungsfall und Programm, das mittels Dynamic Taint Tracking beobachtetwerden soll, unterschiedlich. Beispielsweise wurde in [NS06] ein x86-Emulator umdas Dynamic Taint Tracking modifiziert. Dieser fuhrt Programme aus und schlagtAlarm, wenn diese schadlichen Code ausfuhren. Dazu wurden Eingabedaten vonnicht vertrauenswurdigen Quellen, wie beispielsweise der Netzwerkkarte1 als taintsource definiert. Taint sinks hingegen stellen Funktionen dar, wie beispielsweise dieBerechnung von Sprungadressen oder betriebssystemspezifische System Calls. Wirdeine Sprungadresse mit markierten Daten berechnet schlagt der modifizierte Emu-lator Alarm.

Taint tag

Als taint tag wird die Markierung von Daten bezeichnet. Verlassen Daten taintsources oder werden Berechnungen mit Daten aus taint sources durchgefuhrt, wer-den diese mit einem taint tag versehen und somit markiert.Bei der Implementierung von Dynamic Taint Tracking muss fur die Speicherungvon taint tags an Daten eine geeignete Datenstruktur ausgewahlt werden. Die Vor-gehensweisen sind, wie die Wahl der taint source und des taint sink, abhangig vomAnwendungsfall und der Moglichkeit die zu beobachtenden Programme auszufuhren.Das Programm TaintCheck aus [NS06] implementiert zur Speicherung von taint tagseinen eigenen shadow memory Bereich. Hierbei hat jeder Eintrag im Speicher desEmulators ebenfalls einen Eintrag im shadow memory. Im shadow memory wird einPointer gespeichert, der im Falle von markierten Daten auf eine weitere Datenstruk-tur zeigt, die Informationen zum taint tag und Art der taint source enthalt. Imunmarkierten Fall zeigt der Pointer auf null.

Taint propagation

Unter taint propagation versteht man beim Dynamic Taint Tracking die Verbreitungvon Markierungen der Daten. So erhalten Daten, die eine Berechnung mit bereitsmarkierten Daten durchfuhren oder eine Zuweisung von markierten Daten erhalten,ebenfalls diesen taint tag. Man spricht in so einem Fall von einer taint propagation.Je nach Anwendungsfall ist es moglich verschiedene (logische) Regeln zu definieren,wann genau eine taint propagation stattfindet [SAB10].

Overtainting und undertainting

Beim Dynamic Taint Tracking Verfahren konnen zwei Typen von Fehlern auftreten.

1Hierbei konnen sich Daten, die aus dem Internet von dem Programm nachgeladen werden, alsbosartig herausstellen.

KAPITEL 3. DYNAMIC TAINT TRACKING 11

• overtaintingBei der Analyse mit Dynamic Taint Tracking kann es passieren, dass Datenmarkiert werden, die gar keine Relation zu einer definierten taint source haben.In einem solchen Fall spricht [SAB10] von overtainting.

• undertaintingWerden bei einem Informationsfluss zwischen taint source und taint sink keineentsprechenden Daten markiert, handelt es sich um undertainting2 [SAB10].

2Bei TaintDroid spricht man im Falle von overtainting von”false positive“ und bei undertainting

von”false negative“ [Enc+10]

12

KAPITEL 4. TAINTDROID 13

4 TaintDroid

TaintDroid [Enc+10] ist eine Erweiterung von Android, um die Moglichkeit dasVerhalten von Apps beim Umgang mit privaten Daten des Nutzers wahrend ihrerAusfuhrung zu beobachten. Damit greift TaintDroid die in Kapitel 1 erwahnte Pro-blemstellung von Android auf und versetzt den Nutzer in die Lage Missbrauch vonprivaten Daten durch Apps wie Grayware zu erkennen. Zur Realisierung dieses An-satzes implementiert TaintDroid das Dynamic Taint Tracking Verfahren in Android.Eine Analyse mittels diesem Verfahren funktioniert auch ohne vorhandenen Quell-code der Apps (siehe Kapitel 3), der in den meisten Fallen auch gar nicht zuganglichist.Dieses Kapitel stellt den Aufbau und die Implementierung der Android ErweiterungTaintDroid vor. Dazu wird zu Beginn die Architektur von TaintDroid beschrieben,sowie die Umsetzung des Dynamic Taint Tracking Verfahrens innerhalb des Betriebs-systems Android vorgestellt. Daruber hinaus werden Ergebnisse eines Benchmarks,sowie einer Fallstudie bezuglich TaintDroid vorgestellt.

4.1 Implementierungsansatz von TaintDroid

Das Ziel von TaintDroid ist es, mittels Dynamic Taint Tracking, private Daten desSmartphone Nutzers vor Missbrauch durch Apps wahrend der Laufzeit festzustellenund zu melden. Hierfur mussen zuerst die taint sources sowie die taint sinks (sieheKapitel 3) in Android lokalisiert werden. Als taint sources wurden in TaintDroidalle sensitiven Informationen und Daten des Nutzers definiert [Enc+10, S.2]. Diesesind in den meisten Fallen uber spezielle Provider innerhalb des Application Fra-meworks von Android erreichbar (siehe Kapitel 2). Die taint sinks in Android sinddiejenigen Stellen an denen Daten das System verlassen, wie beispielsweise die Netz-werkschnittstelle von Android. Mithilfe von taint tags, die an Daten welche aus taintsources stammen, vermerkt werden, kann ein Informationsfluss vom taint source biszum taint sink verfolgt werden. Verlassen sensitive Daten des Nutzers das Systeman einem taint sink, schlagt TaintDroid Alarm.

TaintDroid unterscheidet sich von den gangigen Implementierungen der DynamicTaint Track Verfahren, welche meist auf der Ebene von nativem Code arbeiten umdie taint propagation (siehe Kapitel 3) zu implementieren [Enc+10]. Solche Im-plementierung erfordern eine Emulation des Systems mit modifiziertem Emulator[NS06] und besitzen eine meist niedrige Performance. Des Weiteren ist ein solcherAnsatz fur Android nicht geeignet, da die Beobachtung des App-Verhaltens in Echt-zeit durch TaintDroid erfolgen soll.

14 4.1. IMPLEMENTIERUNGSANSATZ VON TAINTDROID

Stattdessen nutzt TaintDroid einige architektonische Aspekte von Android aus undmodifiziert diese, wie die Android-eigene Laufzeitumgebung in der alle Apps ausge-fuhrt werden (siehe Kapitel 2.2). TaintDroid implementiert dazu vier unterschiedli-che tracking level:

• Variable-level tracking,

• Method-level tracking,

• File-level tracking und

• Message-level tracking.

Die Lage der unterschiedlichen tracking level im Android System kann der Abbildung4.1 entnommen werden. Die Funktionsweise und Implementierung der einzelnen Le-vel werden in Kapitel 4.2 vorgestellt.

Die Modifikationen vom Androidsystem, welche dem Implementierungsansatz vonTaintDroid zu Grunde liegen, haben zur Folge, dass TaintDroid selbst nicht als eigeneApp in Android lauffahig ist. Stattdessen mussen die Erweiterungen von TaintDroidals modifiziertes Androidsystem neu compiliert werden. Das dabei erhaltene Taint-Droid Image kann dann auf ein Android lauffahiges Smartphone installiert werden,wo es die alte Android Version ersetzt. Um eine solche Installation vornehmen zukonnen muss das Smartphone in den meisten Fallen

”gerootet“ sein.

TaintDroids Ansatz des Dynamic Taint Tracking unter Android funktioniert unterder Annahme, dass die Software des Android Betriebssystems im Auslieferungs-zustand vertrauenswurdig ist [Enc+10]. Dies umfasst alle Systembibliotheken, dieLaufzeitumgebung, die Middleware, sowie den Linux Kernel (zum Aufbau von An-droid siehe Kapitel 2, insbesondere Abbildung 2.1 auf Seite 6). Da Android AppsSystembibliotheken oder das Application Framework nicht manipulieren konnen, istunter dieser Annahme gesichert, dass die Modifikationen von TaintDroid an Androidstets vertrauenswurdig sind.Die einzige Moglichkeit, die Apps haben, um die Modifikationen von TaintDroidzu umgehen und so einem tainting zu entgehen, stellt die Nutzung von nativen

Abbildung 4.1: Der Implementierungsansatz von TaintDroid mit seinen vier unterschied-lichen tracking-level. (Bild aus [Enc+10])

KAPITEL 4. TAINTDROID 15

Bibliotheken (.so Bibliotheken) dar. Um einen solchen Ausbruch zu verhindern, ver-bietet TaintDroid das Nachladen von nativen Bibliotheken, die den Applikationenbeiliegen. Stattdessen werden nur native Bibliotheken zugelassen, die bereits demAndroidsystem beiliegen und uber das JNI geladen werden und somit vertrauens-wurdig sind. Die entsprechende Funktionen zum Laden von Bibliotheken uber JNIwurde von TaintDroid so modifiziert, dass die taint propagation (siehe Kapitel 3)unterstutzt wird und die taint tags entsprechend gesetzt werden.Aus dieser Einschrankung resultiert die Unfahigkeit Apps auszufuhren, die eigenenative Bibliotheken nutzen. Laut [Enc+10] betraf dies 2010 nur rund 4% der Appsaus dem Google Play Store [Goob].

4.2 Architektur von TaintDroid

Die Architektur von TaintDroid ist mit dem Ziel entworfen worden vier verschiedenetracking level in Android zu implementieren. Dazu wurden mehrere Modifikationenan Android vorgenommen, die in den folgenden Unterkapitel vorgestellt werden. ZuBeginn wird die Architektur anhand eines Beispiels von einem Informationsfluss vontaint source zu taint sink vorgestellt. Die Abbildung 4.2 visualisiert dieses Beispiel.

(1) Der Zugriff auf sensitive Informationen des Nutzers, wie dem Standort oderprivate Kontakte, werden von einer vertrauenswurdigen Applikation, wie demLocation Provider oder dem Content Provider ausgefuhrt. Beide Provider fun-gieren hierbei als taint source.

(2) Beim Zugriff auf eine taint source wird eine Modifikation von TaintDroid, eintaint interface [Enc+10, S. 4], aktiviert, welches ein taint tag fur die abgeru-fenen Daten in der ausfuhrenden Dalvik VM der App speichert.

(3) Die Dalvik VM propagiert die taint tags entsprechend dem Informationsflussin der App, die sie aktuell ausfuhrt, in einer virtual taint map.

(4) Fuhrt die App einen Aufruf zu einer anderen App mittels IPC (Inter ProcessCommunication) durch, welcher markierte Daten aus taint sources enthalt,wird uber die modifizierten nativen Bibliotheken von Android sichergestellt,dass Pakete, die an den IPC Binder weitergegeben werden, ebenfalls einenentsprechenden taint tag enthalten.

(5) Der Kernel ubermittelt das markierte IPC Paket an die Empfanger-App, wel-che als nicht vertrauenswurdig angesehen wird, da sie kein Standard Bestand-teil des Android System ist.

(6) In der Empfanger-App wird das IPC Paket ausgepackt und die entsprechendenDaten in der Dalvik VM Instanz der aktuellen App eingelesen. An dieser Stellewerden die Daten entsprechend dem taint tag des IPC Paketes ebenfalls wiedermarkiert.

(7) Die Daten werden dem Informationsfluss entsprechend wie in (3) propagiert.

16 4.2. ARCHITEKTUR VON TAINTDROID

(8) Die nicht vertrauenswurdige App fuhrt einen Aufruf einer vertrauenswurdigeBibliothek zur Ansteuerung eines taint sinks aus, beispielsweise der Netzwerk-schnittstelle.

(9) Die modifizierte Bibliothek zur Ansteuerung des taint sinks uberpruft, ob diezu ubertragende Daten ein taint tag besitzen und dementsprechend als sensi-tive Daten deklariert sind. Ist dies der Fall loggt TaintDroid die Daten, sowiedie ausfuhrende App und benachrichtigt den Nutzer.

Abbildung 4.2: Die Architektur von TaintDroid [Enc+10]

4.2.1 Taint propagation von interpretiertem Code (Variable-level tracking)

Apps werden unter Android in einer Instanz der Dalvik VM ausgefuhrt. Um denInformationfluss einer App uberwachen zu konnen, muss TaintDroid in der Lagesein, die ausgefuhrten Instruktionen der Dalvik VM zu uberwachen und dort einetaint propagation zu implementieren. Diese Funktion ubernimmt das Variable-leveltracking.Die Implementierung des Variable-level tracking modifiziert den VM Interpreter umdie Umsetzung einer TaintDroid eigenen Funktionslogik, der Taint Propagation Logic[Enc+10]. Diese beschreibt das Verhalten von taint tags, wenn innerhalb des VM In-terpreters Instruktionen ausgefuhrt werden, die markierte Daten enthalten. Um mittaint tags innerhalb der Dalvik VM arbeiten zu konnen, mussen diese vorerst an denentsprechenden Daten gespeichert werden. Es existieren unterschiedliche Implemen-tierungsansatze fur die Speicherung von taint tags beim Dynamic Taint TrackingVerfahren, wie beispielsweise der Einsatz von shadow memory [NS06]. TaintDroidhingegen speichert taint tags angrenzend zu den echten Daten im Speicherbereichder Dalvik VM. Innerhalb der Dalvik VM werden funf verschiedene Typen von Va-riablen unterschieden. Zu jeder Variable wird ein 32-bit großer Bitvektor als taint tag

KAPITEL 4. TAINTDROID 17

gespeichert. Dieser bietet die Moglichkeit zur Unterscheidung von 32 verschiedenenArten von sensitiven Daten. Die verschiedenen Variablentypen lauten:

a. lokale Variablen von Methoden,

b. Methodenparameter,

c. statische Felder von Klassen,

d. Felder von Objektinstanzen und

e. Arrays.

Die Variablentypen a und b werden von der Dalvik VM auf einem internen Stackgespeichert. Fur die Speicherung von taint tags allokiert TaintDroid bei jedem Me-thodenaufruf die doppelte Große an Stackspeicher. Somit liest ein Register r derDalvik VM (siehe Kapitel 2.2), welches eine Variable fruher an Stelle i ausgelesenhat, bei TaintDroid die Variable von Stelle 2 ∗ i aus. Dies bedeutet, dass nach jedergespeicherten Variable auf dem Stack, der dazugehorige taint tag folgt. Das beschrie-bene Konzept wird in Abbildung 4.3 visualisiert.Taint tags zu den Variablen vom Typ c bis e werden angrenzend in der internenSpeicherstruktur der Dalvik VM gespeichert. Dazu ist zu bemerken, dass aus Hin-sicht auf die Performance und Speicheroptimierung, fur Arrays beliebiger Große nurein taint tag gespeichert wird. Dies kann zu einem overtainting (siehe Kapitel 3) derim Array enthaltenen Daten fuhren.

Abbildung 4.3: Speicherung der taint tags im Stack fur interpretierte Programme in derDalvik VM (Interpreted Targets), sowie fur nativ ausgefuhrten Programmcode (NativeTargets). [Enc+10]

18 4.2. ARCHITEKTUR VON TAINTDROID

4.2.2 Taint propagation von nativem Code (Method-level tracking)

Das Method-level tracking implementiert die Verbreitung von taint tags auf der Aus-fuhrungsebene von nativem Programmcode. Grundsatzlich wird in TaintDroid nati-ver Code wahrend der Ausfuhrung nicht uberwacht, wie es bei interpretiertem Codein der Dalvik VM der Fall ist (siehe Kapitel 4.2.1). Stattdessen werden Anderungenan den Methoden zum Auruf des nativen Codes vorgenommen. Dazu wird der nativeCode in zwei unterschiedliche Bereiche unterteilt, in interne Methoden der virtuellenMaschine, sowie in Methoden die uber das JNI aufgerufen werden.Interne Methoden der VM nutzen einen seperaten Stack. Dieser ist in Abbildung 4.3unter

”Native Targets“ dargestellt. Diese Methoden besitzen neben einem Pointer

zu den Methodenparameter auch einen weiteren Pointer fur den return-Wert. VM-interne Methoden wie System.arraycopy() wurden um die Nutzung der im Stackgespeicherten taint tags, fur taint propagation, gepatcht und erweitert.Fur Methoden, die uber JNI ausgefuhrt werden, wurde fur TaintDroid die JNI callbridge1 so modifiziert, dass sie ebenfalls taint propagation unterstutzt. Um feststel-len zu konnen wann taint tags in nativen Methoden weitergegeben werden mussen,setzt TaintDroid bisher eine Heuristik ein. Diese sieht vor, dass bei JNI Metho-den, die nur mit primitiven Datentypen und String als Methodenparameter sowieRuckgabewerten arbeitet, die taint tags als Vereinigung aller in den Parameter undreturn-Wert vorhanden tags gesetzt wird [Enc+10, S.7]. Andere Methoden, die bei-spielsweise Objekte als Parameter einsetzen werden bisher nicht unterstutzt. Daherbesteht die Moglichkeit des undertaintings.

4.2.3 Taint propagation bei IPC (Message-level tracking)

Das Betriebssystem Android sieht die Moglichkeit vor, dass Applikationen unterein-ander kommunizieren und Daten austauschen konnen. Innerhalb von Android wirdjede App in einer eigenen Instanz der Dalvik VM ausgefuhrt (siehe Kapitel 2.2).Die Kommunikation untereinander geschieht mittels einer von Google angepasstenVersion des IPC-Binders OpenBinder [Inc]. Um sicherzustellen, dass taint tags vonDaten auch bei der Kommunikation zwischen Apps erhalten bleiben, implementiertTaintDroid ein eigenes tracking level, das Message-level tracking. Hierbei wird dieMessage, die per IPC-Binder an die empfangende App verschickt wird, mit einemtaint tag markiert, welcher der Vereinigung der taint tags der zu versendenden Datenentspricht. Beim Empfang und der Verarbeitung der Message, werden alle versen-deten Daten mit dem entsprechenden taint tag in der VM-Instanz der EmpfangerApp versehen.Dieses Vorgehen kann zu einem overtainting fuhren.

4.2.4 Sekundarspeicher taint propagation (File-level tracking)

Taint tags sollen uber den gesamten Informationsfluss von taint source bis zur taintsink an den Daten erhalten bleiben. Daher implementiert TaintDroid ein eigenes

1Bei der JNI call bridge handelt es sich um den Aufruf der Schnittstelle JNI aus der Dalvik VMheraus.

KAPITEL 4. TAINTDROID 19

taint tracking Level fur Sekundarspeicher, das File-level tracking. Dieses sieht vor,dass fur jede Datei im Sekundarspeicher taint tags festgelegt werden konnen. Wer-den markierte Daten von einer App in eine Datei geschrieben, werden ihre taint tagsauch der Datei zugeordnet. TaintDroid speichert fur jede Datei nur einen einzigentaint tag. Im umgekehrten Fall wird beim Lesen aus einer mit einem taint tag mar-kierten Datei der taint tag auf die Daten ubertragen.Durch die Einschrankung auf ein einzelnes taint tag pro Datei besteht die Gefahr desovertaintings, da beim Auslesen der Datei alle Daten mit dem taint tag der Dateimarkiert werden.

Zur Realisierung des File-level tracking wurde das Android Dateisystem YAFFS2[Ltd] um Attribute zur Speicherung der taint tags erweitert [Enc+10, S.7].

4.3 Benchmark

TaintDroid nimmt zur Umsetzung des Dynamic Taint Tracking Verfahrens in An-droid diverse Modifikationen im Android System vor (siehe Kapitel 4.2). Die Modifi-kationen betreffen zentrale Stellen des Androidsystems, wie Systembibliotheken vonAndroid, oder das Speicherlayout in der Dalvik VM. Dies hat zur Folge, dass dieentsprechenden Modifikationen bei Ausfuhrung oft durchlaufen werden und einenOverhead erzeugen. Die Abbildung 4.4 zeigt eine Ubersicht einzelner Operationenin Android und den durch TaintDroid generierten Overhead. Nach einem Bench-mark aus [Enc+10] erzeugt TaintDroid insgesamt einen zusatzlichen Overhead von14% in der Laufzeit und 3,5% beim Speicherverbrauch.

Abbildung 4.4: Overhead von TaintDroid bei einzelnen Operationen in Android.

4.4 Fallstudie

In [Enc+10] wurde eine Fallstudie mit TaintDroid durchgefuhrt, um die Fahigkeitenvon TaintDroid zu demonstrieren und zu analysieren. Dazu wurde, mit Hilfe vonTaintDroid, das Verhalten von 30 popularen Apps aus dem Android Market2 beimUmgang mit privaten Nutzerdaten untersucht.Fur die Fallstudie wurden aus den 50 beliebtesten Apps im Android Market 30 Ap-ps ausgesucht, die neben der Permission zum Zugriff auf den Internetzugang desSmartphones, auch Zugriff auf private Daten, wie den Standort und den Telefon-status, sowie Zugriff zur Steuerung der Kamera und die Moglichkeit zur Aufnahme

2Mittlerweile unter dem Namen Google Play bekannt.

20 4.4. FALLSTUDIE

von Audiosignalen, anfragten. Die Abbildung 4.5 gibt einen Uberblick uber die 30ausgewahlten Apps und ihre Berechtigungen.

Zur Untersuchung der Apps wurden diese auf ein Android Smartphone installiert, aufdem eine mit TaintDroid erweiterte Android Version 2.1 installiert war. Des Weite-ren wurden, sofern von der App gefordert, vorgesehene Registrierungen durchgefuhrtund letztendlich die Funktionen der einzelnen Apps ausgefuhrt. Zur Verifizierung derErgebnisse von TaintDroid wurde der gesamte Netzwerkverkehr mitgeschnitten undebenfalls analysiert. Bei dieser Untersuchung stellte TaintDroid unterschiedlichenMissbrauch der privaten Nutzerdaten durch einige der untersuchten Apps fest. DieErgebnisse der Untersuchung sind in der Abbildung 4.6 festgehalten. So versende-ten zwei der untersuchten Apps die Telefonnummer, die IMSI (International MobileSubscriber Identity), sowie die ICC-ID (Integrated Circuit Card - IDentifier) desSmartphones an eigene Server der App Entwickler. Die IMSI ist eine eindeutigeNummer in GSM- und UMTS-Mobilfunknetzen und dient zur eindeutigen Identifi-zierung eines Netzteilnehmers. Bei der ICC-ID handelt es sich um die Seriennummervon SIM Karten. Der Nutzer wird zu keiner Zeit der Verwendung der beiden Appsuber dieses Verhalten informiert. Des Weiteren stellte TaintDroid fest, dass siebenApps die IMEI (International Mobile Station Equipment Identity) des Smartphonesauslesen und an eigene Server versenden. Die IMEI wird zur eindeutigen Identifizie-rung des Smartphones im mobilen Netz genutzt.Den Missbrauch der Standortdaten des Smartphones konnte TaintDroid in 15 Fallenfeststellen. In allen Fallen versendeten die betroffenen Apps den Standort an Servervon bekannte Firmen, die Werbung in Apps einblenden lassen. Auch hier wird derNutzer bei keiner der 15 Apps uber dieses Verhalten informiert. Bei der Ubertra-gung der Standortdaten zeigt sich ein wichtiger Vorteil von TaintDroid gegenuberAnsatzen, die nur nach bestimmten Pattern in ausgehenden Paketen suchen. Soversendeten vier der 15 Apps den Standort in einem nicht einsehbaren speziellenbinar-Format. Durch die Verwendung von Dynamic Taint Tracking war TaintDroidin der Lage die Standortdaten zu erkennen, wahrend ein Paketscan gescheitert ware[Enc+10, S. 10].

Insgesamt konnte durch den Einsatz von TaintDroid erfolgreich bosartiges Verhal-ten bei einem Teil der 30 untersuchten Apps beim Umgang mit privaten Datenfestgestellt werden.

KAPITEL 4. TAINTDROID 21

Abbildung 4.5: Die in der Fallstudie aus [Enc+10] mit TaintDroid untersuchten Appsund ihre angeforderten Permissions.(L = Standort, C = Kamera, A = Audiosignal aufnehmen, P = Telefonstatus)

Abbildung 4.6: Von TaintDroid festgesteller Missbrauch von privaten Daten [Enc+10].

22 4.4. FALLSTUDIE

KAPITEL 5. RELATED WORK 23

5 Related Work

Neben der in Kapitel 4 vorgestellten Android Erweiterung TaintDroid zur Erkennungdes Missbrauchs von privaten Nutzerdaten durch Applikationen, existieren weitereAnsatze, die sich ebenfalls diesem Thema widmen. So bieten das Saint-Framework[Ong+12] sowie das Konzept Security-by-Contract [Des+08] erweiterte Uberpru-fungen der Einhaltung von Zugriffsbeschrankungen auf private Daten fur AndroidSmartphones beziehungsweise fur Windows Mobile Phones. Gegenuber TaintDroidsAnsatz findet jedoch in beiden Fallen keine weitere Verfolgung von privaten Infor-mationen statt, sobald diese in eine Applikation gelangt sind.Mit PiOS [Ege+11] existiert ebenfalls fur das mobile Betriebssystem iOS von Appleein Programm zum besseren Schutz der privaten Daten. Im Gegensatz zu TaintDro-id nutzt PiOS dafur einen anderen Ansatz. PiOS fuhrt eine statische Analyse aufdekompilierten Binarcode von Applikationen aus und generiert daraus Kontrollfluss-graphen. Mit dessen Hilfe ist PiOS in der Lage potentiellen Missbrauch von privatenDaten festzustellen. Im Vergleich zu TaintDroid ist damit jedoch keine Kontrolle inEchtzeit moglich.

Daruber hinaus existieren neben der Erkennung des Missbrauches von privaten Da-ten auch Moglichkeiten um praventiv dagegen vorzugehen. Dies konnen beispielswei-se Apps wie Anti-Viren Scanner sein, die bosartige Apps wie Malware (siehe Kapitel1) direkt nach der Installation erkennen oder Firewalls, die ein- beziehungsweiseausgehende Internetkommunikation regeln. Ein Uberblick uber Applikationen vondiesen Typen fur die mobilen Betriebssysteme Android, iOS und Windows MobilePhone wird in [AL12] gegeben.

24

KAPITEL 6. FAZIT 25

6 Fazit

In dieser Arbeit wurde mit TaintDroid eine Moglichkeit fur Nutzer von AndroidSmartphones vorgestellt Applikationen beim Umgang mit privaten Daten zu uber-wachen. Damit erweitert TaintDroid das mobile Betriebssystem Android um eineFunktion, wozu das Sicherheitskonzept von Android in der Standardausfuhrung nichtin der Lage ist (siehe Kapitel 2.1), das Erkennen des Missbrauchs von privaten Da-ten durch bosartige Apps in Echtzeit, wie beispielsweise Grayware (siehe Kapitel1). Dies gelingt TaintDroid durch die Implementierung des Dynamic Taint TrackingVerfahrens (siehe Kapitel 3) in das Androidsystem. Dabei generiert TaintDroid nureinen geringen Overhead in der Ausfuhrung gegenuber einem unmodifizierten An-droidsystem.Nachteile des von TaintDroid gewahlten Verfahrens ist die fehlende Erkennung vonKontrollflussen. Dadurch besteht die Gefahr, dass Apps durch Einsatz von Kontroll-flusstechniken private Daten des Nutzers, von TaintDroid unbemerkt, nach außentragen konnen. Somit gibt TaintDroid keine hunderprozentige Garantie zur Erken-nung des Missbrauches von privaten Daten. Des Weiteren besteht bei TaintDroideine geringe Chance von Falschmeldungen, die durch mogliches over- sowie under-tainting bei der Implementierung der Taint Propagation einhergehen (siehe Kapitel4.2). Zudem ist TaintDroid nur fur technisch versierte Smartphone Nutzer zugang-lich, da die tiefgreifenden Modifikationen des Androidsystems durch TaintDroid einekomplette Neuinstallation des Systems notwendig machen.

Trotz der erwahnten Nachteile ist TaintDroid ein guter Ansatz zum Schutz vonprivaten Nutzerdaten in Smartphones und zeigt zusammen mit der Fallstudie aus[Enc+10] (siehe Kapitel 4.4) den Bedarf solcher Software, welcher bei der steigendenVerbreitung von Smartphones noch weiter zunehmen wird.

26

LITERATUR 27

Literatur

[AL12] Benjamin Adolphi und Hanno Langweg.”Security Add-Ons for Mobile

Platforms“. In: Secure IT Systems. Hrsg. von Audun Jøsang und BengtCarlsson. Bd. 7617. Lecture Notes in Computer Science. Springer BerlinHeidelberg, 2012, S. 17–30. isbn: 978-3-642-34209-7. doi: 10.1007/978-3-642-34210-3_2. url: http://dx.doi.org/10.1007/978-3-642-34210-3_2.

[Alla] Open Handset Alliance. Android Security Overview. url: http : / /

source.android.com/devices/tech/security/index.html (besuchtam 29. 11. 2013).

[Allb] Open Handset Alliance. Open Handset Alliance. url: http://www.

openhandsetalliance.com (besucht am 24. 11. 2013).

[App] Apple. iOS. url: https : / / www . apple . com / de / ios (besucht am24. 11. 2013).

[Bit] Bitkom. Neuer Rekord bei Smartphones. url: http://www.bitkom.org/77351_77345.aspx (besucht am 15. 12. 2013).

[Bor08] Dan Bornstein.”Dalvik VM Internals“. In: Google IO Conference. 208.

[Cos+07] Manuel Costa u. a.”Bouncer: Securing Software by Blocking Bad Input“.

In: SIGOPS Oper. Syst. Rev. 41.6 (Okt. 2007), S. 117–130. issn: 0163-5980. doi: 10.1145/1323293.1294274. url: http://doi.acm.org/10.1145/1323293.1294274.

[Des+08] Lieven Desmet u. a.”Security-by-contract on the .NET Platform“. In:

Inf. Secur. Tech. Rep. 13.1 (Jan. 2008), S. 25–32. issn: 1363-4127. doi:10.1016/j.istr.2008.02.001. url: http://dx.doi.org/10.1016/j.istr.2008.02.001.

[Ege+11] M. Egele u. a.”PiOS: Detecting Privacy Leaks in iOS Applications“. In:

Proceedings of the Network and Distributed System Security Symposium(NDSS). San Diego, CA, Feb. 2011.

[Enc+10] William Enck u. a.”TaintDroid: an information-flow tracking system for

realtime privacy monitoring on smartphones“. In: Proceedings of the 9thUSENIX conference on Operating systems design and implementation.OSDI’10. Vancouver, BC, Canada: USENIX Association, 2010, S. 1–6.url: http://dl.acm.org/citation.cfm?id=1924943.1924971.

[Enc+11] William Enck u. a.”A study of Android application security“. In: In

Proc. USENIX Security Symposium. 2011.

28 LITERATUR

[Fel+11a] Adrienne Porter Felt u. a.”A survey of mobile malware in the wild“. In:

Proceedings of the 1st ACM workshop on Security and privacy in smart-phones and mobile devices. SPSM ’11. Chicago, Illinois, USA: ACM,2011, S. 3–14. isbn: 978-1-4503-1000-0. doi: 10.1145/2046614.2046618.url: http://doi.acm.org/10.1145/2046614.2046618.

[Fel+11b] Adrienne Porter Felt u. a.”Android Permissions Demystified“. In: Pro-

ceedings of the 18th ACM Conference on Computer and Communica-tions Security. CCS ’11. Chicago, Illinois, USA: ACM, 2011, S. 627–638. isbn: 978-1-4503-0948-6. doi: 10.1145/2046707.2046779. url:http://doi.acm.org/10.1145/2046707.2046779.

[Fel+12] Adrienne Porter Felt u. a.”Android permissions: user attention, compre-

hension, and behavior“. In: Proceedings of the Eighth Symposium on Usa-ble Privacy and Security. SOUPS ’12. Washington, D.C.: ACM, 2012,3:1–3:14. isbn: 978-1-4503-1532-6. doi: 10.1145/2335356.2335360.url: http://doi.acm.org/10.1145/2335356.2335360.

[Gar] Gartner. Worldwide Mobile Phone Sales. url: https://www.gartner.com/newsroom/id/2623415 (besucht am 24. 11. 2013).

[Gooa] Google. Android Developers Homepage. url: http://developer.android.com (besucht am 10. 11. 2013).

[Goob] Google. Google Play Store. url: https://play.google.com/store(besucht am 12. 15. 2013).

[Inc] Palmsource Inc. OpenBinder. url: http://www.angryredplanet.com/~hackbod/openbinder/docs/html/ (besucht am 15. 12. 2013).

[Ltd] Aleph One Ltd. Yet Another Flash File System. url: http://www.

yaffs.net/ (besucht am 15. 12. 2013).

[Mic] Microsoft. Windows Phone. url: http://www.windowsphone.com/de-DE (besucht am 24. 11. 2013).

[NS06] James Newsome und Dawn Xiaodong Song.”Dynamic Taint Analysis for

Automatic Detection, Analysis, and SignatureGeneration of Exploits onCommodity Software.“ In: NDSS. The Internet Society, 23. Feb. 2006.isbn: 1-891562-19-3. url: http://dblp.uni- trier.de/db/conf/

ndss/ndss2005.html#NewsomeS05.

[Ong+12] Machigar Ongtang u. a.”Semantically rich application-centric security

in Android“. In: Sec. and Commun. Netw. 5.6 (Juni 2012), S. 658–673.issn: 1939-0114. doi: 10.1002/sec.360. url: http://dx.doi.org/10.1002/sec.360.

[Onl] heise Online. Millionenfach installierte Android App schnueffelte Nut-zerdaten aus. url: http : / / www . heise . de / security / meldung /

Millionenfach-installierte-Android-App-schnueffelte-Nutzerdaten-

aus-2062105.html (besucht am 07. 12. 2013).

LITERATUR 29

[SAB10] Edward J. Schwartz, Thanassis Avgerinos und David Brumley.”All You

Ever Wanted to Know about Dynamic Taint Analysis and Forward Sym-bolic Execution (but Might Have Been Afraid to Ask)“. In: Proceedingsof the 2010 IEEE Symposium on Security and Privacy. SP ’10. Wa-shington, DC, USA: IEEE Computer Society, 2010, S. 317–331. isbn:978-0-7695-4035-1. doi: 10.1109/SP.2010.26. url: http://dx.doi.org/10.1109/SP.2010.26.

[VCC11] Timothy Vidas, Nicolas Christin und Lorrie Faith Cranor.”Curbing An-

droid Permission Creep“. In: In W2SP. 2011.

[VVC11] Timothy Vidas, Daniel Votipka und Nicolas Christin.”All Your Droid

Are Belong to Us: A Survey of Current Android Attacks“. In: Proceedingsof the 5th USENIX Conference on Offensive Technologies. WOOT’11.San Francisco, CA: USENIX Association, 2011, S. 10–10. url: http://dl.acm.org/citation.cfm?id=2028052.2028062.