Digitale Spuren im Hauptspeicher Möglichkeiten und Herausforderungen neuer Methoden der Computer-Forensik

Ordnungsmerkmale

erschienen in: <kes> 2009#4, Seite 51

Rubrik: Management und Wissen

Schlagwort: Computer-Forensik

Zusammenfassung: Etablierte Methoden und Techniken der Computer-Forensik, wie die Analyse duplizierter Datenträger, sind heute oft nicht mehr ausreichend, um fortgeschrittene Angriffe nachzuweisen. Oft kann erst die digitale Spurensuche direkt im Hauptspeicher eines Systems die entscheidenden Erkenntnisse liefern.

Autor: Von Andreas Kurtz, Heilbronn

Der Einbruch eines Hackers über eine Web-Applikation, ein Mitarbeiter, der vertrauliche Daten an ein Konkurrenzunternehmen versendet, oder ein unbekannter Wurm, der sich im Netzwerk ausbreitet – auf all dies verzichtet man gerne. Kommt es dennoch zu derlei Vorfällen und man möchte zumindest wissen, was geschehen ist, dann tritt die Computer-Forensik in Aktion: Verdächtige Systeme wurden dazu früher häufig vom Netz getrennt und abgeschaltet, enthaltene Datenträger anschließend dupliziert und analysiert.

Dieses "Standardverfahren" ist zwar völlig ausreichend, wenn es beispielsweise darum geht, einem Mitarbeiter im Unternehmen das Herunterladen illegaler Inhalte aus dem Internet nachzuweisen – die sichergestellten Datenträger werden dazu einfach auf entsprechende Datenfragmente durchsucht. Viele komplexere Vorfälle lassen sich durch diese Herangehensweise jedoch nur sehr schwer oder gar nicht nachvollziehen: Beispielsweise nutzt ein Angreifer bei so genannten (Remote-)Code-Injection-Angriffen eine Speicherschwachstelle aus, um Schadcode in einen Server-Dienst einzuschleusen und anschließend auszuführen – sämtliche Spuren befinden sich ausschließlich im Speichersegment des angegriffenen Prozesses. Schaltet man das System aus, werden alle Hauptspeicherinhalte gelöscht und die Spuren zerstört.

In den letzten Jahren wurden gängige IT-Forensikprozesse deshalb um neue Methoden erweitert: Neben den persistenten Daten, die sich auf Speichermedien befinden, will man nun auch möglichst viele flüchtige Daten eines Systems sichern, also Daten, die beim Ausschalten verloren gehen. Durch diese zusätzliche Auswertung kann eine forensische Analyse gleichzeitig deutlich zielführender erfolgen: Ein IT-Forensiker muss nicht mehr die "Nadel im Heuhaufen" auf den sichergestellten Datenträgern suchen, sondern bekommt über die flüchtigen Daten einen genauen Eindruck vom Live-Zustand des Systems vermittelt.

Im Rahmen der Live-Analyse gibt es eine Vielzahl von Daten, die bei der späteren Auswertung interessant sein könnten. Hier gilt der Grundsatz: Je flüchtiger die Daten sind, desto früher sollte man sie sammeln (vgl. [1]). Neben dem kompletten Hauptspeicherinhalt sollten zu Beginn daher sämtliche Caches und offenen Netzwerkverbindungen, Prozessinformationen, angemeldete Benutzer sowie geladene Betriebssystem-Treiber gesichert werden.

Schattenseiten der Live-Analyse

Einerseits will man bei einer Live-Analyse so viele Daten wie möglich sammeln, zum anderen gilt es dabei zu vermeiden, vorhandene Spuren zu zerstören oder zu verfälschen. In der Praxis ist dies längst nicht immer zu erreichen: Denn auch die Werkzeuge, die man zum Sammeln der Daten einsetzt, verändern den Zustand des betroffenen Systems (zumindest leicht). Schon die Spurensicherung bedeutet also stets einen Kompromiss zwischen Flüchtigkeit und Verfälschung.

Ein weiteres Problem besteht darin, dass die Forensik-Tools auf dem zu analysierenden System selbst ausgeführt werden müssen: Dadurch sind auch die Sammelwerkzeuge angreifbar! Ist auf einem System beispielsweise ein Rootkit installiert, das verschiedene Prozesse versteckt, lassen sich diese im Rahmen der Live-Analyse durch solche Werkzeuge nicht erfassen.

Um diesen Schattenseiten entgegenzuwirken, existieren bereits Ansätze, zunächst den kompletten Hauptspeicher eines Systems zu sichern und dann "extern" zu untersuchen. Im Prinzip sollte es ja reichen, ein Abbild des kompletten Hauptspeichers zu erstellen, um anschließend alle flüchtigen Daten aus diesem Abbild zurückzugewinnen. Wird tatsächlich der vollständige Speicher erfasst, ließen sich beispielsweise auch aktive Malware identifizieren und versteckte Prozesse finden.

Allheilmittel Hauptspeicher?

Doch auch die Sicherung des gesamten Hauptspeichers (RAM) erfordert zunächst einen Eingriff – hierzu gibt es unterschiedliche Ansätze: Manche Betriebssysteme gestatten ein direktes Auslesen des RAMs über so genannte "Memory Devices". Die Windows-Welt benötigt jedoch ab Server 2003 SP1 (Windows Vista verhält sich ähnlich) separate Programme, um den Hauptspeicher sicherzustellen – diese erfordern einen Betriebssystem-Treiber, da in den genannten Versionen der Zugriff auf den Hauptspeicher nur noch aus dem Kernel heraus erlaubt ist. Ein bekanntes, frei verfügbares Werkzeug zur Sicherung des Hauptspeichers auf diese Art ist beispielsweise Win32dd [2].

Um durch die RAM-Sicherung möglichst wenige Informationen eines Systems zu verfälschen, können die Daten auch mithilfe spezieller Hardware – etwa einer PCI-Karte – gesichert werden: Auf Knopfdruck wird dann ein Abbild des Hauptspeichers erstellt. Auch über den Firewire-Anschluss besteht die Möglichkeit, auf den Hauptspeicher zuzugreifen. Der große Vorteil solcher Lösungen besteht darin, dass die RAM-Inhalte unabhängig vom zugrunde liegenden Betriebssystem direkt über die Hardware ausgelesen werden und somit keine Verfälschung der Systemdaten erfolgen kann.

Auch Virtualisierungstechniken könnten sich an dieser Stelle hilfreich erweisen: Da ein Host-System uneingeschränkten Zugriff auf die darauf betriebenen virtuellen Maschinen besitzt, besteht die Möglichkeit, den Hauptspeicher der Gast-Betriebssysteme "von außen" auszulesen. Auf diese Art lassen sich Vorgänge und Zustände innerhalb einer virtuellen Maschine überwachen, ohne dass ein Virus oder Rootkit sich davor verstecken könnte.

Verkettete Spuren

Eine der größten Herausforderungen beim Extrahieren detaillierter Systeminformationen aus einem Speicherabbild stellt das Auffinden von Kernel-Strukturen dar: Die Speicherbereiche verschiedener Prozesse sind in den meisten Betriebssystemen über doppelt verkettete Listen miteinander verknüpft. Das Prinzip der Hauptspeicheranalyse besteht nun darin, das Speicherabbild linear nach Mustern zu durchsuchen, die bekannte Prozess-Datenstrukturen repräsentieren – hier kommen klassische Algorithmen der Mustererkennung zum Einsatz. Wurde das erste Prozessobjekt gefunden, kann man auf Basis der doppelt verketteten Liste (durch Verfolgen des Zeigers auf den jeweils nachfolgenden Prozess, vgl. Abb. 1) alle weiteren Prozesse aus dem Abbild extrahieren.

[Illustration]
Abbildung 1: Struktur von Prozesslisten im Hauptspeicher

Neben der genauen Definition der Suchmuster ist in diesem Zusammenhang auch eine korrekte Bestimmung der Speicheroffsets (vgl. Abb. 1) innerhalb eines Kernel-Objekts wichtig: Diese Offsets geben an, an welcher Stelle sich bestimmte Werte innerhalb einer Datenstruktur befinden. Konkret besagt dies beispielsweise, wie viele Byte ein Prozess-Name vom Pointer auf den nächsten Prozess im Hauptspeicher entfernt ist.

Die meisten Analysewerkzeuge setzen hierbei auf statische Offsets, die im Vorfeld beispielsweise durch den Einsatz von Debuggern bestimmt wurden; sämtliche Analysen werden dann auf Basis dieser einmal berechneten Abstände durchgeführt. Da sich jedoch bereits bei kleinsten Änderungen am Betriebssystemkern die Low-Level-Repräsentation der zugehörigen Datenstrukturen im Hauptspeicher ändert, lassen sich die gewünschten Informationen dann nicht mehr korrekt auslesen. Daher sind Verfahren zur Hauptspeicheranalyse sehr stark von der verwendeten Betriebssystem-Version abhängig. Dies erklärt auch, warum im Unix-/Linux-Umfeld nur wenige Werkzeuge zur Hauptspeicheranalyse existieren: Wo es beispielsweise bei Windows XP einen einzelnen Betriebssystem-Kern gibt, liefert ja jeder Linux-Distributor seinen eigenen angepassten Kernel aus, wodurch sich teilweise völlig andere Speicheroffsets ergeben.

Blick in den Werkzeugkasten

[Screenshot]
Abbildung 2: Volatility [3] ist ein Open-Source-Tool zur Analyse von Windows-XP-(SP2/SP3)-Speicherabbildern

Mittlerweile gibt es verschiedene Tools, mit deren Hilfe man Informationen wie laufende Prozesse, aktive Netzwerkverbindungen, geöffnete Dateien et cetera aus einem Speicherabbild extrahieren kann: Eines der bekanntesten im Open-Source-Umfeld ist das auf Python basierende Volatility [3], das Windows-XP-(SP2/SP3)-Speicherabbilder analysiert (vgl. Abb. 2).

[Screenshot]
Abbildung 3: HBGary Responder Pro [4] ist ein kommerzielles Tool zur Extraktion flüchtiger Daten aus einem Windows-Hauptspeicherabbild

Ein relativ neues, kommerzielles Werkzeug zur Hauptspeicher- und Malware-Analyse bietet HBGary für 9.000 US-$ mit dem "Responder Pro" an [4]: Über eine einfach zu bedienende Oberfläche hat man damit die Möglichkeit, flüchtige Daten aus einem Hauptspeicherabbild zu extrahieren – dazu muss lediglich eine Datei mit dem Speicherabbild importiert werden und das Programm beginnt automatisch mit der Analyse.

Abbildung 3 zeigt das Ergebnis der Auswertung eines Windows-Vista-Hauptspeicherabbilds: Über die Navigation im linken Teilbereich lassen sich bestimmte Kategorien auswählen, zu denen im rechten Fenster dann Detailinformationen eingeblendet werden – im Beispiel die gewonnene Prozessliste, es werden jedoch noch mehrere Dutzend weiterer Systeminformationen unterstützt. Der Responder Pro kennt Muster und Speicheroffsets aller Windows-Varianten und zugehöriger Service-Packs (32bit/64bit) und bietet außer der hier vorgestellten "Offline"-Speicheranalyse auch Methoden einer fortschrittlichen Malware-Analyse, um Würmer und Rootkits direkt im Hauptspeicher zu erkennen.

Andreas Kurtz ist Berater für IT-Sicherheit bei der cirosec GmbH in Heilbronn.

Literatur

[1]
D. Brezinski, T. Killalea, Guidelines for Evidence Collection and Archiving, RFC 3227/BCP 55, [externer Link] www.ietf.org/rfc/rfc3227.txt
[2]
Win32dd – a free kernel land tool to acquire physical memory, [externer Link] http://win32dd.msuiche.net
[3]
The Volatility Framework: Volatile memory artifact extraction utility framework, [externer Link] www.volatilesystems.com/default/volatility
[4]
HBGary Inc., Responder Professional, [externer Link] www.hbgary.com/products-services/responder-professional/
[5]
Christoph Becker, Lukas Grunwald, Martin F. Hoffmann, Günter Lessing, , Eugen Steiner, Wer suchet, der findet, Was bei der forensischen Analyse von IT-Systemen zu beachten ist, <kes> 2003#1, S. 68
[6]
Alexander Geschonnek, Tatort PC, Computer-Forensik-Ermittlungen nach dem S-A-P-Modell, <kes> 2006#2, S. 60
[7]
Volker Schwaberow, Tools zur IT-Forensik, <kes> 2006#2, S. 66
[8]
Manuel Rundt, Steven Ebling, Renato Fazzone, Bitte bitgenau!, Gerichtsverwertbarkeit digitaler Beweissicherungen, <kes> 2007#5, S. 23