untersuchung zur broadcastsicherheit von android-appssohr/papers/bachelorthesis...android ist das am...

Fachbereich 3: Mathematik und Informatik

BachelorarbeitUntersuchung zur Broadcastsicherheit von

Android-AppsAnalysis of Android broadcast security

Daniel Müller

Matrikel-Nr.

17. September 2015

1. Gutachter: Dr. Karsten Sohr2. Gutachter: Prof. Dr. Ute Bormann

Betreuer: Dr. Karsten Sohr

Daniel Müller

Untersuchung zur Broadcastsicherheit von Android-Apps

Analysis of Android broadcast security

Bachelorarbeit, Fachbereich 3: Mathematik und Informatik

Universität Bremen, September 2015

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-Apps

Selbstständigkeitserklärung

Hiermit erkläre ich, dass ich die vorliegende Arbeit selbstständig angefertigt, nicht anderweitig zuPrüfungszwecken vorgelegt und keine anderen als die angegebenen Hilfsmittel verwendet habe.Sämtliche wissentlich verwendete Textausschnitte, Zitate oder Inhalte anderer Verfasser wurdenausdrücklich als solche gekennzeichnet.

Bremen, den 17. September 2015

Daniel Müller

3


Danksagung

Ein besonderer Dank gilt meinem Betreuer, Dr. Karsten Sohr, für seine Unterstützung, die sehrschnellen Antworten auf E-Mail-Nachfragen und auch die Finanzierung des zur Untersuchungder Telekom-App nötigen Hotspot-Zugangs.Auch danke ich Prof. Dr. Ute Bormann für die Übernahme der Zweitprüferschaft. Außerdem Dr.Achim Brucker vom SAP-Sicherheitsteam, der stets bei Fragen zum SAP-SDK zur Verfügungstand. Ein weiterer Dank für die Beantwortung von Rückfragen zur OnlineManager-App geht anHerrn Volker Tutt vom Telekom-Sicherheitsteam und an die beteiligten Entwickler.Zuletzt möchte ich meinen Eltern für die Unterstützung während meines Studiums danken, ohnedie ich nie so weit gekommen wäre.

4

Inhaltsverzeichnis

1 Einleitung 11.1 Ziele der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Grundlagen 52.1 Ziele für sichere Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Asymmetrische Kryptoverfahren, digitale Signaturen und Zertifikate . . . . . . . 62.3 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.1 Konzepte der Anwendungsprogrammierung unter Android . . . . . . . . . 102.3.1.1 Das Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.2 Buildprozess und APK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3.2.1 Der Signierungsprozess . . . . . . . . . . . . . . . . . . . . . . . 18

2.3.3 Ausführung von Apps in der Dalvik VM . . . . . . . . . . . . . . . . . . . 19

3 Was sind Broadcasts? 213.1 Broadcast-Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.1 Statische Broadcast-Receiver . . . . . . . . . . . . . . . . . . . . . . . . . 223.1.2 Dynamische Broadcast-Receiver . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2 Arten von Broadcast-Intents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.1 Normaler Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.2 Sticky Broadcasts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2.3 Ordered Broadcasts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2.4 Sticky Ordered Broadcasts . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4 Sicherheitsprobleme und Absicherungsmöglichkeiten 314.1 Sicherheitsaspekte bei der Deklaration . . . . . . . . . . . . . . . . . . . . . . . . 324.2 Besonderheiten bei speziellen Broadcast-Arten . . . . . . . . . . . . . . . . . . . 344.3 Absicherungsmöglichkeiten beim Versenden von Broadcasts . . . . . . . . . . . . 35

4.3.1 Verschlüsselung (Informationsebene) . . . . . . . . . . . . . . . . . . . . . 364.3.2 Permissions (Systemebene) . . . . . . . . . . . . . . . . . . . . . . . . . . 374.3.3 Explizite Verwendung (Systemebene) . . . . . . . . . . . . . . . . . . . . . 41

i


4.3.4 Lokale Einschränkung (Systemebene) . . . . . . . . . . . . . . . . . . . . 424.4 Absicherungsmöglichkeiten beim Empfang von Broadcasts . . . . . . . . . . . . . 42

5 Vorgehen bei einer typischen Broadcastanalyse 455.1 Vorbereitungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.2 Ermitteln kritischer Codeteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6 Analyse am Beispiel 516.1 OnlineManager (Deutsche Telekom AG) . . . . . . . . . . . . . . . . . . . . . . . 51

6.1.1 Analyse des Manifests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.1.2 Analyse des Quellcodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.1.2.1 Sticky Broadcasts . . . . . . . . . . . . . . . . . . . . . . . . . . 536.1.2.2 Weitere Broadcasts . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.2 Client Hub/Incident Management (SAP) . . . . . . . . . . . . . . . . . . . . . . . 596.2.1 Analyse des Quellcodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.2.1.1 Ungesicherter Service-Intent . . . . . . . . . . . . . . . . . . . . 636.2.1.2 Ungesicherte Broadcasts . . . . . . . . . . . . . . . . . . . . . . . 66

6.3 Twitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.3.1 Sicherheitsmaßnahmen im Manifest . . . . . . . . . . . . . . . . . . . . . . 696.3.2 Verwendung von LocalBroadcastManager . . . . . . . . . . . . . . . . . . 706.3.3 Verwendung von Permissions im Code . . . . . . . . . . . . . . . . . . . . 716.3.4 Explizite Adressierung von Komponenten . . . . . . . . . . . . . . . . . . 72

7 Erkennung von verwundbaren Codestellen durch statische Analyse 73

8 Fazit und Ausblick 79

A Anhang 81

ii

Kapitel 1

Einleitung

Android ist das am weitesten verbreitetste Betriebssystem für Mobilgeräte und hat bei den

Smartphoneverkäufen derzeit einen Anteil von gut 75% [sta15]. Smartphones entwickeln ihr vol-

les Potential erst durch die Installation von Zusatzanwendungen, den Apps. Im Normalfall werden

diese über App-Stores, also kontrollierte Softwareplattformen vertrieben. Zum größten Teil wer-

den die Anwendungen von Drittherstellern entwickelt und gehen immer wieder mit sehr sensiblen

Daten um.

Bereits im Juni 2013 gaben zum Beispiel 17% der deutschen Smartphonenutzer an, ihr Handy

auch für das mobile Banking zu verwenden [BIT13]. Das Abrufen des Kontostands und das

Tätigen von Überweisungen mit dem Mobilgerät nehmen einen immer größeren Anteil in den

Verwendungsstatistiken ein, genau wie das bargeldlose Bezahlen.

Doch Finanzen sind nur ein Aspekt, bei denen Nutzer mit sensiblen Daten auf ihrem Handy

umgehen. Natürlich fragt man sich dann schnell, wie sicher diese Informationen auf dem Gerät

denn eigentlich sind, zumal immer wieder Anwendungen in den offiziellen App-Stores auftauchen,

die diese Informationen abfangen und sie einem Angreifer zukommen lassen.1

Wenn Android-Anwendungen untereinander oder mit dem Betriebssystem kommunizieren möch-

ten, dann geschieht das unter anderem mit sogenannten Broadcasts – also mit Nachrichten, die

von einer Stelle aus an verschiedenste Anwendungen verschickt werden. Diese können die an-

gesprochenen sensiblen Daten beinhalten; sie stellen also einen Aspekt dar, den man im Kon-

text dieses Themengebiets untersuchen kann. Es ist zum Beispiel denkbar, dass ein Spiel einer

Banking-App durch einen Broadcast Kontoinformationen mitteilt, über die ein bestimmter Be-

trag abgerechnet werden soll. Diese Daten können – falls in falsch konfigurierten Broadcasts1 Der unter [Gil14] beschriebene, recht aktuelle Fall ist diesbezüglich sehr interessant.

1

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-Apps1.1. ZIELE DER ARBEIT

verschickt – ausgespäht, manipuliert oder aber von Drittanwendungen gefälscht werden. Da-

durch können Angreifer an Benutzernamen, Passwörter oder auch Kontodaten gelangen. Somit

sind hier die in Kapitel 2.1 eingeführten Sicherheitsziele Vertraulichkeit, Integrität und Authen-

tizität gefährdet.

1.1 Ziele der Arbeit

Es ist durchaus möglich, Broadcasts mit regulären Mitteln der Android-Umgebung abzusichern,

jedoch wird dies auch in größeren Anwendungen häufig nicht gemacht. Immer wieder fallen typi-

sche Fehler im Programmcode vieler Anwendungen auf. Im Verlauf dieser Arbeit sollen anhand

von dekompiliertem Quellcode verbreiteter Android-Anwendungen Beispiele der falschen Broad-

castverwendung aufgezeigt werden. Gleichzeitig werden Maßnahmen erklärt, mit deren Nutzung

man diese Sicherheitsprobleme verhindern könnte. Zuletzt soll herausgestellt werden, wie ein

statisches Analysetool diese Fehler automatisiert entdecken kann und darüber hinaus Lösungs-

vorschläge entwickeln könnte.

Ein erstes Zwischenziel ist es daher, dem Leser ein allgemeines Grundverständnis über das

Android-Themengebiet zu geben. Wie ist das System aufgebaut, wie funktionieren die Apps

und welche Komponenten sind im Kontext dieses Themengebiets relevant? Zusätzlich wird dem

Bereich der Broadcasts im Allgemeinen ein großer Teil gewidmet. Auf Grundlage dieser Infor-

mationen soll dann weiter darauf eingegangen werden, wie man Android-Anwendungen aus dem

Android-Package-Format (APK) am besten in ihre Bestandteile zerlegen kann, wie sie dekompi-

liert werden und wie man dadurch den Java-Source-Code erhält, um Apps aus dem App-Store

untersuchen zu können. Entwickler können die herausgestellten Inhalte dieser Bachelorarbeit

dann verwenden, um eigene Anwendungen auf typische Sicherheitslücken zu untersuchen.

1.2 Überblick

Zunächst wird wie beschrieben ein allgemeiner Überblick über die Funktionsweise und den Auf-

bau des Android-Betriebssystems an sich gegeben. An der Stelle wird ebenfalls aufgegriffen, wie

Apps unter Android ausführt werden, wodurch dann ersichtlich wird, weshalb ein Konzept wie

2

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-AppsKAPITEL 1. EINLEITUNG

das der Broadcasts überhaupt notwendig ist. Das dritte Kapitel befasst sich mit den unter-

schiedlichen Broadcast-Arten und ihren jeweiligen Besonderheiten. Typische Fehlerquellen bei

der Benutzung von Broadcasts werden anschließend im vierten Teil der Arbeit untersucht, wobei

gleichzeitig Hinweise zur sicheren Verwendung gegeben werden. Da Broadcasts oft im Zusammen-

hang mit sogenannten Services, also Hintergrundprozessen genannt werden, werden im vierten

Kapitel zusätzlich auch Sicherheitsaspekte zu ebendiesen aufgegriffen.

Der praktische Teil dieser Arbeit, das Untersuchen bekannter Android-Anwendungen, invol-

vierte unter anderem das Dekompilieren und Analysieren der Android-Package (APK)-Dateien.

Diese generelle Vorgehensweise ist im fünften Kapitel erklärt, die Ergebnisse werden im sechs-

ten beschrieben. Im siebten Kapitel wird herausgestellt, wie man ein Analyseprogramm zur

Automatisierung der geleisteten Arbeit entwickeln könnte, bevor dann im Fazit abschließend

einige Gedanken aufgegriffen werden, die als Begründung für die unachtsame Verwendung von

Broadcast-APIs seitens der App-Entwickler angesehen werden können.

3

Kapitel 2

Grundlagen

Dieses Kapitel beschreibt Grundlagen der Informationssicherheit und der relevanten Themenge-

biete, die zum Verständnis der folgenden Kapitel notwendig sind.

2.1 Ziele für sichere Systeme

IT-Systeme sollen, wie in der Einleitung erwähnt, immer häufiger sicherheitskritische Aufgaben

erledigen und sensible Daten verarbeiten. Gleichzeitig besitzen sie in vielen Fällen Schwachstellen,

die von einem Angreifer ausgenutzt werden können, um Sicherheitsmechanismen zu umgehen. Die

Lehre der Informationssicherheit definiert aus diesem Grund im Wesentlichen drei Hauptziele,

die ein sicheres System erfüllen muss. Diese sind sowohl für komplexe IT-Infrastrukturen relevant

als auch für einzelne Anwendungen.1

• Vertraulichkeit

Beim Sicherheitsziel der Vertraulichkeit geht es darum, sicherzustellen, dass das System In-

formationen nur mit dazugehöriger Autorisierung herausgibt. Es darf also auch nicht die

Möglichkeit geben, Datenströme ohne Berechtigung mitzuschneiden. Dies wird zum Beispiel

über Verschlüsselungsverfahren sichergestellt, bei dem der Schlüssel als Autorisierungsme-

chanismus genutzt werden kann.

• Integrität und Authentizität

Für das Sicherheitsziel der Integrität dürfen Informationen im System nicht unautorisiert

und unbemerkt veränderbar sein. Authentizität setzt voraus, dass Daten eindeutig einem

1 Vgl. für dieses Unterkapitel [BSG14a].

5

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-Apps2.2. ASYMMETRISCHE KRYPTOVERFAHREN, DIGITALE SIGNATUREN UND ZERTIFIKATE

Besitzer bzw. einem Autor zurechenbar sind. Hierfür lassen sich digitale Signaturen nut-

zen, wie in Kapitel 2.2, Asymmetrische Kryptoverfahren, digitale Signaturen und

Zertifikate beschrieben.

• Verfügbarkeit

Für dieses Ziel ist sicherzustellen, dass die Verfügbarkeit (Aufrufbarkeit, Funktionalität,

...) von Softwarekomponenten und sonstiger Funktionen nicht durch äußere Einflüsse be-

einträchtigt werden kann. Ein häufiger Angriff auf dieses Sicherheitsziel ist die Denial-of-

Service-Attacke.

Damit Subjekte (Nutzer, Prozesse, ...) unter Berücksichtigung der obigen Ziele sicher auf Objekte

(Dateien, Geräte, ...) zugreifen können, gibt es im Allgemeinen zwei verschiedene Sicherheitsmo-

delle: Mandatory Access Control (MAC) und Discretionary Access Control (DAC).

MAC funktioniert auf Grundlage von sehr allgemeinen Zugriffsregeln. Beispielhaft kann man

MAC am Bell-LaPadula-Modell verdeutlichen. Bei diesem Sicherheitsmodell erhält zunächst je-

des Objekt ein Label, was einer Einstufung bezüglich seiner Vertraulichkeitsstufe entspricht.

Damit ein Subjekt nun auf ein Objekt einer bestimmten Sicherheitsklasse zugreifen kann, ist es

nötig, dass es mindestens die gleiche Sicherheitsklasse besitzt [BSG14d]. Ein sogenannter Refe-

renzmonitor ist für die Prüfung dieser Berechtigung verantwortlich.

Bei DAC setzt der Nutzer hingegen manuell Berechtigungen pro Subjekt und Objekt. Das System

kann zum Beispiel in einer zuvor vom Administrator angelegten Zugriffsmatrix direkt nachse-

hen, ob ein bestimmtes Subjekt auf ein bestimmtes Objekt zugreifen darf. Anders als bei MAC

existieren hier konkrete Zugriffsregeln und Zuordnungen auf Subjekt-Objekt-Basis.

2.2 Asymmetrische Kryptoverfahren, digitale Signaturen und

Zertifikate

In dieser Arbeit wird an mehreren Stellen der Begriff des Zertifikats und der der digitale Signa-

tur aufgegriffen. Deshalb sollen in diesem Kapitel zunächst einige bewusst sehr kurz gehaltene

Grundlagen dieser Themengebiete erklärt werden. An geeigneter Stelle wird auf weiterführende

Literatur verwiesen.

6

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-AppsKAPITEL 2. GRUNDLAGEN

Oft möchte der Empfänger einer Nachricht oder einer Datei (hier genannt Alice) in der Infor-

matik sicherstellen, dass sie wirklich vom erwarteten Absender (Bob) stammt und dass sie auf

dem Kommunikationswege nicht von Dritten verändert wurde. Man will also die Sicherheitsziele

Integrität und Authentizität gewährleisten. Hierzu nutzt man das Prinzip der digitalen Signatur

in Verbindung mit Zertifikaten.

Eine digitale Signatur entspricht prinzipiell einer Unterschrift mit Stift und Papier, nur dass hier-

bei keine Tinte genutzt wird. Vielmehr werden den zu übertragenden Daten Prüfinformationen

hinzugefügt. Um Daten digital zu signieren, wird in den meisten Fällen zunächst ein kryptogra-

fischer Hashwert mit einer Hashfunktion über die zu unterschreibenden Daten gebildet.

Damit die Nachricht nicht einfach von einer beliebigen Person verändert werden kann, die dann

einen neuen Hashwert berechnet, wird letzterer mit einem asymmetrischen Kryptoverfahren ver-

schlüsselt. Hierbei existieren zwei verschiedene Schlüssel: der Public- und der Private-Key. Ver-

schlüsselt man eine Nachricht mit dem Private-Key, kann sie nur mit dem Public-Key entschlüs-

selt werden und umgekehrt. Der Public-Key wird normalerweise veröffentlicht und der Private-

Key geheim gehalten. So kann die Nachricht von vielen entschlüsselt, aber nur von einer Person

verschlüsselt werden – oder umgekehrt. Ein typisches Beispiel für ein solches Kryptoverfahren

ist RSA.2

Der Hashwert wird mit dem Private-Key von Bob verschlüsselt. Das heißt: Ist der Hashwert durch

Alice mit dem Public-Key von Bob entschlüsselbar, muss er zuvor auch von Bob verschlüsselt

worden sein. Somit wird das klassische Sicherheitsziel der Authentizität erfüllt: Die Herkunft der

Nachricht ist belegbar. Nun kann Alice selbst den Hashwert der Nachricht berechnen und ihn mit

dem entschlüsselten Ergebnis vergleichen. Stimmen die Ergebnisse überein, wurde die Nachricht

seit dem Versenden nicht verändert – das Sicherheitsziel der Integrität ist erfüllt.

Zur sicheren Verteilung von Public-Keys werden Zertifikate genutzt, heutzutage aufgebaut nach

dem X.509-Zertifikatsstandard.3 Vereinfacht enthält das Zertifikat den Public-Key und den Na-

men von Bob sowie einige weitere Daten (zum Beispiel E-Mail-Adresse o.ä.). Zusätzlich ist das

Zertifikat digital signiert, sodass sichergestellt ist, dass der Public-Key im Zertifikat nicht durch

einen anderen ausgetauscht wurde. Damit wird der Public-Key eindeutig einer Instanz (in diesem

Fall Bob) zugeordnet.

Die digitale Signatur des Zertifikats kann unter X.509 auf zwei Arten erfolgen: Es kann selbst

2 Da an dieser Stelle nur die prinzipielle Funktionsweise im Fokus stehen soll, wird dem Leser für weitergehendeInformationen zum RSA-Verfahren [BSW10] empfohlen.

3 Weiterführende Informationen zum Standard sind unter [Coo+08] nachlesbar.

7

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-Apps2.3. ANDROID

signiert werden, also in diesem Beispiel mit Bobs Private-Key, oder durch eine vertrauenswür-

dige Drittinstanz, der sogenannten Zertifizierungsstelle bzw. Certification Authority (CA). Zur

Überprüfung dieser Unterschrift wird dann wieder der Public-Key der CA benötigt, welcher wie-

derum durch ein (selbstunterschriebenes oder extern bezeugtes) Zertifikat bekanntgemacht wird.

So entsteht eine Kette von Zertifikaten, die nach und nach verifiziert werden muss. Am Ende der

Zertifizierungskette stehen die Root-Zertifikate – sie sind von den entsprechenden Zertifizierungs-

stellen selbst unterschrieben. Hier gilt ein Vertrauensprinzip; diese Stammzertifikate werden mit

der jeweiligen Software mitgeliefert. Da die Nutzer der Software vertrauen, herrscht auch ein

Vertrauen in die beigelegten Root-Zertifikate. [BSG14c]

In dieser Arbeit steht hauptsächlich die Signierung der Anwendungspakete (APKs) im Vorder-

grund, wie in Kapitel 2.3.2.1, Der Signierungsprozess beschrieben. Das allgemeine digitale

Signieren ist in Abb. 2.1 illustriert.

2.3 Android

Android ist ein auf dem Linuxkernel basierendes Open-Source-Betriebssystem, primär ausgerich-

tet auf Mobilgeräte. Es wird von der Open Handset Alliance entwickelt, einem Zusammenschluss

von derzeit 87 Firmen aus der Technologiebranche [All], wobei der Internetkonzern Google den

Hauptentwickler darstellt [MK09]; [All, 14].

Das System zeichnet sich neben der Optimierung für berührungsempfindliche Bildschirme durch

verschiedene weitere besondere Konzepte aus, die im Folgenden beschrieben werden.

Bereits seit der ersten Version ist es Entwicklern möglich, eigene Anwendungen (Applications,

abgekürzt Apps) für Geräte zu schreiben, auf denen Android installiert ist. Sie werden im All-

gemeinen in Java programmiert und für gewöhnlich über eine zentrale Anwendung verteilt, dem

Google Play Store. Anwendungen aus anderen Quellen werden mit den Standardeinstellungen blo-

ckiert – es ist nötig, diese Sicherheitsüberprüfung manuell auszuschalten. Dadurch ist es Google

möglich, Apps von Drittentwicklern vor dem Veröffentlichen im Play Store beispielsweise auf

Schadfunktionalität zu überprüfen und kontrolliert auszuliefern.

Jede App definiert zentrale Eigenschaften in einer individuellen Datei namens AndroidManifest.

xml (vgl. Kapitel 2.3.1.1, Das Manifest) und wird in einer eigenen Virtuelle Maschine (VM)

8


Abbildung 2.1 Schematischer Ablauf des Signiervorgangs, basierend auf [Acd08]. Lizenz: Crea-tive Commons Attribution-Share Alike 3.0 Unported.

9


betrieben. Das Nutzen einer VM hat verschiedene Vorteile: Beispielsweise erhalten Anwendungs-

programmierer dadurch eine Unabhängigkeit von der verwendeten Hardwareplattform des Ge-

räts. Sicherheitsaspekte werden ebenfalls verbessert: Anwendungen können nur über festgelegte

Schnittstellen mit dem Betriebssystem oder anderen Anwendungen kommunizieren – die Spei-

cherbereiche sind strikt voneinander getrennt. Bringt eine App die VM zum Absturz, bleibt das

eigentliche Betriebssystem weiterhin stabil. [Lev13]

In den neueren Android-Versionen ab 5.0 wird Android RunTime (ART) als VM verwendet; bei

den vorherigen Versionen ist dies die Dalvik Virtual Machine (DVM). [Goob]; [Bec11].

Die DVM ist gut dokumentiert, wurde oft sicherheitsbezogen analysiert und ist schon deut-

lich länger im produktiven Einsatz. Auf dem Testgerät, welches im Rahmen dieser Arbeit zur

Verfügung stand (HTC Desire), war es ohne weiteres nur möglich, eine Android-Version zu in-

stallieren, die die DVM verwendet (4.2.2). Aus dem Grund wird im Folgenden alleinig letztere

näher erläutert.

Architekturell kann man sich das wie in Abbildung 2.2 vorstellen. Der Linux-Kernel steht an

erster Stelle der Architekturhierarchie. Er sorgt für die Kommunikation mit der Hardware des

Gerätes (zum Beispiel mit dem Display oder dem WLAN-Adapter). Darauf bauen die Android-

Bibliotheken auf, die weitergehende Programme wie 3D-Libraries oder aber auch die DVM be-

reitstellen. Hierauf folgt dann das Anwendungsframework – eine Sammlung von Programmen, die

beispielsweise für die Fensterverwaltung der ausgeführten Anwendungen sorgt. Zuletzt kommen

die eigentlichen Apps, die in der angesprochenen VM ausgeführt werden.

2.3.1 Konzepte der Anwendungsprogrammierung unter Android

Da die einzelnen Anwendungen durch die unterschiedlichen virtuellen Maschinen strikt voneinan-

der getrennt sind, sind spezielle Programmiermodelle notwendig, um trotzdem Interprozesskom-

munikation zu ermöglichen.4 Nicht alle der im Folgenden kurz vorgestellten Konzepte sind auf

dieser Besonderheit begründet, es ist jedoch wichtig, sie an dieser Stelle einzuführen, da dadurch

das weitere Verständnis dieser Arbeit stark vereinfacht wird.

a) Activities

Eine Activity ist eine (typischerweise) bildschirmfüllende Programmansicht einer App. Pro-

4 Vergleiche für dieses Unterkapitel [Gooa]

10


Abbildung 2.2 Allgemeiner Aufbau von Android. Das System ist hierarchisch aufgebaut: Zu-nächst existieren hardwarenahe Treiber aus dem Linux-Kernel, auf der letztenSchicht folgen dann die fertigen Apps. Bildquelle: [Vas09], Lizenz: GDFL.

11


grammiertechnisch besteht sie aus einer Klasse, die von Activity erbt, und einer dazu-

gehörigen XML-Datei, die die Gestaltung der grafischen Benutzeroberfläche (das Layout)

beschreibt. Klicks bzw. Berührungen und andere Ereignisse im Zusammenhang mit Steuer-

elementen des Graphical User Interface (GUI) (also zum Beispiel Buttons und Textfelder)

können mit sogenannten Action-Handlern abgearbeitet werden.

b) Dialoge

Wenn der weitere Programmablauf vom Eingreifen des Benutzers abhängig ist, wird häufig

ein Dialog angezeigt. Dieser enthält im Allgemeinen einen Titel, eine textuelle Beschreibung

der geforderten Informationen und weitere Steuerelemente. Der Dialog ist nicht bildschirm-

füllend, blockiert die aktuell dargestellte Activity jedoch. Ein solcher Dialog wird mit der

showDialog(i)-Methode der jeweiligen Activity dargestellt, wobei eine Activity in der Me-

thode onCreateDialog(i) verschiedene Dialoge definieren kann, die dann vom Program-

mierer mit dem Parameter i selektiert werden können.

c) Permissions

Damit Apps ihre virtuellen Maschinen kontrolliert verlassen können, gibt es das Prinzip

der Permissions. Dabei handelt es sich im Grunde um Berechtigungen, die eine App vom

System anfordern kann. Sie kann auch eigene definieren, um den Zugriff auf Komponenten

wie zum Beispiel die im Folgenden erklärten Services, Activities oder Broadcast-Receiver

einzuschränken.

Mit dem sogenannten Protection-Level-Wert lässt sich im Manifest festlegen, welche Apps

die Permissions erlangen können. Eine Angabe des Protection-Levels signature setzt bei-

spielsweise voraus, dass anfordernde Apps mit dem gleichen Zertifikat signiert wurden wie

diejenige, die sie deklariert hat. Weiteres zu diesem Thema ist in Kapitel 4.3.2 beschrieben.

d) Intents

Intents ermöglichen die Kommunikation mit anderen Komponenten über das Betriebssys-

tem. Man nutzt sie, um dem System mitzuteilen, dass die eigene Anwendung eine bestimmte

systemrelevante Aktion (genannt Action) durchführen möchte. Dies kann beispielsweise das

Starten einer anderen Activity oder das Anrufen einer Telefonnummer sein. Durch Setzen

von bestimmten Flags und Eigenschaften der Intent-Objekte wird diese Action genauer

spezifiziert. Ebenfalls kann man anderen Anwendungen und Anwendungskomponenten mit

Intents benutzerdefinierte Nachrichten zukommen lassen, die sogenannten Broadcasts. Wie

in Abbildung 2.3 dargestellt, ist das Betriebssystem dafür zuständig, die passenden Emp-

fänger zu ermitteln und die Nachricht zuzustellen.

12


Abbildung 2.3 Verarbeitung von Intents in Android. Activity A möchte eine andere Activitystarten, generiert einen Intent und übergibt ihn der Methode startActivity()(1). Das Betriebssystem sucht Anwendungen, auf die der Klassenname passt (2)und ruft ggf. onCreate() der passenden Activity auf (3). Bildquelle: [Gooh],Lizenz: Creative Commons Attribution 2.5.

Intents können entweder explizit oder implizit sein.

• Explizite Intents geben direkt an, welche Anwendungskomponente adressiert wird.

Beispielsweise ActivityX, bei der Deklaration des Intents explizit definiert durch An-

gabe des Klassennamens com.example.myApp.ActivityX (vgl. Code 2.1). Hierbei wird

auch der Kontext (this in diesem Fall) übergeben. Er definiert, welche Anwendung die

Klasse bereitstellt. Alternativ kann man hier auf eine andere App verweisen.

Code 2.1 Ein expliziter Intent unter Angabe des Klassennamens der Zielactivity.

1 Intent explicitIntent = new Intent(this, com.example.myApp.←↩ActivityX.class);

2 startActivity(explicitIntent);

• Implizite Intents wählt man, wenn man nicht genau weiß, welche Komponente man

adressieren möchte. Sie definieren verschiedene Parameter und benennen die gewünsch-

te Action mit einem Action-String, überlassen dem Betriebssystem aber die konkrete

Auswahl der abhandelnden Anwendung(en). Ziele eines impliziten Intents müssen ei-

nen zum Action-String passenden Intent-Filter (vgl. Code 2.2) definieren und können

mit einem Wert android:priority zusätzlich festlegen, wie wichtig es ist, dass sie bei

mehreren potentiellen Zielen eines Intents als Erstes adressiert werden.

13


Ein generelles Beispiel ist das Öffnen einer Webseite (vgl. Code 2.3). Der App ist

nicht bekannt, welche Webbrowser-Anwendungen installiert sind und welche verwen-

det werden soll. Das System kümmert sich dann um die Ausführung eines passenden

Programms oder darum, dem Nutzer einen Auswahlbildschirm mit möglichen Zielan-

wendungen zu präsentieren.

Code 2.2 Intent-Filter im Manifest. Hier für das Anzeigen einer Internetseite nach

[Mic12].

1 <activity android:name=".BrowserActivitiy" android:label="←↩@string/app_name">

2 <intent -filter android:priority="...">3 <action android:name="android.intent.action.VIEW" />4 <category android:name="android.intent.category.DEFAULT" ←↩

/>5 <data android:scheme="http"/>6 </intent -filter >7 </activity >

Code 2.3 Generierung eines impliziten Intents zum Öffnen einer Internetseite unter

Angabe des passenden Action-Strings Intent.ACTION_VIEW.

1 Intent implicitIntent = new Intent(Intent.ACTION_VIEW , Uri.←↩parse("http://www.example.com"));

2 startActivity(implicitIntent);

e) Services5

Ein Service ist eine Klasse, die von Service (bzw. einer der dazugehörigen Subklassen) erbt

und im Hintergrund läuft. Währenddessen führt der Service typischerweise eine Aktion aus,

die in der Methode onHandleIntent() definiert wird (zum Beispiel das Abspielen von Musik

oder das Durchführen einer aufwendigen Berechnung) – das heißt, dass der Nutzer keine

Benutzeroberfläche des Services sieht. Ein zu startender Service muss nicht notwendigerweise

aus der gleichen App stammen. Damit er gestartet werden kann, muss er im Manifest (vgl.

Kapitel 2.3.1.1) der deklarierenden App angegeben werden, wie in Code 2.4 dargestellt.

Oft gibt er keinen Rückgabewert an den Aufrufer zurück; in anderen Fällen nutzen die

Entwickler wiederum Broadcasts, um Ergebnisse der Serviceausführung zu vermelden.

5 Vgl. [Gool].

14


Code 2.4 Definition eines Services im Manifest. Durch den Parameter

android:exported=''true'' können auch fremde Apps den Service starten.

Wird android:permission angegeben, können nur Apps mit einer bestimmten

Permission den Service starten (vgl. Kapitel 4.3.2).

1 <service android:name="dmueller.MyService" android:exported="←↩true" android:permission="(...)">

2 <intent -filter >3 <action android:name="dmueller.MyServiceActionString" ←↩

/>4 </intent -filter >5 </service >

Die Klasse Service ist darauf ausgelegt, im Hauptthread der Anwendung zu laufen. Damit

könnte sie letzteren durch eine aufwendige Berechnung blockieren. Um die Arbeit des Ser-

vices in einen weiteren Thread auszulagern, kann stattdessen die Subklasse IntentService

verwendet werden. [Gool]

f) Broadcast-Receiver6

Apps können Broadcasts mit Broadcast-Receivern empfangen. Broadcast-Receiver können

auf verschiedene Arten definiert werden. Die Art der Definition hat gewisse Auswirkungen

auf die Sicherheit und die zu treffenden Schutzmaßnahmen. Mögliche Definitionen sind:

1. Statische Deklaration im Manifest

Eine App kann in ihrem Manifest (vgl. Kapitel 2.3.1.1) angeben, dass sie auf be-

stimmte Broadcast-Intents wartet. Es muss dann eine Klasse angegeben werden, die

auf diese empfangenen Intents reagieren soll und von BroadcastReceiver erbt. Broad-

casts können mit dieser Methode auch empfangen werden, wenn das Programm beendet

ist.

2. Dynamische Deklaration im Code

Alternativ können Broadcast-Receiver zur Laufzeit durch den Aufruf von register-

Receiver() registriert werden. Da der Broadcast-Receiver im Prozess der startenden

App registriert wird, wartet er nur so lange auf Intents, wie die App läuft [Gooe]. Wird

der Broadcast-Receiver beim Beenden der startenden Activity nicht durch unregister-

Receiver() deregistriert, wirft das System eine dazugehörige Exception.

3. Variante der dynamischen Deklaration: LocalBroadcastManager

Wenn man bestimmte Broadcasts nur innerhalb des eigenen Prozesses (lokal) verschi-

cken und empfangen möchte, bietet sich die Nutzung der Klasse LocalBroadcastManager

an. Sie bietet eigene Methoden zum lokalen Empfangen und Versenden von Broadcasts6 Vgl. [Good].

15


an. Genaueres zu den Broadcast-Arten wird in Kapitel 3 erläutert.

2.3.1.1 Das Manifest

Jede Android-App beinhaltet eine Datei mit dem Namen AndroidManifest.xml. Diese Datei –

verfasst im XML-Format – definiert durch Tags und Attribute die wesentlichen Eigenschaften

der App. Unter anderem wird hier festgelegt, wie die Anwendung heißt, für welche Betriebssys-

temversion(en) sie gedacht ist und vor allem welche Berechtigungen das Programm benötigt. Das

Manifest enthält auch den sogenannten Package-Name – einen String, der systemweit eindeutig

sein muss und im <manifest>-Tag genannt wird. Damit wird die Anwendung eindeutig identifi-

ziert. Apps können den gleichen Titel tragen, solange ihre Package-Names unterschiedlich sind.

Ein Überblick über die im Manifest möglichen Tags ist im Anhang unter Code A.1 abgedruckt.

Mit <uses-permission>-Tags werden von der Anwendung Permissions angefordert. Falls das

Programm beispielsweise mit dem Internet kommunizieren soll, ist hier der entsprechende Tag zu

setzen. Weiteres zu Permissions ist im Kapitel 4.3.2, Permissions (Systemebene) beschrieben.

Darüber hinaus wird innerhalb des Tags <application> durch Verwendung von <activity>

festgelegt, welche Activities in der App verwendet werden und welche beim Start des Programms

angezeigt werden soll. Letzteres wird durch einen Intent-Filter erreicht – erhält die Anwen-

dung einen impliziten Intent mit dem Action-String android.intent.action.MAIN, so wird

die entsprechende Activity gestartet (Code 2.5). Mit Kategorien (Tag <category>) kann die

Zielmenge impliziter Intents weiter eingeschränkt werden - ebenso kann eine Kategorie weitere

besondere Eigenschaften einer App-Komponente definieren. Die Angabe der Kategorie android.

intent.category.LAUNCHER in Code 2.5 sorgt dafür, dass die jeweilige Activity im Android-

Programmmenü angezeigt wird. [Gooh]

Code 2.5 Festlegen der initialen Activity im Manifest.

1 <activity2 android:name=".MainActivity"3 android:label="@string/app_name" >4 <intent -filter>5 <action android:name="android.intent.action.MAIN" />6 <category android:name="android.intent.category.LAUNCHER" ←↩

/>7 </intent -filter>8 </activity>

Statische Broadcast-Receiver werden ausschließlich mit <receiver>-Tags aus Code A.1 definiert.

16


Abbildung 2.4 Organisation eines Ressourcenordners unter Android. Abkürzungen in den Ord-nernamen wie hdpi (High Dots Per Inch) und ähnliche ermöglichen eine Sortie-rung der Bilddateien nach Bildschirmauflösung des Zielgeräts.

2.3.2 Buildprozess und APK

Durch das Bauen (Building bzw. Build-Prozess) einer Android-Anwendung wird vom Tool aapt

aus dem Quellcode eine Datei vom Typ APK erstellt. Sie ist im Grunde eine ZIP-Datei mit einer

anderen Endung. Dadurch lässt sie sich auch mit gängigen ZIP-Extraktoren öffnen und verarbei-

ten, was den Prozess des Dekompilierens erheblich vereinfacht (vgl. Kapitel 5, Vorgehen bei

einer typischen Broadcastanalyse). APK-Dateien werden nicht nur von Android-Systemen

verarbeitet, auch für BlackBerry-OS gibt es entsprechende Installationsmöglichkeiten.7

Die APK-Datei enthält verschiedene Komponenten, zuallererst einmal den auf den Java-Class-

Dateien basierenden kompilierten Source-Code für die DVM in der Datei classes.dex (vgl.

hierzu auch Kapitel 2.3.3, Ausführung von Apps in der Dalvik VM).

Die verwendeten Ressourcen, also zum Beispiel Bilder, Farbdeklarationen und so weiter, liegen im

Unterordner res in der jeweiligen Verzeichnisstruktur, wie sie auch in der zur Programmierzeit

verwendeten Entwicklungsumgebung organisiert wurden (vgl. Grafik 2.4). Eine Datei namens

resources.arsc ordnet den einzelnen Medien jeweils eine ID zu, um eine Zuordnung zwischen

Datei und Referenz im Code zu schaffen.

7 Für weitergehende Informationen ist die Webseite [Klu14] zu empfehlen.

17


Weiterhin ist das Manifest in binärer Form in der Datei AndroidManifest.xml im Wurzelver-

zeichnis des APKs gespeichert. Es ist also beim Öffnen nicht direkt lesbar. Allerdings gibt es

diverse Converter, die aus der kompilierten Form des Manifests eine menschenlesbare machen.

Näheres hierzu ist in Kapitel 5, Vorgehen bei einer typischen Broadcastanalyse beschrie-

ben.

Ein weiterer Ordner, META-INF, enthält die digitale Signatur jeder einzelnen Datei im APK und

das Zertifikat, welches zur Unterschrift genutzt wurde.

2.3.2.1 Der Signierungsprozess

Damit Anwendungen ohne Probleme installiert werden können, müssen sie als Voraussetzung

des Android-Betriebssystems digital signiert werden.8 Wie bereits in Kapitel 2.2 erklärt wurde,

ist die digitale Signatur eine Bestätigung der Herkunft bestimmter Daten und stellt sicher, dass

sie seit dem Signieren nicht verändert wurden. Bei Apps hilft die Signierung, sicherzustellen,

dass ein Angreifer das APK nicht verändert hat. Ansonsten wäre es denkbar, Sicherheitsroutinen

durch Löschen der entsprechenden Codeteile oder durch Abändern von Fallunterscheidungen zu

deaktivieren. Das neue APK kann arglosen Nutzern dann über verschiedene Wege untergeschoben

werden. Der Angreifer könnte damit unbemerkt an Passwörter, Bankdaten und ähnlich sensible

Informationen gelangen.

Verändert man den Code eines signierten APKs, stimmt die Signatur nicht mehr – die Installati-

on schlägt fehl. Auch eine neue Signierung mit einem anderen Zertifikat hilft hier nicht: Android

stellt bei der Installation von neuen App-Versionen sicher, dass die Anwendung mit demselben

Zertifikat signiert wurde wie die Vorgängerversion. Die Identifizierung der Vorgängerversion wird

anhand des Package-Name vorgenommen. Somit können manipulierte Anwendungen nicht ein-

fach über existierende installiert werden. Natürlich ist es aber immer noch möglich, dass ein

Nutzer eine manipulierte, neu signierte Anwendung aus einer Drittquelle als Erstes installiert –

also bevor eine originale Version installiert wurde. In diesem Fall lässt sich die Herkunft nicht oh-

ne weiteres verifizieren, weswegen standardmäßig nur Programme aus dem Play Store installiert

werden können. [Goom]

Apps, die mit dem gleichen Zertifikat signiert wurden, können vom System gesondert behandelt

werden: Sie können im selben Prozess (und damit in derselben DVM [Riv13]) gestartet werden8 Sofern diese Sicherheitsprüfung nicht über Drittsoftware bewusst ausgeschaltet wurde. Siehe [Goom].

18


und so zusammenarbeiten. Hierdurch wird Modularität gewährleistet, da diese Komponenten

dann vom Nutzer auch getrennt aktualisiert werden können. [Goom]

Im Kontext dieser Arbeit ist es jedoch wesentlich interessanter, dass auch Permissions so einge-

richtet werden können, dass sie nur von Apps verwendet werden können, die mit dem gleichen

Schlüssel unterschrieben wurden (vgl. hierzu Kapitel 4.3.2, Permissions (Systemebene)).

Als Besonderheit ist es unter Android nicht notwendig, dass Zertifikate von einer Certification

Authority beglaubigt werden [Goom].

2.3.3 Ausführung von Apps in der Dalvik VM

Wie bereits erwähnt werden Anwendungen unter Android in einer eigenen VM gestartet.

Ein Vorteil einer VM liegt auf der Hand: Die Hauptprogrammiersprache für Android-Apps, Java,

wird stets als ”write once, run anywhere”-Sprache [Ehr10] beworben. Diese Bezeichnung macht

schon deutlich, dass es darauf ankommt, mit Java möglichst portable Anwendungen erstellen zu

können. Sie sollen idealerweise auf jedem Java-fähigen Gerät funktionieren. Auch Android baut

auf diesem Gedanken auf: Ein Open-Source-System für alle mobilen Geräte. Da letztere auf den

unterschiedlichsten Prozessor- und Hardwarearchitekturen aufbauen können, ist eine Abstrakti-

on von der Hardwareebene durch spezielle, virtuelle Maschineninstruktionen sinnvoll. Dadurch

können sämtliche Apps ohne weitere Anpassungen am Programmcode ausgeführt werden, solange

eine auf die Hardwareplattform angepasste VM existiert.

Anders als beispielsweise die als Java-VM übliche JVM führt die DVM nicht normalen Java-

Bytecode aus; hier ist stattdessen alles auf maximale Speichereinsparung optimiert, da Mobilge-

räte eine vergleichsweise geringe Leistung und Speicherkapazität aufweisen. So interpretiert die

DVM speziell optimierten Code, der in der angesprochenen Datei classes.dex im APK steht.

Nach der routinemäßigen Kompilierung des Java-Quellcodes in Java-Bytecode sorgt das Tool dx

für eine Umwandlung der Class-Dateien in den Dalvik-Executable-Code (dex-Code) [Bec11]. Es

existieren Dekompilierprogramme, die versuchen, aus dem dex-Code den ursprünglichen Java-

Quelltext wiederherzustellen. Dies führt jedoch aufgrund der großen Optimierung durch das

Programm dx in den meisten Fällen zu Code, der nicht der korrekten Java-Syntax entspricht

oder gar nicht erst dekompiliert werden kann.

Ein Beispiel für den optimierten dex-Code ist in Tabelle 2.1 vermerkt. Generell lassen sich

19


Dalvik-Bytecode Java-Bytecode

add-int d0, s0, s1 iload s0

iload s1

iadd

istore d0

Tabelle 2.1 Beispiel für eine mit DVM-Instruktionen mögliche Einsparung von drei Instruktionenbei einer einfachen Integer-Addition gemäß [Hua12].

durch die Nutzung der DVM rund 50% an Instruktionen in der VM einsparen. Da einzelne

dex-Instruktionen allerdings komplexer sind, ist auch der Programmcode der VM größer. Damit

ist die Ausführung einer einzelnen Instruktion also entsprechend langsamer. [Hua12]

Das Starten der Anwendungen in einem eigenen Prozess und einer gesonderten virtuellen Ma-

schine hat darüber hinaus Sicherheitsvorteile. Die Anwendungen teilen sich keinen gemeinsamen

Speicherbereich und die Stabilität des Systems wird erhöht, da ein abstürzendes Programm nur

die jeweilige VM mit abstürzen lassen kann – nicht das Betriebssystem selbst. Schwierigkeiten

bereitet dies hingegen der Interprozesskommunikation, da Apps so nur über Umwege kommuni-

zieren können.

Neben der eigenen VM wird eine Anwendung unter Android auch mit einer individuellen User-ID

versehen und gestartet, die zur Installationszeit für jede App individuell generiert wird. Zugrif-

fe auf Dateien anderer Anwendungen werden also spätestens vom Android zugrundeliegenden

Linux-Kernel unterbunden, da hier User-IDs zur Identifikation von Zugriffsrechten genutzt wer-

den (Discretionary Access Control). [BP09, 17 ff.] Da auch die Zugriffsberechtigungen von Spei-

cherbereichen unter Unix-Systemen mit der User-ID verwaltet werden, können Anwendungen

hierdurch nicht auf andere Bereiche des Arbeitsspeichers zugreifen. Sollen Anwendungen daher

im gleichen Prozess gestartet werden, müssen sie über einen speziellen Eintrag im Manifest die

gleiche User-ID anfordern. [dev]

Durch die Abschottung der Programme spricht man von einer Sandbox. Die Sandbox kon-

trolliert jegliche Zugriffe auf Hard- und (fremde) Softwarekomponenten. Zum Verlassen der

Sandbox sind im Fall von Android Permissions notwendig (siehe Kapitel 4.3.2, Permissions

(Systemebene)).

20

Kapitel 3

Was sind Broadcasts?

Broadcasts werden sowohl dazu genutzt, innerhalb der eigenen Anwendung mit verschiedenen

Komponenten (zum Beispiel Threads) zu kommunizieren, als auch anwendungsübergreifende

Kommunikation (und damit Interprozesskommunikation) zu realisieren. Da Apps unter Android

in einer Sandbox ausgeführt werden, werden hierzu die Grenzen der jeweiligen VM überschritten.

Auch das Betriebssystem schickt Broadcasts an andere Anwendungen, zum Beispiel wenn der

Nutzer die Uhrzeit verändert oder ein Anruf eingeht. Damit können Apps ohne großen Aufwand

auf systemrelevante Ereignisse reagieren.

Wenn man der Einfachheit halber von verschickten Nachrichten spricht, so sind damit eigentlich

Intents gemeint; sie werden vom Programmierer bzw. von der App erzeugt und vom Android-

System an die Ziele ausgeliefert.

3.1 Broadcast-Receiver

Um Broadcast-Intents empfangen und verarbeiten zu können, muss die jeweilige Anwendung

einen Broadcast-Receiver registrieren. Es gibt verschiedene Möglichkeiten der Registrierung, die

an dieser Stelle noch einmal ausführlicher vorgestellt werden sollen.

Allen Registrierungsarten ist gemein, dass eine Instanz der abstrakten Klasse BroadcastReceiver

implementiert werden muss. In der onReceive()-Methode wird dann festgelegt, welcher Code

beim Empfang eines Broadcasts ausgeführt werden soll. Google nennt folgenden interessanten

Hinweis zur onReceive()-Methode:

21

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-Apps3.1. BROADCAST-RECEIVER

When it runs on the main thread you should never perform long-running opera-

tions in it (there is a timeout of 10 seconds that the system allows before considering

the receiver to be blocked and a candidate to be killed). [Good]

Normalerweise läuft die onReceive()-Methode im Main-Thread der App. Es ist daher zu emp-

fehlen, die Verarbeitung des Broadcasts in einen neuen Thread auszulagern, wenn Berechnungen

ausgeführt werden sollen, die länger als wenige Sekunden dauern.

3.1.1 Statische Broadcast-Receiver

Statische Broadcast-Receiver warten immer auf eingehende Broadcasts – also auch, wenn die App

nicht gestartet ist. Sie werden im Manifest des Programms registriert. Dazu wird optional ein

Intent-Filter definiert, der angibt, dass die App auf einen impliziten Intent mit der entsprechenden

Bezeichnung wartet. Wird keiner angegeben, lässt sich der Broadcast-Receiver nur durch explizite

Intents aufrufen, wie unter Kapitel 4.3.3, Explizite Verwendung (Systemebene) beschrieben.

Code 3.1 Auszug des Manifests für ein typisches Broadcast-Receiver-Beispiel

1 <application (...)>2 (...)34 <receiver android:name="MyBroadcastReceiver">5 <intent -filter>6 <action android:name="android.intent.action.←↩

TIMEZONE_CHANGED" />7 </intent -filter>8 </receiver>9 </application>

In Code 3.1 wird festgelegt, dass die Klasse MyBroadcastReceiver des aktuellen Projekts

auf den Broadcast mit dem Action-String android.intent.action.TIMEZONE_CHANGED re-

agieren soll. Ändert der Nutzer des Geräts die Zeitzone, verschickt das System automatisch

den entsprechenden Broadcast. Durch den Filter wird dann gemäß der Abbildung 2.3 aus

Kapitel 2.3.1, Konzepte der Anwendungsprogrammierung unter Android die Methode

MyBroadcastReceiver.onReceive() aufgerufen.

Im Manifest gibt es verschiedene Parameter, die der Programmierer zur Spezifizierung des stati-

schen Receivers angeben kann. Sicherheitsbezogen besonders relevant sind die android:exported-

und die android:permission-Eigenschaft. Mit diesen Optionen lässt sich einschränken, wer dem

Receiver Nachrichten schicken kann. Sie werden in Tabelle 3.1 näher beschrieben. Liegt keine

22

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-AppsKAPITEL 3. WAS SIND BROADCASTS?

Tabelle 3.1 Auflistung der möglichen Parameter für Receiver im Manifest nach [Gook].

Parameter Mögliche Werte Bedeutung

android:enabled [''True'' | ''False''] Ist der Broadcast-Receiver aktiviert undkann er Broadcasts empfangen?

android:exported [''True'' | ''False''] Können andere Apps Broadcasts an diesenReceiver schicken? Sobald der Receiver ei-nen Intent-Filter angibt und diesen Para-meter nicht weiter definiert, verwendet dasSystem true als Standardwert – ansonstenfalse.

android:icon Drawable resource Verweist auf eine Bilddatei. Damit kanndem Receiver ein Symbol zur Visualisie-rung zugeordnet werden.

android:label String resource Ein String, der zur textuellen Beschrei-bung des Receivers dient.

android:name BroadcastReceiver Bezeichnung der Klasse, dieBroadcastReceiver implementiert.

android:permission String Bezeichnet die Permission, die eine Appbesitzen muss, um Broadcasts an diesenReceiver schicken zu dürfen (vgl. Kap.4.3.2). Wird dieser Parameter weggelas-sen, wird (falls vorhanden) die Permissionvom übergeordneten <application>-Tagvererbt.

android:process String Ermöglicht es, den Broadcast-Receiver ineinem anderen Prozess laufen zu lassen.Dadurch können verschiedene Apps Recei-ver im selben Prozess starten, was die Res-sourcenverwendung reduzieren kann.

Absicherung durch Permissions oder vergleichbare Konzepte vor, reagiert die Anwendung auf

jeden empfangenen Broadcast.

Code 3.2 Aufbau der MyBroadcastReceiver-Klasse.

1 public class MyBroadcastReceiver extends BroadcastReceiver {23 @Override4 public void onReceive(Context arg0, Intent arg1) {5 //Show toast on receival6 Toast.makeText(arg0, "Broadcast received!", Toast.LENGTH_LONG)←↩

.show();7 }89 }

23

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-Apps3.1. BROADCAST-RECEIVER

Abbildung 3.1 Eine Toast-Benachrichtigung nach Ändern der Zeitzone.

In Code 3.2 ist eine beispielhafte Implementierung einer Receiverklasse dargestellt. Die on-

Receive()-Methode, die als Einstiegspunkt dient, wenn ein Broadcast empfangen wurde, zeigt

eine Toast-Benachrichtigung auf der GUI an (Abb. 3.1).

Trotz der Trennung zwischen Code und Manifest können diese Receiver-Komponenten auch im

Code deaktiviert und aktiviert werden. Hierzu kann die Methode setComponentEnabledSetting-

(ComponentName componentName, int newState, int flags) aus dem Paket android.

content.pm.PackageManager verwendet werden.

Es gibt Broadcasts, die nicht auf statischem Wege empfangen werden können (zum Beispiel

android.intent.action.BATTERY_CHANGED) [Goof]. Hierzu muss der Empfänger dynamisch de-

klariert werden, wie im Folgenden beschrieben.

3.1.2 Dynamische Broadcast-Receiver

Dynamische Broadcast-Receiver werden zur Laufzeit des Programms erzeugt (zum Beispiel durch

den Klick auf einen bestimmten Button in der GUI). Anders als statische Broadcast-Receiver

werden dynamische folglich im Code selbst definiert – also auch spätestens mit dem Beenden der

App wieder zerstört. Ein Beispiel ist in Code 3.3 ersichtlich.

Code 3.3 Dynamisches Binden an den Intent-Filter aus Code 3.1.

1 @Override2 protected void onCreate(Bundle savedInstanceState) {3 (...)4 this.registerReceiver(new MyBroadcastReceiver(), new ←↩

IntentFilter("android.intent.action.←↩TIMEZONE_CHANGED"));

5 }

24


Ähnlich wie schon beim statischen Receiver werden bei der dynamischen Variante der Intent-

Filter und auch die abhandelnde Broadcast-Receiver-Klasse festgelegt. registerReceiver() ist

überladen und hat alternativ eine Variante, die die Angabe einer Permission als dritten Parameter

ermöglicht. Das entspricht dann dem Parameter android:permission aus Tabelle 3.1.

Genau wie auch statische Broadcast-Receiver können dynamische auf mehrere unterschied-

liche Intents auf einmal warten. Hierzu können beim IntentFilter-Objekt über die Me-

thode addAction() zusätzliche Action-Strings angegeben werden. Ein direktes Pendant zur

android:exported-Eigenschaft gibt es an dieser Stelle nicht. Dafür muss der LocalBroadcast-

Manager verwendet werden.

Wird der Broadcast-Receiver beim Beenden der startenden Activity nicht deregistriert, wirft das

System eine dazugehörige android.app.IntentReceiverLeaked-Exception.

3.2 Arten von Broadcast-Intents

Broadcasts können sowohl seriell als auch simultan verschickt werden. Mit bestimmten Parame-

tern kann man, wie schon beim Empfang, Einfluss auf die Sicherheit nehmen. Die Intent-Arten

werden an dieser Stelle erläutert. In Tabelle 3.2 werden sie dann abschließend verglichen.

3.2.1 Normaler Broadcast

Beim Aufruf von sendBroadcast() wird ein Broadcast asynchron an alle anderen Anwendungen

verschickt, die einen entsprechenden Broadcast-Receiver deklariert haben. Die Reihenfolge ist

nicht-deterministisch, mehrere unterschiedliche Receiver können die Nachricht auch gleichzeitig

erhalten. [Good] Ein Prioritätswert bei der Deklaration des zum Receiver gehörenden Intentfilters

hat durch die nicht vorhandene Serialität keinerlei Auswirkungen [Goog].

Code 3.4 Verschicken eines normalen Broadcasts.

1 package com.example.simplebroadcastsender;23 import (...);45 public class MainActivity extends Activity {6

25

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-Apps3.2. ARTEN VON BROADCAST-INTENTS

7 @Override8 protected void onCreate(Bundle savedInstanceState) {9 super.onCreate(savedInstanceState);

10 setContentView(R.layout.activity_main);1112 Intent i = new Intent("com.example.myBroadcast");13 i.putExtra("credentials", "username and password");14 sendBroadcast(i);15 }1617 }

Um einen Broadcast zu verschicken, muss zunächst ein entsprechender Intent definiert werden.

Intents können über sogenannte Extra-Felder mit weiterem Inhalt versehen werden. Im Fall

von Code 3.4 wird ein einfacher String als Zusatzinformation hinterlegt. Dieser kann später

problemlos von anderen Anwendungen mit i.getExtra() ausgelesen werden. So kann man nicht

nur ”Signale” verschicken, sondern diese auch mit Inhalt und weiteren Parametern versehen.

Besonders interessant ist es, wenn hier Zugangsdaten übergeben werden.

3.2.2 Sticky Broadcasts

Ein Sticky Broadcast verbleibt im System, bis removeStickyBroadcast() aufgerufen wird. Jeder

dazugehörige Broadcast-Receiver, der nach dem Verschicken des Sticky Broadcasts registriert

wird, erhält diesen Broadcast nachgeliefert.

Existieren mehrere passende Sticky Broadcasts im System, wird die Methode onReceive() des

Receivers für jedes der Objekte aufgerufen. Weiterhin wird bei der Registrierung willkürlich

ein einzelner Sticky Broadcast, der dem angegebenen Filter entspricht, als Rückgabewert von

registerReceiver() zurückgeliefert (bevor er anschließend noch einmal an den Receiver aus-

geliefert wird). [Gooe]

Damit eine App Sticky Broadcasts verschicken kann, ist die Angabe einer zusätzlichen Permission

im Manifest notwendig, wie in Code 3.5 dargestellt.

Code 3.5 Anpassung im Manifest.

1 <uses-permission android:name="android.permission.BROADCAST_STICKY" />

Code 3.6 Verwendung eines Sticky Broadcast.

1 package com.example.simplestickybroadcastsender;2

26


3 import (...);45 public class MainActivity extends Activity {67 @Override8 protected void onCreate(Bundle savedInstanceState) {9 super.onCreate(savedInstanceState);

10 setContentView(R.layout.activity_main);1112 Intent i = new Intent("com.example.myBroadcast");13 i.putExtra("credentials", "username and password");14 sendStickyBroadcast(i);1516 }17 }

Um einen Sticky Broadcast zu verschicken, muss in der verschickenden Klasse dann nur noch

sendBroadcast() durch sendStickyBroadcast() ersetzt werden (Code 3.6).

Da zum Empfang gewöhnliche BroadcastReceiver-Instanzen verwendet werden, muss man sich

der Besonderheit bewusst sein, dass das Empfangen eines (unter Umständen nachgelieferten)

Sticky Broadcast nicht unbedingt bedeutet, dass eine bestimmte Situation im Moment des Emp-

fangs eingetreten ist.

Mit dieser Vorgehensweise lassen sich Nachrichten vorhalten, die über einen längeren Zeitraum

interessant sind. Gleichzeitig lassen sich damit Daten über die Extra-Felder zwischenspeichern

und im Nachhinein abrufen, auch von anderen Anwendungen aus. Eine Besonderheit ist, dass

die sendende Anwendung auch beendet werden kann – der Sticky Broadcast bleibt trotzdem im

System und für andere Anwendungen abrufbar.

Gibt die Methode intent.filterEquals() für einen als Sticky Broadcast zu sendenden Intent

und einen bereits gespeicherten true zurück, ersetzt der neue den alten. Bei filterEquals()

werden eventuelle Unterschiede in den Extra-Feldern nicht untersucht. [App]

Sticky Broadcasts sollten nicht mehr verwendet werden, da sie aufgrund von diversen Sicher-

heitsproblemen (vgl. 4.2, Besonderheiten bei speziellen Broadcast-Arten) seit Android-

Version 5.0 als ”veraltet” markiert sind [Gooe].

3.2.3 Ordered Broadcasts

Neben den Sticky Broadcasts gibt es noch eine weitere ”außergewöhnliche” Möglichkeit, Broad-

casts zu verschicken. Hierzu wird die asynchrone Methode sendOrderedBroadcast() benutzt.

27

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-Apps3.2. ARTEN VON BROADCAST-INTENTS

Es gibt eine Überladung, um Permissions zu verwenden.

Ordered Broadcasts sind nützlich, wenn man die Reihenfolge bei der Zustellung der Broadcasts

beeinflussen möchte. Wie schon zuvor beschrieben, können Intent-Filter Prioritäten definieren.

Der Receiver mit dem Intent-Filter der höchsten Priorität erhält den jeweiligen Intent zuerst.

Gibt es mehrere Broadcast-Receiver mit passenden Intentfiltern der gleichen Priorität, so er-

halten diese den Intent in undefinierter Reihenfolge, jedoch nach wie vor nacheinander [Alb11].

Dieses undefinierte Verhalten bei Intentfiltern der gleichen Priorität existiert auch bei implizit

aufgerufenen Services – jedoch wird dann nur ein (zufällig ausgewählter) Service gestartet.

Bei Ordered Broadcasts ist es möglich, den nachfolgenden Receivern Daten zu übergeben. Damit

kann ein Receiver Informationen eines Broadcasts verarbeiten und in überarbeiteter Form an

den nächsten weitergeben. Die originalen Broadcastdaten sind jedoch weiterhin über den Intent,

der der onReceive()-Methode übergeben wird, abrufbar. [Alb11]

Zum Setzen und Lesen dieser Zusatzinformationen können die Methoden setResult() und

getResult() verwendet werden. Mit der Angabe eines zusätzlichen Receivers ist es mit einer

Überladung der sendOrderedBroadcast()-Methode auch für die sendende App möglich, den

Rückgabewert des letzten Empfängers auszuwerten.

Die weitere Auslieferung von Broadcasts an niedriger- und gleichpriorisierte Empfänger kann

bei Ordered Broadcasts unterwegs abgebrochen werden. Hierfür steht abortBroadcast() zur

Verfügung.

3.2.4 Sticky Ordered Broadcasts

Sticky Ordered Broadcasts stellen eine Variante der Sticky Broadcasts dar. Wie bei gewöhnlichen

Sticky Broadcast wird der übergebene Intent im System gespeichert, gleichzeitig werden die un-

terschiedlichen Broadcast-Receiver in der Art und Weise aufgerufen, wie bei Ordered Broadcasts.

Auch bei sendStickyOrderedBroadcast() kann ein zusätzlicher Broadcast-Receiver angegeben

werden, dessen onReceive()-Methode am Ende mit dem Resultat des letzten Receiver aufgerufen

wird.

Wie schon Sticky Broadcasts sind Sticky Ordered Broadcasts als veraltet markiert und sollten

nicht mehr verwendet werden.

28


Tabelle 3.2 Gegenüberstellung wesentlicher Eigenschaften der Broadcastarten. Vgl. [Dro15].

Charakteristik Normal Sticky Ordered StickyOrdered

Permissions zur Einschränkung derAuslieferung nutzbar?

Ja Nein Ja Nein

Haben Broadcast-Receiver Rückgabe-werte?

Nein Nein Ja Ja

Geordnete Auslieferung der Broad-casts?

Nein Nein Ja Ja

Nachträgliche Zustellung bereits aus-gelieferter Broadcasts?

Nein Ja Nein Ja

Abbrechen der Auslieferung durchBroadcast-Receiver möglich?

Nein Nein Ja Nein[Good]

29

Kapitel 4

Sicherheitsprobleme und Absicherungsmög-

lichkeiten

Da Broadcasts, wenn sie beim Versenden nicht weiter geschützt werden, von allen anderen An-

wendungen empfangen werden können, besteht das Risiko, dass ein Angreifer sensible Daten

abfangen könnte. Zusätzlich kann eine Schadsoftware Broadcasts unter einem Action-String ver-

schicken, der von einer anzugreifenden Anwendung überwacht wird. Gibt es hier beim Empfang

keine Absicherung, lassen sich eventuell verschiedenste Aktionen in der Zielanwendung auslösen.

So ist es denkbar, dass das Programm durch bestimmte Broadcasts oder Überlastung (Denial-of-

Service-Attacke) zum Absturz gebracht werden kann, was generell, aber insbesondere auch bei

sicherheitskritischen Programmen nicht wünschenswert ist.

Die Hauptursache für dieses Problem liegt darin begründet, dass der Intent-Namespace global

ist – das bedeutet, dass man Intents unter einem beliebigen Action-String versenden kann, ohne

dass dies reguliert wird [Good]. Lediglich einige vom System reservierte Action-Strings können

nicht für eigene Broadcasts verwendet werden [Goof].

Hätte andererseits jede Anwendung einen reservierten (und exklusiven) Namensbereich für In-

tent-Bezeichnungen, stünde dies dem Prinzip der Interprozesskommunikation im Wege.

Hat ein Angreifer vollen (physischen) Zugriff auf das Zielgerät, ist es ihm zuletzt immer noch

möglich, den Code einer anzugreifenden App nach dem Dekompilieren zu verändern, ihn mit

einem gefälschten Zertifikat neu zu signieren und die App dann manuell neu auf dem Gerät

zu installieren. So lassen sich Angaben im Manifest verändern, insbesondere Schutzlevels von

Permissions herabsetzen oder aber Sicherheitsmechanismen von Broadcast-Receivern entfernen.

31

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-Apps4.1. SICHERHEITSASPEKTE BEI DER DEKLARATION

4.1 Sicherheitsaspekte bei der Deklaration

Eine statische Deklaration der Broadcast-Receiver im Manifest ermöglicht es einem Angreifer,

die Angreifbarkeit des Empfängers besonders einfach einzuschätzen. Dies liegt daran, dass die

Entwickler für im Manifest definierte Broadcast-Receiver auch an genau dieser Stelle Angaben zu

den üblicherweise verwendeten Sicherheitsmaßnahmen machen müssen (zum Beispiel Angaben

zur Nutzung von Permissions oder spezielle Einstellungen zum exported-Wert). Weiterhin kann

das Manifest nicht obfuskiert werden, sodass man den XML-Code nach der Konvertierung aus

dem Binärformat immer im Klartext lesen kann.

Registriert man einen statischen Broadcast-Receiver im Manifest, der implizit mit systemreser-

vierten Intent-Filtern adressiert werden soll, muss man bedenken, dass es für Schadsoftware im-

mer noch die Möglichkeit gibt, diesen explizit zu adressieren. Wird ein solcher Broadcast-Receiver

gestartet, bedeutet das also nicht zwingend, dass das erwartete, systemrelevante Ereignis auch

wirklich eingetreten ist. Eine Absicherungsmöglichkeit ist in Kapitel 4.4 beschrieben.

Bei dynamischen Deklarationen gibt es das Problem, dass es eine Überladung der register-

Receiver()-Funktion gibt, die ohne Permission-Angabe funktioniert. Aus diesem Grund werden

von den Entwicklern in einigen Fällen keine Berechtigungsanforderungen an Anwendungen ge-

stellt, die Broadcasts an den Receiver schicken möchten.

Häufig wird der Code einer App vor der Veröffentlichtung obfuskiert. Dadurch lassen sich Me-

thoden nur schwer ihrer ursprünglichen Bedeutung zuordnen – auch der Verzweigungsgrad des

Codes kann durch den Obfuskiervorgang stark erhöht werden. Da dynamische Deklarationen

im normalen Java-Code der App vorgenommen werden, ist es nach der Obfuskierung schwierig,

zu ermitteln, wann welcher registerReceiver()-Aufruf gestartet wird und wann ein Receiver

wieder deregistriert wird. Das wird dem Motto ”security by obscurity” gerecht. Gleichzeitig weiß

man nicht immer, ob und wann ein Broadcast-Receiver überhaupt verwendet wird und welche

Absicherungen benutzt wurden, da Codeteile beim Dekompilieren verloren gehen können. Zusätz-

lich kann es sein, dass ein Broadcast-Receiver innerhalb von wenigen Sekunden den Broadcast

erhält, auf den er wartet, und dann unregisterReceiver() aufgerufen wird – so kann ein kur-

zes Zeitfenster entstehen, in welchem man als Angreifer versuchen muss, Nachrichten an den

Broadcast-Receiver zu verschicken.

Ein weiteres gefährliches Sicherheitsrisiko existiert im Zusammenhang mit der Deklarationsrei-

henfolge von Permissions. Unter Kapitel 4.3.2, Permissions (Systemebene) wird beschrieben,

32

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-AppsKAPITEL 4. SICHERHEITSPROBLEME UND ABSICHERUNGSMÖGLICHKEITEN

wie Permissions zur Einschränkung der Broadcastverteilung verwendet werden können. Schon im

Vorfeld zum genannten Kapitel soll hier beschrieben werden, welche Problematiken es bei der

Definition dieser Berechtigungen geben kann.

Definiert eine Anwendung eine Permission in ihrem Manifest durch einen <permission>-Tag,

wird diese bei der Installation ins System aufgenommen. Definiert eine weitere Anwendung spä-

ter dieselbe Permission, so werden die bereits gespeicherten Informationen nicht überschrieben

und der entsprechende Tag im Manifest ohne Warnung ignoriert. Dieses Verhalten kann von ei-

nem Angreifer ausgenutzt werden. Es ist ein Szenario denkbar, bei dem eine Schadsoftware (App

B) vor einer Anwendung installiert wird, die anzugreifen ist (App A). Nehmen wir an, die ver-

trauenswürdige Anwendung App A deklariert eine Permission und hat den Protection-Level auf

Signature festgelegt. App B deklariert dieselbe Permission, jedoch mit Protection-Level normal.

Wird App B zuerst installiert, so existiert die Permission im System mit der Berechtigungsstufe

normal – jede Anwendung kann sie ohne Warnmeldung (und vor allem ohne Signaturprüfung!)

anfordern. Ebenfalls legt so einzig App B die Permission-Beschreibung fest, die dem Nutzer zur

Installationszeit angezeigt wird. Hier können dem Nutzer also problemlos irreführende Informa-

tionen angezeigt werden.

Werden dann sensible Broadcasts verschickt, kann App B unbemerkt mitlesen.1 So können auch

ungewollt Services gestartet werden, die eigentlich durch eine Permission geschützt werden.

Um dieses Sicherheitsproblem zu verhindern, müssen spezielle Prüfungen durchgeführt werden.

Eine Möglichkeit ist es, zu testen, ob die gewünschte Permission bereits im Vorfeld von einer

anderen Anwendung definiert wurde und die Installation oder Programmausführung dann ggf.

abzubrechen.2

Ähnlich problematisch ist es, wenn eine App eine Permission verwenden möchte, die noch nicht

deklariert wurde. Die Permission-Anforderung wird dann stillschweigend ignoriert.

Mit der Android-Version 5.0 wurde dieses Verhalten geändert: Hier können nur Apps, die mit dem

gleichen Zertifikat signiert wurden, schon existierende Permissions erneut definieren – ansonsten

schlägt die Installation fehl. [Mur15b]

Ein ähnliches Problem existiert im Kontext von Services. Die Serviceklassen können – gemäß

der zwei Intentarten – auf verschiedene Arten adressiert werden: Explizit und implizit (vgl. Ka-

pitel 2.3.1, Konzepte der Anwendungsprogrammierung unter Android). Wird ein Service

explizit aufgerufen, müssen Ziel-Package-Name (bzw. Ziel-Kontext) und -Klassenname im Code

1 Siehe hierzu für weitergehende Informationen [Mur15b].2 Hierzu kann man zum Beispiel das Toolkit aus [Mur15a] verwenden.

33

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-Apps4.2. BESONDERHEITEN BEI SPEZIELLEN BROADCAST-ARTEN

eindeutig festgelegt werden. Da Package-Names für jede (installierte und im Google Play Store

verfügbare) Anwendung eindeutig sind und das unberechtigte Überschreiben dieser Anwendung

durch die digitale Signatur verhindert wird, ist diese Aufrufmethodik als die sicherste einzustufen:

Exportiert eine andere Anwendung einen Service mit identischem Klassennamen, verhindert der

unterschiedliche Package-Name, dass dieser fälschlicherweise ausgeführt wird. Natürlich ist hier

die o.g. Problematik mit der Installationsreihenfolge zu beachten: Wird die Schadsoftware zuerst

installiert, kann sie problemlos einen bestimmten, zu der Zeit im System noch nicht existierenden

Package-Name annehmen.

Werden Services hingegen implizit aufgerufen, kann eine schadhafte Anwendung einen eigenen

Service mit einem zum Action-String passenden Intent-Filter exportieren. Die Prioritätseinstel-

lung des Intentfilters, android:priority, kann auf den höchstmöglichen Wert gesetzt werden,

sodass, falls keine weitere Prüfung erfolgt, je nach Anwendungsumgebung der schadhafte Service

gestartet wird. Der kann dann unter Umständen sensible Extra-Informationen aus dem Intent

abfangen. Da man beim Aufruf von Services keine Permissions der Zielanwendung voraussetzen

kann, ist eine Absicherungsmöglichkeit das manuelle Prüfen der Anwendungssignatur der Ziel-

serviceklasse. Dies ist zum Beispiel unter [Com15] beschrieben und im Paket SignatureUtils des

Toolkits [Mur15a] implementiert.

4.2 Besonderheiten bei speziellen Broadcast-Arten

Da Sticky Broadcasts im System verbleiben, bis sie explizit gelöscht werden oder das System

neu gestartet wird, besteht hier umso mehr das Risiko, dass der Entwickler vergisst, den Broad-

cast aus dem System zu entfernen. Ebenso kann es sein, dass die Anwendung abstürzt, bevor

der Broadcast entfernt wurde. So lassen sich noch im Nachhinein Daten abrufen, obwohl die

eigentliche Anwendung längst beendet ist.

Jede App kann Sticky Broadcasts unter einem beliebigen Action-String versenden, sie verändern

oder löschen. Schon im Voraus zu Kapitel 4.3.2, Permissions (Systemebene) sei an dieser

Stelle angemerkt, dass es bei Sticky Broadcasts nicht die Möglichkeit gibt, einen sicheren Aufruf

von sendStickyBroadcast zu verwenden, um Permissions zu benutzen.

Aus diesen Gründen sind Sticky Broadcasts als unsicher anzusehen, weshalb sie seit Android-

Version 5.0 als veraltet markiert sind. [Gooe].

34


Verschickt eine Anwendung Broadcasts vom Ordered-Typ, so kann man eine App erstellen,

die einen Intent-Filter definiert, der mit einer höheren Priorität auf die jeweiligen Intents war-

tet, als die anzugreifende Applikation. Nun ist sichergestellt, dass der Broadcast in jedem Fall

vor der Zielanwendung bei der Schadsoftware angelangt. Man kann den Broadcast jetzt abbre-

chen oder auch die Daten manipulieren, falls eine der nachfolgenden Receiver-Klassen diese mit

getResult() abruft. So erreichen etwaige Warn- oder Fehlermeldungen ihr Ziel unter Umstän-

den nicht (was einer Denial-of-Service-Attacke entspräche) oder sie lassen sich von der Bedeutung

her invertieren.

Da man mit Ordered Broadcasts sowohl bei den Receivern als auch in der sendenden Klasse

die Rückgabewerte des jeweils vorherigen (bzw. letzten) Broadcast-Receiver verarbeiten kann,

kann ein Angreifer einen Receiver mit niedrigster Priorität definieren und diese Werte damit

manipulieren. Der Wert für android:priority sollte zwischen -1000 und 1000 liegen [Goog],

auch wenn durch eigene Tests nachgewiesen werden konnte, dass größere und kleinere Zahlen

ebenfalls das erwartete Ergebnis herbeiführen. Diverse Quellen weisen darauf hin, dass man sich

trotz allem an positive Prioritätswerte halten soll:

Use non-negative priorities only. Negative ones are valid but will result in weird

behavior most of the time. [Alb11]

4.3 Absicherungsmöglichkeiten beim Versenden von Broadcasts

Verschickt eine App einen Broadcast, kann jede andere App diesen empfangen, wenn sie einen

entsprechenden Broadcast-Receiver registriert hat und keine Absicherungsmöglichkeiten gewählt

wurden. Der Sender erhält keine Benachrichtigung, ob und von wem die Nachricht gelesen wur-

de. Vertrauenswürdige Apps können dadurch unbeabsichtigt zu trojanischen Pferden werden; zur

Installationszeit sichert der Android-Nutzer ihnen bestimmte Permissions zu, wie beispielsweise

das Lesen von bestimmten Daten auf einem externen Speichermedium. Verschickt die vertrau-

enswürdige App diese Informationen dann ungeschützt in einem Broadcast, können diese von

Schadsoftware abgefangen werden, wodurch letztere an Informationen gelangt, auf die sie eigent-

lich keinen Zugriff haben dürfte.

Die angesprochenen Sicherheitsprobleme lassen sich auf zweierlei Ebenen angehen: Nach Unter-

suchen diverser Gegenmaßnahmen können diese Lösungen am ehesten als Umsetzungen auf der

35

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-Apps4.3. ABSICHERUNGSMÖGLICHKEITEN BEIM VERSENDEN VON BROADCASTS

Systemebene und der Informationsebene kategorisiert werden. Mit Umsetzungen auf Systemebe-

ne werden im Folgenden Sicherheitsmaßnahmen beschrieben, die vom Android-System umgesetzt

werden und durch Setzen bestimmter Parameter oder ähnlichem vom Programmierer aktiviert

werden können. Lösungen auf der Informationsebene setzen voraus, dass die per Broadcast ver-

schickten Informationen an sich durch Sicherheitsmaßnahmen verändert oder ergänzt werden.

4.3.1 Verschlüsselung (Informationsebene)

Am ehesten ist es natürlich denkbar, die Extras verschickter Broadcasts zu verschlüsseln. Dies

würde eine Lösung auf Informationsebene darstellen, da die verschickten Nutzdaten verändert

werden müssen, um einen Angreifer vom Mitlesen abzuhalten.

Implementieren ließe sich eine solche Verschlüsselung an sich recht einfach. Wenn man einem

Broadcast einen Extra-Eintrag hinzufügen möchte, so muss letzterer Parcelable implemen-

tieren, ein Android-eigenes Serialisierungsinterface. Dieses ist deutlich effizienter als die Java-

eigenen Serialisierungsmethoden und -klassen (wie zum Beispiel Serializable) [MKA15, 297].

Parcelable-Klassen müssen die Methode writeToParcel() implementieren, die festlegt, wie das

Objekt serialisiert wird. An dieser Stelle könnte man eine Verschlüsselung der Klassenvariablen

einbauen. Die deserialisierende Methode createFromParcel() könnte dann die Entschlüsselung

implementieren. Werden dann für den normalen Gebrauch abseits des Broadcastkontextes die

klasseneigenen Getter- und Settermethoden verwendet, geht keinerlei Performanz verloren, da

an der Stelle keine Verschlüsselung stattfindet. Gleichzeitig bleibt sichergestellt, dass keine un-

verschlüsselten Daten in Broadcasts übertragen werden.

Mit einer entsprechend starken symmetrischen Verschlüsselung wird es einem Angreifer unmög-

lich, geschickte Daten im Klartext abzufangen und die Extra-Einträge mitzulesen. Dies gilt

jedoch nur, solange der Schlüssel unbekannt ist; dieser sollte nicht statisch sein, da der An-

greifer ihn ansonsten zum Beispiel durch Dekompilieren aus dem Quellcode extrahieren könnte.

Deshalb sind eigentlich Schlüsselvereinbarungsmechanismen wie das Diffie-Hellman-Verfahren

empfehlenswert, bei dem der Schlüssel zur Laufzeit dynamisch zwischen den Kommunikations-

partnern vereinbart wird, was den Prozess jedoch arg verkompliziert – und ein neues Problem

aufbringt: Wie stellt man sicher, dass wirklich die gewünschte Anwendung Partner beim Diffie-

Hellman-Schlüsselaustausch ist? Es könnte ein asymmetrisches Kryptoverfahren mit Zertifikaten

angewandt werden. Insbesondere bei vielen Broadcasts steigt die benötigte Rechenleistung (und

36


damit die benötigte Energie) dadurch aber ungefähr um den Faktor 1000 an [BSG14b, Folie 3],

was im Allgemeinen – zusammen mit der Verkomplizierung des Codes – selbstverständlich nicht

praktikabel ist.

Auch sind es nicht in jedem Falle die eigentlichen Nutzdaten, die interessant sind – das Empfangen

des Broadcast-Intents selbst kann für einen Angreifer bereits nützlich sein. So kann man sich ein

Szenario vorstellen, bei dem eine Alarmanlagen-App einen Broadcast unter einem bestimmten

Action-String verschickt, sobald der Nutzer die häusliche Alarmanlage aktiviert oder deaktiviert

hat. Der Angreifer muss hierzu nicht unbedingt wissen, was genau im Broadcast steht (zum

Beispiel ein eventueller Zugangscode oder ähnliches), sondern kann allein die Information des

stattgefundenen Broadcasts an einen potentiellen Einbrecher weiterleiten, wie auch folgendes

Zitat von Bormann, Sohr und Gerdes zeigt:

Oft ist die Tatsache einer Kommunikationshandlung bereits geheimzuhaltende

Information [BSG14a]

Hier ist also das Sicherheitsziel der Vertraulichkeit bzw. die Geheimhaltung in besonderem Ma-

ße gefährdet. In solch einem Fall hilft einem die Nutzung von Sicherheitsmaßnahmen auf der

Informationsebene nicht weiter. Es sind Lösungen auf der Systemebene gefragt.

4.3.2 Permissions (Systemebene)

Um festzulegen, wer gesendete Broadcasts empfangen kann, ist es empfehlenswert, Permissions

zu nutzen. Die sendende App kann dazu einen leicht modifizierten sendBroadcast()-Aufruf ver-

wenden. Diese Überladung der sendBroadcast()-Funktion akzeptiert einen zweiten Parameter,

receiverPermission – ein String, der die Bezeichnung der Permission darstellt. Damit müssen

empfangende Apps die entsprechende Berechtigung aufweisen. Das Senden eines Broadcasts mit

einer Permission kann dann geschrieben werden als:

sendBroadcast(intent, "com.example.myPermission");.

Wie bereits an vorheriger Stelle erwähnt, definiert das Android-System bereits zahlreiche Permis-

sions, die der Anwendungsprogrammierer auch abseits des Broadcastkontextes verwenden kann

(und für bestimmte Aktionen auch muss). Eigene Permissions werden im Manifest definiert (Code

4.1).

37


Code 4.1 Deklaration einer Permission im Manifest

1 <permission android:name="com.example.myPermission"2 android:label="Name, der zur Installationszeit angezeigt wird."3 android:description="Beschreibung , die zur Installationszeit ←↩

angezeigt wird."4 android:protectionLevel="..." />

Nun sollen nicht alle Apps die Permission beliebig verwenden können – dann wäre der Schutz

nutzlos. Es gibt daher verschiedene Schutzlevels, die bei android:protectionLevel eingetragen

werden können. In Tabelle 4.1 werden sie gegenübergestellt. Je nachdem, wie eine Permission ge-

schützt ist, ist es für externe Anwendungen einfach bis unmöglich, an die Permission zu gelangen

und damit eine Nachricht mitzulesen, die unter Nutzung der Berechtigung verschickt wurde.

Der bei protectionLevel einzusetzende Parameter hängt davon ab, welchen Einsatzzweck man

mit dem Broadcast verfolgt. Wenn man selbstdefinierte Permissions verwendet, um zu verhindern,

dass andere Anwendungen Broadcasts an eigene Receiver schicken können oder dass Drittsoftware

Broadcasts abfangen kann, ist es in den meisten Fällen empfehlenswert, signature auszuwählen.

Mit Flags kann man weitere Einschränkungen zur Permissionvergabe machen. Zusammen mit

einem |-Symbol können sie an den android:protectionLevel-Wert angehängt werden. [Ele14,

38 ff.]

Der Nutzer wird über Berechtigungsanforderungen einer App zur Installationszeit benachrichtigt,

wie in Abb. 4.1 dargestellt. Er hat die Möglichkeit, die Installation abzubrechen, wenn er die an-

geforderten Berechtigungen für verdächtig hält, was ein Sicherheitsmerkmal des Android-Systems

ist. Permissions können auch dazu verwendet werden, einzuschränken, wer Services starten oder

eine Activity aufrufen kann.

Möchte man in einer App eine Permission verwenden, so ist ein Eintrag unter dem Bezeich-

ner <uses-permission> im Manifest notwendig (Code 4.2). Dann ist die Installationsreihen-

folge ebenfalls von Bedeutung: Eine App, die eine Permission deklariert, muss vor einer App

installiert werden, die ebendiese verwenden möchte. Wird die Reihenfolge vertauscht, ist der

<uses-permission>-Eintrag ungültig und wird vom System nicht beachtet, auch nicht nach

Neustart des Geräts.

Wird von einer Anwendung ein Broadcast mit einer Permission verschickt, lösen Broadcast-

Receiver nicht aus, wenn sie zwar auf den jeweiligen Intent warten, die dahinerstehende App

aber die Permission nicht angefordert hat. Somit erfährt eine Anwendung dann nichts von ei-

nem verschickten Broadcast. Das Sicherheitsproblem der Geheimhaltung des Stattfindens einer

38


Tabelle 4.1 Mögliche Werte und Flags für android:protectionLevel (Vgl. [Gooj], [Med+13,107]), [Ele14, 38 ff.])

ProtectionLevel Erklärung

normal Geringster Schutzlevel. Jede Anwendung kann die jeweilige Permission erhal-ten, der Nutzer wird nicht um Erlaubnis gefragt. Er kann sich jedoch in einerÜbersicht alle Permissions der App anzeigen lassen.

dangerous Die Anforderung einer als dangerous klassifizierten Permission muss bei derInstallation der App erst durch den Nutzer bestätigt werden.

signature Bei diesem Schutzlevel müssen anfordernde Apps mit dem gleichen Zertifikatsigniert worden sein, wie die App, die die Permission deklariert hat. DerBenutzer wird nicht um Erlaubnis gefragt, da das System eigenständig überdie Legitimation entscheiden kann.

signatureOrSystem Ähnlich wie signature, ermöglicht es jedoch auch Systemanwendungen ausder Systempartition, diese Permission zu erlangen. Typischerweise wird die-se Option eingesetzt, wenn ein angepasstes Android-System gleichzeitig vonunterschiedlichen Programmierern entwickelt wird und diese Zugriff auf einegemeinsame Permission benötigen. Der Fall wird an dieser Stelle nicht weiterbetrachtet, da er im Produktiveinsatz nur selten vorkommt.

system(Flag)

Das system-Flag setzt voraus, dass die anfordernde App auf der System-Partition installiert ist.

development(Flag)

Wird das Flag development hinzugefügt, so kann die jeweilige Permissionseit Android-Version 4.2 im Nachhinein dynamisch mit dem Tool pm über dieAndroid-Entwicklerkonsole hinzugefügt und entfernt werden.

39


Abbildung 4.1 Der Benutzer wird bei bestimmten Schutzlevels gefragt, ob er der Berechtigungs-anforderung zustimmt (links). Nach Klick auf einen Eintrag in der Liste wird eineBeschreibung angezeigt (rechts).

Kommunikation aus Kapitel 4.3.1, Verschlüsselung (Informationsebene) ist damit gelöst.

Code 4.2 Anforderung einer Permission im Manifest

1 <uses-permission android:name="com.test.canSendAndReceiveMyBroadcast"←↩/>

Gemäß dem folgenden Zitat aus der offiziellen Android-Entwicklerdokumentation, bezogen auf

ein Beispiel, in dem eine Permission zum Start einer Activity deklariert wird, ist es nötig, ne-

ben der Berechtigungsdeklaration mit <permission> die Berechtigung auch noch einmal mit

<uses-permission> anzufordern, wenn sie in der deklarierenden App benutzt werden soll.

Its [the permission’s] use must be requested in order for other components of the

application to launch the protected activity, even though the protection is imposed

by the application itself. [Gooc]

Umgesetzt wird dieses MAC-artige Prinzip der Permissions durch einen Referenzmonitor [EOM09].

Jede App erhält eine Menge von Permissions. Vor der Durchführung einer Action prüft der Re-

ferenzmonitor in Form der Android-Middleware, ob der Zugriff erlaubt ist – die notwendige

Berechtigung also in der Menge der Permissions der App ist. Es kann an dieser Stelle vorkom-

men, dass der Zugriff bei einer Komponente aus der eigenen App verweigert wird, wenn die

40


Anwendung die Permission zwar definiert, aber nicht selbst anfordert [EOM09], was auch das

vorherige Zitat zeigt.

4.3.3 Explizite Verwendung (Systemebene)

Alternativ ist es möglich, Methoden wie intent.setPackage(), intent.setClassName() und

ähnliche zu verwenden, um den Empfänger eines Broadcasts näher zu spezifizieren.

Mit intent.setPackage() ist es möglich, festzulegen, aus welchem Package ein Receiver stam-

men muss, damit der Broadcast zugestellt wird. Das System sucht potentielle Empfänger dann

nur in ebendiesem Anwendungspaket.

intent.setClassName() kann genutzt werden, wenn man genau weiß, welche Receiver-Klasse

aus welcher Anwendung den Intent empfangen soll. Hier muss jedoch bedacht werden, dass letz-

tere Methode nur mit Komponenten funktioniert, die im Manifest deklariert wurden. Es ist daher

nicht möglich, mit intent.setClassName() einen dynamisch registrierten Broadcast-Receiver

zu adressieren (vgl. hierzu [mik13]).

Die hier beschriebene Methode funktioniert auch für Sticky Broadcasts. Oft ist aber nicht nur

eine einzelne App das Ziel dieser Broadcasts, sodass setPackage() oder setClassName() dann

nicht verwendet werden können. In dem Fall dürfen keine sicherheitskritischen Informationen mit

den Sticky Broadcasts übermittelt werden.

Bei diesen Methoden ist weiterhin die unter 2.3.2.1, Der Signierungsprozess beschrie-

bene Problematik der Installationsreihenfolge relevant. Wird eine Schadsoftware auf dem Ge-

rät installiert, die erstmalig den gleichen Package-Name benutzt, wie die eigentlich erwartete

App, kann immer noch die falsche Komponente adressiert werden. Darüber hinaus werden über

setPackage() konkretisierte Intents erst ab Android-Version 4.0 sicher verarbeitet. Zuvor wur-

den die Parameter aus den genannten Methoden nicht beachtet. [Gooe] Explizite Adressierung

bietet sich in besonderem Maße an, wenn Broadcasts innerhalb der eigenen Anwendung (oder

innerhalb der eigenen Anwendungssammlung) verschickt werden sollen, da die benötigten In-

formationen wie Package-Name und Klassenname dem Entwickler dann in jedem Fall bekannt

sind.

41

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-Apps4.4. ABSICHERUNGSMÖGLICHKEITEN BEIM EMPFANG VON BROADCASTS

4.3.4 Lokale Einschränkung (Systemebene)

Weiß man von Vornherein, dass die Broadcasts nur innerhalb der eigenen App und den dazuge-

hörigen Threads (also: im selben Prozess) verschickt werden sollen, kann man die Auslieferung

auf diesen Kontext einschränken. Dazu bietet sich die Klasse LocalBroadcastManager an.

Werden mit dieser Klasse Broadcasts verschickt und mit ihr Broadcast-Receiver registriert, so

können von Apps außerhalb des eigenen Prozesses weder erstere empfangen noch Broadcasts

an letztere übermittelt werden. Auch ist das Nutzen des lokalen Managers deutlich effizienter

[Gooi], da das System zur Zustellung einen viel kleineren Empfängerkontext zu analysieren hat.

So entfallen viele potentielle Exploits und Möglichkeiten von Man-In-The-Middle-Angriffen, wo-

durch diese Möglichkeit des Broadcasts als am sichersten, wenn auch als nicht ganz so flexibel

anzusehen ist.

Generell funktioniert die Registrierung eines lokalen Receivers und das Verschicken eines lo-

kalen Broadcasts ähnlich wie in den vorherigen Kapiteln, weswegen hier auf ausführliche Co-

debeispiele verzichtet wird. Gesagt sei jedoch, dass die Methoden LocalBroadcastManager.

[un]registerReceiver() und LocalBroadcastManager.sendBroadcast() zum (De-)registrieren

und Versenden benutzt werden müssen.

Als Besonderheit existiert die Methode LocalBroadcastManager.sendBroadcastSync(), die

den Broadcast blockierend versenden kann und die reguläre Methodenausführung erst nach Abar-

beiten der onReceive()-Methoden aller Receiver fortsetzt. [Gooi] Eine Verwendung von Sticky-

oder Ordered Broadcasts ist nicht vorgesehen.

4.4 Absicherungsmöglichkeiten beim Empfang von Broadcasts

Anders als bei der Absicherung des Verschickens von Broadcasts geht es bei der Absicherung

des Empfangs darum, zu verhindern, dass unberechtigte Apps Broadcasts an einen registrierten

Receiver schicken können. Wird der Empfang nicht abgesichert, lassen sich eventuell ungewollt

Aktionen in der empfangenden Anwendung auslösen. Da letztere ggf. deutlich bedeutendere

Permissions besitzen kann als die Anwendung des Angreifers, könnte sie außerdem mit ganz

anderen Berechtigungen auf (ggf. bösartigen) Daten des Intents arbeiten und sie dann vielleicht

sogar an andere Komponenten, wie zum Beispiel Services weiterreichen.

42


Ähnlich wie schon beim Verschicken von Broadcasts kann man zunächst einmal auch beim

Empfang die Klasse LocalBroadcastManager nutzen, wenn Broadcasts innerhalb der eige-

nen Anwendung versendet werden. Die Verwendung ist denkbar einfach. Statt des Aufrufs

von registerReceiver() kann mit dem aktuellen Anwendungskontext context die Metho-

de LocalBroadcastManager.getInstance(context).registerReceiver() verwendet werden.

Hier gibt es keine speziell überladene Variante mit Permissions – dies ist jedoch auch nicht not-

wendig, da andere Anwendungen nicht auf diese Kommunikationsschnittstelle zugreifen können.

Zum Versenden von Broadcasts kann LocalBroadcastManager.getInstance(context).send-

Broadcast() verwendet werden. Es ist wichtig, zu beachten, dass Nachrichten, die über ein

gewöhnliches sendBroadcast() verschickt werden, nicht von einem durch den Aufruf von Local-

BroadcastManager.registerReceiver() registrierten Broadcast-Receiver empfangen werden.

Für statische Receiver kann man alternativ zum LocalBroadcastManager den Parameter android:-

exported (vergleiche Tabelle 3.1) im Manifest auf false setzen. Dann ist es anderen Anwendun-

gen auch nicht möglich, diesen zu kontaktieren. Verlässt man sich darauf, dass ein Broadcast-

Receiver implizit durch systemreservierte Action-Strings kontaktiert wird, sollte man in jedem

Fall in der onReceive()-Methode den Action-String überprüfen, um sicherzustellen, dass der

Broadcast-Receiver nicht unerwarteterweise explizit aufgerufen wurde. Hierzu kann getAction()

auf dem empfangenen Intent verwendet werden.

Weiterhin kann man Broadcast-Receiver mit Permissions schützen. Bei statischen Receivern

kann im Manifest der Parameter android:permission auf den Namen der gewünschten Per-

mission gesetzt werden. Deklariert man die Receiver dynamisch, kann eine Überladung von

registerReceiver() verwendet werden, die die Angabe einer Permission ermöglicht. Dann emp-

fängt der Receiver nur Broadcasts, wenn der Sender eine entsprechende Berechtigung besitzt.

43

Kapitel 5

Vorgehen bei einer typischen Broadcastana-

lyse

Dieses Kapitel dokumentiert das allgemeine Vorgehen bei den Analysen aus Kapitel 6, bei denen

konkrete Anwendungen auf Sicherheitsprobleme untersucht werden.

5.1 Vorbereitungen

Um herauszufinden, welche Broadcasts eine App verschickt, muss sie in den allermeisten Fällen

dekompiliert werden, da man keinen Zugriff auf den originalen Quellcode hat. Beim Dekompi-

lieren wird versucht, Maschinen- oder Bytecode zurück in den ursprünglichen Programmcode

zu überführen. Durch zahlreiche Optimierungen zur Kompilierzeit gehen diverse Informationen

verloren, die dann beim Dekompilieren nicht mehr verfügbar sind. Das wohl wichtigste Beispiel

hierfür sind Kommentare im Code, die nicht wiederherstellbar sind, da sie durch den Compiler

schon beim Übersetzen entfernt werden – sie liefern keinen Beitrag zum eigentlichen Programm.

Dadurch ist der erhaltene Code in den meisten Fällen nur eine Annäherung an den Ursprungs-

quelltext.

Es gibt diverse Tools, die es einem ermöglichen, Java-Code aus APK-Dateien zu generieren. In

Kapitel 2.3.2, Buildprozess und APK wurde bereits der Aufbau eines APK-Installationspakets

beschrieben – die Datei clases.dex ist im Kontext der Dekompilierung also besonders relevant.

Folgende Schritte sind dementsprechend notwendig, um den Java-Sourcecode zu erhalten:

45

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-Apps5.1. VORBEREITUNGEN

1. APK extrahieren

Die relevanten Dateien müssen aus dem APK-Archiv extrahiert werden. Neben dem dex-

Code könnten in anderem Kontext auch das Manifest, die Layout-Dateien oder die grafischen

Ressourcen interessant sein.

Häufig verwendete Tools: Programme, die das ZIP-Format lesen können (zum Beispiel

WinRar, WinZip, ...). Einige Programme (zum Beispiel dex2jar1) führen diesen Schritt au-

tomatisch gemeinsam mit Schritt 2 aus.

2. dex-Datei in class-Dateien aufteilen

Der Dalvik-Bytecode aus der classes.dex wird in Java-Class-Dateien übersetzt. Häufig

werden die Class-Dateien – je nach Tool – in einem JAR-Archiv zusammengefasst.

Häufig verwendete Tools: DARE2, dex2jar.

3. Class-Dekompilierung

Dieser Teil ist nicht mehr androidspezifisch, sondern bezieht sich nur noch auf die Umwand-

lung von Java-Class-Dateien in Java-Quellcode. Das Vorgehen ist identisch zur gewöhnlichen

Dekompilierung von Java-Programmen.

Häufig verwendete Tools: JD-GUI3, DJ Java Decompiler4

Auffällig ist, dass verschiedene Tools verschiedene Ergebnisse liefern – die Resultate unterscheiden

sich sowohl in der Qualität als auch inhaltlich. In dieser Arbeit hat sich eine Kombination aus

DARE und JD-GUI zur ersten Analyse bewährt. Große Codeteile, die bei der Verwendung von

DARE im dekompilierten Ergebnis zu finden waren, fehlten bei der Verwendung von dex2jar

immer wieder (beispielsweise waren die Informationen aus Code 6.3 unter Nutzung von dex2jar

nicht sichtbar).

Das neuere Tool JADX5 übernimmt alle drei oben genannten Schritte automatisch, wenn man ei-

ne APK-Datei öffnet. In sehr vielen Fällen lieferte es ein deutlich besseres Ergebnis als die anderen

Tools. Da es jedoch noch nicht ausgereift ist (derzeit ist Version 0.6.0 aktuell) schlägt die Dekom-

pilierung bei vielen Methoden fehl, sodass man dann teilweise nur registerbasierte Instruktionen

der VM erhält. Bei allen anderen genannten Tools zur Dekompilierung werden oft viele Klassen

einer zu dekompilierenden App zusammenhangslos im Wurzelverzeichnis des Quellcode-Ordners

platziert. Da sie dadurch innerhalb der anderen Java-Klassen nicht mehr ordnungsgemäß refe-

1 Projektwebseite: https://github.com/pxb1988/dex2jar2 Projektwebseite: http://siis.cse.psu.edu/dare/3 Projektwebseite: http://jd.benow.ca/4 Projektwebseite: http://www.neshkov.com/, kommerziell.5 Projektwebseite: https://github.com/skylot/jadx

46

https://github.com/pxb1988/dex2jar

http://siis.cse.psu.edu/dare/

http://jd.benow.ca/

http://www.neshkov.com/

https://github.com/skylot/jadx

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-AppsKAPITEL 5. VORGEHEN BEI EINER TYPISCHEN BROADCASTANALYSE

renziert werden können, entstehen unzählige fehlerhafte Verweise im Code. Referenzen sind dann

nicht eindeutig ihren Zielen zuzuordnen, was das Nachvollziehen des Programmablaufs enorm

erschweren kann. JADX ist das einzige getestete Tool, welches an dieser Stelle für eine korrekte

Zuordnung durch die Erstellung eines Standardpackages namens defpackage sorgt. Daher bietet

es sich sehr gut als Ergänzung zu den anderen Programmen an.

5.2 Ermitteln kritischer Codeteile

Anfangs bietet es sich an, das Manifest auf Hinweise zu untersuchen, die eine unsichere Broadcast-

verwendung nahelegen. Dies können einerseits exportierte Komponenten wie Broadcast-Receiver

und Services sein, andererseits können auch selbstdefinierte Permission ohne passende Schutz-

klassen Informationen darüber liefern, ob die Programmierer mit den Schutzmaßnahmen des

Betriebssystems vertraut sind. Die im Manifest angegebenen Klassen der Receiver und Services

sollten dann als nächstes genauer untersucht werden, damit man herausfindet, ob an diesen Stel-

len weitere Schutzmechanismen implementiert sind, wie unter Kapitel 4, Sicherheitsprobleme

und Absicherungsmöglichkeiten beschrieben.

Die erhaltenen Java-Quelltexte sind oft syntaktisch falsch oder lückenhaft. Bei den meisten Pro-

grammiersprachen gibt es beim Kompilieren keine Umkehrfunktion – es handelt sich beim De-

kompilieren vielmehr um ein Generieren von Code, der auf dem kompilierten Maschinencode

basiert und in etwa die gleiche Funktion erfüllt. Aus diesem Grund spricht man auch von Rever-

se Engineering.

Eine weitere Schwierigkeit ist, dass Entwickler ihre Anwendungen häufig obfuskieren, um diesen

Reverse-Engineering-Vorgang zu erschweren. Dabei bleibt die Funktion des Programms unver-

ändert, Variablen-, Methodennamen und Klassennamen werden jedoch für gewöhnlich in bedeu-

tungslose Buchstabenkombinationen geändert. Zusätzlich kann hierbei der Verzweigungsgrad

des Codes automatisiert stark erhöht werden, damit ein potentieller Angreifer in den zahlreichen

neuen, oft nur wenige Zeilen umfassenden Methoden in vielen neuen generierten Klassen den

Überblick verliert und aus Zeit- oder Motivationsgründen aufgibt. Es gibt durchaus noch weitere

Varianten des Obfuskierens, die hier jedoch nicht weiter im Fokus stehen sollen.

Interessant ist, dass bei aus dex-Dateien zurückerrechneten Class-Files keine lokalen Variablenbe-

zeichnungen mehr erhalten bleiben, diese Namen also offensichtlich beim Kompiliervorgang des

47

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-Apps5.2. ERMITTELN KRITISCHER CODETEILE

Tools dx verändert werden (in Namen der Form a,b,c,...). Klassenvariablennamen bleiben

jedoch erhalten. Nutzt man ein Tool wie JD-GUI, um hingegen direkt die Java-Class-Dateien zu

Dekompilieren, die während des Build-Vorgangs und vor der dx-Optimierung generiert werden,

sind alle Variablennamen noch vorhanden. Daraus folgt, dass für Android-Apps kein Obfuskier-

programm benötigt wird, um einfach nur die Variablennamen in einer Methode zu verschleiern.

Methoden- und Klassennamen sind hiervon jedoch nicht betroffen, ihre Namen bleiben ohne

weiteres erhalten.

Besitzt man die dekompilierten Java-Quelltexte, bietet es sich an, diese Dateien mit der Suchfunk-

tion eines Texteditors automatisiert nach bestimmten Schlüsselbegriffen zu durchsuchen (zum

Beispiel ”sendBroadcast”, ”broadcastReceiver”, ”credentials”, ”username”, ”password”). Oft fin-

det man dann Action-Strings, die man gemäß der Benennung verschiedenen Prioritäten zuordnen

kann – welcher Broadcast ist für die weitere Analyse interessant, welcher eher unwichtig, da er

nur uninteressante Status- oder Verwaltungsinformationen enthält?

Obfuskierte Anwendungen machen es einem nicht einfach, zu erkennen, ob es sich bei Suchergeb-

nissen um ”toten” Code handelt oder ob dieser im regulären Programmablauf noch verwendet

wird. Dazu kommen die unzähligen syntaktischen Fehler durch den Dekompiliervorgang.

Eine Möglichkeit, die in manchen Fällen helfen kann, ist das Debugging. Ist dies zur Entwick-

lungszeit eine fast schon unverzichtbare Methode, um den Programmablauf anhand des ver-

fassten Quellcodes zu verfolgen, kann man sie auch bei dekompilierten Anwendungen einsetzen.

Unter Nutzung der Entwicklungsumgebung Eclipse wird hierzu beispielsweise ein neues Android-

Projekt erstellt und mit den (syntaktisch ggf. nicht korrekten) Informationen aus dem dekom-

pilierten Projekt gefüllt (Quellcode, Layouts, Manifest, ...). Dann können Breakpoints gesetzt

werden – also Codezeilen, bei deren Erreichen der Debugger die Programmausführung anhal-

ten soll, um die aktuelle Position im Programmcode zu markieren. Zuletzt kann der Debugger

mit dem Tool DDMS (Dalvik Debug Monitor Service) an einen ausgeführten Prozess aus dem

Android-Gerät angehängt werden. Durch manuelles Aufrufen verschiedenster Funktionen in der

App versucht man nun, den entsprechenden Code auszuführen um den Breakpoint zu erreichen.

Das Debugging ist am einfachsten, wenn der originale Sourcecode vorliegt, was bei der Analyse

kommerzieller Anwendungen so gut wie nie der Fall ist. Nutzt man dekompilierten Quellcode,

funktioniert das Debugging in einigen Fällen nicht gut, da wie bereits erwähnt die Syntax des

Codes oft fehlerhaft ist, Codeteile fehlen und teilweise keine Ähnlichkeit mehr mit dem originalen

Code aufweisen, sodass Breakpoints u.U. nicht ausgelöst werden. Dann könnte man zu dem

48

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-AppsKAPITEL 5. VORGEHEN BEI EINER TYPISCHEN BROADCASTANALYSE

Schluss kommen, bestimmter Code wird niemals ausgeführt, obwohl diese Annahme nicht korrekt

ist.

Ist der Java-Code komplett unverständlich, kann es helfen, sich die Smali-Instruktionen anzuse-

hen. Diese basieren direkt auf dem Dalvik-Bytecode. Dalvik-Bytecode und Smali-Instruktionen

lassen sich problemlos ineinander überführen. Durch diese Eigenschaft sind sie im Gegensatz

zum dekompilierten Java-Code deutlich genauer und ermöglichen weitergehende Analysen auf

verlässlicherer Basis. [Gru15]

Um weitere Hinweise auf den Einsatzzweck einer Methode zu erhalten, kann man den Kontext

untersuchen: Bei nicht-obfuskierten Anwendungen kann der Methoden- oder Klassenname einen

Hinweis darauf geben, manchmal können es auch fest einprogrammierte Strings sein – diese

werden normalerweise aus naheliegenden Gründen nicht obfuskiert.

Um den Aufrufkontext einer Methode weiter eingrenzen zu können, kann man auch versuchen,

mittels einer Suchfunktion aus einem Editor die dazugehörigen Methodenaufrufe zu finden und

dann an den jeweiligen Stellen die obigen Methoden wie Debugging oder Kontextanalyse weiter-

zuführen.

Ist ein Debugger an eine zu untersuchende App angehängt, hat man einen weiteren Vorteil: In der

Entwicklungsumgebung können Konsolenmeldungen angezeigt werden, die von der App ausgege-

ben werden. Sie können nicht-obfuskierte Methoden- und Klassennamen in Stringform enthalten

und das Verständnis des Codeablaufs daher stark vereinfachen. Da das Debugging durch den

fehlerhaften dekompilierten Code häufig nicht korrekt funktioniert, können die Konsolenausga-

ben dazu verwendet werden, anhand der vorliegenden Log-Informationen nachzuvollziehen, an

welcher Stelle im Programmablauf man sich derzeit befindet.

49

Kapitel 6

Analyse am Beispiel

In diesem Kapitel werden verschiedene Apps auf die angesprochenen Sicherheitsprobleme hin

untersucht. Sämtliche dekompilierte Klassen und Manifest-Dateien, die hier referenziert werden,

finden sich im Original auf der beigelegten CD.

6.1 OnlineManager (Deutsche Telekom AG)

Die OnlineManager-App der Deutschen Telekom AG1 ist für Android und iOS verfügbar. Sie ist

vor allem dazu gedacht, sich komfortabel mit Telekom-Hotspots verbinden zu können. Man kann

seine Zugangsdaten in die Anwendung eingeben und wird dann automatisch mit dem Hotspot

verbunden, sobald man in seine Nähe kommt. Außerdem hat man jederzeit das bisher genutzte

mobile Datenvolumen im Blick. Mit einem gekauften Hotspot-Pass, also einem zeitlich begrenzten

Zugangsaccount, konnte die App auch praktisch ausprobiert und tiefergehend analysiert werden.

Bei der Analyse des APKs in Version 4.3.1.169 wurden gleich zu Beginn diverse potentielle

Sicherheitsprobleme sichtbar.

6.1.1 Analyse des Manifests

Code 6.1 Besonders interessanter Auszug aus dem Manifest der OnlineManager-App

1 <manifest xmlns:android="http://schemas.android.com/apk/res/android"

1 Für Android erhältlich unter https://play.google.com/store/apps/details?id=de.telekom.hotspotlogin.de

51

https://play.google.com/store/apps/details?id=de.telekom.hotspotlogin.de

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-Apps6.1. ONLINEMANAGER (DEUTSCHE TELEKOM AG)

2 package="de.telekom.hotspotlogin.de"3 android:versionCode="1"4 android:versionName="1.0" >56 (...)7 <uses-permission android:name="android.permission.BROADCAST_STICKY←↩

"/>8 (...)9

10 <application (...)>11 (...)12 <receiver android:name="de.telekom.hotspotlogin.receiver.←↩

WifiIntentMapper">13 <intent -filter>14 <action android:name="android.net.wifi.STATE_CHANGE"/>15 <action android:name="android.net.wifi.WIFI_STATE_CHANGED"←↩

/>16 <action android:name="de.telekom.hotspot.intent.action.←↩

LOGIN_RESPONSE"/>17 <action android:name="de.telekom.hotspot.intent.action.←↩

CAPTCHA_CHALLENGE"/>18 </intent -filter>19 </receiver>20 (...)21 </application>22 </manifest>

Zunächst fällt in Code 6.1 auf, dass die App die Permission für Sticky Broadcasts anfordert. Wie

in Kapitel 3.2.2, Sticky Broadcasts beschrieben, lohnt es sich hier, näher zu untersuchen,

welche Sticky Broadcasts versendet werden.

Auch fällt auf, dass von der App im Manifest keine benutzerdefinierten Permissions angefordert

oder definiert werden. Da in Zeile 13 von Code 6.1 ein Receiver einen Intent-Filter für offen-

sichtlich selbstgewählte Action-Strings de.telekom.hotspot.intent.action.LOGIN_RESPONSE

bzw. -.CAPTCHA_CHALLENGE definiert, könnte dies bereits ein Hinweis auf ungesicherte Broad-

casts sein. Schon die Intentbezeichnung lässt vermuten, dass an der entsprechenden Stelle im

Programmcode mit sensiblen Logininformationen gearbeitet wird. Daher muss anhand des Pro-

grammcodes untersucht werden, welchen Inhalt die unter den entsprechenden Action-Strings

verschickten Broadcasts haben. Eine andere App könnte diese unter Umständen mitlesen oder

zumindest den angegebenen Broadcast-Receiver kontaktieren, wenn dort auch keine weiteren

Schutzmaßnahmen implementiert wurden.

6.1.2 Analyse des Quellcodes

Deutlich Genaueres kann man nun bei der Analyse des Quellcodes herausfinden.

52

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-AppsKAPITEL 6. ANALYSE AM BEISPIEL

6.1.2.1 Sticky Broadcasts

Eine Suche nach dem Begriff ”sticky” in den dekompilierten Klassen lieferte die Verwendungs-

bereiche der Sticky Broadcasts. Es werden drei Arten verschickt:

• de.telekom.hotspot.intent.action.PRIVATE_DTAG_SCANNED_NETWORKS_CONFLICT

• de.telekom.hotspot.intent.action.WIFI_STATUS

• de.telekom.hotspot.intent.action.CAPTCHA_CHALLENGE

Die ersten beiden haben bei genauerer Analyse keine weitere sicherheitsbezogene Relevanz – hier

werden nur Informationen über die WLAN-Suchergebnisse und -Einstellungen publiziert. Der

letzte Intent ist jedoch deutlich interessanter. Hier wird dem Namen nach mit einer Captcha-

Herausforderung gearbeitet. Verantwortlich ist hierfür die Klasse de.telekom.hotspotlogin.

service.HotSpotLoginService. Wenn diese Challenge ungeschützt zugänglich ist, lassen sich

leicht Anwendungen bauen, die sie auslesen und an ein automatisiertes Script weiterreichen. So

hätte die Captcha-Abfrage keinerlei Wirkung mehr und eine Systemüberlastung wäre möglich

(Denial-of-Service-Attacke). Auch könnte man durch Brute-Force-Attacken Passwörter und ähn-

liches knacken, wenn keine zusätzlichen Absicherungsmaßnahmen existieren.

Code 6.2 zeigt, wie dem Sticky Broadcast ein Extra-Feld der Bezeichnung captcha_image hin-

zugefügt wird. Dies ist höchstwahrscheinlich das dargestellte Bild, welches durch eine Drittan-

wendung automatisiert analysiert werden könnte. Es ist vom Typ android.graphics.Bitmap,

was diese These unterstützt. captcha_status ist vom Typ aE. Die Referenz auf diese Klasse

wurde nur durch das Tool JADX vollständig aufgelöst; dabei handelt es sich um einen Enum-

Typ, welcher verschiedene Statusmeldungen bereitstellt (SUCCESS, FAILURE, ...). Die Klasse

ist im Anhang unter Code A.3 zu finden. Somit wird also im Broadcast aller Wahrscheinlichkeit

nach festgehalten, ob die Captcha-Abfrage korrekt gelöst wurde oder nicht. Diese Rückmeldung

könnte zum Beispiel von einem Brute-Force-Programm ausgenutzt werden, um den Erfolg eines

Angriffsversuchs zu bewerten.

Im Verlauf der Untersuchung durch diese Arbeit wurde kein zugängliches Captcha-Feld in der

Anwendung entdeckt, weswegen ein möglicher Exploit und die obige Vermutung nicht getestet

werden konnte. Man sollte diesen Teil am besten anhand des originalen Quellcodes verifizieren

und letzteren ggf. absichern.

53


Code 6.2 Code aus HotSpotLoginService.java. Verwendetes Tool: JADX.

495 Intent intent = new Intent("de.telekom.hotspot.intent.←↩action.CAPTCHA_CHALLENGE");

496 intent.putExtra("captcha_status", aE.CHALLENGE_REQUIRED);497 intent.putExtra("captcha_image", bitmap);498 context.sendStickyBroadcast(intent);

6.1.2.2 Weitere Broadcasts

Eine Suche nach sendBroadcast in den mit JADX dekompilierten Klassen brachte den interes-

santen Codeteil aus der Klasse de.telekom.hotspotlogin.service.a aus Code 6.3 zum Vor-

schein. Er wird dazu genutzt, die Zugangsdaten zum Hotspot über das mobile Datennetz unter

Nutzung einer HTTPS-Verbindung abzurufen.

Code 6.3 Ausschnitt aus de.telekom.hotspotlogin.service.a. Der dritte Methodenparameter

enthält die vermeintlichen Zugangsdaten. Verwendetes Tool: JADX.

32 static /* synthetic */ void a(a aVar, b bVar, CredentialsHttpParser ←↩credentialsHttpParser) {

33 switch (f.a[bVar.ordinal()]) {34 case c.SlidingMenu_viewAbove /*1*/:35 Context context = aVar.a;36 Intent intent = new Intent("de.telekom.hotspot.intent.←↩

action.HTTPS_SUCCESS");37 intent.putExtra("credentials", credentialsHttpParser);38 context.sendBroadcast(intent);39 case c.SlidingMenu_viewBehind /*2*/:40 a(aVar.a, ErrorType.HTTPS_ERROR_TIMEOUT);41 case c.SlidingMenu_behindOffset /*3*/:42 a(aVar.a, ErrorType.HTTPS_ERROR_TECHNICAL);43 default:44 }45 }

Hier wird offensichtlich ein Broadcast unter dem Action-String de.telekom.hotspot.intent.

action.HTTPS_SUCCESS verschickt, wenn der Wert des Enums bVar einen bestimmten Wert

annimmt. Der Code der Enum-Klasse ist im Anhang unter Code A.4 abgedruckt. Auffällig ist

hierbei, dass die Methode bVar.ordinal() gemäß Definition eigentlich nullbasierend ist. Das

erste Enum-Element (SUCCESS) nimmt unter Anwendung dieser Methode also eigentlich den

Wert 0 an. Die durch den Decompiler ausgewerteten, in den Kommentaren angegebenen Werte

des Switch-Statements scheinen einsbasierend zu sein, was sich als irreführend herausgestellt hat.

Es wird daher davon ausgegangen, dass b.SUCCESS in den ersten Zweig des Switch-Statements

54


führt, b.SESSION_TIMEOUT in den zweiten und so weiter. Dies passt zu den im Code verwendeten

Schlüsselwörtern wie HTTPS_SUCCESS und HTTPS_ERROR_TIMEOUT.

Beim genannten Broadcast werden keine Permissions angefordert – es wird die unsichere Variante

von sendBroadcast verwendet. Interessanterweise beinhaltet der Broadcast einen Extra-Eintrag

mit dem Titel credentials, was auf die Zugangsdaten für den Hotspot schließen lässt.

Es lässt sich leicht eine App programmieren, welche Broadcasts mit diesem Intent abfängt und

darstellt. Dazu ist zunächst die Klasse de.telekom.hotspotlogin.protocol.sms.Credentials-

HttpParser nötig, da sie, wie in Code 6.3 in Zeile 37 zu sehen, als Container für die Zugangsdaten

dient. Sie muss sich beim Sniffer-Programm ebenfalls im Package de.telekom.hotspotlogin.

protocol.sms befinden, da es ansonsten beim Extrahieren des abgefangenen Extra-Datums ei-

ne NoClassDefFoundError-Exception geben würde. Die dekompilierte Version dieser Klasse ist

syntaktisch nicht korrekt, weshalb sie im Kontext dieser Arbeit unter Analyse des originalen

Codes nachgebildet wurde (im Anhang unter Code A.2). Nun lässt sich ein einfacher Broadcast-

Receiver bauen, der auf entsprechende Intents wartet. Die onReceive()-Methode gibt dann die

extrahierten Daten auf die Konsole aus. Der Code dieser selbstgeschriebenen App ist auf der

beigelegten CD.

Bei einem normalen Login durch die Hotspot-App konnte kein solcher Broadcast abgefangen

werden. Daher muss genauer analysiert werden, wann der Broadcast verschickt wird. Um dies

herauszufinden, wurden Methodenaufrufe von de.telekom.hotspotlogin.service.a.a(a, b,

CredentialsHttpParser) gesucht. Hierfür bietet sich eine Entwicklungsumgebung wie Eclipse

an, die Referenzen auf die Methode automatisiert ermitteln kann.

Dadurch fällt dann auf, dass die potentiell verwundbare Methode in de.telekom.hotspotlogin.

service.g.onPostExecute() aufgerufen wird. Bei der Klasse g handelt es sich um ein Objekt,

welches von AsyncTask erbt, also einen asynchronen Hintergrundprozess darstellt. onPostExecute()

wird automatisch bei einem solchen Objekt nach Abarbeiten der doInBackground()-Methode

gestartet. Es stellt sich heraus, dass in doInBackground() ein als Parameter übergebener Webser-

ver kontaktiert wird, von dem Zugangsdaten abgerufen werden. Die HTTP-Antwort wird dann in

onPostExecute() genutzt, um die gefährliche Methode der Klasse de.telekom.hotspotlogin.

service.a aufzurufen.

55


Gestartet wird der Hintergrundprozess zum Abrufen der Zugangsdaten ausschließlich in der

Methode de.telekom.hotspotlogin.service.a.a(Context). Letztere wird in Verbindung mit

zwei Klassen verwendet, die Klick-Ereignisse der Benutzeroberfläche abhandeln: In de.telekom.

hotspotlogin.ui.C0085af (siehe Code 6.4) und de.telekom.hotspotlogin.ui.C0088ai (sie-

he Code 6.5). Sie erben von OnClickListener und werden ausschließlich in der Activity de.

telekom.hotspotlogin.ui.MobileCustomerCredentialEditor verwendet, weshalb zunächst

davon ausgegangen werden kann, dass die Daten vom Server abgerufen werden, wenn die ent-

sprechende Activity gestartet und ein bestimmtes Element ausgewählt wird. Die entsprechende

Stelle ist auszugsweise in Code 6.6 angegeben.

Die beiden Actionhandler unterscheiden sich folgendermaßen:

• Methode C0085af.onClick()

Code 6.4 Code aus ui.C0085af.onClick(). Verwendetes Tool: JADX.

17 public final void onClick(DialogInterface dialogInterface , int i) ←↩{

18 this.a.f.show();19 a aVar = new a(this.a.getApplicationContext(), j.a(this.a).j()←↩

);20 if (j.a(this.a).j()) {21 j.a(this.a).a(false);22 new Handler().postDelayed(new C0086ag(this, aVar), 5000);23 return;24 }25 aVar.a(this.a);26 }

Diese Methode sorgt dafür, dass beim Klick auf das entsprechende GUI-Element zunächst

ein Fortschrittsdialog angezeigt wird (Zeile 18). Da der Abruf der Zugangsdaten über das

mobile Netz geschehen muss, wird überprüft, ob der WLAN-Adapter deaktiviert ist (Zeile

20). Ist dies nicht der Fall, so wird das mit dem Methodenaufruf a(false) in Zeile 21

nachgeholt. Damit das Gerät anschließend Zeit hat, das mobile Datennetz zu aktivieren,

wird die Klasse C0086ag mit einer Verzögerung von fünf Sekunden über postDelayed()

gestartet. (Zeile 22). Um diesen verzögerten Start zu ermöglichen, implementiert C0086ag

das Runnable-Interface. In der dazu zu implementierenden C0086ag.run()-Methode wird

die genannte a.a(Context)-Methode aufgerufen, die die Kommunikation mit dem Server im

Hintergrund startet. Beim Beenden dieses Hintergrundprozesses wird dann wie beschrieben

das Verschicken der Zugangsdaten im Broadcast ausgelöst.

Ist der WLAN-Adapter bereits deaktiviert, wird die verwundbare Methode dann in Zeile 25

statt der If-Abfrage aufgerufen.

56


• Methode C0088ai.onClick()

Code 6.5 Code aus ui.C0088ai.onClick(). Verwendetes Tool: JADX.

16 public final void onClick(DialogInterface dialogInterface , int i) ←↩{

17 MobileCustomerCredentialEditor.e;18 new a(this.a.getApplicationContext(), j.a(this.a).j()).a(this.←↩

a);19 }

Bei diesem Actionhandler wird der abrufende AsyncTask durch a.a(Context) in Zeile 18

ohne Verzögerung gestartet.

Bei MobileCustomerCredentialEditor handelt es sich um eine Activity, die Daten eines Mobil-

funkvertrags entgegen nimmt, um darüber Nutzungsgebühren des Hotspots abrechnen zu können.

Dass diese Klasse in der App tatsächlich verwendet wird und genau diesem Zweck dient, konnte

durch Debugging des dekompilierten Codes überprüft werden.

Code 6.6 In der Klasse MobileCustomerCredentialEditor werden die Actionhandler benutzt.

Verwendetes Tool: JADX.

243 protected Dialog onCreateDialog(int i) {244 (...)245 switch (i) {246 (...)247 case c.SlidingMenu_fadeDegree /*11*/:248 return bI.c(this, bD.←↩

getArgumentsForUsingMobileDataWarningDialog(this, new ←↩C0085af(this), new C0087ah()));

249 case c.SlidingMenu_selectorEnabled /*12*/:250 bLVar3 = new bL();251 bLVar3.a = getString(R.string.https_timeout_title);252 bLVar3.b = getString(R.string.https_timeout_message);253 bLVar3.g = getString(R.string.cancel);254 bLVar3.f = getString(R.string.retry);255 bLVar3.h = new C0088ai(this);256 bLVar = bLVar3;257 i2 = -1;258 break;259 (...)260 }261 if (bLVar == null) {262 a = bI.a((Context) this, i2, i3);263 } else {264 a = bI.b(this, bLVar);265 }266 a.setOnCancelListener(new C0089aj());267 return a;268 }

Wie im Kapitel 2.3.1, Konzepte der Anwendungsprogrammierung unter Android be-

schrieben, können mit showDialog(i) eigene Dialoge dargestellt werden, die in der Methode

57


onCreateDialog(i) genauer spezifiziert werden.

Wird als Dialog-ID 11 (siehe Code 6.6, Zeile 247) oder 12 (siehe Code 6.6, Zeile 249) angegeben,

so werden die zuvor erklärten Actionhandler benutzt:

• Dialog-ID 11:

Der Methode bD.getArgumentsForUsingMobileDataWarningDialog() wird der Action-

handler C0085af übergeben, der die Serverkommunikation mit der Verzögerung startet.

Analysiert man die Methodenaufrufe tiefergehend, wird deutlich, dass ein Dialog mit dem

String automatic_setup_mobile_usage_warning_message aus den Ressourcen angezeigt

wird. Letzterer wird gemäß der Datei strings.xml aus dem APK der App zu folgender

Nachricht aufgelöst:

Die automatische Einrichtung Ihrer Zugangsdaten benötigt eine aktive mobile

Datenverbindung. Sollten Sie aktuell über WLAN verbunden sein, wird WLAN

während der automatischen Einrichtung kurz deaktiviert. [...]

Als Actionhandler für einen mit ”OK” beschrifteten Button wird dann C0085af verwendet.

• Dialog-ID 12:

Als Nachricht wird dem Benutzer der String https_timeout_message angezeigt, welcher zu

folgender Nachricht aufgelöst wird:

Automatische Einrichtung fehl- geschlagen.[sic] Bitte versuchen Sie es erneut.

Der Actionhandler für einen mit ”Wiederholen” beschrifteten Button ist dann C0088a1.

Dies erklärt, warum bei diesem Handler keine Verzögerung von fünf Sekunden notwendig

ist: Wird die HTTPS-Einrichtung wiederholt, wurde WLAN bereits durch den vorherigen

Aufruf der onClick()-Methode von C0085af im Dialog mit der ID 11 deaktiviert. Somit

wird die Serveranfrage beim zweiten Versuch deutlich schneller initiiert.

Im Code sind keine Aufrufe der Methode showDialog() der Klasse MobileCustomerCredential-

Editor mit fest angegebenen Parameterwerten von 11 oder 12 vorhanden. Auch generell gibt es

keine Variablen, die den Wert 11 bzw. 12 annehmen und der showDialog()-Methode übergeben

werden. Auch wenn es recht unwahrscheinlich ist, könnte es sein, dass diese Zahlen nicht fest in

die App geschrieben wurden und dynamisch berechnet werden oder aber bei der Dekompilierung

verloren gegangen sind.

Aus diesem Grund hat der Verfasser der Arbeit das Serviceteam der Telekom kontaktiert, wobei

sich herausgestellt hat, dass der Code tatsächlich nicht verwendet wird:

this part of code is not used at all in the current version and it has been not used

58


in past versions. [...] This server is off since beginning 2014, so currently there is no

way to get credentials using a https interface. [Tut15]

Abbildung 6.1 stellt die zuvor beschriebenen Vorgänge zum Abrufen der Zugangsdaten per Hyper

Text Transfer Protocol Secure (HTTPS) noch einmal als Datenflussdiagramm dar.

Trotz allem liegt dieser Arbeit der Code der Sniffing-Anwendung bei, sodass dieser zumindest auf

theoretischer Basis nachvollzogen werden kann. Sollte der analysierte Code in einer zukünftigen

Version der Hotspot-App verwendet werden, so liegt bereits ein Exploit vor. Tatsächlich scheint

der in der Methode a.a(Context) referenzierte Server (https://WLANAuthenticate.telekom.de/

getCredentials?) zum aktuellen Zeitpunkt (August 2015) nicht erreichbar zu sein.

Die übrigen verschickten und empfangenen Broadcasts in der App sind größtenteils Verwal-

tungsinformationen: So werden Systembenachrichtigungen empfangen und verarbeitet, die die

Veränderung der Signalstärke eines WLAN-Netzes angeben (Action-String android.net.wifi.

RSSI_CHANGED) und es werden Broadcasts verschickt, die zum Beispiel auf Fehler (oder Erfolg)

bei der Verbindung mit dem Hotspot hinweisen (Action-String de.telekom.hotspot.intent.

action.EAP_CONNECTION_FAILURE, de.telekom.hotspot.intent.action.LOGIN_RESPONSE und

ähnliche).

6.2 Client Hub/Incident Management (SAP)

Bei Client Hub handelt es sich um eine Anwendung, die gemäß Abb. 6.2 das Austauschen von

Zugangsdaten unter mehreren SAP-Business-Apps vereinfachen soll. Damit lässt sich ein Single-

Sign-On-Verhalten realisieren.

Die Anwendung ist nicht im Play Store zu finden. Sie muss selbst kompiliert und signiert werden

und steht daher über das SAP Mobile SDK zur Verfügung. Apps, die mit demselben Zertifikat

signiert werden, wie die installierte Client-Hub-Instanz, können dann Zugangsdaten in einem so-

genannten Data Vault, also einer verschlüsselten Datenbank abspeichern und auf diese zugreifen.

[SAPc]

Apps, die die Client-Hub-Funktionalitäten benutzen wollen, müssen außerdem SAPs Kapsel-

Bibliotheken oder das OData-Protokoll verwenden [SAPc]. Kapsel liefert entsprechende APIs

59

https://WLANAuthenticate.telekom.de/getCredentials?

https://WLANAuthenticate.telekom.de/getCredentials?

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-Apps6.2. CLIENT HUB/INCIDENT MANAGEMENT (SAP)

Abbildung 6.1 Datenflussdiagramm der Telekom-App zur Anforderung der Zugangsdaten perHTTPS. Es wurden die Stellen rot gekennzeichnet, die eine Nutzung der HTTPS-Funktion verhindern.

60


Abbildung 6.2 Schematischer Aufbau der Kommunikation mit Client Hub nach [VP15].

zur einfachen Kommunikation mit der Client-Hub-Anwendung mit (das Kapsel-Logon-Plugin,

vgl. [SAPb]).

Ein Beispiel für eine an den Client Hub angebundene Anwendung ist SAP Incident Management

in Version 1.0.0. Dies ist ein Programm, um Vorfälle im IT-Management auch auf dem Mobilgerät

verwalten zu können.

6.2.1 Analyse des Quellcodes

Der Incident-Management-App liegen im Package com.sap.mobile diese Bibliotheksklassen einer

unbekannten Client-Hub-Version bei:

• lib.clientHubSLL.ClientHub

• lib.clientHubAppSLL.ClientHubServiceHelper

• clientHub.MCIMService

Für das weitere Verständnis sei an dieser Stelle schon einmal vorweggenommen, dass SAP In-

cident Management lediglich mit lib.clientHubSLL.ClientHub kommuniziert, weswegen die

anderen Klassen kursiv gedruckt wurden.

Ein vereinfachter Ausschnitt der Client-Hub-Architektur ist im Klassendiagramm in Abb. 6.3

dargestellt. Der dekompilierte Quellcode ist hier am Beispiel von SAP Incident Management

recht einfach zu verstehen, da er nicht obfuskiert ist und die Kombination aus den Tools dex2jar

61


Abbildung 6.3 Schematischer Aufbau der betrachteten Klassen. Die Klasse clientHub.MCIMService stellt im Produktiveinsatz den exportierten Service der installier-ten Client-Hub-Instanz dar und befindet sich aus unbekannten Gründen in derIncident-Management-App.

und JD-GUI syntaktisch gute Ergebnisse bei der Dekompilierung liefert. Im Falle von Ver-

ständnisschwierigkeiten kann man teilweise zusätzlich auf den originalen Code der Client-Hub-

Anwendung zugreifen. Er ist im SAP Mobile SDK frei verfügbar, damit Entwickler Anwendungen

wie beschrieben an den Client Hub anbinden können. Die Quellen zu den Klassen aus dem lib.

clientHubAppSLL-Package liegen dem SDK leider auch nur in kompilierter Form bei.

62


6.2.1.1 Ungesicherter Service-Intent

Betrachten wir zunächst die Klasse lib.clientHubSLL.ClientHub. Sie muss in ähnlicher oder

identischer Form jeder App beiliegen, die mit dem Client Hub kommunizeren möchte, da sie

für die Kommunikation mit dem Client-Hub-Service zuständig ist. Letzterer delegiert Data-

Vault-Anfragen im Hintergrund und schickt das Resultat später per Broadcast an alle war-

tenden Empfänger. Initiiert wird eine solche Kommunikation unter anderem über einen Aufruf

der Methoden ClientHub.getCredentials() oder ClientHub.setCredentials(). Verschiede-

ne Intents werden dazu genutzt, um eingegebene Zugangsdaten zur Speicherung an den Ser-

vice zu übermitteln, gespeicherte Daten vom Service anzufordern oder zum Beispiel auch um

zu prüfen, ob die Client-Hub-Anwendung überhaupt auf dem Gerät installiert ist. Für diese

Anfragen werden die Action-Strings android.intent.action.MAIN und com.sap.mobile.lib.

clientHubSLL.MCIM_PROCESSED genutzt, ersterer zum (parametrisierten) Starten des Services

mit startService(), letzterer zum Senden und Empfangen des Anfrageergebnisses per Broad-

cast. Diese Ergebnisse werden – genau wie auch die Anfrageparameter – ungesichert als einfache

Extra-Einträge übermittelt.

In ClientHub.setCredentials() wird so der eingegebene Benutzername zusammen mit dem

Passwort unter dem Action-String android.intent.action.MAIN verwendet, um in der Metho-

de sendCallToMcimService() mit startService() den Hintergrunddienst zur Speicherung zu

starten (Code 6.7).

Um genauer zu definieren, was der Intent android.intent.action.MAIN bewirken soll, der den

Service startet, gibt es ein Extra-Feld mit den Namen methodType, welches zum Beispiel auf

getCredentials oder setCredentials gesetzt wird.

Code 6.7 Explizites Starten des Client-Hub-Services in clientHubSLL.ClientHub. Verwendetes

Tool: JD-GUI.

172 private static void sendCallToMcimService(Intent paramIntent)173 throws Exception174 {175 paramIntent.setClassName("com.sap.mobile.clientHub", "com.sap.←↩

mobile.clientHub.MCIMService");176 context.startService(paramIntent);177 }

Ein startService()-Aufruf kann unter Android, wie in Kapitel 4.1 erwähnt, nicht mit Permis-

sions geschützt werden. Das heißt, dass es keine spezielle Überladung der Methode gibt, die man

nutzen kann, um mittels signaturgeschützter Berechtigungen sicherzustellen, dass die gestartete

63


Serviceklasse der Zielanwendung auch die erwartete ist. Je nach Art des startenden Intents kann

eine bösartige Anwendung einen Service unter dem Klassennamen exportieren (wenn zusätzlich

der Package-Name stimmt) und/oder einen Intent-Filter höherer Priorität angeben. Ein ähnlicher

Angriff wurde in Kapitel 4.1, Sicherheitsaspekte bei der Deklaration näher erläutert.

Um dieses Sicherheitsproblem zu umgehen, müssten manuell Prüfungen auf Anwendungssigna-

turbasis implementiert werden – im Falle der Client-Hub-Architektur würde es genügen, zu prü-

fen, ob die den Service startende App mit demselben Zertifikat signiert wurde, wie die Zielanwen-

dung.2 Dies wird an keiner Stelle des Codes gemacht. So können bösartige Client-Hub-Varianten

gestartet werden, die die übertragenen Benutzerdaten abgreifen könnten.

Dies wurde vom Verfasser der Arbeit erfolgreich ausprobiert, indem eine Client-Hub-Variante be-

wusst mit einem anderen Zertifikat signiert wurde, als jenes, welches zum Signieren der Incident-

Management-App benutzt wurde. Außerdem wurde sie so manipuliert, dass sie einem Angrei-

fer Daten aus dem Service-Intent anzeigen kann. Damit konnte beispielsweise problemlos der

Single-Sign-On-Passcode abgegriffen werden. Diese Client-Hub-Variante befindet sich auf der

beigelegten CD.

Da Benutzernamen und Passwörter bei SAP Incident Management erst nach erfolgreichem Ver-

bindungsaufbau zum dazugehörigen SAP-Server an die Client-Hub-Anwendung geschickt werden,

konnten diese mangels entsprechender Zugangsdaten nicht abgefangen werden; der verantwortli-

che Code in der Methode lib.clientHubSLL.ClientHub.setCredentials() ist jedoch prinzi-

piell identisch zum bereits angegriffenen Code. Es ist auch nachvollziehbar, wann die Methode

ausgeführt wird – das ist in Abb. 6.4 dargestellt. Das Datenflussdiagramm enthält die beteiligten

Klassen, Pakete und Methoden. Da keine validen Zugangsdaten vorlagen, wurde in der App bei

der Fallunterscheidung ”Logon erfolgreich?” im Diagramm immer der Negativzweig gewählt.

Aus diesem Grund sollte das Abfangen der Daten kein Problem sein, wenn Zugang zu einem

SAP-Server besteht. Auch wenn dieses Sicherheitsproblem nicht direkt im Kontext der Broad-

casts steht, sondern hier das unsichere Starten eines Services problematisch ist, ist die Erkenntnis

überaus interessant.

Andersherum ist eine Absicherung mit Permissions hingegen mit ”Bordmitteln” möglich: Ein

exportierter Service kann im Manifest festlegen, dass er nur von Anwendungen gestartet wer-

den kann, die eine bestimmte Berechtigung besitzen (siehe Kapitel 2.3.1, Konzepte der

Anwendungsprogrammierung unter Android). Dies wird im Falle des neusten Client Hub ge-

2 Weitere, sehr interessante Informationen hierzu finden sich unter [Com15]

64


Abbildung 6.4 Datenflussdiagramm für das Generieren des startService()-Intents mit sämtli-chen sensiblen Benutzerdaten.

65


macht – dadurch können Drittanwendungen nicht an die gespeicherten Benutzerdaten gelangen,

indem sie den Service mit entsprechend manipulierten Intents starten. Dies ist jedoch unabhängig

vom zuvor angesprochenen Sicherheitsproblem, bei dem Anwendungen an neu einzuspeichernde

Daten gelangen könnten.

6.2.1.2 Ungesicherte Broadcasts

Auffällig ist, dass der App SAP Incident Management zwar die relevante Serviceklasse clientHub.

MCIMService beiliegt, diese jedoch nicht verwendet wird. Dies war aufgrund der Architektur ei-

gentlich auch zu erwarten: Client Hub wird normalerweise, wie bereits erklärt, als eigenständige

App installiert. In Code 6.7 ist zu sehen, wie der Service gestartet werden soll. Dazu müsste

ein Eintrag mit <service>-Tag mit dieser Klasse im Manifest von SAP Incident Management

vorhanden sein – das ist jedoch nicht der Fall. Auch die anderen Klassen aus dem Package

clientHub werden nicht außerhalb des Pakets referenziert. Mit der unter Kapitel 5.2 vorgestell-

ten Methode zum Debuggen einer dekompilierten App konnte sichergestellt werden, dass zwar

Code 6.7 ausgeführt wird, jedoch nicht clientHub.MCIMService. Es scheint sich dabei um eine

alte Client-Hub-Version zu handeln, die aus unbekannten Gründen in das APK von SAP Incident

Management gelangt ist. Deshalb ist es trotz allem lohnenswert, diese zumindest auf theoretischer

Basis weiter zu untersuchen, da die dortige Sicherheitslücke in neueren Client-Hub-Versionen of-

fenbar behoben wurde – möglicherweise hat sie aber einmal in der Produktivumgebung existiert

und ist in manchen Softwarekonfigurationen nach wie vor ausnutzbar.

Die (nicht verwendete) Klasse MCIMService der beiliegenden Client-Hub-Version würde nach dem

Start in der Methode onHandleIntent() die Anfrage an die Klasse ClientHubServiceHelper

weiterreichen und den Rückgabewert in einem ungesicherten Broadcast verschicken (siehe Code

6.8, speziell Zeile 25). Mit der Analyse des Smali-Codes konnte sichergestellt werden, dass bei

der Verwendung des Tools JD-GUI zur Dekompilierung keine Informationen verloren gegangen

sind: sendBroadcast() werden tatsächlich keine weiteren Parameter übergeben.

Code 6.8 Interessanter Ausschnitt aus der MCIMService-Klasse. Verwendetes Tool: JD-GUI.

8 public class MCIMService9 extends IntentService

10 {11 (...)12 protected void onHandleIntent(Intent paramIntent)13 {

66


14 (...)15 Intent localIntent = ClientHubServiceHelper.handleClientHubService←↩

(paramIntent , getApplicationContext());16 if (localIntent != null) {17 sendBroadcastFromMcimService(localIntent);18 }19 }2021 public void sendBroadcastFromMcimService(Intent paramIntent)22 {23 paramIntent.setAction("com.sap.mobile.lib.clientHubSLL.←↩

MCIM_PROCESSED");24 paramIntent.addCategory("android.intent.category.DEFAULT");25 sendBroadcast(paramIntent);26 }27 }

Um zu analysieren, was in diesem Broadcast verschickt werden würde, muss gemäß Zeile 15 aus

Code 6.8 die Methode handleClientHubService() aus der Klasse ClientHubServiceHelper

analysiert werden, genauer gesagt deren Rückgabewert. In der Methode wird die im Intent spezi-

fizierte, gewünschte Aktion ausgeführt, definiert durch das Extra-Feld methodType. Beispielswei-

se werden die übergebenen Zugangsdaten in einem Objekt vom Typ com.sybase.persistence.

PrivateDataVault gespeichert, falls methodType auf setCredentials gesetzt ist. Dabei handelt

es sich um eine Implementierungsart des allgemeinen Data Vaults aus der SAP Mobile Platform,

welche Daten verschlüsselt in einer SQLite-Datenbank persistieren und abrufen kann [SAPa].

Nach Ausführen einer solchen Aktion liefert handleClientHubService() einen Intent zurück –

dies ist also der im Kontext der Untersuchung relevante Teil, da letzterer dann per Broadcast

verschickt wird.

Ist methodType auf setCredentials gesetzt, enthält dieser Intent nur das Extra-Feld result,

welches die (ggf. nicht-) erfolgreiche Aktualisierung vermeldet. Um Daten also schon direkt beim

Einspeichern abzugreifen, muss stattdessen wie zuvor beschrieben der ungesicherte Service-Intent

abgefangen werden. Steht methodType jedoch auf getCredentials, so enthält dieser Broadcast

sensible Daten wie Benutzername und Passwort (Code 6.9).

Code 6.9 Fataler Code aus der ClientHubServiceHelper-Klasse, der zum Verschicken von Nut-

zernamen und Passwort per Broadcast führen würde. Verwendetes Tool: JD-GUI.

15 private static Intent getCredentials(String paramString1 , String ←↩paramString2)

16 {17 Log.i("MCIM", "In get User Settings");18 Intent localIntent = new Intent();1920 (...)21

67


22 JSONObject localJSONObject = new JSONObject(localPrivateDataVault.←↩getString(new JSONObject(localPrivateDataVault.getString(←↩paramString2)).getString("SecProfile")));

2324 (...)2526 localIntent.putExtra("UserName", localJSONObject.getString("←↩

UserName"));27 localIntent.putExtra("Password", localJSONObject.getString("←↩

Password"));28 localIntent.putExtra("CertString", localJSONObject.getString("←↩

CertString"));29 localIntent.putExtra("SSOToken", localJSONObject.getString("←↩

SSOToken"));3031 (...)3233 return localIntent;3435 (...)36 }

Lädt man sich das aktuelle SAP-Mobile-SDK in Version 3.0 SP08 herunter und analysiert man

die dort beigelegte Client-Hub-Version, fällt auf, dass die verwundbare Codestelle geändert wur-

de (Code 6.10). Somit ist den Entwicklern dieses Sicherheitsproblem offensichtlich auch aufge-

fallen. Es wurde die Permission com.sap.mobile.clientHub.CLIENTHUB_ACCESS_PERMISSION

eingeführt, die im Manifest mit dem Protection-Level signature gesichert ist. Auch der Ser-

vice MCIMService ist im Manifest exportiert und mit dieser Permission geschützt; letzteres be-

deutet, dass eine Kommunikation zwischen dieser Client-Hub-Version und der SAP-Incident-

Management-App durch die Unterschiede bei den Permissions unmöglich ist. Die Incident-

Management-App müsste diese Permission im Manifest anfordern.

Durch tiefergehende Recherchen war es möglich, auch die eigentlich nicht mehr verfügbare Ver-

sion 3.0 SP04 auf die gefundene Schwachstelle hin zu untersuchen. Hier war sie ebenfalls nicht

mehr vorhanden, weshalb davon auszugehen ist, dass die gefundenen Client-Hub-Dateien in SAP

Incident Management aus einer noch älteren Version des SAP-SDKs in Version 3.03 stammen

oder sogar eine unveröffentlichte Entwicklungsversion darstellen könnten.

Code 6.10 Korrigierter Code aus der aktuellen SDK-Version 3.0 SP08 der Klasse MCIMService.

34 public void sendBroadcastFromMcimService(Intent broadcastIntent) {35 broadcastIntent.setAction(Utils.MCIM_LIB_BROADCAST_URI);36 broadcastIntent.addCategory("android.intent.category.DEFAULT")←↩

;

3 Gemäß der Quelle [nln14] kam der Client Hub in der SDK-Version 3.0 hinzu. Vorherige SDK-Versionen sind andieser Stelle also nicht relevant.

68


37 sendBroadcast(broadcastIntent , "com.sap.mobile.clientHub.←↩CLIENTHUB_ACCESS_PERMISSION");

38 }

6.3 Twitter

Der Kurznachrichtendienst Twitter stellt eine App bereit4, mit der auch von unterwegs die neus-

ten Informationen abgerufen und verbreitet werden können. Sie soll in diesem Kapitel in Version

5.66.0 als Positivbeispiel dienen und es werden diverse Stellen herausgearbeitet, bei denen die

Programmierer Sicherheitsmechanismen für Broadcasts korrekt verwendet haben. Auch wenn

dies bei insgesamt 7379 dekompilierten, überwiegend obfuskierten Klassen im APK natürlich

längst keine Garantie ist, so kann man nach diesem Kapitel zumindest bedingt davon ausgehen,

dass viele der typischen Sicherheitsprobleme hier nicht anzutreffen sind, da sich die Entwickler

den Problemen offenbar bewusst sind – anders als bei den Negativbeispielen.

Diese App ist darüber hinaus auch ein exzellentes Beispiel für besonders aufwendige Obfuskie-

rung. Variablen und Konstanten sind oft in einzelne Klassen ausgelagert. Strings werden an eini-

gen Stellen durch diverse Methodenaufrufe dynamisch zusammengesetzt. Bei weiterem Interesse

wird dem Leser ein Blick in den beigelegten Code der dekompilierten Anwendung empfohlen.

6.3.1 Sicherheitsmaßnahmen im Manifest

Bei der Analyse des dekompilierten Manifests fallen gleich zu Beginn einige selbstdeklarierte

Permissions auf. Im Kontext der Broadcastanalyse sind die beiden, die in Code 6.11 dargestellt

werden, besonders wichtig. Sie haben den Protection-Level signature und können daher nicht

von anderen Apps angefordert werden, wenn diese mit anderen Zertifikaten signiert wurden –

dies entspricht der empfohlenen Vorgehensweise für die Verwendung bei Broadcasts, die sensible

Daten enthalten könnten.

Code 6.11 Relevante, selbstdefinierte Permissions aus der Twitter-App.

5 <permission android:name="com.twitter.android.permission.←↩C2D_MESSAGE" android:protectionLevel="signature"/>

4 Für Android erhältlich unter https://play.google.com/store/apps/details?id=com.twitter.android

69

https://play.google.com/store/apps/details?id=com.twitter.android

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-Apps6.3. TWITTER

6 <permission android:name="com.twitter.android.permission.←↩RESTRICTED" android:protectionLevel="signature"/>

Dazugehörige Broadcast-Receiver werden bei der Deklaration mit den Permissions geschützt.

Damit können sie nicht von anderen Apps kontaktiert werden, die die jeweilige Permission nicht

besitzen (Code 6.12).

Code 6.12 Mit Permission geschützter Broadcast-Receiver.

462 <receiver android:name="com.twitter.android.client.←↩AppBroadcastReceiver" android:permission="com.twitter.android.←↩permission.RESTRICTED">

463 <intent -filter>464 (...)465 </intent -filter>466 </receiver>

Code 6.13 Durch exported-Attribut geschützter Broadcast-Receiver.

142 <receiver android:exported="false" android:label="@string/app_name" ←↩android:name="com.twitter.android.client.chrome.←↩

ChromeCustomTabsActionReceiver">143 <intent -filter>144 (...)145 </intent -filter>146 </receiver>

Bei Receivern (und auch Services) wird das Attribut exported im Manifest in einigen Fällen

explizit auf false gesetzt (Code 6.13) oder sie werden durch fehlende Intent-Filter gar nicht erst

exportiert.

6.3.2 Verwendung von LocalBroadcastManager

Die Twitter-App verwendet – wie auch viele andere Apps, zum Beispiel WhatsApp, Facebook o.ä.

– die Google-Cloud-Messaging-Library. Dabei handelt es sich um eine Bibliothek, um Kommuni-

kation zwischen einem Webserver und Android- oder iOS-Geräten zu realisieren.5 Ein Webserver

kann dazu die Google-Cloud-Messaging-Server kontaktieren, bei denen sich die Mobilgeräte zu-

vor unter Verwendung der Bibliothek registrieren. Der Google-Server leitet die Nachricht des

Senders dann an die Empfänger weiter, wobei er die Daten ggf. zwischenspeichert, sollte das Ziel

nicht erreichbar sein.

5 Diese Bibliothek ist unter https://developers.google.com/cloud-messaging/ genauer beschrieben.

70

https://developers.google.com/cloud-messaging/


In den Klassen dieser Bibliothek finden sich Broadcasts, die unter Verwendung eines LocalBroad-

castManagers verschickt werden. In Code 6.14 ist ein Beispiel, bei dem ein Broadcast verschickt

wird, der mit der Registrierung der App beim Server in Verbindung steht.6 Auch wird das Ziel

des Intents explizit mit setClass und dem aktuellen Kontext context benannt (a.a entspricht

einem Objekt der Klasse com.twitter.library.platform.PushReceiver), was sicherheitstech-

nisch ebenfalls ein gutes Vorgehen ist, in Verbindung mit dem LocalBroadcastManager jedoch aus

Sicherheitsgründen nicht zwingend notwendig ist. Eventuell hören mehrere Broadcast-Receiver

auf dem gleichen Action-String, weswegen hier durch die explizite Angabe eine Einschränkung

auf einen bestimmten Empfänger vorgenommen wurde. Es muss angemerkt werden, dass die-

se Bibliothek von Google, also dem Android-Entwickler selbst stammt und daher von vorn-

herein ein elaborierterer Umgang mit den Absicherungsmöglichkeiten zu erwarten war. Es sei

deshalb zusätzlich angemerkt, dass der LocalBroadcastManager auch innerhalb des twitterei-

genen Codes korrekt verwendet wird, beispielsweise in der Methode com.twitter.android.

DeviceRegistrationService.a().

Code 6.14 Durch Verwendung von LocalBroadcastManager in der Klasse com.google.android.

gcm.b ist der Broadcast für Außenstehende nicht abgreifbar. Verwendetes Tool: JADX.

95 static void b(Context context , String... strArr) {96 (...)97 Intent intent = new Intent("com.google.android.c2dm.intent.←↩

REGISTRATION");98 intent.putExtra("sender", a);99 intent.setClass(context , a.a);

100 LocalBroadcastManager instance = LocalBroadcastManager.getInstance←↩(context);

101 (...)102 instance.sendBroadcast(intent);103 }

6.3.3 Verwendung von Permissions im Code

Wenn von der App anwendungsübergreifende Broadcasts verschickt werden, setzen die Entwick-

ler Permissions ein. So beispielsweise in der Klasse com.twitter.library.platform.a (Code

6.15), die in der Methode a() einen Ordered Broadcast verschickt, der durch die erwähnte Per-

mission ap.a bzw. aufgelöst com.twitter.android.permission.RESTRICTED geschützt wird.

6 Der genaue Protokollablauf soll hier nicht im Vordergrund stehen; mehr Informationen sind aber zum Beispielbei [Vog11] nachlesbar.

71

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-Apps6.3. TWITTER

Diese ist im Manifest mit dem Protection-Level signature definiert. Dadurch wird ein Man-In-

The-Middle-Angriff oder eine Denial-of-Service-Attacke verhindert.

Code 6.15 Hier wird in der Klasse com.twitter.library.platform.a ein geordneter Broadcast

durch eine Permission geschützt. Verwendetes Tool: JADX.

68 public void a(Account account , Bundle bundle , SyncResult syncResult)69 {70 (...)71 intent.putExtra(blockingGetAuthToken , z2).putExtra("data", ←↩

dataSyncResult);72 context.sendOrderedBroadcast(intent , ap.a);73 (...)74 }

6.3.4 Explizite Adressierung von Komponenten

Im Kapitel 4.3 wurde beschrieben, wie man explizite Intents zur Adressierung von Komponenten

verwenden kann. In der Twitter-App wird dies zur Bestimmung von Service-Klassen genutzt:

Diese werden ausschließlich mit expliziten Intents adressiert.

72

Kapitel 7

Erkennung von verwundbaren Codestellen durch

statische Analyse

Im Laufe der mit der Arbeit verbundenen Untersuchungen haben sich einige Anhaltspunkte

herausgestellt, die ein Analysetool automatisiert abarbeiten könnte, um die häufigsten Schwach-

stellen einer Broadcastverwendung aufzudecken. Auch wenn zuvor an vielen Stellen der Begriff

des Services genutzt wurde, um weitergehende Sicherheitsprobleme von Intents aufzuzeigen, soll

der Fokus an dieser Stelle gemäß dem Thema der Arbeit allein auf den Broadcasts verbleiben.

Meldungen des Tools können in Verwundbarkeiten und Warnungen einsortiert werden, wobei

letztere angeben, dass möglicherweise eine unsichere Verwendung der Broadcastfunktionen vor-

liegt, jedoch final eine manuelle Prüfung des Entwicklers notwendig ist. Eine verlässliche Ent-

scheidung seitens des Programms ist nicht immer möglich, da dem Tool im Allgemeinen weder

Informationen zur geplanten Einsatzumgebung bekannt sind, noch der gesamte Quellcode aller

auf dem Zielgerät installierten Apps vorliegt und ein Entwickler möglicherweise noch andere

Hintergedanken hatte, die eine bestimmte Architekturentscheidung notwendig machten.

Als Erstes lässt sich das Manifest auf ungesicherte Broadcast-Receiver untersuchen, wie schon

in Kapitel 5, Vorgehen bei einer typischen Broadcastanalyse beschrieben. Hierzu genügt

es, automatisiert alle XML-Elemente des Typs <receiver> zu prüfen, ob android:permission-

Attribute fehlen und/oder ob der Parameter von android:exported auf true steht. Falls letzte-

rer nicht angegeben ist, kann überprüft werden, ob ein Intent-Filter angegeben ist, wodurch vom

System automatisch der Standardwert true angenommen wird. Wenn Permissions angegeben

sind, muss weiter analysiert werden, welche Protection-Levels sie haben. Schwache Schutzlevels

führen dazu, dass sich schädliche Apps die entsprechenden Berechtigungen ohne weiteres aneig-

73


nen können. Diese gefährlichen Situationen müssen zu Verwundbarkeitsmeldungen führen.

Gleichzeitig bleiben aber auch – und dies ist, wie sich in den vorigen Kapiteln gezeigt hat, der

deutlich kritischere Teil – verschickte Broadcasts, die mitgeschnitten werden könnten. Hierzu

bietet es sich an, den Code auf sendBroadcast()-Aufrufe zu untersuchen. Dann muss die Me-

thodensignatur geprüft werden: Wurde die sichere sendBroadcast(Intent intent, String

receiverPermission)-Signatur verwendet oder die unsichere Variante? In letzterem Fall ist

der verschickte Broadcast ist eindeutig unsicher und kann von anderen Anwendungen mitgele-

sen werden. Das Analysetool sollte hier einen Verwundbarkeitsalarm zeigen. Wurde die sichere

Variante zum Versenden genutzt, kann man dann ggf. wie schon zuvor die Permission genauer

untersuchen.

Das Tool kann außerdem Warnhinweise geben, wenn sich an einer Stelle die Nutzung eines

LocalBroadcastManagers anbieten würde. Selbstverständlich ist mit der Analyse von nur einem

einzigen Android-Projekt nicht immer eindeutig vorhersagbar, ob es noch andere potentielle

Empfänger für einen Broadcast gibt. Folgende Hinweise können jedoch dazu genutzt werden, um

die Wahrscheinlichkeit zu bestimmen, dass ein LocalBroadcastManager ausreichen würde.

• Empfänger in der App

Gibt es für einen genutzten Action-String keinen Broadcast-Receiver in der jeweiligen App,

so kann das Tool davon ausgehen, dass eine andere Anwendung adressiert wird. Ein Lo-

calBroadcastManager bietet sich nicht an.

• Empfänger nicht exportiert

Ist der Empfänger des jeweiligen Action-Strings in der App mit android:exported=''false''

gekennzeichnet, so steigt die Wahrscheinlichkeit, dass der Intent nur innerhalb der eigenen

App verwendet wird.

• Zielklassen des Intents werden explizit adressiert

Werden die Empfänger der Broadcasts immer (oder überwiegend) explizit mit Klassen aus

dem gleichen Projekt adressiert, so kann man (zumindest an einigen Stellen) einen Lo-

calBroadcastManager verwenden, um das Risiko der unsicheren Verwendung der Broadcast-

methoden zu reduzieren.

Alternativ kann der Entwickler falls vorhanden sämtliche dazugehörige Softwareprojekte in das

Analyseprogramm laden. Dann kann es ohne Probleme alle Empfänger eines Broadcasts ermitteln

und exakt bestimmen, ob eine lokale Verwendung genügen würde.

74

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-AppsKAPITEL 7. ERKENNUNG VON VERWUNDBAREN CODESTELLEN DURCH STATISCHE

ANALYSE

Es ist außerdem zwar generell möglich, den Nutzer des Tools auf eine fehlende explizite Adres-

sierung der Intents hinzuweisen, jedoch würde es viele ”false positives” unter den Ergebnissen

geben, da diese Adressierungsart insbesondere bei mehreren verschiedenen Broadcastempfängern

unerwünscht ist. Die Anzahl der Empfänger ist vom Tool wie zuvor erläutert nicht definitiv vor-

hersagbar. Ist bekannt, dass es nur einen bestimmten Empfänger in einer App gibt, so kann ein

Hinweis auf die anwendbare explizite Adressierung gegeben werden.

Das Analysetool kann damit schon eine Liste der potentiell abfangbaren Broadcasts erstellen.

Verfeinert werden könnte die Anzeige dadurch, dass man untersucht, ob den entsprechenden

Broadcasts Extra-Einträge hinzugefügt werden. Dies könnten Benutzernamen und Passwörter

sein. Hier ist eine Filterung nach Stichwörtern wie credentials, username, password, pwd und

ähnlichen denkbar. Extras werden häufig in Form von Wrapperklassen in Intents eingebunden.

Damit hat man noch einen weiteren Anhaltspunkt, den das Tool untersuchen kann. Anstatt nur

die bezeichnenden Strings der Extra-Felder zu analysieren und sie mit Stichwörtern zu verglei-

chen, kann man die Klassen des Projekts auf von Parcelable erbende filtern. So findet man

Klassen, die für die Extra-Felder von Intents verwendet werden können. Da der originale Code

auch häufig kommentiert ist, kann man die Stichwortsuche auf diese Kommentare ausweiten,

um letztendlich Rückschlüsse auf den Broadcast an sich zu ziehen. Es stellt also einen Vorteil

dar, wenn man im Gegensatz zu den dekompilierten Klassen den originalen Quellcode besitzt –

es existieren Kommentare, die zur weiteren Informationsgewinnung genutzt werden können. All

dies entspricht gewissermaßen der in Kapitel 5.2 erläuterten Untersuchung des Einsatzkontextes

der Broadcasts.

Zuletzt können Methodenaufrufe weiter klassifiziert werden: Das Tool muss beachten, dass Sticky

Broadcasts (und Sticky Ordered Broadcasts) als veraltet markiert sind und deshalb auch hier

eine Warnung anzeigen. Werden Ordered Broadcasts verwendet, so sollten Permissions angegeben

sein. Alle Warnungen können unterschiedlichen Dringlichkeitsstufen zugeordnet werden und in

einer übersichtlichen Darstellung präsentiert werden. In vielen Fällen lassen sich kleinere Fehler

ggf. auch automatisch korrigieren. In der Liste mit den Ergebnissen könnte man im Kontextmenü

eines Listeneintrags ähnlich wie in der Entwicklungsumgebung Eclipse eine Art ”Quick fix...’-

Option gemäß Tabelle 7.1 implementieren. Abb. 7.1 illustriert das beschriebene Vorgehen des

Programms noch einmal.

75


Fall Quick-Fix

Exportierter Receiver ohne Permission. Auf Wunsch des Nutzers kann eine neue Permis-sion im Manifest deklariert werden, die bei al-len unsicheren Receiver-Deklarationen eingefügtwird. Alternativ kann er selbst eine Permissionangeben, die bereits existiert und genutzt wer-den soll.

Permission mit niedrigem/keinem Protection-Level.

Stimmt der Nutzer zu, kann der Protection-Level vom Tool auf signature hochgestuft wer-den.

Explizit adressierbarer Receiver, der auf System-Intents wartet.

Das Tool fügt in der onReceive()-Methode ei-ne If-Abfrage ein, die prüft, ob die Action desIntents der erwarteten entspricht.

Nutzung als ”veraltet” gekennzeichneter Broad-castmethoden.

Hier ist keine automatische Codeänderung mög-lich, da vermutlich weitreichende Änderungenam Projekt/an den Projekten notwendig sind.

Nutzung unsicherer Überladungen zum Sendeneines Broadcasts.

Auf Wunsch des Nutzers kann eine neue Permis-sion im Manifest deklariert werden, die bei al-len unsicheren sendBroadcast()-Aufrufen ein-gefügt wird. Alternativ kann er selbst eine Per-mission angeben, die bereits existiert und ge-nutzt werden soll.

LocalBroadcastManager verwendbar. Alle Methodenaufrufe von sendBroadcast()o.ä. werden durch LocalBroadcastManager.getInstance(this).sendBroadcast() ersetzt.Ähnliches Vorgehen bei registerReceiver().Ggf. Entfernen der vorherigen Broadcast-Receiver-Registrierungen im Manifest.

Die gewünschte Receiver-Klasse sollte explizitadressiert werden.

Der zum Verschicken genutzte Intent wirdvom Tool um einen Methodenaufruf vonsetClassName() o.ä. erweitert.

Tabelle 7.1 Mögliche automatische Lösungsverfahren bei gefundenen Broadcastverwundbarkei-ten.

76

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-AppsKAPITEL 7. ERKENNUNG VON VERWUNDBAREN CODESTELLEN DURCH STATISCHE

ANALYSE

Abbildung 7.1 Modelliertes Vorgehen eines Analysetools.

77

Kapitel 8

Fazit und Ausblick

Abschließend lässt sich sagen, dass zwar diverse Absicherungsmöglichkeiten für Broadcasts und

die in dieser Arbeit herausgestellten Sicherheitsprobleme existieren, diese jedoch auch in kom-

merziellen Android-Anwendungen häufig nicht verwendet werden. Die Gründe hierfür können

vielschichtig sein. Eine Möglichkeit ist, dass vielen Entwicklern nichts von der Existenz der be-

schriebenen sicheren Verfahrensweisen bekannt ist. Entwicklungsumgebungen wie Eclipse zeigen

in einigen Fällen jedoch Hinweise über die unsichere Broadcast-Verwendung, beispielsweise wenn

ein exportierter Receiver keine Permission anfordert.

Andererseits kann es sein, dass das Budget nicht gegeben ist, um die Apps sicherer zu machen.

Das Ausarbeiten geeigneter Permissions, das Einführen manueller Prüfungen auf die Anwen-

dungssignatur im Kontext von Services oder aber das Ermitteln von alternativen Architekturen

zur Vermeidung von Sticky Broadcasts und Sticky Ordered Broadcasts kann zeitlich aufwen-

dig sein, insbesondere wenn viele verschiedene Apps des gleichen Herstellers zusammenarbeiten

müssen. Da die letzteren nicht immer als ”veraltet” markiert waren, gibt es womöglich noch zahl-

reiche Entwickler, die an den alten Standards festhalten und es nicht anders gelernt haben. Bei

diesen Sicherheitsproblemen kann auch der Hintergedanke ”das findet schon keiner heraus” eine

Rolle spielen, speziell wenn aufwendige Obfuskierverfahren wie zum Beispiel bei der Twitterapp

zur Verschleierung eingesetzt werden. Es findet eine Abwägung zwischen Kosten und Nutzen

statt.

Alles in allem befinden sich offenbar unzählige verwundbare Anwendungen im App-Store, die

mit einfachsten Mitteln abgesichert (und auch angegriffen) werden könnten. Gleichzeitig wird

auch das Android-Betriebssystem immer weiter verbessert - die Android-Entwickler nehmen sich

mit jeder Version neuen Sicherheitsproblemen an, wie beispielsweise in Kapitel 4.1 mit der

Verhinderung der Neudeklaration von Permissions bei unterschiedlichen Anwendungssignaturen

79


in Android 5.0 aufgezeigt wurde. Unglücklich ist, dass die Android-Entwickler im Bereich der

Broadcasts nicht das Sicherheitsprinzip der ”Fail-Safe Defaults” eingesetzt haben:

The principle of fail-safe defaults states that, unless a subject is given explicit access

to an object, it should be denied access to that object. [Bis02, 344]

Dieses Zitat nach Bishop zeigt, dass in einem sicheren System keine Standardzugriffsrechte exis-

tieren sollten und jedes Zugriffsrecht explizit angefordert werden müsste. Dies ist bei Broadcasts

offensichtlich nicht der Fall, da jede Anwendung verschickte Broadcasts erhalten kann, wenn

diese nicht zusätzlich abgesichert wurden.

Auf Grundlage der Ausarbeitungen in dieser Arbeit kann man nun das in Kapitel 7 illustrierte

Tool zur automatisierten Quellcodeanalyse entwickeln. Mit einem ausgereiften Programm könnte

man sogar so weit gehen, dass jede Anwendung, die in den App-Store gestellt werden soll, zuvor

automatisiert auf die klassischen Sicherheitsprobleme untersucht wird. Eine Veröffentlichung wird

dann ggf. verweigert, wenn das Tool eine definitive Sicherheitslücke aufspürt. Entwickler können

die Arbeit darüber hinaus heranziehen, um ihre eigenen Anwendungen auf typische Fehler zu

untersuchen und sie gemäß den Ausführungen aus Kapitel 4 abzusichern.

80

Anhang A

Anhang

A.1 Programmcode

A.1.1 Code zum Kapitel 2.3.1.1

Code A.1 Grundstruktur der Manifest-Datei nach [Wik15]1 <?xml version="1.0" encoding="utf -8"?>2 <manifest>3 <uses-permission />4 <permission />5 <permission -tree />6 <permission -group />7 <instrumentation />8 <uses-sdk />9 <uses-configuration />

10 <uses-feature />11 <supports -screens />12 <compatible -screens />13 <supports -gl-texture />1415 <application>1617 <activity>18 <intent -filter>19 <action />20 <category />21 <data />22 </intent -filter>23 <meta-data />24 </activity>2526 <activity -alias>27 <intent -filter> . . . </intent -filter>28 <meta-data />29 </activity -alias>3031 <service>32 <intent -filter> . . . </intent -filter>33 <meta-data/>34 </service>3536 <receiver>

81

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-AppsA.1. PROGRAMMCODE

37 <intent -filter> . . . </intent -filter>38 <meta-data />39 </receiver>4041 <provider>42 <grant -uri-permission />43 <meta-data />44 </provider>4546 <uses-library />4748 </application>49 </manifest>

A.1.2 Code zu Kapitel 6.1

Code A.2 Nachbildung der dekompilierten CredentialsHTTPParser.java in korrekter Syntax.1 package de.telekom.hotspotlogin.protocol.sms;23 import android.os.Parcel;4 import android.os.Parcelable;56 public class CredentialsHttpParser implements Parcelable {7 private String stra;8 private String strb;9 private String strc;

1011 public int describeContents() {12 return 0;13 }1415 public void setUsernameA(String a){16 stra = a;17 }1819 public void setPwdB(String b){20 strb = b;21 }2223 public void setParamC(String c){24 strc = c;25 }2627 public String getUsernameA(){28 return stra;29 }3031 public String getPwdB(){32 return strb;33 }3435 public String getParamC(){36 return strc;37 }3839 public void writeToParcel(Parcel out, int flags) {40 out.writeString(stra);41 out.writeString(strb);42 out.writeString(strc);

82

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-AppsANHANG A. ANHANG

43 }4445 public static final Parcelable.Creator <CredentialsHttpParser > CREATOR←↩

= new Parcelable.Creator <CredentialsHttpParser >() {46 public CredentialsHttpParser createFromParcel(Parcel in) {47 return new CredentialsHttpParser(in);48 }4950 public CredentialsHttpParser[] newArray(int size) {51 return new CredentialsHttpParser[size];52 }53 };5455 private CredentialsHttpParser(Parcel in) {56 stra = in.readString();57 strb = in.readString();58 strc = in.readString();59 }60 public CredentialsHttpParser() {6162 }

Code A.3 Dekompilierte aE-Klasse mit Statusangaben für die Captcha-Abfrage.1 package defpackage;23 public enum aE {4 CHALLENGE_REQUIRED ,5 CHALLENGE_NOT_REQUIRED ,6 SUCCESS ,7 FAILURE ,8 BLOCKED ,9 SESSION_EXPIRED ,

10 TECHNICAL_ERROR11 }

Code A.4 Dekompilierte b-Klasse mit Statusangaben zur Zugangsdatenermittlung.1 public enum b {2 SUCCESS ,3 SESSION_TIMEOUT ,4 TECHNICAL_ERROR ,5 SMS_STATUS_CREDENTIALS_RECEIVED6 }

83

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-AppsA.2. DATENTRÄGER

A.2 DatenträgerAuf der beigelegten CD befinden sich die in Kapitel 6 referenzierten Android-Apps als APK, diedekompilierten Ergebnisse verschiedener Tools und die dazugehörigen Manifest-Dateien. Außer-dem sind Projekte enthalten, die Konzepte verdeutlichen sollen oder aber Exploits realisieren.

84


A.3 Abbildungsverzeichnis

2.1 Schematischer Ablauf des Signiervorgangs, basierend auf [Acd08]. Lizenz: CreativeCommons Attribution-Share Alike 3.0 Unported. . . . . . . . . . . . . . . . . . . 9

2.2 Allgemeiner Aufbau von Android. Das System ist hierarchisch aufgebaut: Zunächstexistieren hardwarenahe Treiber aus dem Linux-Kernel, auf der letzten Schichtfolgen dann die fertigen Apps. Bildquelle: [Vas09], Lizenz: GDFL. . . . . . . . . . 11

2.3 Verarbeitung von Intents in Android. Activity A möchte eine andere Activity star-ten, generiert einen Intent und übergibt ihn der Methode startActivity() (1).Das Betriebssystem sucht Anwendungen, auf die der Klassenname passt (2) undruft ggf. onCreate() der passenden Activity auf (3). Bildquelle: [Gooh], Lizenz:Creative Commons Attribution 2.5. . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4 Organisation eines Ressourcenordners unter Android. Abkürzungen in den Ord-nernamen wie hdpi (High Dots Per Inch) und ähnliche ermöglichen eine Sortierungder Bilddateien nach Bildschirmauflösung des Zielgeräts. . . . . . . . . . . . . . . 17

3.1 Eine Toast-Benachrichtigung nach Ändern der Zeitzone. . . . . . . . . . . . . . . 24

4.1 Der Benutzer wird bei bestimmten Schutzlevels gefragt, ob er der Berechtigungs-anforderung zustimmt (links). Nach Klick auf einen Eintrag in der Liste wird eineBeschreibung angezeigt (rechts). . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.1 Datenflussdiagramm der Telekom-App zur Anforderung der Zugangsdaten perHTTPS. Es wurden die Stellen rot gekennzeichnet, die eine Nutzung der HTTPS-Funktion verhindern. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.2 Schematischer Aufbau der Kommunikation mit Client Hub nach [VP15]. . . . . . 616.3 Schematischer Aufbau der betrachteten Klassen. Die Klasse clientHub.MCIMService

stellt im Produktiveinsatz den exportierten Service der installierten Client-Hub-Instanz dar und befindet sich aus unbekannten Gründen in der Incident-Management-App. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.4 Datenflussdiagramm für das Generieren des startService()-Intents mit sämtli-chen sensiblen Benutzerdaten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7.1 Modelliertes Vorgehen eines Analysetools. . . . . . . . . . . . . . . . . . . . . . . 77

85

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-AppsA.4. TABELLENVERZEICHNIS

A.4 Tabellenverzeichnis

2.1 Beispiel für eine mit DVM-Instruktionen mögliche Einsparung von drei Instruk-tionen bei einer einfachen Integer-Addition gemäß [Hua12]. . . . . . . . . . . . . 20

3.1 Auflistung der möglichen Parameter für Receiver im Manifest nach [Gook]. . . . 233.2 Gegenüberstellung wesentlicher Eigenschaften der Broadcastarten. Vgl. [Dro15]. . 29

4.1 Mögliche Werte und Flags für android:protectionLevel (Vgl. [Gooj], [Med+13,107]), [Ele14, 38 ff.]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

7.1 Mögliche automatische Lösungsverfahren bei gefundenen Broadcastverwundbar-keiten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

86


A.5 Codeverzeichnis2.1 Ein expliziter Intent unter Angabe des Klassennamens der Zielactivity. . . . . . . . 132.2 Intent-Filter im Manifest. Hier für das Anzeigen einer Internetseite nach [Mic12]. . 142.3 Generierung eines impliziten Intents zum Öffnen einer Internetseite [...] . . . . . . . 142.4 Definition eines Services im Manifest. [...] . . . . . . . . . . . . . . . . . . . . . . . . . . 152.5 Festlegen der initialen Activity im Manifest. . . . . . . . . . . . . . . . . . . . . . . . . 163.1 Auszug des Manifests für ein typisches Broadcast-Receiver-Beispiel . . . . . . . . . . 223.2 Aufbau der MyBroadcastReceiver-Klasse. . . . . . . . . . . . . . . . . . . . . . . . . . 233.3 Dynamisches Binden an den Intent-Filter aus Code 3.1. . . . . . . . . . . . . . . . . . 243.4 Verschicken eines normalen Broadcasts. . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.5 Anpassung im Manifest. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.6 Verwendung eines Sticky Broadcast. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.1 Deklaration einer Permission im Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . 384.2 Anforderung einer Permission im Manifest . . . . . . . . . . . . . . . . . . . . . . . . . 406.1 Besonders interessanter Auszug aus dem Manifest der OnlineManager-App . . . . . 516.2 Code aus HotSpotLoginService.java. Verwendetes Tool: JADX. . . . . . . . . . . 546.3 Ausschnitt aus de.telekom.hotspotlogin.service.a. [...] . . . . . . . . . . . . . . . 546.4 Code aus ui.C0085af.onClick(). Verwendetes Tool: JADX. . . . . . . . . . . . . . 566.5 Code aus ui.C0088ai.onClick(). Verwendetes Tool: JADX. . . . . . . . . . . . . . 576.6 In der Klasse MobileCustomerCredentialEditor werden die [...] . . . . . . . . . . . 576.7 Explizites Starten des Client-Hub-Services in clientHubSLL.ClientHub. [...] . . . . 636.8 Interessanter Ausschnitt aus der MCIMService-Klasse. [...] . . . . . . . . . . . . . . . . 666.9 Fataler Code aus der ClientHubServiceHelper-Klasse, der zum [...] . . . . . . . . . 676.10 Korrigierter Code aus der aktuellen SDK-Version 3.0 SP08 [...] . . . . . . . . . . . . . 686.11 Relevante, selbstdefinierte Permissions aus der Twitter-App. . . . . . . . . . . . . . . 696.12 Mit Permission geschützter Broadcast-Receiver. . . . . . . . . . . . . . . . . . . . . . . 706.13 Durch exported-Attribut geschützter Broadcast-Receiver. . . . . . . . . . . . . . . . 706.14 Durch Verwendung von LocalBroadcastManager in der Klasse [...] . . . . . . . . . . 716.15 Hier wird in der Klasse com.twitter.library.platform.a ein [...] . . . . . . . . . . 72A.1 Grundstruktur der Manifest-Datei nach [Wik15] . . . . . . . . . . . . . . . . . . . . . . 81A.2 Nachbildung der dekompilierten CredentialsHTTPParser.java [...]. . . . . . . . . . . . 82A.3 Dekompilierte aE-Klasse mit Statusangaben für die Captcha-Abfrage. . . . . . . . . 83A.4 Dekompilierte b-Klasse mit Statusangaben zur Zugangsdatenermittlung. . . . . . . . 83

87

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-AppsLITERATUR

Literatur[Bec11] Arno Becker. »Innenansichten - Die Architektur von Android«. In: c’t (Apr. 2011).

[In Auszügen abrufbar unter http://www.heise.de/ct/artikel/Innenansichten-1176816.html].

[Bis02] Matt Bishop. Computer Security: Art and Science. Addison-Wesley Professional,Dez. 2002. isbn: 978-0201440997.

[BP09] Arno Becker und Marcus Pant. Android. Grundlagen und Programmierung. 1. Aufl.dpunkt.verlag, Mai 2009. isbn: 978-3898645744.

[BSW10] Albrecht Beutelspacher, Jörg Schwenk und Klaus-Dieter Wolfenstetter. ModerneVerfahren der Kryptographie. 7. Aufl. Vieweg + Teubner, Mai 2010. isbn: 978-3834812285.

[CGK11] Charlie Collins, Michael Galpin und Matthias Kaeppler. Android in Practice. 1. Aufl.Manning Publications, Okt. 2011. isbn: 978-1935182924.

[Ele14] Nikolay Elenkov. Android Security Internals: An In-Depth Guide to Android’s Secu-rity Architecture. 1. Aufl. No Starch Press, Okt. 2014. isbn: 978-1593275815.

[Med+13] Zigurd Mednieks, G. Blake Meike, Laird Dornin und Zane Pan. Enterprise Android:Programming Android Database Applications for the Enterprise. 1. Aufl. John Wiley& Sons, Okt. 2013. isbn: 978-1118183496.

[MK09] Heiko Mosemann und Matthias Kose. Android. Anwendungen für das Handy-Betriebs-system erfolgreich programmieren. Carl Hanser Verlag GmbH & Co. KG, Juni 2009.isbn: 978-3446417281.

[MKA15] Dave MacLean, Satya Komatineni und Grant Allen. Pro Android 5. 5. Aufl. Apress,Juni 2015. isbn: 978-1430246817.

88


Quellen aus der Google-Entwicklerdokumentation[Gooa] Google. Android Glossary. [Stand 30. April 2015]. url: https://developer.android.

com/guide/appendix/glossary.html.[Goob] Google. Android Lollipop. [Stand 19. Juli 2015]. url: http://developer.android.com/

about/versions/lollipop.html#Perf.[Gooc] Google. App Manifest. [Stand 06. Juni 2015]. url: http://developer.android.com/

guide/topics/manifest/manifest-intro.html.[Good] Google. BroadcastReceiver. [Stand 30. April 2015]. url: http://developer.android.

com/reference/android/content/BroadcastReceiver.html.[Gooe] Google. Context. [Stand 05. Mai 2015]. url: http : / / developer . android . com /

reference/android/content/Context.html.[Goof] Google. Intent. [Stand 11. August 2015]. url: http : / / developer . android . com /

reference/android/content/Intent.html.[Goog] Google. <intent-filter>. [Stand 11. August 2015]. url: http://developer.android.

com/guide/topics/manifest/intent-filter-element.html.[Gooh] Google. Intents and Intent Filters. [Stand 19. Juli 2015]. url: http ://developer .

android.com/guide/components/intents-filters.html#Types.[Gooi] Google. LocalBroadcastManager. [Stand 21. Juli 2015]. url: http : / / developer .

android.com/reference/android/support/v4/content/LocalBroadcastManager.html.[Gooj] Google. <permission>. [Stand 09. Mai 2015]. url: http://developer.android.com/

reference/android/content/Context.html.[Gook] Google. <receiver>. [Stand 05. Mai 2015]. url: http ://developer .android . com/

guide/topics/manifest/receiver-element.html.[Gool] Google. Services. [Stand 30. April 2015]. url: http://developer.android.com/guide/

components/services.html.[Goom] Google. Signing Your Applications. [Stand 24. Mai 2015]. url: http://developer.

android.com/tools/publishing/app-signing.html.

89

https://developer.android.com/guide/appendix/glossary.html

https://developer.android.com/guide/appendix/glossary.html

http://developer.android.com/about/versions/lollipop.html#Perf

http://developer.android.com/about/versions/lollipop.html#Perf

http://developer.android.com/guide/topics/manifest/manifest-intro.html

http://developer.android.com/guide/topics/manifest/manifest-intro.html

http://developer.android.com/reference/android/content/BroadcastReceiver.html

http://developer.android.com/reference/android/content/BroadcastReceiver.html

http://developer.android.com/reference/android/content/Context.html


http://developer.android.com/reference/android/content/Intent.html

http://developer.android.com/reference/android/content/Intent.html

http://developer.android.com/guide/topics/manifest/intent-filter-element.html

http://developer.android.com/guide/topics/manifest/intent-filter-element.html

http://developer.android.com/guide/components/intents-filters.html#Types

http://developer.android.com/guide/components/intents-filters.html#Types

http://developer.android.com/reference/android/support/v4/content/LocalBroadcastManager.html

http://developer.android.com/reference/android/support/v4/content/LocalBroadcastManager.html



http://developer.android.com/guide/topics/manifest/receiver-element.html

http://developer.android.com/guide/topics/manifest/receiver-element.html

http://developer.android.com/guide/components/services.html

http://developer.android.com/guide/components/services.html

http://developer.android.com/tools/publishing/app-signing.html

http://developer.android.com/tools/publishing/app-signing.html

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-AppsINTERNETQUELLEN UND WEITERES MATERIAL

Internetquellen und weiteres Material[Acd08] Acdx. Digital Signature diagram. [Stand 24. Mai 2015]. 2008. url: http://commons.

wikimedia.org/wiki/File:Digital_Signature_diagram.svg.[Alb11] Bruno Albuquerque. Processing Ordered Broadcasts. [Stand 18. Juni 2015]. Jan. 2011.

url: http://android-developers.blogspot.de/2011/01/processing-ordered-broadcasts.html.

[All] Open Handset Alliance. Members. [Stand 28. April 2015]. url: http : / / www .openhandsetalliance.com/oha_members.html.

[App] Just An Application. The Android Intent Based APIs: Part Six – Broadcast In-tents. [Stand 13. August 2015]. url: https://justanapplication.wordpress.com/tag/sendstickyorderedbroadcast/.

[BIT13] BITKOM. Bankgeschäfte mit dem Smartphone. [Stand 15. Mai 2015]. Juni 2013.url: http://www.bitkom.org/de/presse/78284_76410.aspx.

[BSG14a] Carsten Bormann, Karsten Sohr und Stefanie Gerdes. Informationssicherheit: Ein-führung. Foliensatz 1. Foliensatz des Moduls ’Informationssicherheit’ der UniversitätBremen. Okt. 2014.

[BSG14b] Carsten Bormann, Karsten Sohr und Stefanie Gerdes. Informationssicherheit: Kryp-tographie. Foliensatz 6. Foliensatz des Moduls ’Informationssicherheit’ der Universi-tät Bremen. Okt. 2014.

[BSG14c] Carsten Bormann, Karsten Sohr und Stefanie Gerdes. IT-Sicherheit: Digitale Signa-tur, Zertifikate, PKI, E-Mail-Sicherheit. Foliensatz 9. Foliensatz des Moduls ’Infor-mationssicherheit’ der Universität Bremen. Dez. 2014.

[BSG14d] Carsten Bormann, Karsten Sohr und Stefanie Gerdes. IT-Sicherheit: Zugriffskon-trolle. Foliensatz 2. Foliensatz des Moduls ’Informationssicherheit’ der UniversitätBremen. Okt. 2014.

[Com15] CommonsWare. startService() with Permissions. Internetforum. [Stand 04. Au-gust 2015]. 3. Aug. 2015. url: http : / / stackoverflow . com / questions / 31792338 /startservice-with-permissions?noredirect=1#comment51514522_31792338.

[Coo+08] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley und W. Polk. InternetX.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL)Profile. [Stand 28. August 2015]. Mai 2008. url: https://tools.ietf.org/html/rfc5280.

[dev] IBM developerWorks. Understanding security on Android. [Stand 21. Juli 2015]. url:http://www.ibm.com/developerworks/library/x-androidsecurity/.

[Dro15] Drops. Android Broadcast Security. [Stand 11. August 2015]. Juli 2015. url: http://translate.wooyun.io/2015/07/22/Android-Broadcast-Security.html.

[Ehr10] David Ehringer. The Dalvik Virtual Machine Architecture. [Stand 28. August 2015].März 2010. url: http ://show.docjava .com/posterous/ file/2012/12/10222640-The_Dalvik_Virtual_Machine.pdf.

[EOM09] William Enck, Machigar Ongtang und Patrick McDaniel. »Understanding AndroidSecurity«. In: IEEE Transactions on Signal Processing information for authors 7.1(Jan. 2009). [Stand 10. Mai 2015]. url: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4768655.

[Gil14] David Gilbert. Malware Posing as Official Google Play App Found in....Official Goog-le Play Store. [Stand 15. Mai 2015]. Juni 2014. url: http://www.ibtimes.co.uk/malware-posing-official-google-play-app-found-official-google-play-store-1453409.

[Gru15] Ben Gruver. Smali: About. [Stand 04. August 2015]. Apr. 2015. url: https://code.google.com/p/smali/.

90

http://commons.wikimedia.org/wiki/File:Digital_Signature_diagram.svg

http://commons.wikimedia.org/wiki/File:Digital_Signature_diagram.svg

http://android-developers.blogspot.de/2011/01/processing-ordered-broadcasts.html

http://android-developers.blogspot.de/2011/01/processing-ordered-broadcasts.html

http://www.openhandsetalliance.com/oha_members.html


https://justanapplication.wordpress.com/tag/sendstickyorderedbroadcast/

https://justanapplication.wordpress.com/tag/sendstickyorderedbroadcast/

http://www.bitkom.org/de/presse/78284_76410.aspx

http://stackoverflow.com/questions/31792338/startservice-with-permissions?noredirect=1#comment51514522_31792338

http://stackoverflow.com/questions/31792338/startservice-with-permissions?noredirect=1#comment51514522_31792338

https://tools.ietf.org/html/rfc5280

http://www.ibm.com/developerworks/library/x-androidsecurity/

http://translate.wooyun.io/2015/07/22/Android-Broadcast-Security.html

http://translate.wooyun.io/2015/07/22/Android-Broadcast-Security.html

http://show.docjava.com/posterous/file/2012/12/10222640-The_Dalvik_Virtual_Machine.pdf

http://show.docjava.com/posterous/file/2012/12/10222640-The_Dalvik_Virtual_Machine.pdf

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4768655

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4768655

http://www.ibtimes.co.uk/malware-posing-official-google-play-app-found-official-google-play-store-1453409

http://www.ibtimes.co.uk/malware-posing-official-google-play-app-found-official-google-play-store-1453409

https://code.google.com/p/smali/

https://code.google.com/p/smali/


[Hua12] Jim Huang. Understanding the Dalvik Virtual Machine. Präsentation. [Stand 28.August 2015]. Nov. 2012. url: http://www.slideshare.net/jserv/understanding-the-dalvik-virtual-machine.

[Klu14] Jan Kluczniok. BlackBerry: So installieren und nutzen Sie Android-Apps. [Stand 13.Mai 2015]. Feb. 2014. url: http://www.netzwelt.de/news/118231-blackberry- so-installieren-nutzen-android-%09apps.html.

[Lev13] Joe Levi. Dalvik vs. ART: Android virtual machines and the battle for better per-formance. [Stand 28. April 2015]. Nov. 2013. url: http://www.openhandsetalliance.com/oha_members.html.

[Mic12] MichaelP. What is the different between Explicit and implicit activity call in android?Internetforum. [Stand 17. Mai 2015]. Apr. 2012. url: http://stackoverflow.com/questions/10272699/what- is- the-different-between-explicit-and- implicit-activity-call-in-android.

[mik13] one mikro2nd. Darker Corners of Android: BroadcastReceivers and Intents. [Stand13. August 2015]. Sep. 2013. url: http://onemikro2nd.blogspot.de/2013/09/darker-corners-of-android.html.

[Mur15a] Mark Murphy. CWAC Security: Helping You Help Your Users Defend Their Data.[Stand 06. August 2015]. Juli 2015. url: https://github.com/commonsguy/cwac-security/#usage-checkcustompermissions.

[Mur15b] Mark Murphy. The Custom Permission Problem. [Stand 06. August 2015]. Juli 2015.url: https://github.com/commonsguy/cwac-security/blob/master/PERMS.md.

[nln14] nln. SAP Mobile Platform (SMP) 2.3 Vs 3.0 – Comparison by Features. [Stand 29.Juli 2015]. Juni 2014. url: http://enterprisemobilityblog.com/sap-mobile-platform-smp-2-3-vs-3-0-comparison-by-features/.

[Riv13] Jorge Suarez Rivaya. »Dalvik«. In: (Okt. 2013). [Stand 21. Juli 2015]. url: http://anatomyofandroid.com/2013/10/20/dalvik/.

[RL15] Margaret Rouse und George Lawton. Middleware. [Stand 19. Juli 2015]. Juni 2015.url: http://searchsoa.techtarget.com/definition/middleware.

[SAPa] SAP. DataVault. [Stand 26. Juni 2015]. url: http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc01925.0232/doc/html/jne1318272064787.html.

[SAPb] SAP. Kapsel. [Stand 06. Juli 2015]. url: http://scn.sap.com/blogs/johnwargo/2013/10/21/an-introduction-to-smp-kapsel.

[SAPc] SAP. Managing Android Application Registration Using Client Hub. [Stand 26. Ju-ni 2015]. url: http : / / help . sap . com / saphelp _ smp303sdk / helpdata / en / 7c /1c1ced70061014aff2cbebaea7f018/content.htm.

[SAPd] SAP. OData in a Nutshell. [Stand 06. Juli 2015]. url: http://wiki.scn.sap.com/wiki/download/attachments/233739132/02_odata_in_a_nutshell.pdf.

[sta15] statista. Vergleich der Marktanteile von Android und iOS am Absatz von Smartphonesin Deutschland von Januar 2012 bis Juli 2015. [Stand 15. September 2015]. 2015.url: http://de.statista.com/statistik/daten/studie/256790/umfrage/marktanteile-von-android-und-ios-am-smartphone-absatz-in-deutschland/.

[Tut15] Volker Tutt. Private E-Mail-Konversation zur OnlineManager-App der Telekom. Zi-tat eines namentlich nicht näher genannten Entwicklers der OnlineManager-App.Aug. 2015.

[Vas09] Alvaro Fuentes Vasquez. Diagram System architecture Android. [Stand 28. April2015]. 2009. url: http : / / commons . wikimedia . org / wiki / Category : Android _architecture#/media/File:Diagram_android.png.

91

http://www.slideshare.net/jserv/understanding-the-dalvik-virtual-machine

http://www.slideshare.net/jserv/understanding-the-dalvik-virtual-machine

http://www.netzwelt.de/news/118231-blackberry-so-installieren-nutzen-android-%09apps.html

http://www.netzwelt.de/news/118231-blackberry-so-installieren-nutzen-android-%09apps.html



http://stackoverflow.com/questions/10272699/what-is-the-different-between-explicit-and-implicit-activity-call-in-android



http://onemikro2nd.blogspot.de/2013/09/darker-corners-of-android.html

http://onemikro2nd.blogspot.de/2013/09/darker-corners-of-android.html

https://github.com/commonsguy/cwac-security/#usage-checkcustompermissions

https://github.com/commonsguy/cwac-security/#usage-checkcustompermissions

https://github.com/commonsguy/cwac-security/blob/master/PERMS.md

http://enterprisemobilityblog.com/sap-mobile-platform-smp-2-3-vs-3-0-comparison-by-features/

http://enterprisemobilityblog.com/sap-mobile-platform-smp-2-3-vs-3-0-comparison-by-features/

http://anatomyofandroid.com/2013/10/20/dalvik/

http://anatomyofandroid.com/2013/10/20/dalvik/

http://searchsoa.techtarget.com/definition/middleware

http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc01925.0232/doc/html/jne1318272064787.html



http://scn.sap.com/blogs/johnwargo/2013/10/21/an-introduction-to-smp-kapsel

http://scn.sap.com/blogs/johnwargo/2013/10/21/an-introduction-to-smp-kapsel

http://help.sap.com/saphelp_smp303sdk/helpdata/en/7c/1c1ced70061014aff2cbebaea7f018/content.htm

http://help.sap.com/saphelp_smp303sdk/helpdata/en/7c/1c1ced70061014aff2cbebaea7f018/content.htm

http://wiki.scn.sap.com/wiki/download/attachments/233739132/02_odata_in_a_nutshell.pdf

http://wiki.scn.sap.com/wiki/download/attachments/233739132/02_odata_in_a_nutshell.pdf

http://de.statista.com/statistik/daten/studie/256790/umfrage/marktanteile-von-android-und-ios-am-smartphone-absatz-in-deutschland/

http://de.statista.com/statistik/daten/studie/256790/umfrage/marktanteile-von-android-und-ios-am-smartphone-absatz-in-deutschland/

http://commons.wikimedia.org/wiki/Category:Android_architecture#/media/File:Diagram_android.png

http://commons.wikimedia.org/wiki/Category:Android_architecture#/media/File:Diagram_android.png

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-AppsINTERNETQUELLEN UND WEITERES MATERIAL

[Vog11] Lars Vogel. Android Cloud to Device Messaging (C2DM) - Tutorial. [Stand 10. Juli2015]. Dez. 2011. url: http://www.vogella.com/tutorials/AndroidCloudToDevice-Messaging/article.html#implementation_mobileregistration.

[VP15] Midhun VP. 2 Steps to Manage Mobile App Registration using Client Hub. [Stand26. Juni 2015]. März 2015. url: http://scn.sap.com/community/developer-center/mobility-platform/blog/2015/03/30/2-steps- to-manage-mobile-app-registration-using-client-hub.

[Wik15] WikiBooks. Das Manifest. [Stand 07. Mai 2015]. 2015. url: http://de.wikibooks.org/wiki/Googles_Android/_Das_Manifest.

92

http://www.vogella.com/tutorials/AndroidCloudToDevice-Messaging/article.html#implementation_mobileregistration

http://www.vogella.com/tutorials/AndroidCloudToDevice-Messaging/article.html#implementation_mobileregistration

http://scn.sap.com/community/developer-center/mobility-platform/blog/2015/03/30/2-steps-to-manage-mobile-app-registration-using-client-hub



http://de.wikibooks.org/wiki/Googles_Android/_Das_Manifest

http://de.wikibooks.org/wiki/Googles_Android/_Das_Manifest

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-AppsAbkürzungsverzeichnis

A.6 AbkürzungsverzeichnisAPK Android-Package, S. 2, 3, 8, 17–19, 45, 46, 51, 58, 66, 69, 84, 94 ART Android RunTime, S. 10

CA Certification Authority, S. 8

DAC Discretionary Access Control, S. 6, 20DVM Dalvik Virtual Machine, S. 10, 17–20, 86, 95

GUI Graphical User Interface, S. 12, 24, 56

HTTP Hypertext Transfer Protocol, S. 55HTTPS Hyper Text Transfer Protocol Secure, S. 54, 58–60, 85

MAC Mandatory Access Control, S. 6, 40, 94

REST Representational State Transfer, S. 96

VM Virtuelle Maschine, S. 8, 10, 19–21, 46

WLAN Wireless Local Area Network, S. 10, 53, 56, 58, 59

XML Extensible Markup Language, S. 12, 16, 32, 73, 96

93

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-AppsA.7. GLOSSAR

A.7 GlossarAction

Der Prozess der Kommunikation zwischen verschiedenen Softwarekomponenten durch In-tents.

Action-StringDer Bezeichner der durchzuführenden Action. Im Kontext dieser Bachelorarbeit also insb.der Titel, unter dem ein Broadcast verschickt und empfangen werden kann. Er wird inJava-Namespace-Form angegeben (beispielsweise com.example.myBroadcastName).

ActionhandlerBezeichnet Code, der ausgeführt wird, wenn mit einem GUI-Element eine Interaktion statt-findet. Der Code wird also beispielsweise durch den Klick auf einen Button ausgelöst.

ActivityBezeichnet eine bildschirmfüllende Programmansicht einer App.

Android-Package (APK)Ein Dateiformat, in dem Androidanwendungen in kompilierter Form an Nutzer verteilt wer-den.

App-StoreBeschreibt eine Plattform, über die Anwendungen für Mobilgeräte vertrieben werden. Deroffizielle App-Store für Android heißt beispielsweise Google Play Store.

Asymmetrisches KryptoverfahrenEin asymmetrisches Kryptoverfahren zeichnet sich dadurch aus, dass zur Ver-/Entschlüsselungein Schlüsselpaar verwendet wird - ein Schlüssel für die Verschlüsselung, einer für die Ent-schlüsselung. Siehe Kapitel 2.2.

Asynchrone AusführungMit dem Aufruf einer asynchronen Unterroutine wird die Ausführung der aufrufenden Me-thode fortgesetzt, ohne auf die vollständige Abarbeitung der Unterroutine zu warten. Hierzuwerden z.B. zusätzliche Threads verwendet.

Bell-LaPadulaEin MAC-Sicherheitsmodell, bei dem Objekte (Dateien, Geräte, ...) und Subjekte (Benutzer,Prozesse, ...) Vertraulichkeitsmarkierungen erhalten. Der Zugriff auf Objekte einer Vertrau-lichkeitsklasse kann nur von Subjekten mit einer entsprechenden Sicherheitsstufe erfolgen.[BSG14d]

Broadcast-ReceiverBroadcast-Receiver empfangen Broadcasts, die von anderen Apps oder einer anderen An-wendungskomponente verschickt wurden.

Brute-Force-AttackeAngriffsmethode, bei der versucht wird, ein Passwort, einen Zugangscode oder ähnlich sen-sible Daten allein durch Ausprobieren (ggf. unter Verwendung verschiedener Heuristiken)herauszufinden.

Build-ProzessFasst das Kompilieren von Java-Source-Code in DVM-Bytecode, das Sammeln der von einerAnwendung verwendeten Ressourcen sowie das Erstellen einer APK-Datei zusammen.

CaptchaCaptchas werden benutzt, um automatisierte Anfragen von Scripts an einen Dienst zu unter-binden, indem der Nutzer z.B. eine (visuell verzerrte) dargestellte Buchstabenfolge abtippenmuss.

94

Bachelorarbeit Untersuchung zur Broadcastsicherheit von Android-AppsGlossar

Certification AuthorityEine vertrauenswürdige Instanz, die Zuordnungen von Zertifikaten zu ihren Besitzern be-glaubigt. Vgl. Kapitel 2.2.

Dalvik Virtual MachineEine spezielle virtuelle Maschine, in der Android-Apps ausgeführt werden.

DekompilierenVersuch, den Vorgang des Kompilierens rückgängig zu machen und an Code zu gelangen,der idealerweise dem ursprünglichen Quellcode entspricht.

Denial-of-Service-AttackeVersuch, die Verfügbarkeit von Systemkomponenten einzuschränken (vgl. Kapitel 2.1). Dazukann ein Computersystem beispielsweise durch extrem viele simultane Anfragen überlastetwerden oder es wird durch Schadsoftware die Weiterleitung von bestimmten Steuerinforma-tionen verhindert.

dexAbkürzung für Dalvik Executable - bezeichnet den in der DVM ausführbaren Bytecode.

Digitale SignierungEin Verfahren, bei dem die Herkunft und die Unversehrtheit von Daten durch eine virtuelleUnterschrift bestätigt wird. Vgl. Kapitel 2.2

EnumMit Enums (oder Enumerationen) können in der Programmierung sehr leicht Aufzählungenrealisiert werden.

ExploitBezeichnet die Vorgehensweise, die zur Durchführung eines Angriffs durch Ausnutzen einerSchwachstelle in einem Programm notwendig ist.

ExportDie Eigenschaft exported gibt an, ob andere Apps mit einer Komponente der eigenen An-wendung interagieren können.

ExtraEin Extra ist eine Zusatzinformation beliebigen Typs, die einem Intent beigefügt und auchwieder ausgelesen werden kann.

HashwertEine (kryptografische) Hashfunktion bildet variabel lange Binärdaten auf eine im idealenFalle individuelle Prüfsumme (den Hashwert) fester Länge ab.

HotspotHotspots sind an öffentlichen Orten aufgestellte Access Points, die meist gegen Zahlung einesgewissen Betrags zeitlich begrenzten Zugang zum Internet ermöglichen.

Hyper Text Transfer Protocol Secure (HTTPS)Bezeichnet ein Protokoll für die sichere Datenübertragung im Internet, bei dem die Kom-munikation durch verschiedene Verfahren verschlüsselt werden kann.

IntentBezeichnet ein Programmobjekt, welches dem Betriebssystem mitteilt, dass die App einebestimmte Absicht hat - z.B. das Öffnen eines anderen Fensters oder das Überbringen einerNachricht an eine andere App.

Intent-FilterEin Intent-Filter sorgt dafür, dass eine Komponente auf Intents reagiert, die implizit unterder im Filter angegebenen Bezeichnung (siehe Action-String) verschickt wurden.

95


iOSVon Apple entwickeltes, auf Mac OS basierendes Betriebssystem, welches ähnlich wie An-droid für Mobilgeräte ausgelegt ist.

Kontext (Android)Der Kontext ermöglicht es, auf Anwendungsressourcen zuzugreifen und Aktionen auf Anwen-dungsebene auszuführen (beispielsweise das Öffnen einer anderen Activity oder das Verschi-cken von Broadcasts). Er dient außerdem dazu, dem System eine Referenz auf die jeweiligeAnwendung zu liefern.

LayoutDas Layout beschreibt die Aufteilung einer grafischen Benutzeroberfläche, häufig in einerXML-Datei.

Man-In-The-Middle-AngriffEin Angriffsszenario, bei dem ein Dritter eine Datenübertragung abhören und eventuell sogarmanipulieren kann.

Mandatory Access ControlBezeichnet ein Sicherheitsprinzip, bei dem das System eine Sicherheitsrichtlinie umsetzt.Benutzer können Rechte also nicht einfach selbst verteilen oder verändern.

ManifestJede Android-App beinhaltet eine Manifest-Datei, die Eigenschaften der Anwendung fest-legt. Vgl. Kapitel 2.3.1.1.

MiddlewareBezeichnet Software, die zwei Ebenen eines Softwaresystems verbindet (vgl. [RL15]). AlsAndroid-Middleware wird typischerweise die als ”Libraries” bezeichnete Schicht aus Abb.2.2 bezeichnet [CGK11].

ObfuskierenProgrammcode kann obfuskiert werden, also vor dem Kompiliervorgang z.B. durch Umbe-nennung der Methoden-, Variablen- und Klassennamen so verändert werden, dass es einempotentiellen Dekompilierer erschwert wird, dessen ursprüngliche Bedeutung zu verstehen.

ODataEin offenes Protokoll zur Entwicklung von REST-basierten Anwendungen (vgl. [SAPd]).

Ordered BroadcastHierbei werden Broadcast-Intents nicht nichtdeterministisch an alle Broadcast-Receiver aus-geliefert, sondern nach Prioritäten geordnet. Vgl. Kapitel 3.2.3.

Package-NameEin String, der eine App im System eindeutig identifiziert.

PermissionFür bestimmte Aktionen benötigen Apps Permissions. Bei Broadcasts können Permissionsz.B. einschränken, welche Anwendungen Nachrichten an einen Broadcast-Receiver sendenkönnen.

ReferenzmonitorEine Komponente eines Sicherheitssystems, die Zugriffe von Subjekten (Nutzer, Prozesse,...) auf Objekte (Dateien, Geräte, ...) anhand einer Sicherheitsrichtlinie prüft und ggf. zulässtoder verweigert.

96


SAP KapselBei Kapsel handelt es sich um von SAP entwickelte Plugins für Apache Cordova - einerPlattform, die es ermöglicht, Apps mit Technologien wie HTML und JavaScript zu entwickeln[SAPb].

ServiceBeschreibt einen Teil einer Anwendung, der im Hintergrund gestartet wird und dort typi-scherweise längerdauernde Aktionen ausführt oder auf eine Anweisung wartet.

Single-Sign-OnTechnik, bei der eine zentrale Stelle mit einem einzelnen Login dafür sorgt, dass der Userauf mehrere Services zugreifen kann, ohne sich bei jedem Service neu anmelden zu müssen.

Smali-CodeEine assemblerartige Sprache, mit der Android-Bytecode menschenlesbar dargestellt werdenkann.

Sticky BroadcastDiese Art eines Broadcast verbleibt solange im System, bis sie explizit gelöscht wird. Vgl.Kapitel 3.2.2.

Sticky Ordered BroadcastEine Kombination aus Sticky Broadcast und Ordered Broadcast. Vgl. Kapitel 3.2.4.

ToastEine Möglichkeit unter Android, den Nutzer über ein Ereignis zu informieren. Dargestelltwird ein schwarzer Balken am unteren Bildschirmrand mit einer eigens konfigurierbarenNachricht.

Virtuelle MaschineStellt eine virtuelle Hardware- und Betriebssystemplattform bereit, auf der Anwendungengetrennt vom eigentlichen Betriebssystem und der physischen Hardware ausgeführt werdenkönnen.

ZertifikatEin Zertifikat bezeugt die Zuordnung eines Public-Keys (siehe asymmetrisches Kryptover-fahren) zum jeweiligen Besitzer.

97

untersuchung zur broadcastsicherheit von android-appssohr/papers/bachelorthesis...android ist das am...

Documents