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 IDS-Mitschnitt des RPC-Angriffs:
11/07-23:11:50.870124 216.216.74.2:710 -> 172.16.1.107:871 |
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.
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:
Abbildung 3:
Autopsy: Suche nach dem Wort „linsniff“ in ungenutzten Inodes
Abbildung 4:
Autopsy: Anzeige von Dateien. Hier: Inhalte von Rootkit-Dateien
unter /dev/ida/.drag-on
Abbildung 5:
Autopsy: Anzeige des Inhalts und Export von gelöschten Dateien.
Hier: ein vollständiges Rootkit TAR File
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
Auf dem Zielsystem 10.0.0.1 sollte dann zum Abspeichern des Datenstroms
folgender Befehl verwendet werden: |
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 /var/log | nc 10.0.0.1 8000
Auf dem System 10.0.0.1 sollte dann folgender Befehl verwendet werden:
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 |
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:
Abbildung 9:
Incident Response Collection Report (IRCR)
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
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.
Seitenanfang | ZIDline 7 - Oktober 2002 | ZID | TU Wien