Studienarbeit. Verteidigung externer Rechnerressourcen

Studienarbeit Verteidigung externer Rechnerressourcen Risiken durch die Aufgabe der physikalischen Kontrolle und Gegenmaßnahmen am Beispiel gemieteter Linux Server Falk Husemann März 2014 Technische Universität Dortmund Fakultät für Informatik Lehrstuhl für praktische Informatik (LS4) http://ls4-www.cs.tu-dortmund.de

Inhaltsverzeichnis 1 Einleitung 1 2 Risiken externer Rechnerressourcen 3 2.0.1 Anwendungsausführung......................... 4 2.0.2 Virtuelle Maschinen........................... 4 2.0.3 Physikalische Ressourcen......................... 4 3 Abwehrkonzepte 7 3.0.4 Anti-Forensik............................... 7 3.0.5 Attack Trees............................... 8 3.0.6 Militärtaktik............................... 9 4 Gemietete Linux-Server 11 4.0.7 Vermieterumfeld............................. 11 4.0.8 Angriffsmodelle.............................. 12 5 Gegenmaßnahmen 15 5.0.9 Verschlüsselung.............................. 15 5.0.10 Pre-Boot Umgebung........................... 17 5.0.11 Scout................................... 18 5.0.12 Deceivers Getty.............................. 19 6 Implementierung 23 6.0.13 Rettungssystem prüfen.......................... 23 6.0.14 Installationsvorbereitung......................... 24 6.0.15 Installation durchführen......................... 24 6.0.16 Betriebssystem anpassen......................... 26 6.0.17 Systemstart................................ 26 7 Zusammenfassung & Ausblick 29 Literaturverzeichnis 31 i

ii INHALTSVERZEICHNIS A Anhang 33 A.1 dgetty....................................... 33 A.2 scout........................................ 35 Erklärung 37

Kapitel 1 Einleitung Das Mieten von externen Rechnerressourcen für Unternehmen und Institutionen bietet eine Entlastung. Gemietete Rechnerressourcen sind günstig, bei Bedarf näher am Kunden und bieten vertragliche Garantien, für deren Einhaltung der Vermieter zuständig ist. Dazu gehört zum Beispiel die Verpflichtung zum Hardwaretausch bei Defekt. Aber auch allgemeine Garantien zur Verfügbarkeit, der Netzanbindung oder der Stromversorgung sind möglich. Diesen Entlastungen steht die Delegation des operativen Betriebs entgegen, die dazu führt, dass Abstriche beim Datenschutz und der Integrität seitens des Mieters gemacht werden müssen. Der Vermieter externer Rechnerressourcen übt unmittelbar die physikalische Kontrolle aus. Um Schutzziele wie Vertrauchlichkeit, Integrität oder Zurechenbarkeit (siehe [2]) zu gewährleisten, muss die Mitwirkung des Vermieters gesichert sein. Von der Mitwirkung zur Einhaltung der gesetzten Schutzziele durch den Vermieter kann aber nicht immer ausgegangen werden. Werden Rechnerressourcen in fremden Ländern angemietet, ist der Vermieter zur Einhaltung der dort geltenden Rechte verpflichtet, auch wenn diese den Schutzzielen des Mieters entgegen stehen. Ein Vermieter von Servern in China ist anderen Gesetzen zum Datenschutz unterworfen, als der deutsche Mieter. Trotz des grenzübergreifenden Datenverkehrs müssen beide die lokale Gesetzgebung beachten. Dies führt zwangsweise zu Interessenskonflikten. Aber auch innerhalb eines Landes können Interessenskonflikte die Einhaltung von definierten Schutzzielen verhindern. Nachlässigkeit des Vermieters oder Hintertüren in der vermieteten Dienstleistung im angenommenen Interesse des Mieters, oder den Schutzzielen des Mieters entgegenstehende gesetzliche Bestimmungen. Aus diesen Gründen müssen sensible Daten durch besondere Schutzmaßnahmen gegen Fremdzugriff gesichert werden. Diese Studienarbeit untersucht die Bedrohungen, Risiken und Schwachstellen, denen die Daten des Mieters ausgesetzt sind und bietet unkonventio- 1

2 KAPITEL 1. EINLEITUNG nelle Lösungsmöglichkeiten. Es wird von der Prämisse ausgegangen, dass der Vermieter gegen die Schutzziele des Mieters handelt oder handeln muss. Zum Beispiel, um persönliche Vorteile zu erlangen, oder um gesetzliche Pflichten zu erfüllen. Dabei werden Gegenmaßnahmen exemplarisch am Beispiel Linux vorgestellt und eine Taktik entwickelt, um die Maßnahmen gemeinsam einsetzen zu können.

Kapitel 2 Risiken externer Rechnerressourcen Durch die Delegation der physikalischen Kontrolle, muss dem Vermieter der externen Rechnerressource besonderes Vertrauen entgegengebracht werden. Dieses Vertrauen kann durch den Vermieter auf vielfältige Weise missbraucht werden. Folgend werden externe Ressourcen grob in mehrere Klassen, in Abhängigkeit ihres Abstraktionsgrades von physikalischen Ressourcen, aufgeteilt. Dies dient der Demonstration der vielfältigen Möglichkeiten des Vermieters, die Schutzziele des Mieters zu verletzten. Um die physikalischen Bedrohungen zu modellieren werden AttackTrees[12] verwendet. Abbildung 2.1: Schichten eines Computersystems und Abstraktionsebenen Externe Rechnerressourcen, die durch den Vermieter zur Verfügung gestellt werden, können nicht nur physikalisch sein. Rechnerressourcen werden zur Steigerung der Effizienz, Vereinfachung der Verwaltung oder aus Kostengründen auch über von der Hardware abstrahierende Ebenen zur Verfügung gestellt. Jede dieser Abstraktionsebenen bietet dem Vermieter potenziell Zugang zu den abstrahierten Ressourcen. 3

4 KAPITEL 2. RISIKEN EXTERNER RECHNERRESSOURCEN 2.0.1 Anwendungsausführung Am weitesten von der Computerhardware entfernt, ist die gemietete Anwendungsausführung, wie zum Beispiel bei Webhosting-, Mail-, oder Backup-Dienstleistungen. Hier wird für viele Mieter ein (Verbund-)System von physikalischen Servern betrieben, auf das der Mieter keinen Zugriff hat. Der Mieter wird in die Lage versetzt, die gemietete Anwendung in begrenztem Umfang zu steuern. Eine Einhaltung von Schutzzielen gegen den Willen des Vermieters ist hier schwer. Um die unter der vermieteten Anwendung liegenden Schichten des Computersystems zu administrieren, die auch die Daten der gemieteten Anwendung enthalten, muss der Vermieter Einsicht nehmen können. Daraus folgt, dass die Vertraulichkeit der gespeicherten Daten gegen den Willen des Vermieters nicht möglich ist. Bei der naheliegenden Vermutung, dass Verschlüsselung mit Public-Key-Verfahren helfen könnte, ist zu bedenken, dass für die Verarbeitung durch die gemietete Anwendung, die zu verarbeitenden Daten zumindest während ihrer Auswertung im Klartext vorliegen müssen. 2.0.2 Virtuelle Maschinen Nächst näher an der Computerhardware sind Virtuelle Maschinen. Dabei wird ein Computer mittels Virtualisierung nicht direkt auf der Computerhardware ausgeführt, sondern auf einer Virtuellen Maschine, die durch einen Hypervisor zur Verfügung gestellt wird. Genau wie bei der Anwendungsausführung ist eine Intervention durch den Vermieter leicht dadurch möglich, dass zu administrativen Zwecken Zugriff auf die unteren Schichten des Computersystems bestehen muss. Typische Hypervisoren speichen die virtuellen Festplatten der virtuellen Maschinen in Dateien, die leicht ausgelesen und mit forensischen Programmen analysiert werden können. 2.0.3 Physikalische Ressourcen Um Schutzziele einzuhalten, eignen sich abstrahierte Rechnerressourcen nicht. Je mehr unterliegende Schichten eine externe Rechnerressource benötigt und je weniger der Mieter selbst verwaltet, desto einfacher ist der Zugriff durch den Vermieter möglich. Bei gemieteter Anwendungsausführung (2.0.1) genügen bereits einfache Hilfsprogramme, bei virtuellen Maschinen (2.0.2) kann die virtuelle Festplattendatei herangezogen werden. Aber auch durch physikalische Angriffe auf die Ressourcen, wie zum Beispiel einen gemieteten Server, kann leicht Zugriff auf die beim Vermieter gespeicherten Daten erlangt werden. Dazu können alle Ein- und Ausgabeschnittstellen herangezogen werden.

5 Um ohne Erlaubnis auf Daten eines gemieteten Servers zuzugreifen, hat der Vermieter verschiedene Möglichkeiten. Dabei wird zwischen verschiedenen Ebenen des physikalischen Zugriffs in Abhängigkeit der Tiefe des Eingriffs unterschieden. Zuerst ist der Vermieter in der Lage, durch Anschluss von Ein- und Ausgabegeräten Zugriff auf die lokale Befehlsschnittstelle, wie zum Beispiel ein Unix getty oder den Windows- Anmeldebildschirm zu erlangen. Dort kann Interaktion mit dem System stattfinden. Nächst tiefer ist der Eingriff in den Betrieb durch den Anschluss von Peripheriegeräten, wie zum Beispiel der Start des Systems von einer CD-ROM oder DVD-ROM, mit dem Ziel lokale Daten unter Umgehung der Zugriffsbeschränkungen des Betriebssystems zu lesen, zu schreiben oder zu verändern. Durch Anschluss von Peripheriegeräten per FireWire kann ein Hauptspeicher-Abbild im laufenden Betrieb erstellt werden. Zuletzt kann der Vermieter den Festspeicher aus dem System entfernen, um ein Abbild zur forensischen Analyse zu erstellen. Die Möglichkeiten sind breit gefächert und der physikalische Zugriff kann durch den Mieter nicht verhindert werden.

6 KAPITEL 2. RISIKEN EXTERNER RECHNERRESSOURCEN

Kapitel 3 Abwehrkonzepte Aus den in Abschnitt 2.0.3 gezogenen Schlussfolgerungen hinsichtlich der Risiken extern gemieteter Rechnerressourcen folgt, dass die Anmietung physikalischer Ressourcen die erfolgreichsten Aussichten zur Einhaltung vorgegebener Schutzziele bietet. Um diesen Ansatz weiter zu verfolgen und die Risiken externer physikalischer Ressourcen betrachten zu können, werden drei Methodiken vorgestellt. Zuerst wird der forensische Prozess nach BSI-Methode beschrieben und die Methoden der Anti-Forensik eingeführt. Dann wird die Modellierung von Angriffen mittels AttackTrees dargestellt. Um ein ganzheitliches Konzept zur Verteidigung entwickeln zu können, werden darauffolgend grundlegende Militärtaktiken beschrieben. 3.0.4 Anti-Forensik Anti-Forensik beschäftigt sich mit Verfahren, die Existenz, Menge und Qualität von Beweisen negativ [zu] beeinflussen [5]. Dabei wird zwischen verschiedenen Teilgebieten unterschieden. Allen liegt zugrunde, dass sie Teilaspekte des forensischen Prozesses zur Erhebung von Beweisen negativ beeinflussen. Der forensische Prozess, wie im Leitfaden IT-Forensik [6] des Bundesamts für Sicherheit in der Informationstechnik angegeben, wird durch einen kontinuierlichen Verbesserungsprozess abgebildet. Alle Untersuchungsabschnitte des Prozesses haben gemeinsam, dass ihre Ergebnisse in einem Nachschritt dokumentiert und zusammengefasst werden müssen. Der Prozess wird in folgende Teilschritte untergliedert. 1. Strategische Vorbereitung 2. Operationale Vorbeitung 3. Datensammlung 4. Untersuchung 5. Datenanalyse 7

8 KAPITEL 3. ABWEHRKONZEPTE 6. Dokumentation Die Teilgebiete der Anti-Forensik richten sich hauptsächlich gegen die Datensammlung, Untersuchung und Datenalyse. Eine Einordnung und Beschreibung folgt. Das Ziel des Teilgebiets Trail obfuscation (Spurverschleierung) ist es, die Erstellung von Zeitabläufen und zughörigen Ereignissen zu beeinflussen. Zu diesem Zweck können unter anderem Logdateien gelöscht, verändert oder gefälscht werden, sodass ein falsches Bild des zeitlichen Ablaufs von Ereignissen ensteht. Darüber hinaus können Falschinformationen im zu analysierenden Dateisystem abgelegt werden. Dieses Teilgebiet richtet sich gegen die erfolgreiche Datenanalyse. Das Teilgebiet Data hiding (Daten verstecken) beschäftigt sich mit den Möglichkeiten den Schritt der Datensammlung zu erschweren oder zu verhindern. Dafür wird Steganographie oder die folgend angewendete Verschlüsselung eingesetzt. Mittels Artifact wiping/data destruction (Daten zerstören) wird ebenfalls die Datensammlung erschwert, indem die sammelbaren Daten vernichtet werden. Über diese Maßnahmen hinaus ist eine Verteidigung nicht nur gegen den forensichen Prozess, sondern gegen den Forensiker denkbar. 3.0.5 Attack Trees Attack Trees sind eine Erweiterung von Fehlerbäumen und wurden von Bruce Schneier entwickelt [12], um vorsätzliche Angriffe formal modellieren zu können. Sie bestehen aus drei Komponenten. Die Wurzel gibt das übergeordnete Angriffsziel an. Knoten geben Teilziele an. Blätter geben Wege zum Erreichen des verbundenen Teilziels an. Knoten können AND- oder OR-Verknüpft werden. Zur Vereinfachung wird angenommen, dass alle nicht gekennzeichneten Knoten OR-Verknüpft sind. Ein einfacher Attack Tree, um einen Safe zu öffnen, sieht wie folgt aus 1. Zur einfacheren Lesbarkeit kann der Baum in Listennotation überführt werden und sieht dann wie folgt aus. 1. Safe öffnen 1.1. Schloss knacken 1.2. Kombination finden 1.2.1. Notiz finden 1.2.2. Kombination von Zielperson 1.2.2.1. Bedrohen 1.2.2.2. Abhören (AND) 1 Beispiel aus Bruce Schneiers Veröffentlichung

9 Abbildung 3.1: Attack Tree zur Öffnung eines Safes 1.2.2.2.1. Gespräch belauschen 1.2.2.2.2. Ziel zur Nennung der Kombination bringen 1.2.2.3. Erpressen 1.2.2.4. Bestechen 1.3. Safe aufschneiden 1.4. Falsch installiert Nach Schneier können den Knoten und Blättern boolesche und kontinuierliche Werte zugewiesen werden. 3.0.6 Militärtaktik Um Gegenmaßnahmen, gegen den in Abschnitt 3.0.4 vorgestellen forensischen Prozess, nicht nur auf operativer Ebene einsetzen zu können, muss eine Taktik entwickelt werden. Dies ist dem notwendigen Zusammenspiel verschiedener Maßnahmen geschuldet, die auch den menschlichen Faktor berücksichtigen müssen. Es bietet sich an, bewährte Koordinationsmaßnahmen der Militärtaktik zu entlehnen und anzupassen. Perimeter In der IT-Sicherheit spielte sehr lange die Perimeter-Taktik die entscheidende Rolle. Dabei wird um die zu schützenden Ressourcen ein Perimeter gebildet und mit Hilfe von Firewalls und Einbruchserkennungssystemen verteidigt. Eine typische Aufteilung in mehrere Perimeter unterscheidet zwischen externen, internen und gegebenfalls exponierten (DMZ) Netzwerksegmenten.

10 KAPITEL 3. ABWEHRKONZEPTE Defense in depth (Tiefenstaffelung) ist eine Taktik deren Ziel nicht die Verhinderung eines erfolgreichen Angriffs ist, sondern die Verzögerung. Statt den Angreifer durch eine starke Verteidigungslinie zu besiegen, werden die Anstrengungen in die Tiefe gestaffelt um ein schnelles Vordringen zu verlangsamen und Zeit für eine angemessene Reaktion zu gewinnen. Übertragen auf die IT-Sicherheit entspricht dies der Absicherung der einzelnen schützenswerten Komponenten über die Netzwerk- und Anwendungsebenen. Hedgehog defence (Einigeln) ist eine Taktik deren Ziel nicht die Verteidigung einer Frontlinie ist. Kleine Einheiten werden an stark befestigten Punkten eingesetzt und führen die Verteidigung auch dann weiter aus, wenn die durch diese Punkte gebildete Verteidigungslinie durchbrochen wurde. Das führt dazu, dass große Mengen an Ressourcen gebunden werden, um die so verteidigten Punkte anzugreifen. Diese rundherum verteidigbaren Punkte können entweder durch Ausbrüche oder Nachschub zu einer Verteidigungslinie ausgebaut werden und schneiden die vorgedrungenen Angreifer vom Nachschub ab. Angewandt auf die IT-Sicherheit entspricht dies der Absicherung der Zugangspunkte zu den schützenswerten Ressourcen und die Herstellung einer Interaktionsmöglichkeit zwischen den dafür eingesetzten Sicherungsmaßnahmen.

Kapitel 4 Gemietete Linux-Server Exemplarisch werden folgend die Zugriffsmöglichkeiten auf einen gemieteten Linux-Server und weitere Risiken durch Vorarbeiten des Vermieters betrachtet. Dazu kommen Risiken, die nicht durch den regulären Betrieb, sondern durch forensiche Analyse nach dem in 3.0.4 vorgestellten Prozess entstehen. 4.0.7 Vermieterumfeld Das Mieten eines externen Servers besteht seitens des Vermieters aus vielen Teil-Dienstleistungen. Um Server effektiv zu verwalten, bieten viele Vermieter zusätzliche Hilfs-Dienstleistungen an. Dazu gehören nicht abschließend folgende. Verwaltungsoberfläche zur Verwaltung des Servers und Zugriff auf weitere Hilfs-Dienstleistungen. Vorbereitete Betriebssystem-Abbilder können durch den Mieter über eine Verwaltungsoberfläche eingespielt werden. Je nach Grad der Anpassung durch den Vermieter können diese Abbilder eigene Kernel, Netzwerkmonitoring-Skripte und SSH-Schlüssel für die Verwaltung durch den Vermieter enthalten. Webreset um den Server durch den Mieter selbstständig neustarten zu können. Rettungssystem um im Fehlerfall des installierten Betriebssystems den Mieter in die Lage zu versetzen, den Fehler zu beheben. Diese Umgebungen werden meist mittels PXE über das Netzwerk gestartet. Servermanagement und -monitoring Skripte die den Zustand des Servers in die Verwaltungsoberfläche des Vermieters einbinden. Fernwartungszugänge über die der Vermieter im Fehlerfall vollen Zugang zum Servers des Mieters erlangen kann, um Fehler zu beheben. 11

12 KAPITEL 4. GEMIETETE LINUX-SERVER KVM over IP durch die der Mieter den Server bis auf BIOS-Ebene steuern kann. 1 Jede Teil-Dienstleistung kann die Arbeit des Mieters erleichtern, aber auch eingesetzt werden, um Schutzziele zu verletzen. Mittels vorbereiteten Betriebssystem-Abbildern kann Schadsoftware auf dem Server eingeschleust werden. Durch die Fähigkeit des Vermieters, den Server mittels Webreset aus- und einzuschalten, die Verfügbarkeit verletzt werden. Ein zur Verfügung gestelltes Rettungssystem kann alle getätigten Eingaben protokollieren. Um das Ausnutzen der genannten Verletzungspotenziale auszuschließen, muss auf den Einsatz der vom Vermieter angebotenen Hilfsdienste verzichtet werden. Wo dies nicht möglich ist, muss die Ausnutzung der potenziellen Schwachstellen zuverlässig erkannt werden. Über die hinreichend bekannten Möglichkeiten des Vermieters hinaus, sind auch herkömmliche Maßnahmen zur forensischen Analyse des Servers einsetzbar. Allen vorran die Datensammlung durch Erstellung von Kopien der Datenträger. Aufgrund der vielfältigen Möglichkeiten des Vermieters auf das gemietete System Einfluss zu nehmen, ist eine Perimeter- Verteidigung wie in 3.0.6 beschrieben wenig erfolgversprechend. 4.0.8 Angriffsmodelle Um die Möglichkeiten des Vermieters oder eines Forensikers darzustellen, werden folgend die in 3.0.5 vorgestellten Attack Trees eingesetzt. Es wird mit dem Attack Trees für das Auslesen des lokalen Datenträgers eines ungeschützten gemieteten Linux Servers begonnen. Durch Vorstellung der entwickelten Gegenmaßnahmen wird dieser spezialisiert und erweitert. Ungeschützt ergeben sich vier grundlegende Möglichkeiten, den Datenträger des Servers auszulesen. Die Erste ist, den Datenträger auszubauen und auszulesen. Es gibt keine Einschränkungen und keine Abwehr gegen die forensische Analyse, die Daten sind sofort lesbar. Die zweite Möglichkeit besteht darin, in den Startprozess des Systems einzugreifen und das Linux-System anzuweisen, statt dem init Prozess ein anderes Programm zu starten, dass keine Zugriffsbeschränkungen durchsetzen kann. Bei dieser Möglichkeit muss die Konfiguration des Bootmanagers angepasst werden 2. Die dritte Möglichkeit ist, die Anmeldung an der lokalen Kommandozeile mittels Monitor und Tastatur. Hierbei sind Monitor und Tastatur nur zwei repräsentative Möglichkeiten. Ein Angriff durch Ausprobieren ist programmatisch mit eingebetteten Systemen möglich, die sich als Tastatur ausgeben. Weiter ist der Zugriff auf den Arbeitsspeicher des Systems über DMA-Schnittstellen wie Firewire 1 Diese Technologie findet gerade weite Verbreitung auf vielen Servern unter dem Namen vpro, AMT und IPMI. 2 Zum Beispiel bei GRUB, durch Ergänzung der Zeile init=/bin/bash als Kernel-Parameter

13 möglich [9]. Aus diesen Überlegungen ergibt sich der folgende Attack Tree in Graphen- und Listennotation. Abbildung 4.1: Schritt 1: Attack Tree ungeschützter Server 1. Datenträger auslesen 1.1 Datenträger ausbauen 1.2 System ohne Zugriffsbeschränkungen starten (AND) 1.2.1 System Neustarten 1.2.2 Lokale Eingabe im Bootmanager 1.3 Lokale Anmeldung 1.4 DMA Zugriff

14 KAPITEL 4. GEMIETETE LINUX-SERVER

Kapitel 5 Gegenmaßnahmen Um die vorgenannten Bedrohungen abzuwenden, zu erkennen oder zu vereiteln, wird ein Maßnahmenkatalog vorgeschlagen. Das Ergebnis ist ein voll-verschlüsselter physikalischer Server, der besonders physikalischen Bedrohungen eine angemessene Verteidigung entgegensetzt. Dabei wird die Hedgehog-Taktik aus 3.0.6 angewendet, indem viele einzelne Mechanismen zusammen die Sicherheit des Servers erhöhen. 5.0.9 Verschlüsselung Im Abschnitt Anti-Forensik (3.0.4) wird Verschlüsselung als Verteidigung gegen die forensische Analyse gespeicherter Daten vorgestellt. Verschlüsselung bezeichnet den Vorgang, bei dem ein Klartext durch Anwendung eines Verschlüsselungsverfahrens in einen Geheimtext gewandelt wird. Um den Geheimtext wieder lesbar zu machen, ist ein Schlüssel notwendig. Folgend wird beschrieben, welche verschiedenen Verschlüsselungsmechanismen zur Verschlüsselung eines gemieteten Servers zur Verfügung stehen. Full-Disk-Encryption wird als Lösung vorgestellt und das Bootschlüssel-Problem beschrieben, dass folgend gelöst werden muss. Linux dm-crypt Für Linux steht das transparente Verschlüsselungs-Subsystem dm-crypt zur Verfügung. Bei der Verschlüsselung eines Servers mit dm-crypt nach [11] werden Metadaten in den Kopf der verschlüsselten Partition geschrieben (LUKS-Header wie in [4] beschrieben). Diese Metadaten erlauben die Erkennung der Partition als verschlüsselt. Die Partition selbst kann mit verschiedenen Blockchiffren wie AES, Twofish oder RC4 verschlüsselt werden. Die Chiffren können in verschiedenen Betriebsarten (siehe [3] für abschließende Auflistung) eingesetzt werden. 15

16 KAPITEL 5. GEGENMAßNAHMEN Bei externen Rechnerressourcen wie zum Beispiel gemieteten Servern ergeben sich durch die geographische Entfernung besondere Einschränkungen für die Wirksamkeit der Verschlüsselung mit dm-crypt. Verschlüsselung schützt gespeicherte Daten nur, wenn sie aktiv ist. Das setzt voraus, dass der gemietete Server ausgeschaltet ist oder im richtigen Moment vor dem Versuch des Auslesens ausgeschaltet wird. Ohne geeignete zusätzliche Überwachung, wie zum Beispiel ein System zur Einbruchserkennung, kann dieser Moment nicht erkannt werden. Full-Disk-Encryption Wird die Installation des Servers durch den Vermieter vorgenommen, kann darüber hinaus nur die Datenpartition beziehungsweise einzelne Verzeichnisse nachträglich verschlüsselt werden. Dies stellt keinen umfassenden Schutz vor forensischer Analyse dar, da wertvolle Metadaten und Audit trails auf der Systempartition hinterlassen werden. Daraus folgt, dass nur eine Voll-Verschlüsselung, sogenannte Full-Disk-Encryption (FDE), des gesamten Festspeichers, im ausgeschalteten Zustand der forensischen Analyse widerstehen kann. Um ein Betriebssystem von einem mittels FDE verschlüsselten Datenträger zu starten, muss entgegen der Namensgebung ein unverschlüsselter Teil des Datenträgers herangezogen werden. Auf diesem Teil befindet sich in der Regel der Systemkern, notwendige Treiber und die Software zur Entschlüsselung der weiteren zum Systemstart notwendigen Blöcke. Dieser Teil des Datenträgers kann nicht geschützt werden. Bootschlüssel-Problem Bei mittels FDE verschlüsselten Systemen muss bei jedem Systemstart der Schlüssel für den Datenträger eingegeben werden, von dem das Betriebssystem gestartet werden soll. Um diese Eingabe zu ermöglichen, startet das System in eine Pre-Boot Umgebung, die Eingaben entgegen nehmen kann [1]. Bei einem gemieteten Server steht die Möglichkeit zur lokalen Eingabe nicht zur Verfügung. Zur Freischaltung der Full-Disk-Encryption über das Internet muss ein geheimer Schlüssel über verschiedene Netze zum geographischen Standort des Servers übertragen werden. Bedingt durch die Architektur des Internets wird die Verbindung zur Übertragung des Schlüssels einen nicht exakt vorhersehbaren Weg nehmen und kann an einer nicht abschätzbaren Anzahl an Knotenpunkten abgefangen werden. Trotzdem muss die Vertraulichkeit der Übertragung und die Beschränkung des Zugangs zur Pre-Boot Umgebung gewährleistet werden. Aus diesen Überlegungen ergibt sich der folgende Attack Tree eines mit FDE verschlüsselten Servers in Abbildung 5.1. Die in 4.1 beschriebenen Schritte 1.1 Datenträger ausbauen und 1.2.2 Lokale Eingabe im Bootmanger

17 führen nicht mehr zum Erfolg. Der Schritt 1.2.1 System Neustarten bleibt genauso wie die übrigen Schritte weiter möglich, führt aber nicht mehr zum gewünschten Ziel und wird deshalb gestrichen. Abbildung 5.1: Schritt 2: Server mit Full-Disk-Encryption 1. Datenträger auslesen 1.1 Bootschlüssel abhören 1.1.1 Netzwerkmitschnitt (AND) 1.1.1.1 Routerzugriff erlangen 1.1.1.2 Schlüsel mitschneiden 1.1.2 Keylogger in Pre-Boot Umgebung 1.2 Lokale Anmeldung 1.3 DMA Zugriff Da noch keine Möglichkeit vorgestellt wurde, den Bootschlüssel sicher zu übertragen, kann dieser abgehört werden. Die notwendigen Vorraussetzungen dafür erfüllt unter anderem das vom Vermieter zur Verfügung gestellte Netzwerk, über das der Schlüssel übertragen werden muss. Da der Netzwerkzugang ein zentraler Teil der gemieteten Dienstleistung ist, kann er nicht wie in 4 vorgeschlagen, auf ihn verzichtet werden. 5.0.10 Pre-Boot Umgebung Unter Linux wird die Pre-Boot Umgebung aus der initrd geladen [7]. Die initrd ist ein Dateisystemabbild und enhält ein vorläufiges Wurzeldateisystem. Zweck der in der initrd enthaltenen Werkzeuge und Treiber ist es, den weiteren Startprozess durchzuführen. Bei einem nach FDE verschlüsselten System enthält die initrd neben den genannten Werkzeugen auch die Werkzeuge und Schnittstellen, um die Entschlüsselung der Datenträger einzuleiten und die dafür notwendigen Schlüssel über eine Eingabeaufforderung entgegen

18 KAPITEL 5. GEGENMAßNAHMEN zu nehmen. Wenig bekannt ist die Möglichkeit, beliebige Programme in der initrd zu installieren, oder ganz auf ein Wurzeldateisystem zu verzichten. Darüber hinaus ergibt sich aus historischen Gründen [8] die Möglichkeit, die Netzwerkschnittstelle des Systems vor abgeschlossenem Systemstart zu starten. Diese beiden Funktionen können genutzt werden, um einen Secure-Shell Server in der initrd zu installieren und diesen vor dem Systemstart vom verschlüsselten Datenträger vom Internet aus zugänglich zu machen. Der Schlüssel für den Systemdatenträger kann so verschlüsselt zum Zielsystem übertragen werden. Das löst das in 5.0.9 beschriebene Bootschlüssel-Problem und eliminiert den Knoten 1.1.1 Netzwerkmitschnitt aus dem Attack Tree. Es bleibt das Risiko der Modifikation der initrd, da diese unverschlüsselt vorliegen muss. Dort einen Keylogger zu installieren kompromittiert die Sicherheit des nach FDE verschlüsselten Servers. Aus diesen Überlegungen ergibt sich der neue Attack Tree in Abbildung 5.2. Abbildung 5.2: Schritt 3: Verschlüsselter Zugang zur Pre-Boot Umgebung 1. Datenträger auslesen 1.1 Bootschlüssel abhören 1.1.1 Keylogger in Pre-Boot Umgebung 1.2 Lokale Anmeldung 1.3 DMA Zugriff 5.0.11 Scout Wie in 5.0.10 hergeleitet, erzielt Verschlüsselung nur genau dann Vertraulichkeit auf einem gemieteten Server, wenn der Schlüssel der in die unverschlüsselte Pre-Boot Umgebung übertragen werden muss, nicht abgehört werden kann. Da die initrd nicht verschlüsselt werden kann, sind Zusicherungen hinsichtlich Integrität oder Vertraulichkeit nicht haltbar. Diese

19 sind aber für die geforderte Funktion der sicheren Eingabe des Schlüssels für den Systemdatenträger nicht notwendig. Es muss nur erkannt werden können, ob eine Kompromittierung stattgefunden hat. Diese Funktionalität ist mir Prüfsummenvergleichen realisierbar und kann den Angriff auf den Bootschlüssel stark verzögern. Diese Prüfsummenvergleiche bietet das Skript scout, durch dass der Startvorgang wie in Abbildung 5.3 angepasst wird. BIOS BIOS POST POST Phase Phase 1 1 & & Phase Phase 2 2 Bootloader Bootloader (GRUB) (GRUB) Kernel Kernel Laden Laden & & Starten Starten Initrd Initrd einbinden einbinden Netzwerk Netzwerk hochfahren SSH-Server starten starten Prüfsummen der der Initrd Initrd erstellen erstellen Schlüssel Schlüssel für für Cryptsetup senden senden Bootvorgang fortsetzen fortsetzen Init-Prozess Init-Prozess starten starten Systemstart Systemstart beendet beendet Abbildung 5.3: Angepasster Startvorgang mit Pre-Boot Wartezeit Das Skript leistet die Einwahl in die Pre-Boot Umgebung, erstellt Prüfsummen des Inhalts und vergleicht die Prüfsummen mit einer lokal gespeicherten Datenbank vorheriger Prüfsummen. Das Ergebnis des Vergleichs wird dem Benutzer angezeigt, sodass dieser entscheiden kann, ob die Eingabe des Schlüssels sicher ist. Durch Einsatz von scout kann der Knoten 1.1.1 Keylogger in Pre-Boot Umgebung aus Schritt 3 (Absatz 5.0.10) und damit der darüberliegende Knoten nicht ausgeschlossen werden, da die Installation weiterhin möglich ist. Da die Erkennung der Installation durch Prüfsummenvergleich und Erkennung des Neustarts des Systems möglich ist, wird der Knotem im Attack Tree annotiert weitergeführt (siehe Abbildung 5.4). Er ist bei Anwendung von scout solange wirkungslos, wie das Prüfsummenverfahren nicht direkt angegriffen wird. Dabei implementiert scout eine Defense in depth Maßnahme nach 3.0.6. 5.0.12 Deceivers Getty Unter Linux und Unix ist die primäre Interaktionsmöglichkeit mit dem System vor Ort das Terminalverwaltungsprogramm getty. Ein getty präsentiert dem Benutzer einen Anmelde-

20 KAPITEL 5. GEGENMAßNAHMEN bildschirm, an dem Konto und Kennwort eingegeben werden können und als Resultat bei erfolgreicher Anmeldung ein lokales Terminal gestartet wird../dgetty.py 38400 tty2 Ubuntu 13.04 hydra tty2 hydra Login: root Password: Login failure. Zur Unterstützung des Terminalverwaltungsprogramms werden mehrere Textdateien mit Systeminformationen zur Verfügung gestellt. Namentlich /etc/issue, /etc/hostname und /etc/motd. Die Datei issue enthält ein Banner, dass über dem Anmeldebildschirm angezeigt wird. Die Datei hostname, den nicht qualifizierten Hostnamen des Servers und die Datei motd eine kurze Nachricht des Systemverwalts an die Benutzer, die nach der Anmeldung angezeigt wird. Um der Gefahr durch lokale Interaktion des Vermieters mit dem Server zu begegnen eignet sich ein Honeypot, da das Abschalten der lokalen Interaktionsmöglichkeiten verdächtig wirkt. Honeypots sind Systeme, die den Angreifer ablenken sollen. Um die Verteidigung gegen lokale Interaktion zu implementieren, wurde ein Low-Interaction Console Honeypot entwickelt. Das Werkzeug mit dem Namen Deceivery Getty implementiert alle Funktionen, die ein getty auszeichnen und ist durch Auslesen der relevanten Systemdateien nicht von einem normalen getty zu unterscheiden. Nach mehrfacher Falscheingabe von Anmeldedaten wird ein erfolgreicher Login simuliert. Parallel dazu wird der Status der Anmeldung und eingegebener Befehle an externe Skripte weitergereicht. So wird eine angemesse Reaktion auf lokale Interaktion ermöglicht. Sinnvolle Reaktionen sind unter anderem die folgenden. Löschen des Verschlüsselungsheaders und damit Herstellung von Nicht-Unterscheidbarkeit der verschlüsselten Partitionen zu zufällig beschriebenen Partitionen mittels LUKS Emergency Self-Destruction [10] Abschalten des Servers und damit Aktivierung der Verschlüsselung Benachrichtung des Mieters hinsichtlich Aktivität an der lokalen Konsole Durch die vorhergehenden Betrachtungen kann der Knoten 1.2 Lokale Anmeldung und der dazugehörige Angriffsvektor eliminiert werden. Die lokale Interaktion mit dem Server

21 Abbildung 5.4: Schritt 4: Übrige Angriffsvektoren kann solange nicht als Angriffsvektor eingesetzt werden, wie keine Schwachstellen in dgetty gefunden wird.

22 KAPITEL 5. GEGENMAßNAHMEN

Kapitel 6 Implementierung Das Verfahren der Voll-Verschlüsselung von Linux-Servern im gemieteten Umfeld ist erprobt und mit vielen Anbietern und Vermietern kompatibel. Folgend werden die entscheidenden Schritte exemplarisch vorgestellt. Dabei wird davon ausgegangen, dass der Server bereits ins Rettungssystem gestartet wurde. Es wird die auf Servern weitverbreitete Distribution Debian manuell installiert. Das vorgestellte Verfahren ist auf alle Linux-Distributionen direkt übertragbar, die das Debian-Paketformat einsetzen. Andere Distributionen die auf dem RedHat-Paketformat basieren oder ein weiteres Paketformat einsetzen, erfordern weitere manuelle Arbeitsschritte. 6.0.13 Rettungssystem prüfen Wie in den vorherigen Abschnitten erwähnt, unterliegt das Rettungssystem, dass hier als Installationssystem eingesetzt wird, der Kontrolle des Vermieters. Diese Kontrolle kann eingeschränkt, aber nicht verhindert werden. Um diese Einschränkung zu erreichen, sind die folgenden Maßnahmen durchzuführen. Abschalten der lokalen gettys durch Auskommentieren in der Datei /etc/inittab. Skripte des Vermieters stoppen, löschen oder durch setzen der entsprechenden Berechtigung nicht-ausführbar markieren. Datenvermeidung betreiben und keine oder möglichst wenige Daten im Rettungssystem hinterlassen. Firewall mittels iptables einrichten um den Zugriff auf den Server im Rettungssystem nur mit der zur Installation verwendeten IP-Adresse zuzulassen. 23

24 KAPITEL 6. IMPLEMENTIERUNG 6.0.14 Installationsvorbereitung Im Rahmen der Vorbereitung der Installation müssen zuerst die zum späteren Zugriff notwendigen Netzwerkdaten mit geeigneten Werkzeugen wie ifconfig für die lokale Netzwerkadresse und route für den Router ausgelesen werden. Die Nameserver des Vermieters können aus der Datei /etc/resolv.conf ermittelt werden. Diese Daten müssen gesichert werden. Es muss ein Partitionsschema für die lokalen Datenträger eingerichtet werden. Die folgende Tabelle zeigt exemplarisch eine Partitionstabelle im Master Boot Record, die sich für die folgenden Einrichtungsschritte eignet. Tabelle 6.1: Partitionstabelle für Voll-Verschlüsselung Blockgeraet Groessee Zielverzeichnis Partitionstyp Bootfaehigkeit /dev/sda1 1 GiB /boot 83 Ja /dev/sda2 512 MiB swap 83 Nein /dev/sda3 Rest / 83 Nein Die Partionen werden formatiert und gemeinsam im lokalen Rettungssystem des Servers eingebunden. Dabei ist zu beachten, dass die Partition, die das Wurzelverzeichnis aufnehmen soll mittels dm-crypt mit LUKS-Header verschlüsselt wird. Folgend die notwendigen Befehle exemplarisch für die vorgestellte Partitionstabelle. mkfs.ext4 /dev/sda1 cryptsetup luksformat /dev/sda3 cryptsetup luksopen /dev/sda3 sda3_crypt mkfs.ext4 /dev/mapper/sda3_crypt mount /dev/mapper/sda3_crypt /mnt/ mkdir /mnt/boot mount /dev/sda1 /mnt/boot 6.0.15 Installation durchführen Auf dem wie vorhergehend beschrieben vorbereiteten Datenträger kann folgend das Betriebssystem installiert werden. Dabei muss sichergestellt werden, dass keine unnötigen Spuren hinterlassen werden. Um dieses Ziel zu erreichen, wird ein kleiner Teil des Arbeitsspeichers als lokales Dateisystem eingebunden. Aus diesem Teil heraus wird Debian mit dem Installationswerkzeug debootstrap installiert. mount t tmpfs none /tmp cd /tmp

25 wget http://ftp.de.debian.org/debian/pool/main/d/ debootstrap/debootstrap_1.0.55_all.deb Durch die Zweckentfremdung des Installationswerkzeugs zum Einsatz in einem Rettungssystem sind Anpassungen an diesem notwendig. Außerdem muss die Integrität des Pakets geprüft werden. Da in einem Rettungssystem die Werkzeuge zur Prüfung oder Installation von Debian-Paketen nicht vorhanden sein müssen, geschieht diese Prüfung sowie die notwendige Anpassung, manuell. Zuerst wird das Paket entpackt. ar xf debootstrap_1.0.55_all.deb tar xjf data.tar.xz tar xzf control.tar.gz Darauffolgend wird die Integrität der Dateien im Paket durch Erzeugung der Dateiprüfsummen und Vergleich mit den dem Paket beiliegenden Prüfsummen verifiziert. Der folgende Befehl vergleich die Prüfsummen paarweise und zeigt die Unterschiede. cat md5sums cut d " " f 3 xargs md5sum $1 > md5sums.local; diff md5sums md5sums.local Um die Installation mittels debootstrap durchführen zu können, muss der Pfad der Installationsvorlagen, die debootstrap beiliegen im Skript angepasst werden. Ausgehend vom beschriebenen Verfahren muss der Quelltext an nur eine Stelle wie folgt angepasst werden. # Originalzustand DEBOOTSTRAP_DIR=/usr/share/debootstrap # Zielzustand DEBOOTSTRAP_DIR=/tmp/usr/share/debootstrap Nach Anpassung und Prüfung der Integrität des Installationsprogramms muss der öffentliche Schlüssel importiert werden, der zur Signierung der installierten Pakete aus den Paketquellen verwendet wurde. Dies dient dem Zweck, nur offizielle Pakete zu installieren. Im Falle von Debian wird ein PGP-Schlüssel verwendet. wget no check certificate https://ftp master.debian.org/keys/archive key 7.0.asc gpg import archive key 7.0.asc Folgend kann das Betriebssystem leicht mit Hilfe einer der von debootstrap mitgelieferten Installationsvorlagen installiert werden. usr/sbin/debootstrap keyring=/root/.gnupg/pubring.gpg arch amd64 wheezy /mnt/ http://ftp2.de.debian.org/debian Nach erfolgreicher Installation müssen die verschlüsselten Partitionen in der Datei /etc/- crypttab dem installierten System bekannt gemacht werden. Die Datei wird zum Zeitpunkt des Systemstarts gelesen. Um das vorgestellte Partitionsschema zu implementieren, wird die Partition für das Wurzeldateisystem sowie die Auslagerungspartition hinzugefügt. Die weitere Einrichtung entspricht dem Standardvorgehen zur manuellen Installation eines Linux-Systems.

26 KAPITEL 6. IMPLEMENTIERUNG Tabelle 6.2: Inhalt der Datei /etc/crypttab Ziel Quell-Blockgerät Schlüsseldatei Optionen sda2_crypt /dev/sda2 /dev/urandom cipher=aes-cbc-essiv:sha256,size=256,swap sda3_crypt /dev/sda3 none luks 6.0.16 Betriebssystem anpassen Nach der Installation sind Anpassungen am installierten System notwendig, um die Wehrfähigkeit wie gefordert herzustellen. Dabei sind zwei Schritte auszuführen. Zuerst muss die initiale Bootumgebung so eingerichtet werden, dass ein verschlüsseltes Login mittels Secure-Shell möglich ist. Als zweiter Schritt, muss das alternative getty aus 5.0.12 installiert werden. Pre-Boot Umgebung Um die verschlüsselte Einwahl in die Pre-Boot Umgebung zu ermöglichen, muss in as initrd Dateisystem, dass die zum Systemstart notwendigen Programme und Treiber enthält, ein Secure-Shell Server eingebettet werden. Außerdem muss die Netzwerkschnittstelle konfiguriert werden. Dies geschieht in einem Debian-System durch Anpassung der Datei /etc/initramfs-tools/initramfs.conf. DEVICE=eth0 IP=EIGENE_IP4::ROUTER_IP4:255.255.255.0:HOSTNAME:eth0:off DROPBEAR=y Die verschlüsselte Einwahl soll mit dem Schlüssel des Administrators erfolgen. Der zugehörige öffentliche Schlüssel muss dafür in der Datei /etc/initramfs-tools/root/.authorized_keys hinterlegt werden. dgetty Das Werkzeug dgetty wird durch Ersatz der herkömmlichen gettys in der Datei /etc/inittab installiert. Dabei werden die Einträge wie folgt ersetzt. 1:2345:respawn:/sbin/rungetty tty1 unobody /usr/local/dgetty/dgetty.py 38400 tty1 6.0.17 Systemstart Nach Installation und Anpassung des Betriebssystems kann der Erststart durchgeführt werden. Nachdem der Linux-Kernel die Pre-Boot Umgebung hergestellt hat, wartet das

27 System auf die Verbindung durch das Prüfwerkzeug scout aus 5.0.11, dargestellt in Abbildung 6.1. Abbildung 6.1: System in Pre-Boot Umgebung gestartet, Konsolensicht Durch Aufruf von scout wird die beschriebene Funktionalität der Integritätsprüfung durchgeführt und dem Benutzer vor Eingabe des Schlüssels als Zusammenfassung dargestellt. Abbildung 6.2: Einwahl in Pre-Boot Umgebung, Benutzersicht

28 KAPITEL 6. IMPLEMENTIERUNG

Kapitel 7 Zusammenfassung & Ausblick Es wurde die Problematik durch die Delegation der physikalischen Kontrolle an einen Vermieter vorgestellt. Aufbauend auf der Betrachtung von Dienstleistungen auf verschiedenen Schichten eines Computersystems wurde die Anti-Forensik, Attack Trees und einfache Militärtaktik eingeführt, um die Entwicklung von Gegenmaßnahmen zu unterstützen. Diese Gegenmaßnahmen wurden exemplarisch für gemietete Linux-Server entwickelt und implementiert. Im Rahmen der Studienarbeit konnten einige fortgeschrittene Aspekte der physikalischen Kontrolle sowie einige Angriffsvektoren nicht berücksichtigt werden. Diese werden folgend genannt und können als Ausgangspunkt für weitere Betrachtungen dienen. Cold Boot Angriffe, bei denen der geheime Schlüssel für einen Datenträger durch starke Kühlung des Arbeitsspeichers über Neustarts hinaus lesbar bleiben kann. Hier kann mit Speicherung des Schlüssels in CPU-Registern gearbeitet werden. Kernel Canaries, die auch den unverschlüsselt gestarteten Linux-Kernel selbst vor Modifikation schützen. Dazu kann ein vertrauenswürdiges Kernel-Modul eingesetzt werden. Safe Boot, dass durch eine durchgängige Zertifikatenkette das Vertrauen in die gestartete Pre-Boot Umgebung erhöht. 29

30 KAPITEL 7. ZUSAMMENFASSUNG & AUSBLICK

Literaturverzeichnis [1] Almesberger, Werner: Booting linux: The history and the future. In: Proceedings of the Ottawa Linux Symposium, 2000. [2] Biskup, Joachim: Security in Computing Systems: Challenges, Approaches and Solutions. Springer, 2008. [3] Fruhwirth, Clemens: New methods in hard disk encryption, 2005. [4] Fruhwirth, Clemens: LUKS On-Disk Format Specification Version 1.1.1. http://cryptsetup.googlecode.com/svn-history/r42/wiki/luks-standard/ on-disk-format.pdf, Dezember 2008. [5] Garfinkel, Simson: Anti-forensics: Techniques, detection and countermeasures. In: The 2nd International Conference on i-warfare and Security (ICIW), Seiten 77 84, 2007. [6] Informationstechnik, Bundesamt für Sicherheit in der: Leitfaden IT-Forensik. https://www.bsi.bund.de/shareddocs/downloads/de/bsi/ Internetsicherheit/Leitfaden_IT-Forensik_pdf.pdf, 2010. [7] Jones, M. Tim: Linux initial RAM disk (initrd) overview. https://www.ibm.com/ developerworks/library/l-initrd/l-initrd-pdf.pdf, Juli 2006. [8] Kuhlmann, Gero: Mounting the root filesystem via NFS (nfsroot). https://www. kernel.org/doc/documentation/filesystems/nfs/nfsroot.txt, 1996. [9] Martin, Antonio: Firewire memory dump of a Windows XP computer: a forensic approach. Black Hat DC, Seiten 1 13, 2007. [10] MUTS: Emergency Self Destruction of LUKS in Kali. http://www.kali.org/ how-to/emergency-self-destruction-luks-kali/, Januar 2014. [11] Packschies, Lars: Praktische Kryptographie unter Linux, Kapitel 11.5. Open source press München, 2005. [12] Schneier, Bruce: Attack trees. Dr. Dobbs journal, 24(12):21 29, 1999. 31

32 LITERATURVERZEICHNIS

Anhang A Anhang A.1 dgetty Das Skript dgetty.py wird auf dem zu schützenden System installiert. Es hängt von den importierten Bibliotheken und Standard-Systemdateien ab. Zur Ausführung wird das Hilfsprogramm rungetty ( https://packages.debian.org/de/source/sid/rungetty ) benötigt. dgetty.py #!/usr/bin/python # After how many tries should we act as if it was too much? confmaxtries=5 # How many seconds to wait after each wrong login attempt? conftimeoutsleep=5 # After how many seconds do we act, as if the login was right? confsuccesstries=2 # Which script to run on keyboard interaction? confscript="./dgetty interact.bash" import sys import time import getpass import os import traceback # Get some arguments in if len(sys.argv) < 3: sys.stdout.write("usage:./dgetty.py baudrate ttyno\n") sys.stdout.write("example:./dgetty.py 38400 tty2\n") exit(1) # Get data for common character sequences in /etc/issue baudrate=sys.argv[1] tty=sys.argv[2] hostname=open("/etc/hostname","r").readline().rstrip() 33

34 ANHANG A. ANHANG # Open our login screen template issue = open("/etc/issue","r").readlines() # Lets get the motd should intruder persist motd = open("/etc/motd","r").readlines() # Login and pass are globals global loginconsole global passwordconsole def printissue(): # Replace important variables from /etc/issue for line in issue: line=line.replace("\\n",hostname) line=line.replace("\\l",tty) line=line.rstrip() sys.stdout.write(line+"\n") # Print the Login prompt and read the entered Login/Password def printlogin(): global loginconsole,passwordconsole sys.stdout.write(hostname+" Login: ") loginconsole=sys.stdin.readline().rstrip() passwordconsole=getpass.getpass() runscript("loginattempt","login: "+loginconsole+", Pass:"+passwordConsole) # Notify script def runscript(event,input): os.system(confscript+" "+event+" "+input+" > /dev/null 2>&1") # Print login prompt until the password is right def simulateauthentication(): printissue() for tried in (1,confSuccessTries): printlogin() if tried % confmaxtries == 0: sys.stdout.write("maximum number of tries exceeded ("+str(confmaxtries)+")\n") time.sleep(conftimeoutsleep) if tried!= confsuccesstries: time.sleep(conftimeoutsleep) sys.stdout.write("\nlogin failure.\n") else: break for line in motd: sys.stdout.write(line) def mainloop(): try: simulateauthentication() while True: sys.stdout.write(loginconsole+"@"+hostname+ :~# ) input=sys.stdin.readline().rstrip() runscript("shellinput","\""+input+"\"") # Attack can exit the shell if input == "exit": simulateauthentication() except SystemExit as e:

A.2. SCOUT 35 sys.exit(e) except KeyboardInterrupt: sys.exit(1) except Exception: sys.exit(1) mainloop() A.2 scout Das Skript scout.bash hängt von den folgenden Programmen ab, die zwingend erforderlich sind. hashdeep kompiliert für die Zielarchitektur ( http://md5deep.sourceforge.net/ ) fping zur Feststellung der Server-Verfügbarkeit ( http://fping.sourceforge.net/ ) Das Skript legt das Verzeichnis /.scout im Heimverzeichnis des ausführenden Benutzers an. In diesem Verzeichnis wird sowohl die aktuelle Vergleichsliste der Prüfsummen, wie auch die vorherige abgelegt. scout.bash #!/bin/bash if [ z $1 ]; then echo "To unlock with default id_rsa key:" echo " $0 hostname/ip" echo "To unlock with custom path to id_rsa key:" echo " $0 hostname/ip /path/to/dropbear/id_rsa" exit 1 fi if [ z ${2} ]; then IDRSA=~/.ssh/id_rsa fi HOST="$1" if [! d ~/.scout ]; then fi mkdir p ~/.scout while [ true ]; do # Server online? fping q T5 $HOST > /dev/null 2>&1 if [ "$?" eq "0" ]; then # Is it a dropbear from initrd? DROPBEAR= nc w 1 $HOST 22 grep o "[[:print:]] dropbear[[:print:]] " wc l if [ "${DROPBEAR}" ne "1" ]; then echo e "\033[1mWaiting for pre boot environment...\033[0m"

36 ANHANG A. ANHANG sleep 10 continue fi echo e "\033[1mPreparing pre boot integrity check...\033[0m" if! [ x ~/.scout/hashdeep ]; then echo "hashdeep binary not found in ~/.scout/hashdeep." exit 1 fi cat ~/.scout/hashdeep ssh i ${IDRSA} ouserknownhostsfile=~/.ssh/initrd_known_hosts \\ "root@"${host} cat ">" /root/hashdeep ssh qi ${IDRSA} ouserknownhostsfile=~/.ssh/initrd_known_hosts \\ "root@"${host} "chmod 500 /root/hashdeep" if [ e ~/.scout/${host}_initrd_hashlist ]; then mv ~/.scout/${host}_initrd_hashlist ~/.scout/${host}_initrd_hashlist.1 fi echo e "\033[1mVerifying pre boot environment...\033[0m" ssh qi ${IDRSA} t ouserknownhostsfile=~/.ssh/initrd_known_hosts \\ "root@"${host} "/root/hashdeep r c sha256 /bin /conf /etc /init /root \\ /sbin /scripts /lib/lib /lib/klibc /lib/modules/ /tmp /usr" \\ sed e /^#/d e /^%/d sort > ~/.scout/${host}_initrd_hashlist ssh qi ${IDRSA} ouserknownhostsfile=~/.ssh/initrd_known_hosts \\ "root@"${host} "rm f /root/hashdeep" if [ e ~/.scout/${host}_initrd_hashlist.1 ]; then CHANGES= comm 13 ~/.scout/${host}_initrd_hashlist \\ ~/.scout/${host}_initrd_hashlist.1 cut d "," f 3 wc l if [ "${CHANGES}" ne "0" ]; then echo e \E[37;31m "\033[1mWARNING\033[0m Changes from last boot \\ checksum detected:" comm 13 initrd_hashlist initrd_hashlist.old cut d "," f 3 echo e "\ndo you want to continue anyway (y/n)?: " read cont if! [ "${cont}t"="yt" ]; then exit 1 fi fi echo e \E[37;30m "\033[1mChecksums Match\033[0m" else echo "No checksums found to compare to." fi ssh qi ${IDRSA} t ouserknownhostsfile=~/.ssh/initrd_known_hosts \\ "root@"${host} echo n hostname " unlock Password: ";read s PASSWORD; \\ echo n "${PASSWORD}" > /lib/cryptsetup/passfifo echo e "\n" # did it work (no longer a dropbear) or not? sleep 5 DROPBEAR= nc w 1 $HOST 22 \\ grep o "[[:print:]] dropbear[[:print:]] " wc l if [ "${DROPBEAR}" ne "1" ]; then echo e \E[37;30m "\033[1mPre boot environment exited. Unlock ok!\033[0m" exit 1 else echo e \E[37;31m "\033[1mWARNING\033[0m Pre boot \\ environment didn t exit. Wrong password?" continue

ERKLÄRUNG 37 done else fi fi echo "Host offline. Waiting..." sleep 5

38

ERKLÄRUNG 39 Hiermit versichere ich, dass ich die vorliegende Arbeit selbstständig verfasst habe und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet sowie Zitate kenntlich gemacht habe. Dortmund, den 18. März 2014 Falk Husemann