Besser lernen dank der zahlreichen Ressourcen auf Docsity
Heimse Punkte ein, indem du anderen Studierenden hilfst oder erwirb Punkte mit einem Premium-Abo
Prüfungen vorbereiten
Besser lernen dank der zahlreichen Ressourcen auf Docsity
Download-Punkte bekommen.
Heimse Punkte ein, indem du anderen Studierenden hilfst oder erwirb Punkte mit einem Premium-Abo
Es basiert auf dem Linux-Kernel und übernimmt somit auch dessen, hauptsächlich von UNIX stammenden, Sicherheits- und. Rechtemodelle. Mit Dalvik gibt es auf ...
Art: Skripte
1 / 64
Diese Seite wird in der Vorschau nicht angezeigt
Lass dir nichts Wichtiges entgehen!
Fakultät Technik und Informatik Studiendepartment Informatik
Faculty of Engineering and Computer Science Department of Computer Science
Bachelorarbeit eingereicht im Rahmen der Bachelorprüfung
im Studiengang Bachelor of Science Angewandte Informatik am Department Informatik der Fakultät Technik und Informatik der Hochschule für Angewandte Wissenschaften Hamburg
Betreuender Prüfer: Prof. Dr. rer. nat. habil. Dirk Westhoff Zweitgutachter: Prof. Dr. Thomas C. Schmidt
Eingereicht am: 28. August 2012
Tabellenverzeichnis vi
Abbildungsverzeichnis vi
5.1. Szenario A: Apps, deren Komponenten und deren Interaktion untereinander 43 5.2. Szenario B: Apps, deren Komponenten und deren Interaktion untereinander 44 5.3. Szenario A: Zustandsschnappschüsse................... 46 5.4. Szenario B: Zustandsschnappschüsse................... 47
Quellcodeverzeichnis
4.1. Schnittstellendefinition von FlowGraph in AIDL.............. 30
vii
1. Einleitung 1. Einleitung
Das Android Betriebsystem erfreut sich seit Jahren steigender Beliebtheit, insbeson- dere auf Mobiltelefonen. Auch in anderen Bereichen, wie zum Beispiel Tablets oder SetTop-Boxen (Google TV) erhält es langsam Einzug. Jeder kann sich für eine kleine Gebühr bei Google Inc. registrieren und danach Apps in Google Play^1 einstellen, ohne dass diese weder eine manuelle noch automatische Prüfung durchgehen. Dies stellt eine besondere Gefahr für den Nutzer dar, da sich einfach bösartige Apps in Google Play einstellen lassen, die vielen Millionen Nutzern sofort zur Verfügung stehen. Beispiele hierfür sind Malware welche Telefonnummern ausspäht Cluley [2010] und ein Proof-of-Concept der BBC Ward [2010], welcher sich als Spiel tarnt um private Daten auszuspähen. Nutzer sind es gewohnt, mit ein paar Klicks, einfach Anwendungen aus Google Play auf ihrem Gerät zu installieren und diese danach zu verwenden. Bevor Apps aus dem Google Play installiert werden, muss der Benutzer hingegen der Installation noch einmal zustimmen, wo ihm die erlaubten Rechte der zu installierenden App in einer Übersicht angezeigt werden.
Jedoch ist zu beachten, dass ein Großteil der Nutzer die Übersicht der Rechte vor der Installation nicht beachtet oder die Beschreibung der Rechte nicht versteht. In einer Studie [Felt et al., 2012, S. 11] war mehr als die Hälfte der Nutzer nicht bewusst, dass Ihnen die genauen Rechte, die eine Anwendung benötigt, aufgelistet wurden. Aus diesem Grund müssen zusätzliche Maßnahmen getroffen werden, um Nutzer und deren Privatsphäre vor potentiellen Gefahren zu schützen.
(^1) ehemals Android Market
1. Einleitung
Zur einfachen Kommunikation zwischen Apps untereinander und zu Systemdiensten dient das Binder Framework. Es besteht aus einer Kernel-Erweiterung und Schnittstellen im Android SDK und bietet App-Entwicklern RPC-Funktionalitäten ähnlich CORBA oder Java RMI. Ein Großteil der Schnittstellen im Android SDK basiert auf Binder. [Schreiber, 2011, S. 16]
Ziel dieser Arbeit ist es, auf Basis von Interprozesskommunikation entstandene, Rech- teausweitung auf Android-Systemen zu erkennen. Die Arbeit konzentriert sich vor allem auf die Fälle von Rechteausweitung, die den ungewollten Zugriff auf sensitive Daten, wie Kontaktdaten oder Geoposition, ermöglichen. Des Weiteren soll die hier entwickelte Android-Erweiterung die Entwicklung von End- nutzerapplikationen nicht beeinträchtigen. Durch die vollständige Implementierung auf System- und Application-Framework-Ebene müssen bestehende Apps nicht angepasst werden, um von den hier entwickelten Sicherheitsmechanismen zu pro fitieren. Somit lassen sich weiterhin Apps aus dem von der of fi ziellen Handelsplattform Google Play installieren und nur Apps die zur Laufzeit Rechteausweitung unternehmen könnten in ihrer Funktionalität beeinträchtigt werden. Hierfür wird geprüft, ob auf Basis von der Analyse von Informationsfl üssen, insbeson- dere das Weiterreichen von sensitiven Daten, mögliche Rechteausweitung zuverlässig erkannt werden. Das liefert die Grundlage für eine Unterbindung dieser Rechteauswei- tung.
Die Arbeit befasst sich Hauptsächlich mit Rechteausweitung auf Anwendungsebene und besonders dem Kommunikationssystem auf dieser Ebene. Diese kann absichtlich durch bösartige Apps entstehen und durch Programmfehler im Application-Framework oder der Apps. Rechteausweitung auf Ebene des Systemkerns, meist ausnutzbar durch Programm- fehler im Kernelcode, wird von dieser Arbeit nicht im Detail betrachtet. Es hat sich gezeigt, dass besehende Lösungen wie SELinux^2 oder auch TOMOYO Linux [Harada et al.,
(^2) https://www.nsa.gov/research/selinux/index.shtml
1. Einleitung
2004] das Problem dieser Form der Rechteausweitung stark begrenzen können [Bugiel et al., 2011, S. 2]. Darüber hinaus wird davon ausgegangen, dass das Android-System, vor allem der Systemkern, Standarddienste und das Applikations Framework, inklusive der hier entwickelten Erweiterung, sicher und unverändert auf dem System laufen. Eine Modifi zierung von diesen Komponenten gefährdet die zuverlässige Funktionsweise der Erweiterung. Diese Absicherung kann zum Beispiel durch Secure Boot erfolgen. Es erlaubt einem ein Androidsystem vertrauenswürdig zu starten und auszuführen. Unter Nutzung eines Hardware-Kryptographiemoduls und kryptographischen Signaturen von festen Bestand- teilen des Systems kann man somit sicherstellen, dass diese Bestandteile seit dem Zeitpunkt der Signierung nicht verändert wurden. Durch die Signierung und konsequente Überprüfung von Bootloader, Kernel, Dalvik VM und weiteren sicherheitsrelevanten Teilen des Systems kann sichergestellt werden, dass die hier umgesetzten Modi fi kationen, welche der Erkennung von Rechteausweitung dienen, nicht ausgehebelt werden. Da die Möglichkeiten, die eigentliche Rechteausweitung zu unterbinden oder ander- weitige Gegenmaßnahmen einzuleiten, sehr vielseitig sind, stellen diese ein einzelnes Forschungsthema dar. Daher ist die Analyse und Konzeption möglicher Gegenmaßnah- men nicht Gegenstand dieser Arbeit.
In Kapitel 2 werden zuerst die grundlegenden Hintergrundinformation zum Thema Android, Prozesse auf dem System und die Kommunikation unter ihnen, erläutert. Ferner wird hier auch auf die Sicherheitsmechanismen von Android und Rechteausweitung eingegangen. Kapitel 3 beschreibt bisherige Ansätze aus der Forschung, die sich zum Ziel gesetzt haben die Sicherheit auf der Android-Plattform zu verbessern und vor allem mögliche Rechteausweitungen einzuschränken. Darauf folgend wird das eigene Design auf Basis von dynamischer Darstellung von Informationsflüssen vorgestellt. Kapitel 4 befasst sich mit den Implementationsdetails von TaintDroid und der Umset- zung der Android-Erweiterung, die das zuvor beschriebene Konzept der Darstellung von Informationsflüssen umsetzt. Ausserdem werden hier Hilfsprogramme vorgestellt, welche zur Visualisierung des jeweils aktuellen Systemzustands dienen.
2. Grundlagen 2. Grundlagen
Das Android Betriebsystem lässt sich in 4 Ebenen einteilen.
Abbildung 2.1.: Android System Architektur, (Quelle: [Google])
Auf unterster Ebene be findet sich der Betriebssystemkern, ein auf Linux basierender Kernel, der mit, für das Android System spezi fi schen Erweiterungen ergänzt wurde. Zu diesen Erweiterungen zählt unter anderem Binder, eine neue Schnittstelle zur In-
terprozesskommunikation (IPC), die flexible Kommunikation zwischen den laufenden Prozessen anbietet. Daneben gibt es noch Erweiterungen wie ashmem, für das einfa- chere Handhaben von geteiltem Speicher zwischen Prozessen. Android ist keine Linux-Distribution im klassischen Sinne. Es unterstützt weder das sonst gängige X-Window-System als graphische Benutzeroberfläche, noch sind stan- dardmäßig die üblichen GNU Bibliotheken vorhanden. Native Bibliotheken wie z.B. Datenbanken, Web-Rendering oder auch OpenGL ordnen sich in der mittleren Ebene ein. Die Middleware von Binder befindet sich auch auf dieser Ebene. Binder ist mit bekannten RPC Umsetzungen wie CORBA oder auch Java RMI vergleichbar. Der wesentliche Unterschied ist, das Binder nicht Netzwerktransparent ist. Es wurde nur für Interprozesskommunikation innerhalb eines Systems und nicht über Netzwerkgrenzen hinaus entwickelt. Ausserdem ist hier auch Dalvik einzuordnen. Dalvik ist eine register-basierte VM, die sich an der ARM-Architektur orientiert. Sie ist optimiert für ressourcenschwache Geräte, da Android hauptsächlich für den Embedded-Bereich wie Smartphones oder auch Tablets ausgelegt ist. [Nicola Carlo, 2009] Auf der oberen Ebene ist der Großteil des Android Applikation Frameworks angesie- delt, gegen das die Entwickler von Benutzeranwendungen programmiert. Diese Apps befinden sich auf der obersten Ebene.
Der Aufbau von Apps, d.h. Endnutzeranwendungen, auf der Android-Plattform unter- scheidet sich grundlegend von dem, auf üblichen Desktop-Systemen. Bei gängigen Unix-Anwendung hat man nur einen Einstiegspunkt in die Anwendung, üblicherweise die main() -Funktion. Eine Android App hingegen kann aus mehreren high-level Kompo- nenten bestehen, von denen jede einem möglich Einstiegspunkt in die App entspricht. [Mednieks et al., 2011, S. 75f.] Der Aufbau jeder App wird in ihrer Manifest-Datei beschrieben. Die Manifest-Datei hat ein XML-basiertes Format, wodrin die einzelnen Komponenten aufgeführt sind und welche Aktionen mit der Anwendung an welche Komponente weitergeleitet werden. Ausserdem beschreibt die Manifest-Datei die benötigten Berechtigungen der App. Die möglichen Komponenten einer App werden im Folgenden genauer erläutert.
2. Grundlagen
Beispiele für ContentProvider, welche mit Android standardmäßig mitgeliefert werden, sind unter anderem die ContentProvider für Kalender, Anru fl isten oder auch Musik. [Mednieks et al., 2011, S. 79f.]
2.1.2.4. BroadcastReceiver
BroadcastReceiver-Komponenten fungieren als Empfänger von high-level IPC Nach- richten, den Intents. Gesendete Intents können von mehr als einem BroadcastReceiver empfangen werden. Anwendungsentwickler können für jeden BroadcastReceiver Fil- ter in der Manifest-Datei hinterlegen, sodass der BroadcastReceiver nur für vorher bestimmte Ereignisse aufgerufen wird. Ein Beispiel für Ereignisse, die mittels Broadcast-Intent verteilt werden, ist der Emp- fang einer SMS. [Mednieks et al., 2011, S. 82]
Auf einem Android-System hat man mit verschiedenen Rechtemodellen auf den ver- schiedenen Ebenen des Systems zu tun. Auf der untersten Ebene gibt es, wie unter Linux üblich, auf UIDs und GIDs basierende Datei- und Ausführungsrechte. Diese werden durch den Betriebssystemkern durchgesetzt. Die Endbenutzer-Anwendungen laufen alle als dedizierten Prozesse. Bei der Installation einer neuen App wird Ihr vom System eine feste UID zugewiesen unter der diese im System ausgeführt wird. Die UID ist Entwicklerspezifi sch, das heisst alle Anwendung des gleichen Entwicklers (durch den selben Entwicklerschlüssel signiert), laufen unter der selben UID. Darüber hinaus gibt es auf weiter oberen Ebenen Android spezi fische Berechtigungen ( Permissions ). In Android 2.2 gibt es 134 Permission , welche sich in 3 Kategorien [Felt et al., 2011a, S. 2] einteilen lassen:
2. Grundlagen
Für Endnutzeranwendungen stehen dem Nutzer von Android unterschiedliche Quel- len zur Verfügung. Die meistgenutzte Quelle ist die standardmäßig installierte App Google Play. Anders als beim Apple AppStore, wo die von Entwicklern eingereichten Anwendungen vom Betreiber der Verkaufsplattform veri fi ziert und getestet werden, werden bei Google Play die eingereichten Apps direkt den Endnutzer bereitgestellt. Um mögliche Gefahren für die Privatsphäre und Sicherheit der Nutzer von Android zu Beschränken, muss der Nutzer vor der endgültigen Installation einer App diesen Installationswunsch in einem Dialog explizit bestätigen. In diesem Dialog werden dem Nutzer die Berechtigungen, inklusive kurzer Erläuterungen zu denen, welche die App benötigt aufgezeigt. Hier hat der Nutzer die letzte Möglichkeit über die Installation zu entscheiden und muss zwischen Funktionalität und Sicherheit abwägen. Damit hat Google die Frage der Sicherheit und Privatsphäre des Nutzers an den Nutzer selbst weitergeleitet, welche jedoch meist die einzelnen Berechtigungen nicht verstehen oder den Dialog ganz ignorieren. [Felt et al., 2012] Ein Großteil der Permissions wird innerhalb des Systemprozesses von Android im- plementiert, wo sich die Implementation der meisten Dienste be fi ndet. Nur ein paar Permissions, welche sich einfach zu Funktionen des Systemkerns zuweisen lassen, werden mit Hilfe von Unix-Gruppen und Zugriffskontrolle dieser auf Systemkernebene erzwungen. Zu diesen Ausnahmen zählen unter anderem Bluetooth- und Internetzugriff. [Felt et al., 2011a, S. 3]
Auf einem Android-System verhalten sich die Apps und System-Dienste wie in einem verteilten System. Aus Sicherheitsgründen läuft jede Anwendung in ihrer eigenen Instanz der DVM, welche als limitier Prozess direkt auf dem OS läuft. Da diese Prozesse nur Zugriff auf die eigenen Daten haben, stellen sie eine Sandbox dar. Um dennoch einen hohen Grad an Wiederverwendbarkeit der Komponenten zu ermöglichen, ist man auf Kommunikation zwischen den Diensten und Apps angewiesen. Abbildung 2.2 gibt eine Übersicht über die Möglichkeiten der Kommunikation die einer Android-App zur Verfügung stehen. Der of fizielle Weg unter Android eine Kommunikation zwischen Anwendungen herzu- stellen sind Intents oder RPC-Aufrufe mittels Binder.
2. Grundlagen
lehnten Sprache de fi niert werden. Auf Basis dieser Beschreibung generiert das Android SDK dann die passenden Proxy- und Stub-Klassen. [Schreiber, 2011, S. 17-18]
2.1.4.3. Intents
Intents sind stark abstrahierte Nachrichten die Entwicklern vorrangig als Java-API zur Verfügung stehen und erlauben eine sehr hochrangige Art der Kommunikation zwischen Komponenten des Systems. Speziell werden sie hauptsächlich zum Starten von neuen Activities oder zur Kommunikation zwischen Activities verwendet. Ein Intent beinhaltet eine Aktion die auszuführen ist, z.B. einen Telefonanruf auszuführen, und optional zusätzliche Daten, z.B. welche Nummer anzurufen ist. Ein Intent ist entweder explizit, d.h. an eine vorde finierte Komponente gerichtet, oder implizit. Bei impliziten Intents bestimmt das System an welche Komponenten es ausge- liefert wird. [Schreiber, 2011, S. 16] Eine besondere Form von Intents auf der Android-Plattform sind die Broadcast Intents. Diese können von mehr als eine App empfangen werden und werden oft zu Benach- richtigung von Apps und Systemkomponenten über besondere Ereignisse im System verwendet. Installation von neuen Apps aber auch ein niedriger Batteriestand zählen zu derartigen Ereignissen.
2.1.4.4. Queries/Cursor
ContentProvider stellen eine wichtige Komponente innerhalb von Android dar und sind essentiell zur Umsetzung eines Model-View-Controller (MVC) Stils unter Android [Mednieks et al., 2011, S. 81]. Abfragen werden mittels query() -Methode ausgeführt und auf die jeweiligen Ergebnismengen kann mit Hilfe eines Cursor-Objekts iteriert werden. Die von ContentProvidern angebotenen Aktionen umfassen das Erstellen neuer, das Entfernen oder Ändern bestehender Einträge und die fl exible Abfrage von Einträgen [Mednieks et al., 2011, S. 306f.]. Der eigentliche Zugriff auf die Aktionen der ContentProvider wird über die im vorheri- gen Abschnitt 2.1.4.2 beschriebe RPC-Funktionalität geregelt.
2. Grundlagen
Unter Rechteausweitung versteht man die Erweiterung der Rechte einer Komponente über die, vorher für dieser Komponente, de fi nierten Rechte hinaus. Es gibt verschiedene Möglichkeiten für Komponenten ihre Rechte zu erweitern. Rechteausweitung lässt sich in zwei Arten aufteilen:
Vertikale Rechteausweitung Hierbei kann eine Anwendung oder Benutzer durch Bugs oder Designfehler Funktionen höherer Ebene ausführen, für die normalerweise mehr Rechte von Nöten wären.
Horizontale Rechteausweitung Diese Art von Rechteausweitung tritt ein, wenn An- wendungen oder Benutzer auf gleicher Ebene auf Funktionen und Daten anderer Anwendungen oder Nutzer auf dieser Ebene zuzugreifen können.
Ein Prozess kann Fehler im Betriebssystemkern ausnutzen um beliebige Instruktio- nen mit Systemrechten auszuführen und damit die Rechte des eigenen Prozesses verändern. Derartige Angriffe fi nden vertikal, über mehrere Systemeben hinweg, statt und können durch SELinux eingeschränkt werden.
Die Apps auf einem Andorid-System laufen in ihren eigenen Sandboxen, welche auf Systemkern-Ebene durch individuelle UIDs von anderen Apps und dem System selbst getrennt sind. Somit ist das System vor bösartigen oder fehlerhaften Anwendungen geschützt. Ausserdem sind die Apps gegen andere Apps geschützt, da jede App nur Direktzugriff auf die eigenen Daten innerhalb ihrer Sandbox hat. Um in einem System, wo jede App für sich gekapselt ist, dennoch Kollaboration mit anderen Komponenten zu ermöglichen gibt es Kommunikationsmöglichkeiten zwischen den Apps. Ohne diese wären die Möglichkeiten der Entwicklung von brauchbarer Software auf dieser Art von Systemen sehr beschränkt. Allerdings sind es genau diese Kommunikationsmöglichkeiten zwischen den Apps, die eine Schwäche für die Sicherheit des Systems und damit auch der Privatsphäre des Nutzers darstellen. Die Schwäche liegt darin, dass die Kommunikation zwischen verschiedenen Komponenten unkontrolliert verläuft und somit eine horizontale Rech- teausweitung begünstigen kann. Dabei unterscheidet man zwischen confused-deputy Angriffen und Angriffen von konspirierenden Komponenten. Confused-deputy Angriffe werden gerade dann ermöglicht, wenn die Entwickler von
