Download - Ausarbeitung - Lean Startup Security · Android Reverse Engineering & Code Injection Ausgeführt von: Hermann Wagner, BSc (1410303021) Lukas Schweitzer, BSc (1410303015) Thomas Wild,

Transcript
Page 1: Ausarbeitung - Lean Startup Security · Android Reverse Engineering & Code Injection Ausgeführt von: Hermann Wagner, BSc (1410303021) Lukas Schweitzer, BSc (1410303015) Thomas Wild,

Ausarbeitung

im Studiengang Informationsmanagement & Computersicherheit

Lehrveranstaltung Wahlpflichtfach: Sicherheit von Mobilnetzen und

mobilen Applikationen

Aufgabe 2

Android Reverse Engineering & Code Injection

Ausgeführt von: Hermann Wagner, BSc (1410303021)

Lukas Schweitzer, BSc (1410303015)

Thomas Wild, BSc (1410303045)

BegutachterIn: Dipl.-Ing. (FH) Stefan Schmidt, MSc

Wien, 15.02.2015

Page 2: Ausarbeitung - Lean Startup Security · Android Reverse Engineering & Code Injection Ausgeführt von: Hermann Wagner, BSc (1410303021) Lukas Schweitzer, BSc (1410303015) Thomas Wild,

2

Aufgabenstellung

Ziel dieser Übung ist Kennenlernen und Verwenden diverser Reverse Engineering Tools für

Android Apps und die praktische Durchführung einer Code Injection.

Es sollen insgesamt folgende Schritte durchgeführt werden:

(1) Auswahl einer „verdächtigen“ App aus dem Google Play Store oder einem alternativen

Market ODER Download eines Malware Samples von Seiten wie

http://contagiodump.blogspot.co.at/2011/03/take-sample-leave-sample-

mobilemalware.html

(2) Kopieren des .apk Files auf den Desktop Rechner mit Hilfe eines geeigneten

Dateimanagers für Android (Achtung, Rooten des Gerätes ist nicht nötig, manche File

Manager unterstützen das Erstellen von Backups auf der SD Card!)

(3) Verwendung eines Java Decompilers (empfohlen wird dex2jar,

http://code.google.com/p/dex2jar/), und Analyse des Java Codes: Wie sicher ist die App

geschrieben, welche Daten werden übertragen,...

(4) Verwendung des apktools (http://code.google.com/p/android-apktool/) zum Reverse

Engineering der App, Analyse des Smali Codes

(5) Ein Online Decompiler wie der Android APK Decompiler

(http://www.decompileandroid.com/) liefert oft leicht anders dekompilierten Code

Zusätzlich kann man weitere Tools wie JDGUI ausprobieren

(https://code.google.com/p/innlab/downloads/detail?name=jd-gui-0.3.3.windows.zip&)

(6) Online-Recherche zur ausgewählten App (schon bekannt?, wie viele Downloads?,

welche Art von Malware?, Art der Verbreitung,...)

(7) Wenn möglich Ausführen der App im Emulator

(8) Code Injection: Code von Aufgabenstellung 1 in die neue App integrieren (Versenden

von Kontaktdaten z.B. gleich in OnCreate())

(9) Repackaging

Sonstiges

Dokumentation (10 Seiten) erstellen

Abgaben bis 18.02.2015: Dokumentation & Source Code (Malware mit injected Code)

per Mail oder über Dropbox, Yousendit, etc

Page 3: Ausarbeitung - Lean Startup Security · Android Reverse Engineering & Code Injection Ausgeführt von: Hermann Wagner, BSc (1410303021) Lukas Schweitzer, BSc (1410303015) Thomas Wild,

3

0 Vorwort

Basierend auf der Aufgabenstellung wurde dieses Dokument in 3 Hauptkapitel und einer

Zusammenfassung unterteilt. Im ersten Kapitel geht es um das Beschaffen einer

verdächtigen bzw. bösartigen Android Applikation aus verschiedensten Quellen. Das Kapitel

2 behandelt dann, wie eine jede Android App analysiert und aus jeder Bytecode Applikation

der Quellcode rekonstruiert werden kann. Nachdem die App analysiert und ihre

Funktionalität verstanden wurde, wird in Kapitel 3 eigener Code zum Originalcode der App

hinzugefügt und die App neu erstellt. Als letztes Kapitel folgen eine Zusammenfassung und

ein Fazit der Autoren.

1 Auswahl einer „verdächtigen“ App (1, 6)

Im ersten Schritt soll eine verdächtige Android App bzw. Android Malware heruntergeladen

werden. Doch bevor wir das machen, werfen wir erst einmal einen Blick darauf welche Arten

von Malware es überhaupt für Android gibt:

Viren und Würmer

…gibt es für Android de facto gar nicht. Da jede Applikation einen eigenen Linux User

zugewiesen bekommt, der nur in seinem eigenen Verzeichnis und auf seine eigenen

Ressourcen volle Zugriffsrechte hat und sonst keine, ist es einer Android App nicht

möglich sich in einer anderen App einzunisten, wie es ein Virus per Definition tut.

Auch bei der Ausführung sind die Applikationen voneinander abgeschottet, da jede

App in einer eigenen Instanz der Android Runtime gestartet wird. Dadurch läuft eine

jede App in einer eigenen Sandbox und ihr ist es nicht möglich auf die Prozessräume

anderer Apps zuzugreifen (sofern es keinen Exploit für die Sandbox gibt). Wollen

Applikationen miteinander Daten austauschen, so müssen sie dies über die

vordefinierten und abgesicherten Schnittstellen tun, die Android ihnen zur Verfügung

stellt.

Da die Android Applikationen allesamt in Java geschrieben sind und Java eine Reihe

an Sicherheitsmechanismen bereits in der Programmiersprache selbst implementiert

sind (zB. automatischer Check der Array-Grenzen, Zugriffskontrolle mittels private,

protected, …), ist es sehr schwer einen Exploit in einer Android App zu finden und

diesen auszunutzen um eigenen Code auszuführen (Ausnahme: Android-Browser

der bis Android 4.3 verwendet wurde und auf der nicht mehr unterstützen Webview-

Komponente basiert – Exploits, Exploits, Exploits ).

Durch diese beiden Eigenschaften ist sichergestellt, dass Android Applikationen nicht

die Sicherheit des Systems schwächen können und als Einfallstor dienen, wie es zum

Beispiel bei Windows der Fall ist.

Page 4: Ausarbeitung - Lean Startup Security · Android Reverse Engineering & Code Injection Ausgeführt von: Hermann Wagner, BSc (1410303021) Lukas Schweitzer, BSc (1410303015) Thomas Wild,

4

Weiters muss der Benutzer der Installation einer jeden Applikation im Vorhinein

zustimmen. So etwas wie eine Installation im Hintergrund gibt es nicht (wieder unter

der Voraussetzung, dass es keinen Exploit für Android gibt). Dadurch kann sich ein

Wurm nicht von selbst verbreiten und auf einer Vielzahl an Endgeräten einnisten.

Trojaner

Da es weder Viren noch Würmer gibt, bleibt eigentlich nur noch die dritte der drei

Haupt-Kategorien, in die Malware unterschieden werden kann: Trojaner.

Getarnt als nützliches Programm, führt diese Art von Malware im Hintergrund

Funktionen aus, die vom Benutzer des Systems ungewollt sind bzw. dem Benutzer

schaden. Wichtig dabei ist, dass der Benutzer der Installation des Programms aktiv

zustimmt (anders geht es ja auf Android auch gar nicht), aber nur über einen Teil der

Funktionalitäten des Programms Bescheid weiß. Da eine jede Anwendung jedoch in

der Manifest-Datei angeben muss, welche Zugriffsberechtigungen (API-Aufrufe) sie

benötigt und der Benutzer diesen bei der Installation der App zustimmen muss, kann

dieser zumindest in etwa nachvollziehen was die App alles machen kann und ob die

angefragten Berechtigungen plausibel erscheinen. Benötigt eine Taschenlampen-App

zum Beispiel Zugriff auf das Adressbuch und auf GPS, so sollten diese

Berechtigungsanfragen den Benutzer als Warnsignal dienen und er sollte diese App

als höchst verdächtig einzustufen und besser nicht installieren.

Wirft man einen genaueren Blick auf die, in den App-Stores, verfügbaren (Gratis-)

Applikationen, so muss man leider feststellen, dass ein Großteil der Apps

Berechtigungen anfordert, die eigentlich nicht zur angegebenen Funktionalität passen

und daher als Trojaner eingestuft werden müssen. Das Hauptproblem dabei ist, dass

die Apps durch den Verkauf von Benutzerdaten Geld verdienen können und das

Ganze durch die implizite Zustimmung des Benutzers zu den AGB (die sich ohnehin

niemand durchliest) sogar dem Gesetz entspricht.

Neben dieser „harmloseren“ und gängigen Form von trojanischen Pferden, gibt es

aber auch gefährlichere Varianten von Android Trojanern, die es nicht nur auf die

privaten Meta-Daten der Benutzer abgesehen haben:

o Gefälschte Banking Apps (Banking Trojans)

o Keylogger zum Stehlen von Credentials

o Aufzeichnen von Gesprächen

o Anrufen bzw. SMS an Premium-Nummern

o Stehlen von privaten Dokumenten, Fotos und Videos

o usw.

Wir sehen also, dass Prinzip die Suche nach Android-Malware uns nicht sehr schwer fallen

wird, da sehr viele Apps mit „Zusatzfunktionen“ ausgestattet sind. Wir wollen uns jedoch

nicht mit einer „normalen“ 0815 App aus dem Android Store begnügen, sondern analysieren

Page 5: Ausarbeitung - Lean Startup Security · Android Reverse Engineering & Code Injection Ausgeführt von: Hermann Wagner, BSc (1410303021) Lukas Schweitzer, BSc (1410303015) Thomas Wild,

5

eine bereits bekannte Malware. Diese können wir von der Webseite

http://contagiominidump.blogspot.co.at/ herunterladen. Über diese Webseite können eine

Vielzahl von Malware Samples heruntergeladen werden. Diese sind zwar passwortgeschützt,

jedoch kann man die Webseiten-Betreiberin anschreiben damit sie einem das Passwort

zusendet.

Für diese Aufgabe haben wir die Malware „Android FBI Ransomlocker“ ausgewählt. Diese

tarnt sich in den diversen App Stores als bekannte App oder Antivirus (in unserem Fall als

Adobe Flash Player) und führt nach Ausführung dann dazu, dass der Benutzer des

Smartphones keinen Zugriff mehr auf dieses erhält und eine FBI-Warnmeldung angezeigt

bekommt. In der Warnmeldung wird dann in weiterer Folge verlangt, dass einige hunderte

Dollar in Form von einer MoneyPak – Gutschrift überwiesen werden, damit die Applikation

das Mobiltelefon wieder zur Verwendung freigibt. Mehr Details zum Verhalten der Applikation

folgen in der Analyse der App.

Installieren der „verdächtigen“/bösartigen App am Emulator

Nun, da wir eine APK-Datei zur Analyse ausgewählt haben, wollen wir diese natürlich auf

den Emulator übertragen und die Datei im ersten Schritt erst einmal nur installieren.

Dafür gibt es wiederum mehrere Möglichkeiten, wobei wir hier zwei Methoden zeigen wollen.

Die einfachste Methode ist folgende:

(1) Starten des Emulators und warten bis der komplett hochgefahren ist (also so lange

bis man den Bildschirm entsperren kann)

(2) Am Host-PC die Konsole, in das sdk-Verzeichnis springen und anschließend in den

Ordner „platform-tools“ wechseln.

(3) Mit dem Befehl: adb install „Pfad_zur_APK_Datei“ wird die gewünschte APK-

Datei am Emulator installiert.

Bei einer erneuten Installation muss zusätzlich die Option -r angegeben werden.

Eine weitere Methode wäre folgende:

(1) Installieren eins Android App Stores am Emulator.

Ansurfen der Webseite http://m.aptoide.com/ im Emulator und auf „Install Aptoide“

klicken. Nachdem die Datei heruntergeladen wurde, im Emulator von oben nach

unten wischen um den Download anzuzeigen. Ein einfacher Klick auf den Download

genügt um die Installation zu starten.

Page 6: Ausarbeitung - Lean Startup Security · Android Reverse Engineering & Code Injection Ausgeführt von: Hermann Wagner, BSc (1410303021) Lukas Schweitzer, BSc (1410303015) Thomas Wild,

6

(2) Nun öffnen wir den App Store und suchen nach einem Dateimanager. Dann wählen

wir einen aus der als vertrauenswürdig gekennzeichnet wurde (Trusted = Signatur im

App Store stimmt mit der Signatur im Android Store und mit der Signatur des

Entwicklers überein).

(3) Nachdem dieser Installiert wurde öffnen wir in Android Studio den „Android Device

Manager“. Dieser ermöglich es uns Dateien von dem Host-PC auf den Android

Emulator zu übertragen. Wir kopieren die APK-Datei in ein Verzeichnis, auf welches

jede App (also auch der zuvor geladene File Manager) Zugriff hat.

Page 7: Ausarbeitung - Lean Startup Security · Android Reverse Engineering & Code Injection Ausgeführt von: Hermann Wagner, BSc (1410303021) Lukas Schweitzer, BSc (1410303015) Thomas Wild,

7

(4) Nun können wir mit dem File-Manager in

das Download-Verzeichnis wechseln und

die APK-Datei auswählen & installieren.

Der Unterschied zwischen beiden Methoden ist,

dass bei der ersten Methode der Benutzer des

Emulators nicht gefragt wird ob er die

Berechtigungen, die die App fordert, genehmigt.

Stattdessen wird einfach die APK-Datei installiert.

Aus diesem Grund verwenden wir die Methode 2

um die Installation durchzuführen. Bei den

geforderten Berechtigungen der Applikation ist

natürlich schon auffallend, dass die App:

Den Lock-Screen deaktivieren möchte

Andere Applikationen schließen möchte

Andere Applikationen wiederherstellen

möchte

Sofort beim Start gestartet werden möchte

Verhindern möchte, dass das Smartphone

in den Sleeping Modus wechselt

Page 8: Ausarbeitung - Lean Startup Security · Android Reverse Engineering & Code Injection Ausgeführt von: Hermann Wagner, BSc (1410303021) Lukas Schweitzer, BSc (1410303015) Thomas Wild,

8

Egal auf welche Art die Installation der App

schlussendlich erfolgt, das Ergebnis ist folgendes: Es

wird eine Applikation installiert mit dem Symbol des

Adobe Flash Players.

Nach der erfolgreichen Installation können wir nun

die Applikation analysieren.

2 Analyse und Reverse Engineering (2, 3, 4, 5, 7)

Nach der Auswahl der zu analysierenden App und der Installation, folgt nun die Analyse der

Applikation. Diese Analyse führen wir durch indem wir die apk-Datei dekompilieren und uns

in weiterer Folge den Java-Code der Anwendung näher ansehen. Bevor wir das machen,

wollen wir aber die App erst einmal ausführen um zu sehen ob und wie diese überhaupt

funktioniert.

Dazu legen wir uns zur Sicherheit eine Kopie des Emulators an (falls nicht schon vor der

Installation erledigt) und klicken auf den Flash Player Icon.

Als erstes öffnet sich gleich das Geräte-

Administrationsfenster, welches der App Zugriff auf

die Android Device Administration API erlaubt.

Diese bietet Administrations-Features auf

Systemebene und ist eigentlich für Unternehmens-

Applikationen gedacht, bei denen die IT-Abteilung

erweiterte Kontrolle über Smartphones der

Angestellten haben möchte. Mehr Informationen

dazu hier.

Auf jeden Fall muss der Benutzer diesen

Berechtigungen nach dem Starten der App einmalig

zustimmen.

Im ersten Versuch klicken wir erst mal auf CANCEL um zu sehen welche Funktionen die App

entfaltet, wenn sie keine Admin-Rechte hat.

Page 9: Ausarbeitung - Lean Startup Security · Android Reverse Engineering & Code Injection Ausgeführt von: Hermann Wagner, BSc (1410303021) Lukas Schweitzer, BSc (1410303015) Thomas Wild,

9

Nach dem verneinen und dem Klick auf „Proceed“ werden folgende Meldungen angezeigt:

Das Gerät wurde also angeblich gesperrt. Im

Android Device Manager sieht man den neu

gestarteten Prozess „com.android.locker“.

Das erste was der Benutzer nun versuchen

wird, ist das Beenden der App. Jedoch der

„Zurück-Button“ funktioniert nicht mehr. Bei

Klick auf den Home-Button wird die App zwar

wie jede andere minimiert, jedoch schon ein

paar Sekunden später wird schon wieder die

App in den Vordergrund geholt und das

„Activate Device Administrator“ Fenster

angezeigt. Dem Benutzer bleibt dadurch fast

keine Zeit die App zu beenden.

Auch nach Neustart des Emulators / Smartphones wird die

Ransomware erneut gestartet.

Die einzige Möglichkeit die App zu beenden und zu

deinstallieren ist über die „Hardware“-Taste zum Wechseln

der Apps.

Page 10: Ausarbeitung - Lean Startup Security · Android Reverse Engineering & Code Injection Ausgeführt von: Hermann Wagner, BSc (1410303021) Lukas Schweitzer, BSc (1410303015) Thomas Wild,

10

Räumt man der App Admin-Rechte ein, so besteht unter Einstellungen / Apps nicht mehr die

Möglichkeit die Applikation zu entfernen, da der Uninstall Button ausgegraut ist.

Entfernen der Ransomware

Die App kann z.B. über den sogenannte „Safe Mode“ wieder entfernt werden. Wie man in

diesen wechseln kann wird auf entnimmt man am besten der Bedienungsanleitung des

jeweiligen Smartphones. Im „Safe Mode“ können Applikationen, die der Benutzer manuell

zum Mobiltelefon hinzugefügt hat, nicht starten. Geht man nun zur Einstellungen / Apps so

ist der Uninstall Button noch immer ausgegraut. Aus diesem Grund muss man zuvor auf

Einstellungen / Security wechseln und im Menüpunkt „Device Administrators“ bei der Flash

Player App auf Deaktivieren klicken.

Nun kann man über die Einstellungen die App entfernen.

Im Android Emulator kann man eine App auch über ADB deinstallieren (Jedoch nur, wenn

App nicht als Device Administrator eingetragen ist):

adb uninstall <package>

Also in unserem Fall: adb uninstall com.android.locker

Erkennungsrate

Da die App bereits als Malware bekannt ist, wollen wir uns ansehen wie viele Anti-Virus

Programme für Android die App als Malware erkennen: Aus diesem Grund laden wir die App

auf VirusTotal.com hoch und sehen uns das Ergebnis näher an:

Page 11: Ausarbeitung - Lean Startup Security · Android Reverse Engineering & Code Injection Ausgeführt von: Hermann Wagner, BSc (1410303021) Lukas Schweitzer, BSc (1410303015) Thomas Wild,

11

Das Ergebnis zeigt, dass die meisten AntiVirus die App als Malware identifizieren können

und den Nutzer vor dieser schützen können.

Im Reiter „File Detail“ kann man sich die verschiedensten Eigenschaften der Applikation

ansehen und schon einmal einen Überblick über die Funktionen verschaffen:

Page 12: Ausarbeitung - Lean Startup Security · Android Reverse Engineering & Code Injection Ausgeführt von: Hermann Wagner, BSc (1410303021) Lukas Schweitzer, BSc (1410303015) Thomas Wild,

12

Verbreitung

Es scheint mehrere verschiedene Varianten der Malware zu geben. So gibt es einerseits

verschiedene vorgetäuschte Funktionen (Antivirus, FlashPlayer, …) und andererseits

verschiedene Meldungen (FBI, Interpol, …) mit unterschiedlichen Geldforderungen. Ein paar

Beispiele können unter folgendem Link eingesehen werden:

http://malware.dontneedcoffee.com/2014/08/scarepackageknstant.html

Kommunikation mit dem „Mutterschiff“

Um zu sehen ob und wie die bösartige App mit ihrem Entwickler(n) über das Internet

kommuniziert, verwenden wir das Tool tcpdump, welches im Emulator integriert ist und den

gesamten Netzwerktraffic vom und zum Emulator aufzeichnet. Dazu verwenden wir jedoch

ein neues Android Image auf dem die Malware noch nicht installiert war. Dann starten wir die

Konsole, wechseln wir in das Verzeichnis …\sdk\tools und geben folgenden Befehl ein:

emulator -tcpdump emulator.cap -avd my_avd

Der Emulator wird gestartet. Nun installieren wir die bösartige Applikation und starten diese.

Wir geben ihr Admin-Rechte und versuchen anschließend das Mobiltelefon freizuschalten

indem wir irgendeinen Code eingeben.

Dann öffnen wir die erstellte FBI.cap Datei im Wireshark um uns die Kommunikation

zwischen Emulator und den Rest der Welt anzusehen. Wichtig ist zu wissen, dass der

Emulator die IP-Adresse 10.0.2.15 hat und der Host-PC die Adresse 10.0.2.2. Somit können

wir gleich den gesamten Traffic von uns zur Adresse 10.0.2.2 wegfiltern, da uns ja nur der

Traffic vom Emulator ins Internet interessiert und nicht der Traffic zwischen Emulator und

Host-PC.

Page 13: Ausarbeitung - Lean Startup Security · Android Reverse Engineering & Code Injection Ausgeführt von: Hermann Wagner, BSc (1410303021) Lukas Schweitzer, BSc (1410303015) Thomas Wild,

13

Auffallend ist auf jeden Fall, dass unser Emulator (10.0.2.15) immer wieder versucht eine

Verbindung zur IP-Adresse 193.169.86.104 aufzubauen, jedoch keine Antwort mehr

bekommt. Ein Lookup der IP-Adresse ergibt folgendes:

Es handelt sich also um eine russische Adresse, die aber anscheinend aktuell nicht

vergeben ist. Da die Malware App schon ein paar Monate alt ist, gehen wir davon aus, dass

es den Server anscheinend nicht mehr gibt.

Weiters sendet der Emulator TLSv1.2 verschlüsselte Daten an die IP-Adressen

216.58.209.162 und 23.23.129.71. Erstere ist eine IP-Adresse, die Google gehört und

zweitere kann einer Amazon Web Services EC2-Instanz zugeordnet werden.

Aktuell bleibt erst einmal offen ob der generierte Traffic von der bösartigen App stammt,

jedoch erscheint der Traffic höchst verdächtig (vor allem der von der IP 216.58.209.162), da

er im Emulator ohne die installierte App nicht auftaucht.

Reverse Engineering

Nun da wir in grob wissen was die bösartige App macht, werden wir uns den Quellcode der

Applikation im Detail ansehen. Dazu sehen wir uns erst einmal die APK-Datei an. Wir

wissen, dass diese ein Archiv ist und öffnen sie daher mit einem De-Komprimierungstool wie

z.B. 7-Zip:

Page 14: Ausarbeitung - Lean Startup Security · Android Reverse Engineering & Code Injection Ausgeführt von: Hermann Wagner, BSc (1410303021) Lukas Schweitzer, BSc (1410303015) Thomas Wild,

14

Wir können uns die Manifest-Datei und das Erstellungsdatum (falls nicht manipuliert) der App

ansehen.

Aus der AndroidManifest.xml Datei können wir herauslesen welche Activity beim

Programmstart geladen wird. Dazu suchen wir nach „activity“ und sehen uns an was danach

kommt. Wir sehen „MainActivity$mainActivity“ und danach einen Intent-Filter mit der Action:

„android.intent.action.MAIN“ und der Kategorie: „android.intent.category.LAUNCHER“. Die

MainActivity wird bei uns also als erstes geladen.

Im Ressourcen-Ordner können wir uns z.B. ansehen welche Abbildungen die App

verwendet:

Interessant ist für uns in weiterer Folge die knapp 650 kB große classes.dex Datei, da in ihr

die eigentliche Applikation im Dalvik Bytecode-Format steckt. Um aus dem Bytecode

wiederum Java-Quellcode zu erstellen, müssen wir die dex-Datei jedoch nicht aus dem APK-

Archiv extrahieren, sondern können wie folgt vorgehen:

a) APK-Archiv in ein JAR-Archiv umwandeln

Dazu verwenden wir das Kommandozeilen Tool dex2jar Konverter, welches unter

folgendem Link zum Download verfügbar ist:

https://code.google.com/p/dex2jar/

b) JAR-Archiv dekompilieren

Nun öffnen wir das Jar-Archiv mit Hilfe des Programms JD Java Decompiler

(http://jd.benow.ca/) und schon können wir uns den Java Quellcode der App

ansehen, wie in der Abbildung unterhalb schön zu sehen ist.

Page 15: Ausarbeitung - Lean Startup Security · Android Reverse Engineering & Code Injection Ausgeführt von: Hermann Wagner, BSc (1410303021) Lukas Schweitzer, BSc (1410303015) Thomas Wild,

15

Wir sehen einige Java-Klassen mit vielaussagenden Namen (Encryption,

BackgroundService, VirusSearcher, …). Wenn wir uns jede Klasse nacheinander näher

ansehen, so merken wir, dass einige Methoden verschleiert (obfuscated) wurden und der

Java Decompiler nicht in der Lage ist, diese in Hochsprachencode umzuwandeln. Er zeigt

uns nur den Bytecode. Die Methode sendCode in der Klasse RequestSender.class ist ein

gutes Beispiel dafür:

Die ganze App zu durchleuchten und zu verstehen würde den Rahmen dieser Ausarbeitung

sprengen, aber wir wollen uns zumindest die MainActivity.class Datei näher ansehen.

Page 16: Ausarbeitung - Lean Startup Security · Android Reverse Engineering & Code Injection Ausgeführt von: Hermann Wagner, BSc (1410303021) Lukas Schweitzer, BSc (1410303015) Thomas Wild,

16

Wir starten (wie die Ausführung der App) mit der onCreate()-Methode.

Die ersten paar Zeilen passen das Aussehen der Activity an, deaktivieren den

Sperrbildschirm und zeigen dem Benutzer dann die „activity_main“ (2130903040).

Als nächstes wird dann die IMEI des Mobiltelefons ausgelesen, in ein Textfeld

geschrieben und somit dem Benutzer angezeigt.

Nun wird ein neuer Thread erzeugt und in diesem die verschleierte Methode

sendIncrement() der RequestSender Klasse aufgerufen.

Es wird ein neues Encryption – Objekt erzeugt, jedoch damit noch nichts gemacht

Dann wird ein Application Service gestartet, welches den Code in der

BackgroundService.class Datei ausführt

Dann wird versucht Geräte-Administrationsrechte zu erlangen mittels dem

Methodenaufruf: setDeviceAdmin()

Zu guter Letzt wird zum Button noch ein OnClickListener hinzugefügt, der bei einem

Klick auf den Button die SenderActivity-Klasse lädt und in den Vordergrund bringt.

Page 17: Ausarbeitung - Lean Startup Security · Android Reverse Engineering & Code Injection Ausgeführt von: Hermann Wagner, BSc (1410303021) Lukas Schweitzer, BSc (1410303015) Thomas Wild,

17

3 Code Injection (8, 9)

Wir wollen nun zeigen wie man eine signierte APK-Datei, deren Quellcode einem nicht zur

Verfügung steht, modifizieren kann. Wir werden als signierte APK-Datei die in den

vorherigen Kapiteln behandelte FBI Ransomware verwenden und in diese eigenen Code

einfügen. Zur einfachen Verständnis soll erst einmal nur der Toast „Hacked!“ beim Starten

der bösartigen App angezeigt werden. Dafür rufen wir uns vorher aber noch einmal in

Erinnerung wie eine APK-Datei aufgebaut ist:

Dabei ist in der Datei classes.dex der gesamte ausführbare Code enthalten. Das heißt wir

werden diese Datei verändern & ersetzen müssen.

Vorgehensweise

(1) Entpacken der APK-Datei und disassembeln der Datei classes.dex in ein Format, in

dem wir den Code verändern können (.smali)

(2) Statische Analyse der App

(3) .smali (Code) in die App einfügen

(4) Bytecode neu kompilieren zur Datei classes.dex, die Datei in der APK-Datei ersetzen

und die APK-Datei neu signieren

Page 18: Ausarbeitung - Lean Startup Security · Android Reverse Engineering & Code Injection Ausgeführt von: Hermann Wagner, BSc (1410303021) Lukas Schweitzer, BSc (1410303015) Thomas Wild,

18

Verwendete Tools

Android Studio + Android SDK

7-Zip

BytecodeViewer (https://github.com/Konloch/bytecode-viewer/releases)

Dex2jar Konverter (http://code.google.com/p/dex2jar/)

android-apktool (https://code.google.com/p/android-apktool/)

Proof of Concept

(1) Disassembeln der DEX-Datei des APK-Archives

Dazu öffnen wir ganz einfach das APK-Archiv (FBI_ransomlocker.apk) mit dem

BytecodeViewer. Zuvor stellen wir jedoch die „View Panes“ noch richtig ein.

Pane1 soll den Output des Procyon-Decompilers zeigen.

Pane2 soll den editierbaren Smali-Code zeigen.

Dieser nimmt uns insofern Arbeit ab, da er automatisch die .dex-Datei dekompiliert

und in Hochsprachencode bzw. Smali-Code übersetzt.

(2) Statische Analyse des Codes

Analysier haben wir die App schon im vorherigen Kapitel. Aber wir werfen mal einen

genaueren Blick auf den Smali-Code.

(3) Eigenen Code einfügen

Editieren werden wir den Smali-Code. Aus diesem Grund müssen wir den Code, den

wir einfügen wollen entweder direkt in Smali-Code schreiben oder aber wir erstellen

Page 19: Ausarbeitung - Lean Startup Security · Android Reverse Engineering & Code Injection Ausgeführt von: Hermann Wagner, BSc (1410303021) Lukas Schweitzer, BSc (1410303015) Thomas Wild,

19

mittels Android Studio eine neue Applikation, die den Code enthält und lassen uns

eine neue APK-Datei erstellen.

Wir erstellen das Projekt und somit eine APK-Datei. Diese ist im Projektordner unter

...\projekt\app\build\outputs\apk\app-debug.apk zu finden.

Wir starten eine neue Instanz des BytecodeViewers und öffnen die app-debug.apk

Datei in ihm.

Diesen Smali-Code kopieren wir und fügen ihn in den Smali-Code der bösartigen App

direkt nach dem Aufruf der setContentView() Methode ein.

Page 20: Ausarbeitung - Lean Startup Security · Android Reverse Engineering & Code Injection Ausgeführt von: Hermann Wagner, BSc (1410303021) Lukas Schweitzer, BSc (1410303015) Thomas Wild,

20

Die erste Zeile (gelb markiert) ändern wir ab von

„Lcom/mic14/mobile/codeinj1/MainActivity“ auf

„Lcom/android/locker/MainActivity$mainActivity“ so wie in der Zeile darüber.

Dann kompilieren wir die App mittels File/Compile bevor wir sie mittels File/Save as

DEX… als Datei „classes.dex“ exportieren.

(4) Neue APK-Datei erstellen & signieren

Nun öffnen wir das originale APK-Archiv „FBI_ransomlocker.apk“ mit einem

Dekomprimierungstool und ersetzen die Datei classes.dex mit unserer manipulierten

Datei. Die APK-Datei speichern wir nun als „FBI_ransomlocker_injected.apk“.

Zu guter Letzt müssen wir die manipulierte APK-Datei noch signieren, damit diese am

Emulator ausgeführt werden kann. Dazu verwenden wir die Toolsuite „dex2jar

Konverter“ und verwenden das Programm d2j-apk-sign.bat wie folgt:

Die neu erstellte, signiert APK-Datei „FBI_ransomlocker_injected_signed.apk“ laden

wir nun mittels dem Android ADB Tool in den Emulator hoch:

Page 21: Ausarbeitung - Lean Startup Security · Android Reverse Engineering & Code Injection Ausgeführt von: Hermann Wagner, BSc (1410303021) Lukas Schweitzer, BSc (1410303015) Thomas Wild,

21

Nun öffnen wir die Applikation mit dem Flash-Player-Icon und sehen sofort nach

dem Öffnen den „Hacked“ Toast.

Der Proof of Concept war also erfolgreich.

Einbinden des Codes aus der Aufgabe 1

Nun wollen wir noch den Code aus der Aufgabe 1 in die Ransomware einbinden.

Diese App (Abbildung links) macht nichts anderes als bei Betätigung des Buttons alle

Kontakte aus dem Telefonbuch zu extrahieren, in einer AES verschlüsselten Datei zu

speichern und anschließend an einen Server zu senden. Die Server-Applikation (php)

entschlüsselt anschließend die empfangene Datei (siehe Abbildung in der Mitte) und

speichert diese im XML-Format ab (siehe Abbildung rechts).

Wenn wir diese Funktionalität nun zur bösartigen Flash Player App hinzufügen möchten, so

benötigen wir natürlich nicht diese rote Activity und den Button. Wir wollen, dass unser Code

sofort ausgeführt wird, sobald die Malware startet. Deshalb müssen wir im ersten Schritt die

Applikation aus Aufgabe 1 entsprechend anpassen.

Am einfachsten funktioniert das Ganze wenn wir den gesamten Quellcode von Aufgabe 1 in

eine neue Klasse namens „Helper“ auslagern und von dieser in der MainActivity Klasse in

der OnCreate()-Methode eine Instanz erstellen.

Page 22: Ausarbeitung - Lean Startup Security · Android Reverse Engineering & Code Injection Ausgeführt von: Hermann Wagner, BSc (1410303021) Lukas Schweitzer, BSc (1410303015) Thomas Wild,

22

Zusätzlich sollte auch das Package genau gleich heißen, damit wir uns im Nachhinein beim

Kopieren des Smali-Codes Zeit ersparen. Wir ändern also das Package auf

com.android.locker.

Nun entfernen wir noch alle Widgets aus der Activity und auch alle unnötigen Klassen aus

dem MainActivity.java File: z.B.

extractAll()

onCreateOptionsMenu()

onOptionsItemSelected()

Übrig bleiben folgende Methoden:

onCreate() in der MainActivity

uploadContacts() in der Helper-Klasse

getVcardString() in der Helper-Klasse

get() in der Helper-Klasse

hexStringToByteArray() in der Helper-Klasse

Das Ganze sollte dann wie folgt aussehen:

Nachdem diese Änderungen vollzogen sind, lassen wir die Applikation neu erstellen und

testen ob unsere App noch immer dieselbe Funktionalität hat (nur ohne den Button-Klick).

Funktioniert alles wie geplant, so kopieren wir uns die erstellte APK-Datei aus dem

Verzeichnis „\app\build\outputs\apk“, benennen sie um in Aufgabe1.apk und speichern sie in

ein temporäres Verzeichnis.

Da wir für die zusätzlichen Funktionen aus Aufgabe1 andere Berechtigungen benötigen als

die Ransomware bereits hat, müssen wir in diesem Fall auch die Manifest-Datei anpassen.

Aus diesem Grund verwenden wir zusätzlich auch das APKTool:

Page 23: Ausarbeitung - Lean Startup Security · Android Reverse Engineering & Code Injection Ausgeführt von: Hermann Wagner, BSc (1410303021) Lukas Schweitzer, BSc (1410303015) Thomas Wild,

23

(1) Dekompilieren beider APK-Dateien mittels den Befehlen:

apktool.bat d FBI_ransomlocker.apk

apktool.bat d Aufgabe1.apk

Als Ergebnis erhalten wir zwei neue Ordner mit den jeweiligen Namen der APK-Datei.

In den Ordnern befindet sich die Manifest.xml Datei, als auch die Ressourcen-XML-

Dateien und die ins Smali-Format dekompilierten Quellcodedateien.

(2) Vergleichen und anpassen der Manifest-Dateien

Wir übernehmen die zusätzlich benötigten Berechtigungen für den Aufgabe1-Code in

die APK-Datei der dekompilierten Ransomware. In diesem Falle handelt es sich nur

um die Zeile:

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

(3) Einfügen der Helper Klasse

Wir kopieren die beiden Dateien der Helper-Klasse (Helper$1.SMALI und

Helper.SMALI) vom Verzeichnis „…\Aufgabe1\smali\com\android\locker\“ in das

Verzeichnis „…\FBI_ransomlocker\smali\com\android\locker\“.

Wir öffnen die beiden .SMALI Dateien um zu checken ob beim Verweis auf die

MainActivity immer MainActivity$mainActivity steht. Wenn nicht, dann ersetzen wir

den String einfach.

(4) Erstellen einer neuen APK-Datei

Nun erstellen wir mit Hilfe des apkTools eine neue APK-Datei, die im Ordner dist

erstellt wird:

Page 24: Ausarbeitung - Lean Startup Security · Android Reverse Engineering & Code Injection Ausgeführt von: Hermann Wagner, BSc (1410303021) Lukas Schweitzer, BSc (1410303015) Thomas Wild,

24

Diese benennen wir um in „FBI_ransomlocker_Aufgabe1halfInjected.apk“, da ja noch

der zusätzliche Code der Main-Activity fehlt.

(5) Code Injection in der OnCreate() Methode der MainActivity

Um nun die OnCreate() Methode der MainActivity zu manipulieren, öffnen wir die

Dateien „Aufgabe1.apk“ und „FBI_ransomlocker_Aufgabe1halfInjected.apk“ in zwei

eigenen Instanzen des Bytecode Viewers.

Von der MainActivity der Aufgabe1.apk kopieren wir uns im SMALI-Editable View die

3 Zeilen nach dem setContentView(I)V Aufruf in der onCreate() Methode.

Diese fügen wir in die MainActivity der FBI_ransomlocker_Aufgabe1halfInjected.apk

wiederum nach dem setContentView Aufruf der onCreate() Methode:

Page 25: Ausarbeitung - Lean Startup Security · Android Reverse Engineering & Code Injection Ausgeführt von: Hermann Wagner, BSc (1410303021) Lukas Schweitzer, BSc (1410303015) Thomas Wild,

25

Wichtig dabei ist, dass wir wiederum „MainActivity“ durch „MainActivity$mainActivity“

ersetzen.

Wir kompilieren das Ganze (View/Compile) und speichern die SMALI Dateien als

Dex-Datei (View/SAVE as DEX…) mit dem Namen

„FBI_ransomlocker_Aufgabe1Injected.dex“ ab. Wir kopieren uns die Datei unter den

Namen „classes.dex“.

*Der Vorteil am Bytecode Viewer ist, dass wir die Zeilennummern (.LINE XXX) in den .SMALI-Dateien

nicht manuell anpassen müssen, wie wir es im Editor machen müssten, wenn wir neuen Code einfügen:

(6) Erstellen der signierten APK-Datei

Nun kopieren wir uns das APK-Archiv, welches die beiden Helper-Klassen als auch

die angepasste Manifest-Datei enthält:

„FBI_ransomlocker_Aufgabe1halfInjected.apk“, benennen sie um in

„FBI_ransomlocker_Aufgabe1Injected.apk“, öffnen diese mit 7-Zip und ersetzen die

„classes.dex“ Datei mit der im vorherigen Schritt erstellten.

Anschließend signieren wir uns die neu erstellte APK-Datei mit Hilfe des dex2jar

Konverters und dessen Entwickler-Schlüssels:

(7) Installieren der App

Nun installieren wir am Emulator die soeben neu erstellte und signierte APK-Datei:

(8) Testen der App

Nach der Installation können wir zuerst den XAMPP-Server starten und anschließend

auf das Flash Player Icon klicken, um die manipulierte Anwendung zu testen. Die

Malware muss sich genau gleich wie vor den Änderungen verhalten. Wenn wir mit

dem File Explorer in den sdcard Ordner wechseln sehen wir jedoch sofort eine neue

„Contacts_“ Datei. Die manipulierte Applikation funktioniert also wie gewünscht.

Page 26: Ausarbeitung - Lean Startup Security · Android Reverse Engineering & Code Injection Ausgeführt von: Hermann Wagner, BSc (1410303021) Lukas Schweitzer, BSc (1410303015) Thomas Wild,

26

4 Zusammenfassung

Eine bestehende Android Applikation zu dekompilieren, eigenen Code einzufügen und eine

neue App daraus zu generieren ist zwar kein Kinderspiel, aber doch recht einfach. Somit

kann Jedermann einfach eine beliebte Applikation (z.B. GTA San Andreas) aus dem Android

Store herunterladen, die APK-Datei vom Mobiltelefon kopieren, seinen eigenen Code

einfügen und anschließend die App in einem anderen Store (z.B. Aptoide) zum Download

anbieten. Das einzige Erkennungsmerkmal ist, dass die Signatur der manipulierten App nicht

mit der Signatur der originale App übereinstimmt. Aus diesem Grund sollten Anwender

Hinweise auf falsche Signaturen nicht ignorieren und die App im Zweifelsfall nicht

installieren.