Foto: Markus Feilner

Filesysteme und Imageformate gibt es viele, aber nur wenige können bei der Datensuche der unkomplizierten der Afflib Konkurrenz machen. Und die Images sind die kleinsten Ihrer Art.

Träume werden wahr mit der Afflib. Das behaupten zumindest viele Forensiker. Mit dem Advanced Forensics Format ginge alles schneller, kleiner und vor allem in freier Software. Interessanterweise ist die von Simson Garfinkel [1] entwickelte Afflib ([2], [3]) tatsächlich deutlich ausgereifter als es ihr Bekanntheitsgrad vermuten läßt. Ähnlich wie Libewf [4], der Quasi-Standard in der Forensik, arbeitet auch sie mit Komprimierung und unterscheidet sich so vom üblichen DD und artverwandten Programme wie Dc3dd [5], Dcfldd [6], oder Dd_rescue [7].

Schon wieder ein neuer Standard?

Weshalb nun ein neues Forensik-Format, wenn Raw-Images mit DD, komprimierte mit Libewf oder Qcow2 (siehe den Artikel Werkzeuge fürs Image in diesem Heft) doch bereits alles abdecken? Images unter der Libewf erstellt, bedeuten ein proprietäres Format, vom Platzhirsch Encase [4] erstmalig eingeführt. Diese Form von Monokultur hat immer Grenzen.

Patentstreitigkeiten sind vorhersehbar, wie zuletzt im Fall Microsoft gegen TomTom [8]. Mit der Afflib ist dagegen eine komplette Bibliothek verfügbar, die das Beste aus beiden Welten zwischen DD und Libewf vereint und in vielen Bereichen weit übertrifft.

Entwickler Garfinkel bietet auf der Projekt-Homepage diverse Forensikwerkzeuge an. Die beiden wichtigsten Programme sind die Afflib-Bibliothek selbst, sowie das Programm Aimage. Leider hat keines der beiden Softwarepakete Einzug ins Debian-Repository gefunden. Also bleibt nur die altbekannte Kombination: »./configure && make && make install«.

Wer die Programme lediglich zu Testzwecken analysieren möchte, findet auf der Heft-DVD ein passendes Debian-Live-Image. Auf der selbstständig bootenden CD ist eine wertvolle Sammlung forensischer Werkzeuge enthalten, speziell für die Arbeit an Unix-Systemen. Im Rahmen von Ermittlungsverfahren haben Forensiker mit dieser CD in den letzten sechs Monaten Images von über 100 Root-Servern im gesamten Bundesgebiet erfolgreich erzeugt.

CD-Sammlung für unterwegs

Nicht selten stellten sie in den Serverfarmen von ISPs fest, dass die üblichen Live-CDs wie Helix oder GRML den Bootvorgang verweigern, meist wegen fehlerhaften CD-ROM-Laufwerken. Jeder Profi führt aus diesem Grund immer eine ganze Sammlung verschiedener Tools bei sich.

Die CD arbeitet komplett kommandozeilenbasiert – auf eine Grafik haben die Entwickler absichtlich verzichtet. Auch wenn Live Distributionen normalerweise kein Passwort besitzen, ist hier das Root-Password auf »linux« gesetzt, um nach dem Bootvorgang einen einsatzfähigen SSH-Dienst zu erhalten.

Auf Anfrage ist auch ein bootfähiges Debian-Live-Image für USB-Sticks verfügbar. Diese Version enthält eine komplette GUI für “Mausschubser” und hat den Autoren in vielen Fällen so manchen Ärger erspart, in denen keine oder nur defekte CD-Laufwerke vorhanden waren, und so nur der USB-Anschluss in Frage kam.

Das erste Image

Egal, ob die Programme manuell über die Sourcen installiert sind oder ob die Live-CD zum Einsatz kommt, erster Schritt ist immer das Erzeugen eines Images.

Ein Aufruf von »aimage« ohne weiteren Parameter wirft nahezu 100 Zeilen Hilfestellung aus, ideal für einen Überblick über die zahlreichen Optionen. Beim Testimage handelt es sich um einen bootfähigen USB-Stick. Die forensische Auswertestation zeigt ihn als »/dev/sda« an:

Disk /dev/sda: 1957 MB, 1957167104 bytes
255 heads, 63 sectors/track, 237 cylinders,total 3822592 sectorsUnits = sectors of 1 * 512 = 512 bytes 
Disk identifier: 0x00012177
Device  Boot  Start  End  Blocks  Id  System/dev/sda1  *  63  2184839  1092388+ 83 Linux 

Die notwendigen Parameter für Aimage lauten »aimage Infile Outfile«, für das erste Testimage also: »aimage /dev/sda debianstick.aff« Abbildung 1 zeigt die detaillierte Ausgabe. Dagegen erscheint die Erfolgsmeldung in Listing 1 eher spartanisch. Jetzt noch schnell mit »file« ausprobieren, ob Linux das Format erkennt:

debianstick.aff: data

Schade. Die Ausgabe »data« zeigt Linux immer dann an, wenn es kein anderes bekanntes Dateiformat findet.

Abbildung 1: Aimage aus der Afflib im Einsatz: Das Erstellen eines Images begleitet das Tool mit umfangreichen Details über den Fortschritt. Listing 1 zeigt die vergleichsweise spartanische Erfolgsmeldung danach.

01 Input: /dev/sda
02   Model: USB_DISK  S/N: 929FEE5C
03   Output file: debianstick.aff
04   Bytes read: 1,957,167,104
05   Bytes written: 1,187,947,079
06 
07 raw image md5:  20D2 B1AF 2A75 3A94 C774 AD0D 7D9D 5046
08 raw image sha1: 087D C817 EDEB 36E2 CB13 D512 2001 8477 5963 E912
09 raw image sha256: 7B95 6628 EAE4 6E16 A184 CA4F FECA 07C9 9A13 EC0D 4AEA 2982 D206 E73E 4962 1297
10 Free space remaining on capture drive:  36,555 MB

Affuse

Dagegen hilft mit »affuse« über Fuse, [9] das neue Image zu mounten:

affuse -o ro debianstick.aff /mnt

Die Erkenntnis, “kein Fehler ist eine Erfolgsmeldung” stellt nur eingefleischter Kommandozeilen-Freaks zufrieden. Alle anderen werden mit einem nachfolgenden »mount«-Befehl den Erfolg überprüfen:

mount affuse on /mnt type fuse.affuse (ro,nosuid,nodev) 

Wie angekündigt hat Fuse ordnungsgemäß seinen Dienst verrichtet. Die Imagedatei befindet sich nun in »/mnt«.

-r--r--r-- 1 root root 1957167104 1. Jan 1970  debianstick.aff.raw 

Auf diesem Raw-Image kann der Admin nun bereits mit Fdisk arbeiten, zum beispiel um die Bootfähigkeit des USB-Sticks zu verifizieren. Nicht wundern, die Ausgabe von »fdisk -lu« zeigt, wie auch bei Dd oder Libewf, die tatsächliche Größe des Mediums vermeintlich fehlerhaft mit 0 Bytes an.

Zeit, zu testen, ob das Abbild in einer Virtualisierung startet. Kvm erweist sich hier als Favoritt. Wenn die CPU nicht mitspielt, greift der Admin kurzerhand zu Qemu. Ein einfaches »kvm debianstick.aff.raw« startet den gesicherten USB-Stick. Das komprimierte Image ist auch über Affuse direkt bootfähig (Abbildung 2).

Abbildung 2: Schaut nach wenig aus, hat es aber in sich: Das hier bootende Debian-system liegt in einem komprimierten Image auf der Festplatte vor, dass mit Affuse über Fuse gemountet ist. Entpacken ist unnötig.

Mit einem USB-Stick lassen sich schnelle Ergebnisse zeigen, aber die Dateigrößen aus dem Beispiel entsprechen normalerweise nicht der Realität der Ermittler. Die sehen sich typischerweise Festplatten um 500 GByte gegenüber, meist im Raid, allerdings auch fast immer nur mit wenigen Gigabyte belegt. Auf einem Hardware-Raid-1-System mit zwei 500-GByte-Festplatten, macht Afflib ein Image File von 50 GByte. Raw-Images bräuchten zweimal 500 GByte.

Sowohl Libewf als auch Afflib setzen standardmäßig auf die Zlib-Komprimierung [10]. Afflib unterstützt auch den LZMA-Algorithmus [11], der zwar bedeutend langsamer ist, aber dafür deutlich bessere Komprimierungsraten erreicht.

Wer LZMA anstelle von Zlib nutzen will, muss Aimage den Parameter »-L« übergeben: »aimage -L /dev/sda debianstick.aff«.

Halb so große Images

Um den Vorsprung zu demonstrieren, haben die Linux-Magazin-Autoren zwei MySQL-Systeme mit verdächtigen Daten installiert. Einem FreeBSD mit LAMP auf einer 8,4 GByte Festplatte steht ein Debian mit reinem MySQL-Server auf einer 10 GByte-Disk gegenüber.

Die Ergebnisse der Kopmrimierung sind eindeutig: Die Images die die Libewf erzeugt, haben bestenfalls 1,36 GByte beim BSD-System und 0,96 GByte beim Debian-System. Afflib mit Gzip schafft dagegen bereits 1,29 und 0,89 GByte Filesize, aber mit LZMA sogar erstaunlich kleine 0,89 GByte für das BSD-Image und nur 560 MByte für das eigentlich größere Debian-System.

Aimage im Netzwerk

Es gibt bessere Tage im Leben eines Forensikers, aber manchmal findet er sich in der Farm des ISP und der dortige Administrator erklärt ihm stolz, dass im Raum 6000 Rootserver ihren Dienst verrichten. Aber ausgerechnet die beiden, von denen der Ermittler ein Image ziehen will, sind nur mit USB 1 ausgestattet und laufen unter OpenBSD. Selbst wenn es gelingen sollte, eine externe Sicherungs-Festplatte (NTFS, FAT32 oder Ext) unter BSD zu mounten, USB 1 wäre unakzeptabel langsam.

Hier hilft die Live-CD aus der Heft-DVDweiter. Der Rootserver bootet von ihr, ein Cross-Over-Netzwerkkabel verbindet die forensische Auswertestation (im folgenden Beispiel 10.0.0.1) über manuell zugeordnet IP-Adressen. Hier läuft Aimage im Listen-Mode und wartet auf ein engehendes Image:

aimage -L listen:8888 serverimage.aff

Auf dem Root-Server laufen jetzt die vertrauenswürdigen Binaries der CD, zum Beispiel NC oder Dc3dd. Das folgende Beispiel überträgt das komplette Image der Festplatte des Rootservers (»dev/sda«) mit Dc3dd und Netcat:

dc3dd if=/dev/sda progress=on | nc 10.0.0.1 8888 

Nach erfolreichherr Übertragung befinet sich das Image auf der Auswertestation.

Von Spürhunden und Affen

Nach den Images kommt die Auswertung. Im Open-Source-Bereich hat sich das Sleuthkit [12] weit verbreitet.

Der Admin sollte es aber tunlichst aus den Sourcen installieren, denn nur dann prüft es auf installierte Libewf- und Afflib-Bibliotheken und bezieht sie beim Build ein. Zusätzlich zu den Raw-Formaten »raw« und »split«, erkennt Sleuthkit jetzt auch Ewf und mehrere Afflib-Formate (Abbildung 3). Das Zusammenspiel klappt, wie das folgende Beispiel zeigt: Aus dem Afflib-Image ist eine Übersichtsliste aller Dateien des Sticks erstellt, gruppiert nach Datum. Dazu kommt »fls« zum Einsatz:

fls -o 63 -i aff -r -m / debianstick.aff > /tmp/filelist.mac 

Dabei haben die Parameter folgende Bedeutung:

• »-o 63«: Offset in Sektoren zur ersten Partition
  (zuvor mit fdisk ermittelt)
• »-i aff«: Image-Typ
• »-r«: Rekursiv, Unterverzeichnisse einbeziehen
• »-m«: MAC-Time-Informationen einbeziehen

Die Datei »filelist.mac« ist jetzt noch nicht sinnvoll lesbar, aber »mactime« aus dem Sleuthkit konvertiert sie: »mactime -b /tmp/filelist.mac > /tmp/filelist«.

Abbildung 3: Ewf- und Afflib-Support gibts im Sleuthkit nur für die Admins, die aus den Quellen kompilieren. Mit »fls -i list« lässt sich das schnell überprüfen.

Fazit

Mit Afflib steht dem Forensiker eine Bibliothek zur Seite, die es in sich hat. Durch die leistungsfähigere LZMA-Komprimierung übertrifft sie alle ähnlichen Formate, sogar das von Encase als Quasi-Standard etablierte, aber propretäre EWF-Format. Trotzdem bleibt die Frage, ob es sich gegen den Konkurrenten durchsetzen kann, denn auch die Afflib ist immerhin schon seit 2007 verfügbar. Obwohl die mit LZMA-Komprimierung erzielten Einsparungen enorm sind, fristet die Afflib eher noch ein Schattendasein. Das Interesse der proprietären Anbieter, dieses Format zu adaptieren, dürfte sich in Grenzen halten. Forensiker, die in einer Fallauswertung keine Kompatibilität zum EWF-Standard benötigen, sind mit diesem leistungsfähigen und stabilen Produkt dagegen gut beraten.