Security (beveiliging)

Security
(beveiliging)
Erik Poll
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
INTRO SECURITY
Wat is security?
●
●
“controlling access to resources”
OS moet de beheerde resources
beschermen tegen ongeoorloofd gebruik
Welke resources moet ‘t OS beschermen?
●
processor
●
geheugen
●
I/O devices, bijv
–
disks
–
printers
●
programma’s
●
data
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!
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
Security in OS abstracties
●
●
Algemeen: security onderdeel van
abstracties die OS gebruikt
Bijvoorbeeld:
–
User kan naar file schrijven, waarvoor lowlevel 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.
Security steeds groter probleem!
●
●
Steeds meer gevoelige gegevens en
diensten electronisch en on-line
Computersystemen steeds kwetsbaarder,
door
–
Toenemende complexiteit
–
Toenemende connectiviteit (netwerken)
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
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
Security Objectives: CIA
●
Confidentiality (geheimhouding)
–
●
Integrity (integriteit)
–
●
Geen ongeautoriseerd lezen van gegevens
Geen ongeautoriseerd wijzingen van gegevens
Availablity (beschikbaarheid)
–
Systeem beschikbaar voor legitieme gebruiker
dwz geen Denial-of-Service attack
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
Hoe realiseer je security ? (AAAA)
Authentication
1. Identificeer gebruikers
Access control
2. Zeg wie wat mag en controleer dit
Auditing & Actie
3. Kijk of er (toch) niks misgaat
4. En zoja: onderneem actie hiertegen
Security in fysieke wereld wordt ongeveer
net zo gerealiseerd, bijv:
1.
Wie laat je je huis/kamer binnen?
2.
Wat mag iemand in je huis ?
3.
Kijk af en toe of er geen ramen zijn
ingeslagen, of waardevolle spullen ontbreken.
4.
Zoja: verander sloten, koop rolluiken, etc. en
bel de politie & de verzekering.
Maar er zijn essentiele verschillen!
Met name: nadruk op 3 en 4.
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
AUTHENTICATION
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.
Passwords
●
Gebruikelijkste manier van authenticatie
●
Vaak een zwakke schakel:
–
Passwords zijn vaak makkelijk te raden
–
Password worden niet geheim gehouden
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
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 ?
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
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.
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
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
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 !
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?
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.
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 !
ACCESS CONTROL
Access Control
●
●
Specificeren van access rechten
Controleren (enforcen) van access
rechten,
–
●
dwz. controle vooraf/tijdens executies
Auditing
–
dwz. controle achteraf
Access Control
●
Matrix van welk subject (user/proces) aan
welk object (programma/file) mag komen
file1
file2
a.out
root
rw
rw
rwx
anne
rw
rw
rwx
bob
r
-
x
Access Control
●
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 in UNIX/Linux
●
●
Gebruiker heeft user-id en group-id
File heeft owner en group, en rwxpermissies voor owner, group, other
•
rw-r--r-- erikpoll sos tentamen.tex
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
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
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
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
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
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
WAT KAN ER ALLEMAAL MISGAAN ?
Beruchte security problemen
●
Bekijk vers gealloceerd geheugen of
diskruimte, en kijk of hier interessante
informatie staat
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
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
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
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
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
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.
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”
Trusted Computer Base (TCB)
●
●
Voorbeeld: internet bankieren met smartcard en speciale
smartcard lezer
Waarom niet een smartcard lezer ingebouwd in de PC?
Malware (malicious code)
●
trapdoor
●
logic bomb
●
Trojan horse
●
virus
●
–
vroeger: op floppy’s
–
nu: macros (word,VSB) in email attachments
worm
–
●
heeft geen carrier nodig, in tegenstelling tot virus
downloadable code (Java applets in browser)
Trojan Horse
●
●
●
Gebruiker draait programma – met zijn
access rights – met (verborgen) ongewenst
gedrag
Een probleem bij alle gedownloade code
(Ook mogelijk zonder dat de gebruiker er erg in heeft:
bijv. zet een executable ls in je home directory en klaag
bij CNCZ dat er iets mis is met je homedir)
Beroemde backdoor & Trojan
Ken Thompson (Turing Award lecture)
1. Backdoor in login.c
If (name==”ken”) {don't check password;
log in as root;
2. Code in C-compiler (trojan horse) om backdoor toe te
voegen bij (her)compilatie van login.c
3. Code in C-compiler om dit (2&3) toe te voegen bij
(her)compilatie van C-compiler
NB trust is transitive
Mandatory Access Control
●
●
●
Ipv discretionary access control
Ontneem gebruiker vrijheid om permissies te
geven
bij multi-level security (bijv. public, secret,
topsecret) kan de * property
–
no read up: subject mag alleen objecten van lager of gelijk
–
no write down: subject mag enkel objecten van hoger of gelijk
level lezen
level schrijven
beschermen tegen Trojan horse attacks
Reference monitor
●
●
●
trusted system dat mandatory access control
policy enforcet in setting met multi-level
security
populair in defensie toepassingen
zo’n trusted system is natuurlijk onderdeel van
TCB
Security design principles
●
keep it simple!
●
principle of least privilige
●
–
default is no access
–
geef proces de minimum rechten die echt nodig zijn
check for current permission
–
TOCTOU (time-of-creation vs time-of-use)
●
maak ontwerp publiek (Kerckhoffs principle)
●
maar: hou security acceptabel voor gebuikers
CRYPTOGRAFIE
Netwerken
●
●
Security problemen erger door netwerken
Speciaal probleem: geheimhouding van
gegevens over netwerken
Inloggen over netwerk
●
stuur password ongecodeerd over net
–
●
one time passwords
–
●
rlogin, telnet
erg onhandig
stuur password gecodeerd over net
–
slogin, ssh
–
Maar: hoe verspreiden we de sleutels?
Symmetrische Cryptografie
●
●
●
Bijv
–
DES (Data Encryption Standard, 56 bit key)
–
AES (Advanced ~, 128,192,256 bits key)
Coderen en decoderen met dezelfde
sleutel, die zender en ontvanger weten
Probleem: aantal sleutels, verspreiden
ervan, en geheimhouden ervan
Public-Key Cryptografie
●
Oftewel assymmetrische crypto
●
Bijv RSA, gebruikt in PGP, ssh
●
Openbare, publieke, sleutel voor codering,
●
Geheime, privé, sleutel voor decodering
●
Voordelen
–
publieke sleutel kan over netwerk
–
ook te gebruiken voor authenticatie
Public Key
●
Nadeel van public key crypto: traag!
●
Daarom
–
–
●
gebruik eerst public key crypto om
symmetrische sleutel te versturen
gebruik daarna de symmetrische sleutel aka
session
Bijv. gebruik RSA om DES session key af te spreken
Security nooit beter dan zwakste schakel
●
Pas op: zwakste schakel van de veiligheid
van crypto is mogelijk (waarschijnlijk?) de
opslag van de cryptographic keys op een
filesysteem...
Humans are incapable of securely storing high-quality
cryptographic keys, and they have unacceptable speed
and accuracy when performing cryptographic operations.
They are also large, expensive to maintain, difficult to
manage, and they pollute the environment. It is
atonishing that these devices continue to be
manufactured and deployed. But they are sufficently
pervasive that we must design our protocols around their
limitations
–
Kaufman, Perlman, and Speciner
Smart cards
●
Mini computertje, met geheugen (om bijv.
sleutels op te slaan) en rekencapaciteit (voor
de/encryptie), zeer beperkte I/O, en heel simpel
OS
●
Simpeler dan PC, dus more secure
●
Goede opslagplek voor sleutels
●
Gebruikt in SIMs, bankpas, paspoort,...
●
tamper-resistant Trusted Platform
Aanbevolen literatuur over security
●
Security Engineering, van Ross Anderson
●
Secret & Lies, van Bruce Schneier
●
Kijk ook eens op
–
www.cert.org/advisories
–
bugtraq