© Iaroslav Neliubov, 123RF.com

Ganz egal, wie haarsträubend unsicher Android und Konsorten sich präsentieren, im Unternehmen führt an “Bring your own device” kein Weg mehr vorbei, auch wenn das Sicherheit und Compliance-Ansätze untergräbt. Dieser Artikel zeigt, wie Admins mit Bordmitteln ein wenig Kontrolle zurückgewinnen.

Admins und Security-Experten verlören mehr und mehr die Kontrolle, darin waren sich die Sprecher der Susecon-Keynotes Anfang November in Orlando weitgehend einig (Videos auf der DELUG-DVD, [1]). Suses CEO Nils Brauckmann sprach das Problem als Erster an, und sowohl bei IBM, SAP wie auch bei Cisco ist man sich der Dramatik bewusst.

Dazu komme, so die CEOs und Vizepräsidenten weiter, ein Bedeutungsverlust, den die IT im Unternehmen erleide. Mangels IT-Verständnis erzwingen mehr und mehr Vorstandsetagen Einsparungen, neue Management-Tools und mehr Cloudlösungen. Großen Anteil an dem desaströsen Paradigmenwechsel habe in weiten Teilen die Flut von unsicheren Geräten, die im Zuge von BYOD in die Firmen gelange und dazu führe, dass fortan auch das LAN als unsicheres Terrain gilt [2].

BYOD zerstört Sicherheitskonzepte

Neben der Notwendigkeit, neue Sicherheitskonzepte und Architekturen (Deep Packet Inspection, Software Defined Networking, … ) einzuführen, bleibt jedoch das Problem: Die Mehrzahl der Endgeräte ist unsicher [3]. Weil Google bei Android die grundlegenden Sicherheitskonzepte der Unix- und Linux-Welt ignorierte, bleibt dem Admin nur, sich abzufinden und das Beste daraus zu machen. Wer genug Geld hat und die Macht, seinen Anwendern Vorschriften zu machen, greift zu teuren Cryptophones oder zu den vielen Angeboten an Mobile-Device-Management-Software.

Ein Admin jedoch, der auch letzteren nicht traut, aber Zugriff auf die mobilen Androiden seiner Mitarbeiter hat, kann auch mit Linux und dem Einverständnis der Mitarbeiter einiges unternehmen, um die Situation zu verbessern, ganz ohne teure MDM-Software anzuschaffen.

Dieser Artikel zeigt, wie sich Tools aus dem Android-SDK [4] nutzen lassen, um Informationen über den Zustand des Geräts abzurufen. Er benennt Apps, die bei der Analyse hilfreich sein können, und erläutert, wie der Admin Geräte in einen sicheren Grundzustand zurückzuversetzt – inklusive Backup der Benutzerdaten und Flashen eines Bootloaders.

Wer das beherrscht, traut sich vielleicht auch zu, ein kompromittiertes Handy auszuwerten, und schreckt dafür nicht vor dem Kernel- und Cross-Kompilieren zurück, um einen Memorydump von Androiden zu ziehen.

Am Anfang steht das Rooten des Androiden

Weil Google die gängige Linux-Architektur umgeworfen hat, braucht, wer auf einem Android-Endgerät ein wenig mehr machen will als das, was der Datenkrake erlaubt, Rootrechte. Die sind nicht immer leicht zu erwerben, am einfachsten gelingt das Rooten in der Regel mit Geräten von kooperativen Herstellern. Dazu gehört Google mit den Nexus-Geräten, aber auch Samsungs Galaxys und Sony oder HTC spielen meist gut mit.

Achtung: Wer das (wie fast alles in diesem Artikel) auf einem fremden Gerät, also zum Beispiel dem eines Mitarbeiters, machen will, braucht dessen schriftliche Einwilligung. Details zu den heiklen rechtlichen Rahmenbedingungen von BYOD bietet der Rechtsartikel in dieser Linux-Magazin-Ausgabe. Der folgende Text geht davon aus, dass der Admin die Zustimmung des Mitarbeiters eingeholt oder Geräte vor sich hat, die er den Mitarbeitern an die Hand geben kann. Das ist zwar nicht unbedingt echtes BYOD, die Probleme bleiben aber dank der Android-Schwächen gleich.

Superuser-Apps

Die Wege zum Rootzugriff sind so vielfältig, dass sich keine allgemeingültige Anleitung geben lässt – hier hilft nur die zum jeweiligen Gerät passende Recherche in den Entwicklerforen oder einschlägigen Webseiten von den XDA-Developers bis zu Android User und Androidpit. Wer das geschafft hat, etwa mit Apps wie Superuser [5], dem steht eine ganze Reihe an Apps zur Verfügung, die Google nicht gerne sieht und die deutlich erweiterte Funktionen bringen.

Diese rangieren von einen Proxy für den Browser definieren über einen Adblocker einrichten, Traffic sniffen, die Default-Route oder den DNS-Server auf einen sicheren Weg einstellen bis hin zu vielfältigen Einstellungen, die auf Desktop-PCs nur mit hohem Aufwand umsetzbar wären, beispielsweise individuelle Firewallregeln für jede App.

Nicht unerwähnt darf bleiben, dass sich Sicherheitsexperten nicht einig sind, ob man seinen Androiden rooten soll oder nicht. Die Autoren dieses Artikels teilen das Argument der Waffengleichheit: Ein Angreifer könnte es jederzeit über Exploits mit Malware rooten – warum soll der Besitzer darauf verzichten? Außerdem überzeugen die Features, die das Rooten mitbringt, den erfahrenen Linux-Anwender schnell.

Sniffen, loggen, sichern

Mit Apps wie dem Netzwerk Log [6] protokollieren Smartphones auch über längere Zeiträume hinweg den Netzwerktraffic, den das Gerät verursacht. Gefiltert oder in anschauliche Graphen verpackt (siehe Abbildung 1) erlangen Admins und Anwender so den Überblick, welche App wie viel Datenübertragung verursacht.

Abbildung 1: Nur eine praktischen Monitoring-App unter vielen: Netzwerk Log snifft auf gerooteten Androiden (hier ein Nexus 7) den Netzwerktraffic und baut anschauliche Statistiken.

Eine Taschenlampen-App beispielsweise, die regelmäßig Daten überträgt, fiele dem aufmerksamen Anwender spätestens hier negativ auf. Malware oder Einbrecher, die unbemerkt größere Datenmengen übertragen wollen, müssten darauf vorbereitet sein oder den TCP-Stack verändern, um unentdeckt zu bleiben. Auch lassen sich hier einzelne Anwendungen überwachen, Filter setzen und vieles mehr. Überraschenderweise hält sich die Akkubelastung bei aktiviertem Logging durchaus in Grenzen.

Solche nützlichen Tools gibt es massenhaft in Googles Play-Store oder alternativen App-Stores. Scheinbar genauso viele Webseiten bieten Top-Ten-, Top-20- oder gar Top-30-Listen der besten Root-Apps an. Den Autoren dieses Artikels fielen Tuningtools wie der Android Tuner, der Cron-Ersatz Tasker, Adblock Plus, der Pentester Zanti oder das Wifi-Inspect-Tool mit PCAP-Sniffer namens Wifinspect besonders positiv auf. Ebenso gelungen scheint die Applikationsfirewall AFWall+ (Abbildung 2, [7]), die anwendungsspezifischen Internetzugriff ermöglicht. Der Besitzer des Smartphones kann so einfach einzelnen Apps verbieten, etwa über GSM-Netze eine Verbindung aufzubauen, sondern dies explizit aufs WLAN beschränken.

Abbildung 2: Die Firewall-App AFWall+ konfiguriert, wer wann über welche Medien Verbindungen aufbauen darf.

Eine mindestens genauso große Anzahl an Backup- und Restore-Tools erlaubt die Sicherung von Apps und ihren Daten vom Android-GUI aus, als ein Beispiel genannt sei das beliebte Titanium Backup [8]. Mehr Apps für Admins nennt ein Artikel im Linux-Magazin 12/13 [9]. Was viele Admins und Besitzer der Smartphones nicht wissen: Vieles geht auch von der Linux- oder Android-Konsole aus.

Adb: Android Debug Bridge

Im Android-SDK [4], mit dem sich auch schon der Artikel [10] beschäftigt, ist die Android Debug Bridge enthalten. Das kleine Werkzeug stellt zusammen mit dem gleichnamigen Daemon eine Terminalverbindung zu einem über USB angeschlossenen Smartphone her (Listing 1). Dabei kennt sowohl das kleine Werkzeug »adb« wie auch die Android-Shell selbst diverse hilfreiche Kommandos, mit denen der Admin das Gerät überwachen, auslesen, sichern und in einen vordefinierten Zustand zurückversetzen kann.

01 [mfeilner@pc]# adb devices
02 List of devices attached
03
04 [mfeilner@pc]# su
05 Passwort:
06 [root@pc]# killall adb
07 [...]
08 [root@pc]# adb devices
09 * daemon not running. starting it now on port 5037 *
10 * daemon started successfully *
11 List of devices attached
12 015d8bed0d3c0814        device

Wer die Befehle aus dem SDK häufiger benutzt, fügt dessen Pfad am besten mit »PATH= $PATH:/home/mfeilner/bin/adt-bundle-linux-x86_64 -20130917/sdk/platform-tools/« zu seinem Linux-Pfad hinzu, idealerweise über die Startdateien der Shell. Wer das SDK mehreren Usern zur Verfügung stellen will, entpackt es am besten nach »/opt« .

Listing 1 zeigt, dass bisweilen Rootrechte notwendig sind, um an USB angeschlossene Androiden zu erkennen. Damit das klappt, muss Root den eventuell vom Anwender gestarteten Adb-Daemon killen, erst dann taucht das Smartphone auf. (Aus diesem Grund funktioniert der Befehl erst in Zeile 8 von Listing 1.) Nach einer Bestätigung auf dem Android-Display wechselt der Status in Zeile 12 von »unauthorized« auf »device« . Listing 2 zeigt erste Informationen aus dem Nexus 7.

01 [root@pc]# adb shell
02 shell@android:/ $ uname -a
03 Linux localhost 3.1.10-gd08812a #1 SMP PREEMPT Wed Sep 4 19:55:23 PDT 2013 armv7l GNU/Linux
04 shell@android:/ $ cat /proc/version
05 Linux version 3.1.10-gd08812a (build03@cyanogenmod) (gcc version 4.6.x-google 20120106 (prerelease) (GCC) ) #1 SMP PREEMPT Wed Sep 4 19:55:23 PDT 2013
06 shell@android:/ $ free
07   total  used  free  shared  buffers
08 Mem:  997720  880472  117248  0  12320
09 -/+ buffers:  868152  129568
10 Swap:   0  0  0
11 shell@android:/ $ cat /proc/cpuinfo
12 Processor       : ARMv7 Processor rev 9 (v7l)
13 processor       : 0
14 BogoMIPS        : 1993.93
15 processor       : 1
16 BogoMIPS        : 1993.93
17 processor       : 2
18 BogoMIPS        : 1993.93
19 processor       : 3
20 BogoMIPS        : 1993.93
21 Features        : swp half thumb fastmult vfp edsp neon vfpv3 tls
22 CPU implementer : 0x41
23 CPU architecture: 7
24 CPU variant     : 0x2
25 CPU part        : 0xc09
26 CPU revision    : 9
27 Hardware        : grouper
28 Revision        : 0000
29 Serial          : 0f410a0001440200

USB-Debugging

Der ganze Prozess klappt nur, wenn auf dem Androiden »USB-Debugging« aktiviert ist und der Android-Anwender den Bestätigungsdialog für den jeweiligen PC mit dem Tippen auf »Ok« akzeptiert hat – ein Optionsfeld erlaubt es, einzelne Maschinen immer sofort und ohne Nachfrage zu verbinden.

USB-Debugging schaltet er übrigens in neueren Android-Versionen über 7-faches Antippen des Eintrags »Einstellungen | Über das Telefon/Tablet | Buildnummer« ein. Ab dem vierten Tippen zählt ein Pop-up hoch, danach findet sich ein neuer Eintrag in den Einstellungen, wo der Besitzer USB-Debugging aktivieren kann. Erst dann funktioniert das im Folgenden Beschriebene mit der Adb, Fastboot und das Flashen von eigenen Roms.

Logcat und Dumpsys

Mehr hilfreiche Informationen über das System bieten Befehle wie »adb logcat« (Abbildung 3), der den Fifo-Puffer des Androiden anzeigt – eine durchaus interessante Quelle für Informationen, aus der sich gelegentlich auch Hacker bedienen konnten, wie ein Artikel im Linux-Magazin [3] erläuterte. Ähnlich hilfreich sind »dumpsys« oder »bugreport« an der Adb-Shell oder der interaktive Aufruf mit »adb bugreport > /tmp/bugreport« , der einen kompletten Auszug der Konfiguration des laufenden Systems ausgibt. Abbildung 4 zeigt am Beispiel von More, wie sich Dumpsys auch mit klassischen Unix-Tools nutzen lässt, um per Pipe oder Ausgabe-Umleitung in eine Datei die Lesbarkeit zu erhöhen.

Abbildung 3: »adb logcat« gibt das Systemprotokoll aus, hier beim Display-Entsperren und Backupversuch.

Abbildung 4: »dumpsys | more« listet zunächst die Prozessliste des laufenden Systems auf.

Auf dem Tablet läuft Cyanogenmod 10.1.3, das dem Anwender und Admin in vielen Fällen deutlich mehr Möglichkeiten für die Konfiguration bietet, gleich als gerootetes System daherkommt und in neueren Versionen auch den wichtigen Remote-Wipe-Button im Webinterface mitbringt (Abbildung 5).

Abbildung 5: Wer das Angebot von Cyanogenmod ab Version 10.2 nutzt und sich einen Account beschafft, wird unter anderem mit einer Remote-Wipe-Funktion belohnt.

Immer ein Backup erstellen vor dem Flashen

Bevor er so ein alternatives, meist deutlich aktuelleres, schnelleres und sichereres Image auf das Tablet oder Smartphone spielt, sollte der Admin jedoch ein Backup machen. Wie angedeutet gelingt das auch problemlos von der Kommandozeile. Adb beherrscht nicht nur den Shell-Modus, sondern lässt sich auch interaktiv mit Optionen wie Push und Pull für den Filetransfer, aber auch mit »backup« und »restore« als Sicherungsinstrument einsetzen. »adb backup Datei« schreibt alle Userdaten in eine Datei, analog stellt »adb restore Datei« den vorherigen Zustand wieder her. Achtung: So eine Datei kann schnell mehrere Gigabyte groß werden, das Erstellen dauert.

Dennoch vermag das Backup and Restore dem Admin viel Zeit und Nerven zu ersparen, vor allem im Vergleich zum kompletten Neueinrichten eines Androiden samt eventueller Recherche für Logindaten oder Konfigurationsdetails. Mit dem Full Restore ist es ein Leichtes, einen definierten, sicheren Ausgangszustand wieder einzuspielen.

Wie beim ersten Mal

Dagegen ist es meist wenig sinnvoll, ein defektes oder kompromittiertes System wiederherzustellen. Wer aber eine Analyse durchführen muss, kann ein beschädigtes System samt Einbruchsspuren bei Bedarf in einer virtuellen Android-Umgebung in Ruhe analysieren, auch dafür bringt das SDK Tools mit. Ein Blick auf die Backup-Optionen mit »adb help« erläutert, wie sich beispielsweise von mehreren Anwendern genutzte Androiden (mit Shared-Bereich) sichern und wiederherstellen lassen.

Um den Androiden in einen halbwegs sicheren Ausgangszustand zu versetzen, der gleichzeitig frei von Bloat- und Spyware der diversen Herstellerbrandings ist, empfiehlt sich die Installation eines freien Image. Dafür braucht der Admin im Beispiel mit einem Nexus-7-Tablet (das 2013er Modell für knapp 200 Euro) drei passende Dateien und ein weiteres Tool aus dem SDK: Fastboot.

Fastboot, Flashen und Recovery-Images

Listing 3 zeigt im Schnelldurchlauf, wie er das Gerät mit dem freien und schlanken Cyanogenmod 10.2 flasht. Das geht auch ohne Windows und den schicken, eigens dafür geschriebenen Installer: Zunächst schiebt der Linuxer das von der Cyanogenmod-Webseite [11] heruntergeladene Image mit »adb push« aufs Smartphone, anschließend die grundlegenden Google-Apps (wie den Play-Store), die im Image nicht enthalten sind. Zum Entsperren des Bootloaders (»fastboot oem unlock« ) und zum Flashen eines Recovery-Systems (»fastboot flash recovery Datei« ) dient Fastboot, dessen Optionen auch im Listing enthalten sind.

01 [root@pc]# adb push cm-10.2-grouper.zip /sdcard/Download/cm.zip
02 [root@pc]# adb push gapps-jb-20130301-signed.zip /sdcard/Download/gapps.zip
03 [root@pc]# fastboot --help
04 usage: fastboot [ <option> ] <command>
05
06 commands:
07   update <filename>                reflash device from update.zip
08   flashall                         flash boot + recovery + system
09   flash <partition> [ <filename> ] write a file to a flash partition
10   erase <partition>                erase a flash partition
11   format <partition>               format a flash partition
12   getvar <variable>                display a bootloader variable
13   boot <kernel> [ <ramdisk> ]      download and boot kernel
14   flash:raw boot <kernel> [ <ramdisk> ]  create bootimage and flash it
15   devices                          list all connected devices
16   continue                         continue with autoboot
17   reboot                           reboot device normally
18   reboot-bootloader                reboot device into bootloader
19   help                             show this help message
20 options:
21   -w                  erase userdata and cache (and format if supported by partition type)
22   -u                  do not first erase partition before formatting
23   -s <specific device>  specify device serial number or path to device port
24   -l                  with "devices", lists device paths
25   -p <product>        specify product name
26   -c <cmdline>        override kernel commandline
27   -i <vendor id>      specify a custom USB vendor id
28   -b <base_addr>      specify a custom kernel base address. default: 0x10000000
29   -n <page size>      specify the nand page size. default: 2048
30   -S <size>[K|M|G]    automatically sparse files greater than size.  0 to disable
31
32 [root@pc]# fastboot oem unlock
33 [root@pc]# fastboot flash recovery recovery-clockwork-touch-6.0.2.3-grouper.img
34 [root@pc]# adb reboot bootloader
35 [...]

Hat alles geklappt, bootet »adb reboot« das Android-Gerät im jungfräulichen Zustand. Wer sich das Pushen von Dateien sparen will, schaut sich die Adb-Option »sideload« an, mit der er direkt vom PC aus Dateien auf das Gerät laden kann. Auch für Fastboot gilt: Oft sind Rootrechte auf dem PC notwendig, ob das Tool das Gerät findet, kann der Anwender mit »fastboot devices« überprüfen. Nur weil »adb devices« funktioniert, heißt das nicht immer, dass auch Fastboot das Gerät erkennt.

Androiden von Linux aus rebooten

Nach dem Android-Reboot gilt es, am Smartphone oder Tablet die vorher daraufgeschobenen Images auszuwählen und zu booten. Viele Geräte verlangen vorher noch einen Wipe der Partitionen und Caches – der Recovery-Modus bietet für all das Menü-Einträge, die sich mit den Lauter-/Leiser- sowie Ein-/Aus-Tasten auswählen lassen. Sodann startet die Initialisierung des Android-Betriebssystems. Spätestens jetzt sind alle vorher auf dem Gerät befindlichen Daten gelöscht. Wer jetzt nach Abschluss der Konfiguration sein Backup wieder einspielt, hat den gewünschten – hoffentlich sichereren – Ausgangszustand zurück.

Tiefenanalyse

Im schlimmsten Fall hat der Admin ein Android-Gerät vor sich, das vermutlich kompromittiert ist oder zumindest durch auffälliges Verhalten Anlass zu der Vermutung gab. Wer derlei Anzeichen mit den oben beschriebenen Tools festgestellt hat, will – neben dem Zurücksetzen auf einen sicheren Ausgangszustand – sicherlich auch mehr Details darüber herausfinden, wer, wie und wann das Tablet infiziert hat. Auch für Android helfen die gängigen Linux-Tools wie Sleuthkit [12] weiter.

Jedes Betriebssystem legt seine Konfigurationsdetails in einer typischen Form ab, Linux nutzt lesbare Konfigurationsdateien, Windows die Registry, Android überwiegend SQlite-Datenbanken. Die sind auch bei vielen Desktopprogrammen beliebt, etwa bei Firefox. Es spielt dabei keine Rolle, ob Firefox unter Windows, Linux oder OS X läuft, die History liegt immer in »places.sqlite« , lediglich der Speicherort variiert. Googles Android-Browser speichert seine History in einer Datei namens »browser.db« .

SQlite unter der Lupe in GUI und Befehlszeile

Wer solche Datenbanken analysieren will, um zum Beispiel eine Historie der vergangenen Webaktionen zu erhalten, muss diese bei Androiden erst einmal aus dem Gerät herauslocken. Um das zu testen und zu lernen, bieten sich die Virtualisierungsfunktionen des Android-SDK an – hier kann der Admin in Seelenruhe in laufenden Systemen herumpfuschen, ohne etwas zu zerstören. Doch muss er selbst für Inhalte sorgen, etwa per Adb-Push- und Adb-Pull-Befehl. Schneller geht es meist, gleich im Internet nach existierenden Images mit vorkonfigurierten Daten zu suchen. Übungsimages gibt es viele, die amerikanische Forensikfirma Viaforensics etwa bietet diverse Images zum kostenlosen Download an [13].

Ein Yaffs-Nandump-Image und Sleuthkit

Als Beispiel dient im Folgendem das Abbild »yaffs2-nexus-one-postpopulation.nanddump« . Dessen Dateinamens-Erweiterung Nandump weist auf das Dateisystem Yaffs hin, das bereits im Artikel [10] reichlich Probleme bereitete und das nur wenige Programmen auslesen können. Für Linux gibt es mittlerweile Treiber aus dem Yaffs-Projekt [14].

Auch wenn sich diese Treiber zur Laufzeit dem Auswertesystem hinzufügen lassen, erscheint es deutlich eleganter, die Erweiterungen von Sleuthkit 4.1 zu nutzen. Sie bringen erstmals direkten Support für Yaffs und Ext 4 mit. Weil zu Redaktionsschluss die meisten Repositories aber noch auf alte Versionen von Sleuthkit setzen, muss der analysewillige Admin dies aus den Quellen bauen. Den Erfolg zeigt Listing 4 mit vier Befehlen aus dem Sleuthkit.

01  [root@pc]# fls -V
02 The Sleuth Kit ver 4.1.0
03
04 [root@pc]# fls -f list
05 Supported file system types:
06         ntfs (NTFS)
07         fat (FAT (Auto Detection))
08         ext (ExtX (Auto Detection))
09         iso9660 (ISO9660 CD)
10         hfs (HFS+)
11         ufs (UFS (Auto Detection))
12         raw (Raw Data)
13         swap (Swap Space)
14         fat12 (FAT12)
15         fat16 (FAT16)
16         fat32 (FAT32)
17         ext2 (Ext2)
18         ext3 (Ext3)
19         ext4 (Ext4)
20         ufs1 (UFS1)
21         ufs2 (UFS2)
22         yaffs2 (YAFFS2)
23
24 [root@pc]# fls yaffs2-nexus-one-postpopulation.nanddump
25 d/d 2:          lost+found
26 d/d 261:        dontpanic
27 d/d 262:        misc
28 d/d 268:        local
29 d/d 270:        data
30 d/d 271:        app-private
31 d/d 272:        app
32 d/d 273:        property
33 d/d 274:        dalvik-cache
34 d/d 291:        anr
35 d/d 292:        system
36 d/d 394:        backup
37 d/d 3:          <unlinked>
38 d/d 4:          <deleted>
39 d/d 61867264:   $OrphanFiles
40 [...]
41
42 [root@pc]#  fls -r yaffs2-nexus-one-postpopulation.nanddump | grep browser.db
43 +++ r/r * 1573464:  browser.db-journal#600,6
44 +++ r/r * 3670621:  browser.db-journal#605,14
45 +++ r/r * 3408487:  browser.db-journal#615,13
46 +++ r/r 656:        browser.db
47 +++ r/r * 8913552:  browser.db#656,34
48 +++ r/r * 8651408:  browser.db#656,33
49 [...]

Mit diesem Ergebnis kann die Auswertung beginnen. Das im Listing verwendete Sleuthkit ist Version 4.1.0 (mittlerweile wäre sogar 4.12 verfügbar), es unterstützt Yaffs, das Dateisystem ist lesbar und der Spürhund kann darin Verzeichnisse und Dateien finden.

Exemplarisch sucht der Admin gleich die History des Android-Browsers und rekonstruiert sie. Die gesuchte Datei ist »browser.db« mit dem Inode 656. Dies Suchergebnis fehlte im Listing 4 noch, weil dort diese Suche noch nicht rekursiv erfolgte. Interessant ist, dass sich hier auch alte Versionen (die Journals) der Datei finden.

Wear Levelling erzeugt Journaldateien

Das liegt am schonenden Wear Leveling [15], wobei der Flashspeicher unter Yaffs speicherzellenschonend die Schreibzugriffe gleichmäßig zu verteilen sucht. Das freut den Forensiker, kann er doch gleich mehrere Dateien auswerten, auch wenn der User die History eventuell gelöscht oder bereinigt hat. Er extrahiert dazu die »Browser.db« mit dem »icat« -Kommando samt Meta-Informationen aus dem Image und betrachtet sie mit dem grafischen Sqlitebrowser (Abbildung 6):

Abbildung 6: Wenn das nicht verdächtig ist: Der Anwender hat Webseiten der CIA, der Drogenfahndung DEA und Secret Services bis hin zum Weißen Haus abgerufen.

[root@pc]# icat  yaffs2-nexus-one-postpopulation.nanddump 656 > browser.de

Wie in der Abbildung zu sehen ist, liegt das Datumsfeld »Date« noch im »PRTIme« -Format vor, zusammen mit den schwer lesbaren Unix-Timestamps. Ein Awk-Skript erzeugt daraus aussagekräftige Werte:

[root@pc]# awk '{print strftime("%a, %d %b %Y.%H:%M:%S",($1/1000000-11644473600))}'

Analoge Informationen lassen sich zu fast jeder installierten Anwendung aus dem Image herauslesen, wobei auch das mit Adb erzeugte Backup oder die Push- und Pull-Befehle bereits ähnliche Analysen aus dem laufenden System zulassen. Wer das regelmäßig macht, eventuell automatisiert und inklusive per Policy vorgeschriebener Maßnahmen, hat zumindest gute Chancen, das offene Zeitfenster für Einbrecher zu verkleinern.

Wenn das noch nicht reicht, helfen Memorydump-Analysen: Auch die im Linux-Magazin vorgestellte Memorydump-Analyse des laufenden Systems mit Volatility [16] ist für Android verfügbar.

Volatility

Seit Version 2.2 steht Volatility für Linux bereit, seit der Beta 2.3.1 ist Android- und Mac-Support enthalten. Problematischer als Volatility erweist sich aber das Erstellen eines eigenen Memorydump aus einem vorliegenden Androiden. Wie bei Linux brauchen jeder Kernel und jede Android-Version angepasste Lime-Treiber, deren Konstruktion selbst hartgesottene Linux-Spezialisten vor mittelgroße Aufgaben stellen. Für ein Volatility-Beispiel gibt es Gott sei Dank Testimages, zum Beispiel bei [17].

Wer sich aus Googles Repository die Datei »Rodeo2012.tgz« (Link auf »DFRWS 2012 Rodeo« ) herunterlädt, findet darin zwei Dateien: »Evo4GRodeo.lime« und »Evo4G.zip« . Die erste ist der eigentliche, mit Lime erstellte Memorydump, bei der zweiten Datei handelt es sich um die Profildatei, die im Volatility-Projektverzeichnis nach »plugins/overlays/linux« kopiert wird. (Mehr zu den Lime-Profilen bietet der Linux-Magazin-Artikel [16].) Wenn das Profil zum Image passt, kann der Admin loslegen:

[root@pc]# vol.py --info | grep Linux
Volatile Systems Volatility Framework 2.3_beta
LinuxEvo4GARM - A Profile for Linux Evo4G ARM

Listing 5 zeigt die zum Zeitpunkt des Dump gemounteten Dateisysteme, der Befehl »linux_dentry_cache« hilft bei der Suche nach Dateien, etwa der »browser.db« , die vielleicht noch nicht auf der Festplatte gesichert ist:

01 [root@pc]# vol.py -f Evo4GRodeo.lime --profile=LinuxEvo4GARM linux_mount
02 Volatile Systems Volatility Framework 2.3_beta
03 WARNING : volatility.obj      : Overlay structure tty_struct not present in vtypes
04 tmpfs                     /app-cache  tmpfs   rw,relatime
05 tmpfs                     /mnt/obb    tmpfs   rw,relatime
06 tmpfs                     /mnt/asec   tmpfs   rw,relatime
07 /dev/block/vold/179:1     /mnt/secure/asec/.android_secure    vfat     rw,relatime,nosuid,nodev,noexec
08 /dev/block/mtdblock5      /cache      yaffs2  rw,relatime,nosuid,nodev
09 /dev/block/mtdblock6      /data       yaffs2  rw,relatime,nosuid,nodev
10 none                  /acct        cgroup rw,relatime
11 tmpfs                 /mnt/sdcard/.android_secure  tmpfs  ro,relatime
12 htcfs                 /data/htcfs  fuse   rw,relatime,nosuid,nodev
13 /dev/block/vold/179:1 /mnt/sdcard  vfat   rw,relatime,nosuid,nodev,noexec
14 none                  /dev/cpuctl  cgroup rw,relatime
15 tmpfs                 /dev         tmpfs  rw,relatime
16 devpts                /dev/pts     devpts rw,relatime
17 /dev/block/mtdblock4  /system      yaffs2 ro,relatime
18 sysfs                 /sys         sysfs  rw,relatime
19 /sys/kernel/debug     /sys/kernel/debug       debugfs    rw,relatime
20 proc                  /proc        proc   rw,relatime

[root@pc]# vol.py -f Evo4GRodeo.lime --profile=LinuxEvo4GARM linux_dentry_cache> filelist

In der Datei »filelist« liegen die Informationen aber erst im Bodyfile-Format, einem Rohdatenformat, das MACB-Time (aus dem Sleuthkit) ins lesbare MACB-Format umwandelt (»mactime -d filelist > filelist.mac« ). Abbildung 7 zeigt, wie ein »grep browser.db filelist.mac« die gewünschte Information liefert. Volatility stellt damit die Nummern der Inodes bereit, mit denen der Admin eine Datei wiederherstellen kann:

Abbildung 7: Browser-Histories aus dem Speicher des Android-Geräts. Analoge Daten gibt es für jede App.

[root@pc]# vol.py linux_find_file -F "/data/data/com.android.browser/databases/browser.db"[...][root@pc]# vol.py linux_find_file -i 0xd3aebd20 -O browser.db

Im Gegensatz zu Sleuthkit dient hier der virtuelle Inode »0xd3aebd20« zur Identifikation. Jetzt ließe sich wieder der Sqlitebrowser bemühen, doch taugt auch die Befehlszeile zur Analyse. Abbildung 8 zeigt eine erfolgreiche Operation mit »sqlite3 browser.db« und anschließendem Auflisten der enthaltenen Tabellen (».tables« ). Da zeigt sich: In der Datenbank sind offensichtlich HTC-Bookmarks enthalten. Die bringt dann ein »select * from htctopbookmarks;« zu Tage (Listing 6).

01 1|HTC|http://www.htc.com/|2|11|h|ht|htc
02 2|Google|http://www.google.com/|2|11|g|go|goo
03 3|Facebook|http://www.facebook.com/|2|11|f|fa|fac
04 4|Yahoo!|http://www.yahoo.com/|2|11|y|ya|yah
05 5|YouTube|http://www.youtube.com/|2|11|y|yo|you
06 6|Windows Live|http://www.live.com/|2|11|l|li|liv
07 7|Wikipedia|http://www.wikipedia.org/|2|11|w|wi|wik
08 8|Blogger.com|http://www.blogger.com/|2|11|b|bl|blo
09 9|Baidu.com|http://www.baidu.com/|2|11|b|ba|bai
10 [...]

Abbildung 8: Die Browser-Konfiguration aus dem Arbeitsspeicher des laufenden Systems lässt sich auch am CLI analysieren.

Das Problem Memorydump

Wer eigene Memorydumps anfertigen will, muss derzeit massiv selbst Hand anlegen, und zwar an Sourcecode, Kernel, Module und mehr. Das folgende Beispiel beschreibt die Vorgehensweise, die im Test mit Android 4.4 (Kitkat verwendet Kernel 3.4) sowie einem HTC-Gerät funktionierte. Eine anschauliche – aber nicht immer stimmige – Anleitung von Google selbst findet sich unter [18]. Voraussetzung für den Erfolg sind neben dem Android-SDK Entwicklertools und ein Crosscompiler.

Allerdings verwendet das Beispiel nicht den aus Googles Native Development Kit (NDK, [19]), sondern den auf Ubuntu vorhandenen GNU-Crosscompiler für ARM, weil der einfacher zur Kooperation zu bewegen war. Erst kurz vor Redaktionsschluss erreichten die Autoren Berichte von Mitarbeitern des Schweizer Bundesamts für Informatik und Telekommunikation, die auch mit Hilfe des NDK-Compilers Memdumps extrahieren konnten. Für Ubuntu zeigt Listing 7, wie man die Android-Kernelsourcen aus Googles Git holt.

01 [root@pc]# aptitude install gcc-arm-linux-gnueabi
02 [...]
03 [root@pc]# git clone https://android.googlesource.com/kernel/goldfish.git /opt/android-source
04 [...]
05 [root@pc]# cd /opt/android-source/
06 [root@pc]# git branch -a
07 * master
08   remotes/origin/HEAD -> origin/master
09   remotes/origin/android-goldfish-2.6.29
10   remotes/origin/android-goldfish-3.4
11   remotes/origin/linux-goldfish-3.0-wip
12   remotes/origin/master
13 [...]
14 [root@pc]# git checkout -t remotes/origin/android-goldfish-3.4 -b goldfish-3.4
15 [...]
16 [root@pc]# export ARCH=arm
17 [root@pc]# export SUBARCH=arm
18 [root@pc]# export CROSS_

Jetzt kommt der spannende Teil: Bevor der Administrator die Quellen des Kernels kompiliert, benötigt er die zum Geräte-Kernel passende »config« . Auf den meisten Devices liegt diese gezippt unter »/proc/config.gz« , andere Hersteller machen es dem Forensiker schwer, indem sie diese Datei nicht mitinstallieren, teilweise sogar aus den Quelltextarchiven entfernen. Wenn dann weder in Foren noch in installierbaren Open-Source-Mods solche Konfigurationsdateien zu finden sind, dann hilft nur das langwierige Try-and-Error-Verfahren.

Auch in jeder virtuellen Gastmaschine (die das SDK starten kann) sollte eine solche Datei liegen, in seltenen Fällen findet sie sich vielleicht im auf dem Smartphone installierten Recovery-System. Wer diese Hürde genommen hat, entpackt und editiert die Config-Datei. Normalerweise reicht es bereits aus, dabei die drei »MODULES« -Zeilen einzufügen oder zu editieren:

CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULES_UNLOAD=y
CONFIG_MODULES_FORCE_UNLOAD=y
CONFIG_BLOCK=y

Jetzt gilt es, die Datei im Quelltextverzeichnis zu speichern und Make aufzurufen. Liegt der Kernel beispielsweise in »/opt/android-source/arch/arm/boot/« , dann zieht – in diesem Verzeichnis aufgerufen – das Kommando

[root@pc]# svn checkout http://lime-forensics.googlecode.com/svn/trunk/lime-android

die Lime-Treiber für Android samt Makefile für Linux-Umgebungen herunter – und hier fangen die individuellen Probleme mit den Geräten an.

Generell muss »KDIR_GOLD := /opt/android-source« auf den richtigen Pfad verweisen, doch bereits die Optionen der »CROSS_COMPILE« -Anweisung unterscheiden sich von Gerät zu Gerät. Gemeinsam ist den Ansätzen nur, dass sie den Crosscompiler mit »ARCH=arm CROSS_COMPILE=$(CCPATH)/arm-linux -gnueabi« aufrufen.

Lime-Modul laden

Am Beispiel eines vom SDK emulierten Androiden zeigt Listing 8, wie das Lime-Modul auf das Smartphone gelangt. Sofort nachdem das Modul geladen ist (einmal nur, nicht bei jedem Start, daher Insmod anstelle von Modprobe), speichert es einen Dump auf der (virtuellen) SD-Karte, die sich mit den gewohnten Tricks herunterladen lässt – hier bietet es sich an, gleich eine Netcat-Verbindung (Nc) zu nutzen, schon weil die Datenübertragung damit schneller ist als der Umweg über die SD-Card.

01 [root@pc]# emulator -avd goldfish -kernel  /opt/android-source/arch/arm/boot/zImage -show-kernel -verbose
02 [root@pc]# adb push lime-goldfish.ko /sdcard/lime.ko
03 [root@pc]# adb shell
04 [shell@android]## insmod /sdcard/lime.ko "format=lime path=/sdcard/goldfish.lime"

Doch selbst wenn all diese Schritte geklappt haben, braucht Volatility noch die richtigen Erweiterungen. Analog zu den Linux-Kerneln im Artikel [16] muss der Admin mit Make die »system.map« und »module.dwarf« erzeugen, die als Zip-File im Profil-Verzeichnis von Volatility landen. Nach einem »zip Goldfish-3_4.zip module.dwarf /opt/android-source/System.map« findet Vol.py auch das neue Profil mit dem Namen Goldfish (Abbildung 9). Wer das geschafft und die für sein Gerät korrekten Einstellungen in den Makefiles und der Kernel-Config gewählt hat, kann jetzt mit der Analyse des Memdump loslegen. Der Befehl

Abbildung 9: Der erste Schritt ist geschafft: Volatility erkennt das Android-Profil.

vol.py -f goldfish.lime --profile=LinuxGoldfish-3_4ARM linux_mount

listet – wie oben beschrieben – auch auf Android die vorhandenen Mounts auf.

Fazit

Android ist unsicher, daran ändert auch die Addon-Software, die viele Hersteller bieten, nichts. Das Vertrauen in ein unsicheres OS können auch solche Produkte nicht stärken. Wer nicht tief in die Tasche greifen will, muss selbst Vorkehrungen treffen, um seinen Mitarbeitern und Geräten im schlimmsten Fall schnell wieder ein funktionierendes, sauberes Gerät zur Verfügung zu stellen.

Mit den richtigen Analysetools lässt sich vielleicht auch herausfinden, was als Einfallstor diente, um mit Apps wie der Firewall AFWall+ geeignete Maßnahmen zu treffen und das Tor in Zukunft zu verschließen. An der Vernunft der Mitarbeiter und gegenseitigem Vertrauen führt dennoch kein Weg vorbei.

Sicherheitsexperten, etwa auf der Securitymesse It-SA, sind sich einig: Android- und Apple-Devices im Unternehmen sind wie PCs in Internetcafés: unsicher, ständig Bedrohungen ausgesetzt, nicht kontrollierbar. Da hilft nur das regelmäßige Neuinstallieren.

Der Autor

Hans-Peter Merkel ist mit dem Schwerpunkt Datenforensik seit vielen Jahren in der Open-Source-Community aktiv. Er bildet Mitarbeiter von Strafverfolgungsbehörden in Europa, Asien und Afrika aus und engagiert sich als Gründer und Vorsitzender bei Freioss und Linux4afrika.