Häufige Sicherheitsprobleme - Arbeitsgruppe Kryptographie und

Vorlesung Sicherheit
Dennis Hofheinz
IKS, KIT
11.07.2013
1 / 36
Überblick
1 Kurzüberblick häufige Sicherheitslücken
Erinnerung
Denial of Service
Code Execution
Cross-Site Scripting
SQL Injection
Bonus: kryptographische Implementierungsprobleme
Zusammenfassung
2 Allgemeine Bemerkungen
2 / 36
Überblick
1 Kurzüberblick häufige Sicherheitslücken
Erinnerung
Denial of Service
Code Execution
Cross-Site Scripting
SQL Injection
Bonus: kryptographische Implementierungsprobleme
Zusammenfassung
2 Allgemeine Bemerkungen
3 / 36
Motivation
Bislang idealisierte Bausteine/Algorithmen betrachtet
Insbesondere: ideale Implementierung unterstellt
Frage: was kann bei Implementierung schiefgehen?
Ziel nachfolgend: häufige Fehlerquellen erklären
4 / 36
Erinnerung
Ziel: häufige Software-Fehlerquellen erklären
Die fünf häufigsten Typen von Sicherheitsproblemen:
(Buffer) Overflows (schon erklärt)
Denial of Service
Code Execution
Cross-Site Scripting
SQL Injection
Bonus: schlechte Zufallsgeneratoren, schlechte APIs
5 / 36
Überblick
1 Kurzüberblick häufige Sicherheitslücken
Erinnerung
Denial of Service
Code Execution
Cross-Site Scripting
SQL Injection
Bonus: kryptographische Implementierungsprobleme
Zusammenfassung
2 Allgemeine Bemerkungen
6 / 36
Denial of Service
Ziel: Verfügbarkeit eines Systems angreifen
Schädigt insbesondere Systeme, bei denen Verfügbarkeit
finanziell kritisch ist (Online-Banking, Online-Shopping)
Naheliegend: System durch viele Anfragen überlasten
Beispiel: Botnetz (d.h. Menge von Viren infizierter und
gekaperter“ Rechner) greift ständig auf Online-Dienst zu
”
Lässt sich prinzipiell nur schwer verhindern (vor allem bei
Botnetz-Angriffen)
Aber auch geschicktere Angriffe möglich
7 / 36
Hash Table Collisions
Szenario: geschickte Anfragen an Webserver/-dienst stellen,
die möglichst viel Zeit zur Verarbeitung brauchen
HTTP-GET-/-POST-Anfragen von Anwender setzen
Variablen
Beispiel: GET-Anfrage von Benutzer
http://www.google.com/search?q=mad+magazine
setzt Variable q auf mad magazine“
”
Programm (z.B. in PHP, Python) verarbeitet Anfrage und
liest Variablen in Dictionary-Datenstruktur ein
Frage: was könnte dabei schiefgehen?
Zunächst genauer verstehen, was da passiert
8 / 36
Dictionaries
Datenstruktur Dictionary: assoziatives Array
anfrage[’q’] = ’mad magazine’
anfrage[’client’] = ’ubuntu’
... = ...
Wird intern in Array fixer Länge gespeichert:
anfrage[h(’q’)] = (’q’, ’mad magazine’)
anfrage[h(’client’)] = (’client’, ’ubuntu’)
für (nicht-kryptographische) Hashfunktion h : {0, 1}∗ →
Zn
9 / 36
Dictionaries
Dictionaries intern in normales“ Array konvertiert:
”
anfrage[h(’q’)] = (’q’, ’mad magazine’)
anfrage[h(’client’)] = (’client’, ’ubuntu’)
für (nicht-kryptographische) Hashfunktion h
Frage: was passiert bei h-Kollisionen?
Antwort: ersetze Key-Value-Paar durch Liste von
Key-Value-Paaren
10 / 36
Dictionaries
Kosten von n Zugriffen auf Dictionary O(n),
wenn keine h-Kollisionen auftreten
Kosten von n Zugriffen auf Dictionary O(n2 ),
wenn nur h-Kollisionen auftreten
Bei normalen“ Eingaben treten wenige h-Kollisionen auf
”
⇒ üblicherweise Dictionaries sehr effizient
Aber: bei ungünstigen“ Dictionary-Keys (Variablennamen)
”
mit vielen h-Kollisionen Dictionaries sehr ineffizient
11 / 36
Dictionaries und Denial of Service
Angriff: wähle ungünstige“ Variablennamen in
”
HTTP-Anfrage ⇒ lange Verarbeitungsdauer, weil
Variablen-Wert-Paare in Dictionary eingelesen werden
Beachte: h nicht kollisionsresistent
Beispiel: (Quelle: 27C3-Vortrag ”Effective Denial of Service attacks
against web application platforms“)
PHP: Anfragen mit 70-100kb/s lasten i7-Kern voll aus
ASP.NET: Anfragen mit 30kb/s lasten Core2-Kern voll aus
Java (Tomcat), Python ähnlich, Ruby katastrophal
Was tun?
h randomisieren (kryptographische Hashfunktion zu langsam)
Anzahl Variablen bei Anfragen einschränken
12 / 36
Überblick
1 Kurzüberblick häufige Sicherheitslücken
Erinnerung
Denial of Service
Code Execution
Cross-Site Scripting
SQL Injection
Bonus: kryptographische Implementierungsprobleme
Zusammenfassung
2 Allgemeine Bemerkungen
13 / 36
Code Execution
Ziel: lasse eigenen Code beim Opfer ausführen
Beispiel: Buffer Overflow auf Stack (siehe oben)
Warum ist das schlimm?
(Lese-/Schreib-)Zugriff auf anderes System erlangen
Anderes System kontrollieren (→ Botnetze)
Andere impersonieren
Überlappungen mit anderen Softwarefehlern
Deshalb hier nicht weiter behandelt
14 / 36
Überblick
1 Kurzüberblick häufige Sicherheitslücken
Erinnerung
Denial of Service
Code Execution
Cross-Site Scripting
SQL Injection
Bonus: kryptographische Implementierungsprobleme
Zusammenfassung
2 Allgemeine Bemerkungen
15 / 36
Motivation
Ziel: (JavaScript-)Code auf Rechner des Opfers ausführen
Szenario: Opfer surft auf Websites, denen es vertraut
Etwa: Opfer surft in Diskussionsform seriöser Website
Angriff:
Angreifer postet Nachricht, die ausführbaren JS-Code enthält,
als Forumsbeitrag
Opfer ruft Beitrag ab, liest JS-Code, Browser des Opfers führt
JS-Code aus
16 / 36
Motivation
Missstand: Forenseite lässt Angreifer
ausführbaren/ausgeführten JS-Code als Kommentar posten
Warum ist das schlimm?
JS-Code läuft in vertrauenswürdigem Kontext
. . . hat Zugriff auf Cookies/Funktionen von grundsätzlich
vertrauenswürdiger Foren-Website
Beispiel veranschaulicht Probleme
17 / 36
Beispiel
Szenario: Facebook-Nutzer besucht Pinnwand des Angreifers
Angreifer hat auf seiner Pinnwand JS-Code platziert, der
Facebook-Session-Cookie von Opfer an Angreifer sendet
Effekt: Angreifer sieht mit Facebook-Session-Cookie für
Facebook wie Opfer aus und kann Konto von Opfer
kontrollieren
Problem wurde 2010 behoben
Andere Möglichkeit: Facebook-Wurm, der
1
2
sich das Opfer mit dem Angreifer befreunden lässt
und sich anschließend selbst an Freunde des Opfers sendet
(Kommentarfunktion)
18 / 36
Überblick
1 Kurzüberblick häufige Sicherheitslücken
Erinnerung
Denial of Service
Code Execution
Cross-Site Scripting
SQL Injection
Bonus: kryptographische Implementierungsprobleme
Zusammenfassung
2 Allgemeine Bemerkungen
19 / 36
SQL
Was ist SQL? (Structured Query Language)
Sprache, um Abfragen von Datenbanken zu formulieren
Beispiel:
SELECT * FROM cd WHERE interpret = "Fall Out Boy";
wählt alle CDs von Fall Out Boy aus
Nicht nur Queries möglich, sondern auch Anweisungen:
DROP TABLE cd;
löscht Datenbank aller CDs (aufpassen hiermit!)
20 / 36
Beispiel
Beispiel: Nutzer wird nach Interpret gefragt
Frage an Nutzer: Nach welchem Album suchen?
Was intern damit passieren könnte (Nutzereingabe über
Webinterface, PHP auf Webserver redet mit SQL-Server):
$alb = $ GET[’album’];
sql query($db,’SELECT * FROM cd WHERE album = ”$alb”;’);
Erste Zeile setzt $alb auf HTTP-Parameter album“
”
Zweite Zeile kommuniziert mit SQL-Server, soll nach allen
Alben mit Namen $alb suchen
21 / 36
Beispiel
Beispiel:
PHP-Skript, um nach von Benutzer gewähltem Album zu
suchen:
$alb = $ GET[’album’];
sql query($db,”SELECT * FROM cd WHERE album = ’$alb’;”);
Erwartete Eingabe (Beispiel): Folie à Deux
Tatsächliche Eingabe: ’; DROP TABLE cd; #
Konsequenz: PHP-Code setzt zwei SQL-Anfragen ab
1 SELECT * FROM cd WHERE album = ’’
2 DROP TABLE cd
Zweite Anfrage löscht Datenbank aller CDs
22 / 36
SQL Injection
Problem (wie so oft): Nutzereingaben werden intern
weiterverarbeitet, ohne geeignet zu escapen“
”
Kann dazu führen, dass auf Server beliebiger SQL-Code
ausgeführt wird
Mögliche Effekte:
Löschen von Datenbanken
Datenzugriff auf andere Datenbank (z.B. DB aller Passwörter)
Gegenmaßnahme: jede Nutzereingabe escapen/kontrollieren
23 / 36
SQL Injection
(xkcd.com)
24 / 36
Überblick
1 Kurzüberblick häufige Sicherheitslücken
Erinnerung
Denial of Service
Code Execution
Cross-Site Scripting
SQL Injection
Bonus: kryptographische Implementierungsprobleme
Zusammenfassung
2 Allgemeine Bemerkungen
25 / 36
Schlechter Zufall
Kryptographie braucht guten (d.h. unabhängig
gleichverteilten) Zufall
Besonders kritisch bei Schlüsselgenerierung (z.B. für PKE)
Schlüssel einmal generiert, sehr oft benutzt
Schlechter Zufall bei Verschlüsselung ⇒ Chiffrat unsicher
Schlechter Zufall bei Schlüsselgenerierung ⇒ alle Chiffrate
unsicher
Viele mögliche Gründe für schlechten Zufall: fehlende
Entropie, physikalischer Angriff, Implementierungsfehler
26 / 36
Was kann passieren?
Erinnerung ElGamal-/DSA-Signaturen:
G
pk = ( , g , g x )
Sig(sk, M) = (a, b)
G
sk = ( , g , x)
mit
a := g
e
für zufälliges e
G
a · x + e · b = M mod | |
und b als Lösung von
Zweimal derselbe Zufall (d.h. dasselbe e) für Signaturen (a, b)
und (a, b 0 ) verschiedener Nachrichten M, M 0 verwendet:
G
mod |G|
a · x + e · b = M mod | |
0
a·x +e ·b =M
0
Lineare Algebra liefert zunächst e und dann x (also sk!)
Real: Sony hat für PS3 so Code signiert (→ Linux auf PS3)
27 / 36
Was kann passieren?
Schlechter Zufall bei Schlüsselgenerierung verheerend
Im Extremfall nur, sagen wir, 216 mögliche Schlüsselpaare
(Brute-Force-Suche über alle Schlüssel möglich)
Leider realistisch: Debian-OpenSSL-Problem
September 2006: Debian-Maintainer patcht OpenSSL-Paket,
damit Valgrind-Analyse-Tool keine Zugriffe auf undefinierten
Speicher meldet
Problem: OpenSSL greift gezielt auf undefinierten Speicher zu,
um Zufall für Schlüsselgenerierung zu erzeugen
Effekt: Debian-OpenSSL-Schlüsselgenerierung nutzt (für
anfällige Versionen) nur Prozess-ID (16 Bit) als Zufall
Im Mai 2008 bemerkt und korrigiert
28 / 36
Schlechter Zufall (Beispiel)
http://dilbert.com/strips/comic/2001-10-25/
29 / 36
Schlechte APIs
API (Application Programming Interface):
Programmierschnittstelle
Viele APIs kompliziert, unübersichtlich, ändern sich
Ähnlich (strenggenommen keine API):
Kommandozeilenoptionen von komplexen Programmen
Typisches Vorgehen bei Versuch, unbekannte API zu nutzen
1
2
3
4
5
Rumprobieren
Versuchen, Dokumentation zu lesen
Vorwärtsblättern zu den Beispielen
Versuch, Beispiel auf eigene Bedürfnisse anzupassen
Sofort aufhören, sobald erwünschter Effekt eintritt
Sehr problematisch bei kryptographischen APIs
30 / 36
Schlechte APIs
Erinnerung RSA:
pk = (N, e)
sk = (N, d)
e
C = M mod N
(oder, besser:) C = pad(M)e mod N
Beispiel: https://github.com/saltstack/salt/commit/
5dd304276ba5745ec21fc1e6686a0b28da29e6fc
31 / 36
Überblick
1 Kurzüberblick häufige Sicherheitslücken
Erinnerung
Denial of Service
Code Execution
Cross-Site Scripting
SQL Injection
Bonus: kryptographische Implementierungsprobleme
Zusammenfassung
2 Allgemeine Bemerkungen
32 / 36
Zusammenfassung
Häufig sicherheitsrelevante Probleme bei Implementierung
Wiederkehrendes Problem: Eingabe (z.B. über Webinterface)
wird nicht geeignet geparst/überprüft/escaped
Ermöglicht Angreifer oft sogar, Code einzuschleusen
Kryptographiespezifisch: schlechter Zufall, schlechte APIs
Vermeidung der Probleme: Eingaben immer konservativ
parsen, Standardmethoden/-APIs/-pakete benutzen
33 / 36
Überblick
1 Kurzüberblick häufige Sicherheitslücken
Erinnerung
Denial of Service
Code Execution
Cross-Site Scripting
SQL Injection
Bonus: kryptographische Implementierungsprobleme
Zusammenfassung
2 Allgemeine Bemerkungen
34 / 36
Allgemeine Hinweise
Verschlüsselung benutzen (GPG, Truecrypt)
Standardverfahren benutzen (RSA-/ECC-Varianten, AES,
Keccak, TLS)
Bei TLS in aktueller Version, mit aktuellen Patches
Nicht: schnell selbst in obskurem Artikel vorgeschlagenes
chaosbasiertes Verschlüsselungsverfahren implementieren
35 / 36
Bei Interesse. . .
Veranstaltungen im kommenden Semester (WS13/14):
Komplexitätstheorie, mit Anwendungen in der Kryptographie
Asymmetrische Verschlüsselungsverfahren
Digitale Signaturen
Seitenkanalangriffe in der Kryptographie
Praktikum Kryptographie
Voraussichtlich im übernächsten Semester (SS14):
Symmetrische Verschlüsselungsverfahren
Beweisbare Sicherheit in der Kryptographie
Ausgewählte Kapitel der Kryptographie
Kryptographische Wahlverfahren
36 / 36