Seminararbeit

Sicherheit vonAndroid-Applikationen

Florian Will27. Januar 2014

Gutachter: Prof. Dr. Jan JurjensDipl.-Inform. 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 Willflorian.will@udo.eduMatrikelnummer: 136951Studiengang: Master Informatik

Seminar Sicherheit und SoftwareengineeringThema: Sicherheit von Android-Applikationen

Eingereicht: 27. 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 27. Januar 2014

Florian Will

iv

INHALTSVERZEICHNIS v

Inhaltsverzeichnis

Abbildungsverzeichnis vii

1 Einleitung 1

2 Grundlagen 32.1 Android-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Dalvik VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Android-Applikationsformat . . . . . . . . . . . . . . . . . . . . . . . 62.4 Android-Berechtigungsmodell . . . . . . . . . . . . . . . . . . . . . . 62.5 Kommunikation zwischen Applikationen . . . . . . . . . . . . . . . . 7

3 Fallbeispiele: Sicherheitslucken in Android 93.1 Umgehen der APK-Signaturprufung . . . . . . . . . . . . . . . . . . . 93.2 Erschleichen von In-App-Kaufen . . . . . . . . . . . . . . . . . . . . . 103.3 Ungewollte Ausfuhrung von USSD-Codes . . . . . . . . . . . . . . . . 11

4 Analyse der Sicherheit von Android-Applikationen 134.1 Allgemeine Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.1.1 Dekompilierung von Anwendungen . . . . . . . . . . . . . . . 134.1.2 Analyse des Programmcodes . . . . . . . . . . . . . . . . . . . 144.1.3 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2 Untersuchung der Kommunikation zwischen Applikationen . . . . . . 164.2.1 Moglichkeiten fur Angriffe auf Intent-Basis . . . . . . . . . . . 164.2.2 Auffinden potenzieller Schwachstellen . . . . . . . . . . . . . . 174.2.3 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5 Fazit 19

Literaturverzeichnis 21

vi INHALTSVERZEICHNIS

ABBILDUNGSVERZEICHNIS vii

Abbildungsverzeichnis

2.1 Architekturubersicht fur Android . . . . . . . . . . . . . . . . . . . . 42.2 Inhalt einer .apk -Datei . . . . . . . . . . . . . . . . . . . . . . . . . . 7

viii ABBILDUNGSVERZEICHNIS

KAPITEL 1. EINLEITUNG 1

1 Einleitung

Die Sicherheit von Android-Anwendungen gewinnt an Bedeutung, seit Mobilgeratemit dem von Google entwickelten Betriebssystem den Alltag immer mehr durchdrin-gen und fur immer vielfaltigere Zwecke eingesetzt werden. Nachdem Smartphoneszunachst hauptsachlich fur Tatigkeiten wie Telefonate, die Verwaltung von E-Mailsund SMS, das Surfen im Internet oder das Musikhoren eingesetzt wurden, gibt esinzwischen fur fast jeden Verwendungszweck eine spezielle Anwendung.

Was dabei schnell in Vergessenheit gerat, ist die Tatsache, dass jede Anwendung auchein Sicherheitsrisiko darstellt und mit jeder App-Installation Vertrauen in einen Her-steller gesetzt wird, der oft kaum bekannt ist. Zwar bietet Android Mechanismen,die mogliche Gefahren durch die starke Beschrankung der einer Anwendung zurVerfugung stehenden Aktionen reduzieren, doch auch unter Berucksichtigung die-ses Berechtigungssystems konnen Daten ausgespaht, Informationen gesammelt undfinanzieller Schaden angerichtet werden. Ist der Nutzer bei der Installation nicht auf-merksam, wird einer vermeintlich harmlosen Anwendung schnell der Zugriff auf dieDaten der personlichen Kontakte, den aktuellen Aufenthaltsort oder die Funktionfur das Senden von kostenpflichtigen Premium-SMS eingeraumt.

Doch selbst wenn grundlich gepruft wird, welche Zugriffsrechte bei der Installationangefordert werden, ist kein Schutz vor Angriffen uber Sicherheitslucken in And-roid selbst gewahrleistet. Weil fur altere Gerate haufig keine Versorgung mehr mitSicherheitsaktualisierungen fur Android sichergestellt ist, konnen schadliche Anwen-dungen bekannte Lucken haufig noch auf diesen Geraten ausnutzen, obwohl sie inaktuellen Android-Versionen bereits behoben wurden.

Eine Moglichkeit, das Risiko fur Android-Nutzer trotz dieser Umstande zu senken,wird von Google im zentralen App-Marktplatz Play Store genutzt: Neu eingestell-te Anwendungen oder Aktualisierungen werden vor der Veroffentlichung durch denBouncer [Loc12] auf schadliches Verhalten gepruft. Eine solche Prufung kann bei-spielsweise feststellen, ob im Programmcode der Anwendung eine der bekanntenAndroid-Lucken ausgenutzt wird und gegebenenfalls die Freischaltung verweigern.

Im Rahmen dieser Ausarbeitung sollen Moglichkeiten fur die Analyse fremder undeigener Anwendungen unter Sicherheitsaspekten betrachtet und eine Vorstellung vonden unter Android durch Sicherheitslucken verursachten Gefahren geschaffen wer-den. Die fur das Verstandnis erforderlichen Grundlagenkenntnisse zu Android werdenin Kapitel 2 behandelt. Um exemplarisch einige mogliche Auswirkungen der Installa-tion schadlicher Anwendungen zu beleuchten, die Lucken in Android ausnutzen, umuber die ihnen eigentlich zugeteilten Rechte hinauszugehen, stellt Kapitel 3 einigesolcher Sicherheitslocher vor. Schließlich fuhrt Kapitel 4 Moglichkeiten auf, um mit

2

der Unterstutzung von Software-Werkzeugen eine Bewertung der Schadlichkeit belie-biger Android-Applikationen vornehmen zu konnen oder Fehler darin aufzudecken,die zu einer Schwachung der Sicherheit fuhren.

KAPITEL 2. GRUNDLAGEN 3

2 Grundlagen

Die Abschnitte dieses Kapitels sollen einen Uberblick uber die grundlegenden Kennt-nisse vermitteln, die fur das Verstandnis der nachfolgenden Kapitel 3 und 4 erfor-derlich sind. Daher wird auf die Architektur von Android, die Struktur und Ausfuh-rungsumgebung von Anwendungen sowie die in Android ubliche Form der Kommu-nikation zwischen Applikationen mittels Intents eingegangen.

2.1 Android-Architektur

Obwohl Android auf dem Linux-Kernel als Betriebssystemkern basiert, unterscheidetsich die Architektur des Systems [Arch] deutlich von Linux-Distributionen, die aufklassische Arbeitsplatzrechner zugeschnitten sind. Die Topologie mit einigen ausge-wahlten Komponenten ist in Abbildung 2.1 dargestellt und wird in diesem Abschnittgrob beschrieben.

Der Linux-Kernel bildet die Basis von Android. Es werden einige von Google ent-wickelte Kernelkomponenten benotigt, die im Hauptentwicklungszweig von Linuxderzeit nicht enthalten sind. Ein entsprechend erweiterter Linux-Kernel wird daherauch als Android-Kernel bezeichnet. Im Kernel fur ein Android-Gerat sind auchTreiber fur die verschiedenen Hardwarelemente wie Kamera, Audiochip und Gra-fikeinheit des Gerats angesiedelt. Jeder Geratehersteller kann Kerneltreiber beliebigimplementieren oder bereits vorhandenen Treibercode einsetzen. Damit jedoch bei-spielsweise der Kamerazugriff nicht fur jedes Gerat beziehungsweise dessen Treiberneu angepasst werden muss, existieren verschiedene Hardware Abstraction Layer(HAL) in einer Schicht zwischen Kernel und Systemdiensten. Es handelt sich da-bei jeweils um eine von Google vorgegebene Schnittstelle, die von Gerateherstellernimplementiert werden muss. [Arch]

Eine Ebene hoher sind die Systemdienste von Android angesiedelt. Diese nutzendie Schnittstellen der HAL aus der Ebene darunter und stellen damit grundlegendeFunktionen wie Moglichkeiten zur Audiowiedergabe und die Verwaltung der Kamerazur Verfugung. Auf dieser Ebene ist ein Großteil des Zugriffsschutzes fur Anwen-dungen implementiert, so dass nur berechtigte Anwendungen beispielsweise auf dieKamerabilder zugreifen konnen (siehe Abschnitt 2.4). [Arch]

Mit Binder wird die systemweite Inter-Prozess-Kommunikation abgewickelt: Sowohldie Verbindung zwischen Applikationen und Systemdiensten als auch der Nachrich-tenaustausch von Applikationen untereinander erfolgt daruber. Bei der Inter-Appli-kations-Kommunikation werden dafur Intents eingesetzt, auf die in Abschnitt 2.5eingegangen wird. [Arch]

4 2.1. ANDROID-ARCHITEKTUR

Abbildung 2.1: Architekturubersicht fur Android (Abbildung entnommen aus [Arch])

KAPITEL 2. GRUNDLAGEN 5

Auf der obersten Abstraktionsschicht finden sich schließlich die Android-Applikatio-nen und das zugehorige Applikations-Framework, welches den Anwendungen Zugriffauf die Systemdienste ermoglicht. Diese Ebene ist in Java implementiert und wirdaktuell durch die Laufzeitumgebung Dalvik (siehe Abschnitt 2.2) ausgefuhrt. DasDateiformat einer Android-Anwendung ist in Abschnitt 2.3 dargestellt. [Arch]

2.2 Dalvik VM

Auf Arbeitsplatzrechnern wird fur die Ausfuhrung von Java-Bytecode ublicherweisedie Java Virtual Machine (JVM) eingesetzt. Google nutzt speziell fur die Zweckevon Android jedoch eine eigene Java-Ausfuhrungsumgebung namens Dalvik. Diesevirtuelle Maschine soll einige Anforderungen erfullen [Bor08]:

• Die Ausfuhrung findet auf einer langsamen CPU statt

• Es steht nur wenig Arbeitsspeicher zur Verfugung (ursprunglich waren fursamtliche Apps insgesamt nur 20 MB vorhanden)

• Das Betriebssystem nutzt keine Speicherseiten-Auslagerung (Swap)

• Die Energieversorgung des Systems erfolgt uber eine Batterie

Um diese Einschrankungen besser berucksichtigen zu konnen, weicht Dalvik vom an-sonsten ublichen Format kompilierter Java-Dateien ab. Statt jede Java-Klasse in eine.class-Datei zu ubersetzen und diese dann als getrennte Dateien in einem .jar -Ar-chiv zusammenzufassen, werden die Java-Klassen einer Applikation nach der Kom-pilierung in nur einer einzelnen .dex -Datei zusammengefasst. Dies ermoglicht dieNutzung eines fur alle Klassen gemeinsamen Pools von konstanten Strings, Typen-bezeichnern, Methodenbezeichnern und weiteren konstanten Daten, die ansonsten injeder .class-Datei enthalten sein mussten. Ein von Google durchgefuhrter Vergleichkommt zu dem Ergebnis, dass .dex -Dateien in der Regel weniger als die Halfte desfur ein entsprechendes .jar -Archiv benotigten Speicherplatzes in Anspruch nehmen.Selbst komprimierte .jar -Dateien waren bei diesem Vergleich noch großer als un-komprimierte .dex -Dateien. [Bor08]Ein weiterer Unterschied zwischen der JVM und Dalvik besteht im Format des Byte-codes, der ausgefuhrt werden kann. Die Instruktionen, die durch die JVM verarbeitetwerden konnen, entsprechen ungefahr dem Modell eines Kellerautomaten: Operatio-nen wie die Addition besitzen keine Parameter, denn ihre Operanden werden implizitauf dem Stack ubergeben und dort wird auch das Ergebnis abgelegt [Lin+13, Ab-schnitt 2.6.2,

”Operand Stacks“]. Im Gegensatz dazu nutzt Dalvik das Modell einer

Registermaschine mit virtuellen Registern, bei der in jeder Instruktion die Ein- undAusgaberegister explizit angegeben werden. Dadurch kann laut Google die Anzahlder Instruktionen um 30% gesenkt werden, wahrend jedoch 35% mehr Speicherplatzfur die Kodierung der Instruktionen benotigt wird. Da jedoch bei der Ausfuhrungfur jede Instruktion ein gewisser zusatzlicher Verarbeitungsaufwand anfallt, fuhrtdie Reduzierung der Zahl von Instruktionen zu einer schnelleren Ausfuhrung derProgramme. Dalvik-Bytecode hat also gegenuber JVM-Bytecode die Eigenschaft,die Ausfuhrungsgeschwindigkeit auf Kosten des Speicherbedarfs zu verbessern. In

6 2.3. ANDROID-APPLIKATIONSFORMAT

der Summe betrachtet wird jedoch durch die Verwendung nur eines einzigen Kon-stantenpools (s.o.) mehr Speicherplatz eingespart als durch die Nutzung des wenigerspeicherplatzeffizienten Bytecodes zusatzlich in Anspruch genommen wird. [Bor08]

2.3 Android-Applikationsformat

Android-Anwendungen werden als .apk -Datei (Android Application Package [Glo])gespeichert, wobei es sich um ein Dateiarchiv aus mehreren Dateien handelt. Die In-halte des Dateiarchivs sind in Abbildung 2.2 dargestellt. Wie daraus ersichtlich ist,enthalt es die in Abschnitt 2.2 beschriebene .dex -Datei mit dem Code der Anwen-dung in kompilierter Form. Falls die Anwendung auf Bibliotheken zuruckgreift, istder Code jeder Bibliothek in Form einer weiteren .dex -Datei im Archiv eingebettet.Außerdem sind die bei der Ausfuhrung benotigten Ressourcen wie Bilddateien oderUbersetzungen der Texte enthalten. [APK]

Interessant ist die Datei AndroidManifest.xml des Applikations-Archivs. Im And-roidmanifest muss deklariert werden, aus welchen Activities1, Hintergrunddiensten,Kommunikationsschnittstellen und sonstigen Elementen die Anwendung zusammen-gesetzt ist und wo sich die Implementierungen dazu jeweils im Code befinden. [Man]

Nach der Erstellung muss eine .apk -Datei durch das Werkzeug jarsigner, das ur-sprunglich fur gewohnliche .jar -Dateien entwickelt worden ist, signiert werden, da-mit es auf einem Gerat installiert werden kann. Durch diesen Mechanismus wirdauf dem Gerat sichergestellt, dass beispielsweise ein Update fur die Musikplayer-Applikation nur dann installiert werden kann, wenn dessen Signaturschlussel mitdem der bereits vorhandenen Musikplayer-Applikation ubereinstimmt und die Si-gnatur erfolgreich gepruft wurde. Es ist somit nicht moglich, eine Anwendung durcheine Falschung zu ersetzen, ohne im Besitz des privaten Schlussels des Anwendungs-Herstellers zu sein. [Sign]

2.4 Android-Berechtigungsmodell

Unter Android existiert ein Berechtigungsmodell [Fel+11], durch das eine Beschran-kung der Aktionen, die einer Anwendung gestattet sind, erzwungen wird. Grund-satzlich darf eine Anwendung nur auf Dateien zugreifen, die von ihr selbst erzeugtwurden, um das Ausspahen der Daten anderer Anwendungen zu verhindern. Auchder Zugriff auf die Hardware ist zunachst stark begrenzt, so ist beispielsweise keinZugriff auf das Internet oder Sensoren wie Kamera oder Kompass moglich.

Eine Applikation erhalt nur dann Zugriff auf eine potenziell sicherheits- oder daten-schutzrelevante Funktion, wenn in der Datei AndroidManifest.xml deklariert wurde,dass diese Funktion benotigt wird. Bei der Installation einer Anwendung wird ei-ne Liste aller solcher Zugriffsberechtigungen angezeigt, die durch die Applikationangefordert werden, und es kann daraufhin entschieden werden, ob mit der Instal-lation fortgefahren werden soll. Besonders kritische Berechtigungen durfen nur vonAnwendungen angefordert werden, die mit dem Schlussel des Gerateherstellers si-

1Eine Activity entspricht in Android ungefahr einem Fenster mit den dazugehorigen Nutzer-funktionen bei Arbeitsplatzrechnern

KAPITEL 2. GRUNDLAGEN 7

Abbildung 2.2: Inhalt einer .apk -Datei (Abbildung extrahiert aus [APK])

gniert wurden. Damit sind sie in der Regel vorinstallierten Applikationen wie denSystemeinstellungen vorbehalten. [Fel+11]

Technisch umgesetzt werden diese Beschrankungen großtenteils durch eine Uberpru-fung bei der Ausfuhrung von Funktionen innerhalb der Systemdienste in Android.Wird beispielsweise die Schnittstellenfunktion fur die Aufnahme eines Fotos im Java-Code einer Anwendung aufgerufen, so kommuniziert die entsprechende Methode desAndroid-Anwendungsframeworks uber Binder mit dem Kamera-Systemdienst. Die-ser pruft, ob die Anwendung die notige Berechtigung in ihrem Manifest angeforderthat, und nimmt daraufhin ein Foto auf oder liefert gegebenenfalls einen Zugriffs-fehler. Einige Berechtigungen, beispielsweise der Internetzugriff oder Zugriff auf dieDateien, die auf der SD-Karte des Telefons gespeichert sind, werden auch uber klas-sische Unix-Nutzergruppen und Dateisystemberechtigungen realisiert. [Fel+11]

2.5 Kommunikation zwischen Applikationen

Android-Anwendungen konnen sich gegenseitig Nachrichten senden, die als Intentbezeichnet werden. Ein Intent ist ein Java-Objekt, das auf verschiedenen Wegen voneinem Sender zu einem oder mehreren Empfangern gelangen kann. So wird der Starteiner Activity (entspricht einem Fenster in klassischen Betriebssystemen) stets da-durch ausgelost, dass diese Activity ein Intent empfangt. Falls die Activity zu diesemZeitpunkt noch nicht ausgefuhrt wird, erfolgt der Start dabei transparent durch dasSystem. Die Activity kann in Abhangigkeit vom Inhalt des Intents unterschiedlicheZustande annehmen, beispielsweise angezeigte Eingabefelder mit Vorgabewerten be-legen. Auch Hintergrunddienste werden gestartet, wenn diese ein Intent empfangen,beispielsweise mit einem zu bearbeitenden Auftrag als Inhalt. [Int]

Es gibt zwei verschiedene Arten, auf die Intents an einen einzelnen Empfanger ver-sendet werden konnen. Im ersten Fall wird der Intent als expliziter Intent bezeichnet.Ein solcher zeichnet sich dadurch aus, dass der Komponentenname des Empfangersexplizit vorgegeben ist. Hierbei erfolgt die Zustellung des Intents in jedem Fall anden gewahlten Empfanger. In der Regel sind die Komponentennamen von Activitiesoder Hintergrunddiensten fremder Apps jedoch unbekannt. Soll ein Intent mit demInhalt

”Zeige dieses Video mit dem MIME-Typ video/mpeg an“ gesendet werden,

kann daher kein geeigneter Empfanger angegeben werden, da der Komponentenna-

8 2.5. KOMMUNIKATION ZWISCHEN APPLIKATIONEN

me der Activity des durch den Nutzer bevorzugten Videoplayers unbekannt ist. Furdiesen Zweck existiert die zweite Art von Intents, die als implizite Intents bezeichnetwerden. Diesen wird durch den Sender kein fester Empfanger zugeordnet. Wird einsolcher Intent versendet, werden die Kriterien aller im System registrierten Intent-Filter auf Ubereinstimmung mit dem zu sendenden Intent gepruft. Ergibt diese Su-che keinen Treffer, schlagt das Senden fehl. Gibt es genau einen Treffer, so wird derIntent an die mit dem Filter verknupfte Komponente zugestellt. Werden mehrerepassende Filter gefunden, erhalt der Nutzer die Moglichkeit, eine der Komponen-ten als Empfanger auszuwahlen. Somit ist eine lose Kopplung beim Datenaustauschzwischen Anwendungen uber Intents gewahrleistet. [Int]Eine zusatzliche Moglichkeit fur den Einsatz von Intents sind Broadcasts. Wirdein Broadcast durch das Android-System oder eine Anwendung gesendet, so wirdein Intent an alle speziell dafur registrierten Broadcast-Empfanger zugestellt, fallsdie bei der Registrierung festgelegten Kriterien des Broadcast-Empfangers zu demBroadcast-Intent passen. Dieses Broadcast-System ist unabhangig von den oben be-schriebenen impliziten und expliziten Intents. [Int]

KAPITEL 3. FALLBEISPIELE: SICHERHEITSLUCKEN IN ANDROID 9

3 Fallbeispiele: Sicherheitslucken in Android

Um die Gefahren, die bei der unter Android ublichen Installation und Ausfuhrungvon Applikationen von Drittherstellern auftreten, beurteilen zu konnen, darf nichtnur der Idealzustand betrachtet werden, bei dem das Android-Berechtigungsmodellwie vorgesehen funktioniert. Durch Nachlassigkeiten beim Entwurf oder der Imple-mentierung der verschiedenen Teile von Android kommt es immer wieder zu Sicher-heitslucken, die boswillige Applikations-Entwickler ausnutzen konnten, um eigentlichnicht vorgesehene Wege fur die Verletzung der Privatsphare oder anderweitigen Miss-brauch des Gerats einzuschlagen. Aufgrund der großen Anzahl bisher aufgetauchterLucken kann die Auswahl in diesem Kapitel nur zur Illustration dienen.

3.1 Umgehen der APK-Signaturprufung

Ein Beispiel aus dem Juli 2013 dafur, wie Dritthersteller-Anwendungen Sicherheits-lucken in Android ausnutzen konnen, ist Android Bug 8219321 – von den Entdeckernals

”Master Key“-Lucke bezeichnet [For13]. Diese ermoglicht unter gewissen Umstan-

den das Verandern bereits signierter APK-Dateien, ohne dass dadurch die Signatur-prufung bei der Installation der Anwendung fehlschlagt. Damit wird beispielsweisefremden Applikationen das Deklarieren und Nutzen von Zugriffsberechtigungen, dieeigentlich den Systemanwendungen des Gerateherstellers vorbehalten sind, ermog-licht.

APK-Dateien konnen prinzipiell aufgrund der Abstammung vom ZIP-Format unter-schiedliche Dateien mit identischen Dateinamen und -pfaden enthalten. Die Ursacheder Sicherheitslucke liegt in unterschiedlichen Implementierungen fur das Dekompri-mieren einer solchen APK-Datei mit doppelten Dateinamenseintragen. Es wurdenim Android-Code an mindestens acht verschiedenen Stellen Implementierungen furdie Dekomprimierung gefunden, sowohl in C und C++ als auch in Java. MancheImplementierungen nutzten bei Dateinamenskollisionen stets die erste im APK-Ar-chiv enthaltene Datei des gleichen Namens, andere stets die Letzte. So wurde bei derVerifikation der Signatur von APK-Dateien nur die Signatur der letzten gleichnami-gen Datei gepruft. Gleichzeitig wurde jedoch bei der Ausfuhrung der Programmcodebzw. das Androidmanifest aus der ersten Datei mit dem Namen classes.dex bzw.AndroidManifest.xml genutzt. [Fre13]

Gelangt ein Angreifer nun an eine durch den Hersteller signierte Applikation, sokann er seine eigenen Dateien an den Anfang des APK-Archivs anfugen – und wenner dabei nur Dateinamen nutzt, die im Archiv bereits enthalten waren, wird Andro-id die Signatur bei der Installation nicht fur ungultig erklaren, obwohl zur Laufzeitdie Java-Klassen und das Androidmanifest des Angreifers genutzt werden. Im Mani-

10 3.2. ERSCHLEICHEN VON IN-APP-KAUFEN

fest kann der Angreifer dann beliebige Zugriffsrechte deklarieren, die eigentlich demHersteller vorbehalten sind. [Fre13]

Das Ausnutzen der Lucke auf diesem Weg wurde dadurch erschwert, dass auf Ge-raten vorinstallierte APK-Dateien in der Regel keine classes.dex -Datei enthalten.Der Code liegt stattdessen bereits in einer fur das jeweilige Gerat optimierten Formaußerhalb des Archivs vor. Daher konnen vorinstallierte Anwendungen in der Re-gel nicht von Angreifern um eigenen Java-Code erweitert werden, weil durch dasHinzufugen einer neuen classes.dex -Datei die Signatur nicht mehr verifiziert werdenkonnte. Allerdings wurde eine Moglichkeit gefunden, alleine durch eine Modifikationdes Androidmanifests zur Aktivierung einer Debug-Option eigenen Code auszufuh-ren. Der Fehler wurde von Google bereits vor dem offentlichen Bekanntwerden derLucke behoben1, indem bei APK-Dateien mit Dateinamenskollisionen das Entpackendes Archivs bei der Signaturprufung verweigert wird. [Fre13]

3.2 Erschleichen von In-App-Kaufen

Google stellt fur Android-Anwendungsentwickler die Moglichkeit zur Verfugung, ineiner Applikation virtuelle Gegenstande oder den Zugang zu Funktionen zu ver-kaufen. Dies wird mit dem Begriff

”In-App-Kauf“ bezeichnet. Die Transaktion wird

dabei uber den Service Google Play abgewickelt, der gleichzeitig ein Marktplatz furdas Verkaufen oder kostenlose Verteilen von Anwendungen ist. Fur die Kommuni-kation zwischen Applikation und Google Play wird eine Bibliothek zur Verfugunggestellt, die eine API fur diesen Zweck implementiert. [IAP]

In diesem Zusammenhang wurden Ende Oktober 2013 zwei Probleme bekannt, durchderen Kombination das Erschleichen von In-App-Kaufen ohne Bezahlung moglichwar. Das erste Problem lag darin, dass jede beliebige Anwendung einen eigenen Hin-tergrunddienst zum Empfang von Intents, die eigentlich an den Google-Play-Rech-nungsdienst zugestellt werden sollten, registrieren konnte. Dazu war lediglich dieFestlegung einer hohen Prioritat fur den Intent-Filter erforderlich, denn die Aktivie-rung des Rechnungsdienstes erfolgte uber einen impliziten Intent, also ohne Angabeeines Empfangers. Die Zustellung an den Rechnungsdienst erfolgte nur aufgrund desim Intent kodierten Befehls, der normalerweise nur durch den Rechnungsdienst be-arbeitet wird – was jedoch andere Anwendungen nicht daran hindert, selbst Intentsmit diesem Befehl zu akzeptieren. Somit war es moglich, eine erfolgreiche Abwick-lung der Bezahlung durch den Rechnungsdienst vorzutauschen, obwohl diese nichterfolgt ist, da die Anfrage den offiziellen Dienst nie erreicht hat. Dafur musste der ge-falschte Rechnungsdienst nur zu jeder Anfrage eine positive Ruckmeldung erzeugen,die eine erfolgreiche Bezahlung vortauscht. [Sch13]

Dieses oder ein ahnliches Szenario sollte eigentlich durch eine Sicherheitsmaßnahmeverhindert werden: Der Google-Server fertigt zur Bestatigung der Transaktion einedigitale Signatur an und leitet diese durch den Rechnungsdienst an die Applikati-on weiter, wo sie uberpruft wird, bevor die Bezahlung als abgeschlossen angesehenwird. Dafur enthalt die von Google bereitgestellte Bibliothek Beispielcode, der die

1Der entsprechende git commit ist 5360af4aa1d23fd910680b09fa06f0820db03a9a,”Remove

support for duplicate file entries.“ in /platform/libcore

KAPITEL 3. FALLBEISPIELE: SICHERHEITSLUCKEN IN ANDROID 11

Validierung der Signatur illustriert. Allerdings war dieser Beispielcode fehlerhaft2

und ging – ohne die Uberprufung durchzufuhren – von einer erfolgreichen Trans-aktion aus, falls die durch den Rechnungsdienst gelieferte Signatur der leere Stringist. Somit konnten durch eine Kombination der beiden Sicherheitslucken erfolgreichKaufe ohne Bezahlung durchgefuhrt werden. Google hat den Fehler im Beispielcodebereits vor dem offentlichen Bekanntwerden der Lucke behoben, versaumte es jedochzunachst, die Entdeckung der Sicherheitslucke dem Forscher, der sie gemeldet hatte,zuzuschreiben. [Sch13]

3.3 Ungewollte Ausfuhrung von USSD-Codes

Ein USSD-Code (Unstructured Supplementary Service Data) ist eine speziell forma-tierte Zeichenkette, die mit einem Asterisk-Zeichen (*) beginnt und mit einer Raute(#) endet. Wird ein solcher Code in der Wahlfunktion eines Mobiltelefons genutzt,fuhrt dies in der Regel zu einem direkten Verbindungsaufbau zwischen dem Geratund einer Anwendung des Mobilfunkanbieters, uber die auch eine interaktive Sitzungmit Menufunktionen abgewickelt werden kann. Diese Funktion wird beispielsweisezur Abfrage des aktuellen Kontostands bei Prepaid-Tarifen oder fur das Bearbeitenvon Einstellungen verwendet. [San11]

Im Zusammenhang mit USSD-Codes wurde im September 2012 eine Android-Si-cherheitslucke bekannt. Die Telefonfunktion von Androidgeraten wird durch eineAnwendung realisiert, die spezielle Zugriffsrechte fur die Anwahl von Telefonnum-mern besitzt und als Dialer bezeichnet wird. Der in Android enthaltene Dialer star-tet automatisch beim Aufruf einer tel-URI [RFC3966] wie

”tel:+49-231-123456789“,

beispielsweise beim Klick auf einen entsprechenden Link im Browser oder falls eineandere Applikation einen Intent mit einer solchen URI sendet. Die Telefonnummerist dann bereits vorgewahlt, so dass der Nutzer nur noch den

”Wahlen“-Button be-

tatigen muss, um die Verbindung aufzubauen.

Das Sicherheitsproblem trat auf, da der Android-Dialer einige USSD-Codes direktnach der vollstandigen Eingabe ausfuhrte, auch wenn der Nutzer noch nicht den

”Wahlen“-Button genutzt hatte. Dies war selbst dann der Fall, wenn die Eingabe

alleinig durch den Aufruf einer tel-URL erfolgte, was prinzipiell durch einen Klickauf einen Link auf beliebigen Webseiten moglich ist. Obwohl dies im Widerspruchzum Standard fur tel-URIs steht [RFC3966], vermutet der Entdecker der Lucke, dassdies aufgrund einer Formulierung in einem 15 Jahre alten Standard fur USSD-Codesso implementiert wurde. [Bor12]

Kritisch ist das beschriebene Verhalten, da auch USSD-Codes fur die Verwaltungder SIM-Karte existieren, mit deren Hilfe sich diese fur die Nutzung von Mobilfun-knetzen erforderliche Karte innerhalb von drei bis vier Sekunden nutzlos machenlasst. Somit kann durch einen Link-Klick im Browser ohne weitere Nutzerinterak-tion die SIM-Karte unbrauchbar werden. Einige Samsung-Gerate lassen sich durchUSSD-Codes sogar mit einem solchen Angriff auf den Auslieferungszustand zuruck-setzen, so dass auf dem Mobiltelefon gespeicherte Bilder, Kontakte oder Termine

2Der Logikfehler bei der Uberprufung war dabei recht einfach nachzuvollziehen:if(Signatur ist nicht leer) { if(Signaturprufung schlagt fehl) { return FEHLER } } return OK

12 3.3. UNGEWOLLTE AUSFUHRUNG VON USSD-CODES

verloren gehen, falls diese nicht anderswo gesichert sind. Betroffen von diesem Ver-halten sind nach Aussagen des Entdeckers der Lucke alle Android-Versionen von 2.3bis 4.1 und moglicherweise auch altere Versionen. In Android 4.2 wurde das Problembehoben. [Bor12]

KAPITEL 4. ANALYSE DER SICHERHEIT VON ANDROID-APPLIKATIONEN 13

4 Analyse der Sicherheit von Android-Applikationen

Obwohl Android-Anwendungen in ihrem Manifest genau Auskunft daruber gebenmussen, welche Daten des Telefons durch sie ausgelesen werden konnen und aufwelche Hardware zugegriffen werden soll, ist haufig unklar, zu welchem Zweck dieseZugriffsrechte uberhaupt benotigt werden. Um diese Frage besser beantworten zukonnen, wird in diesem Kapitel zunachst ein Ansatz fur eine allgemeine Sicherheits-analyse beliebiger Applikationen vorgestellt.In einem weiteren Abschnitt wird besonders der Umgang mit Intents untersucht.Denn nicht nur Android selbst, auch einzelne Anwendungen von Drittherstellernkonnen aufgrund von Sicherheitslucken fur Angreifer attraktiv sein, wenn uber eineLucke etwa auf vertrauliche Daten der Anwendung zugegriffen werden kann oderderen Zugriffsrechte fur den Angreifer wertvoll sind. Beachtenswert ist, dass sowohldie in Kapitel 3 beschriebene Lucke im Android-Dialer als auch die Moglichkeit zurIn-App-Kauf-Erschleichung zumindest teilweise auf unsachgemaßem Umgang mitIntents beruhen.

4.1 Allgemeine Analyse

Die folgenden Unterabschnitte beschreiben ein mogliches Vorgehen [Enc+11] fur ei-ne allgemeine Sicherheits- und Schadlichkeitsanalyse. Es wurde auf 1100 beliebte,kostenlose Applikationen aus dem damals noch als Android Market bezeichnetenPlay Store angewendet. Die Grundlage fur die Untersuchung bildeten dabei 21 Mil-lionen Java-Quelltextzeilen, die durch Dekompilierung der Anwendungen gewonnenwurden. Falls eine Applikation zusatzlich auch nativen Programmcode als dynami-sche Bibliothek enthielt, wurde dieser nicht genauer untersucht, wodurch Teile derFunktionalitat bei der Analyse verborgen blieben.

4.1.1 Dekompilierung von Anwendungen

Fur die Untersuchung wurde zunachst ein dex-Decompiler entwickelt, der als ded

bezeichnet wird. Die Gewinnung von Java-Quelltext ermoglicht die anschließendeNutzung von bereits existierenden Java-Analysewerkzeugen. Der Vorgang ist in dreiSchritte unterteilt: Retargeting, Optimierung und Dekompilierung. Das Retargetingbeschreibt den Vorgang, bei dem die in einer .dex -Datei enthaltenen Java-Klassenin eine jeweils eigene .class-Datei extrahiert werden und wird in den folgenden Ab-satzen genauer beschrieben. Fur die Optimierung und Dekompilierung wurde keineeigene Losung entwickelt, sondern Soot eingesetzt, welches Java-Bytecode in Formvon .class-Dateien als Eingabe erhalt, deren Inhalt auf Lesbarkeit hin optimiert undschließlich Java-Quelltext daraus erzeugt. [Enc+11]

14 4.1. ALLGEMEINE ANALYSE

Fur das Retargeting sind mehrere Teilschritte notig. Dalvik-Bytecode enthalt in ei-nigen Fallen weniger explizite Informationen uber den Typ einer Variable, als furgultigen Java-Bytecode benotigt wird. Es muss daher zunachst an einigen Stelleneine Beobachtung der Operationen, die mit den in Registern abgelegten Wertendurchgefuhrt werden, erfolgen um den Variablentyp der dort abgelegten Variablen-inhalte zu ermitteln und spater korrekten Java-Bytecode zu erzeugen. [Enc+11]

Im Anschluss werden die fur eine Klasse erforderlichen Konstanten aus dem globalenKonstantenpool extrahiert und in den Konstantenpool der jeweiligen .class-Dateieingefugt. Es mussen auch einige Konstanten im Pool neu erzeugt werden, die imDalvik-Bytecode direkt innerhalb einer Instruktion angegeben werden konnen, beiJava-Bytecode jedoch aus dem Pool referenziert werden mussen. [Enc+11]

Nun folgt ein Vorverarbeitungsschritt fur die Ubersetzung von Dalvik- in Java-Byte-code. Dieser reichert Dalvik-Instruktionsblocke fur die Erzeugung mehrdimensiona-ler Arrays mit einigen aus dem Kontext generierten Informationen an, da ansonsteneine lineare Ubersetzung des Codes nicht moglich ist. Zuletzt kann der Dalvik-Co-de jede Methode durchlaufen und Instruktion fur Instruktion in ein entsprechendesJava-Bytecode-Aquivalent ubersetzt werden. Dazu werden die genutzten Dalvik-Re-gister auf eine lokale Variable im Java-Bytecode und die Dalvik-Instruktion auf in derRegel mehrere Bytecode-Instruktionen abgebildet. Die Zusammensetzung der .class-Dateien aus Konstantenpool und Bytecode schließt das Retargeting ab. [Enc+11]

4.1.2 Analyse des Programmcodes

Fur die statische Analyse des Java-Codes wurde Fortify SCA (Static Code Analyser)als Werkzeug eingesetzt. Dabei kamen vier unterschiedliche Methoden zum Einsatz:Kontrollflussanalyse, Datenflussanalyse, strukturelle Analyse und semantische Ana-lyse. [Enc+11]

Bei der Kontrollflussanalyse wird das Programm auf das mogliche Auftreten be-stimmter Sequenzen von Aktionen hin untersucht, unter Berucksichtigung der Aus-wirkungen von Kontrollstrukturen wie Schleifen oder bedingten Verzweigungen. DieForscher fuhren an, dass es hierbei zu Fehlern kommen kann, da nicht alle Ausfuh-rungsreihenfolgen, die das Modell annimmt, auch bei der tatsachlichen Ausfuhrungauftreten konnen. Es sei aber auch moglich, dass einige Reihenfolgen unentdecktbleiben, was jedoch nur selten auftrete. [Enc+11]

Die Datenflussanalyse betrachtet Quellen sensibler Daten wie der Telefonnummeroder der Geratenummer und Datensenken wie das Internet oder den SMS-Dienst.Dabei wird untersucht, ob ein Datenfluss von einer Quelle zu einer Senke existiertund somit vertrauliche Daten das Telefon prinzipiell bei der Nutzung der Anwendungverlassen konnten. [Enc+11]

Sehr viel einfacher ist die strukturelle Analyse: Der Code wird dabei nicht globalbetrachtet, sondern es erfolgt lediglich eine lokale syntaktische Untersuchung aufUbereinstimmung mit einem vorgegeben Muster. Beispielsweise kann so sehr ein-fach erkannt werden, ob eine Anwendung die Gerate-ID des Telefons ausliest, in-dem ein Muster fur den Aufruf der entsprechenden getDeviceId()-Methode erstelltwird. [Enc+11]

KAPITEL 4. ANALYSE DER SICHERHEIT VON ANDROID-APPLIKATIONEN 15

Schließlich ermoglicht die semantische Analyse eine Untersuchung der Werte, die dieAnwendung in Variablen nutzt oder an Methodenaufrufe ubergibt. Beispielsweisewurde damit festgestellt, ob eine Anwendung beim Aufruf der Methode sendText-Message() eine fest vorgegebene Rufnummer als Empfanger nutzt, was auf Miss-brauch hinweisen konnte, bei dem automatisiert kostenpflichtige SMS an Premium-Rufnummern versendet werden. [Enc+11]

4.1.3 Ergebnisse

Die Dekompilierung des Quelltexts der 1100 Anwendungen dauerte annahernd 500Stunden, von denen 99,97% der Zeit durch den Java-Decompiler Soot beanspruchtwurde. Es wurden jedoch nur ungefahr 94% der 262.110 Java-Klassen erfolgreichdekompiliert: Bei 0,59% der Klassen schlug bereits das Retargeting fehl, etwa weil diefehlenden Typinformationen nicht erfolgreich rekonstruiert werden konnten. Weitere5% der Klassen konnten durch Soot nicht in Quelltext ubersetzt werden. [Enc+11]

Bezuglich der Identifikationsmerkmale einschließlich IMEI (eine eindeutige Identifi-kationsnummer fur das Telefon) und Telefonnummer eines Gerats wurde durch dieStudie festgestellt, dass diese von Anwendungen haufig unverschlusselt uber das In-ternet ubertragen werden. Offenbar werden diese Merkmale haufig zur Identifikationund spateren Wiedererkennung von Nutzern – wie im WWW Cookies – eingesetzt.Teilweise wurden aber auch ganze Sammlungen von Gerateinformationen inklusiveVersionsnummern, Hardwareinformationen und IMEI an einen Server gesendet. Eineweitere wichtige Feststellung der Studie ist, dass die IMEI heute nicht mehr nur vonMobilfunkanbietern mit personlichen Daten wie Anschrift oder Mail-Adresse ver-knupft werden kann, sondern beispielsweise auch die MP3-Player-Anwendung vonAmazon eine Verknupfung der IMEI mit dem Nutzerkonto ermoglicht. Bei Institu-tionen, die Zugriff auf solche Datensammlungen besitzen, darf die IMEI also nichtals anonymes Identifikationsmerkmal sondern viel mehr als personlicher Datensatzangesehen werden. [Enc+11]

Die Untersuchung auf absichtlichen Missbrauch lieferte keinen Verdacht gegen be-stimmte Anwendungen. Es wurde von keiner der gepruften Anwendungen versucht,vom Nutzer unbemerkt kostenpflichtige Premium-Rufnummern anzuwahlen oderPremium-SMS zu versenden. Stattdessen wurden nur Moglichkeiten fur die schnelletelefonische – teilweise kostenpflichtige – Kontaktaufnahme in Applikationen ver-schiedener Hersteller gefunden. Auch beim Zugriff auf Kamera, Mikrofon und derListe der installierten Anwendungen konnte kein Missbrauch festgestellt werden. Daden Forschern der direkte Zugriff auf Sockets anstelle der einfacheren Java-Klassenfur Netzwerkkommunikation verdachtig erschien, wurden die 75 davon betroffenenApplikationen etwas genauer untersucht. Auch dabei wurden keine unerwarteten Ak-tionen aufgedeckt, obwohl eine noch genauere Untersuchung in der Studie empfohlenwird. [Enc+11]

Bei der Untersuchung der Bibliotheksnutzung wurde festgestellt, dass Bibliothekenhaufig fur die Einbindung von Werbung oder zur Analyse der App-Nutzung einge-setzt werden. Es wurden 22 verschiedene Bibliotheken zu diesem Zweck gefunden,die von 561 der untersuchten Apps eingesetzt wurden. Manche Apps nutzten sogarmehrere – bis zu 8 Stuck. Oft wird von den Bibliotheken auf Identifikationsmerkma-

16 4.2. UNTERSUCHUNG DER KOMMUNIKATION ZWISCHEN APPLIKATIONEN

le des Telefons oder den aktuellen Geratestandort zugegriffen. Viele entsprechendeDatenflusse in das Internet konnten bei der Datenflussanalyse nicht aufgefundenwerden, weil sie entweder durch Inter-Prozess-Kommunikation unterbrochen wer-den oder Teile des Datenflusses in Klassen angesiedelt ist, deren Dekompilierungfehlschlug. [Enc+11]

Weiteres Augenmerk wurde auf Android-spezifische Probleme gerichtet. Es wurdefestgestellt, dass oft zu sorglos mit den Android-Log-Funktionen umgegangen wirdund dort sensible Daten ausgegeben werden. Mit Hilfe einer Zugriffsberechtigung furdas Auslesen der Logs, bei der ein gewohnlicher Nutzer eventuell keinen Verdacht indieser Hinsicht schopft, konnte eine Applikation diese sensiblen Daten, die von ei-ner anderen Anwendung ausgegeben wurden, erfassen. Auch die unsichere Nutzungvon Intents, durch die fremde Applikationen beispielsweise Zugriff auf vertrauli-che Daten erhalten oder diese manipulieren konnen, wurde aufgedeckt (siehe auchAbschnitt 4.2). Außerdem wurden 69 Anwendungen gefunden, die native Funktio-nen einer beigelegten Bibliothek uber das Java Native Interface aufrufen. Da dieseFunktionen nicht in Java programmiert sind, wurden sie nicht dekompiliert oderanderweitig untersucht. [Enc+11]

4.2 Untersuchung der Kommunikation zwischen Applikationen

In diesem Abschnitt wird das Werkzeug ComDroid [Chi+11] fur die automatisierteUntersuchung der Intent-Verwendung in Anwendungen vorgestellt. Bei der Nutzungvon Intents fur den Nachrichtenaustausch zwischen unterschiedlichen Applikationenoder Hintergrunddiensten muss beachtet werden, dass die installierten Applikatio-nen von anderen Herstellern nicht als vertrauenswurdig angesehen werden durfen.Trotzdem sind sie in der Lage, Intents an offentliche Schnittstellen anderer Apps zusenden oder auch Intents zu empfangen. [Chi+11]

4.2.1 Moglichkeiten fur Angriffe auf Intent-Basis

Angriffe mittels Intents konnen unterteilt werden in Angriffe, bei denen die Anwen-dung des Angreifers Intents empfangt und Angriffe, bei denen sie Intents versendet.Ein Empfang ist dabei nur mit Broadcast-Intents oder mit impliziten Intents mog-lich, fur die durch den Sender kein expliziter Empfanger angegeben wurde. SensibleInformationen sollten daher ausschließlich uber explizite Intents oder solche mit Zu-griffsbeschrankungen gesendet werden. Andernfalls konnen die Inhalte des Intentsdurch bosartige Anwendungen ausgelesen oder eine durch den Nutzer in Folge desIntents erwartete Reaktion ausgelost werden, etwa das Anzeigen eines gefalschtenLoginformulars fur das Abgreifen von Nutzerdaten. Die Anzeige einer durch den An-greifer erstellten Nutzeroberflache als Reaktion auf ein abgefangenes Intent wird alsActivity Hijacking bezeichnet, das Starten eines durch den Angreifer entwickeltenHintergrunddienstes hingegen als Service Hijacking. Die in Abschnitt 3.2 beschriebe-ne Moglichkeit fur das Vortauschen einer erfolgreichen Bezahlung bei In-App-Kaufenstellt ein Beispiel fur ein erfolgreiches Service Hijacking dar. [Chi+11]

Die andere Angriffsart basiert auf dem Senden gefalschter Intents. Anwendungenkonnen – absichtlich oder aus Versehen – offentlich zugangliche Intent-Schnittstel-

KAPITEL 4. ANALYSE DER SICHERHEIT VON ANDROID-APPLIKATIONEN 17

len anbieten, an die von jeder anderen Anwendung ein Intent mit eigenen Inhaltengesendet werden kann [Chi+11]. In diesem Fall darf den Intent-Inhalten kein Ver-trauen geschenkt werden. Enthaltene URIs sollten beispielsweise nicht direkt genutztwerden, da es sonst zu Sicherheitslucken wie in Abschnitt 3.3 mit der Ausfuhrungvon USSD-Codes kommen kann. Bereits die Anzeige von Text, der uber ein Intentungewisser Herkunft empfangen wurde, kann zu Problemen fuhren, wenn der Nutzerdiesen als legitime Aufforderung etwa zur Ubersendung von Zugangsdaten per E-Mail auffasst.

4.2.2 Auffinden potenzieller Schwachstellen

Das ComDroid-Werkzeug durchsucht den disassemblierten Dalvik-Bytecode der zuuntersuchenden Anwendung nach potenziellen Schwachstellen. Dabei wird fur jedesIntent-Objekt im Code verfolgt, ob ein expliziter Empfanger gesetzt wurde, ob eineauszufuhrende Aktion bei Empfang festgelegt wurde, ob zusatzliche Einstellungenvorgenommen wurden, und ob Daten als Parameter mit dem Intent verknupft wur-den. Wird ein Intent-Objekt versendet, ohne dass Zugriffsberechtigungen oder einexpliziter Empfanger festgelegt wurden, so erfolgt die Ausgabe einer Warnung durchComDroid. [Chi+11]

Außerdem wird auch das Androidmanifest der Anwendung untersucht und dabeifestgestellt, ob eine Schnittstelle vorhanden ist, die offentlich ist und damit auf dieVerarbeitung von durch einen Angreifer praparierten Intents vorbereitet sein muss.Der disassemblierte Bytecode muss ebenfalls berucksichtigt werden, denn zur Lauf-zeit konnen dynamisch weitere offentliche Intent-Empfanger zusatzlich zu denen desManifests registriert werden. Mit Ausnahme der offentlichen Schnittstelle, die beimStart der Anwendung durch das Android-System aufgerufen wird, erfolgt fur jedegefundene Schnittstelle eine Warnung. Dabei wird auch angegeben, ob im dazuge-horigen Code auf eventuell als Parameter ubergebene Daten zugegriffen wird, wasbesondere Vorsicht erfordert, da diese Daten durch einen Angreifer beliebig prapa-riert werden konnten. [Chi+11]

4.2.3 Ergebnisse

Bei der Untersuchung von 100 weitverbreiteten Anwendungen wurden 401 Warnun-gen fur offentliche Schnittstellen und 1013 Warnungen fur das Senden von Intents,die potenziell abgefangen oder umgeleitet werden konnen, erzeugt [Chi+11]. Es han-delt sich dabei nicht um 1414 Sicherheitslucken, denn das Android-Intentsystem er-fullt absichtlich den Zweck einer losen Kopplung zwischen Sender und Empfanger,die uber offentliche Schnittstellen miteinander kommunizieren konnen (siehe Ab-schnitt 2.5). Soll beispielsweise ein im Browser gefundener Link in einer anderenAnwendung weitergenutzt werden, so handelt es sich um die korrekte Vorgehens-weise, wenn ein impliziter Intent mit dem Link als Parameter gesendet wird. DerNutzer wahlt dann eine der im System vorhandenen offentlichen Schnittstellen zurVerarbeitung von Intents mit einem Link-Parameter aus, an die der Intent zugestelltwird. In diesem Szenario ware durch ComDroid eine Warnung fur den Code erzeugt

18 4.2. UNTERSUCHUNG DER KOMMUNIKATION ZWISCHEN APPLIKATIONEN

worden, der den impliziten Intent im Browser versendet, und eine Warnung fur dieSchnittstelle, die den Intent empfangt.Die Forscher untersuchten im Anschluss 20 der 100 Anwendungen manuell, um fest-zustellen, ob einige Warnungen Hinweise auf tatsachliche Sicherheitslucken darstel-len. Von 181 Warnungen durch ComDroid wurden 20 als

”definitive Schwachstelle“

eingestuft und in weiteren 14 Fallen war ein ungewolltes Einschleusen von Intents(spoofing) moglich. Aus den 20 Anwendungen waren 9 von definitiven Schwach-stellen, 12 von spoofing-Schwachstellen oder definitiven Schwachstellen betroffen.Exemplarisch fuhren die Forscher einige gefundene Schwachstellen an. So erfolgt dieinterne Kommunikation einer Fahrplananwendung fur den offentlichen Nahverkehruber offentliche Broadcasts, welche von anderen Anwendungen mitgehort werdenkonnen, um den aktuellen Standort des Geratenutzers auszulesen. Durch das Ein-schleusen eines Intents mit entsprechendem Inhalt konnten auf der angezeigten Um-gebungskarte auch nicht vorhandene Bushaltestellen oder Abfahrtszeiten eingefugtwerden. [Chi+11]

KAPITEL 5. FAZIT 19

5 Fazit

Nach einem anfanglichen Uberblick uber die Grundlagen der Android-Architektur,der Dalvik-VM sowie dem Dateiformat, dem Berechtigungsmodell und der Kommu-nikationsinfrastruktur fur Anwendungen wurde das Augenmerk zunachst auf zweiaktuelle und eine etwas altere Android-Sicherheitslucke gerichtet. Selbst Systeme,die dem Benutzer ein hohes Maß an Kontrolle uber die eigenen Daten und dasMobilgerat einraumen mochten, sind in der Regel aufgrund von Schwachen in derImplementierung anfallig fur Missbrauch unter Ausnutzung von Sicherheitslucken.Wie in Kapitel 3 exemplarisch dargestellt wurde, ist auch Android nicht vor solchenFehlern gefeit. Bei diesem Betriebssystem kommt jedoch hinzu, dass der Nutzernur in geringem Maße Kontrolle besitzt: Entweder die von einer Anwendung an-geforderten Zugriffsrechte werden vollstandig akzeptiert oder die Installation wirdabgebrochen. Wie oft, wann und wozu eine Berechtigung genutzt wird, ist fur denNutzer spater nicht ersichtlich oder kontrollierbar. Ob dies bei der Anzahl der ver-fugbaren Anwendungen aus zweifelhaften Quellen und den haufig wertvollen Datenauf dem Gerat als zeitgemaß angesehen werden kann, ist fraglich. Eine Verbesse-rung des Berechtigungsmodells, beispielsweise mit der Moglichkeit, die Installationfortzusetzen, dabei jedoch einzelne Berechtigungen zu verwehren, wird innerhalbder Nutzergemeinschaft haufig vorgeschlagen. Ebenso sollte bei besonders kritischenAktionen oder Zugriffen zum Zeitpunkt der Inanspruchnahme der Berechtigung einezusatzliche Erlaubnis durch das Betriebssystem beim Nutzer eingeholt werden.

Zur Verbesserung des Vertrauens in die aktuell eingesetzten Anwendungen kann einetiefgreifende Analyse angebracht sein. Doch die in Kapitel 4 vorgestellte Methode,dekompilierten Java-Code zu analysieren, wird durch die unzuverlassige Dekompi-lierung beschrankt. Aufgrund des Anteils von 5% nicht im Quelltext vorliegenderKlassen bleibt ein Teil der Datenflusse und Aktivitaten der Anwendung verborgen.Auch der Einsatz von nativem Code kann einfach zur Verschleierung verdachtigerProgrammteile genutzt werden. Auch wenn es aufgrund ihrer Verbreitung unwahr-scheinlich ist, dass in den 1100 untersuchten Anwendungen Schadlinge enthaltensind, die durch die Analyse nicht entdeckt wurden, ist unter diesen Umstanden einezuverlassige Funktion bei Anwendungen aus zweifelhafter Quelle nicht sichergestellt.Moglicherweise leistet der von Google entwickelte Bouncer zuverlassigere Dienste,um schadliche Anwendungen zu erkennen und auszufiltern, damit die von Googlebereits behobenen Sicherheitslucken nicht auf alteren Geraten ausgenutzt werdenkonnen. Allerdings liegt hier ein weiteres Problem von Android: Eine effektivereVorbeugung gegen Angriffe auf diesem Wege ware ein verlangerter Zeitraum, indem die Betriebssysteme von Mobilgeraten mit Aktualisierungen gepflegt werden.

20

Wahrend wahrscheinlich selbst fachlich erfahrene Endanwender Schwierigkeiten beider Interpretation der Warnungen des Analysewerkzeugs ComDroid bei fremdenAnwendungen haben, ist ein Einsatz durch den Anwendungsentwickler sinnvoll. Beijeder erzeugten ComDroid-Warnung sollte sichergestellt sein, dass dieser Teil derAnwendung tatsachlich zur Kommunikation mit anderen Anwendungen gedacht istund auch mit unvorhergesehenen Eingabedaten umgehen kann. Dieser Aspekt wirdnach den Ergebnissen der Studie von vielen Entwicklern nicht ausreichend beruck-sichtigt.Letztlich bleibt festzustellen, dass die Sicherheit von Android-Systemen zwar auf-grund des relativ strikten Berechtigungsmodells vermutlich besser als auf klassischenArbeitsplatzrechnern anzusehen ist. Trotzdem gibt es noch Moglichkeiten zur Ver-besserung der (Daten-)Sicherheit durch starkere Transparenz und Kontrollmoglich-keiten bei den Berechtigungen, um Sicherheits-Analysewerkzeuge fur Anwendungenverzichtbar zu machen. Falls Google diese nicht umsetzt, stellt dies einen voraus-sichtlich immer weiter zunehmenden Wettbewerbsnachteil dar.

LITERATUR 21

Literatur

[APK] Building and Running. url: http://developer.android.com/tools/building/index.html (besucht am 15. 12. 2013).

[Arch] Android Low-Level System Architecture. url: http://source.android.com/devices/index.html (besucht am 04. 12. 2013).

[Bor08] Dan Bornstein.”Dalvik VM Internals“. In: Google I/O Developer Con-

ference. 2008. url: http://sites.google.com/site/io/dalvik-vm-internals (besucht am 04. 12. 2013).

[Bor12] Ravishankar Borgaonkar. USSD/Android-Dailer-Vulnerability [sic]. 2012.url: http://web.ict.kth.se/~rbbo/ussdvul.html (besucht am14. 12. 2013).

[Chi+11] Erika Chin u. a.”Analyzing Inter-Application Communication in An-

droid“. In: Proceedings of the 9th international conference on Mobilesystems, applications, and services. ACM. 2011, S. 239–252.

[Enc+11] William Enck u. a.”A Study of Android Application Security“. In: Pro-

ceedings of the 20th USENIX Conference on Security. SEC’11. SanFrancisco, CA, 2011.

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

ceedings of the 18th ACM conference on Computer and communicationssecurity. ACM. 2011, S. 627–638.

[For13] Jeff Forristal. Uncovering Android Master Key That Makes 99% of De-vices Vulnerable. 2013. url: http://bluebox.com/corporate-blog/bluebox-uncovers-android-master-key/ (besucht am 11. 12. 2013).

[Fre13] Jay Freeman. Exploit (& Fix) Android”

Master Key“. 2013. url: http://www.saurik.com/id/17 (besucht am 11. 12. 2013).

[Glo] Android Glossary. url: http://developer.android.com/guide/

appendix/glossary.html (besucht am 27. 01. 2013).

[IAP] Selling In-app Products. url: http : / / developer . android . com /

training/in-app-billing/index.html (besucht am 11. 12. 2013).

[Int] Intents and Intent Filters. url: http://developer.android.com/guide/components/intents-filters.html (besucht am 15. 12. 2013).

[Lin+13] Tim Lindholm u. a. The Java Virtual Machine Specification, Java SE7 Edition. 1st. Addison-Wesley Professional, 2013.

22 LITERATUR

[Loc12] Hiroshi Lockheimer. Android and Security. Vorstellung des Malwares-canners

”Bouncer“. Feb. 2012. url: http://googlemobile.blogspot.

de/2012/02/android-and-security.html (besucht am 14. 12. 2013).

[Man] The AndroidManifest.xml File. url: http://developer.android.

com/guide/topics/manifest/manifest-intro.html (besucht am15. 12. 2013).

[RFC3966] Henning Schulzrinne. The tel URI for Telephone Numbers. RFC 3966.Dez. 2004.

[San11] Janagoudar Sanganagouda. USSD: A Communication Technology toPotentially Oust SMS Dependency. Aricent (White Paper). 2011.

[Sch13] Dominik Schurmann. Google Play In-App Billing Library Hacked. 2013.url: http://sufficientlysecure.org/index.php/2013/10/29/google-play-billing-hacked/ (besucht am 11. 12. 2013).

[Sign] Signing Your Applications. url: http://developer.android.com/tools/publishing/app-signing.html (besucht am 04. 12. 2013).