Security (beveiliging)

1. Erik Poll Security (beveiliging)

2. Overzicht • Intro computer security • Authentication • Access Control • Wat kan er allemaal misgaan ? • Buffer overflow, trojan horses, … • Netwerken & cryptografie • Volgende week ook: inbraak op ‘t UCI

3. INTRO SECURITY

4. Wat is security? • “controlling access to resources” • OS moet de beheerde resources beschermen tegen ongeoorloofd gebruik

5. Welke resources moet ‘t OS beschermen? • processor • geheugen • I/O devices, bijv • disks • printers • programma’s • data

6. Waartegen moet OS beschermen? • Van het OS willen we bescherming van • van OS tegen gebruikers • van gebruikers tegen zichzelf • van (al dan niet kwaadwillende) gebruikers tegen elkaar • alles tegen kwaadwillenden van buiten • Niet alleen in multi-processing of multi-user omgeving, maar ook in single-user/single process omgeving!

7. Wat we al gezien hebben aan security: • Kernel vs user mode (in hardware) • het begrip proces • scheduling controleert access tot CPU • PCB controleert access tot files, geheugen, … • virtual memory: paging, segmentation (deels in hardware) • controleert access tot geheugen • file systemen, met rwx permissies • controleer access tot disk

8. Security in OS abstracties • Algemeen: security onderdeel van abstracties die OS gebruikt • Bijvoorbeeld: • User kan naar file schrijven, waarvoor low-level schrijfinstructie aan disk gegeven wordt. Maar user mag niet rechtstreeks op disk schrijven dmv deze low-level instructie, en dit zou een security probleem zijn.

9. Security steeds groter probleem! • Steeds meer gevoelige gegevens en diensten electronisch en on-line • Computersystemen steeds kwetsbaarder, door • Toenemende complexiteit • Toenemende connectiviteit (netwerken)

10. De realiteit • “The only system which is truly secure is one which is switched off and unplugged, locked in a titanium lined safe, buried in a concrete bunker, and surrounded by nerve gas and very highly paid armed guards. Even then, I wouldn't stake my life on it” • Prof. Gene Spafford

11. Waarom is security moeilijk ? • Toenemende complexiteit, waar security maar zo sterk is als de zwakste schakel • Security fouten lastig te ontdekken: • Bijv: printer die niet werkt leidt snel tot klachten, maar printer waar gratis geprint kan worden niet. • Gebruikers - en sysadmins – vinden security maar lastig. • Bijv: afzetten security-features, of werken als root/superuser/administrator

12. Security Objectives: CIA • Confidentiality (geheimhouding) • Geen ongeautoriseerd lezen van gegevens • Integrity (integriteit) • Geen ongeautoriseerd wijzingen van gegevens • Availablity (beschikbaarheid) • Systeem beschikbaar voor legitieme gebruiker dwz geen Denial-of-Service attack

13. Security Objectives • Integrity is vaak belangrijker dan confidentiality. Bijv: • banksaldo's, tentamencijfers, ..., • hele OS en alle data na inbraak op computer! • Privacy bijzonder geval van confidentiality, nl. voor persoonlijke gegevens

14. Hoe realiseer je security ? (AAAA) Authentication • Identificeer gebruikers Access control • Zeg wie wat mag en controleer dit Auditing & Actie • Kijk of er (toch) niks misgaat • En zoja: onderneem actie hiertegen

15. Security in fysieke wereld wordt ongeveer net zo gerealiseerd, bijv: • Wie laat je je huis/kamer binnen? • Wat mag iemand in je huis ? • Kijk af en toe of er geen ramen zijn ingeslagen, of waardevolle spullen ontbreken. • Zoja: verander sloten, koop rolluiken, etc. en bel de politie & de verzekering. Maar er zijn essentiele verschillen! Met name: nadruk op 3 en 4.

16. Terminologie Stallings noemt authentication • “user oriented access control” • “gebruikersgerichte toegangscontrole” en access control • “data oriented access control”, • “gegevens gerichte toegangscontrole” maar deze terminologie is niet standaard

17. AUTHENTICATION

18. Authentication • Identificatie dmv iets wat je hebt, bent, of weet • Sleutel • Gezicht, stem, vingerafdruk, iris (biometrie) • Handtekening, password • of een combinatie hiervan • Paspoort + gezicht, smartcard + pincode.

19. Passwords • Gebruikelijkste manier van authenticatie • Vaak een zwakke schakel: • Passwords zijn vaak makkelijk te raden • Password worden niet geheim gehouden

20. Problemen met passwords (1) • Meestal makkelijk te raden • Daarom brute force/dictionary attack mogelijk • Bescherming hiertegen: • beperk aantal pogingen • maar dit maakt Denial-of Service attack mogelijk, als je de usernamen kent • vertraag inloggen - houd gebruikers aan password policy

21. Problemen met passwords (2) Passwords worden niet geheim gehouden • verteld aan anderen, opgeschreven • in scriptjes, password managers gezet • onge-encrypt over netwerk verstuurd bij remote inloggen • verklapt door social engineering tricks • bijv. tik jij altijd ctrl-alt-del in voor je inlogt op een machine in een PC zaal hier ?

22. Hoe slaat OS passwords op? Plaintext password file, • dwz passwords “in the clear” opgeslagen, als (uid, pwd) • Sterke access control cruciaal ! • Ook voor backup tapes ... • Root kan alle passwords lezen

23. Hoe slaat OS passwords op? Encrypted password file, • dwz passwords ge-encrypt opgeslagen, als (uid, encryptkey(pwd)) • Bij inloggen, password worden ge-decrypt en vergeleken met ingetikt password • Password nooit unge-encrypt op disk, maar wel onge-encrypt in memory • Root kan waarschijnlijk nog steeds alle passwords lezen.

24. Hoe slaat OS passwords op? Hashed password file, • dwz passwords gehashed (met secure hash), als (uid,hash(pwd)) • Bij inloggen, ingetikt password wordt ook gehashed en verleken met hashed password • Password nooit un-geencrypt op disk en nooit un-encrypt in geheugen • Zelfs root, of inbreker met toegang tot password file, kan niet alle passwords lezen

25. Secure hash • Een secure hash is een functie f waarvan het moeilijk is de inverse f-1 te berekenen • Dwz gegeven y, is het moeilijk een x te vinden zdd f(x)=y • De enige manier om dit te doen is alle mogelijke x te proberen • en als x bijv. een 256 bits woord is, dan is dat (nog!) niet feasible

26. Hashed password file • Stel je hebt access tot hashed password file. Hoe kom je achter de passwords ? • Dictionary attack: hash waarschijnlijke passwords en vergelijk resultaat met gehashde passwords in file • Eg alle strings met [a..z] met lengte < 6 • NB 266 is veel kleiner dan 2256 !

27. Salted hashed password file Bescherming tegen dictionary attack: salt • Ipv (uid, hash(pwd)) slaan we (uid, hash(pwd,salt)) op in password file, waar salt voor elke entry in password file een andere maar bekende waarde is (bijv de uid zelf) • Waarom/hoe beschermt dit tegen dictionary attacks?

28. Iets anders wat mis kan gaan... • Bekende security flaw bij password checking op TENEX OS • Kijk hoe snel een fout password wordt verworpen • Leidt hieruit af eerste karakter goed was • Herhaal dit voor volgende karakters • Hier is responsetijd een zgn. hidden channel dat informatie lekt.

29. Alternatieven voor passwords • Smartcards • bijv. gebruikt voor Internet bankieren • Biometrie: herkenning van vingerafdruk, iris, gezicht, stem, oor, ... • Hot topic tegenwoordig, maar niet zonder beperkingen en nadelen !

30. ACCESS CONTROL

31. Access Control • Specificeren van access rechten • Controleren (enforcen) van access rechten, • dwz. controle vooraf/tijdens executies • Auditing • dwz. controle achteraf

32. Access Control • Matrix van welk subject (user/proces) aan welk object (programma/file) mag komen

33. Gigantische tabel nodig. Daarom organisatie per rij of kolom: Access Control List (ACL): zeg per object wie er aan mag komen. Meest gebruikelijk. Capability List: per user/proces: zeg waar-ie aan mag komen. Voorbeeld: paging. Access Control

34. Access control in UNIX/Linux • Gebruiker heeft user-id en group-id • File heeft owner en group, en rwx-permissies voor owner, group, other • rw-r--r-- erikpoll sostentamen.tex

35. Access control in UNIX: setuid • Executable kan zowel als object als subject gezien worden • setuid maakt de user-id van een proces gelijk aan de eigenaar vd executable • setuid proces heeft rechten van eigenaar van file ipv rechten van user die proces aanroept • Notoire bron van security gaten • In nieuwere UNIX & Linux systemen: fijnere controle mbv capability tickets

36. Access control in Windows-2000 • Elk process heeft een access token, met • User-id (SID) • Groups-id's • Default access control list, voor objecten gecreerd door dit proces • Elk object heeft een security descriptor, • Welke operaties toegestaan voor welke SID's • Welke operaties geaudit worden

37. Waar kan access control misgaan ? • In de specificatie ervan: • vergissing in access control matrix • kloppen de permissies in /home/itt/erikpoll wel? • onbewust verlenen van permissies, bijv door • op attachment te klikken • software te downloaden en executeren

38. Waar kan access control misgaan ? • Gebruikers (en systeembeheerders!) vinden access control maar lastig, en zetten het daarom af • bijv: door processen als root te draaien

39. Waar kan access control misgaan ? • Door software bugs, met name in • kernel code • setuid programma’s • of in andere code waarmee een gebruiker tijdelijk (meer) rechten mee kan verkrijgen, bijv. cgi-bin scripts of SQL queries via webpagina’s

40. Fundamenteel en overmijdbaar risico: • User moet programma’s kunnen opstarten die meer permissies hebben dan user zelf, bijv. • User mag password wijzingen; hiervoor wordt in password file geschreven. • Iedereen mag in proberen te loggen; hiervoor wordt de passwork file gelezen. • Via www.cs.kun.nl/rooster kan iedereen queries op de roosterdatabase uitvoeren.. • Dit heeft security risico's, nl. als er bugs in deze programma’s zitten

41. WAT KAN ER ALLEMAAL MISGAAN ?

42. Beruchte security problemen • Bekijk vers gealloceerd geheugen of diskruimte, en kijk of hier interessante informatie staat

43. Beruchte security problemen • symbolic links zijn bron van ellende • zet symbolic link “core” naar /etc/password en crash een root proces • lpr –r en zet symbolic link om tijdens printen • race condities: mkdir niet atomair; link nieuwe dir naar /etc/password tijdens executie mkdir • buffer overflows, • liefst in deamons: sendmail, finger

44. Buffer overflows • aka “stack overflow”, “smashing the stack” • De allergrootste bron van security holes • Kijk maar eens op www.cert.org/advisories • Recente voorbeelden: Slammer, Blaster worms • Idee: geef een system call een idioot lange parameter om stack te overschrijven • Als hier niet op gechecked wordt, kun je willekeurige code in kernel mode uitvoeren

45. Buffer overflows • Moraal: controleer parameters! Bijv. gebruik bijv. nooit gets(buffer,file) // lees string uit file tot end-of-line // en schrijf deze naar buffer maar altijd fgets(buffer,n,file) // idem, maar max n karakters

46. Buffer overflows • Buffer overflows zijn mogelijk in C en C++ omdat deze talen niet aan array bounds checking doen • Moderne talen, als Java en C#, doen dit wel, wat buffer overflows uitsluit

47. Gebrekkige input validation • Rare input waar niet op gecontroleerd wordt is vaak een bron van security holes. Bijv • geef filenaam “bla.txt;rm%20/etc/passwd” aan cgi-bin scriptje dat file upload • geef usernaam “ `OR 1=1 ” aan web applicatie die SQL query uitvoert • Check altijd op dit soort rare invoer, • bijv. sta enkel [a..zA..Z] in invoer toe

48. kernel bloating • Bugs in OS kernel de bron van security holes • Moraal: houdt de kernel klein • Helaas gebeurd het tegenovergestelde: kernel bloating, waar juist veel code in kernel mode moet draaien, • zowel in UNIX/Linux als in Windows • Bijv. in Windows, device drivers zijn onderdeel vd kernel.

49. Trusted Computer Base (TCB) • TCB is dat deel van een systeem waar je op vertrouwt • OS kernel is onderdeel van TCB • Omdat er zoveel mis kan gaan: houd de TCB zo klein mogelijk • NB: trusted betekent “je vertrouwt het”, niet “je kunt het vertrouwen”

50. Trusted Computer Base (TCB) • Voorbeeld: internet bankieren met smartcard en speciale smartcard lezer • Waarom niet een smartcard lezer ingebouwd in de PC?