Aufgabe 2 Android Reverse Engineering & Code Injection

Ausarbeitung im Studiengang Informationsmanagement & Computersicherheit Lehrveranstaltung Wahlpflichtfach: Sicherheit von Mobilnetzen und mobilen Appl...
Author: Anneliese Acker
2 downloads 0 Views 2MB Size
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

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-samplemobilemalware.html (2) Kopieren des .apk Files auf den Desktop Rechner mit Hilfe eines geeigneten

(3)

(4) (5)

(6) (7) (8) (9)

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!) 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,... Verwendung des apktools (http://code.google.com/p/android-apktool/) zum Reverse Engineering der App, Analyse des Smali Codes 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&) Online-Recherche zur ausgewählten App (schon bekannt?, wie viele Downloads?, welche Art von Malware?, Art der Verbreitung,...) Wenn möglich Ausführen der App im Emulator Code Injection: Code von Aufgabenstellung 1 in die neue App integrieren (Versenden von Kontaktdaten z.B. gleich in OnCreate()) 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

2

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 WebviewKomponente 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.

3

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 4

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 APKDatei 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.

5

(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.

6

(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 möchte



Sofort beim Start gestartet werden möchte



Verhindern möchte, dass das Smartphone in den Sleeping Modus wechselt

Applikationen

wiederherstellen

7

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äteAdministrationsfenster, welches der App Zugriff auf die Android Device Administration API erlaubt. Diese bietet Administrations-Features auf Systemebene und ist eigentlich für UnternehmensApplikationen 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.

8

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.

9

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 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:

10

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:

11

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.

12

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:

13

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 APKArchiv 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.

14

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.

15

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.

16

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

17

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 18

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.

19

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:

20

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. 21

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:

22

(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-XMLDateien 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:

(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: 23

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:

24

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.

25

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.

26