All About Security

18.11.2010 Risiko- & Kontinuitätsmanagement, Security-Management, Fachartikel

Live Analyse im Rahmen der Sicherheitsvorfallbehandlung

Nicht jeder Sicherheitsvorfall ist auf den ersten Blick als solcher zu erkennen. Viele Sicherheitsvorfälle, insbesondere wenn es sich um gezielte vorsätzliche Angriffe auf IT-Systeme handelt, fallen erst nach Tagen oder Wochen auf. Die Herausforderung für die Systemverantwortlichen besteht nun darin, eine betriebliche Störung von einer sicherheitsrelevanten Unregelmäßigkeit zu unterscheiden. Hinweise hierzu gibt der nachfolgende Artikel.

Klassische Verdachtsmomente für eine Manipulation durch Unbefugte wären etwa, wenn der Administrator unbekannte Prozesse oder Benutzer entdeckt. Auch das Vorhandensein unbekannter Dateien oder Verzeichnisse - womöglich an unüblichen Stellen oder mit ungewöhnlichen Rechten versehen - sollte stutzig machen. Verdächtig wäre ebenso eine nicht erklärbare hohe Systemlast, das plötzliche Nichtfunktionieren oder langsamer werden von Diensten oder ungewöhnliche Anmeldungen an Systemen. Intrusion-Detection-Systeme können weitere Hinweise auf Angriffe liefern. Neben diesen sichtbaren Indizien ist aber auch das Fehlen von erwarteten Dateien oder Konfigurationen verdächtig, indiziert es doch grundsätzlich eine ungewöhnliche Veränderung des Systems. Der denkbar ungünstigste Fall ist das Bekanntwerden eines Sicherheitsvorfalls durch Information von externen Dritten, da hier in vielen Fällen ein Reputationsschaden entsteht.

Nach dem Erkennen einer sicherheitsrelevanten Unregelmäßigkeit müssen die Verantwortlichen zunächst entscheiden, ob es sich um einen Sicherheitsvorfall mit eventuell zu erwartenden größeren Schäden handelt. Entscheidungsgrundlage hierfür ist die klare Definition eines Sicherheitsvorfalls innerhalb der Organisation. Wie nach dem Feststellen eines Sicherheitsvorfalls weiter vorzugehen ist, sollte in einer Richtlinie zur Behandlung von Sicherheitsvorfällen dokumentiert sein. Darin ist zu regeln, bei welchem Ereignis welche Schritte einzuleiten sind, wer gemäß der Meldewege wann und durch wen zu alarmieren ist und wer welche Verantwortlichkeiten hat. Denn bei Auftreten eines Sicherheitsvorfalls ist es in der Regel zu spät, sich darüber Gedanken zu machen. Dann ist Reagieren gefragt. Bei der Reaktion auf einen Sicherheitsvorfall – im Fachjargon: Incident Response – sind die Betroffenen in vielen Fällen vorerst auf sich alleine gestellt. Dies gilt insbesondere für Organisationen mit verteilten Standorten, an denen in den ersten Stunden nach Bekanntwerden des Vorfalls nicht immer ein Expertenteam oder externe Sicherheitsspezialisten für dessen Behandlung verfügbar sein können. In diesen Fällen muss sich vertrauenswürdiges Sicherheitspersonal vor Ort mit der Sicherung der Beweismittel beschäftigen. Das setzt voraus, dass die verantwortlichen Mitarbeiter die Methoden und Werkzeuge zur Behandlung von Sicherheitsvorfallen kennen und deren Einsatz beherrschen. Die Durchführung der notwendigen Maßnahmen zur Behebung von Sicherheitsvorfällen erfolgt meist unter Zeitdruck. Falsche Reaktionen können aber noch zur Verschlimmerung der Situation beitragen, etwa indem man durch überhastete Entscheidungen versehentlich Daten löscht, die eventuell beweiskräftig gewesen wären. Das gilt insbesondere für die Tätigkeiten am aktiven, nicht ausgeschalteten System - während der sogenannten Live Analyse. In einer solchen Situation ist es alles andere als einfach, die Nerven zu bewahren und mit Bedacht vorzugehen.

Flüchtige Daten einsammeln

Bei Verdacht auf einen Sicherheitsvorfall wird in der Regel versucht, mit Bordmitteln - anhand der Prozessliste des Windows Task Managers etc. - zu überprüfen, ob dieser sich bestätigt. Damit wird allerdings der Zustand des Systems schon verändert und unter Umständen Beweisspuren des Delikts zerstört. Des Weiteren muss sich die handelnde Person bewusst sein, dass die systemeigenen Werkzeuge im Rahmen des Einbruchs manipuliert worden sein könnten. Sie könnten bei der Datenwiedergabe Spuren des Einbruchs vor den Augen der handelnden Person verbergen, aber auch Spuren - im schlimmsten Fall Datenbestände - löschen. Sie sind daher nicht mehr als vertrauenswürdig einzustufen und ihre Verwendung ist unbedingt zu vermeiden.

Im Falle eines begründeten Verdachtsmoments ist es daher sinnvoll, grundsätzlich von einem Einbruch respektive einem Sicherheitsvorfall auszugehen und vor allen weiteren Untersuchungen zunächst sämtliche flüchtigen Daten zu sichern, die nach dem Ausschalten des betroffenen Systems nicht mehr verfügbar wären. Die Tragweite eines Sicherheitsvorfalls wird in vielen Fällen erst im weiteren Verlauf der Ermittlungen deutlich. Glücklich, wer da auf die flüchtigen Daten aus der Live Analyse zurückgreifen kann. Zwei Dinge sind bei der Live Analyse vor allem wichtig: Man muss die flüchtigen Daten des verdächtigen Systems schnellstmöglich sicherstellen und dabei den Zustand des Systems so wenig wie möglich verändern. Das aus der klassischen forensischen Wissenschaft bekannte und von Edmund Locard formulierte Austauschprinzip (Locard’s Exchange Principle) „Jeder und alles am Tatort nimmt etwas mit und lässt etwas zurück“ ist ebenfalls auf die Computerforensik und konkret auf die Live Analyse anwendbar. So resultieren aus den erforderlichen Tätigkeiten in der Regel auch Veränderungen des Systemzustands. Umso wichtiger ist es, alle durchgeführten Handgriffe ausführlich und nachvollziehbar zu protokollieren. Es beginnt und endet mit der Bestimmung der Systemzeit, womit die Zeitspanne der Live Analyse festgehalten und zu den restlichen Geschehnissen auf dem verdächtigen System abgegrenzt ist. Für die zeitliche Korrelation der sichergestellten Daten von weiteren Systemen, die für die Aufklärung des Sicherheitsvorfalls relevant sind, müssen die Zeitdifferenzen aller beteiligten Systeme zu einer Referenzzeit ermittelt werden. Es kann auch keinesfalls schaden, einen Kollegen zu bitten, bei der folgenden Beweissicherung als Zeuge zu fungieren.

Die Sicherungsreihenfolge der flüchtigen Daten ist durch deren Halbwertszeit bestimmt. Begonnen wird nach Ermittlung der Systemzeit immer mit den flüchtigsten Informationen. Werkzeuge für das Sichern dieser Daten sind das Minimum, das in die Toolbox eines Ermittlers gehört. Die Werkzeuge des verdächtigen Systems sind für die Live Analyse tabu. Folglich muss sich der Ermittler die Toolbox aus Werkzeugen aufbauen, die aus vertrauenswürdigen Quellen stammen. Dabei ist insbesondere darauf zu achten, dass die Werkzeuge statisch gelinkt sind. Tools, die für die Sicherung der flüchtigen Daten Systembibliotheken verwenden oder mit ihnen wunderschöne GUI s hervorzaubern, sollte man nicht einsetzen. Die Verwendung von Kommandozeilen-Tools erleichtert außerdem die erforderliche Dokumentation, da sich die Ergebnisse unkompliziert in Berichte integrieren lassen. Das manuelle Aufrufen der Incident- Response-Tools ist aufgrund der Vielzahl an Parametern fehlerträchtig und kostet wertvolle Zeit. Denn auch ein laufendes System, mit dem nicht direkt interagiert wird, verändert sich unentwegt und zerstört dabei womöglich Daten, die für die Aufklärung des Sachverhaltes relevant sein könnten. Das Ziel ist also eine zeitnahe, zügige, reproduzier- und vergleichbare Herangehensweise bei der Beweismittelsicherung.

Automatisierung

Einen großen Schritt näher kommt man diesem Ziel, wenn die Werkzeuge automatisiert und mit gleichbleibenden Parametern aufgerufen werden. Diesen Ansatz verfolgen Incident-Response-Toolkits - Skripte, die die Werkzeuge entsprechend der Halbwertszeit der zu sichernden Informationen und mit geeigneten Parametern aufrufen. Auf dem Markt sind verschiedene Incident-Response-Toolkits - kommerziell und frei - verfügbar, die sich im Wesentlichen in Konfiguration, Bedienkomfort und Präsentation der Ergebnisse unterscheiden. Die zugrunde liegenden Werkzeuge sind in der Regel ähnlich und lassen sich erweitern. Das Windows Forensic Toolchest hebt sich durch seine umfangreichen und sinnvoll aufgebauten HTML-Reports sowie den interaktiven Modus und die Möglichkeit, Werkzeuge, die das Incident Response Skript benötigt, aus dem Internet herunterzuladen, von den freien Toolkits ab. Für den Profi sind die Werkzeuge auch manuell aufrufbar, etwa um bestimmte Parameter zu ändern oder einzelne Untersuchungen zu wiederholen oder zu überprüfen. Die Ergebnisse der Live Analyse sollten nie auf die Datenträger des zu untersuchenden Systems geschrieben werden, da dadurch potenziell beweiskräftige Daten im freien Speicher überschrieben werden könnten. Das Abbild des Hauptspeichers allein belegt auf aktuellen Systemen mehrere Gigabyte. Vielmehr sollte man die Ergebnisse über das Netzwerk auf ein Analysesystem übertragen oder auf einen leeren externen Datenträger speichern.

Selbst wenn man keine professionelle Spürnase ist und selten in die Verlegenheit kommt, Beweise sammeln zu müssen, lohnt es sich, eine solche Werkzeugsammlung vorzuhalten. Denn erstens steht der Betroffene in einer Einbruchssituation wie erwähnt unter Zeitdruck und findet in der Hektik keine passenden Werkzeuge, schon gar nicht auf verschiedenen externen Datenträgern.

Zweitens sollte man sich beizeiten mit den Werkzeugen befassen und sie ausgiebig ausprobieren, damit man im Ernstfall nicht ins kalte Wasser springt und wertvolle Zeit verliert. Damit der Ermittler die Ergebnisse korrekt interpretiert und die richtigen Schlüsse zieht, sollte er die Eigenheiten und Grenzen der eingesetzten Werkzeuge unbedingt kennen und die Ergebnisse eines Untersuchungsdurchgangs immer mit einem zweiten Werkzeug oder gar weiteren Tools verifizieren. Die Ergebnisse können aus vielerlei Gründen verschieden und durchaus aussagekräftig sein. Sinnvoll ist diese Maßnahme besonders auch in Hinblick auf sogenannte antiforensische Techniken, mit denen ein Einbrecher seine Spuren zu verwischen sucht. Denn dieser kennt die Schwächen der gegnerischen Werkzeuge und macht sie sich zunutze. Ein Ermittler, der die Schwächen ebenfalls kennt und die Ergebnisse mit alternativen Werkzeugen überprüft, ist hier klar im Vorteil.

Sicherung und Analyse von Speicherabbildern

Schritt eins bei der Sicherung der flüchtigen Daten besteht im Erzeugen eines Speicherabbilds, da diese Daten den flüchtigsten Charakter aufweisen. Ein Speicherabbild lässt sich bei den Betriebssystemen Windows 2000 und Windows XP noch unter Verwendung der Windows-Portierung von dd aus den Forensic Acquisition Utilities und dem Aufruf dd.exe conv=noerror bs=4096 if=\\.\PhysicalMemory of=< memory.dmp> erstellen. Der Zugriff auf diese Pipe ist allerdings seit dem SP1 unter Windows 2003 nicht mehr aus dem User-Mode gestattet. Neueste Werkzeuge wie mdd (Mantech), win32dd (Matthieu Suiche) und WinEn (Guidance Software) nutzen Windows Kernel Gerätetreiber, um aus dem Kernelmode ein Abbild des physikalischen Speichers zu erstellen. Der Nachteil dieses Ansatzes ist das Erzeugen des Abbildes, während das System weiterläuft und damit auch der Arbeitsspeicher einer ständigen Veränderung unterliegt. Im Idealfall löst man auf dem verdächtigen System einen Crash-Dump aus, wodurch das System augenblicklich anhält und keine weiteren Veränderungen im Arbeitsspeicher möglich sind. Das ist aber erst dann sinnvoll, wenn man zuvor alle weiteren flüchtigen Daten gesichert hat. Das Auslösen eines Crash-Dumps über die Tastenkombination „CTRL rechts + 2x Scroll Lock“ funktioniert erst, nachdem man präventiv den erforderlichen Registry-Schlüssel gesetzt (siehe Microsofts Knowledge-Base-Artikel Q244139 und Q274598) und das System neu gestartet hat. Sofern das verdächtige System im laufenden Zustand gesperrt ist und die genannten Werkzeuge nicht genutzt werden können, ist die Sicherung mittels Hardwarezugriff eine Alternative. Ein vorhandenes IEEE 1394 Interface lässt sich für den direkten Zugriff auf den Speicher (DMA) unter Umgehung des Betriebssystems verwenden. Zuvor wird auf dem System, welches für die Sicherung des RAM verwendet wird, ein ROM Image eingespielt, welches dem Zielsystem bei Verbindung über IEEE 1394 den Anschluss eines iPods vorgaukelt. Für den Fall, dass das verdächtige System gesperrt ist und über keinen IEEE 1394 Port verfügt, bleibt noch die sogenannte Princeton Methode. Dabei wird der Speicherbaustein mittels handelsüblichen Kühlsprays so stark herunter gekühlt, dass die elektrischen Ladungen auch nach Abschaltung der Spannungsversorgung mehrere Minuten erhalten bleiben. Diese Zeit wird genutzt, um den Speicherbaustein zu entfernen und in ein Analysesystem einzubauen, welches unter einem minimalen Betriebssystem die Erzeugung eines Speicherabbildes von dem tiefgekühlten Speicherbaustein ermöglicht. Forscher wiesen mittels flüssigen Stickstoffs einen Datenverlust von nur 0,17 % nach 60 Minuten nach.

War die Auswertung von Speicherabbildern bis vor wenigen Jahren auf einfache Suchen nach relevanten Zeichenketten begrenzt, bieten moderne Werkzeuge wie Volatility und Memoryze deutlich leistungsfähigere, forensische Analysemöglichkeiten. Hierzu gehören unter anderem die Ausgabe der laufenden Prozesse, bestehenden Netzwerkverbindungen sowie der von den laufenden Prozessen geladenen DLLs und geöffneten Dateien. Nutzern des in Python geschriebenen Frameworks Volatility steht eine wachsende Sammlung von Plugins für verschiedenste, fortgeschrittene Analysen beispielsweise für die Erkennung von IAT, EAT und in-line Hooks zur Verfügung. Ferner können eigene Plugins entwickelt werden. Die Untersuchung von Speicherabbildern erlaubt auch einen Blick in die Vergangenheit. Objekte, beispielsweise Prozessstrukturen, die bereits terminiert wurden, sind im Arbeitsspeicher in der Regel noch auffindbar. Dies eignet sich hervorragend für die Untersuchung von Angriffen auf IT-Systeme. Ein Prozess, der im Rahmen eines Exploits gestartet und beendet wurde, ist möglichweise noch auffindbar und bietet Hinweise auf den Tathergang. Des Weiteren können Prozesse, die beispielsweise durch Rootkits mittels BlöckenDirect Kernel Object Manipulation versteckt wurden, durch die Suche nach Signaturen von EPROCESS-Blöcken unter Umgehung der forward und backward links zwischen den einzelnen EPROCESS-Blöcken identifiziert werden. Die in dem Speicher geladenen Registry-Strukturen können ebenfalls ausgewertet werden. Neben den dafür vorhandenen Plugins wurde das Werkzeug RegRipper, mit dem Reports über forensisch interessante Registry-Keys erstellt werden können, für die Nutzung mit Volatility angepasst. Unter [hogfly] stehen diverse Speicherabbilder zur Untersuchung bereit, die mit unterschiedlichstem Schadcode infiziert worden sind.

 

Abbildung-1 Auflistung der laufenden Prozesse unter Verwendung Forward/Backward Links in EPROCESS Blöcken  Grafikdownload

Insbesondere für die forensische Untersuchung von Systemen, die mit schadhaftem Code befallen sind, reicht die klassische Methode der Auswertung von gesicherten Festplatten, die sogenannte Post-Mortem-Analyse, in vielen Fällen nicht mehr aus. Der Sicherung und Auswertung von flüchtigen Daten, insbesondere des Arbeitsspeichers, kommt daher eine immer größere Bedeutung zu. Dies haben auch die Hersteller integrierter Analyseumgebungen wie EnCase (Guidance Software) und FTK (AccessData) erkannt und kürzlich Analysemöglichkeiten in ihre Produkte integriert [Schuster].

 

Abbildung-2 Auflistung der laufenden Prozesse unter Umgehung der Forward/Backward Links in EPROCESS Blöcken  Grafikdownload

Post-Mortem-Analyse

Nach der Sicherung der flüchtigen Daten sollte das verdächtige System durch Ziehen des Netzsteckers hart ausgeschaltet werden, um weitere Veränderungen der Daten durch ein geordnetes Herunterfahren zu vermeiden. Anschließend werden von dem Datenträger des verdächtigen Systems forensische (deckungsgleiche) Kopien erstellt. An forensische Duplikate als Basis für die Post-Mortem-Analyse stellen die Beteiligten unter anderem hohe Integritätsanforderungen, nicht zuletzt aus Gründen der späteren Gerichtstauglichkeit. So muss durch Prüfsummenverfahren belegt und jederzeit nachweisbar sein, dass das bitweise erstellte Duplikat eines verdächtigen Datenträgers exakt dem Originaldatenträger entspricht. Schreibzugriffe auf den zu untersuchenden Datenträger soll ein Schreibschutzgerät, ein sogenannter Write-Blocker, technisch verhindern. Dabei wird der Write-Blocker zwischen die zu untersuchende Festplatte und das Analysesystem geschaltet. Für die Erstellung der forensischen Kopie steht eine Vielzahl an Werkzeugen zu Verfügung, die prinzipiell alle eine bitweise, deckungsgleiche Kopie des zu untersuchenden Datenträgers erstellen. Zu beachten ist hierbei, dass diese Werkzeuge bzw. die verwendeten Write-Blocker auch Datenbereiche in ATA-Konfigurationen wie Host Protected Areas (HPA) und Device Configuration Overlays (DCO) erkennen und einbeziehen. Hinsichtlich der verfügbaren Werkzeuge zur Erstellung forensischer Kopien ist das Werkzeug FTK Imager von Hersteller AccessData hervorzuheben, da es in der nun verfügbaren Version 3.0 das schreibgeschützte Einbinden (Mounten) von forensischen Kopien (Images) unter Windows als logisches oder physikalisches Laufwerk ermöglicht. Die in einem Image enthaltenen FAT- und NTFS-Partitionen werden in Windows als eigenständige Laufwerke eingebunden. Hierfür waren zuvor gesonderte Werkzeuge notwendig. Dies ist ideal für die Suche nach schadhaftem Code mittels Virenscanner ohne dass das Image durch diesen Eingriff verändert wird. Werkzeuge wie Live View sind in der Lage ein forensisches Image in eine VMware virtuelle Maschine umzuwandeln. Dies erlaubt eine Untersuchung des gesicherten Datenträgers aus der Sicht des ursprünglichen Anwenders.

Abbildung-3 Analyse eines Speicherabbildes mit FTK, Quelle: http://blogs.sans.org/computer-forensics/2010/08/10/review-access-data-forensic-toolkit-ftk-version-3-part-2/

Grafikdownload

Fortgeschrittene Analysetechniken der Post-Mortem-Analyse ermöglichen integrierte Analyseumgebungen wie EnCase (Guidance Software), FTK (AccessData) und X-Ways Forensics (X-Ways Software Technology). Neben diesen kommerziellen Werkzeugen bieten auch die Open Source Tools Autopsy Forensic Browser und PTK, beide ein Front-End für das forensische Urgestein The SleuthKit, grundlegende Funktionalitäten. Diese sind beispielsweise auf der computerforensischen Live CD Helix und der SANS Investigative Forensic Toolkit Workstation [SIFT] enthalten. Wer für das Ausprobieren der genannten Werkzeuge Übungsimages sucht, wird unter [Mueller] oder [CFReDS] fündig.

Fazit

Klassische Methoden und Techniken der Computer-Forensik, wie die Analyse forensischer Datenträgerkopien, sind heute oft nicht mehr ausreichend, um fortgeschrittene Angriffe auf IT-Systeme nachzuweisen. Oft kann erst die digitale Spurensuche direkt im Arbeitsspeicher eines Systems die entscheidenden Erkenntnisse für die Aufklärung des Sachverhaltes liefern. Zusammenfassend ist das A und O der Sicherheitsvorfallbehandlung, dass man sich sowohl technisch als auch organisatorisch nicht unvorbereitet in einer Situation wiederfindet, in der man unter Zeitdruck ohne Expertenhilfe und ohne passende Werkzeuge auf eine Ausnahmesituation reagieren muss. Das rechtzeitige Erstellen eines entsprechenden Plans sowie das Zusammenstellen und gründliche Ausprobieren der Werkzeugkiste sind Voraussetzung für eine erfolgreiche Beweissicherung und Basis für weitere Ermittlungen. Außerdem sollte man tunlichst darauf achten, alle Tätigkeiten und Erkenntnisse schlüssig und nachvollziehbar zu dokumentieren.

 

Literatur:
[hogfly] A memory snapshot project, http://forensicir.blogspot.com/2009/03/memory-snapshot-project.html

[Schuster] Recent Advances in Memory Forensics, Andreas Schuster, ZISC 2010, http://computer.forensikblog.de/files/talks/ZISC2010-Recent_Advances_in_Memory_Forensics.pdf

[SIFT] SANS Investigative Forensic Toolkit(SIFT), https://computer-forensics2.sans.org/community/siftkit/

[Mueller] Blog von Lance Mueller mit Practical Challenges, http://www.forensickb.com/

[CFReDS] Hacking Case des CFReDS Project, http://www.cfreds.nist.gov/Hacking_Case.html

 

Sebastian Krause, GAI NetConsult GmbH

 

 

 

 

Diesen Artikel empfehlen

Autor: Sebastian Krause