Sicherheit

1. Sicherheit

2. Zugriffsrechte und Authentifizierung Sicherheit – Wozu? Einbruchsmöglichkeiten Sicherheit im Netz Sicherheit

3. Sicherheit – wozu? • Sicherheit ist kein technisches Problem, sondern ein menschliches. • IT-Sicherheitskonzepte sind nötig für: • Datenschutzkonzept • Virenschutz • Programminstallationen (Keine unkontrollierten!) • backup • ..... Sicherheit

4. Sicherheit – wozu? • Haftungsverpflichtung • Betriebs- und Geschäftsgeheimnisse §204 Abs 1 StGB, §17 Unlauterer Wettbewerb UWG • Datenschutz (Kreditkarten!): zivil.+strafr.Haftung §7 Bundesdatenschutzgesetz BDSG • Kontrolle und Transparenz im Unternehmensbereich KonTraG: effizientes Risikomanagement verlangt (§91,2 AktG) vom Vorstand einer AG (§§76ff,93 AktG)und vom Geschäftsführer einer GmbH (§43 GmbHG) sonst persönlich schadensersatzpflichtig! • Abschlußtestat für börsennotierte AG nur wenn Risiko-Früherkennungssystem ex. • EU-Eigenkapitalrichtlinie (Basel II) Rating von Kreditnehmern, auch nach IT-Sicherheit: Kreditzinsen! • Sarbanes-Oxley-Act SOX Sektion 404 Funktionsfähiges internes Kontrollsystem incl. IT-Risikomanagement nötig, sonst persönliche Haftung! Sicherheit

5. Kontext Risikomanagement Sicherheit

6. Bot-Netze • Bot-Herden ca. 0.30$ pro PC, mit Rating Quelle: www.bizeul.org/files/RBN_study.pdf Sicherheit

7. Hintergrundfakten • Kriminelle Dienstleistungen Quelle: Technology Review, 4/2008 Sicherheit

8. Kriminelle Energie: Hintergrundfakten Sicherheit

9. Frage Sicherheit Gesetz§202c StGB (2007): „Wer eine Straftat nach §202a oder b (Ausspähen und Abfangen von Daten) vorbereitet, indem er … Computerprogramme, deren Zweck die Begehung einer solchen Tat ist, herstellt, sich oder einem anderen verschafft, verkauft, einem anderen überlässt, verbreitet oder sonst zugänglich macht,… wird mit Freiheitsstrafe bis zu einem Jahr oder mit einer Geldstrafe bestraft.“ Frage: Welchen Effekt hat dieses Gesetz? Es werden mehr Verbrechen verhindert, da die Täter Angst vor Strafe haben Es werden Verbrechen gefördert, da damit sichere Systeme verhindert werden Keins von beiden Grundlagen der Programmierung 1 - Teil 3 R.Brause: Sicherheit und Schutz

10. Zugriffsrechte und Authentifizierung Sicherheit – Wozu? Einbruchsmöglichkeiten Sicherheit im Netz Sicherheit

11. Einbruchsmöglichkeiten Passworte erlangen • Passwort erraten • logist. Angriff (Telefon, pers. Besuch,...) • Auslesen der Paßwortdatei unter Unix: /etc/passwd, Anwenden vonLexika von Namen und Begriffen, • Anwenden von finger,who für Daten wie Namen, ZimmerNr., ... • Aber: Willkürl. Passworte sind keine Lösung! • Besser: Biosignatur, Chipkarten, ... • Passwort abhören Datenpakete mithören z.B. von Telnet. Abhilfe: Verschlüsselung, z.B. secure shell, secute file transfer Sicherheit

12. Einbruchsmöglichkeiten • Trojanische Pferde:„harmlose“ Programme mit „Neben“funktionen • Pseudo-login Programme • Email-Programme: emails mit Kontroll-Zeichen, Multimedia email mit Active-X oder link zu Webseite (blended Threat) • WWW-Dienste: Active-X, postscript-viewer, • FTP file transfer: falsche Zugriffsrechte => Überschreiben von Systemdateien • „nützliche“Programme (Spiele etc.): spyware key-logger! • WürmerProgrammierter Einbruch, Errichtung von backdoors • VirenSelbst-Replizierendes Programm, Errichtung von backdoors Sicherheit

13. Einbruchsmöglichkeiten virus program Start user user program program code code Start Infektion • Virusinfektion Sicherheit

14. Einbruchsmöglichkeiten VStart VStart 1000 0 Virus code Virus code String 1 String2 Kontrollübernahme durch Buffer-Overflow > 90% • Überladen von Unix-ProgrammCode bzw. Rücksprungadresse auf Stack Start Rückadr. SP  String2 String1 Argumentpuffer Stackbereich Sicherheit

15. Buffer-Overflow-Angriff Stackframe bei normalem Funktionsaufruf C-Code void function(int a, int b, int c) { char buffer1[8]; char buffer2[16]; ...} void main() { function(1,2,3); } Assembler-CodeAuszug aus "gcc -S -o example1.s example1.c" function: pushl %ebp # sichert EBP 32-Bitbase pointer movl %esp,%ebp # kopiert ESP stack pointer nach EBP subl $24,%esp # schafft Platz f. buffer1+2 movl %ebp,%esp # korrigiert EBP ... popl %ebp ret main: pushl %ebp movl %esp,%ebp pushl $3 # Parameter auf den Stack pushl $2 pushl $1 call function # Funktionsaufruf addl $12,%esp # Stack aufräumen Sicherheit

16. Buffer-Overflow-Angriff Beispiel: Stackmanipulation C-Code 1 void function(int a, int b, int c) { 2 char buffer1[8]; 3 char buffer2[16]; 4 int *ret; 5 6 ret = buffer1 + 12; 7 (*ret) += 8; 8 } 9 10 void main() { 11 int x; 12 13 x = 0; 14 function(1,2,3); 15 x = 1; 16 printf("%d\n",x); 17 } 12 // skip „x=1“ Ausgabe = ? return-Adresse überschrieben, x unverändert, Ausgabe = „0“ Sicherheit

17. Buffer-Overflow-Angriff Kodierung des Angriffstrings • unsicherer Ort der RET-Adr.  NOPs • Virencode darf keine Null enthalten (warum?)  XOR mit Zahl Sicherheit

18. Buffer-Overflow-Angriff Also: strncpy(Quelladr,Zieladr) statt strcpy(Quelladr, Zieladr) in C verwenden ! Benutzung von Stacksicherung wie StackShield, StackGuard, SecureStack,… HW: Keinwrite auf read-only-Code, keinexecute auf read/write-Datenzulassen (AMD64) Einsatz einer sicheren Bibliothek (Link!) libsafe für • strcpy (char *dest, const char *src) • strcat (char *dest, const char *src) • getwd (char *buf) • gets (char *s) • fscanf (FILE *stream, const char *format, ...) • scanf (const char *format, ...) • realpath (char *path, char *reolved_path([ ]) • sprintf (char *str, const char *format, ...) • . . . Sicherheit

19. Der Rootkit-Angriff • Idee: Verhindere, dass ein Virus (Wurm,Trojaner,...) entdeckt und beseitigt wird • Angriff: Fange alle Aufrufe ab, die Dateien, Ordner, Prozesse auflisten können und manipuliere sie. Treiber-Methode kernel mode rootkits API-Methode user mode rootkits SysCall SysCall Sicherheit

20. Der Rootkit-Angriff Rootkit dll • Beispiel Windows NT user mode rootkits „dll import hooking“ User process FindFirstFile Beispiel „Hacker Defender“ von www.rootkit.com user mode kernel mode Sicherheit

21. Rootkit-Erkennung Phase 1: Datensammlung Phase 2: Vergleich Sicherheit

22. Der Rootkit-Angriff • Beispiel Windows NT kernel mode rootkits Methode: systemcallhooking Win32 user mode kernel m o de Systemdienste Object Process Local Memory Security I/O Manager Manager Proc. Calls Manager Monitor S y stem rootkit driver Kernel Process list Hardware Abstraction Layer HAL Hardware Sicherheit

23. Der Rootkit-Angriff • Beispiel Windows NT kernel mode rootkits Methode: Manipulation von Kerndaten Win32 user mode kernel m o de Systemdienste Object Process Local Memory Security I/O Manager Manager Proc. Calls Manager Monitor S y stem rootkit driver Kernel Process list Hardware Abstraction Layer HAL Hardware Sicherheit

24. Der Rootkit-Angriff User process Kernel system call I/O Manager Liste der malware Dateien rootkit filter driver Regular file driver Hard disk • Beispiel Windows NT kernel mode rootkits Methode: Filter-Treiber-Angriff user mode kernel mode Beispiel: NT-rootkit Sicherheit

25. Zugriffsrechte und Authentifizierung Sicherheit – Wozu? Einbruchsmöglichkeiten Sicherheit im Netz Sicherheit

26. Einbruch über Zugriffsrechte Kontrollübernahme (Viren, Würmer etc.) durch • Dateisystem-Zugriffsrechte falsche Schreib/leserechte für Systemdateien => Überschreiben möglich, falsche PATH-Angabe (zuerst .) => falsches „System“programm wird ausgeführt • Systemprogramme-Zugriffsrechte Ausnutzen von Fehlern, um mit Systemrechten zu schreiben. Beispiel: emacs, CGI-Scripts • Administratorrechte für die Installation dubioser Programme Sicherheit

27. Capability-orientierte Zugriffsrechte Capab. ACL Problem: Zugriff auf 1000 Rechner durch 1000 Benutzer Muss jeder sich bei jedem registrieren mit Paßwort? Idee: Capability-Modell vs. ACL Sicherheit

28. Rollenbasierte Zugriffsrechte operieren lesen schreiben lesen stützen schreiben • Capability-Erweiterungen • Rollen-basiertes Modell: User können Rollen mit Capabilities annehmen • Vertraulichkeit (Informationsweitergabe) • Kein User darfObjekte lesen/schreiben, die höher klassifiziert sind als er selbst • Beispiel Krankenhausrollen • Person Rolle Objekt Patient Müller Chirurg Meier Anästhesieprotokoll Anäs thesist Schmidt Kranken blatt Kranken-pfleger Paulsen Sicherheit Grundlagen der Programmierung 1 - Teil 3 R.Brause: Sicherheit und Schutz

29. Authentifizierung Aber: Hilft nicht gegen Trojaner oder man-in-the-middle-Angriff! Sicherheit Authentifizierungsquellen „Etwas, was Sie wissen“ Passwort, PIN, Testfragen „Etwas, was Sie haben“ Kreditkarte, Handy, Token-Generator „Etwas, was Sie sind“ Fingerabdruck, Iris, Bio-Daten Zwei Faktoren-Authentifizierung (T-FA) „starke“ Authentifizierung z.B. PIN und Fingerabdruck Grundlagen der Programmierung 1 - Teil 3 R.Brause: Sicherheit und Schutz

30. Trusted Computing • Initiative, Programmekontrolliert HW-geprüftauszuführen • Konzept: Vertrauenskette (chain of trust) • Problem: SchütztnichtgegenProgrammierfehler z.B. Secure Startup Windows Vista Anwendung BS-Lader CPU boot BIOS BS Hash Hash Hash Messung Messung Hash Messung Messung Vergleich Vergleich Vergleich Vergleich platform configuration register Hash k Hash 2 Hash 1 Hash0 Trusted Platform Module TPM chip Sicherheit

31. Zugriffsrechte und Authentifizierung Sicherheit – Wozu? Einbruchsmöglichkeiten Sicherheit im Netz Sicherheit

32. Sicherheit im Netz: Fire wall fire wall router relay host fire wallrouter: IP-screening der Datenpakete, IP-Übersetzung (HW/SW) Problem: IP-Screening unzureichend(PortNr. wechselt, ex. mehrere Ports für 1 task, Rückantwort an unbekannten Sender nötig) • relay host oder Gateway: Netz-Programme und –Dienste, kontrolliert mit positiv/negativ-Liste (ACL) „Wer darf was“. • Billiglösung dual homed host: external router & relay host & fire wall router andere Netze external LAN Internet router Sicherheit

33. Computerbetrug: Phishing Prinzip: Vorspiegeln falscher Anfragen (email) Speziell: Spear-Phishing Beispiel Postbank-Anfrage Anfrage Bank Kunde SMS Abhilfe: I-TAN M-TAN Indizierte TAN Dynamische TAN Sicherheit Grundlagen der Programmierung 1 - Teil 3 R.Brause: Sicherheit und Schutz

34. Netzgestützter Angriff Problem: Man-in-the-middle Angriff Anfrage Angreifer Bank Kunde verändert Antwort Problem: key logger Angriff Kunde Bank Key logger Angreifer Sicherheit Grundlagen der Programmierung 1 - Teil 3 R.Brause: Sicherheit und Schutz

35. Beispiel 2012: 36 Mio. Euro Schaden Trojaner infiziert PC des Nutzers & fragt nach Handy-Nr. Kriminelle räumen Eselkonto ab SMS mit Virus mTAN wird an Trojaner umgeleitet Trojaner leitet Geld auf ein Eselkonto Online-banking

36. Abhilfe: Isolierung der Prozesse • Beispiel Qubes OS Joanna Rutkowska • Isolierung aller Prozesse von einander durch individuelle, leichte VMs • Isolierung auch der grafischen Benutzeroberflächeninstanzen! (trustedwindowmanager) • Isolierung auch der benötigten Bs-Kernfunktionen (im Unterschied zu VirtualBox etc.) • Abgesicherte Arbeit auf gemeinsamen Dateien • Mikrokern-Basis: XenHypervisor, Typ 1 (HW-basiert) Quelle: Qubes-os.org Sicherheit

37. Abhilfe: Verschlüsselung SenderEmpfänger „inverser“ Schlüssel Kodier-schlüssel Alice Bob Ent-schlüsselungs-Algorithmus Ver-schlüsselungs-Algorithmus Original verschlüsselt Original = symmetrische Schlüssel  asymmetrische Schlüssel öffentlich privat public key - Systeme Sicherheit

38. Abhilfe: Verschlüsselung Beispieleinfache modulo-Verschlüsselung mit Primzahlen p = publickey, q = private key mit pqmod n = 1 z.B. p = 7, q = 13, n = 90 Original: U B O O T ASCII: a = 85 66 79 79 84 kodiert: x = 55 12 13 13 48 x = apmod n ASCII7 <FF> <CR> <CR> 0 Dekodiert a = 85 66 79 79 84 a = qxmod n Problem: p, n gegeben – q kann durch Ausprobieren bestimmt werden, allgemein in log2(n)-Zeit. Lösung: RSA-Algorithmus (1978) Rivest, Shamir, Adleman pq = c, p,q prim, (p,q) privatekey, c public key Faktorisierungc p,qlangsamerals Multiplikationpq  c (one way function) Sicherheit Grundlagen der Programmierung 1 - Teil 3 R.Brause: Sicherheit und Schutz

39. Kerberos-Authentifizierung Die Kerberos-Authentifizierung Athena-Projekt (MIT 1988) Symmetrische Verschlüsselung durch DES • Benutzerauthentifizierung login protocol Anfrage beim AS (Authentication Server) UserName Ergebnis: Sitzungsausweisvalide ca. 8 h Schlüsselverteilung Single Sign onprotocol Anfrage beim TGS (Ticket Granting Service) ServiceName, UserName, Authentification, Sitzungsausweis Ergebnis: Transaktionsausweis (Ticket) valide ca. 5 Min. Service-Einleitung Authentication protocol Anfrage beim Server: ServiceRequest,UserName,Authentifikation, Transaktionsausweis, Ergebnis: ServiceResultat Sicherheit

40. Kerberos-Authentifizierung UserName Ticket UserName, IP, Zeit Service UserName TGS Service UserName Service-Einleitung UserName, IP, Zeit UserName, IP, Zeit Service Ergebnisse Anfrage UserName • Benutzerauthentifizierung Sitzungs-Ausweis UserName A S Schlüsselverteilung Authenticator Sicherheit

41. Kerberos-Authentifizierung Vorteile • Kopie der Ausweise oder Tickets möglich, aber für jede Anfrage fehlt der Authentikator. • Eine Fälschung der Ausweise oder Tickets ist nicht möglich, da die Schlüssel von TGS und Dienst unbekannt sind. • Alle Tickets und Authentifikatoren lassen sich auch vom Benutzer selbst nicht beliebig lange aufbewahren und verwenden: Benutzerrechte können dynamisch verändert werden. • Da das Benutzerpasswort nur einmal eingegeben werden muss, bemerkt der Benutzer von dem ganzenAuthentifikationsprotokoll nichts weiter – eine wichtige Voraussetzung für die Akzeptanz. Sicherheit

42. Kerberos-Authentifizierung Probleme Ausdehnung auf gekoppelte Domänen-LANs (V.5) • Anfrage für Nachbar-Domänentransaktion an RemoteTGS • Ausdehnung auf Nachbarn vom Nachbarn, etc., iterativ bis zum Ziel Probleme • Uhrensynchronität nötig für Zeitschranken. Aber: Zeitauthentizität benötigt selbst das Protokoll; Widerspruch! • Feste Zeitschranken brechen Transaktionen ungewollt ab • Schlüssel und Tickets können evtl. von anderen lokal gelesen werden • Übergang zu abweichenden Systemen bietet Angriffsfläche  einheitliche Sicherheitsrichtlinien XBSS (X/Open Baseline Security Specifications) Sicherheit