Kapitel 7 Sicherheitsarchitekturen Mobiler Endgeräte Fallbeispiele: Android und iphone 7.1 Android Open-Source-Plattform für mobile, Internet-fähige Geräte (Smartphone, Set-Top-Boxes, ) Entwickelt von Open Handset, maßgeblich von Google Erstes Produkt: Android Erstes Release: Android 1.1 Februar 2009 Aktuelles Release: Android 2.2 Mai 2010 Unterstützt GSM, UMTS, Bluetooth, WiFi, GPS, Kompass, Beschleunigungs- und Lagesensoren, Multi-Touch, SD-Karten, Kamera, Juni 2010: 160.000 Android-Mobiltelefone pro Tag ausgeliefert 1
Android-Phone Ein Android besteht aus Applikationen, die vorkonfiguriert sein können als Java-App entwickelt und in VM ausgeführt werden Apps bestehen aus Komponenten Apps interagieren über Komponenten Apps können vom Nutzer direkt installiert werden kein App-Store notwendig Open Access 2
7.1.1 Android-Plattform Java C / C++ Quelle: http://developer.android.com/guide/basics/what-is-android.html 3
Architektur-Komponenten Android-Kernel Modifizierter Linux-Kernel einige Geräte-Treiber, Speicher-, Prozessverwaltung, Kommunikation, Unix UID und Access-Control-Konzepte Android native Libraries in C/C++ C Standardbibliothek: bionic (Eigenentwicklung) Optimiert für mobile Endgeräte (Größe, Geschwindigkeit) Web: Webkit, Datenbank: SQLite Crypto: OpenSSL, BouncyCastle Android-Klassenbibliothek Basiert auf Apache Harmony Keine vollständige J2SE Umgebung 4
Architektur-Komponenten (Forts.) Android-Runtime-Environment besteht aus Dalvik-Virtual-Machine u. Libraries Führt Dalvik-Bytecode aus..dex (dalvic Executable): kompakter und Speicher-effizienter als Java class-files; gut geeignet für ressourcenschwache Geräte Programm-Entwicklung für Android: erfordert ein aktuelles Java-SDK und zusätzlich das Android-SDK Vorgehen: Übersetzen des Java-Quelltexts mit Java-Compiler anpassen mit Cross-Assembler für die Dalvik-VM Jede Java-Entwicklungsumgebung ist nutzbar 5
Isolation von Anwendungen Prozess 1 Prozess 0 (zygote) Prozess 2 App 1 App 2 fork() fork() Dalvik VM 1 Dalvik VM 0 Dalvik VM 2 Binder (IPC) 6
Architektur-Komponenten (Forts.) Android-Application-Framework in Java Jede Anwendung besitzt eigene Unix-UID Sharing erfolgt über Komponenten-basierte Interaktion Komponente: verschiedene Typen: Activity, Service, Content-Provider, Broadcast-Receiver 7
Architektur-Komponenten (Forts.) Android-Application-Framework in Java Die Nutzungsschnittstelle besteht aus Activities: Nutzer können über die gegeben Actvitiy andere Activities starten: direkt oder via Intent Intent: Inter-Component-Kommunikation Starten der UI für eine App Nachrichten-Transport zwischen Komonenten Starten von Background-Diensten Service: Hintergrunddienst ohne grafische Schnittstelle z.b. File-Download, Location-Tracking, Service-Interface zw. Apps: AIDL (Android Interface Definition Language) 8
Architektur-Komponenten (Forts.) Android-Application-Framework in Java Content Provider: bieten anderen Anwendungen Daten an standardisierte Schnittstelle Relationale Datenbanken für Content-Sharing Storage:Eine SQLite-Datenbank pro Anwendung Android-Manifest Technik, um den Inhalt eines App-Package zu spezifizieren jeder App ist eine AndroidManifest.html zugeordnet: beschreibt die Komponenten der App beschreibt Zugriffsregeln beschreibt erforderlichen System-Berechtigungen 9
Beispiel Technische Universität München 10
Überblick über verwendete Sicherheits-Mechanismen 11
7.1.2 Android-Sicherheitsarchitektur Kernel-Security Präventive Maßnahmen: Stack-Protection für Software dlmalloc: Heap-Chunk-Protection gegen Heap-Overflows Fehlende Features u.a.: Kein Adress-Space-Layout-Randomization (ASLR), kein No-Execute-Bit für Stack Sandboxing Eine Linux-User-ID pro Anwendung/Prozess Anwendungen können die gleiche User-ID (shared ID) haben, wenn sie mit dem gleichen Zertifikat signiert wurden 12
Java-Apps werden einer Java-VM (Dalvik-VM) ausgeführt, sehr restriktive Sandbox, Application-Sandbox Nativer C/C++-Code kann zu Dalvik-Prozess geladen werden nicht-type-sicher, anfällig für Angriffe Application Sicherheit Verwendung der Linux-Zugriffskontrolle (UID, GID, rwx-bits) Jede App erhält bei der Installation eine eigene UID Dateien sind standardmäßig nur für den User les- und schreibbar (Zugriffsbits für "world" nicht gesetzt) Feingranulare Privilegien für Apps (und ihrer Komponenten) > 194 verschiedene Zugriffsberechtigungen! 13
Apps müssen global deklarieren, auf welche Komponenten sie welche Zugriffe benötigen: z.b. Internet, GPS, Telefonbuch,..., read, write,.. Bei App-Installation sieht Anwender die angeforderten Rechte zu sehen (oder Signatur) Nutzer kann sie nur komplett gewähren oder ablehnen Eine App erhält keine Rechte, die nicht explizit angefordert wurden. Apps können eigene Rechte definieren, um anderen Apps Zugriff auf ihre Daten und/oder Dienste zu gewähren. 14
Zugriff auf Systemkomponenten (Telefon, GPS, Kamera, Internet, Bluetooth,...): durch GIDs pro Komponente Jedes Gerät erhält eigene GID Eine App erhält Zugriff auf eine Komponente durch Zuordnung zur entsprechenden Gruppe (durch das System) Media-Codecs sehr häufig unsicher und anfällig für diverse Attacken (Overflows, etc.) Eigener Media-Server-Prozess zum dekodieren von Audio/Video-Daten Läuft mit minimalen Rechten: Nur Zugriff auf Display und Soundkarte 15
Zugriffsrechte: Permission-Labels Statische Regeln Permission Labels l1 Component : C1 X Permission Labels l1, l2 Component : C2 : l1 Component : C2 : l2 App 1 App 2 Vier Stufen Normal Keine Rückfrage an den Benutzer Dangerous Rückfrage an den Benutzer Signature Nur für Anwendungen, welche mit dem gleichen Schlüssel signiert wurden SignatureOrSystem - Für Anwendungen, die mit dem gleichen Schlüssel signiert wurden, und für Systemanwendungen 16
Android Market Vergleichbar mit Apple App-Store, jedoch offener Marktplatz kein zentraler Code-Review: http://www.android.com/market/ Community-getriebene "Sicherheit": Benutzer können Anwendungen direkt im Market bewerten Updates der Apps ermöglichen es, z.b. einen Trojaner erst mit einem Update nachzuinstallieren Jede Anwendung muss signiert sein, idr selbst signierte Zertifikate dient der Zuordnung von Entwicklern und Anwendungen auf dem Endgerät (siehe Permissions) 17
7.1.3 Schwachstellen, mögliche Angriffspunkte Statische Permissions Permissions werden nur bei Installation abgefragt (im Gegensatz zu J2ME) Einschränken der Permissions durch den Benutzer ist nicht möglich Problem: Einschleusen von Malware wird erleichtert User-ID-sharing Apps die mit dem gleichen Schlüssel signiert wurden, dürfen mit der gleichen User-ID gestartet werden Apps können ihre Permissions zusammen verwenden Bsp: App A: READ_CONTACTS / App B: INTERNET Problem: Für den Benutzer ist dies nicht ersichtlich 18
Schwachstellen, mögliche Angriffspunkte Technische Universität München Code Execution durch BoF Dalvik verwendet viele native C/C++ - Bibliotheken Anfällig für BoF, Code im Kontext der Dalvik VM ausgeführt werden USB-Debugging-Schnittstelle Kann vom Benutzer aktiviert/deaktiviert werden Installieren von Apps ohne Bestätigung der Permissions Zugriff auf die Shell und Logdaten Intent-Sniffing / -Fuzzing Mithören der Inter-Prozess-Kommunikation Fuzzing von Intents 19
Privacy-Probleme durch Google? Synchronisation der Daten mit diversen Google-Diensten standardmäßig aktiviert, falls Google-Account eingerichtet (lässt sich alles deaktivieren, opt-out): Standort (GPS/GSM-Funkzelle): Google-Suche Standort für Google-Maps, Adressbuch, Kalender Weitere Google-Dienste bzw. Synchronisationen können optional aktiviert werden (opt-in): RSS-Feeds mit Google Reader Verlauf der Google-Suche synchronisieren Google Latitude (Aufenthaltsort für Freunde sichtbar) Google Buzz (ortsbasierte Kurznachrichten) 20
Fazit: in Standardkonfiguration ist der Kernel relativ gut geschützt, ein Austausch des Kernels erfordert Hardware-Manipulationen Über Schwachstellen in Kern-Komponenten, die mit Root- Privilegien und grob-granularen Zugriffsrechten laufen, kann ein Angreifer vollständige Kontrolle über das Gerät erhalten Die Vergabe von Privilegien ist komplex und fehleranfällig, Rechte können ohne Nutzerfreigabe vergeben werden Nutzer kann nicht kontrollieren, ob Apps ihre Rechte korrekt verwenden Sharing von IDs und Rechten ist transparent für Nutzer Open-Source-Web-Engine ist sehr anfällig: Injection etc. 21
Anmerkung: Fragwürdige Offenheit: Google behält per AGB die Gewalt über die Apps und den Marktplatz: Wenn Google ein Produkt entdeckt, das die Marktplatz Nutzungsbedingungen für den Entwicklervertrieb oder anwendbare Gesetze verletzt, hat Google das Recht, nach eigenem Ermessen ein solches Produkt durch Fernzugriff von Ihrem Gerät zu entfernen, wenn das Produkt Ihnen, Ihrem Gerät oder einem beteiligten Teleko-Unternehmen einen ernsthaften Schaden zuzufügen geeignet ist. Quelle: http://www.google.com/intl/de_at/mobile/android/market-policies.html Fakt: Es existiert ein Kill-Bit zum Remote-Löschen von Apps! http://www.heise.de/security/meldung/google-loescht-android-app-auf-smartphones-aus-der-ferne-update-1028907.html 22
Qualitative Sicherheitsanalyse 23
24
Einige Referenzen und Links zu Android: A. Shabtai et. al.: Google Android: A State-of-the-Art Review of Security Mechanisms http://arxiv.org/abs/0912.5101 W. Enck, M. Ongtang, P. McDaniel: Understanding Android Security, IEEE Security & Privacy, S. 50-57, Januar 2009 http://www.computer.org/portal/web/computingnow/0209/whatsnew/securityandprivacy http://developer.android.com/guide/topics/security/security.html http://siis.cse.psu.edu/slides/android-sec-tutorial.pdf 25