Populäre Filesysteme und ihre Sicherheitsprobleme

Transcription

Populäre Filesysteme und ihre
Sicherheitsprobleme
Dr. Johann Murauer
[email protected]
Inhalt
• Teil 1
– Aufbau Unix FS
– Aufbau NTFS
– Spezielle Features
• Teil 2
– Prinzipien der Sicherheit
• Teil 3
– Diskussion der Sicherheitsprobleme
– Schlussfolgerungen und Lösungsvorschläge
Sicherheitsprobleme bei Filesystemen
2
Unix
3
Unix FS - Aufbau
• Keine Norm, gleiches Prinzip
• Data Blocks: Vielfache eines Sektors,
– 512 Bytes 4 KB … 8 KB
– Größe der Inode - Liste wird beim Formatieren
festgelegt
4
Unix FS - Superblock
• Superblock (beschreibt das gesamte
Filesystem):
–
–
–
–
–
–
Größe des Filesystems
Anzahl und Liste der freien Blöcke
Nächste freie Block
Größe der Inode - Liste, Liste der freien Inodes
Nächster freier Inode
Modification Flags
5
Unix FS - Inode
• Inode
– Inode beschreibt genau ein File
– Owner des Files
– Type des Files (File, Directory, Link, Char/BlockDevice, pipe, socket)
– Zugriffsrechte (owner – group – world)
– Zeitangaben (last modified, last access)
– Anzahl der Hard-Links
– Filegröße
– Datenblöcke
6
7
Unix FS - Inode
• Inode – Beispiel (Inode: 64 - 128 Bytes)
– Data logischer Block auf Disk à 4 KByte
– 128 GByte Platte 32*1024*1024 Blöcke 25 Bit zur Darstellung der Blocknummer
– 12 direkte Blöcke 48 KByte Filegöße
– Ind 1 4 KByte 1024 Einträge à 32 Bit
• 1024 * 4 KByte == 4 MByte Filegöße
– Ind 2 1024 * 1024 * 4 KByte == 4 GByte
8
Unix FS - Directory
• Directories sind ganz normale Files!
• Wo ist der Filename?
• Wie wird ein File gefunden?
9
10
Unix FS - Links
• Hardlink
– Nur innerhalb gleichem Filesystem
– ln file_name link_name
• Softlink / Symbolic Links
– Eigentliches File auf beliebigen Filesystem
– ln -s file_name link_name
11
Das Unix Filesystem
12
Das Unix Filesystem
13
Eigenheiten
• Anzahl der Inodes ist fix
• In Unix häufig viele kleine Dateien ~ 4 KB
• Inodes-Listen sind die klassische Variante.
Andere wie JFS (IBM – AIX), XFS (SGI)
verwenden B-Bäume zum Speichern von
Metadaten.
14
NTFS
15
NTFS von Win NT / 2000 / XP
• MBR (BIOS Parameter Block) $Mft
• $Mft an beliebige Position auf der Disk
• $Mft vergleichbar mit Inode-Liste in Unix
16
NTFS - $Mft
• „Normales“ Files, kann in der Größe verändert
werden
• Records von je 1 KByte
• Jedes File besitzt mindestens 1 Record in der $Mft
– Mehrere Records Defragmentiert, viele Attribute
– Auch $Mft hat einen Record in $Mft
– Achtung:
• Hardlink, zusätzlicher Name
• Softlink, zusätzliches File
17
NTFS - $Mft
• Falls ein File relativ klein ist, werden die
Nutzdaten in $Mft gespeichert
• Record 0 bis Record 15 reserviert für NTFS
• Ab Record 16: Beliebige Files und
Directories
• Analyse mit speziellen Tools
– Nfi.exe (Microsoft)
– NTFSInfo.exe (www.sysinternals.com)
18
NTFS - $Mft
19
NTFS - Prinzipien
•
•
•
•
Alles außer dem Bootsektor ist ein File
Ein File ist eine Menge von Attributen
Attribut ist ein Tupel (Typ:Name, Daten)
Es gibt eine Anzahl vordefinierter Attribute
– Data, File Name, Extended Attribute, ....
• Ein Directory ist eine File, das aus
speziellen Attributen besteht
20
NTFS - Prinzipien
• Attribute sind frei wählbar (Experiment)
C:\>echo Das-kommt-in-MeinStream > test.txt:MeinStream
C:\>dir test.txt
19.02.2002 11:23
0 test.txt
C:\>echo Das-kommt-in-DefaultStream >> test.txt
C:\>dir test.txt
19.02.2002 11:24
29 test.txt
C:\>more < test.txt
Das-kommt-in-DefaultStream
C:\>more < test.txt:MeinStream
Das-kommt-in-MeinStream
21
NTFS - Prinzipien
• Kommandos (type / more / dir ...) und greifen
vielfach nur auf fixe Attribute zu
• Betriebssystem-Aufrufe ermöglichen Zugriffe auf
„beliebige“ Attribute
– NFTS liest / schreibt nicht Files sondern AttributeWerte
• Einige Attribute immer im $Mft, andere können
ausgelagert werden.
• Daten/Dir-Blöcke immer als B-Baum organisiert
22
NTFS - wichtige Attribute
•
•
•
•
•
•
•
•
•
•
$VOLUME_INFORMATON
$STANDARD_INFORMATION
$FILE_NAME
$SECURITY_INFORMATION
$DATA
$ATTRIBUTE_LIST
$OBJECT_ID
$REPARSE_POINT
$EA, $EA_INFORMATION
$LOGGED_UTILITY_STREAM
23
NTFS - Directory
• Residente Attribute:
24
NTFS - Directory
• Nonresidente Attribute
25
NTFS - Link zu Datenblöcken
• VCN --- Blocknummer 0 bis n
• LCN --- Clusternummer auf der Disk
• Eine zusammenhängende Anzahl von
Clustern wird als „Run“ bezeichnet
– Viele (kurze) Runs oder viele Attribute mehr
als ein $Mft-Record pro File
26
NTFS - Link zu Datenblöcken
27
NTFS - Links
• Hardlink
– Ein Record in der $Mft mit mehreren $FILE_NAME
– Zähler: Attribut $STANDARD_INFORM.
– Win 32 API: CreateHardLink()
• Softlink
– Eigenes File mit Attribut $REPARSE_POINT
– Verweis auf ein anderes File (über $ObjectID)
– Tool: www.sysinternal.com (junction.exe)
28
Filesysteme und Betriebssystem
29
30
31
Spezielle Features einiger FS
•
•
•
•
•
Streams
Sparse Files
Journaling
Transaktionen
Verschlüsselung
32
Sicherheit
33
Grundprinzipien der Sicherheit
• Verfügbarkeit
– Zuverlässigkeit durch Redundanz
– Verhinderung von DoD
• Authentizität
– Kryptographische Verfahren (MAC, verschlüsselte
Hashwerte)
• Vertraulichkeit
– Zugriffsrechte bzw. kryptographische Verfahren
34
• Probleme bei der Vertraulichkeit mit
Rechten
– Umgehung des Schutzes möglich
• Anderes Betriebssystem, anderer Rechner
• Zusätzliches Betriebssystem
– Lösungen
• Zugangs zum Rechner verhindern
• Festplatte verschlüsseln
• Files verschlüsseln
35
• Zugang zum Rechner verhindern
– Organisatorisches Problem
• Festplatte verschlüsseln
– Keine Aufgabe des Filesystems sondern des
Disk-Treibers
– Alle Benutzer können (potenziell) alle Daten
lesen keine Benutzertrennung
36
• Fileverschlüsselung
– Benutzertrennung
– Aufgabe des Filesystems
Verwendung von symmetrischen Blockcipher
• DES, TripleDES, IDEA, AES, ...
• Verschiedene Modi mit unterschiedlichen Vor- und
Nachteilen
37
• Sicherheit auf einem hohen Niveau lässt
sich in Filesystemen nur mit
Verschlüsselung erreichen
38
Praktische Probleme
39
Sym. Kryptoverfahren (ECB)
40
Sym. Kryptoverfahren (CBC)
41
Sym. Kryptoverfahren (OFB)
42
Sym. Kryptoverfahren, Modi
• ECB
– Aus Sicherheitsgründen nur bei kleinen Files
brauchbar
• CBC
– Aus Performancegründen bei großen Files
unbrauchbar
• OFB
– Praktikabler Kompromiss
43
Verschlüsselung
• Wo wird der Schlüssel und andere
Verwaltungsinformation gespeichert
(Algorithmus, Schlüssel-ID, MAC, …)?
– Fileheader / Filetrailer
– Datenbank
– In den Metainformationen des Filesystems
(Inode, $Mft, ...)
44
Verschlüsselung - Stufenverfahren
• Daten mit Random-DEK, DEK mit KEK_1,
KEK_2, … verschlüsseln
• Vorteile:
• Mehrer Benutzer können zugreifen
• Schlüsselwechsel einfach möglich
• Probleme
– Wo speichert man DEK und KEKs ?
45
Filegröße bei Verschlüsselung
• Richtige Filegröße inkl. Header etc.
– Backup usw.
• Nutzdatengröße
– Für Applikationen
• Kommandos ls / dir
– Was zurückgeben ?
– Woher weiß man, ob ein File verschlüsselt ist
oder nicht ? (DB, Fileanalyse, Meta-Daten, …)
46
Files ohne passenden Schlüssel
• Access Denied
– Aber: Backup etc.
– Was tun mit Metadaten: Filegröße, Zeiten, Namen, …
• Verschlüsselte Daten
– Applikation können stürzen
– In Sonderfällen erwünscht: Verhalten
anwendungsbezogen steuern
• FTP, Mail, Backup, …
• Problem: verlässliche Identifikation der Anwendung
47
Wie wird ein File spezifiziert
• Zweck: Festlegen, ob ein File verschlüsselt
sein soll oder nicht
• Benutzersicht
– Namensraum des Anwenders muss sich
eindeutig auf den Namensraum des Filesystems
abbilden lassen
• Links
• Reparse Points
• Mount Points
48
Wie wird ein File identifiziert
• Filename
– Aber: unterschiedliche Namenräume
(Benutzersicht / Filesystemsicht)
• Bsp: U:\home-jmu\miracl\*.txt Key_1
• Laufwerksbuchstaben
• Netzwerkzugriffe
• ObjectID
• FileID
49
Einschub: Filenamen NTFS
1.
2.
3.
4.
\Device\LanmanRedirector\;U:000000000000afe7\fserv01\homejmu\miracl\first.txt
\Device\LanmanRedirector\;U:0\fserv01\home-jmu\miracl\first.txt
\Device\LanmanRedirector\;U:0\fserv01\home-jmu\miracl\first.txt::$DATA
\Device\LanmanRedirector\;Q:000000000000afe7\fserv01\homejmu\miracl\first.txt
5.
6.
\Device\LanmanRedirector\fserv01\home-jmu\miracl\first.txt
\Device\LanmanRedirector\;U:000000000000afe7\fserv01\homejmu\miracl\FIRST.TXT\:Docf_ PebiesnrMkudrfcoIaamtykdDa:$DATA
7.
8.
\Device\nwrdr\;U:000000000000afe7\fserv01\home-jmu\miracl\first.txt
\Device\NetwareRedirector\fserv01\home-jmu\miracl\first.txt
9.
{4c8cc155-6c1e-11d1-8e41-00c04fb9386d}:$DATA
50
Netzwerkzugriff versus lokaler
Zugriff
• Unterschiedliche Philosophien
– Bei jedem Zugriff wird ver- bzw. entschlüsselt
• Daten gehen in Plain übers LAN
– Nur bei lokalem Zugriff wird ver- bzw.
entschlüsselt
• Daten gehen verschlüsselt übers LAN
• Kann man einen lokalen Zugriff immer verlässlich
von einem Netzwerkzugriff unterscheiden ? (Jein)
• Cachesynchronisation
51
Sondernbehandlungen für …
• Komprimierte Files
– Erkennung
– Zuerst komprimieren und dann verschlüsseln
– Falls dies nicht möglich sein sollte
(Treiberstack):
• Komprimierung verbieten
• „Nutzlose“ Komprimierung durchführen lassen
(aber: Performance!)
52
• Sparse File
– Sie sollen sparse beleiben
• Pageing / Swap Files
– Immer mit einem systemweiten Schlüssel verschlüsseln
(nicht benutzerspezifischen Schlüssel)
• Temp. Files von Applikation
– Können interessante Daten enthalten
• Streams
– Welche Streams außer den „Hauptstream“ gehören
noch verschlüsselt?
53
• Journaling
– Probleme ähnlich wie beim Swap File (keine
benutzerspezifische Keys wegen Reperatur)
– Werden sicherheitsrelevante Informationen
gespeichert? (ja, zumindest bei einigen)
• Transaktionen
– Kann ein Rollback
• eine Verschlüsselung aufheben ?
• eine Umschlüsselung rückgängig machen ?
• eine Verschlüsselung zerstören ?
54
Typische troublemakers
•
•
•
•
Backup – Programme
Replikationsprogramme
Virenscanner
Storage Management Applikationen
55
Behauptung
• Vorhanden Filesysteme, die
Verschlüsselung unterstützen, basieren
meist auf Filtertechnologie (Treiber über
andere Treiber).
• Dieser Ansatz ist ausgesprochen
problematisch.
– Informationen fehlen
– Verhalten nicht eindeutig spezifiziert
56
Was ist notwendig ?
• Definition der Aufgaben des FS (z.Z. alles
ad hoc – Entscheidungen) – ein RFC !!!
•
•
•
•
Netzwerkverkehr ?
Daten in Cache ?
Aktion bei Zugriffsverweigerung ?
Einfache Identifikation der Objekte (Files,
Applikationen)
• Filegrößen
57
Was ist notwendig ?
• Integration ins Betriebssystem
– Metadaten (inode, $Mft, ….)
•
•
•
•
•
•
•
Verschlüsselungszustand
Nutzdatengröße / gesamte Filegröße
Schlüsselbezeichnung
Komprimierungszustand
Sparsefile
Streams
Identifikation der Applikationen, die Daten verschlüsselt
erhalten sollen
58
Was ist notwendig ?
• Integration ins Betriebssystem
– Systemcalls
•
•
•
•
•
•
OpenCreate
Read
Write
Seek
Delete
…
– Die Implementierung der Systemcalls hat die
Sicherheitslogik zu enthalten bzw. Callback dafür
bereitzustellen. Dabei wird Metainformation
mitgegeben / ausgewertet.
59
Resümee
• Kryptographie ist das weitaus stärkste Glied der
Kette
• Kryptographie ist der unproblematischste Teil
• Systemintegration ist der Schwachpunkt
– Betriebs- und Filesysteme sind ohne Bedacht auf
Sicherheit jenseits von Rechten entworfen
• Keymanagent (Erzeugung, Speicherung,
Verteilung, Vernichtung, …)
60
Danke für Ihre
Aufmerksamkeit!
61

Populäre Filesysteme und ihre Sicherheitsprobleme

Transcription

Documents pareils

Anleitung Windows Media Center Dateien WTV in MPEG konvertieren

The file you sent contains the ID3 v2 tag

1. Studienarbeit im Fach Ingenieurinformatik (FA) SS 2013 1

MFT GmbH MFT-Sport Disc

Übung 4

KONFIGURATIONSHILFE

Videoanalyse von Bewegungen:

Übungsblatt 4

Firmware Update

K_Kap11B: Files, Filesysteme Datenstrukturen