Ist die Geschäftskontinuität nicht Teil der Sicherheit?
Andrea Covello
In diesem Artikel dreht sich alles um den Aufbau eine Android Labs, das auf virtuellen Geräten läuft. Die Verwendung von physischen Geräten ist im Normalfall schnörkellos und benötigt weniger Zeit, um ein voll funktionsfähiges Lab zu sein. Dennoch gibt es bedeutende Nachteile. Wenn mehr als ein Analyst an einem App-Analyse-Projekt arbeitet, dann muss jeder Analyst ein eigenes Gerät mit identischem Setup besitzen (teure Lösung), oder das Zeit Management muss sehr gut sein (administrativer Overhead).
Ferner gilt es den Update-Cycle Androids zu beachten. Beim Kauf ist es nicht klar, wie viele zukünftige Android-Versionen vom Hersteller des Geräts unterstützt werden und wie lange es dauert, bis die unterstützten Updates erhältlich sein werden. Mit virtuellen Geräten können nicht nur mehrere Analysten am selben Projekt arbeiten, sondern das Problem des Update-Cycles löst sich ebenfalls.
Eine Schlüsselvoraussetzung des Labs sind Kosteneffizienz, Skalierbarkeit und Stand der Updates. Ein Lab, das nur auf physischen Geräten basiert, würde an diesen Anforderungen scheitern.
Die Kombination all dieser Faktoren macht ein rein hardwarebasiertes Labs problematisch. Dennoch soll das nicht heissen, dass in einem voll funktionsfähigen Labs keine physischen Geräte vorhanden sein sollten. Es ist sogar wahrscheinlich, dass physische Geräte für gewisse Projekte sogar unabdingbar sind.
Die Alternative zu physischen Geräten sind virtuelle Maschinen – Emulatoren. Davon gibt es mehrere, vom im SDK inbegriffenen Emulator über die quelloffene Android-x86 bis hin zu Produkten wie GenyMotion oder Andy.
Android-x86 ist ein Open-Source-Projekt, dessen Name Programm ist. Es geht darum, den Android Quellcode auf eine x86-Plattform zu portieren. Zum Zeitpunkt, an dem ich diesen Artikel im Herbst 2014 schreibe, bietet das Projekt eine Portierung von Android 4.4 an.
Die ISO-Datei kann als Live-Betriebssystem verwendet werden oder auf einer x86-Plattform installiert werden. Über die Installation müssen wir keine grossen Worte verlieren, denn jeder, der etwas Erfahrung mit der Erstellung von Linux/Unix Virtual Machines hat, kann die ISO in VMware oder VirtualBox zum Laufen bringen. Sollten dennoch Probleme auftauchen, bieten Blog Posts Hilfe.
Beim Start von Androind-x86 in einer VM wird der Ethernet-Link als Stellvertretung für mobile Netzwerkverbindung verwendet werden. Um Netzverkehr über einen Intercepting Proxy (zum Beispiel Burp Proxy) umzuleiten, sind noch einige weitere Schritte notwendig. Am einfachsten ist es wohl, eine weitere VM als Netzwerk-Proxy zu verwenden. Diese VM wird den ganzen HTTP- und HTTPS-Traffic von Android-x86 über den Intercepting Proxy leiten. Dieses Vorgehen wurde von Pascal Schaufelberger in einem früheren Labs-Artikel ausführlich beschrieben. Zusätzlich zu diesem Setup ist es ratsam, ein weiteres dediziertes virtuelles Netzwerk einzurichten, das sich mit dem Netzwerk verbindet, welches mit Android-x86 und der Proxy-VM kommuniziert. Dieser Link wird für die Android Debug Bridge (adb) verwendet.
Nutzer von VMware Player können keine zusätzlichen virtuellen Netzwerkinterfaces auf dem Host erstellen. Das macht die gleichzeitige Verwendung von adb und einem Intercepting Proxy, der Webtraffic überwacht, unmöglich. Daher muss in dem Falle die Netzwerkverbindung der Android-x86 VM rekonfiguriert werden.
Wie dem auch sei, um sich mit einem Gerät und adb verbinden zu können, ist die die IP-Adresse, die der Android-x86 VM gehört, notwendig. Gehen Sie in die Konsole, indem sie ALT+F1
drücken und führen Sie den Befehl netcfg
aus. Danach starten Sie auf dem Host-System eine Command Line und führen Sie folgende Befehle aus, um adb und die Android-x86 VM zu verbinden.
* check for any connected devices adb devices * connect to Android-x68 adb connect <IP-ADDRESS> * list the connected devices adb devices
Nach diesen Einstellungen kann über adb auf die Android-x86 VM zugegriffen werden. Sie sind nun in der Lage, den gesamten Netzwerkverkehr über einen Intercepting Proxy einzusehen und allen anderen Netzwerkverkehr auf der Proxy VM mit Tools wie tcpdump und tshark zu überwachen.
Im Vergleich mit anderen Emulatoren bietet die Android-x86 VM gute Nutzbarkeit und ist ein gutes Tool für VM-basierte virtuelle Geräte. Allerdings erfordert das initiale Setup einen grösseren Aufwand und kann unter Umständen nicht die neueste Android-Version unterstützen. Android-x86 ist mit keinerlei Zusatzkosten verbunden.
GenyMotion ist eine Firma, die Android-Emulatoren verkauft. GenyMotion bietet einige Produkte auf ihrer Website an. Eine Gratisversion eines Emulators ist zu Testzwecken und zum persönlichen Bedarf vorhanden. Das Tool kommt im Bündel mit Oracles VirtualBox oder als Standalone Software wenn VirtualBox bereits installiert ist.
Die Verwendung GenyMotions ist einfach: Ein Account ist notwendig, um auf die GenyMotion-Cloud zuzugreifen und die Software herunterzuladen. Weiter müssen die Images mit dem GenyMotion-Tool heruntergeladen werden, das da eine Art von Manager für virtuelle Geräte ist. Auf der positiven Seite steht die Tatsache, dass die virtuellen Gerätekonfigurationen so zahlreich sind, wie die des originalen Android SDK-Emulators.
Unter Umständen wollen Sie die automatischen Produktberichte zur Verbesserung des selbigen an GenyMotion deaktivieren.
Im Unterschied zu Android-x86 schaltet GenyMotion das mobile Netzwerk aus und aktiviert das virtuelle WLAN, welches das Netzwerkinterface von VirtualBox ist. Um die Proxy-Einstellungen zu konfigurieren, um einen Intercepting Proxy zu verwenden, befolgen Sie folgende einfachen Schritte:
Um mit adb zu verbinden sind keine weiteren Schritte notwendig. GenyMotion verbindet automatisch mit adb.
GenyMotion ist eine solide Lösung zur Android-Emulation. Besonders interessant ist die Auswahl an virtuellen Geräten und Betriebssystemen. Wenn GenyMotion geschäftlich genutzt wird, dann ist eine Gebühr von 99 Euro pro User und Jahr fällig. Der Emulator ist schnell und responsiv. Das Interface erlaubt die Kontrolle von mehreren Hardware-Elementen ohne weitere Umschweife.
Android SDK wird direkt mit einem Emulator ausgeliefert. Er ist Teil der Android SDK-Installation und es wird für jede neue Android-Version ein neues Emulator-Image geben. Mit der kommenden Version (Android L) inklusive stehen vier Systeme zum Download bereit.
* Normale Geräte wie Smartphone oder Tablet
Ein virtuelles Gerät wird mit AVD Manager erstellt. Das GUI erlaubt die Konfiguration von mehr als nur gerade dem Gerät und der verwendeten Android-Version, genau wie es GenyMotion tut.
Nach der Erstellung eines virtuellen Geräts kann dieses direkt aus dem AVD Manager gestartet werden. Der Command Line Emulator, der sich im Verzeichnis PATH-TO-SDK\tools
befindet, bietet viele Optionen, das Verhalten und die Ausführung der virtuellen Maschine zu beeinflussen. Zum Beispiel, wenn wir einen Intercepting Proxy nutzen wollen, dann ist die Option -http-proxy
die Funktion, die einen Proxyserver für das virtuelle mobile Netzwerk konfiguriert.
Folgender Befehl startet ein virtuelles gerät und schaltet auch gleich den Proxy ein.
.\emulator.exe -avd VIRTUAL-DEVICE-NAME -http-proxy http://PROXY-IP:PROXY-PORT
Wenn der Proxy während des Aufstartens des virtuellen Geräts nicht erreichbar ist, dann wird dieser ignoriert.
Der Android SDK Emulator hat den Ruf, sehr langsam und schwerfällig zu sein. Aber keine Panik, mit einigen kleinen Anpassungen kann die Performance verbessert werden. Bei der Erstellung des virtuellen Geräts müssen einfach folgende Schritte beachtet werden:
Auch wenn die Emulation von der GPU unterstützt wird, ist das virtuelle Gerät etwas langsamer als es mit den anderen Emulatoren ist. Ein Vorteil ist aber, dass die Images der neuen Version zum Release Date frei erhältlich sein werden.
Welche der Option in diesem Artikel jetzt die allgemein gültig beste Option ist, kann in dieser Form nicht beantwortet werden. Denn sie hängt zu grossen Teilen davon ab, welche Anforderungen an das Lab gestellt werden. Jede der drei Optionen hat Vor- wie auch Nachteile. Die Nutzung des original SDK Emulators ist sicher hilfreich, wenn es darum geht, mit den neuesten Android-Versionen zu arbeiten und die Performanceprobleme keine allzu grosse Rolle spielen. Zudem ist der Emulator sicher keine schlechte Lösung, wenn Command Line Switches wie -http-proxy
benötigt werden.
Die anderen beiden Lösungen folgen einem anderen Ansatz und sind einfacher miteinander zu vergleichen. Android-x86 ist eine gute Option, sollt die neueste Android-Version nicht zwingend nötig sein und wenn das virtuelle Gerät in einer flexibleren und anpassbaren Umgebung funktionieren muss. Die Lösung ist zudem gratis, genau wie der Android SDK Emulator.
GenyMotion ist ein geschlossenes Produkt. Es kommt mit einer eigenen Lösung zum Virtual Device Management, einer eigenen Shell, die alle nötigen Schritte für den Developer – oder auch den Penetration Tester – übernimmt, um sofort loslegen zu können. GenyMotion fühlt sich besser in der Handhabung an und das User Interface erlaubt das Tweaken von vielen Hardware-Optionen. Dies ist wahrscheinlich für Entwickler wichtig, aber könnte auch Application Testern zugutekommen.
Nach der Produktwahl kommt der Moment, an dem die Developer Ihrer Zielapplikation hoffentlich SSL-verschlüsseltes HTTP verwenden. Um dem Rechnung zu tragen, kann ein Burp CA Zertifikat installiert werden.
Diese einfache Aufgabe kann ganz schnell ganz schwer werden, wenn Ihnen bewusst wird, dass der Burp Proxy entweder über HTTP oder via http://PROXY-IP:PROXY-PORT/cert eine Datei namens cacert.der
exportiert, Android aber eine .crt
-Datei erwartet.
Um Burps CA Zertifikat zu installieren, können Sie diese Schritte befolgen:
adb push PATH-TO-CA-CERT.DER /mnt/sdcard/CA-CERT.CRT
(beachten Sie die neue Dateiendung .crt)Dieser Vorgang funktioniert für fast alle Setups. Die grosse Ausnahme ist der SDK-Emulator für Android 4.4.2. Der Menüeintrag Install from SD Card öffnet einen Dateibrowser – genau wie bei anderen Versionen – aber dieser zeigt nicht die emulierte interne SD-Karte an.
Um das Zertifikat auf Android 4.4.2. SDK emulierten Geräten zu installieren, folgen Sie den ersten vier Schritten, die oben genannt werden. Dann laden Sie die Datei auf einen – im Idealfall internen und lediglich zu Testzwecken genutzten – Webserver und laden Sie im Webbrowser des virtuellen Geräts die Datei. Android wird diese als Zertifikat erkennen und die Installation beginnen.
Dieser Prozess wäre wesentlich einfacher, wenn entweder Android nicht nur .crt
-Dateien ausfiltern würde oder Burp Proxy die Definition des Dateinamens für den Zugriff mit dem Browser via http://PROXY-IP:PROXY-PORT/cert
erlauben würde.
Die Android Debug Bridge bietet ein breites Spektrum an Funktionen und ein gutes wie auch wertvolles Tool. Und ungeachtet des Systems, auf dem Ihr Android Lab aufgebaut ist, Sie werden mit adb Ihre eigenen Scripts bauen können.
Die Installation einer Applikation verändert das System. Die Details dieser Veränderung können während einer Analyse von grossem Wert sein. Daher wäre ein Script, das folgende Befehle ausführt, passend:
adb shell touch /mnt/sdcard/test adb install PATH-TO-APK adb shell find / -type f -newer /mnt/sdcard/test > fs-change-install.log adb shell rm /mnt/sdcard/test
fs-change-install.log
enthält eine grosse Menge an Informationen, die aus dem regulären Betrieb stammen. Daher sind alle Einträge, die mit /proc
beginnen zu vernachlässigen, damit ersichtlich ist, was sich wirklich verändert hat. Wenn Sie einen Befehl finden, der nur in /data
läuft, dann stehen die Chancen gut, dass einige Veränderungen nicht in fs-change-install.log
aufgeführt werden.
Wie auch bei einer Installation wird bei einer Deinstallation das Filesystem verändert. Und ebenso kann diese Veränderung von grossem Interesse sein, weswegen auch hier ein Script wie das Folgende zum Tragen kommen kann.
adb shell touch /mnt/sdcard/test adb uninstall PACKAGENAME adb shell find / -type f -newer /mnt/sdcard/test > fs-change-uninstall.log adb shell rm /mnt/sdcard/test
Es gibt eine Vielzahl von weiteren kleinen Tweaks, die das Arbeiten mit adb im Alltag wesentlich vereinfachen. Alles, was Sie dazu brauchen, sind die Tools, die mit dem SDK geliefert werden und Scripting Skills.
Daher konzentriert sich dieser letzte Teil des Artikels auf die Kenntnis der Tools, die vom SDK bereitgestellt werden, deren Nützlichkeit und Hilfestellung im Rahmen der Applikationsanalyse.
Dieses ausserordentlich hilfreiche Tool befindet sich im Ordner PATH-TO-SDK/tools
und heisst monitor.bat
. Unter anderem informiert das Script über die aktuell laufenden virtuellen Geräte, die laufenden Pakete, Heap, Allocation Tracker, Dateiexplorer und eine rollende Ansicht des Logs des Geräts.
Die untenstehende Tabelle zeigt nützliche Befehle für Analysten auf, um mit adb einen guten, soliden und schnellen Start zu finden.
Beschreibung | Befehl |
---|---|
Output einer Liste aller installierten Pakete, inclusive deren Pfad | adb shell pm list packages -f |
Ein Paket aus dem System ziehen | adb pull -p PATH-TO-PACKAGE |
Backup der Application Data. | adb backup -f BACKUP-NAME PACKAGE |
Beliebige Datei auf das Gerät pushen | adb push FILENAME DESTINATION-PATH |
Beliebig Datei vom System ziehen | adb pull -p FILE-PATH |
Emulator für spezifisches virtuelles Gerät starten | .\explorer.exe -avd VIRTUAL-DEVICE-NAME |
Bugreport generieren | adb bugreport |
Es gibt mehrere Wege, ein rein physisches Android Lab mit virtuellen Geräten auszubauen – oder ein solches Lab von Grund auf aufzubauen. Es lohnt sich, einen Schritt zurückzutreten und die Anforderungen an die Testumgebung nüchtern und analytisch zu betrachten. Es gibt gute, kostenlose Möglichkeiten, aber es könnte sich sogar lohnen, in eine andere Plattform zu investieren. In fast jedem Fall dürfte es so sein, dass die Lizenzkosten tiefer sind, als die Kosten eines neuen physischen Gerätes. Zudem wird die neueste Android-Version stets als Image vorhanden sein, womit sich das Warten auf das Update erübrigt.
Die Tools, die das Android SDK bereitstellt, sind einen guten Augenschein wert. Die Command-Line-basierte Ausführung von adb bietet eine Vielzahl Möglichkeiten, damit ihre Nutzer eigene Tools bauen können, die genau auf den Prozess im Arbeitsalltag passen.
Unsere Spezialisten kontaktieren Sie gern!
Andrea Covello
Michèle Trebo
Lucie Hoffmann
Yann Santschi
Unsere Spezialisten kontaktieren Sie gern!