Hochschule Wismar University of Applied Sciences Technology, Business and Design Fakultät für Ingenieurwissenschaften, Bereich EuI

Projektarbeit

Aufbereitung besonderer Speicherkonfigurationen als analysefähiges Material (RAID, LVM, WSS, Verschlüsselung)

Eingereicht am: 6. Juli 2019

von: Melanie Wetzig Sven Lötgering Tom Gertenbach Stefan Depping Inhaltsverzeichnis

Inhaltsverzeichnis

1 Vorüberlegungen4 1.1 Motivation und Zielstellung...... 4 1.2 Anforderung an den Ermittlungsprozess...... 4 1.3 Einordnung in Ermittlungsprozess...... 6 1.4 Write-Blocker...... 6 1.5 Software...... 7 1.5.1 Rohdatenformat (RAW)...... 7 1.5.2 Expert Witness Format (EWF)...... 8 1.5.3 Advanced Forensic Format (AFF)...... 8 1.5.4 Xmount...... 8

2 Rechtliche Betrachtung9 2.1 Einleitung...... 9 2.2 Private Ermittlungen...... 10 2.3 Behördliche Ermittlungen...... 11 2.4 Zusammenfassung...... 11

3 Speichermedien 13 3.1 Einleitung...... 13 3.2 Magnetspeicher...... 13 3.2.1 Speicherung auf einer HDD...... 14 3.2.2 Löschen von Daten auf einer HDD...... 15 3.2.3 Forensische Relevanz...... 15 3.3 Flash-Speicher...... 15 3.3.1 Speicherung auf einer Solid-State-Drive (SSD)...... 16 3.3.2 Löschen von Daten auf einer SSD...... 16 3.3.3 Forensische Relevanz...... 17 3.4 Hybride...... 17 3.5 Zusammenfassung...... 17

4 Analyse eines Datenträgerverbundes 19 4.1 Einleitung...... 19 4.2 Hardware-RAID...... 21 4.2.1 Schritt 1: Einbinden der Abbilder...... 23 4.2.2 Schritt 2: Öffnen der Abbilder in R-Studio...... 23 4.2.3 Schritt 3: Modellierung des RAID-Layouts...... 24 4.3 Software Lösungen unter ...... 31 4.3.1 Software-RAID...... 31 4.3.2 Logical Volume Manager (LVM)...... 36

2 Inhaltsverzeichnis

4.4 Software Lösungen unter Windows...... 40 4.4.1 Manager (LDM)...... 40 4.4.2 Windows Storage Spaces (WSS)...... 40 4.5 Zusammenfassung...... 45

5 Verschlüsselte Datenträger 46 5.1 Einleitung...... 46 5.2 Festplattenverschlüsselung...... 46 5.3 Verschlüsselungstools...... 47 5.3.1 BitLocker...... 47 5.3.2 FileVault 2...... 50 5.3.3 Linux Unified Key Setup (LUKS)/ dm-crypt...... 54 5.3.4 VeraCrypt...... 58 5.4 Zusammenfassung...... 61

6 Fazit 63

Literaturverzeichnis 65

Abbildungsverzeichnis 69

Abkürzungsverzeichnis 71

Selbstständigkeitserklärung 73

3 Kapitel 1. Vorüberlegungen

1 Vorüberlegungen

1.1 Motivation und Zielstellung

Der Ingenieursstudiengang IT-Forensik legt in seiner technischen Ausrichtung besonderen Wert auf das Erlangen qualitativ hochwertiger Fähigkeiten zur Analyse digitaler Spuren. Wie diese Spuren aus kriminaltaktischer Sicht zu bewerten sind, ist ebenfalls Teil des Lehrplans. Nun soll diese Projektarbeit die Brücke von der Erhebung analoger Spuren, zur Erhebung und Sicherung digitaler Spuren bilden. Hierbei wird einleitend die Einordnung im Ermittlungsprozess beschrieben, anschlie- ßend werden die rechtlichen sowie organisatorischen Grundlagen kurz erläutert. Im technischen Schwerpunkt der Projektarbeit steht die Datenerhebung von Massen- datenspeichern. Besonderes Augenmerk wird auf physikalische Speichermethoden, Speicherverbund verteilter Datenträger und Kryptographie gelegt. Die Themen werden unter dem Gesichtspunkt der Post-Mortem-Analyse durchgeführt, sodass eine Betrachtung von aktiven Systemen nicht Gegenstand dieser Arbeit ist. Auf die Datenerhebung via Netzwerk wird ebenfalls nicht eingegangen.

1.2 Anforderung an den Ermittlungsprozess

Nach Geschonneck, Computer Forensik [1, S. 66–67] gibt es sechs Grundsätze, die bei einer Datenerhebung und Auswertung permanent berücksichtigt werden sollten

Akzeptanz

Damit die Skepsis gegenüber der gewonnenen Erkenntnisse minimiert wird, soll- ten Methoden, Dateiformate und Softwarelösungen verwendet werden, die in der Fachwelt als sicheres forensisches Verfahren anerkannt sind. Erkenntnisse die mit Hilfe neuer unkonventioneller Hilfsmittel erlangt wurden, können einfacher in Fra- ge gestellt werden, als Welche die durch anerkannten Methoden herausgearbeitet wurden.

4 Kapitel 1. Vorüberlegungen

Glaubwürdigkeit

Die angewendeten Methoden müssen für Dritte nachvollziehbar sein. Der Ermittler sollte, die Verarbeitungsschritte von Beginn bis zum Abschluss verstehen und erör- tern können. Je komplexer die Werkzeuge werden, desto wichtiger ist das Verständnis der Funktionalität.

Wiederholbarkeit

Jedes Ergebnis und Zwischenergebnis muss, bei gleicher Herangehensweisen und denselben Bedingungen, reproduzierbar sein.

Integrität

Es ist sicherzustellen, dass die gesammelten Spuren unverändert sind und bleiben. Ist eine Veränderung einer Arbeitskopie notwendig, muss dies begründet und doku- mentiert werden. Das Original darf nicht verändert werden. Dies ist im gesamten Ermittlungsprozess zu gewährleisten.

Kausalität

Die Beweisspuren müssen entsprechend nachvollziehbar aufgearbeitet werden, dass Ursache und Auswirkung direkt voneinander abhängig sind. Indizien müssen als solche angegeben werden. Vermutungen dürfen nicht als Teil einer Beweiskette fun- gieren.

Dokumentation

Jeder Schritt im Ablauf der Beweissichtung, Beweiserhebung und der Beweisbewer- tung muss exakt dokumentiert werden.

5 Kapitel 1. Vorüberlegungen

1.3 Einordnung in Ermittlungsprozess

Eine Ermittlung im Zusammenhang mit Computerkriminalität kann mit Hilfe des Secure-Analyse-Present-Modell abgebildet werden. Nach diesem Modell beinhaltet die Secure-Phase die Sicherung der vorhandenen Spuren. Die Analyse-Phase beschäftigt sich mit der Auswertung der gesammelten Spuren. Abschließend werden in der Present-Phase die gewonnenen Erkenntnisse in Form von Beweisen und Kausalitätszusammenhängen in einem Gutachten festgehalten.

Die Ausprägung und Form der einzelnen Phasen ist je nach individuellem Fall un- terschiedlich. Ist eine Live-Analyse vorgesehen verschwimmen die Grenzen zwischen Secure- und Analyse-Phase. Hier werden Spuren gesichert, die sogleich ausgewer- tet und interpretiert werden, da sie entweder selbst flüchtig sind oder auf weitere flüchtige Daten verweisen. Sollte eine Straftat nach § 303a Strafgesetzbuch (StGB) - Datenveränderung oder § 303b StGB - Computersabotage gerade geschehen oder ist sie vor kurzer Zeit geschehen, ist die Sicherung von flüchtigen Daten ein funda- mentaler Ermittlungsschritt. Auf die Life-Analyse soll hier nicht weiter eingegangen werden. Diese Arbeit kon- zentriert sich auf die Datenerhebung der Secure-Phase für eine Offline-Analyse.

1.4 Write-Blocker

Für eine forensische Datenduplizierung ist es wichtig sicherzustellen, dass weder Personen noch Anwendungen die Originaldateien verändern. Um eine solche Ver- änderung zu verhindern, müssen alle schreibenden Zugriffe unterbunden werden. Dieses erfolgt durch sogenannte Write-Blocker. Es gibt zwei Varianten von Write- Blockern. Hardware-Writeblocker, welche sicher und kostenintensiver sind sowie Software-Writeblocker, welche Schreibbefehle des Treibers abfangen. Bei einem Hardware-Writeblocker handelt es sich, wie der Name bereits vermu- ten lässt, um ein Gerät, welches die Kommunikation zwischen dem Computer und dem zu untersuchendem Medium kontrolliert und überwacht. Alle Zugriffe, egal ob Lese- oder Schreibzugriffe, werden durch den Hardware-Writeblocker überprüft und abgefangen. Handelt es sich um einen Schreibzugriff, so wird dieser blockiert und somit nicht an das Speichermedium weitergegeben. Handelt es sich um einen lesen- den Zugriff, so wird dieser an das Speichermedium weitergegeben. Dadurch wird ein Schreiben auf dem Speichermedium verhindert und die Daten sind somit weiterhin

6 Kapitel 1. Vorüberlegungen im Originalzustand vorhanden. Hardware-Writeblocker werden von vielen handels- üblichen Schnittstellen (z. B. SATA, USB) unterstützt. Bei einem Software-Writeblocker muss eine Anpassung des für die Analyse genutz- ten Computers erfolgen. Dieses kann durch unterschiedliche Wege erfolgen. Zum einen gibt es Programme (z. B. USB Write Blocker for ALL Windows, für Win- dows Betriebssysteme), welche bestimmte Einträge in der Windows-Registry ver- ändern und hierdurch einen Schreibschutz hervorrufen. Diese Anpassung kann man auch entsprechend manuell durchführen, solche Programme vereinfachen diese An- passung jedoch. Zum Zweiten gibt es auch die Möglichkeit, bestimmte Treiber des Systems durch spezielle angepasste Treiber zu ersetzen. Hierdurch wird nicht nur ein Schreibschutz gesetzt, sondern aktiv in die Kommunikation zwischen Computer und Speichermedium eingegriffen (z. B. das Tool EnCase, welches diese Möglichkeit unterstützt). Eine dritte Methode ist die Manipulation des BIOS. Im BIOS wird der Interrupt-Befehl INT13h verändert, welcher unter anderem für die Steuerung der Schreibzugriffe auf die Festplatte zuständig ist.

1.5 Software

Neben den verbreiteten großen Softwarelösungen zur Imageerstellung, gibt es eine Vielzahl kleiner Open Source Programmen. Beispielsweise das in Linux integrierte dd oder weitere Programme wie dcfldd, dc3dd und ewfacquire. Die meisten Pro- gramme zur Erstellung eines Datenträgerimages erfüllen ihre Aufgabe. Eine dieser wichtigen Aufgaben ist es nicht lesbare Sektoren mit einer „0“ zu speichern und zu dokumentieren. Differenzierter ist die Wahl des entsprechenden Dateiformats. Als geeigneter Standard für forensische Duplikate haben sich Rohdatenformat (RAW) Expert Witness Format (EWF) und Advanced Forensic Format (AFF) behauptet.

1.5.1 Rohdatenformat (RAW)

RAW ist das älteste forensische Dateiformat um gesamte Datenträger in ihrer ganz- heit zu speichern. Es unterstützt keine Komprimierung. Zur Auswertung muss es immer entpackt sein. Metadaten zugehörig zum Datenträger wie zum Beispiel Has- hwerte müssen in einer weiteren Datei gespeichert werden. Großer Vorteil dieses Dateiformats ist, dass es von nahezu jedem forensischen System verarbeitet werden kann. Die gängigen Dateiendungen sind unter anderem *.raw, *.dd, *.img.

7 Kapitel 1. Vorüberlegungen

1.5.2 Expert Witness Format (EWF)

EWF ist ein proporitäres Dateiformat von der Firma EnCase. Es besitzt effektive Komprimierungsalgorithmen beim erstellten der Abbilder und beinhaltet, neben den eigentlichen Daten, viele Metainformationen über den Sicherungsprozess. EWF ist offengelegt, sodass Drittanbieter es nutzen können. Aktuell ist die Dateiformatver- sion EnCase6.

1.5.3 Advanced Forensic Format (AFF)

AFF ist ein Open Source Standart, welcher die gleichen Funktionen wie EFW bie- tet. Die mitgelieferten Bibliotheken von AFF besitzen die Funktion, das Duplikat zur laufzeit als RAW-Abbild einzubinden, dadurch wird die kompatibilität erhöht. Darüber hinaus hat es eine bessere Komprimierung [2].

1.5.4 Xmount

Xmount ist ein Programm für Linux, dass es dem Anwender ermöglicht, die oben ge- nannten Dateiformate in weitere Dateien zu mounten. So kann ein EWF-Abbild als Rohdatenformat bereitgestellt werden, wodurch sich die Kompatibilität erhöht. Es ermöglicht das Erstellen eines Schreibcaches, sodass mit der Kopie gearbeitet werden kann ohne das Original zu verändern. Beispielsweise wird ein EWF-Bootimage als vmdk-Datei mit Chache bereitgestellt und im Anschluss mit VMWare genutzt.

8 Kapitel 2. Rechtliche Betrachtung

2 Rechtliche Betrachtung

2.1 Einleitung

Dieses Kapitel soll einen kleinen Überblick über die rechtlichen Normen in Bezug auf Analyse von forensisch erhobenen Daten bzw. der Grundlage für die Erhebung der Daten überhaupt und deren Verwendung bieten. Es gibt grundlegende rechtliche Rahmenbedingungen die für eine forensische Ana- lyse oder allgemein die Erhebung von Daten getroffen und durchgesetzt werden müssen [3]:

• die Erhebung

• die Speicherung

• die Verarbeitung und Nutzung

• die Übermittlung

• die Berichtigung, Löschung und Sperrung

• Benachrichtigungs- und Auskunftspflichten

• die Kontrolle

• sowie Haftungs- und Strafvorschriften

Diese grundlegenden rechtlichen Rahmenbedingungen sind in diversen Gesetzen, Verordungen, Richtlinien und Verfahrensvorschriften geregelt. Hierzu zählen Ge- setze und Verordnungen wie Grundgesetz (GG)1, StGB2, Datenschutzgrundverord- nung (DSGVO)3 und Bundesdatenschutzgesetz (BDSG)4, um nur einige zu nennen.

1Es regelt die freiheitlich demokratische Grundordnung. 2Es regelt in Deutschland das materielle Strafrecht. Unter anderem sind hier die Voraussetzungen und Rechtsfolgen strafbaren Handelns bestimmt. 3Es regelt die Verarbeitung personenbezogener Daten durch die meisten Datenverarbeiter (private und öffentliche), vereinheitlicht EU-weit 4Es regelt zusammen mit den Landesdatenschutzgesetzen und anderen bereichsspezifischen Re- gelungen den Umgang mit personenbezogenen Daten, welche verarbeitet werden. Die Verarbei- tung kann manuell oder durch Informations- und Kommunikationssysteme erfolgen.

9 Kapitel 2. Rechtliche Betrachtung

Für den Bereich der forensischen Analyse gibt es hauptsächlich zwei Gruppen, welche Ermittlungen durchführen. Das sind zum einen IT-Forensiker, welche im privaten Sektor Ermittlungen, als Dienstleistung, durchführen und die staatliche Behörden, welche Ermittlungen aufgrund von Ermittlungsverfahren durchführen. Bei den Er- mittlungen ist die staatliche Behörde an Verfahrensvorschriften, wie die Strafpro- zessordnung (StPO), gebunden. Diese gelten so nicht für die privaten Ermittlungen, dennoch sind ihre Ermittlungshandlungen geregelt. Die Rechtmäßigkeit der Ermitt- lungen ergibt sich aus den allgemeinen Gesetzen [4].

2.2 Private Ermittlungen

Im Zuge von privaten Ermittlungen, aus welchen sich später auch staatliche Ermitt- lung (z. B. nach einer Anzeige) ergeben können, müssen die entsprechenden Beweise ebenfalls beweissicher erhoben werden. Nach § 202a Abs. 1 StGB ist das Ausspähen von Daten strafbar. Hiernach darf der IT-Forensiker ohne Erlaubnis des Verfügungsbefugten5 der Daten, diese nicht be- gutachten. Anhand der beauftragten forensischen Analyse durch einen Arbeitgeber, als Beispiel, kann man sehr gut den schmalen Grad von erlaubten und unerlaubten Analysen durch einen IT-Forensiker kenntlich machen. Bei dienstlichen Daten erfolgt die Erstellung und Speicherung von Daten im Rah- men des Dienstverhältnisses auf Weisung und Veranlassung des Arbeitgebers. Daher ist hier auch der Arbeitgeber über die Daten verfügungsbefugt. Somit ist es mög- lich, einen privaten IT-Forensiker mit der Analyse zu beauftragen, ohne dass dieser sich nach § 202a Abs. 1 StGB strafbar macht. Es verhält sich etwas anders, wenn private Daten von der Analyse betroffen sind. Private Daten sind Daten, welche gegen Zugriff Unbefugter besonders gesichert sind. Der Verfügungsberechtigte, in diesem Fall der Mitarbeiter, drückt mit diesen Schutzmaßnahmen aus, den Zugang zu den Daten zu verhindern oder zu erschweren. Zu diesen Schutzmaßnahmen zählt nicht das Kennwort zum Entsperren des Systems (z. B. Windows-Anmeldung). Die- se User-Kennung dient der datenschutzrechtlichen Zugangskontrolle, im Rahmen von Eingabekontrollen, der Zuordnung bestimmter Vorgänge zu einem Nutzer und nicht zur Sicherung von Daten gegen den Zugriff des Arbeitgebers. Eine Analyse der privater Daten darf nur mit Erlaubnis des Verfügungsberechtigten erfolgen [4].

5Verfügungsberechtigt = Inhaber der Eigentumsrechte/Verfügungsrechte

10 Kapitel 2. Rechtliche Betrachtung

2.3 Behördliche Ermittlungen

Bei behördlichen Ermittlungen gibt es sehr viele spezifische Gesetze, Verordnungen und Richtlinien, welche berücksichtigt werden müssen. Hierzu zählen zusätzlich zu den allgemeinen Gesetzen auch weitere wie StPO, Lan- despolizeigesetze6, Polizeigesetz (PolG) und Bundeskriminalamtsgesetze (BKAG). Die Erhebung der Daten, also z. B. die Herausgabe des Datenträgers oder die Erstel- lung einer Kopie des Datenträgers, ist grundsätzlich nur mit richterlicher Verfügung oder nach gesetzlichen Richtlinien zur Gefahrenabwehr zulässig. Werden Daten unrechtmäßig erhoben, können diese nicht als Beweismittel herange- zogen werden. Bei einer forensischen Analyse handelt es sich grundsätzlich um eine Durchsuchung eines Datenträgers, um Beweise zu finden oder Sachverhalte zu analysieren und ge- gebenenfalls dadurch auf neue Beweise zu stoßen. Nach § 110 StPO ist eine Durchsuchung von elektronischen Speichermedien ge- rechtfertigt. Die „Sicherung“ der Daten erfolgt im Regelfall durch die freiwillige Herausgabe des Datenträgers oder durch die Beschlagnahme des Datenträgers gem. § 98 StPO. Danach kann eine Durchsuchung, nach richterlicher bzw. staatsanwaltschaftlicher Anordnung, erfolgen. Ein weiteres Ermittlungsinstrument ist die Online-Durchsuchung. Hierbei handelt es sich um eine verdeckte Durchsuchung, diese wird ohne Wissen des Betroffenen durchgeführt. Online-Durchsuchungen sind nach § 100b StPO möglich. Allerdings werden an ihre Anordnung besonders hohe Maßstäbe gesetzt, da hier ein Eingriff in die Grund- und Persönlichkeitsrechte stattfinden [5].

2.4 Zusammenfassung

Es müssen auch bei der forensischen Analyse von Daten die Grundrechte gewahrt werden. Dieses wird durch vielerlei Gesetze und Verordnungen garantiert. Dadurch ist es dem IT-Forensiker nur innerhalb bestimmter Rahmenbedingungen möglich Analysen vorzunehmen. Grundsätzlich bedarf es der Zustimmung des Verfügungs- berechtigten oder entsprechende richterliche oder staatsanwaltliche Anordnungen, um eine Analyse von Datenträgern durchzuführen.

6Landespolizeigesetze z. B. PolG NW, SOG M-V

11 Kapitel 2. Rechtliche Betrachtung

Daten müssen so sicher gespeichert werden, dass unbefugter Zugriff, aber auch ver- sehentlicher Verlust nicht möglich ist - dies gilt auch bei der Übertragung, z. B. von einer Behörde zur Nächsten. Daten, die für den ursprünglichen Zweck der Speicherung nicht mehr benötigt wer- den, müssen gelöscht werden.

12 Kapitel 3. Speichermedien

3 Speichermedien

3.1 Einleitung

Warum ist es interessant sich verschiedene Speichermedien/Speichertypen anzu- schauen? Festplatten sind Speichermedien, welche forensisch analysiert werden kön- nen. Sie können wertvolle Informationen liefern, weil ein Löschen von Daten durch den Anwender nicht zwangsläufig ein permanentes und unwiderrufliches Löschen der Daten von der Festplatte zur Folge hat. Daraus ergeben sich aus forensischer Sicht einige Möglichkeiten der Analyse von Datenträgern. Bei einer forensischen Analyse muss man aber ebenfalls auf die Integrität der Daten achten, sodass diese Daten bei der Image-Erstellung oder einer Datensicherung im Originalzustand bleiben und keine Veränderung erfahren. Da es sich bei einem RAID-System um einen Festplattenverbund (ein oder mehrere Datenplatten) handelt, welche auf verschiedene Weisen zusammenarbeiten, um un- ter anderem eine erhöhte Zugriffsgeschwindigkeit oder eine bessere Verlustsicherheit der Daten zu erreichen wird im Folgenden auf die aktuell wichtigsten Speicherty- pen magnetische Speicher und Flash-Speicher eingegangen, welche hauptsächlich für Festplattenverbunde verwendet werden. Es sollen in diesem Kapitel die Grundzüge und Besonderheiten der oben genannten Speichertypen kurz herausgearbeitet wer- den.

3.2 Magnetspeicher

Zum einen gibt es Magnetspeicher, wozu auch die Hard Drive Disk (HDD), Dis- ketten oder Magnetbänder gehören. Bei magnetischen Speichern werden Bits durch magnetische Bereiche mit gegensätzlicher Polarität dargestellt. Sie bestehen aus be- weglichen Teilen, weshalb sie grundsätzlich stoßanfällig sind, was sie für den Einsatz in stationärer Hardware (z. B. RAID-System) prädestiniert. Da Disketten im Laufe der Zeit von anderen Speichermedien, wie CDs oder DVDs und USB-Sticks verdrängt wurden wird in dieser Arbeit nicht weiter auf diese eingegangen. Magnetbänder sind

13 Kapitel 3. Speichermedien weniger als Festplatte im herkömmlichen Sinne (Nutzung im Computer als Speicher zum Arbeiten) geeignet, werden aber grundsätzlich als Backup-Medium verwendet, da bei Magnetbändern ein Zugriff auf die Daten nur sequenziell möglich ist. Häufiger im Einsatz befindlich sind HDDs. Hierbei handelt es sich um Festplat- ten, welche in einem vakuumverschweißten Gehäuse mit zumeist zwei übereinander rotierenden Magnetplatten auf einer gemeinsamen, drehbaren Achse untergebracht sind. Zum Datenzugriff sind zwei übereinander angeordnete Lese- und Schreibköpfe zwischen den Platten untergebracht. Anders als bei Magnetbändern ist ein direkter Zugriff (nicht sequenziell) auf die Daten möglich, da die einzelnen Festplatten in Spuren und Sektoren unterteilt sind.

3.2.1 Speicherung auf einer HDD

Das Speichern der Daten auf der Festplatte erfolgt durch die Magnetisierung kleins- ter Eisenpartikel. Diese Eisenpartikel sind auf der Oberfläche der Magnetplatten aufgetragen. Eine Festplatte muss, damit die Daten wiedergefunden werden kön- nen, eingeteilt werden. So wird eine Unterteilung von außen nach innen in Spuren vorgenommen, welche man sich als konzentrische Kreise vorstellen kann. Die Spuren- dichte, der Abstand der Spuren, bestimmt die Speichermenge. Zwei untereinander liegende Spuren heißen Zylinder und besitzen eine Zylinderadresse. Die Spuren wer- den dann wiederum in noch kleinere Abschnitte unterteilt, welche sich Sektoren oder Block nennen. Sie entsprechen einem Kreisausschnitt. Diese Blöcke sind die kleinste Einheit einer Festplatte, welche verwendet werden können. Blöcke mit einer Größe von 64 KByte sind keine Seltenheit. Mehrere Blöcke können zu einem Cluster zu- sammengefasst werden (beinhaltet zwischen einem und 128 Sektoren), welches die Speicherverwaltung großer Datenmengen erleichtert. Es ist nur möglich, dass Clus- ter von dem Betriebssystem angesprochen werden, nicht jedoch einzelne Sektoren. Wenn man eine Datei speichert, entspricht die Größe dieser Datei aber nicht zwangs- läufig der Größe eines oder mehrerer Cluster. Wenn wir uns vorstellen, dass wir einen Cluster aus acht Sektoren haben und die Datei 6,5 Sektoren beschreibt, so bezeich- net man die unbeschriebenen 1,5 Sektoren als File-Slack. Diese File-Slacks spielen für die forensische Analyse eine wichtige Rolle. Der File-Slack kann Informationen über gelöschte Dateien, genutze Programme usw. enthalten.

14 Kapitel 3. Speichermedien

3.2.2 Löschen von Daten auf einer HDD

Hauptsächlich gibt es zwei Möglichkeiten wie Daten „gelöscht“ werden. Es ist mög- lich, dass der Index-Eintrag einer Datei gelöscht wird - hier kann man sich ein In- haltsverzeichnis in einem Buch vorstellen welches herausgerissen wird, was zur Folge hat, dass die Daten selbst weiterhin, allerdings unreferenziert, auf der Festplatte zu finden sind (unallocated area; nicht allokierter Bereich). Sie werden dem Anwen- der nicht mehr im Datei-Explorer angezeigt, weshalb dieser von einer „Löschung“ ausgeht. Hier wird vom System ein Flag gesetzt, welches die Datei nur als gelöscht kennzeichnet. Andererseits wird eine wirkliche Löschung der Daten nur durch das Überschreiben der Datei ermöglicht, je häufiger dieses Überschreiben stattfindet je sicherer ist die vollständige Löschung der Dateien.

3.2.3 Forensische Relevanz

Sofern die Sektoren nicht überschrieben wurden, besteht die Möglichkeit die Da- ten, auch wenn diese nicht mehr referenziert sind, wiederherzustellen. Erst mit dem Überschreiben der Sektoren, mit neuen Daten, gehen die Daten in diesen Sektoren verloren.

3.3 Flash-Speicher

Ein weiteres Speichermedium ist der Flash-Speicher. Ein Flash-Speicher ist auf der Basis der Electrically Earsable Programmable Read-Only Memory (EEPROM)- Technologie entwickelt. Es handelt sich hierbei um eine elektrische Speichermethode, welche nichtflüchtig ist, weshalb die Daten auch bei stromlosen Zustand weiter bestehen bleiben. Das Speichern auf diese Weise hat einen schnellen Lese- und Schreibzugriff zur Folge, weshalb ein Flash-Speicher schneller als ein magnetischer Speicher ist, da hier keine zusätzlichen mechanischen Teile zum Lesen oder Schreiben der Daten verwendet werden muss. Ein Nachteil der Flash-Speicher ist hingegen die begrenzte Lebensdauer. Diese begrenzte Lebensdauer wird durch die vorhandene Oxidationsschicht verursacht, welche zum dauerhaften Speichern der Daten benötigt wird. Bei schreibendem Zugriff gelangen Elektroden durch diese Oxidationsschicht, wobei diese jedes Mal etwas mehr beschädigt wird.

15 Kapitel 3. Speichermedien

3.3.1 Speicherung auf einer SSD

Flash-Speicher ist blockweise organisiert. Typischerweise hat ein Speicherblock 128 bis 512 kByte. Die Blöcke sind üblicherweise zwischen 128 kByte und 512 kByte groß. Selbst wenn es nur um ein paar Bit geht, welche gespeichert werden müs- sen, so muss der ganze Block neu geschrieben werden. Der Controller ist für die Steuerung der Speicher- und Lesezugriffe zuständig. Er kontrolliert, welche Blö- cke bzw. dessen Speicherzellen angesprochen werden. Hier versucht der Controller entsprechend ein Balancing (Wear-Leveling) zwischen häufiger und weniger häufig genutzen Speicherzellen zu bewahren, sodass weniger häufig genutzte Speicherzellen vorrangig angesprochen werden. Das erhält die Lebensdauer, da bei jedem Schreib- zugriff die Sperrschicht und damit die Lebensdauer der Speicherzellen immer weiter verringert wird. Aus diesem Grund versucht das Wear-Leveling mithilfe von ver- schiedenen Verfahren und Methoden die Lebensdauer der Speicherzellen zu verlän- gern, indem der Controller die Schreibzugriffe auf die verschiedenen Speicherblöcke gleichmäßig verteilt. Es gibt ein Problem, welches beim statischen Wear-Leveling auftritt und die Zusammenarbeit mit dem Mechanismus des Betriebssystem betrifft. Wenn Dateien gelöscht (z. B. eine Datei wird im Datei-Explorer gelöscht) werden, bekommt der Flash-Controller, dieses erstmal nicht mit. Die Dateien werden erst vorerst nicht von dem Controller, auf der Festplatte selbst, gelöscht. Das Betriebs- system hat jedoch für sich die Kennzeichnung (Flag), dass der Platz anderweitig genutzt werden kann. Jetzt kann es beim statischen Wear-Leveling passieren, dass der Controller, mit viel Aufwand, anfängt die Dateien zu verschieben (aufgrund des Speicherzellen-Managements). Das würde hier aber keinen Sinn ergeben, da die Da- teien vom Anwender nicht mehr benötigt werden und grundsätzlich als gelöscht zu werten wären.

3.3.2 Löschen von Daten auf einer SSD

Hierbei hilft der TRIM-Befehl, mit welchem das Betriebssystem dem Flash- Controller mitteilt, welche Speicherbereiche nicht mehr gebraucht werden. Da Daten grundsätzlich nicht endgültig gelöscht, sondern zum Löschen markiert werden, wird eine zusätzliche Garbage-Collection benötigt. Der TRIM-Befehl ruft die Garbage- Collection auf und entfernt die als gelöscht markierten Daten auch physikalisch. Physikalisch heißt, die Zellen werden entladen und die Informationen endgültig ent- fernt. Der TRIM-Befehl ist nicht Bestandteil des Betriebssystems.

16 Kapitel 3. Speichermedien

3.3.3 Forensische Relevanz

Bei einer SSD ist, sofern der TRIM-Befehl und die Garbage-Collection aktiviert sind, eine Herstellung bzw. Auslesen von gelöschten Daten sehr schwierig. Als ge- löscht markierte Daten und dessen Speicherzellen werden durch den TRIM-Befehl (inklusive Garbage-Collection) nicht nur aus dem „Verzeichnis “ gelöscht und damit die Referenz zu den Daten, sondern es werden die Speicherzellen entleert, wodurch die Information permanent gelöscht wird. Es gibt aber auch die Möglichkeit den TRIM-Befehl zu deaktivieren, das hat zur Folge, dass die Daten nur im „Verzeich- nis“ gelöscht werden, also nur die Referenzen. Erst wenn die Zellen mit neuen Daten beschrieben werden, werden diese vorher geleert und können erst in diesem geleerten Zustand neu beschrieben werden. Also ist es erst ab diesem Zeitpunkt nicht mehr möglich, die als gelöscht markierten Daten auszulesen.

3.4 Hybride

Ein weiterer Ansatz ist der Einsatz von sogenannten Solid State Hybrid Drive (SSHD), also Hybridfestplatten, bei denen der Flash-Speicher nur als Schreibpuffer zur Steigerung der Performance fungiert. Der Einsatz dieser Festplatten würde dem Nutzer eine höhere Schreibgeschwindigkeit und einen geringeren Stromverbrauch bringen und durch die Speicherung der Daten auf einem Magnetspeicher dennoch die Vorteile einer HDD gepaart mit der Schnelligkeit einer SSD [6].

3.5 Zusammenfassung

Grundsätzlich ist es möglich von Festplatten die Daten, auch wenn diese vermeintlich vom Anwender oder System gelöscht wurden, wiederherzustellen. Bei einer HDD ist die Wiederherstellung möglich, bis die entsprechenden Blöcke überschrieben werden. Hier gilt, je häufiger das Überschreiben stattgefunden hat, je wahrscheinlicher ist die Vernichtung der Daten auf der Festplatte. Bei der SSD gibt es zwei Möglichkeiten. Zum ist der TRIM-Befehl und die Garbage- Collection aktiv und wird vom entsprechenden Betriebssystem angesprochen, dann ist die Wahrscheinlichkeit, dass die Daten wiederhergestellt werden können sehr gering, da hier die Speicherzellen auch physikalisch geleert werden. Wenn hingegen der TRIM-Befehl nicht aktiv genutzt wird, so verhalten sich die Möglichkeiten der

17 Kapitel 3. Speichermedien

Wiederherstellung ähnlich die der HDD. Es ist hier ebenfalls möglich, die Daten auch wenn vermeintlich vom Anwender gelöscht wiederherzustellen.

18 Kapitel 4. Analyse eines Datenträgerverbundes

4 Analyse eines Datenträgerverbundes

4.1 Einleitung

Bei einer Redundant Array of Independent Disks (RAID)-Konfiguration handelt es sich um den Verbund mehrerer physikalischer Festplatten oder Partitionen zu einer logischen Festplatte oder Partition. Derartige RAID-Verbunde finden sich häufig auf den Computern eines Beschuldig- ten. RAID-Verbunde werden von diesen eingerichtet um eines von zwei Ziele zu errei- chen: Die Verfügbarkeit von Daten gegen Ausfälle zu erhöhen oder die Zugriffsge- schwindigkeit auf die Daten zu verbessern. Hierbei ist es auch möglich beide Ziele zu kombinieren. Die Erhöhung der Zugriffsgeschwindigkeit wird erreicht, indem die Daten zu gleichen Teilen auf mehreren Festplatten verteilt werden. Hier spricht man vom „Striping“ (dt.: „Streifen“). Eine mögliche Konfiguration (RAID-0) ist in Bild 4.1 dargestellt. Die Erhöhung der Verfügbarkeit erreicht man durch das Spie- geln (en.: „Mirroring“, mögliche Konfiguration RAID-1) oder durch Berechnung von Paritäten von zwei oder mehreren „Streifen“ (mögliche Konfiguration: RAID-5, Sie- he Bild 4.2). Beide oben genannte Ziele können erreicht werden, indem z. B. eine RAID-Konfiguration gewählt wird, die beides kombiniert (z. B. RAID-10, Siehe Bild 4.3). Neben den vorgenannten gängigen RAID-Layouts, existieren einige weitere teils

Bild 4.1: Schematische Darstellung einer RAID-0 Konfiguration mit zwei Datenträgern, Quelle: Wikipedia [7]

19 Kapitel 4. Analyse eines Datenträgerverbundes

Bild 4.2: Schematische Darstellung einer RAID-1 und einer RAID-5 Konfiguration mit zwei bzw. vier Datenträgern, Quelle: Wikipedia [7]

Bild 4.3: Schematische Darstellung einer RAID-10 Konfiguration mit vier Datenträgern, Quelle: Wikipedia [7] exotisch anmutende Layouts, bei denen die Systemadministratoren im Einzelfall be- sonders hohe Anforderungen festgelegt haben. Ein RAID 51 (Siehe Bild 4.4) wäre etwa die Spiegelung zweier RAID5 Verbunde. Bei dieser Konfiguration wäre der Ausfall von drei der mindestens sechs Festplatten möglich, ohne dass die Verfügbarkeit der Daten eingeschränkt wäre. Die verfügbare Kapazität wäre bei sechs Platten identischer Größe jedoch auf nur 33% begrenzt. Eine weniger exotische Konfiguration, die dennoch mehrere Ausfälle kompensieren kann bildet das RAID-6. Bei diesem RAID-Layout wird beim Einsatz von vier oder mehr Platten der Ausfall von zwei Platten kompensiert, ohne dass die Verfügbarkeit der Daten beeinträchtigt wird. Bei einem RAID-6 mit vier Festplatten stünden also

Bild 4.4: Schematische Darstellung einer RAID-51 Konfiguration mit sechs Datenträgern, Quelle: Wikipedia [7]

20 Kapitel 4. Analyse eines Datenträgerverbundes

Bild 4.5: Schematische Darstellung einer RAID-6 Konfiguration mit fünf Datenträgern, Quelle: Wikipedia [7] mindestens 50% der Kapazität der Festplatten zur Verfügung. RAID-Systeme lassen sich hinsichtlich ihrer Implementierung im System unterscheiden. Einerseits existieren Hardware-RAID Systeme. Bei derartigen Systemen kümmert sich ein eigener Controller, dass die Daten im Sinne des RAID-Layouts korrekt auf den physikalischen Festplatten verteilt werden. Gegenüber dem Computersystem erscheinen die Vielzahl physikalischer Festplatten jedoch als eine einzige logische Platte, die auch als solche dann vom Betriebssystem behandelt werden. Neben dem Hardware-RAID System existieren auch Software-RAID Lösungen. Diese werden also vom Betriebssystem bzw. von Diensten und Prozessen des Computer-Systems verwaltet und letztlich ebenfalls als eine logische Platte bereit- gestellt. Eine Misch-Lösung beider Implementierungen stellen s. g. „Host-RAID“ Systeme dar, die in der untersten Preisspanne kommerzieller Lösungen anzusiedeln sind. Sie werden im Linux-Jargon oft als „Fake-“ [8] bezeichnet, da sie letzten Endes, wie beim Software-RAID, ebenfalls die Ressourcen des Computers beanspruchen. Hierbei sind sie jedoch ebenfalls an den Controller der Hardware gebunden. Sie kombinieren somit streng genommen die Nachteile beider o. g. Lösungen. Sie finden sich heute auf diversen Mainboards vorinstalliert, so dass sie weiterhin eine gewisse Relevanz haben, sich jedoch im Vorgehen nicht sonderlich von Hardware- RAID Systemen unterscheiden. In den beiden folgenden Kapiteln wird anhand eines konkreten Beispiels das Vorge- hen bei der forensischen Analyse von Festplatten eines Software-RAID und bei der Analyse eines Hardware-RAID Systems beschrieben.

4.2 Hardware-RAID

Hardware-RAIDs sind Software-RAIDs in Punkto Flexibilität und bei der Leistung zur Wiederherstellung („rebuild“) von Daten i. d. R. im Nachteil. Zum Einsatz

21 Kapitel 4. Analyse eines Datenträgerverbundes kommen sie i. d. R. noch dort, wo es um möglichst hohe Schreib-Leistung, bei zeit- gleich möglichst geringem Ressourcen-Bedarf des Betriebssystems ankommt. Dies wird durch verschiedene Strategien erreicht, wie dem asynchronen Schreiben von Paritätsinformationen, einer dedizierter Central Processing Unit (CPU) und einem (ggf. durch eine Batterie gepufferten) Schreibcache. Die o. g. Faktoren führen dazu, dass verschiedene Algorithmen den verschiedenen RAID-Controllern zugrunde liegen. Zugleich setzen solche Hardware-RAIDs im Gegensatz zu Software-RAIDs häufig auf proprietäre geschlossene Standards zur Speicherung der Meta-Informationen. Selbst innerhalb derselben Hersteller ist eine Kompatibilität der Controller nicht immer sichergestellt. Idealerweise sollte daher das Auslesen von Datenträgern mit demselben Controller stattfinden, mit dem die Daten auch auf die Platten geschrieben wurden. Dies ist in der Praxis aber nicht immer ohne weiteres möglich (etwa bei Ausfall des Controllers) oder bedarf zumindest einer größeren Vorbereitung (etwa beim Zugriff auf größere Storage Rack ). Daher besteht der Wunsch, möglichst ohne die originären Hardware-Controller Da- tenträger zumindest auslesen zu können, so dass die installierten Dateisysteme für den Forensiker zugänglich werden. Tatsächlich existieren Software-Produkte, die sich genau dieser Herausforderung stellen. Darunter X-Ways, R-Studio, dmde oder dmraid. Die Kosten für die Produkte schwanken von rund 1.000 EUR pro Lizenz für X-Ways oder R-Studio (commercial license) bis hin zu kostenlosen Lösung mit dmraid. Für diese Arbeit wurde ein RAID Controller JMB394 von JMicron [9] genutzt, der u.a. das RAID-Level 0, 1, 5 und 10 unterstützte, das hier zum Einsatz kam. Dieser Controller war im Produkt „Sharkoon 5-Bay RAID Station“ installiert. Betrieben wurden drei Festplatten im RAID 5. Dieses Verbund wurde via USB 3.0 an einem Windows PC installiert und mit einer NTFS Partition über 1 GB formatiert. Die Platten des RAIDs wurden einzeln forensisch erfasst und sollen analysiert werden. Für die Analyse wurden die Produkte X-Ways und dmraid im Vorhinein ausge- schlossen. Das erstgenannte Produkt stand aus Kostengründen nicht zur Verfügung. Das Tool dmraid ist zwar in vielen Linux-Distributionen enthalten, die sich auf forensische Analyse spezialisiert haben und stand somit auch grundsätzlich zur Ver- fügung. Ein Blick in die man-pages offenbarte aber, dass - je nach Version - der o. g. RAID-Controller zwar verfügbar war, jedoch nicht das gewählte RAID-Level 5 unterstützte. Die Produkte X-Ways, R-Studio und dmde werben damit ein RAID anhand der

22 Kapitel 4. Analyse eines Datenträgerverbundes

Bild 4.6: Imagedatei öffnen in R-Studio vorliegenden Festplatten auf Basis von heuristischen Algorithmen identifizieren und auslesen zu können. Bei dmde gelang dies zwar nicht, es ist aber nicht auszuschließen, dass hier ein Anwender-Fehler vorlag. Die Benutzeranleitungen und Sekundar-Quellen erwiesen sich hier leider nicht als hilfreich. Für die folgenden Schritte wurde R-Studio [10] eingesetzt. Dieses Tool ist zwar mit 899 USD für eine „commercial use“ Lizenz, auch eines der teureren, jedoch steht eine kostenlose Variante zur Verfügung, die es erlaubt Daten bis 250 KB online zu rekonstruieren. Das Erstellen eines logischen Abbildes des Dateisystems auf Basis der logischen Abbilder des rekonstruierten RAID-Verbundes war ebenfalls uneinge- schränkt möglich. Im Folgenden wird davon ausgegangen, dass der Forensiker am betroffenen Com- puter drei Festplatten vorfindet, zu denen er jeweils ein Abbild erstellen konnte, welche jeweils für die weitere Analyse genutzt werden können. Die Abbilder liegen im EnCase6 Format vor.

4.2.1 Schritt 1: Einbinden der Abbilder

Zunächst werden die Abbilder unter Nutzung von xmount ausgelesen und dessen Inhalt im Dateisystem des Forensikers gemountet.

1 > xmount --in ewf hdd1.E01 /mnt/disk1 2 > xmount --in ewf hdd2.E01 /mnt/disk2 3 > xmount --in ewf hdd3.E01 /mnt/disk3 4 > ls -rR /mnt/disk* 5 /mnt/disk3: 6 hdd3.info hdd3.dd 7 8 /mnt/disk2: 9 hdd2.info hdd2.dd 10 11 /mnt/disk1: 12 hdd1.info hdd1.dd

4.2.2 Schritt 2: Öffnen der Abbilder in R-Studio

Zunächst müssen die Abbilder in R-Studio über den Button „Image öffnen“ eingele- sen werden (Siehe Bild 4.6). Der Dialog „Imagedatei öffnen“, der nun gestartet wird,

23 Kapitel 4. Analyse eines Datenträgerverbundes

Bild 4.7: R-Studio: Imagedatei öffnen erwartet zunächst Dateitypen, mit denen hier nicht gearbeitet wurde. R-Studio erwartet hier allen voran, die eigenen proprietären Image-Dateitypen *.rdr (Siehe Bild 4.7). Das stellt jedoch kein Problem dar, da alternativ auch die weitaus verbreiterten DD-Dateien ausgewählt werden können, nachdem im Auswahlmenü „Dateien des Typs“ die Suchmaske „Alle Dateien ( * )“ ausgewählt wurde (Siehe Bild 4.8).

4.2.3 Schritt 3: Modellierung des RAID-Layouts

Nun kann R-Studio seine Stärke ausspielen, indem es den Anwender unterstützt, das korrekte RAID-Layout zu ermitteln. Zunächst wählt der Anwender im Menü „Virtuelles RAID erstellen“ den etwas unglücklich beschrifteten Untermenüpunkt „Virtuellen Block erstellenRAID& Automatisch Erkennen“ (Siehe Bild 4.9). In der Baum-Darstellung der „Geräte-Ansicht“ erscheint nun ein neuer Zweig „Virtu- elle Volumesets und RAIDs“. Hier wählt der Anwender den ersten Unterknoten aus. Bei der hier dynamisch vergebenen ebenfalls unglücklichen Beschriftung herrscht Verwechslungsgefahr. An der Stelle, wo in der folgenden Abbildung „Virtual Block RAID 1“ zu lesen ist, bildet die Ziffer eine Sequenz, die nichts mit dem RAID-Level zu tun hat, das zu diesem Zeitpunkt noch ermittelt werden muss (Siehe Bild 4.10). Auf der rechten Seite wird nun ein Bereich „Parent“ angeboten, über den nun die Teile des RAID-Verbundes zusammengestellt und die Konfiguration bestimmt wer- den kann (Siehe Bild 4.11). Hierzu wählt der Anwender den offensichtlichen Button

24 Kapitel 4. Analyse eines Datenträgerverbundes

Bild 4.8: Button Image öffnen in R-Studio

Bild 4.9: Virtuellen Block erstellen in R-Studio

Bild 4.10: Die Geräte-Ansicht von R-Studio

25 Kapitel 4. Analyse eines Datenträgerverbundes

Bild 4.11: R-Studio: Der Bereich parent

Bild 4.12: R-Studio: RAID-Parameter

„Automatische Erkennung“ aus. Der folgende Dialog erscheint und bietet nach einer gewissen Analyse-Zeit dem Anwender valide RAID-Layouts aus, die der Anwender auswählen und mit dem Button „Anwenden“ bestätigen muss (Siehe Bild 4.12). Hierbei kann es dazu kommen, dass mehrere mögliche Layouts kompatibel sind und angewandt werden können. Letztlich obliegt es dann dem Anwender, das korrek- te Layout zu wählen. Hierbei hilft es, dass R-Studio mit wenigen Klicks und ohne spürbare zusätzliche Ladezeit das Layout wechseln kann, um Alternativen durchzu- probieren. Ferner unterstützen hierbei die Funktionen RAID-Konsistenz prüfen (Siehe Bild 4.13) oder der Menüpunkt Scannen (Siehe Bild 4.14). Über die Funktion RAID-Konsistenz prüfen, wird ermittelt, ob die Blöcke konsis- tent sind - also ob Spiegelungen tatsächlich identisch und ob Paritäten tatsächlich korrekt errechnet werden.

26 Kapitel 4. Analyse eines Datenträgerverbundes

Bild 4.13: R-Studio: RAID-Konsistenz

Bild 4.14: R-Studio: Menüpunkt scannen...

27 Kapitel 4. Analyse eines Datenträgerverbundes

Bild 4.15: R-Studio: Darstellung der RAID-Konsistenz

Bild 4.16: R-Studio: Parameter für die Scannen-Funktion

Abbildung 4.15 stellt eine positiv verlaufende Konsistenz-Prüfung dar. Grüne Mar- kierungen sind hierbei korrekt errechnete Blöcke und weiße Blöcke sind leer bzw. mit Nullen belegt, so dass diese Bereiche weiß hinterlegt werden. Bei der Funktion „Scannen“ ermittelt R-Studio valide Blöcke, die auf ein bestimmtes Dateisystem oder einen bestimmten Dateitypen hinweisen. Dieser Prozess kann sehr zeitaufwän- dig sein, daher lohnt es sich zu überlegen, ob Dateisysteme ausgeschlossen werden können und ob man wirklich nach allen Dateitypen suchen möchte oder vielleicht nur nach speziellen - z. B. Office Dokumenten oder Bildern. In Abbildung 4.16 wurden Dateisysteme vorausgewählt, die bei einem Windows-PC üblich wären. Über den Button „Bekannte Dateitypen“ lassen sich einzelne Dateity- pen oder -Gruppen an- und abwählen (Siehe Bild 4.17). Da die Laufzeiten tatsächlich

28 Kapitel 4. Analyse eines Datenträgerverbundes

Bild 4.17: R-Studio: Dateitypen beim Scannen auswählen

Bild 4.18: R-Studio: Übersicht des Fortschritts beim Scannen erheblich sein können, lohnt es sich - für die Identifikation des RAID Layouts - auch den zu analysierenden Bereich einzuschränken und bei der Scanansicht „Einfach (nur Scanfortschritt; schneller.)“ auszuwählen. (Siehe Bild 4.18) Nach einem solchen Scan stehen dem Anwender bereits Möglichkeiten zur Verfügung durch die logische Struktur des Dateisystems zu navigieren und Dateien jeweils wiederherzustellen bzw. einzusehen. Nachdem der Anwender jenes RAID-Layout ausgewählt hat, das ein konsistentes RAID liefert, valide Dateisysteme erkennt und keine - oder möglichst wenige - kor- rupte einzelnen Dateien ermittelt, wird der Anwender diesen Zustand exportieren wollen. Dies ermöglicht ihm die physikalische Abstraktionsebene des RAID-Systems zu entfernen und dessen logische Abbildung zu erzeugen (Siehe Bild 4.19). Hierzu öffnet der Anwender das Menü zum Eintrag „Virtual Block RAID 1“ und wählt den Menü-Eintrag „Image erstellen. . . “ aus. Im folgenden Dialog bietet R-Studio erneut primär das eigene proprietäre Image- Format an.

29 Kapitel 4. Analyse eines Datenträgerverbundes

Bild 4.19: R-Studio: Image erstellen

Bild 4.20: R-Studio: Byte-Für-Byte Image erstellen

Neben der Tatsache, dass dieses den Anwender an das R-Studio Produkt-Portfolio bindet, erlaubt das Format im Vergleich zu EnCase6 ein nur schwaches Kompressi- onsverhältnis. Es bietet auch ansonsten wenige Zusatzfeatures, die uns - die Autoren - dazu verleiten würden, dieses Format dennoch zu empfehlen. Für eine Aufbewahrung und/oder forensische Weiterverarbeitung empfehlen wir daher viel mehr den Umweg über ein Byte-für-Byte-Image, dass im Anschluss mit einem geeigneten Tool platzsparend komprimiert und weiterverarbeitet wer- den kann (Siehe Bild 4.20). Womöglich hilfreich kann jedoch noch sein, die „Scan- Informationen“ im entsprechenden Reiter zu speichern (Siehe Bild 4.21).

30 Kapitel 4. Analyse eines Datenträgerverbundes

Bild 4.21: R-Studio: Scan Informationen speichern

4.3 Software Lösungen unter Linux

4.3.1 Software-RAID

In diesem Kapitel geht es um eine Software RAID Konfiguration, bei der wir da- von ausgehen, dass sie auf Basis des weit verbreiteten Multiple Disk (MD) vorliegt. MDADM ist das entsprechende Administrationstool [11]. Die möglichen Konfigurationsmöglichkeiten können vielseitig sein, denn es ist mög- lich mit MDADM verschiedenste RAID Layouts zu definieren und miteinander zu verschachteln. Es können sowohl einzelne Dateien, ganze RAID-Verbunde, Partitio- nen und auch ganze Festplatten mit einander verbunden werden. Die beiden letztgenannten Optionen sind jedoch die häufigsten Anwendungsfälle und daher bereits Grund genug, dass ein Forensiker zunächst ein Abbild sämtlicher Platten erstellen sollte. Im Folgenden wird davon ausgegangen, dass der Forensiker am betroffenen Compu- ter fünf Festplatten vorfindet, zu denen er jeweils ein Image erstellen konnte, das jeweils nun für die weitere Analyse genutzt werden kann. Die Abbilder liegen im EnCase6 Format vor. Das gewählte Analyse-System verfügt über die SleuthKit Software-Sammlung.

Schritt 1: Einbinden der Abbilder

Zunächst werden die Abbilder unter Nutzung von xmount ausgelesen und dessen Inhalt im Dateisystem des Forensikers gemountet. Hierbei ist es wichtig, den Parameter --cache zu verwenden, um eine s. g. Over- lay Datei anzulegen. Eine derartige Datei erlaubt es dem System bei der späteren

31 Kapitel 4. Analyse eines Datenträgerverbundes

Einbindung der Datenträger Schreibbefehle entgegen zu nehmen. Jedoch werden die Schreibbefehle nicht im Datenträger-Abbild geschrieben, sondern in einer separaten Schicht - dem Overlay - umgesetzt. Dies erst erlaubt es später die Datenträger via MDADM zu mounten - ohne, dass die originalen Abbilder beschädigt werden.

1 > xmount --cache cache1.ovl --in ewf hdd1.E01 /mnt/disk1 2 > xmount --cache cache2.ovl --in ewf hdd2.E01 /mnt/disk2 3 > xmount --cache cache3.ovl --in ewf hdd3.E01 /mnt/disk3 4 > xmount --cache cache4.ovl --in ewf hdd4.E01 /mnt/disk4 5 > xmount --cache cache5.ovl --in ewf hdd5.E01 /mnt/disk5

Im Dateisystem finden sich nun RAW- bzw. DD-Files von den jeweiligen Platten, die nun über losetup einem loopback Device zugeordnet werden. Die ursprünglichen Datenträger stehen somit fortan als Blockdevice zur Verfügung.

1 > losetup /dev/loop1 /mnt/disk1/hdd1.dd 2 > losetup /dev/loop2 /mnt/disk2/hdd2.dd 3 > losetup /dev/loop3 /mnt/disk3/hdd3.dd 4 > losetup /dev/loop4 /mnt/disk4/hdd4.dd 5 > losetup /dev/loop5 /mnt/disk5/hdd5.dd

Schritt 2: Identifikation von MDADM Volumes

Durch Eingabe des folgenden Befehls, ermittelt MDADM das RAID-Layout des jeweiligen Blockdevices.

1 > mdadm --examine /dev/loop1

Die Ausgabe des Befehls lautet für die erste beliebige Platte

1 /dev/loop1: 2 Magic : a92b4efc 3 Version : 1.2 4 Feature Map : 0x0 5 Array UUID : 6041aacf:9d4400c5:4e5253d7:1b3e05d7 6 Name : suspect:0 7 Creation Time : Sat Apr 13 17:57:05 2019 8 Raid Level : raid6 9 Raid Devices : 5 10 11 Avail Dev Size : 16758784 (7.99 GiB 8.58 GB) 12 Array Size : 25138176 (23.97 GiB 25.74 GB) 13 Data Offset : 18432 sectors 14 Super Offset : 8 sectors 15 Unused Space : before=18352 sectors, after=0 sectors 16 State : clean 17 Device UUID : fd6ed775:c28fb7a1:f547b069:848f14be 18 19 Update Time : Sat Apr 13 18:05:41 2019 20 Bad Block Log : 512 entries available at offset 16 sectors 21 Checksum : 91d8e17e - correct

32 Kapitel 4. Analyse eines Datenträgerverbundes

22 Events : 129 23 24 Layout : left-symmetric 25 Chunk Size : 512K 26 27 Device Role : Active device 1 28 Array State : AAAAA (’A’ == active, ’.’ == missing, ’R’ == replacing)

In der Ausgabe lässt sich feststellen, dass die vorliegende Platte hdd1.E01 Teil eines RAID-6 Verbundes ist. Dieser Verbund besteht aus fünf einzelnen Platten - wahrscheinlich die vier verbleibenden Asservate hdd2.E01 bis hdd5.E01. Letzte Gewissheit erhält man, wenn man den gleichen Befehl mit den Blockdevices aller Festplatten-Abbilder wiederholt. In der Ausgabe erfährt der Forensiker außerdem, dass die Kapazität des logischen Laufwerks rund 24 GiB umfasst, während die Größe der einzelnen physikalischen Platten bei jeweils rund 8 GiB lagen. Weitere 16 GB nutzt RAID-6 zur Abbildung von zwei Paritäten, die benötigt werden, um eine doppelte Ausfallsicherheit zu implementieren. Da der Verbund konsistent ist - davon zeugt die korrekt Prüfsumme und das Array State AAAAA - genügt es, wenn der Forensiker fortan mit drei der fünf Platten arbeitet. Dieses Vorgehen schont IO Bandbreiten, Speicherkapazitäten und damit letztlich in der folgenden Bearbeitung auch Zeit. Es steht dem Forensiker aber frei, alle fünf Abbilder zum RAID-6 zu verbinden.

Schritt 3: Einbinden des RAID-Verbundes

In Schritt 2 wurde festgestellt, dass die fünf Plattenabbilder von einem logischen RAID-6-Verbund stammen. Daher lassen diese sich ressourcensparend einbinden, indem drei beliebige Platten des Verbundes gemountet werden.

1 > mdadm --assemble -- readonly --run /dev/md0 /dev/loop1 /dev/loop2 /dev/loop3 2 mdadm: /dev/md0 has been started with 3 drives (out of 5).

Schritt 4: Volumen Analyse

Nun kann der Forensiker ermitteln, mit welchem Dateisystem er es zu tun hat. Auf Basis dieser Erkenntnis, lässt sich das weitere Vorgehen bestimmen. Dazu lässt sich z. B. der Befehl fsstat aus dem SleuthKit verwenden.

1 > fsstat -t /dev/md0 2 ext4

33 Kapitel 4. Analyse eines Datenträgerverbundes

Es wurde ermittelt, dass auf dem Software-RAID das Dateisystem „ext4“ eingesetzt wurde. Es lassen sich nun weitere Analysen des Volumens durchführen, ohne dass dieses eingebunden werden muss. Beispielsweise lassen sich mit dem Carving-Tool foremost Dateien eines gewissen Dateityps anhand der Header-Informationen ermitteln und extrahieren. Da foremost nicht auf das Dateisystem schauen kann, entspricht die Nummer im Dateinamen der extrahierten Dateien dem Anfangsblock der jeweiligen Datei:

1 > foremost -T -t jpeg /dev/md0 2 Processing: /dev/md0 3 |********************************************************************** 4 *********************************************************************** 5 ****************| 6 > cd output/jpeg 7 > ls 8 00270576.jpg 00273955.jpg 17063504.jpg 25431160.jpg 25468552.jpg 9 00270692.jpg 00376832.jpg 17068664.jpg 25439144.jpg 25477184.jpg 10 00272024.jpg 17039368.jpg

Schritt 5: Mount des logischen Dateisystems

Die vorliegenden Datenträger-Abbilder wurden bislang als Platten eines Software- RAIDs identifiziert, in einem RAID-Verbund erfolgreich erneut logisch zusammen- gefasst und können nun auch gemountet werden. Da in diesem Fall ein Linux Dateisystem vorliegt, können wir dieses unmittelbar mappen, sobald der Pfad angelegt wurde.

1 > mkdir /mnt/suspect 2 > mount /dev/md0 /mnt/suspect 3 > ls -lh 4 insgesamt 4,3M 5 -rw-r--r-- 1 root root 220K Apr 13 18:00 Btrfs.pdf 6 -rw-r--r-- 1 root root 198K Apr 13 18:00 Dd.pdf 7 drwxr-xr-x 2 root root 4,0K Apr 13 18:01 fernweh 8 drwxr-xr-x 2 root root 4,0K Apr 13 18:01 happy 9 -rw-r--r-- 1 root root 5,6K Apr 13 18:05 hashdeep.txt 10 -rw-r--r-- 1 root root 0 Apr 13 18:00 Hochschule_Wismar.pdf 11 -rw-r--r-- 1 root root 189K Apr 13 18:00 Logical_Volume_Manager.pdf 12 drwx------2 root root 16K Apr 13 17:58 lost+found 13 -rw-r--r-- 1 root root 141K Apr 13 18:00 Mdadm.pdf 14 drwxr-xr-x 2 root root 4,0K Apr 13 18:01 metropolen 15 -rw-r--r-- 1 root root 0 Apr 13 18:00 NTFS.pdf 16 -rw-r--r-- 1 root root 0 Apr 13 18:00 One-Time-Pad.pdf 17 -rw-r--r-- 1 root root 0 Apr 13 18:00 Polizei-IT-Anwendungen.pdf 18 -rw-r--r-- 1 root root 960K Apr 13 18:00 RAID.pdf 19 -rw-r--r-- 1 root root 148K Apr 13 18:00 ReFS.pdf 20 -rw-r--r-- 1 root root 152K Apr 13 18:00 The_Sleuth_Kit.pdf 21 -rw-r--r-- 1 root root 1,6M Apr 13 18:00 Ubuntu.pdf

34 Kapitel 4. Analyse eines Datenträgerverbundes

22 -rw-r--r-- 1 root root 495K Apr 13 18:00 VirtualBox.pdf 23 -rw-r--r-- 1 root root 187K Apr 13 18:00 ZFS.pdf

35 Kapitel 4. Analyse eines Datenträgerverbundes

4.3.2 Logical Volume Manager (LVM)

Der Logical Volume Manager ist ein softwarebasierte Speicherlösung die in den Li- nuxkernel integriert ist. Logical Volume Manager (LVM) stellt logische Volumen bereit die von physischen Datenträgern abstrahiert und unabhängig sind. Es kann als Ergänzung zu MD angesehen werden und besitzt eine flexible Architektur.

Funktionsweise

Die von LVM bereitgestellten Volumen sind flexibel und skalierbar. Sie können über mehrere physische Datenträger verteilt und zur Laufzeit in ihrer Größe angepasst werden. Häufig wird LVM zusammen mit MD verwendet, aber einige Anbieter inte- grieren eigene RAID-Funktionalitäten. Diese sind in einigen Distributionen bereits integriert oder können nachträglich installiert werden. Von logischen Volumen kön- nen Snapshots angefertigt werden. In einem angelegten Snapshot werden alle Ände- rungen blockweise in ein neues referenzierendes, logisches Volumen geschrieben. Partitionen die in die LVM-Verwaltung integriert sind werden in der (MBR) Partitionstabelle mit dem Typ 0x8e gekennzeichnet. Die kleinste Speichereinheit im LVM wird Physical Extent genannt. Sie ist auf den physischen Datenträgern verteilt. Eine veränderbare Anzahl an Physical Extent bildet eine Vo- lume Group. In dieser Gruppe können mehrere logische Volumes abgelegt und an- schließend dem System zugeordnet werden. LVM hat keinen Einfluss auf dem dar- über eingesetzten Dateisystem. Wird das Volume in seiner Größe angepasst muss das Dateisystem dies unterstützen [12, S. 160–161].

Speichern und Einbinden

Das Duplizieren der LVM-Volumen für die forensische Auswertung ist einfach. Die Konfiguration ist unter /etc/lvm/ abgelegt. Hier finden sich auch Archive von alten Konfigurationen. Bei aktivem System ist es möglich beispielweise mit dd, das Volume zu kopieren. Die LVM-Partitionen sind unter /dev/VOLUMEGROUPNAME/VO- LUME verfügbar. Dieses Vorgehen ist ineffizient, da Snapshots und Volumen in ihrer gesamten Größe gespeichert werden. Zusätzlich gehen Metainformationen zur LVM- Konfiguration verloren. Mit dem Befehl vgimportclone wird eine neu benannte Kopie der originalen Volume Group angelegt. Somit kann das Original kopiert werden. Auf diese Methode kann im Normalfall verzichtet werden. Sämtliche Informationen über alle Datenträger, Volume Groups und Volumes liegen zusätzlich am Anfang

36 Kapitel 4. Analyse eines Datenträgerverbundes

Bild 4.22: LVM Architektur [13]

37 Kapitel 4. Analyse eines Datenträgerverbundes jeder der oben genannten LVM-Partitionen (0x8e). Es empfiehlt sich alle physi- schen Datenträger zu duplizieren. Im Anschluss werden die Duplikate im System des Forensikers mittels folgender Befehle eingebunden. Zu beachten ist das mögliche MD-RAID Aktionen vorher ausgeführt werden müssen.

1 > vgscan # Sucht nach Volume Groups 2 > vgdisplay # Listet die Volume Groups auf 3 > lvs # Liefert Methadaten zu den Volume Groups 4 > ll /dev/VOLUMENGROUP/ # Zeigt alle verfuegbaren Volumen an

Bild 4.23: Volume Groups und Volumes identifizieren

Auf Bild 4.24 sind die bereitgestellten Partitionen zu sehen. Da LVM keine Par- titionstabellen anlegt ist es möglich, mit fsstat in die Struktur des Dateisystems einzusehen. Eine Analyse des Snapshots in Bild 4.25 zeigt auf, dass das Dateisystem formatiert wurde. Im Original ist das Volume mit Ext4 formatiert. Der Befehl fls zeigt dass eine verdächtige Datei namens evil.exe existiert.

38 Kapitel 4. Analyse eines Datenträgerverbundes

Bild 4.24: Volumes und Dateisysteme

Bild 4.25: Dateisystem des Snapshots

39 Kapitel 4. Analyse eines Datenträgerverbundes

4.4 Software Lösungen unter Windows

4.4.1 LDM

Logical Disk Manager ist eine Funktionalität die es ermöglicht mehrere verschiedene Datenträger in ein einzigen logischen Datenträger zu verbinden. Es können dabei die RAID-Level 0, 1 und 5 gewählt werden. Um einen Datenträger in LDM einzubinden muss eine MBR-Partition des Typs 0x42 vorliegen. Am Ende jeder Partition befindet sich die proprietär aufgebaute LDM Datenbank. Weiterführende Informationen sind in Kapietel 7 aus [12, S. 162–170] einzusehen. Das freie Linuxprogramm ldmtool ist für die Rekonstruktion empfehlenswert. An dieser Stelle wird LDM nicht weiter thematisiert, dieses wurde durch die Windows Storage Spaces ersetzt.

4.4.2 WSS

Die Windows Storage Spaces sind eine softwarebasierte Speicherlösung von Micro- soft. Sie wurde mit Windows Server 2016 eingeführt. Mit Windows Server 2019 wurde Windows Storage Spaces durch Storage Space Direct (S2D) auf eine Storage Area Network Ebene erweitert.

Funktionsweise

Datenträger die für Windows Storage Spaces verwendet werden sind mit einer Globally Unique Identifier (GUID)-PartitionTable aufbereitet. In die- ser sind zwei Partitionen registriert. Microsoft Reserved Partition (GUID: E3C9E3160B5C4DB8817DF92DF00215AE) [12, S. 143] und Speicherpool (GUID: 8FAF5CE780F6EE4CAFA3B001E56EFC2D). Es folgen Metainformationen über den Speicherpool. Dazu zählen u. a. die Anzahl physischer Laufwerke, der Resilienz- Typ und die Größe des bereitgestellten Speichers. Resilienz ist die Fähigkeit, bei Störungen die Aufgabenerfüllung aufrecht zu erhalten. Adäquat zu LDM und im Gegensatz zu LVM wird bei WSS eine virtuelle Festplatte und keine Partition bereitgestellt. Diese beginnt mit einem GPT-Header, welcher auf eine Partition verweist die wiederum mit einer spezielle Version von NTFS oder Resilient (ReFS) formatiert ist. Diese Informationen liegen im RAW- Format auf den fünf schnellsten Datenträgern des WSS-Verbundes. Selbst wenn der Ermittler nur eine dieser Festplatten besitzt, stehen ihm sämtliche NTFS Metadaten

40 Kapitel 4. Analyse eines Datenträgerverbundes

über die gespeicherten Dateien zur Verfügung. ReFS ist ein von Microsoft entwickel- tes Dateisystem welches für die Verwendung von Netzwerkspeicher empfohlen wird.

Bild 4.26: GPT-Tabelle der physischen Disk

41 Kapitel 4. Analyse eines Datenträgerverbundes

Bild 4.27: GPT-Tabelle der virtuellen Disk

Bild 4.28: GPT-Tabelle auf physischer Disk identifiziert

Die Skalierung und Redundanz der Daten werden hier auf Dateisystemebene durch- geführt. Dazu wird das Speichermedium anschließend in 256 MB große Blöcke einge- teilt. Microsoft nennt diese Slaps. Wenn keine Redundanz konfiguriert ist, werden die Slaps gleichmäßig auf die Datenträger verteilt. WSS bietet zusätzlich vier verschie- dene Resilienzen an. Die einfache oder doppelte Kopie legen einen 256 MB Block auf weiteren Datenträgern ab. Dies ist performanter als die Paritätsberechnung, beansprucht aber viel Speicherkapazität. Alternativ kann eine einfache oder dop- pelte Parität eingesetzt werden da über alle genutzten Datenträger ein Paritätsslap berechnet wird. Das erhöht die Speichereffizienz des Systems. Sollte ein Laufwerk ausfallen, sofern genügend Speicherplatz auf den gesunden Datenträgern vorhan- den ist, werden die Paritäten bzw. Spiegelungen auf den vorhandenen Laufwerken umgehend rekonstruiert. Anschließend ist das System vor dem Ausfall weiterer Da- tenträger geschützt. Storage Space Direct bietet eine Kombination aus Kopie und Parität, um Speichereffizienz und -geschwindigkeit zu verbessern [14][15].

42 Kapitel 4. Analyse eines Datenträgerverbundes

Bild 4.29: NTFS Master File Table der virtueller Disk

Bild 4.30: NTFS Master File Table auf phsischer Disk identifiziert

43 Kapitel 4. Analyse eines Datenträgerverbundes

Speichern und Einbinden

Das Duplizieren von WSS-Datenträgern ist ebenfalls einfach. Ist das System, dessen Daten zu speichern sind, zugänglich, kann die virtuelle Festplatte mit den geeigneten Mitteln gesichert werden. Das Programm DiskDumper erstellt ein RAW-Image des gewünschten Laufwerks und berechnet anschließend den MD5-Hash. Für die Aus- wertung von Offline-Datenträgern empfiehlt es sich, diese in einem Auswertesystem mit einem aktuellen Windows schreibgeschützt einzubinden. Windows erkennt die Datenträger und bindet den Storage Space entsprechend ein. Diese Vorgehensweise ist vorteilhaft, da die genauen Funktionsweise des WSS von Microsoft nicht öffent- lich zugänglich sind. Somit besteht hierbei die höchste Wahrscheinlichkeit, dass alle Daten zugänglich sind. Alternativ gibt es Softwareprodukte, die die Windows Storage Spaces dennoch ein- binden können. Die Entwickler von R-Studio haben den Aufbau der WSS rekon- struiert, sodass sie die Konfiguration zuverlässig interpretieren und das Laufwerk anschließend bereitstellen können. Diese Funktion ist in der kostenpflichtigen Ver- sion verfügbar. Daher wird im Rahmen dieser Projektarbeit nicht weiter darauf eingegangen.

Bild 4.31: Datenträger sichern mit DiskDumper

44 Kapitel 4. Analyse eines Datenträgerverbundes

4.5 Zusammenfassung

Zusammenfassend ist festzuhalten, dass das Wiederherstellen verteilter Speicher- konfigurationen sehr vom verwendeten Produkt abhängt. Bei Open Source Lösun- gen ist das Wiederherstellen der Datenstruktur kein Hindernis. Durch die Vielzahl von RAID-Herstellern ist es empfehlenswert die von RAID-Controller bereitgestellte Disk mit Hilfe des eigenen Forensik-Systems zu duplizieren. Bei proprietären Spei- cherlösungen, wie Microsofts Windows Storage Spaces, ist zu empfehlen eine Kopie während des laufenden Windows-Systems zu erstellen. Das ist die zuverlässigste Option.

45 Kapitel 5. Verschlüsselte Datenträger

5 Verschlüsselte Datenträger

5.1 Einleitung

Heutzutage stehen für die am Markt relevanten Betriebssysteme integrierte Mög- lichkeiten zur Verfügung, mit geringem Aufwand, sowohl im Computersystem einge- baute als auch extern angeschlossene, Datenträger zu verschlüsseln. Besonders auf Notebooks und für mobile Datenträger im Enterprise-Umfeld wird der Einsatz von Verschlüsselungen empfohlen. Zusätzlich können, bei entsprechendem Schutzbedarf, auch stationäre Arbeitsplatzrechner und sogar Server verschlüsselt werden [16]. Auch im privaten Umfeld sind die Hürden, eine Datenträgerverschlüsselung ein- zusetzen, überschaubar. So bietet Apple seit OS X Lion eine, im Betriebssystem integrierte, Festplattenverschlüsselung (FileVault2) an, welche mit wenigen Klicks eingeschaltet werden kann [17]. Beliebte Linux Distributionen bieten einfache, grafi- sche Einrichtungstools für die Festplattenverschlüsselung mit Bordmitteln [18] und für Windows kann Microsoft die BitLocker-Geräteverschlüsselung sogar automatisch aktivieren, wenn die Hardware es unterstützt [19]. Aufgrund der Sicherheitsempfehlungen für Unternehmen sowie den einfach einzu- richten und zum Teil auch automatisch aktiven Verschlüsselungstools für privat ge- nutzte Geräte steigt die Wahrscheinlichkeit, bei der forensischen Analyse von Com- putersystemen auf verschlüsselte Datenträger zu treffen. In diesem Kapitel werden die in Windows, Linux und macOS integrierten Verschlüs- selungstools vorgestellt und betrachtet, wie eine damit verschlüsselte Systemparti- tion zur Analyse der enthaltenen Daten entschlüsselt werden kann.

5.2 Festplattenverschlüsselung

Um Daten auf Datenträgern zu verschlüsseln gibt es mehrere Ansätze. Zum einen können einzelne Dateien verschlüsselt und in dieser Form, wie jede andere Datei, im Dateisystem des Speichermediums abgelegt werden (z. B. Windows (EFS), Encrypted Filesystem (EncFS), ZIP mit Verschlüsselung). Zum an- deren kann ein gesamter Datenträger bzw. eine Partition verschlüsselt werden. Das

46 Kapitel 5. Verschlüsselte Datenträger

Dateisystem befindet sich in diesem Fall eine logische Schicht über der Verschlüsse- lung. Diese Technik sorgt dafür, dass ein Image einer so verschlüsselten Partition nur unleserliche Daten enthält, die vor der weiteren forensischen Analyse entschlüsselt werden müssen, um auf das Dateisystem zugreifen zu können. In dieser Arbeit liegt der Fokus auf der Entschlüsselung vollständig verschlüsselter Betriebssystem-Partitionen.

5.3 Verschlüsselungstools

Am Markt sind eine Vielzahl von Verschlüsselungsprogrammen verfügbar, mit de- nen Datenträger blockweise verschlüsselt werden können. In diesem Abschnitt wird für jedes aktuelle, populäre Desktop-Computer Betriebssystem (Windows, Linux, macOS) die jeweils integrierte (kann je nach Betriebssystemedition/ Distribution abweichen) Verschlüsselungsmethode vorgestellt. Zusätzlich wird das, für alle Be- triebssysteme verfügbare, VeraCrypt betrachtet.

5.3.1 Microsoft BitLocker

Überblick

Microsoft BitLocker ist eine Festplattenverschlüsselung, die Microsoft seit / Windows Server 2008 als Betriebssystemkomponente ausliefert. BitLo- cker ist in der Lage neben portablen Geräten und Datenpartitionen auch die Betriebssystempartition zu verschlüsseln. Dafür wird eine kleine, unverschlüsselte Systempartition angelegt, von der zuerst gebootet wird. Das dort abgelegte System entschlüsselt und lädt danach das eigentliche Betriebssystem aus der verschlüsselten Betriebssystempartition [20]. Die zu verschlüsselnde Partition wird mit Hilfe eines symmetrischen Schlüssels, dem Full Volume Encryption Key (FVEK), verschlüsselt. Der FVEK wiederum wird mit dem so genannten Volume Master Key (VMK) verschlüsselt. Der VMK wird ebenfalls verschlüsselt. Die Art des Schlüssels kann dabei variieren. Computer, die über ein Trusted Platform Module (TPM) verfügen, können dieses zur Verschlüs- selung des VMK nutzen. Alternativ (oder auch zusätzlich) kann der Schlüssel mit einem Kennwort geschützt werden. Vom VMK können mehrere, mit jeweils einem anderen Schlüssel verschlüsselte, Kopien angelegt werden [21, S. 7]. Das ermöglicht es z. B. das System im normalen Betrieb mittels des Schlüssels aus dem TPM zu entschlüsseln aber auch einen Wiederherstellungsschlüssel zu erzeugen, der an einer

47 Kapitel 5. Verschlüsselte Datenträger

Bild 5.1: BitLocker Key Architecture. Entnommen aus: [21, S. 9] anderen Stelle abgelegt wird, falls die Entschlüsselung per TPM (z. B. wegen eines Hardwaredefekts oder einer Integritätsverletzung) scheitert. Bild 5.1 zeigt eine Übersicht der möglichen Schlüssel. Der verschlüsselte FVEK sowie die Kopien des verschlüsselten VMK werden in einer unverschlüsselten Datenstruktur (BitLocker Metadaten) an drei Stellen (Anfang, Mitte, Ende) auf der ansonsten verschlüsselten Partition abgelegt. Die BitLocker Metadaten-Strukturen beginnen mit der Signatur „-FVE-FS-“ [22, S. 4]. Wird diese Signatur in einem Partitionsimage gefunden, so ist die Partition höchstwahrscheinlich mit BitLocker verschlüsselt.

Schlüsselgewinnung

Damit das Image einer mit BitLocker verschlüsselten Partition entschlüsselt werden kann, wird entweder der FVEK, der VMK oder ein Schlüssel für den VMK be- nötigt. Alle Schlüssel, die zur Laufzeit unverschlüsselt im Arbeitsspeicher abgelegt sind, werden, wenn BitLocker sie zur Entschlüsselung gerade nicht benötigt, über- schrieben [21, S. 13]. Da der VMK nur für einen kurzen Moment zum Entschlüsseln des FVEK benötigt wird, ist es unwahrscheinlich den VMK im Random-Access Me- mory (RAM) auffinden zu können. Der FVEK jedoch wird während der gesamten Laufzeit des Systems im RAM gehalten und kann aus einem Memory Dump ausge- lesen werden [23]. Auf diese und andere Techniken zur Gewinnung des FVEK aus einem laufenden System/ RAM Image oder einem Angriff auf das TPM wird in

48 Kapitel 5. Verschlüsselte Datenträger

Bild 5.2: Partitionstabelle einer Festplatte mit einer BitLocker-Partition dieser Arbeit nicht eingegangen. Für die Entschlüsselung wird angenommen, dass ein Wiederherstellungsschlüssel bekannt ist. Diese werden in Unternehmen z. B. im ActiveDirectory oder einer Schlüsselverwaltungsdatenbank eines Drittanbieters abgelegt. Darüber hinaus kön- nen auch externe Speichermedien (z. B. USB-Sticks) als Schlüsselspeicher dienen. Zuletzt bietet BitLocker auch die Möglichkeit einen Schlüssel auszudrucken oder in einem Microsoft-Konto in der Cloud abzulegen [24]. Für die Analyse der Daten muss zusätzlich zum Image der verschlüsselten Partition demnach auch ein Schlüssel gefunden werden.

Entschlüsselung

Für diese Arbeit wurde die Betriebssystempartition einer Virtual Machine (VM) (ohne TPM) mit BitLocker verschlüsselt. Der VMK wird durch ein Startpasswort geschützt. Zusätzlich wurde (automatisch) ein Wiederherstel- lungsschlüssel erstellt. Im Anschluss wurde die virtuelle Festplatte an eine Ubun- tu Linux VM angehängt und mit dd als RAW-Image kopiert. Mit mmls aus der Programmsammlung “The Sleuth Kit„ wird die Partitionstabelle betrachtet (Bild 5.2). Aufgrund der Größe der Partitionen wird geschlossen, dass es sich bei der größeren New Technology File System (NTFS) Partition um die Betriebssystem- Partition handelt. Diese wird an ein Loop-Device gebunden. Mit Hilfe des head Befehls wird der Beginn der Partition ausgelesen. Anhand der Signatur „-FVE- FS-“ (Bild 5.3) ist erkennbar, dass es sich tatsächlich um die mit BitLocker ver- schlüsselte Partition handelt. Um die Partition weiter zu analysieren wird dislo- cker (https://github.com/Aorimn/dislocker) eingesetzt. Der Befehl dislocker- metadata gibt weitere Informationen über die verschlüsselte Partition aus (Bild 5.4).

49 Kapitel 5. Verschlüsselte Datenträger

Bild 5.3: BitLocker Signatur am Beginn der Partition

Bild 5.4: Metadaten der mit BitLocker verschlüsselten Partition

Die verschlüsselte Partition wird mittels dislocker-fuse und dem, beim Einschalten der Verschlüsslung erstellten, Recovery Key entschlüsselt und danach eingehängt. Dislocker unterstützt verschiedene Arten von Schlüsseln (siehe Abschnitt „Schlüs- selgewinnung“) um die Partition zu entschlüsseln. Mit dem Parameter „-r“ wird die Partition nur lesend eingebunden, um Veränderungen zu vermeiden. Wie in Bild 5.5 erkennbar, kann nun auf den Inhalt der Partition zugegriffen werden.

5.3.2 FileVault 2

Überblick

FileVault2 ist ein in macOS integriertes Verschlüsselungstool. Seit Version 2 unter- stützt FileVault die Verschlüsselung des Betriebssystem-Volumes [17]. Moderne Ver- sionen von macOS nutzen das Apple-eigene Dateisystem Apple File System (APFS) für die Systemfestplatte/SSD. APFS legt auf dieser Platte einen so genannten Con- tainer (entspricht einer Partition) an. Dieser Container enthält bei einem mit Fi-

50 Kapitel 5. Verschlüsselte Datenträger

Bild 5.5: BitLocker verschlüsselten Partition entschlüsselt einhängen leVault verschlüsselten Betriebssystem mindestens drei Volumes. Ein Volume ist verschlüsselt und enthält das Betriebssystem, ein Volume ist nicht verschlüsselt und enthält die Daten, die zum Start des Betriebssystems notwendig sind (Preboot) und ein drittes Volume ist ein Recovery Volume [25]. Bei der Aktivierung von FileVault wird im Preboot-Volume 1 die Datei „Encrypte- dRoot.plist.wipekey“ erstellt. Es handelt sich dabei um ein XML-File, dessen Inhalt zum größten Teil mit einem - im Header des zugehörigen System-Volumes befind- lichen - Schlüssel verschlüsselt ist. Diese Datei enthält den Volume Key, mit dem das System-Volume verschlüsselt ist. Der Volume Key wiederum ist mit einem Key- Encryption-Key verschlüsselt. Vom Key-Encryption-Key existieren mehrere Kopi- en, welche mit jeweils unterschiedlichen Schlüsseln verschlüsselt sind. Diese Schlüs- sel können Passwörter der Systembenutzer, ein Recovery-Key oder ein Zertifikat sein [26]. Apple-Geräte mit eingebautem T2-Chip erzeugen eine zusätzliche Hürde bei der Er- stellung eines Images der Systemfestplatte/SSD. Alle Zugriffe auf das Medium laufen über den T2-Chip und werden dort mit einem an die Hardware gebundenen Schlüssel verschlüsselt. In diesem Fall wird die Hardware, zu welcher der Datenträger gehört benötigt, um das Medium zu entschlüsseln. Innerhalb dieser Verschlüsselung kann zusätzlich noch eine FileVault Verschlüsselung aktiv sein [27]. Auf dieses Szenario (Verschlüsselung mit T2-Chip) wird in dieser Arbeit nicht eingegangen.

Schlüsselgewinnung

Beim Einschalten von FileVault wird ein Recovery-Key erzeugt. Dieser kann ent- weder lokal ausgegeben und z. B. ausgedruckt oder in einen iCloud-Account hoch- geladen werden. Besteht Zugriff auf den iCloud Account des Gerätebesitzers, kann

1In der Quelle [26] wird beschrieben, dass die Datei sich in der Recovery-Partition befindet. Bei dem für diese Arbeit installierten System (macOS 10.14 Mojave in einer VMWare VM) war die Datei jedoch im Preboot-Volume abgelegt.

51 Kapitel 5. Verschlüsselte Datenträger

Bild 5.6: APFS/ FileVault2 Partitionstabelle - mmls der Account unter Umständen zum Abrufen des Wiederherstellungsschlüssel genutzt werden [28]. Neben dem Recovery Key kann das Passwort eines Benutzeraccounts, der zum Entschlüsseln des Volumes berechtigt ist, verwendet werden. Darüber hin- aus kann (besonders in Enterprise Umgebungen) ein Zertifikat zur Entschlüsselung hinterlegt werden [26]. Liegt ein RAM-Dump des zu entschlüsselnden Systems vor, kann der Volume Key auch daraus extrahiert werden [29]. Für diese Arbeit wird jedoch angenommen, dass der Recovery-Key bekannt ist.

Entschlüsselung

Für diese Arbeit wurde eine VMWare VM mit macOS 10.14 installiert und das System-Volume mit FileVault verschlüsselt. Der Recovery-Key wurde nicht in der iCloud abgelegt sondern am Bildschirm ausgegeben. Die Partitionstabelle der VM wird, mit mmls betrachtet, nur unzureichend dargestellt (Bild 5.6), da mmls in der eingesetzten Version nicht mit APFS umgehen kann. Um weitere Informationen über die im Image enthaltenen Partitionen, Container und Volumes zu erhalten, wird die apfs-fuse Toolsammlung genutzt (https://github.com/sgan81/apfs-fuse). Mit dem enthaltenen apfsutil können die Volumes im APFS angezeigt werden (Bild 5.7). Unter Angabe des Recovery-Keys (oder eines Passworts) kann das verschlüsselte System-Volume mit apfs-fuse eingebunden werden (Bild 5.8). Der Zugriff erfolgt in der genutzten Programmversion (vom 20 April 2019) nur lesend und die Software befindet sich noch im experimentellen Stadium.

52 Kapitel 5. Verschlüsselte Datenträger

Bild 5.7: APFS/ FileVault2 Partitions-/ Volumeinformationen - apfsutil

Bild 5.8: FileVault2 verschlüsselte Partition einbinden

53 Kapitel 5. Verschlüsselte Datenträger

5.3.3 LUKS/ dm-crypt

Überblick

DM-Crypt ist ein, im aktuellen Linux-Kernel enthaltenes, Modul um Daten ver- schlüsselt auf Block-Devices zu schreiben und davon zu lesen [30]. DM-Crypt wird durch LUKS um einen Rahmen erweitert, der das Schlüsselmanagement standar- disiert und vereinfacht. LUKS arbeitet auch mit anderen Verschlüsselungsmodulen zusammen [31, S. 1]. In diesem Kapitel wird „LUKS“ jedoch synonym für die Kom- bination aus DM-Crypt und LUKS2 verwendet. LUKS ermöglicht es, sowohl verschlüsselte Containerdateien zu erzeugen als auch ganze Partitionen und Festplatten zu verschlüsseln. Dazu wird ein Header erzeugt, der Metadaten zur Konfiguration der Verschlüsselung enthält. Der Header ist erkenn- bar an der Signatur „LUKS“ und beginnt mit einem Binärobjekt, welches grund- legende Daten zur eingesetzten Verschlüsselung enthält. Darauf folgt eine JSON Struktur, welche unter anderem Informationen über die verwendeten Keyslots und deren Speicherort enthält. Ein Keyslot ist eine Datenstruktur, die den Schlüssel zur mit dm-crypt erzeugten Datenverschlüsselung in verschlüsselter Form enthält. LUKS2 unterstützt bis zu 32 Keyslots, also Schlüssel um auf den dm-crypt-Schlüssel zuzugreifen [32]. Diese Schlüssel können Passwörter sein, es sind aber auch Schlüsseldateien auf ex- ternen Datenträgern (auch im nicht allokierten Bereich), Hardwaretoken, Schlüssel im TPM oder andere Verfahren denkbar. Seit LUKS2 ist der Header redundant vorhanden (nur der Header, nicht die Keys- lots) und es ist möglich, den Header auch außerhalb der verschlüsselten Partition aufzubewahren [32]. Damit würde die Signatur „LUKS“ als Identifikationsmerkmal auf dem Datenträger fehlen.

Schlüsselgewinnung

Da die Schlüssel der LUKS Keyslots sehr unterschiedliche Daten an verschiedensten Orten sein können, gibt es keine allgemeingültige Vorgehensweise um die Schlüssel aufzuspüren. Ist das System jedoch noch eingeschaltet und kann bedient werden, so können die Schlüssel mittels dmsetup table –showkeys aus dem laufenden System ausgelesen werden. Mit den so gewonnen Informationen kann ein eigener Schlüssel für einen Keyslot erzeugt werden [33]. Liegt zu dem verschlüsselten Datenträger ein RAM-Dump des Systems von einem

54 Kapitel 5. Verschlüsselte Datenträger

Bild 5.9: Ubuntu Installationsoptionen

Zeitpunkt vor, zu dem die Daten entschlüsselt waren, so kann der Schlüssel auch daraus gewonnen werden [34]. Für diese Arbeit wird jedoch angenommen, dass ein Schlüssel für einen LUKS Keyslot vorliegt.

Entschlüsselung

Für diese Arbeit wurde eine Ubuntu 19.04 Desktop Installation mit den im In- stallationsdialog (Bild 5.9) angebotenen Verschlüsselungsoptionen verschlüsselt. In dem verschlüsselten Bereich auf der Festplatte wurde mit Hilfe von LVM eine Vo- lume Group angelegt. Darin befinden sich die /root- und die swap-Partition. Dies wird erreicht, indem die abgebildeten Optionen während der Installation angewählt werden. Von dem installierte System wurde mit ewfacquire ein Image (Dateiname „image.e*“) erstellt. Dieses wird nun ausgewertet. Im ersten Schritt wird die Partitionstabelle des Images mit mmls betrachtet (Bild 5.10). Es werden zwei „Linux-Partitionen“ erkannt. In der ersten ist ein minimales Linux zum Booten des eigentlichen Betriebssystems enthalten. Dieses befindet sich, wie in Bild 5.11 erkennbar, verschlüsselt in der zweiten Partition, deren Dateisys- tem (wegen der Verschlüsselung) nicht bestimmt werden kann. Um die verschlüssel- te Partition analysieren zu können, wird das mit ewfacquire erstellte Image mittels Xmount bereitgestellt (siehe 5.12). Im Anschluss wird die verschlüsselte Partition als loop-Device eingebunden (Bild 5.13). An der Signatur „LUKS“ am Partitionsbe- ginn ist erkennbar, dass es sich tatsächlich um die verschlüsselte Partition handelt. Mit dem Tool cryptsetup werden die Metadaten der verschlüsselten Partition an- gezeigt (Bild 5.14). Damit das verschlüsselte Dateisystem lesbar wird, wird es mit

55 Kapitel 5. Verschlüsselte Datenträger

Bild 5.10: Partitonstabelle des verschlüsselten Ubuntu

Bild 5.11: Dateisysteme der Linux Partitionen

Bild 5.12: EWF Image mit Xmount einbinden

Bild 5.13: LUKS Partition als Loop-Device bereitstellen

56 Kapitel 5. Verschlüsselte Datenträger

Bild 5.14: LUKS Header mit cryptsetup anzeigen

57 Kapitel 5. Verschlüsselte Datenträger

Bild 5.15: Partition entschlüsseln und LVM Volumes mappen cryptsetup entschlüsselt. Die entschlüsselte Partition wird unter „/dev/mapper“ ein- gehängt. Da bei der Installation des Betriebssystems LVM verwendet wurde, kann noch nicht auf die Daten der gemappten Partition zugegriffen werden. Mittels lvm pvscan werden die eingebundenen Datenträger nach vom LVM verwalteten Devi- ces durchsucht. Diese werden ebenfalls unter „/dev/mapper“ eingehängt. Die Daten können nun analysiert werden (Bild 5.15).

5.3.4 VeraCrypt

Überblick

VeraCrypt ist ein freies, auf TrueCrypt basierendes, Verschlüsselungstool. Es ist für Windows, Linux und macOS verfügbar und kann sowohl verschlüsselte Container erstellen als auch ganze Partitionen/ Speichermedien verschlüsseln. Daneben kann ein installiertes Windows vollständig verschlüsselt werden (pre-boot authenticati- on) [35]. Eine solche Konfiguration kann daran erkannt werden, dass der VeraCrypt- Bootloader am Anfang der Festplatte abgelegt wird. Der Bootloader kann jedoch auch auf einem externen Medium gespeichert werden (VeraCrypt Rescue Disk) [36]. Grundsätzlich verfolgt VeraCrypt den Ansatz, dass neben der Verschlüsselung auch das Vorhandensein der verschlüsselten Daten möglichst schlecht erkennbar ist. Es wird deshalb auf eine unverschlüsselt lesbare Signatur zu Beginn einer verschlüssel- ten Partition verzichtet. Darüber hinaus ist es möglich, versteckte Container anzu- legen. Eine mit VeraCrypt verschlüsselte Partition beginnt mit einem Header, welcher den eigentlichen Schlüssel zur Verschlüsselung der Daten enthält. Der Header selber ist ebenfalls verschlüsselt [37]. Um den Header zu verschlüsseln, können bei der System- verschlüsselung nur Passwörter genutzt werden [38]. Die Architektur unterstützt nur

58 Kapitel 5. Verschlüsselte Datenträger einen Schlüssel pro verschlüsseltem Medium. Um die Sicherheit zu erhöhen kann - zusätzlich zum Passwort - ein Personal Iterations Multiplier (PIM) angegeben wer- den. Dieser beeinflusst die Anzahl der Iterationen der Funktion, die aus dem an- gegebenen Passwort den eigentlichen kryptographischen Schlüssel für den Header erzeugt [39]. Wird kein PIM angegeben, wird eine Standardanzahl an Iterationen der Schlüsselableitungsfunktion genutzt.

Schlüsselgewinnung

Der Schlüssel zur Entschlüsselung des VeraCrypt Headers kann bei einer System- verschlüsselung nur ein Passwort - optional erweitert durch ein PIM - sein. Einen Recovery-Key gibt es nicht - lediglich eine Rescue Disk, welchen den Header zum Zeitpunkt der Erstellung der Recovery Disk enthält. Das Passwort kann unter Um- ständen ein anderes sein, als das aktuell genutzte, wenn die Disk nach einer Pass- wortänderung nicht vernichtet und neu erstellt wurde. Liegt ein Memory Dump des Systems bei entschlüsselter Partition vor, kann dar- aus der Schlüssel für die Daten extrahiert werden [40]. Läuft das System noch mit entschlüsselter Partition und kann es bedient werden, kann - bei vorhandenen ad- ministrativen Berechtigungen - das Entschlüsselungspasswort auf einen bekannten Wert gesetzt werden [41]. Für diese Arbeit wird davon ausgegangen, dass das Pass- wort bekannt ist und kein PIM vergeben wurde.

Entschlüsselung

Für diese Arbeit wurde eine Windows 10 Installation mittels VeraCrypt verschlüs- selt. Dabei wurde mit der Option „Die Windows System-Partition verschlüsseln“ ge- arbeitet. Von der gesamten Festplatte wurde mit dd ein RAW Image (veracrypt.img) erstellt. Die Partitionsstruktur, mit mmls betrachtet, ist in Bild 5.16 abgebildet. Um die verschlüsselte Partition öffnen zu können, genügt es nicht nur sie alleine als Loop-Device einzuhängen (Bild 5.17). Es wird ein partitioniertes Gerät und keine einzelne Partition erwartet. Dies wird erreicht, indem losetup mit dem Parameter „-P“ aufgerufen wird. Der Parameter „-f“ wählt automatisch das nächste, freie Loop- Device. Nachdem das Image mit allen Partitionen als Loop-Device eingehängt ist, kann die verschlüsselte Betriebssystem-Partition mit VeraCrypt entschlüsselt und gemountet werden. Dabei ist darauf zu achten, dass wie in Bild 5.18 der Parameter „–mount-options=ro,system“ angegeben wird, damit die Partition ReadOnly einge- bunden und als verschlüsselte Systempartition mit pre-boot authentication erkannt

59 Kapitel 5. Verschlüsselte Datenträger

Bild 5.16: Partitionstabelle des mit VeraCrypt verschlüsselten Windows

Bild 5.17: Image mit Partitionen als Loop-Device einbinden

wird. Bei der Verschlüsselung wurde der PIM nicht gesetzt und Schlüsseldateien können für dieses Szenario nicht genutzt werden. Somit muss lediglich das Passwort zur Entschlüsselung angegeben werden. Eine alternative Möglichkeit die Partition zu mounten ist cryptsetup. Dafür muss das Image ebenfalls vollständig als Loop-Device eingehängt werden (siehe Bild 5.17). cryptsetup wird nun so aufgerufen, dass es eine, mit VeraCrypt verschlüsselte, Sy- stempartition öffnen soll. Die entschlüsselte Partition wird unter „/dev/mapper“ eingehängt und kann gemountet werden. Diese Variante ist in Bild 5.19 zu sehen.

Bild 5.18: VeraCrypt Partition einbinden

60 Kapitel 5. Verschlüsselte Datenträger

Bild 5.19: VeraCrypt Partition mit cryptsetup einbinden

5.4 Zusammenfassung

In diesem Kapitel wurde eine Übersicht über die im Betriebssystem integrierten Verschlüsselungstools in Windows, Linux und macOS sowie das Tool VeraCrypt gegeben. Alle haben die Tatsache gemeinsam, dass der Master Key, mit dem die Systempartition tatsächlich verschlüsselt wird, für die Entschlüsselung bei der fo- rensischen Analyse nur dann eine Rolle spielt, wenn er aus dem laufenden System oder einem Speicherabbild gewonnen werden muss/ kann. Wird für die forensische Analyse ein heruntergefahrenes (also vollständig abgeschaltetes) System vorgefun- den zu welchem kein RAM-Dump verfügbar ist, ist es zielführender die Schlüssel, mit denen der Master Key (direkt oder indirekt - je nach Schlüsselverwaltung des genutzten Tools) verschlüsselt wurde, herauszufinden. Stammt das zu analysierende System aus einer Enterprise-Umgebung und handelt es sich um eine Windows oder macOS Installation, bestehen gute Chancen, dass über die IT-Ableitung ein Recovery-Key bezogen werden kann. Sowohl BitLocker als auch FileVault sehen explizit die Möglichkeit vor, solche Schlüssel zentral zu ver- walten. Auch für eine, mit LUKS geschützte, Linux Installation kann ein Recovery Key vorliegen. Bei VeraCrypt ist dies ausgeschlossen, da für die Entschlüsselung des Master Keys nur ein einzelnes, „normales“ Passwort genutzt werden kann. Sowohl Microsoft als auch Apple bieten für ihre Verschlüsselungstools die Möglich- keit, einen Wiederherstellungsschlüssel in der Cloud abzulegen. Besteht Zugriff auf ein solches Cloud-Konto, welches mit dem zu analysierenden Gerät in Verbindung steht, könnte dort ein Recovery-Key abgelegt sein. BitLocker und LUKS bieten darüber hinaus die Möglichkeit, Schlüssel auf externen Speichermedien (z. B. USB- Sticks) zu hinterlegen. Nach solchen Geräten sollte bei der Sicherung des zu analy- sierenden Systems Ausschau gehalten werden. Zuletzt bleibt noch die Möglichkeit, dass ein Recovery-Key oder ein Passwort zur Entschlüsselung in ausgedruckter/ aufgeschriebener Form vorliegt. Für die Entschlüsselung der Datenträger (bzw. daraus entstandener Images) stehen unterschiedliche Tools zur Verfügung. Pro Verschlüsselungstool wurde mindestens

61 Kapitel 5. Verschlüsselte Datenträger ein freies Programm zur Entschlüsselung vorgestellt. Bei modernen Apple-Geräten mit T2 Chip muss beachtet werden, dass der eingebaute Datenträger unter Umstän- den nur mit einem Schlüssel gelesen werden kann, der fest im Chip einprogrammiert ist.

62 Kapitel 6. Fazit

6 Fazit

Zusammenfassend lässt sich sagen, dass die Forensik strengen Reglements in Bezug auf gesetzliche Regelungen, als auch ethisch und moralisch richtigem Handeln, unterlegen ist. Dies gilt nicht nur für behördliche Ermittlungen, welche besonders streng geregelt sind, sondern auch bei Ermittlungen im „privaten“ Umfeld. In jedem Fall ist die Dokumentation, eine damit verbundene Nachvollziehbarkeit der Ermittlungen, hier an erster Stelle zu nennen. Dieses stellt eine Rechtssicherheit (Beweissicherheit) her. Die Integrität der Daten muss in jedem Fall gewahrt werden, wofür Write-Blocker zum Einsatz kommen, damit bei der Analyse die Unveränderlichkeit der Daten garantiert werden kann.

Aufgrund vieler vorhandener RAID-Systeme/ -Level ist eine pauschale Aussage zur Wiederherstellbarkeit der Daten bzw. des Systems nicht möglich. Hier ist eine Vielzahl von Tools vorhanden, welche sowohl auf verschiedenen Plattformen lauffähig sind, als auch verschiedene RAID-Level unterstützen. Somit hängt die Tiefe der Analyse vom verwendeten Tool ab. Das hier verwendete Tool R-Studio bietet einen sehr großen Funktionsumfang, ist jedoch kostenpflichtig - will man den kompletten Funktionsumfang nutzen. Ebenso ist es auf allen gängigen Betriebssys- temen einsetzbar.

Für die blockweise Datenträgerverschlüsselung gibt es diverse Tools, welche eine Verschlüsselung der Betriebssystempartition vornehmen können (z. B. Microsoft BitLocker, LUKS). Eine Entschlüsselung der Partition zur weiteren Analyse der Daten stellte keine nennenswerten Probleme dar. Vorausgesetzt ist die Verfüg- barkeit eines Passwortes/ Passphrase, welches zum Schutz des kryptographischen Festplattenschlüssels verwendet wurde. Die entsprechenden Passwörter können u. a. durch Hacking, Phishing oder mit Hilfe der IT-Abteilung o. ä. beschafft werden. Die an eine bestimmte Hardware gebundene Verschlüsselung, beziehungsweise die damit verbundene Entschlüsselung, stellt eine größere Herausforderung dar. Hier gibt es einen Chipsatz (z. B. Apple T2-Chip), welcher die Entschlüsselung der

63 Kapitel 6. Fazit

Datenträger nur mit der dazugehörigen Hardware vornehmen kann. Somit können Datenträger eines Rechners nicht ohne den dazugehörigen Chip entschlüsselt werden.

Zu den Datenträgern an sich lässt sich zusammenfassend sagen, dass bei der Rekon- struktion von Daten auf Flash-Speichern größere Probleme auftreten als bei HDDs. Eine Wiederherstellung verborgener Daten ist kaum oder gar nicht möglich ist, so- fern der TRIM-Befehl und die Garbage Collection aktiv sind. Ist der TRIM-Befehl deaktiviert, so wird die Garbage-Collection nicht angesprochen. Dadurch bleiben die Daten einer Speicherzelle bis zum nächsten Schreibprozess in dieser Zelle erhalten.

64 Literaturverzeichnis

Literaturverzeichnis

[1] Geschonneck, Alexander: Computer-Forensik: Computerstraftaten erkennen, ermitteln, aufklären. 6., aktualisierte und erweiterte Auflage. Heidelberg, Ger- many : dpunkt.verlag, 2014 (iX-Edition). – ISBN 9783864901331

[2] Hans-Peter Merkel: Die Afflib als Ersatz für proprietäre Forensiktools. In: Linux-Magazin 2009 (2009), Nr. 08

[3] Bundesamt für Sicherheit in der Informationstechnik: Leitfaden "IT-Forensik". https://www.bsi.bund.de/SharedDocs/Downloads/DE/ BSI/Cyber-Sicherheit/Themen/Leitfaden_IT-Forensik.pdf?__blob= publicationFile&v=2. Version: März 2011

[4] Hudy, Felix: Macht sich der private IT-Forensiker bei seinen Ermitt- lungen strafbar? https://www.datenschutzbeauftragter-info.de/ macht-sich-der-private-it-forensiker-bei-seinen-ermittlungen-strafbar/. Version: 18.01.2017

[5] Ackermann ; Clages ; Roll: Handbuch der Kriminalistik: Kriminalistik für Praxis und Ausbildung. 5. Stuttgart : Richard Boorberg, 2019. – ISBN 9783415060258

[6] Scherer, Daniel: Forensische Analyse von Flash-Speichern: Ba- chelorarbeit von Daniel Scherer. 1. CreateSpace Indepen- dent Publishing Platform, 17.06.2015 https://www.amazon.de/ Forensische-Analyse-von-Flash-Speichern-Bachelorarbeit-ebook/ dp/B00ZV8C590/ref=tmm_kin_swatch_0?_encoding=UTF8&qid=&sr=. – ISBN 1514376466

[7] Wikipedia: RAID. https://de.wikipedia.org/wiki/RAID,

[8] Ubuntu: FakeRaidHowto. https://help.ubuntu.com/community/ FakeRaidHowto, unbekannt

[9] Sharkoon: Spezifikation Sharkoon 5-Bay RAID Station. http://de. sharkoon.com/product/1238/12909#specs,

65 Literaturverzeichnis

[10] R-Studio: R-Studio Homepage. https://r-studio.com,

[11] Wikipedia: Mdadm. https://de.wikipedia.org/wiki/Mdadm,

[12] Carrier, Brian: File system forensic analysis. 10. print. Upper Saddle River, NJ : Addison-Wesley, 2011. – ISBN 0321268172

[13] greenstack: greenstack VLM. https://greenstack.files.wordpress. com/2014/09/lvm.png,

[14] Cosmos Darwin ; TECHNET (Hrsg.): Deep Dive: The Sto- rage Pool in Storage Spaces Direct. TECHNET : https: //techcommunity.microsoft.com/t5/Storage-at-Microsoft/ Deep-Dive-The-Storage-Pool-in-Storage-Spaces-Direct/ba-p/425959, 2016

[15] cosmosdarwin: Fault tolerance and storage efficiency in Storage Spaces Di- rect. TECHNET : https://docs.microsoft.com/en-us/windows-server/ storage/storage-spaces/storage-spaces-fault-tolerance#examples, 2017

[16] BSI: IT-Grundschutz: M 4.433 Einsatz von Datenträgerverschlüs- selung. https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ ITGrundschutzKataloge/Inhalt/_content/m/m04/m04433.html?nn= 6610622, 15. EL Stand 2016

[17] Apple Inc.: Das Startvolume Ihres Mac mit FileVault verschlüsseln. https: //support.apple.com/de-de/HT204837, Januar 03, 2018

[18] Apfelböck, Hermann: Linux-Verschlüsselung: So sichern Sie Ihre Daten ab. https://www.pcwelt.de/ratgeber/ Linux-Verschluesselung-Daten-absichern-9802537.html, 29.01.2018

[19] Microsoft ; Microsoft Docs (Hrsg.): Overview of BitLo- cker Device Encryption in Windows 10. https://docs.microsoft. com/en-us/windows/security/information-protection// bitlocker-device-encryption-overview-windows-10, 28.02.2019

[20] Microsoft Docs: BitLocker: BitLocker overview. https://docs. microsoft.com/en-us/windows/security/information-protection/ bitlocker/bitlocker-overview, 26.01.2018

66 Literaturverzeichnis

[21] Microsoft Corporation: BitLockerTM Drive Encryption Security Po- licy: For FIPS 140-2 Validation. https://csrc.nist.gov/csrc/media/ projects/cryptographic-module-validation-program/documents/ security-policies/140sp947.pdf, 31.08.2011

[22] Kornblum, Jesse D.: Implementing BitLocker Drive Encryption for forensic analysis. In: Digital Investigation 5 (2009), Nr. 3-4, S. 75–84. http://dx.doi. org/10.1016/j.diin.2009.01.001. – DOI 10.1016/j.diin.2009.01.001. – ISSN 17422876

[23] Marcin Ulikowski: Volatility Framework plugin for extracting BitLocker FVEK. https://github.com/elceef/bitlocker, 16.05.2016

[24] Microsoft Docs: Prepare your organization for BitLo- cker: Planning and policies. https://docs.microsoft.com/ en-us/windows/security/information-protection/bitlocker/ prepare-your-organization-for-bitlocker-planning-and-policies, 24.04.2019

[25] Apple Inc.: macOS Sicherheit–Überblick für die IT. https://www.apple. com/de/business/resources/docs/macOS_Security_Overview.pdf,

[26] Metz, Joachim ; Choudary, Omar ; Grobert, Felix: IFIP Advances in Infor- mation and Communication Technology. Bd. v.410: Security Analysis and De- cryption of Filevault 2: 9th IFIP WG 11. 9 International Conference on Digital Forensics, Orlando, FL, USA, January 28-30, 2013, Revised Selected Papers. Berlin/Heidelberg : Springer Berlin Heidelberg, 2013. – ISBN 9783642411472

[27] Urban, Julie: Examining Mac Data from Hardware With the Ap- ple T2 Chip. https://www.blackbagtech.com/blog/2018/08/21/ examining-mac-data-hardware-apple-t2-chip/, 21.08.2018

[28] Afonin, Oleg: Breaking FileVault 2 Encryption Through iCloud. https: //blog.elcomsoft.com/2016/08/breaking-filevault-2-encryption/, 29.08.2016

[29] Chicken, Tribal: Extracting FileVault 2 Keys with Volatility. https: //tribalchicken.io/extracting-filevault-2-keys-with-volatility/, 13.02.2016

[30] Broz, Milan: dm-crypt: Linux kernel device-mapper crypto target. https: //gitlab.com/cryptsetup/cryptsetup/wikis/DMCrypt, 23.04.2019

67 Literaturverzeichnis

[31] Fruhwirth, Clemens: LUKS1 On-Disk Format Specification: Version 1.2.3.

[32] Broz, Milan: LUKS2 On-Disk Format Specification: Version 1.0.0.

[33] Natarajan, Ramesh: 10 Linux cryptsetup Examples for LUKS Key Manage- ment (How to Add, Remove, Change, Reset LUKS encryption Key). https: //www.thegeekstuff.com/2016/03/cryptsetup-lukskey/, 01.03.2016

[34] Pettersson, Torbjörn: Cryptographic key recovery from Linux memory dumps

[35] VeraCrypt: VeraCrypt: Free Open source disk encryption with strong security for the Paranoid. https://www.veracrypt.fr/en/Home.html, 13.09.2018

[36] VeraCrypt: VeraCrypt - Documentation: System Encryption. https://www. veracrypt.fr/en/System%20Encryption.html, 30.06.2017

[37] VeraCrypt: VeraCrypt - Documentation: VeraCrypt Volume Format Spe- cification. https://www.veracrypt.fr/en/VeraCrypt%20Volume%20Format% 20Specification.html, 30.06.2017

[38] VeraCrypt: VeraCrypt - Documentation: Keyfiles. https://www. veracrypt.fr/en/Keyfiles%20in%20VeraCrypt.html, 30.06.2017

[39] VeraCrypt: VeraCrypt - Documentation: PIM. https://www.veracrypt. fr/en/Personal%20Iterations%20Multiplier%20%28PIM%29.html, 30.06.2017

[40] VeraCrypt: VeraCrypt - Documentation: Memory Dump Files. https:// www.veracrypt.fr/en/Memory%20Dump%20Files.html, 30.05.2017

[41] VeraCrypt: VeraCrypt - Documentation: Using VeraCrypt Without Ad- ministrator Privileges. https://www.veracrypt.fr/en/Using%20VeraCrypt% 20Without%20Administrator%20Privileges.html, 30.06.2017

68 Abbildungsverzeichnis

Abbildungsverzeichnis

4.1 Schematische Darstellung einer RAID-0 Konfiguration mit zwei Da- tenträgern, Quelle: Wikipedia [7]...... 19 4.2 Schematische Darstellung einer RAID-1 und einer RAID-5 Konfigu- ration mit zwei bzw. vier Datenträgern, Quelle: Wikipedia [7]..... 20 4.3 Schematische Darstellung einer RAID-10 Konfiguration mit vier Da- tenträgern, Quelle: Wikipedia [7]...... 20 4.4 Schematische Darstellung einer RAID-51 Konfiguration mit sechs Da- tenträgern, Quelle: Wikipedia [7]...... 20 4.5 Schematische Darstellung einer RAID-6 Konfiguration mit fünf Da- tenträgern, Quelle: Wikipedia [7]...... 21 4.6 Imagedatei öffnen in R-Studio ...... 23 4.7 R-Studio: Imagedatei öffnen...... 24 4.8 Button Image öffnen in R-Studio ...... 25 4.9 Virtuellen Block erstellen in R-Studio ...... 25 4.10 Die Geräte-Ansicht von R-Studio ...... 25 4.11 R-Studio: Der Bereich parent...... 26 4.12 R-Studio: RAID-Parameter...... 26 4.13 R-Studio: RAID-Konsistenz...... 27 4.14 R-Studio: Menüpunkt scannen...... 27 4.15 R-Studio: Darstellung der RAID-Konsistenz...... 28 4.16 R-Studio: Parameter für die Scannen-Funktion...... 28 4.17 R-Studio: Dateitypen beim Scannen auswählen...... 29 4.18 R-Studio: Übersicht des Fortschritts beim Scannen...... 29 4.19 R-Studio: Image erstellen...... 30 4.20 R-Studio: Byte-Für-Byte Image erstellen...... 30 4.21 R-Studio: Scan Informationen speichern...... 31 4.22 LVM Architektur [13]...... 37 4.23 Volume Groups und Volumes identifizieren...... 38 4.24 Volumes und Dateisysteme...... 39 4.25 Dateisystem des Snapshots...... 39 4.26 GPT-Tabelle der physischen Disk...... 41 4.27 GPT-Tabelle der virtuellen Disk...... 42 4.28 GPT-Tabelle auf physischer Disk identifiziert...... 42 4.29 NTFS Master File Table der virtueller Disk...... 43 4.30 NTFS Master File Table auf phsischer Disk identifiziert...... 43 4.31 Datenträger sichern mit DiskDumper ...... 44

5.1 BitLocker Key Architecture. Entnommen aus: [21, S. 9]...... 48 5.2 Partitionstabelle einer Festplatte mit einer BitLocker-Partition.... 49

69 Abbildungsverzeichnis

5.3 BitLocker Signatur am Beginn der Partition...... 50 5.4 Metadaten der mit BitLocker verschlüsselten Partition...... 50 5.5 BitLocker verschlüsselten Partition entschlüsselt einhängen...... 51 5.6 APFS/ FileVault2 Partitionstabelle - mmls ...... 52 5.7 APFS/ FileVault2 Partitions-/ Volumeinformationen - apfsutil .... 53 5.8 FileVault2 verschlüsselte Partition einbinden...... 53 5.9 Ubuntu Installationsoptionen...... 55 5.10 Partitonstabelle des verschlüsselten Ubuntu...... 56 5.11 Dateisysteme der Linux Partitionen...... 56 5.12 EWF Image mit Xmount einbinden...... 56 5.13 LUKS Partition als Loop-Device bereitstellen...... 56 5.14 LUKS Header mit cryptsetup anzeigen...... 57 5.15 Partition entschlüsseln und LVM Volumes mappen...... 58 5.16 Partitionstabelle des mit VeraCrypt verschlüsselten Windows..... 60 5.17 Image mit Partitionen als Loop-Device einbinden...... 60 5.18 VeraCrypt Partition einbinden...... 60 5.19 VeraCrypt Partition mit cryptsetup einbinden...... 61

70 Abbildungsverzeichnis

Abkürzungsverzeichnis

AFF Advanced Forensic Format APFS Apple File System BDSG Bundesdatenschutzgesetz BKAG Bundeskriminalamtsgesetze CPU Central Processing Unit DSGVO Datenschutzgrundverordnung EEPROM Electrically Earsable Programmable Read-Only Memory EFS Encrypting File System EncFS Encrypted Filesystem EWF Expert Witness Format FVEK Full Volume Encryption Key GG Grundgesetz GUID Globally Unique Identifier HDD Hard Drive Disk LDM Logical Disk Manager LUKS Linux Unified Key Setup LVM Logical Volume Manager MBR Master Boot Record MD Multiple Disk NTFS New Technology File System PIM Personal Iterations Multiplier PolG Polizeigesetz RAID Redundant Array of Independent Disks RAM Random-Access Memory ReFS Resilient File System S2D Storage Space Direct

71 Abbildungsverzeichnis

SSD Solid-State-Drive SSHD Solid State Hybrid Drive StGB Strafgesetzbuch StPO Strafprozessordnung TPM Trusted Platform Module VM Virtual Machine VMK Volume Master Key WSS Windows Storage Spaces

72 Selbstständigkeitserklärung

Selbstständigkeitserklärung

Hiermit erklären wir, dass wir die hier vorliegende Arbeit selbstständig, ohne uner- laubte fremde Hilfe und nur unter Verwendung der aufgeführten Hilfsmittel ange- fertigt haben.

Ort, Datum Unterschrift

73