Verlässliche Verteilte Systeme 1. Prof. Dr. Felix Gärtner. Teil 18: Integritätsmanagement

Transkript

1 Verlässliche Verteilte Systeme 1 Angewandte IT Robustheit und IT Sicherheit Vorlesung im Wintersemester 2004/2005 Prof. Dr. Felix Gärtner Teil 18: Integritätsmanagement Lehr und Forschungsgebiet Informatik 4, RWTH Aachen,

2 Ankündigungen

3 Motivation und Übersicht Integrität = Schutz vor unbefugter Modifikation Integrität von Computersystemen wurde lange Zeit nicht als wichtig angesehen wichtig war die Vertraulichkeit (Sichtweise stammt offenbar aus Militärkreisen) In der heutigen Praxis ist Integrität oft wichtiger als Vertraulichkeit Banken können beispielsweise heute eher damit leben, dass Kontenstände veröffentlicht werden als dass Kontenstände unbefugt manipuliert werden Aber: Integrität zu gewährleisten ist schwer! Heute: Wie schaffe ich Vertrauen in die Integrität eines Computersystems? Warum kann man seinem Auge nicht trauen? Wie kann man sich trotzdem sicher sein?

4 ACM Turing Award Lecture 1983 Ken Thompson (mit Bart) und Dennis Ritchie "erfanden" Anfang der 1970er das Unix Betriebssystem Entwickelt auf einem der ersten "Minicomputer", dem PDP 7 später portiert auf den PDP 11 (siehe Bild) Thompson und Ritchie erhielten 1983 den Turing Award Thompson hielt eine für viele überraschende Dankesrede Abgedruckt in Communications of the ACM, 27 (8), 1984, pp , siehe auch:

5 Was tut dieses Programm?

6 Selbstreproduzierende Programme Selbstreproduzierendes Programm = ein Programm, was sich selbst ausgibt Wenn man das Programm von Thompson übersetzt und ausführt, gibt es ein selbstreproduzierendes Programm aus Zwei wichtige Beobachtungen: So ein Programm kann einfach von einem zweiten Programm generiert werden So ein Programm kann beliebig viel Ballast enthalten (Material, was einfach reproduziert wird, ohne zum Reproduktionsmechanismus zu gehören)

7 Besonderheiten von C In C kann man Zeichenketten symbolisch initialisieren Nicht druckbare Sonderzeichen werden mit dem Escape Zeichen kodiert Beispiel: "Hello World\n" \n codiert das Newline Zeichen Codebeispiel: idealisierter Code aus dem C Compiler, der die Zeichen einliest Wichtig: das Wissen um \n ist in "portabler" Weise kodiert Neuübersetzung schreibt das Wissen fort

8 Wie kommt \n dort hinein? Angenommen, wir wollen \v als neues Sonderzeichen dem Compiler beibringen dann würden wir schreiben: Aber: die Binärversion des Compilers kennt \v noch nicht Code ist illegal! Wir müssen \v dem Compiler erst noch beibringen

9 Trainieren des Compilers Wir schreiben das Programm um in: Jetzt akzeptiert der alte Compiler das Programm Wir installieren das übersetzte Programm als neuen Compiler Jetzt wird auch die "portable" Version übersetzt Compiler hat \v "gelernt"

10 Ein erster Trojaner Links: hypothetische Zeile aus einem C Compiler übersetzt die nächste Zeile der Eingabe Rechts: modifizierter Compiler schaut sich Eingabezeile erst an falls die Eingabezeile einem Muster genügt, wird etwas anderes übersetzt als die Eingabezeile Falls das unabsichtlich war: bug, falls nicht: Trojanisches Pferd Muster könnte das Unix Login Programm gezielt verändern Hintertür (z.b. well known password wie "Hasta la Vista") einbauen

11 Verwischen der Spuren Eine solche Veränderung würde man schnell merken vor allem wenn viele Leute den Quelltext lesen Aber mit einem einfachen Trick kann man das verbergen: Einbau eines zweiten Trojaners: diesmal mit dem Ziel C Compiler Trojaner ist ein selbstreproduzierendes Programm, das beide Trojaner in den C Compiler einbaut Programm muss trainiert werden

12 Der Trojaner verschwindet Ergebnis: der Trojaner ist immer wieder da, aber aus dem Quellcode verschwunden!

13 Die Moral Man kann keiner Software trauen, die man nicht 100% selbst geschrieben hat 100% selbst geschrieben bedeutet: bis hinunter zum Assemblercode theoretisch müsste man selbst den Compiler erstmal in Assembler schreiben, um ihm zu vertrauen aber der Assembler oder Loader könnte auch bereits von Trojanern durchsetzt sein! Man muss den Quellen der eigenen Software vertrauen sowohl dem Quellcode als auch den Bezugsquellen Integritätsmanagement basiert auf der Basis eines vertrauenswürdigen Systems Frage: angenommen das System ist integer, wie kann man gewährleisten, dass es auch so bleibt? Problem: root kann alles!

14 Immutable and Append only Files In BSD 4.4 Unix gibt es unveränderliche (immutable) und Dateien, an die man nur etwas anhängen kann (appendonly) Kandidaten für immutable files: System Konfigurationsdateien wie /etc/inetd.conf Kandidaten für append only files: typischerweise Log Dateien Superuser kann jede Datei als append only oder immutable deklarieren in BSD mit chflags in Lunix mit chattr im ext2fs Dateisystem

15 Test unter Linux mit ext3 explorer:/tmp/vvs # ll total 20 drwxr-xr-x 2 root root 4096 Jan 25 01:27. drwxrwxrwt 453 root root Jan 25 01:27.. explorer:/tmp/vvs # cat > immutable Hallo explorer:/tmp/vvs # chattr usage: chattr [-RV] [-+=AacDdijsSu] [-v version] files... explorer:/tmp/vvs # chattr +i immutable explorer:/tmp/vvs # ll total 24 drwxr-xr-x 2 root root 4096 Jan 25 01:27. drwxrwxrwt 453 root root Jan 25 01:27.. -rw-r--r-- 1 root root 6 Jan 25 01:27 immutable explorer:/tmp/vvs # cat >> immutable -bash: immutable: Permission denied explorer:/tmp/vvs # lsattr immutable ----i immutable explorer:/tmp/vvs #

16 Kernel Security Level Superuser kann natürlich die Rechte von immutable und append only files wieder zurücksetzen Abhilfe: kernel security levels Root kann security level nur erhöhen nur init kann den level erniedrigen, erfordert also Neustart BSD Kernel Security Levels: 1 : permanently unsecure normal Unix behavior 0 : unsecure mode immutable and append only flags can be changed 1 : secure mode immutable and append only flags cannot be changed mounted filesystems, /dev/mem and /dev/kmem are read only 2 : highly secure mode wie secure mode, plus all disk devices are read only (prevents raw bit manipulations of unmounted filesystems)

17 Diskussion Im (highly) secure mode kann man selbst mit root Rechten keine immutable files mehr verändern Wenn man init und seine Konfigurationsdateien als immutable deklariert, kann ein Angreifer noch nicht einmal das System in einem niedrigeren security level neu starten Schreibschutz auf /dev/mem und /dev/kmem schützt vor "onthe fly patching" des Kernels Einzige Möglichkeit für den Angreifer: System im single user mode starten benötigt physischen Zugang zur Maschine In Linux ab gibt es zwar immutable und appendonly files, aber keine kernel security levels

18 Read only Dateisysteme Hardware Schreibschutz ist eine weitere Möglichkeit, um vor Veränderungen zu schützen viele externe Laufwerke haben neuerdings wieder einen entsprechenden Schalter alternativ: Daten auf CD oder DVD Dateisystemen mounten Vorsicht: mounten im read only Modus schützt nicht vor Veränderungen man kann über die Device Datei direkt auf die Platte schreiben (unter umgehung des Software Schreibschutzes) read only Option bei mount ist hauptsächlich für das mounten von sowieso schreibgeschützten Medien da vermeidet massenhafte Fehlermeldungen Idee: Dateisystem so strukturieren, dass man die wichtigen Systemverzeichnisse auf einer CD mountet verhindet Effekte von "mal schnell was installieren" benötigt aber oft Herstellerunterstützung

19 Diskussion Vorteile von read only Dateisystemen: Backups werden einfacher man kann eine Standard System CD brennen und verteilen erleichtert Administration keine Quotas auf diesen Dateisystemen keine Notwendigkeit, den Datenträger zu defragmentieren oder sonstwie zu checken Nachteile: funktioniert nicht für Benutzerdaten (oder Daten, die sich oft ändern) viele Laufwerke haben keinen Hardware Schreibschutz Systeme brauchen in der Regel zwei Laufwerke (zusätzliche Kosten) CDs und DVDs sind viel langsamer als Festplatten

20 Exkurs: Read Only Unix Es gibt zahlreiche Linux und BSD Distributionen, die von einer schreibgeschützten Floppy oder einer CD booten Beispiele: Router Software, Firewall Software etc. Flüchtige Daten werden in RAM Disk gehalten Angreifer kann zwar das System kompromittieren, kann aber keinen Schaden an der Firewall Software selbst vornehmen Distributionen sind zudem oft sehr klein, bieten wenig Angriffsfläche Mischformen möglich: CD basierte Distributionen mit Konfigurationsdateien auf einer schreibgeschützten Floppy Konfiguration kann in "sicheren" Momenten aktualisiert werden

21 Was bedeutet Integrität? Was kann man tun, wenn man die Kompromittierung des eigenen Rechners vermutet? 1. Platte des Rechners physisch entfernen und an einem "sauberen" Rechner mittels forensischer Werkzeuge untersuchen 2. Platte im Rechner belassen, aber von einer "sauberen" Version des Betriebssystems booten und mit "sauberen" Werkzeugen das Dateisystem analysieren 3. Platte im Rechner belassen, einloggen und mit den dort vorhandenen Integritätssicherungswerkzeugen arbeiten 4. Herausbekommen, wie der Angreifer reingekommen ist, Schwachstelle entfernen, weitermachen. Ansätze 3 und 4 sind in der Praxis am weitesten verbreitet, haben aber nichts mit Integritätssicherung zu tun

22 Entdecken von Veränderungen Frage: hat der Angreifer Veränderungen an Dateien vorgenommen und falls ja, welche? Drei Methoden: Vergleich mit unveränderten Originalkopien sicherste Methode, aber aufwändig umzusetzen Vergleich mit unveränderten Metadaten statt kompletten Dateien nur Metadaten (Name, Inhalt des Inode, etc.) weniger aufwändig, aber auch weniger verlässlich Datei kann sich verändern, obwohl Inode gleich bleibt Vergleich mit unveränderten kryptographische Checksummen der Daten starke Hashfunktionen benutzen! Gute Werkzeuge (Tripwire und BSDs mtree)

23 Tripwire Tripwire ist ein Integritätssicherungswerkzeug ursprünglich geschrieben von Gene Kim und Gene Spafford jetzt kommerziell vermarktet: Open Tripwire: Erlaubt flexible Definition welche Daten geprüft werden sollen kann manuell oder automatisch gestartet werden Benutzung: nach der Installation muss initial die Datenbank an MD5 Hashes aufgebaut werden (wenn das später geschieht, kann es schon zu spät sein) regelmäßig eine Prüfung der Dateien gegen die Datenbank veranlassen hoffen, dass es keine root Kompromittierung gab, bei der der Angreifer die Datenbank neu aufgebaut hat Wichtig: unveränderbares Logging!

24 Zusammenfassung und Ausblick Integritätsmanagement ist wichtig, um Vertrauen in das eigene System aufzubauen und zu erhalten Schützt vor unbeabsichtigten und beabsichtigten Veränderungen Wichtig: man braucht immer eine Version der Software, die über jeden Zweifel erhaben ist Nützlich: Integritätskontrolle reduzieren auf physische Sicherheit mittels BSD Konzepten wie den security levels oder mittels read only Dateisystemen Werkzeuge wie Tripwire helfen, wenn sie mit regelmäßiger Kontrolle und sicherem Logging verbunden sind