View
9
Download
0
Category
Preview:
Citation preview
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
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
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.
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
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.
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.
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
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.
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.
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:
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:
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.
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:
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.
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.
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.
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
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
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.
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:
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.
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:
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:
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:
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.
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.
Recommended