Zum Inhalt springen

Disk-Forensik/ Sonstige/ Systemaktivitäten

Aus Wikibooks

Jede Aktion, die auf einem Computersystem ausgeführt wird, hinterlässt Spuren. Dies beinhaltet auch angeschlossene und installierte Hardware (z.B. USB Stick, Speicherkarten, externe Festplatten, usw.), und installierte und auch teilweise bereits deinstallierte Software. Dieser Abschnitt behandelt die forensische Suche nach Nachweisen solcher Aktivitäten.

Hardware[Bearbeiten]

Sobald an einem System eine neue Hardwarekomponente angeschlossen wird, müssen dafür Treiber installiert werden, um die Verwendung dieser Komponente zu ermöglichen. Teilweise geschieht das automatisch im Hintergrund, teilweise muss sich der Benutzer darum kümmern. Diese Treiber werden selten oder sogar nie wieder deinstalliert, wodurch nachvollzogen werden kann, welche Art von Hardware von diesem System benutzt wurde. Unter UNIX/Linux kann mit dem Befehl mount festgestellt werden, wie und wo eine bestimmte Komponente in das Dateisystem eingebunden (gemountet) wurde (z.B. usbfs on /proc/bus/usb type usbfs (rw)).

Verzeichnisse auf Linux Systemen, in die Treiber installiert/gespeichert werden können:

* /lib/modules/`uname -r`/ (z.B. /lib/modules/2.6.12-10-386/)
* /usr/src/linux (falls dieses Verzeichnis existiert)

Der Befehl lspci dient zur Auflistung der Informationen über alle PCI Busse (alle Peripheriegeräte) des Systems, sowie alle Geräte, die zu diesen verbunden sind. Diese Ausgabe kann zum Beispiel wie folgt aussehen:

user@hostname:~$ lspci
0000:00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 01)
0000:00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 01)
0000:00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 08)
0000:00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01)
0000:00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB
0000:00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 08)
0000:00:0f.0 VGA compatible controller: VMWare Inc [VMWare SVGA II] PCI Display Adapter
0000:00:10.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 01)
0000:00:11.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 10)
0000:00:12.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 02)

Auf Windows Systemen werden die installierten Treiber im Pfad C:\WINDOWS\system32\drivers\ als *.sys Dateien gespeichert. Es muss jedoch beachtet werden, dass standardmäßig bereits einige Treiber von oft verwendeter Hardware für die Option Plug & Play am System vorhanden sind, auch wenn nie ein solches Gerät am Rechner angeschlossen wurde. Plug & Play funktioniert, indem aufgrund von Hardwarekennungen ein kompatibler Gerätetreiber in den INF-Dateien gesucht und verglichen wird. Der Suchpfad für die INF-Dateien wird in folgendem Registry Key definiert:

HKEY-LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion
DevicePath:Reg_Expand_SZ:%Systemroot%\Inf

Dieser Variable können auch mehrere Pfade als Wert zugewiesen werden, indem die unterschiedlichen Pfade durch einen Semikolon getrennt werden. Diese angegebenen Datenpfade sollten ebenfalls auf Treiber untersucht werden, da sie ebenfalls Informationen enthalten können, welche Geräte an den Rechner angeschlossen wurden.

Software[Bearbeiten]

Bei der Software muss man einige Unterscheidungen treffen:

* legitim installierte Software
* illegitim installierte Software (z.B. Trojaner, Rootkits,...)
* legitim deinstallierte Software
* illegitim deinstallierte Software

Legitim installierte Software kann unter Windows sehr einfach durch das Auflisten der Software (unter Start => Systemsteuerung => Software) angezeigt werden. Illegitim installierte Software ist relativ leicht aufzuspüren, da lediglich nach (teilweise versteckten) ausführbaren Dateien auf der Festplatte gesucht werden muss. Sobald die Software deinstalliert wurde, wird der Nachweis komplizierter und teilweise sogar unmöglich. Darüber hinaus muss beachtet werden, dass es Programme gibt, die auf das System kopiert und gestartet werden, im Hintergrund laufen und währenddessen gelöscht werden. Im laufenden System sind diese Programme noch aktiv, wobei sie nach einem Neustart des Systems aufgrund fehlender Progammdateien nicht mehr gestartet werden. Darauf sollte vor allem bei der Analyse auf einem laufenden System geachtet werden. Weiter gibt es Programme, die keine Installation benötigen, und lediglich aus einer einzigen ausführbaren Datei bestehen. Ein Beispiel für legitime Software die nicht installiert werden muss ist putty.exe.

Unter Linux ist die Auflistung von installierter Software ein bisschen komplizierter, da Linux Distributionen dies nicht einheitlich verwalten. Da die meiste Software mit Hilfe von den jeweiligen distributionsspezifischen Paketmanagern installiert werden, kann durch Auflistung dieser Pakete der Großteil der installierten Software angezeigt werden. Unter Debian Systemen können alle Pakete, die mit dem System dpkg installiert wurden mit dem Befehl dpkg --get-selections aufgelistet werden. Bei RedHat Systemen wird dies mit dem Befehl rpm -qa durchgeführt. Dadurch werden jedoch nicht die Programme aufgelistet, die als Source direkt am Sytem kompiliert und installiert wurden.

Jedes Programm speichert bei der Installation und bei der Verwendung an unterschiedlichen Orten Programm-spezifische Daten ab, bzw. erstellt oder verändert Registry Keys (unter Windows), die meist nicht alle bei der Deinstallation gelöscht werden. Um nachzuweisen, dass ein bestimmtes Programm auf einem System installiert und in Verwendung war, müssen diese nicht gelöschten Daten ausfindig gemacht werden. Bei bekannten Programmen können durch einfaches Wiederholen auf einem Testsystem die Pfade der nicht gelöschten Daten ausfindig gemacht werden. Sobald es sich jedoch um spezielle Programme oder nicht bekannte illegitim installierte Programme handelt, wird die Suche deutlich aufwändiger.

Binärdateien[Bearbeiten]

Auf dem zu untersuchenden System können unbekannte Binärdateien gespeichert sein, die zunächst ohne Ausführen des Programms analysiert werde sollten. Vor allem sollte auf Programme geachtet werden, die nach bereits bestehenden Systemprozessen oder Systemdateien benannt wurden. Wenn das Analysesystem ein Linux System ist, gibt es einige einfache Befehle um dies durchzuführen. Zunächst muss herausgefunden werden, um welchen Datentyp es sich nun tatsächlich handelt. Dies kann mit dem Befehl file <Dateiname> angezeigt werden. Wenn es sich zum Beispiel beim zu untersuchenden System um DOS oder Windows handelt, könnte dies wie folgt aussehen:

$ file wmo32.exe
wmo32.exe: MS-DOS executable (EXE), 0S/2 or MS Windows

Der nächste Schritt bei der Analyse der als ausführbar erkannten Datei ist die String-Analyse. Diese geschieht durch den Befehl strings <Dateipfad+-name> | more oder nur strings <Dateiname>. Im folgenden Beispiel, das aus [GA06, S.105] übernommen wurde, wird ein Teil des Inhalts einer ausführbaren Datei unter Solaris darstellt:

$ strings sun1
[...]
DISPLAY
/usr/lib/libfl.k
pirc
/bin/sh
[...]

Dieser Auszug lässt vermuten, dass zwischen DISPLAY und /bin/sh ein Zusammenhang besteht, der genauer untersucht werden muss. Darüber hinaus wird angenommen, dass es sich hierbei um eine Version des Systemprogramms /bin/login handelt, die von einem Trojaner verändert wurde. Die originale Datei wurde umbenannt und nach /usr/lib/libfl.k kopiert. Eine weitere Analysemöglichkeit stellt das Tool truss dar. Hierbei werden Programmaufrufe der Binärdatei aufgelistet, wodurch feststellbar ist, ob auf ungewöhnliche Dateien (z.B. Dateien aus dem Verzeichnis /tmp) zugegriffen wird. Das folgende Beispiel wurde von [GA06, S.105] übernommen und veranschaulicht, dass das bereits oben gezeigte Programm unter anderem auf die verschobene Datei /usr/lib/libfl.k zugreift.

$ truss ./sun1
execve(„./sun1“, 0xFFBEFC8C, 0xFFBEFC94) argc = 1
execve(„/usr/lib/libfl.k“, 0xFFBEFC8C, 0xFF8EFC94) Err#2 ENOENT
_exit(1)

Sobald nun die DISPLAY-Variable pirc gesetzt ist, wird eine passwortlose Root-Shell geöffnet. Dies ist nur eines von unzähligen Beispielen, warum jede unbekannte Binärdatei auf einem zu untersuchenden System genauer betrachtet werden sollte.