Schwachstellenanalyse & Reverse Engineering von Android Apps

Inhaltsverzeichnis

Einleitung
Voraussetzungen
Apps herunterladen
Testumgebung einrichten
Android Development Umgebung
Alternativer Emulator
Santoku

Schwachstellen in Android Apps
Intent Spoofing
Unauthorized Intent Receipt
Information Leakage
Backdoor
SSL
DOS
Weitere Schwachstellen
SQL, JavaScript & XML Injection
Fragment Injection
OWASP Mobile Top 10 Risks

Manuelle Analyse
Betrachtung der Manifest-Datei
App Konfiguration herausfinden
Ressourcen untersuchen

Statische Analyse
Grundlagen der Dekompilierung
Manuelle Dekompilierung von Dex-Bytecode
Dekompilierung von Dex zu Java
Prüfung von verdächtigen Konstanten
Dekompilierung von Dex zu Smali
Dekompilierung von Dex zu Jimple
Datenfluss Analyse mit FlowDroid
Optimierung von FlowDroid

Dynamische Analyse
Laufzeit injection mit Drozer
Schwachstellentests
Überwachung von Apps mit Logcat
Netzwerküberwachung

Anhang: VBS Script FindString.vbs & FindAndroidKonst.vbs

Anhang: „isSessionValid“ Methode

Benutzerdefiniertes Verzeichnis

App Downloader Icon

Install

ADT installieren 2

ADT installieren 3

Emulator per Konsole starten

Android Debug Monitor

Installieren von Apps im Emulator

Verfügbare Geräte

Santoku

GoatDroid Konfiguration

GoatDroid App auf virtuellem Device

Mitschneiden von Nachrichten

SQLite Datenbank in GoatDroid

Öffnen von Userinfo.db

Datenbankfelder

Http Session mit geklauter Session ID

URLs in GoatDroid

DOS Angriff auf GoatDroid

Fenster zur Eingabe eines neuen PINs

Apktool Reversing

Der Kompiliervorgang in Java

JVM

Beispiel einer Class Datei

Class Datei im Hex-Editor

Umwandlung von class zu dex

Vergleich von „*.jar“ und „*.dex“ Formaten

Hex Code von der Beispiel App

Apk zu Java

Unterschiede Dekompiler

Smali Ordnerstruktur

Syntax Highlight für Smali

Soot Projekt

Runnable JAR File

Dekompilierung mit Soot

GUI für FlowDroid

Drozer Server starten

Virtuelles Gerät mit Android API 4.0.3

Screen Lock

Schwachstellentest

Logcat GUI

Netzwerküberwachung mit Whireshark

Http Überwachung mit Fiddler2

Fiddler2 Options

Kurzfassung

Diese Arbeit beschäftigt sich mit dem Auffinden von SchwachsteUen in Android Apps. Der Leser dieser Arbeit soll in die Lage versetzt werden, die Sicherheit einer App beurteilen zu können. Damit richtet sich diese Arbeit vorrangig an Android Administratoren und Entwickler. Die beschriebenen Techniken sollten nur aus Eigenentwicklungen angewandt werden.

Die Arbeit gliedert sich in vier logische Abschnitte. Am Anfang stehen Informationen zum Umgang mit Android und dem Google Play Store. Diese Informationen sind Grundlagen, welche wichtigfür alle nachfolgenden Themen sind. Danach werden einige Schwachstellen, die häufig in Android Apps Vorkommen, aufgezeigt und am praktischen Beispiel erläutert. Die letzten zwei Abschnitte stellen den Kern dieser Arbeit da, indem sie beschreiben, wie solche Schwachstellen gefunden werden können. In Abschnitt drei wirdprinzipiell gezeigt, wie eine App aufgebaut ist und wie Quelltext aus einer App gewonnen wird. Der letzte Teil der Arbeit geht auf konkrete Analysetechniken ein.

Insgesamt wird so der aktuelle Stand der Technikfür Sicherheitsanalyse von Android beschrieben.

Einleitung

Voraussetzungen

Aufgrund der Komplexität der Thematik sind zum Verständnis dieses Dokumentes einige Vorkenntnisse von Vorteil. Zum einen sollten Erfahrungen im Umgang mit Java und Android App Entwicklung vorhanden sein. Zum anderen wird das Wissen um grundlegende Funktionen, wie zum Beispiel das Herunterladen von Projekten aus einem Git Repository vorausgesetzt.

Apps herunterladen

Im folgenden sollen Android Apps analysiert werden. Dabei stellt sich als erstes die Frage, wie man an eine bestimmte App gelangt. Eine App wird mit ihren Komponenten in eine Datei mit der Endung „*.apk“ gepackt. Dies ist nur ein Archiv - ähnlich wie bei Java Jar-Dateien, welche mit üblichen Programmen entpackt werden können. Die Apk-Dateien der Apps können direkt aus dem Google Play Store oder nach der Installation vom Gerät geladen werden. Ein Tool, das diesen Vorgang unterstützt, ist der Apk-Downloader. Dies ist ein Plugin für den Chrome Browser, welches eine App aus dem Google Play Store direkt auf den PC laden kann. Aktuell bietet der Apk- Downloader auch eine des Plugins an, welche allerdings nur eingeschränkt funktioniert¹. Das Plugin ist auf derselben WebSite verfügbar.

Nach der Installation macht sich das Plugin in der URL-Leiste bemerkbar. Ist man auf der Site einer Google Play App, kann diese durch das unten dargestellte Icon geladen werden.

Abbildung in dieser Leseprobe nicht enthalten

App Downloader Icon

Beim ersten Benutzen des Plugins fragt dieses nach einer gültigen Geräte ID. Diese lässt sich herausfinden, indem man folgende Nummer wählt: *#*#8255#*#* (*#*#TALK#*#*)

Achtung: die Geräte ID ist nicht die gleiche wie die IMEI.

Testumgebung einrichten

Bevor man die Android Apps analysieren kann, muss man eine geeignete Umgebung schaffen. Die Grundlage für alle Apps und folgenden Tools sind die Android Development Tools(ADT). Meist werden diese zusammen mit Eclipse verwendet, da Google ein entsprechendes Eclipse Plugin zum Download anbietet. Im Folgenden wird erläutert, welche Komponenten für die Testumgebung gebraucht werden. Als Basissystem wird hier Windows gewählt. Wer Linux nutzen will, kann direkt zum Punkt Santoku springen. Dies ist ein fertiges Linux basiertes System mit vielen Tools, die zur Analyse von Android notwendig sind.

Android Development Umgebung

Um das Android Development Toolkit nutzen zu können, muss das Java Development Kit installiert werden. Dieses kann wie üblich auf der WebSite von Oracle heruntergeladen und installiert werden². Wenn dies abgeschlossen ist, wird die Entwicklungsumgebung Eclipse benötigt. Diese gibt es in verschiedenen Versionen. In diesem Fall reicht es aus, die Standardversion „IDE for Java EE Developers“ herunterzuladen³.

Ist dies geschehen, dann kann das Android Development Toolkit Plugin installiert werden. Dazu muss in Eclipse unter dem Menüpunkt „Hilfe“ die Funktion „Install New Software“ ausgeführt werden.

Abbildung in dieser Leseprobe nicht enthalten

Install

In der darauffolgenden Ansicht muss nun der Download-Link⁴ eingetragen und mit OK bestätigt werden. Danach kann das ADT Plugin direkt in Eclipse installiert werden. Die Entwicklungsumgebung verfügt nun über die Fähigkeit, neben normalen Java-Programmen auch Android Apps zu erstellen.

Abbildung in dieser Leseprobe nicht enthalten

ADT installieren 2

Als nächstes kannjetzt das Android Software Development Kit integriert werden. Dafür muss dieses heruntergeladen und installiert werden⁵. Um die Installation zu vervollständigen, können danach unter dem Menü Punkt ,,Window->Android SDK Manager“ die SDK Tools hinzugefügt werden.

Abbildung in dieser Leseprobe nicht enthalten

ADT installieren 3

Neben den SDK Tools stellt der Android SDK Manager auch verschiedene Versionen der API zum Download bereit. In späteren Kapiteln, wo es um das Dekompilieren von Apps geht, kann es zu Fehler kommen wenn nicht die richtige SDK Version verfügbar ist. In diesem Fall kann die richtige Version über den SDK Manager nachgeladen werden.

Nun sind alle Basiskomponenten, die für die Erstellung und Analyse von Android Apps notwendig sind, installiert. Wenn alles richtig gelaufen ist, sollte sichjetzt der Android Emulator starten lassen. Dazu kann folgender Befehl verwendet werden:

Abbildung in dieser Leseprobe nicht enthalten

Emulator per Konsole starten

Zuerst wird mit dem Befehl „android list tagets“angezeigt, welche Geräte vorhanden sind. Dann kann eines der Geräte anhand der „id“ ausgewählt und gespeichert werden. Mit Hilfe dem Namen des Profils lässt sich im nächsten Schritt auf das zuvor erstellte Profil zugreifen. Ein weiteres Tool, das sich im gleichen Ordner befindet, ist das Dalvik Debug Monitor Server(ddms)⁶ Tool. Über dieses Tool ist es möglich, sich mit der Android Version auf dem Emulator zu verbinden. Dies geschieht über die Debugging Brücke. Nach dem Verbinden zeigt ddms zum Beispiel alle auf dem Emulator laufenden Prozesse an. Anhand dieser Informationen ist es auch möglich, den Prozesse einer App im Emulator zu debuggen, was in späteren Kapiteln näher erläutert wird.

Abbildung in dieser Leseprobe nicht enthalten⁷

AlternativerEmulator

Neben dem Emulator von Google gibt es noch weitere Programme zum emulieren von Android, welche sich durch unterschiedliche Vorteile auszeichnen. Einer ist zum Beispiel der Genymotion Emulator, welcher aus dem AndroVM Projekt hervorgegangen ist. Das Installationsprogramm kann auf der Homepage von Genymotion heruntergeladen werden⁸. Die Grundlage des Emulator ist VirtualBox, somit bringt der Emulator neben einer besseren Performance auch noch die Vorteile von VirtualBox mit sich. Dazu zählt zum Beispiel, dass einfache Erstellen von Snapshots. Auch bei dieser VM ist es möglich über die Debug-Schnittstelle auf Android zuzugreifen.

Nach der Installation müssen als erstes die möglichen virtuellen Geräte aus dem Internet heruntergeladen werden.

Abbildung in dieser Leseprobe nicht enthalten

Cancel

Verfügbare Geräte

Danach muss eines ausgewählt werden um die VM zu starten.

Santoku

Santoku ist eine Linux Distribution, welche auf die Sicherheitsanalyse von Android zugeschnitten ist. Basierend auf Ubuntu bringt die Distribution eine Vielzahl verschiedener Tools mit. Tools auf dem „Reverse Engineering“ Umfeld⁹:

- -Androguard
- -Antilvl
- -APK Tool
- -Baksmali
- -Dex2Jar
- -Jasmin
- -JD-GUI
- -Mercury
- -Radare2
- -Smali

Bereitgestellt wird die Distribution als ISO Datei auf der Santoku WebSite¹⁰. Dank dem ISO Dateiformat kann die Installation bei Bedarf auch in einer virtuellen Maschine erfolgen. Beim Installationsvorgang gibt es wenig zu beachten. Allerdings sollten nach der Installation ein Update der wichtigsten Komponenten erfolgen. Auch andere Tools die sehr oft zum Einsatz kommen wie

Git oder das Java Development Kit müssen noch manuell installiert werden. Danach kann die Analyse von Android beginnen.

Abbildung in dieser Leseprobe nicht enthalten

Santoku

Schwachstellen in Android Apps

Android kann zwei Arten von Apps anbieten, zum einen die Native App und zum anderen die Web App. Beide Arten haben Vor- und Nachteile. Die Native App ist vergleichbar mit einem Java Programm, kann aber auch C Komponenten enthalten. Injedem Fall muss diese Art von App auf dem Gerät vollständig installiert werden und ist somit auch offline verfügbar. Braucht der Entwickler uneingeschränkten Zugriff auf die Funktionen des Gerätes, sollte er eine Native App implementieren. Dem gegenüber steht die Web App, welches mit einer WebSite zu vergleichen ist. Bei der Installation wird nur der Schnellstarter hinterlegt und die App ist somit nicht offline fähig. Auch hat die Web App nur eingeschränkte Möglichkeiten im System. Der Vorteil hierbei ist, dass die App auf allen mobilen Betriebssystem gleichermaßen lauffähig ist. Will der Entwickler sich nicht für eine Art entscheiden, kann er auch beide Arten verbinden zu einer hybriden App. Für die folgenden Analysen interessant sind die Nativen und hybriden Apps, da bei den Web Apps die klassischen Verfahren zur Analyse von WebSites verwendet werden können.

Bevor die eigentliche Analyse einer App betrachtet wird, werden verschiedene Schwachstellen von Android Apps erläutert. Kennt man die häufigsten Schwachstellen von Android Apps, kann man gezielt nach solchen Fehler suchen. Deswegen geht es im folgenden darum die typischen Fehler kennen zu lernen, dass verbessern der Fehler ist kein Schwerpunkt dieser Arbeit. Für die folgenden Beispiele wird die Testumgebung von dem Open Web Application Security Project(OWASP) verwendet. Die Testumgebung besteht aus einer Java Anwendung, über die man einen WebServer, Apps und die Android Emulatoren steuern kann. Die Apps sind speziell für das Erlernen typischer Fehler konzipiert. Deswegen eignen sie sich sehr gut für die folgende Betrachtung von kritischen Fehlern. Speziell wird im folgenden die App „GoatDroid“ näher betrachtet. Die Testumgebung(GoatDroid) kann auf der OWASP Homepage¹¹ heruntergeladen werden. Nach dem Herunterladen von GoatDroid kann man „goatdroid-0.9.jar“ starten. Dazu kann folgender Befehl verwendet werden:

Abbildung in dieser Leseprobe nicht enthalten

GoatDroid Starten

Bevor der Emulator gestartet werden kann, muss die richtige Konfiguration hinterlegt werden. Wichtig sind dabei die beiden Felder „Virtual Device Path“ und „SDK Path“. Das erste Feld verweist dabei auf den Ordner indem die erstellten Profile der virtuellen Geräte liegen. Dieser befindet sich meist im Benutzerverzeichnis. Dabei sollte mindestens ein Profil die Version 4.4 oder höher von Android unterstützen. Im zweiten Feld muss der Pfad zur Android SDK hinterlegt werden.

Abbildung in dieser Leseprobe nicht enthalten

GoatDroid Konfiguration

Nach der Konfiguration muss die „GoatDroid“ App ausgewählt werden sowie der Server und der Emulator gestartet werden. Wenn der Emulator hochgefahren ist, kann die App installiert werden. Wenn alles richtig gelaufen ist, kann danach die App auf dem virtuellen Device ausgewählt werden.

Abbildung in dieser Leseprobe nicht enthalten

Wird die App Gestartet, muss noch die IP der Servers und der Port hinterlegt Werden.Als Port kann der angegebene Port „9888“ eingetragen werden. Die IP ist die IP des Hostrechners, welche man mit dem Befehl „ipconfig“ auf der Konsole abfragen kann.

Um Schwachstellen zu Demonstrieren, werden im folgenden Tools verwendet, welche ausführlich erst in den späteren Analyse Kapiteln erklärt werden.

Intent Spoofing

Da alle Komponenten eine Android App erst mal unabhängig voneinander laufen, braucht es ein Mechanismus diese Komponenten miteinander zu verbinden. Intents bieten genau diesen Mechanismus, sie verbinden die Komponenten miteinander. Dabei kann ein Intent als eine Art Nachricht verstanden werden, welche an Komponenten der eigenen oder fremder Apps geschickt werden kann. Die öffentlichen Ziele, welche Intents empfangen können stehen in der Manifestdatei einer App und werden bei der Installation im System registriert. Ändert der Entwickler nicht explizit die Sichtbarkeit eines Intents, ist dieser mit dem Eintrag in der Manifestdatei „public“. Dies kann dann zu schwerwiegenden Sicherheitslücken führen, wenn eine fremde bösartige App Intents sendet um Funktionen auszuführen, für die sie selbst keine Berechtigung hat. Genau dies ist auch in der GoatDroid App der Fall. Betrachtet man die Manifestdatei sieht man eine Reihe interessanter Einstiegspunkt die mittels eines öffentlichen Intents erreichbar sind.

Abbildung in dieser Leseprobe nicht enthalten

Beispiel aus der GoatDroid Manifestdatei

Wie in dem Beispiel zu sehen, gibt es einen „SendSMSNowReceiver“, welcher über einen „SOCIAL_SMS“ Intent erreichbar ist. Dies kann von anderen Apps genutzt werden. Dabei muss die fremde App wissen welche Informationen der Receiver erwartet. Um dies herauszufinden reicht eine einfache Analyse der konstanten Zeichenfolgen im Quellcode des Broadcastreceiver. Aus den Resultaten lassen sich die Felder erkenne die der Intent haben muss. Dies klappt deswegen, weil jedes Datenfeld in einem Intent durch ein Schlüssel-Wert Paar repräsentiert wird. Der Schlüssel kann dabei eine beliebige konstante Zeichenfolge sein.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung in dieser Leseprobe nicht enthalten

Beispiel Intent an SendSMSNowReceiver¹²

Verhindern kann man dies, indem man den Intent nicht öffentlich verfügbar macht. Dies kann mit dem ,,android:exported='false'“ Attribute erfolgen.

Unauthorized Intent Receipt

Einem Angreifer ist es nicht nur möglich, Intents an Komponenten zu schicken und damit Schaden anzurichten, sondern er kann diese auch abfangen. Intents unterteilen sich in zwei Arten, als erstes gibt es die expliziten Intents. Diese Art wird direkt an eine festdefinierte Klasse gesendet und löst dort eine Action aus. Diese Art von Intent ist eindeutig, da sie die Aktion über den voll qualifizierten Namen der Klasse anspricht.

Abbildung in dieser Leseprobe nicht enthalten

Expliziter Intent¹³

Bei der zweiten Art, dem impliziten Intent, wird eine Aktion ausgelöst ohne das explizit eine Klasse angesprochen wird. Dabei übernimmt Android die Zuweisung des Intents an eine konkrete Klasse. Danach kannjede beliebige App den Intent empfangen, wenn sie einen Filter auf die angegebene Aktion gesetzt hat. Dies führt dann dazu, dass die Informationen, die dem Intent angehängt wurden sind, auch der fremden App bekannt gemacht werden. Deshalb sollten keine sensiblen Informationen über implizite Intents geschickt werden. Ein Beispiel für einen solchen impliziten Intent, war der obige Intent zum Angreifen des Broadcastreceivers. Im folgenden soll eine App geschrieben werden, welche die Nachrichten abfängt und ausließt, die der „SendSMSNowReceiver“ von FourGoats in einer SMS verschicken soll. Dazu kann einer beliebigen App die folgende Klasse hinzugefügt werden.

Abbildung in dieser Leseprobe nicht enthalten

Registrierung des Breadcastreceivers

Bei der Installation wird der Broadcastreceiver im System registriert, danach werden alle Intents nicht nur an den „SendSMSNowReceiver“, sondern auch an die Fake App geschickt. Diese kann nun den Inhalt der Intents auswerten und weiter verarbeiten.

Abbildung in dieser Leseprobe nicht enthalten

Mitschneiden von Nachrichten

Information Leakage

Die Android API bietet eine Reihe von Möglichkeiten wie Informationen gespeichert werden können. Dabei kann der Entwickler sich nicht einfach eine Möglichkeit aussuchen, sondern muss den richtigen Speicherort für seine Daten wählen. Dabei unterscheiden sich die Speicherorte aufgrund ihres Sicherheitsniveau. Welcher Speicherort und Sicherheitsniveau angemessen ist, hängt dabei vom Grad der Sensibilität der Informaionen ab. Um die Sensibilität der Informationen einer App einschätzen zu können, kann man zwischen fünf Stufen unterscheiden.

1. keine sensiblen Anwenderdaten
- Daten die keine Rückschlüsse zulassen, wie zum Beispiel die Displayposition auf der etwas angezeigt wird.

2. Benutzerdaten
- Daten die direkt vom Benutzer kommen aber nicht kritisch sind, da sie für eine breite Masse von Leuten gedacht sind. Zum Beispiel Statusmeldungen in sozialen Netzwerken.

3. Metadaten

- Daten die indirekt Rückschlüsse auf den Benutzer und sein Verhalten zulassen. Zum Beispiel GPS Daten.

4. sensible Benutzerdaten
- Daten die direkt vom Benutzer kommen aber nur für einen eingeschränkten Benutzerkreis sichtbar sein sollen, zum Beispiel SMS Nachrichten.

5. hochsensible Benutzerdaten
- Benutzerdaten die einen finanziellen Schaden verursachen können, wie zum Beispiel Kreditkarten Daten.

Das notwendige Sicherheitsniveau steigt von Grad 1 nach Grad 5 an. Ist man sich bewusst, welches Grad die Informationen haben, kann man den geeigneten Speicherort wählen und evtl. noch weitere Sicherheitsmaßnahmen ergreifen.

Mögliche Speicherorte sind:

1. Shared Preferences
- Speicherung von primitiven Datentypen in speziellen XML Dokumenten. Die Dokumente sind im Ordner ,,/data/data/<PaketName>/shared_prefs“ zu finden.

[...]

---

¹ Quelle: http://apps.evozi.com/apk-downloader/

² Quelle: http://www.oracle.com/technetwork/iava/iavase/downloads/iava-se-idk-7-download-432154.html

³ Quelle: http://www.eclipse.org/downloads/

⁴ Quelle: https://dl-ssl.google.com/android/eclipse

⁵ Quelle: https://developer.android.com/sdk/index.html

⁶ Quelle: http://developer.android.com/tools/debugging/ddms.html

⁷ Quelle: http://developer.android.com/tools/help/adb.html

⁸ Quelle: https://cloud.genvmotion.com/page/launchpad/download/

⁹ Quelle: https://santoku-linux.com/features

¹⁰ Quelle: https://santoku-linux.com/

¹¹ Quelle: https://www.owasp.org/index.php/OWASP_Mobile_Securitv_Project#tab=Mobile_Tools

¹² Quelle: http://www.pwntester.com/blog/2012/11/17/168935099/

¹³ Quelle: http://developer.android.com/guide/components/intents-filters.html