Sistemi Operativi III Corso di Laurea in Ingegneria … nei sistemi per la gestione dei delle...

74
Sistemi Operativi III Corso di Laurea in Ingegneria Informatica Facolta’ di Ingegneria, Universita’ “La Sapienza” Docente: Francesco Quaglia Contenuti: 1. Requisiti e metodi per la sicurezza 2. Richiami di crittografia 3. Autenticazione e abilitazione 4. Domini di protezione e sistemi operativi sicuri 5. Attacchi interni al sistema 6. IDS e Reference Monitor

Transcript of Sistemi Operativi III Corso di Laurea in Ingegneria … nei sistemi per la gestione dei delle...

Sistemi Operativi IIICorso di Laurea in Ingegneria InformaticaFacolta’ di Ingegneria, Universita’ “La Sapienza”Docente: Francesco Quaglia

Contenuti:1. Requisiti e metodi per la sicurezza2. Richiami di crittografia3. Autenticazione e abilitazione4. Domini di protezione e sistemi operativi sicuri5. Attacchi interni al sistema6. IDS e Reference Monitor

Requisiti per la sicurezza1. il sistema informatico risulti utilizzabile dai legittimi utenti

2. solo chi dispone di una qualche forma di autorizzazionepossa utilizzarlo, e solo nelle modalità e con le restrizioni stabilite da chi amministra il sistema

il primo requisito può sembrare ridondante: un sistema che non può essere utilizzato da nessuno sicuramentenon è di nessuna utilitàmolto spesso pero’ un aggressore può essere interessatonon tanto ad accedere al sistema informatico, ma piuttosto a rendere impossibile il suo utilizzo ai legittimi utenti (attacchi DOS)nella maggior parte dei sistemi informatici il punto 1 è verificato solo se il sistema non è attaccato

Sicurezza nei sistemi per la gestione dei delle informazioni

• per i sistemi di gestione delle informazioni, il punto 2 precedente si specializza in quanto segue:1. non deve essere possibile la lettura di informazioni

riservate a chi non è autorizzato (confidenzialita’)2. non deve essere possibile la modifica delle

informazioni a chi non ha gli adeguati permessi(integrita’)

3. non deve essere possibile il disconoscimento della produzione delle informazioni da parte di chi le ha create (non ripudio)

Metodi per la sicurezza

• essi sono principalmente 31. Crittografia2. Sistemi di autenticazione3. Sistemi operativi sicuri

• ogni metodo risolve problemi specifici

• i differenti metodi dovrebbero quindi essere utilizzati simulataneamente per garantire adeguati livelli di sicurezza

Crittografia• la parola crittografia proviene dai termini greci krupto (nascosto,

segreto) e grafe (scritto)• scopo della crittografia e’ la trasformazione di un

“messaggio” leggibile da tutti (testo in chiaro) in un messaggio cifrato, leggibile solo da chi possiede apposite conoscenze

• le prime trattazioni matematiche (accessibili al pubblico) risalgono al 1949 ad opera di Shannon

• la crittografia in informatica viene utilizzata sia per “nascondere” informazioni memorizzate su dispositivi di memoria di massa, sia per trasmettere informazioni attraverso canali insicuri (ovvero che possono essere soggetti ad incercettazioni da parte di aggressori)

• inoltre viene utilizzata in alcune forme di autenticazione e per ottenere firme digitali di documenti elettronici

Principi per la crittografiat = testo in chiaroC = funzione di crittazione Kc = chiave di crittazionec = testo crittatoD = funzione di decrittazioneKd = chiave di decrittazione

C(t,Kc) = c (dove C:I x K O)D(c,Kd) = t (dove D: O x K I)

Le tipologie di funzioni di crittazione/decrittazione sono tre:1. a chiave segreta 2. a chiave pubblica-privata3. hash

Sicurezza di un sistema di crittazione

• un sistema di crittazione e’ sicuro se P(t | c) = P(t) per ognit e c, dove

P(t) è la probabilità che il messaggio originale sia t

P(t|c) e’ la probabilità che il messaggio sia tcondizionata alla conoscenza del messaggio crittato c

• ciò vuol dire che la conoscenza del messaggio crittato nondeve darci nessuna informazione sul messaggio non crittato

• esistono anche definizioni meno stringenti di sistema sicuro rispetto a quella data da Shannon (ad esempio tutti i sistemi di crittazione usati oggi sono solo computazionalmente sicuri)

• condizione necessaria affinché una funzione di crittazioneC:I x K O sia sicura è che |K| =|I|

• nei sistemi di crittografia più comunemente usati lo spazio delle chiavi è molto più piccolo dello spazio dei messagginon cifrati

• quindi è sempre possibile rompere il cifrato perenumerazione totale dello spazio delle chiavi, anche se ciò può richiedere un tempo notevolmentelungo e numerose risorse computazionali

Crittografia a chiave segreta• le chiavi di di crittazione e decrittazione coincidono, esempi sono

1. sostituzione monoalfabetica in cui ogni elemento di una stringa alfanumerica si trasforma in un ben determinato altro elemento nel messaggio cifrato

2. cifrari one time pad, possibilmente basati su chiavi della stessa lunghezza dei messaggi

• questo tipo di crittografia puo’ essere sicuro, secondo Shannon, o solo computazionalmente sicuro a seconda della dimensione delle chiavi

• ad esempio, nel caso di sostituzione monoalfabetica, ci si puo’ basare, per decrittare il messaggio su tentativi esaustivi per le chiavi e proprieta’ dei linguaggi naturali

• vi e’ necessita’ di conoscenza pregressa della chiave da entrambe le parti

Crittografia a chiave pubblica-privata• le chiavi di crittazione e decrittazione sono differenti• la chiave di crittazione viene resa disponibile senza necessita’

di un canale sicuro per trasmetterla• la chiave di decrittazione rimane privata per il ricevente delle

informazioni• non e’ necessario generare chiavi nuove per ogni per ogni

coppia di entita’ che intendono comunicare• un esempio di applicazione e’ RSA

Hashing• l’hashing e’ anche noto come message digest, o

trasformazione a senso unico

• chiamando h(m) l' hash di un messaggio m, esso ha le seguenti proprietà:

ci vogliono poche risorse computazionali per calcolare h(m)dato h(m), non esiste alcun metodo computazionalmente semplice per trovare un messaggio n tale che h(n)=h(m)non esiste alcun metodo computazionalmente semplice di trovare due messaggi che abbiano lo stesso hash

• notare che, poiché |O| <|I|, il numero di messaggi che hanno come hash h(m) sarà sempre maggiore dell' unità

• gli hash sono generalmente indipendenti da una chiave

• data una funzione hash h(m), indipendente da una chiave, per creare una nuovafunzione h'(m,k), che dipende anche da una chiave, quelloche si fa è semplicemente concatenare k e m e calcolare l' hash del risultato

• gli hash sono utilizzati per l'autenticazione e per la verificadell' integrità di messaggi o dei dati

Firme digitali• e’ impiegata tipicamente per garantire il non ripudio

• dato un documento, si applica al documento un hashing (tipicamente con forte riduzione della taglia del documento, es. MD5 - Message Digest - e SHA - Secure Hash Algorithm)

• si applica una decrittazione D all’hashing tramite una chiave privata

• si spediscono documento originale e hashing decriptato

• al lato ricevente si calcola l’hashing del documento e si applica una crittazione C con chiave pubblica all’hashing decrittato

• se le informazioni ottenute coincidono allora la firma e’ ritenuta valida

• da notare che la funzione di crittazione/decrittazione (C/D) deve poter ammettere di poter essere applicata in modo da avaere C(D(x))=x, cosa non imediata dato che le funzioni di crittazione sono talvoltastudiate solo per ammettere D(C(x))=x

Autenticazione• l' autenticazione è il processo di verificare l' identità di

qualcuno o qualcosa in maniera affidabile

• e' di vitale importanza per garantire solo a chi ne ha dirittol’accesso a determinati servizi, risorse o informazioni

• le principali forme di autenticazione sono:1. autenticazione basata su password 2. autenticazione crittografica 3. autenticazione basata su dispositivi fisici 4. autenticazione biometrica 5. autenticazione basata su indirizzo

• ovviamente si possono avere anche degli ibridi, e permettere ad esempio l' uso di un certo servizio ad un certo utente solo se la richiesta del servizio proviene da un certo indirizzo IP e l'utenteconosce una password

Autenticazione basata su password• chi vuole autenticarsi dispone di una informazione segreta (la

password), concordata con l' entità con cui ci si vuole autenticare

• il processo di autenticazione consiste nel comunicare la password all' entità che autentica

• questa provvede poi a confrontare la password inviata da chi si vuole autenticare con la password corrispondente, memorizzatain un database

• problemi relativi1. possibilità di ottenere la password quando è trasmessa

semplicemente ascoltando il canale2. se il database che contiene le password viene compromesso,

l'aggressore ottiene le password di tutti gli utenti3. possibilità di ``indovinare’’ la password, se questa è debole (on-

line password guessing e off-line password guessing)

Crittazione delle password• la crittazione delle password e’ un metodo di protezione del

database delle password da uso inproprio per chi ne ha accesso legittimo (es. amministratori di sistema) o non

• la password viene utilizzata come chiave di crittazione (tipicamente tramite hash one-way) di un blocco di dati noto

• il risultato della crittazione viene registrato nel file delle password

• ad ogni accesso, la password viene usata per riprodurre il blocco criptato e verificare la sua corrispondenza con quello presente nel file delle password

• questa tecnica non ripara comunque da “cracker” che hanno ottenuto l’accesso al file delle password e che usano meccanismi di password guessing

Salt e crittazione• la nozione di “salt” viene utilizzata per aumentare il costo

computazionale dell’operazione di password guessing

• ad ogni utente autorizzato viene associato un numero denominato salt

• questo verra’ concatenato alla password vera e propria prima di applicare una operazione di one-way hashing

• se il salt e’ di n bit, per ogni password “tentata” dal cracker si dovranno considerare 2n possibilita’

• il salt associato ad ogni utente viene mantenuto nel database delle password e ridefinito ad ogni cambio della password stessa

• il database mantiene anche il risultato della crittazione applicata alla concatenazione password+salt

Vantaggi del salt

• utenti con la stessa password avranno informazioni differenti registrate nel database delle password

• un attaccante non potra’ quindi determinare l’uguaglianza delle password semplicemente consultando tale informazione

• se un attaccante non possiede il valore del salt allora non puo’ gestire meccanismi efficienti di password guessing off-line

• in tal caso il costo computazionale dell’operazione di password guessing, da realizzare on-line, puo’ risultare proibitivo

Per sistemi UNIX• il database delle password viene mantenuto su due file distinti

1. /etc/passwd2. /etc/shadow

• il file /etc/passwd contiene informazioni di base sugli account ed e’ tipicamente accessibile ad ogni utente

• il file /etc/shadow contiene informazioni addizionali per l’autenticazione, compresa la password criptata tramite l’hashing one-way

• questo file e’ accessibile solo in modalita’ superuser

• se tale file resta confidenziale, password guessing efficiente puo’ essere operato solo dall’amministratore di sistema

• la crittazione si basa su una versione modificata dell’algoritmoDES

Dettagli su /etc/passwd• il file /etc/passwd non "oscurato" ha il seguente formato:

nomeutente:passwd:UID:GID:nome_completo:directory:shell

• ad esempio: nomeutente:Npge08pfz4wuk:503:100:NomeCompleto:/home/nomeutente:/bin/sh

dove Np è il seme (16 bit) e ge08pfz4wuk è la password codificata• nel caso di Shadowing (oscuramento) /etc/passwd invece

conterrà: nomeutente:x:503:100:NomeCompleto:/home/nomeutente:/bin/sh

• x nel secondo campo in questo caso è ora soltanto un segnaposto, ed il formato del file /etc/passwd non è di fatto cambiato, solo chenon contiene più le password codificate.

• questo significa che qualunque programma che legge il file /etc/passwd, ma in realtà non ha bisogno di verificare le password, funzionerà ancora correttamente

Dettagli su /etc/shadow• il file /etc/shadow contiene le seguenti informazioni:

nomeutente:passwd:ult:può:deve:avv:scad:disab:riservato

dove: 1. nomeutente e’ l’account dell'utente2. passwd e’ la password codificata3. ult indica i giorni dall’1/1/1970 fino all'ultima modifica della password4. può indica i giorni prima che la password possa essere cambiata5. deve indica i giorni dopo i quali la password deve essere cambiata6. avv indica i giorni prima della scadenza della password in cui l'utente viene

avvisato7. scad indica i giorni dopo la scadenza della password in cui l'account viene

disabilitato 8. disab indica ig iorni a partire dall’1/1/1970 dopo cui l'account verrà

disabilitato9. riservato indica semplicemente un campo riservato

Funzione di crittazione#include <unistd.h>char *crypt(const char *key, const char *salt)

• dove key e’ l’user typed passwordsalt e’ una stringa a due caratteri scelta nell’insieme [a-zA-Z0-9./]

• tale funzione usa i 7 bit meno significativi di ciascun carattere in key per ottenere una chiave a 56 bit usata per la crittazione

• il valore di ritorno punta ad una sequenza di 13 caratteri ASCII che rappresentano la password crittata, di cui i primi due sono il salt

• attenzione, la funzione e’ non rientrante

Per sistemi Windows

• le informazioni su password e account vengono mantenute sul registry, ovvero un database mappato su un set di file e, per una piccola parte, su memoria volatile

• tra questi file, quello che mantiene le password e’C:\WINDOWS\system32\config\Sam

• le password sono mantenute in forma crittata (tramite hashing)

• il processo di crittazione non utilizza il salt

• le informazioni mantenute nel precedente file determinano anche, come vedremo, la gestione degli accessi agli oggetti

One time passwords• tipicamente utilizzate nel caso di accesso remoto senza crittazione

sul traffico di rete • ad ogni utente viene fornita una lista di password• ad ogni accesso, viene richiesta la password successiva nella lista• questo implica che la scoperta di una singola password (es.

intercettazione durante transito in rete) non fornisce all’attaccante la possibilita’ di utilizzo della stessa per accedere al sistema

• poiche’ non e’ facile mantenere la lista delle password a memoria, vi e’ in genere il problema di doverle registrare su un “supporto dimemorizzazione sicuro”

• si puo’ ovviare tale problema utilizzando un algoritmo di autenticazione proposto da Lamport nel 1981

• tale algoritmo permette l’accesso tramite “transito” di one time passwords, ma l’utente necessita di conoscere una sola di esse

Algoritmo di Lamport• sia P la password nota all’utente ed al sistema• sia f() una funzione “non invertibile”• sia n-1 il numero massimo di accessi ammessi per l’utente• la password per l’i-esimo accesso sara calcolata applicanto n-i

volte la funzione f() alla password P, ovvero Pi =f(f(……(f(P))

• dato che Pi=f-1(Pi-1), la cattura da parte di un attaccante della i-esima password non permettera’ di venire a conoscenza della successiva

• l’unico modo per originare le one time password e’ quindi quello di conoscere la password iniziale P, la quale non transita, e quindi non e’ soggetta ad intercettazione

n-i volte

Autenticazione crittografica• A prova la sua identità a B effettuando una operazione crittografica

su una quantità fornita da B

• se l' operazione crittografica scelta è una cifratura con un algoritmo achiave segreta o con una funzione hash, lo schema per l'autenticazione è il seguente:

1. A si rende noto presso B2. B invia ad A un numero R3. A calcola c(R,k) e lo invia a B4. B confronta c(R,k) inviatogli da A con quello precedentemente

calcolato da B stesso5. se i due valori sono uguali, A è autenticato presso B

• c(R,k) è una funzione di crittazione a chiave segreta o una funzionehash ed R è un numero chiamato sfida

Trattamento della sfida R• B deve generare R in maniera che sia sempre diverso ad ogni

tentativo di autenticazione

• può essere ad esempio un numero casuale molto grande, unTimeStamp, o un numero generato con un qualche altro algoritmo (ad esempio concatenando un numero casuale con unTimeStamp)

• R deve però essere scelto in maniera tale che un aggressore non possa memorizzare un numero sufficiente di coppie <R, c(R,k)> e autenticarsi, fingendosi A, perché B ha usato comesfida un numero R già usato precedentemente

• quindi se si sceglie di usare un TimeStamp come sfida, B deve assicurarsiche non possa avvenire nessun tentativo di connessione prima che ilTimeStamp sia cambiato

Varianti• l' autenticazione tramite funzione hash non risolve il problema

della compromissione del database di B

• questo problema è però risolto se si usa come funzione di crittazione una funzione a chiave pubblica (in quanto neldatabase di B sono memorizzate solo chiavi pubbliche)

1. A si rende noto presso B2. B invia ad A un numero R (sfida)3. A calcola R'=c(R,kprivata) e lo invia a B4. B calcola d(R',kpubblica) e lo confronta con R5. se i due valori sono uguali, A è autenticato presso B

• resta pero’ il problema di dover supportare la memorizzazione della chiave privata al lato dell’utente e di fornire capacita’ di crittazione

Autenticazione basata su dispositivi fisici• chi vuole autenticarsi deve disporre di un apposito dispositivo fisico,

normalmente una smartcard o una tessera magnetica

• il dispositivo fisico in realtà effettua l'autenticazione al posto del possessore, utilizzando uno dei sistemi visti in precedenza

• se ad esempio il dispositivo di autenticazione è una smart card, l'algoritmo di autenticazione potrebbe essere il seguente:

1. il sistema invia alla smart card una sfida2. la smart card critta il numero ricevuto come sfida (possibilmente

in combinazione con la pasword dell’utente) e lo invia al sistema

3. se il numero inviato dalla smart card è uguale a quello calcolato dal sistema, il possessore della smart card è autenticato

• uno dei vantaggi della smartcard, rispetto alla tessera magnetica, e che il protocollo crittografico potrebbe essere cambiato se si puo’ eseguire un iterprete di protocollo sulla smartcard stessa

Abilitazione per indirizzo• l' abilitazione per indirizzo consiste nello specificare, per un

determinato servizio, quali sono gli indirizzi da cui si accettanole richieste

• in genere, l' elenco degli host da cui accettare richieste èchiamato Access Control List (ACL)

• questo tipo di abilitazione e’ alla base di note applicazioni per il controllo dell’accesso ai servizi, quali

i super-server (es. inetd – internet demon, xinetd – extended internet demon)i contenitori TCP (es.tcpd)

UNIX inetd• il suo scopo e’ rimanere in ascolto di connessioni su specifici port

number

• all’arrivo di una connessione, avvia il servizio relativo

• per determinare il servizio associato ad un port number viene consultato il file etc/services, strutturato come segue

……ftp-data 20/tcpftp 21/tcptelnet 23/tcp……

• questo super-demone non e’ stato originariamente pensato per problematiche di sicurezza, bensi’ per motivazioni legate all’uso efficiente delle risorse

Configurazione di inetd• le informazioni di configurazione per inetd vengono mantenute nel

file /etc/inetd.conf

• per ogni servizio controllato viene specificata una linea contenente i seguenti campi

il nome del servizio, come specificato tramite il file /etc/servicesla tipologia di socket relativa (es. stream)il protocollo livello socket (es. TCP)un flag (wait/nowait) che indica se il servizio va eseguito con attesa o in concorrenza pienal’identificazione dell’utente a cui associare l’istanza del processo server (es. root)l’ubicazione dell’eseguibile per il processo server (es. /usr/sbin/telnetd) ed eventuali parametri per esso

Caratteristiche di xinetd• estende le funzionalita’ di inetd come segue

controllo di accesso basato su indirizzo, nome o dominio dell’host remotocontrollo di accesso basato su segmenti di temporegistrazione completa delle connessioni, inclusi successi e fallimentiprevenzione di attacchi DOS tramite definizione di un limite su

numero di istanze di server per un determinato servizionumero di istanze di server totalidimensione dei file di lognumero di connessioni avviate da una singola macchina

• il file di configurazione e’ /etc/xinetd.conf e puo’ essere generato in modo automatico a partire da /etc/inetd.conf tramite l’utility PERL xconv.pl

Contenitori TCP: tcpd• il demome tcpd viene “avvolto” intorno a specifici servizi gestiti

tramite inetd, al fine di implementare controllo di accesso• tcpd e’ il server lanciato ad ogni richiesta pervenuta an inetd• tcpd riceve come parametri la specifica del servizio richiesto, e

quindi la possibilita’ di risalire al relativo eseguibile • la gestione dei servizi avviene tramite delle regole codificate nei file /etc/hosts.deny e /etc/hosts.allow

• questi file descrivono per ogni servizio, gli host non ammessi o ammessi al servizio stesso

• ogni riga dei file ha la forma daemon_list : client_list• la stringa ALL identifica il set di tutti i servizi gestiti da inetd, e di

tutti gli host• un esempio (accesso a tutti i servizi inetd dall’host locale)

# /etc/hosts.allowALL: 127.0.0.1

Contraffazione del reverse DNS• in genere la specifica degli host (o domini ammessi)

avviene tramite nomi simbolici (non solo indirizzi IP)

• all’atto della connessione, tcpd verifica l’indirizzo IP della sorgente ed effettua una richiesta di “reverse DNS” al fine di ottenere il nome simbolico dell’host sorgente

• un attaccante puo’ contraffare l’operazione di reverse DNS per figurare un nome simbolico lecito per la sua macchina

• per ovviare a tale problema, tcpd tipicamente esegue sia il “forwards DNS” che il “reverse DNS” su IP e nome in modo da verificare la veridicita’ del nome

Contromisure sulla contraffazione del reverse DNS

client

inetd

tcpd

IP x.y.z.h

DNSreverseIP to name

forwardname to IP

se uguale a x.y.z.h l’accesso vieneabilitato, altrimenti viene negato

Firewall• un Firewall e’ un particolare router che effettua il filtraggio dei

pacchetti• per un Firewall un indirizzo è una terna <protocollo,indirizzo IP,port

number> , dove port number ha senso se il protocollo è TCP o UDP • in fase di configurazione si introducono delle regole che specificano

quali pacchetti possono attraversare il Firewall, basandosi sull' indirizzo del mittente o della destinazione del pacchetto

• in questa maniera il Firewall può ad esempio permettere il passaggiosolo a pacchetti TCP che abbiano come porta di destinazione la porta80 (porta HTTP standard) della macchina dove risiede il web server

• in tal modo si puo’ disabilitare la macchina dove risiede il web server ad accettare connessioni telnet o ftp da macchine esterne alla rete controllata dal Firewall

• questo puo’ avvenire senza intervenire sulla configurazione delle singole applicazioni

Ispezioni statefull sui firewall• recenti tecniche per i firewall permettono non solo di verificare il

livello dei pacchetti ma anche di verificare il comportamento del protocollo applicativo supportato tramite lo scambio dei pacchetti

• questo tipo di monitoraggio viene denominato ispezione statefull

• ad ogni port number viene associato quindi un protocollo di livello applicativo da monitorare (es. HTTP nel caso di port number 80)

• il firewall verifica quindi anche lo scambio dei dati segua delle regole relative ad un processo noto ed abilitato

• questo permette un certo grado di protezione nei confronti di compromissioni del processo server

Sistemi operativi sicuri• un sistema operativo sicuro si differenzia da un sistema operativo convenzionale nella granularita’ con la quale e’ possibile impostare i permessi di accesso alle risorse

• in tal modo, un aggressore (incluso un utente lecito del sistema) ha una scarsa possibilita’ di fare i danni (in termini di accesso/manipolazione di informazioni o instabilita’/inutilizzabilita’ del sistema) che farebbe su un sistema convenzionale

• esempi di sistemi operativi sicuri sono SELINUX (della NSA) e SecurLinux (della HP)

• i sistemi operativi sicuri si basano sulla nozione di dominio di protezione

Domini di protezioneDEFINIZIONE: un dominio di protezione è un insieme di

coppie <risorsa, modalità>

• se una risorsa non compare nel dominio di protezione associato ad un utente o programma, questo non può accedervi

• se invece compare, questo può accedervi solo nelle modalità specificate nel dominio

• la filosofia quindi dei sistemi operativi che implementano i domini di protezione è quella di associare ad ogni programma ed utente il minimo livello di privilegi necessari per l' esecuzione del proprio compito

• in alcuni di questi sistemi operativi il dominio di protezione è associato non al livello del programma ma al livello del processo.

• il vantaggio di questo approccio è che il dominio può variare nel tempo (tipicamente per riduzione dei privilegi)

• quindi se in esecuzione sono presenti vari processi istanzadel medesimo programma, questi non sono vincolati ad avere lo stesso dominio di protezione

• in questa maniera quando un processo è arrivato ad unpunto in cui non ha più bisogno di accedere ad una risorsa,può ridurre i suoi privilegi, senza compromettere il funzionamento degli altri processi (che magari necessitano di quella risorsa)

Vantaggi dei domini di protezione

• supponiamo che un aggressore sia riuscito ad entrare nel sistema scavalcando le procedure di autenticazione, ad esempio attraverso un bug presente in un programma

• la possibilità che ha di fare dei danni è limitata al dominio di protezione del processo attraverso cui èriuscito ad ottenere l'ingresso nel sistema

• se ad esempio un aggressore riesce ad entrare in unsistema attraverso il web server, non riuscirà comunque a fare danni (o comunque i danni saranno limitatiall'interno del dominio del web server)

Politiche per la sicurezza

DEFINIZIONE: una politica di sicurezza si dice discrezionaria se gli utenti ordinari possono essere coinvolti nella definizione delle funzioni della politica e|onell' assegnazione degli attributi di sicurezza

DEFINIZIONE: una politica di sicurezza si dice mandatoria o non discrezionale se la definizione della logica della politica e l'assegnazione degli attributi di sicurezza sono strettamente controllate da unamministratore di politiche di sicurezza di sistema

Politiche per la sicurezza e SO sicuri• un sistema operativo sicuro non si deve limitare soltanto aimplementare i domini di protezione, ma deve anche implementare politiche di sicurezza mandatorie

• se infatti per un utente fosse possibile aggiungere voci alsuo dominio di protezione, questi ultimi non avrebbero alcun senso, se invece gli fosse possibile togliere delle voci da tali domini, potrebbero esserci dei malfunzionamenti (sistemanon utilizzabile)

• i sistemi operativi più comunemente utilizzati, ovvero isistemi Windows e Unix-like, non offrono alcuna politica di sicurezza mandatoria, ma offrono solo politiche di sicurezza discrezionaria (es. gli utenti stabiliscono i permessi di accesso ai file)

Amministratore di un SO (sicuro)

• in un sistema operativo non sicuro (es Windows e UNIX convenzionali) un amministratore di sistema puo’ avere accesso a qualsiasi risorsa in qualsiasi momento

• se un attaccante sovverte il sistema (vedremo tra breve come possa essere possibile) ed acquisice il permesso di amministratore allora puo’ creare qualsiasi tipo di danno

• in un sistema operativo sicuro in cui i domini massimi siano definiti anche per l’utente amministratore e attivati all’avvio del sistema questo non puo’ accadere

Attacchi interni al sistema• un attacco si dice interno ad un sistema se esso e’ apportato da

un attaccante che per qualche motivo interagisce con un applicazione gia’ operativa nel sistema stesso

• tale attaccante potrebbe per esempio essere un utente lecito del sistema stesso oppure un individuo il quale ha violato un account lecito

• gli attacchi interni al sistema si distinguono nelle seguenti tipologie

cavalli di troialogin spoofingbombe logicheporte nascostebuffer overflow (exploit)

Cavalli di troia• un cavallo di troia consiste in un modulo software incluso in

un programma apparentemente innocuo, o attivato in circostanze apparentemente innocue, che serve invece ad eseguire azioni illecite

• per attivare un cavallo di troia e’ necessaro che il programma che lo contiene venga eseguito

• questo puo’ avvenire in vari modi:

il modulo puo’ essere contenuto in un programma reperibile via rete (in tal caso l’autore del cavallo di troia non deve neanche violare il sistema in oggetto)

il programma che contiene il cavallo di troia puo’ essere installato in directory tipiche per il PATH di una shell, in modo che esso venga chiamato al posto del corrispettivo comando originale avente lo stesso nome

il programma contenente il cavallo di troia potrebbe essere istallato in directory secondarie per il PATH, ma con nome corrispondente a classici errori di battitura (es la per ls)

il programma contenente il cavallo di troia potrebbe essere istallato sulla home di un utente X con nome pari a quello di un classico comando in modo che se il superuser esegue quel comando una volta portatosi su tale home directory di fatto attiva il cavallo di troia (questo poiche’ alcune shell ricercano i comandi prima nel direttorio corrente)

• come azioni classiche i cavalli di troia tendono ad eseguire task che permettano all’attacante di ripenetrare/sovvertire facilmente il sistema in futuro (es. settando il bit SETUID sul programma shell nel caso il cavallo di troia sia attivato dal superuser)

Login spoofing• questo attacco viene realizzato da un attaccante attivo nel sistema

che esegua un programma che simula il programma di login standard

• il questo caso un utente ignaro interagisce con tale programma il quale pero’ non fa altro che registrare login e password su un file e poi terminare la sessione (es. tramite un segnale)

• in tal caso l’utente crede di aver commesso un errore nel digitare la password che invece e’ stata registrata per uso futuro dall’attaccante

• per proteggersi da questo attacco e’ necessario che l’accesso al software di autenticazione avvenga tramite un evento che venga gestito direttamente dal kernel (es CTRL-ALT-DEL su sistemiWindows)

Bombe logiche

• e’ una porzione di software tipicamente inserita in un programma da un utente ammesso al sistema

• questa rimane innocua se il relativo programma riceve periodicamente determinati input dall’utente

• se inprovvisamente l’utente perde i permessi di accesso al sistema, l’input non viene fornito e’ la bomba logica esplode creando eventualmente danni al sistema

• questo attacco era tipico di utenti leciti “ricattatori”, come ad esempio programmatori disonesti

Porte nascoste

• sono porzioni di software inserite in programmi in modo da ottenere, sotto certe condizioni (ad esempio per l’input)un comportamento non conforme alla specifica ma fraudolento edi aiuto per l’attaccante

• ad esempio, si possono inserire condizioni dipendenti dall’input per baypassare dei controlli sugli accessi

• anche questo tipo di attacco puo’ essere proprio di utenti legittimi ma disonesti

• sia le porte nascoste che le bombe logiche possono essere prevenute tramite la verifica del codice incrociata tra piu’ programmatori

Buffer overflow• come noto, quando viene chiamata una procedura o una funzione, vengono eseguiti i seguenti passi:

1. vengono copiati sullo stack i parametri della subroutine (se non c’e’ ottimizzazione con passaggio nei registri)

2. il PC per il ritorno viene copiato sullo stack3. viene riservato sullo stack lo spazio per le variabili locali

• il buffer arr puo’ essere utilizzato per l’input senza che venga effettuato controllo sui suoi limiti, questo e’ quello che succede per esempio tramite classiche chiamate a funzioni quali scanf

• un aggressore può sfruttare questo problema per alterarel'indirizzo di ritorno della subroutine e far eseguire del codice scelto da lui

• questo genere di attacchi è chiamato overflow del buffer o exploit dello stack

• il codice scelto dall’attaccante potrebbe essere gia presente nell’applicazione attiva oppure potrebbe essere immesso tramite lo stack stesso (in input in un buffer quale ad esempio arr), in tal caso siparla di carico di lavoro per l’exploit

• nel caso in cui il codice venga immesso in input allora l’attaccante deve fare i conti con possibili ottimizzazioni nel trattamento dei dati (es. padding) da parte del compilatore

• ATTENZIONE:il livello di danno causabile dal buffer overflow e’ tipicamente dipendente dai privilegi attuali dell’applicazione su cui avviene tale exploit e dalla taglia del carico di lavoro immettibilead esempio, se l’applicazione gira con SETUID, allora si puo’ persino arrivare a controllare il sistema (tramite aggiunta di un nuovo utente e/o manipolazione del SETUID sull’applicazione shell)

Un attacco DOS basato su exploit: Ping of Death• questo attacco (del 1996) e’ sfrutta una inconsistenza del

protocollo IP

• il IPv4 prevede che un pacchetto non possa essere più grande di65535 byte

• poiché però non tutte le reti consentono le stesse dimensioni massime per un pacchetto, il protocollo IP prevede la possibilità di frammentare un pacchetto, che viene ricostruito all' arrivo

• purtroppo però le dimensioni di un frammento e il suo offset dall' inizio del pacchetto sono rappresentati da un campo a 16 bitall'interno dell' header IP

• in questa maniera un aggressore, inviando un frammento di65535 byte che comincia dopo 65535 byte dall' inizio del pacchetto, costringe il sistema operativo bersaglio a ricostruire un pacchetto di 131070 byte

• molti sistemi operativi riservavano pero’ solo 65535 byte di memoria per il buffer dei pacchetti.

• il frammento ricevuto quindi andava ad essere scritto fuori dalbuffer, e sovrascriveva dati vitali per il sistema operativo

• il protocollo IP v6 risolve l' inconsistenza eliminando la possibilità di frammentare un pacchetto

Intrusion Detection Systems (IDS)• le soluzioni progettate per rendere un sistema sicurotipicamente non riescono ad assicurare l‘assenza completa di intrusioni

• nasce quindi l'esigenza di individuare tutti gli attacchi chenon è stato possibile evitare

• questo al fine diprogettare contromisure per prevenire attacchi nuoviproteggere le risorse in caso di attacco in corso

• i sistemi di rilevamento delle intrusioni (IDS) si basano su due distinti paradigmi

Anomaly DetectionMisuse Detection

Anomaly Detection• in questo paradigma si parte dall' assunto che gli attacchi sono

eventi anomali (infrequenti), e si estende questa osservazione ipotizzando che ogni evento anomalo sia un attacco

• si individua quindi un insieme di eventi normali (frequenti) e si ipotizza che tutto ciò che non ricade in questo insieme sia un attacco

• possono essere identificati come attacchi anche eventi che non corrispondono ad attacchi reale (ma sono semplicemente eventi non codificati come normali)

• si ha quindi il problema dei falsi positivi, che puo’ portare all’attivazione di contromisure da parte dell’IDS quando queste non sono effettivamente richieste

• questo approccio puo’ inoltre proporre anche per il problema dei falsi negativi (se un attaccante riesca a compiere il suo lavoro scatenando solo eventi normali)

Misuse Detection• in questo paradigma si individuano a priori gli eventi che

caratterizzano gli attacchi e si codificano all'interno dell' IDS

• si individua quindi un insieme di eventi ``patologici'', ovvero che sono associati ad aggressioni con probabilità molto alta, l'IDS identifica gli attacchi sulla base di questo insieme

• secondo questo paradigma, un attacco non viene riconosciuto se non associato ad eventi riconosciuti come patologici

• viene fuori quindi il problem dei falsi negativi

Confronto tra anomaly e misuse detection• i due approcci sono l' uno il duale dell'altro:

nell' anomaly detection definiamo gli attacchi come l'insieme complementare degli eventi normali nel misuse detection l'insieme degli eventi accettati (e quindi ritenuti normali) e’ definito come complementare dell' insieme ritenuto degli attacchi

• apparentemente l'anomaly detection garantisce una maggiore sicurezza rispetto al secondo approccio, perché il suo tasso di falsi negativi è più basso rispetto al misuse detection

• la realtà però è diversa poiche’ (l'enorme) numero di falsi positivi tende a nascondere le aggressioni vere

• sono richieste quindi notevoli capacità (e molto tempo) a chi gestiscel'IDS per discriminare tra veri e falsi allarmi

• inoltre vengono bloccati molte azioni legittime solo perché rare, con conseguente aumento dell' intrusività dell'IDS

IDS host based e IDS network based• un’altra differenziazione è quella tra IDS network based e IDS host based

i primi esaminano il traffico di rete (o di una sotto rete) in manierato talmente indipendente dall' host di destinazione dei datii secondi invece esaminano i comportamenti degli utenti e dei programmi a livello di host o di gruppi dihost (ad esempio esaminando i loggenerati dalle applicazioni), e quindi richiedono una collaborazionecon le macchine esaminate

• ovviamente esistono approcci ibridi che fanno entrambe le cose

Tipologie classiche di IDS

• le tipologie classiche per i sistemi IDS sono le seguenti:

honeypotfile integrity checkerslog checkersnetwork intrusion detection

Honeypot• un honeypot è un sistema informatico che

non è utilizzato da nessun utente legittimoè facile (o è ritenuto facile) da attaccare perché presenta (o fingedi presentare) delle vulnerabilità

• la prima condizione ci assicura che ogni tentativo di connessione sia illegittimo, e la seconda assicura che tra tutti i computer di una rete, l' honeypot sia quello con più alta probabilità di essere attaccato

• gli honeypot si basano quindi su una estremizzazionedell'anomaly detection, infatti sull' honeypot l'insieme dei comportamenti normale è l' insieme vuoto, e quindi tutto èritenuto un attacco

File (data) integrity checkers

• un file integrity checker individua le modifiche effettuate ai file (dati) calcolando un hash per ogni file che si vuole controllare e confrontandolo con quello contenuto in un database e calcolato precedentemente

• se i due hash sono uguali, il file non è stato modificato

• anche questo approccio è una estremizzazione dell' anomaly detection, in quanto supponiamo che il comportamento normale sia ``accesso solo in lettura`` ai file controllati dall' IDS

• non è possibile rilevare intrusioni che si limitino a leggere deifile e non è possibile discriminare le scritture legittime da quelle illegittime, per cui, come tutti gli IDS basati sull' approccio anomaly detection, il numero di falsi positivi puo’ essere alto

• gli IDS di questo tipo non funzionano in tempo reale, ma controllano le modifiche ai file solo in intervalli di tempoprestabiliti, per cui esiste un intervallo di tempo tra l'aggressione e la rilevazione dell' aggressione

• inoltre gli aggressori hanno sviluppato delle tecniche che consentono di installare cavalli di Troia all'interno del kernel (es. tramite moduli o tramite riscrittura del file /proc/kmen)

• tali modifiche non vengono rilevate dai file integrity checkers,poiché vengono modificate le system-calls utilizzate dagli IDS

• la modifica è tale che l' IDS vede i file vecchi e non quelli modificati dall' aggressore

Un esempio di modulo per la manipolazione (stealing) delle system call

/** System call "stealing" sample*/

/* The necessary header files *//* Standard in kernel modules */#include <linux/kernel.h> /* We're doing kernel work */#include <linux/module.h> /* Specifically, a module *//* Deal with CONFIG_MODVERSIONS */#if CONFIG_MODVERSIONS==1#define MODVERSIONS#include <linux/modversions.h>#endif

#include <sys/syscall.h> /* The list of system calls */

/* For the current (process) structure, we need* this to know who the current user is. */#include <linux/sched.h>

/* In 2.2.3 /usr/include/linux/version.h includes a * macro for this, but 2.0.35 doesn't - so I add it * here if necessary. */#ifndef KERNEL_VERSION#define KERNEL_VERSION(a,b,c) ((a)*65536+(b)*256+(c))#endif#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,2,0)#include <asm/uaccess.h>#endif/* The system call table (a table of functions). We * just define this as external, and the kernel will * fill it up for us when we are insmod'ed */extern void *sys_call_table[];

/* Initialize the module - replace the system call */int init_module(){void *sys_call_pointer;/* Warning - too late for it now, but maybe for * next time... */

printk("I should list the system call table\n");sys_call_pointer = sys_call_table[__NR_open];printk("table entry %d - sys call: %s\n",__NR_open,sys_call_pointer);/* E’ POSSIBILE MODIFICARE TALE PUNTATORE PER ESEGUIRE UN WRAPPER */return 0;

}

/* Cleanup - unregister the appropriate file from /proc */void cleanup_module(){

printk("exiting system call listing module\n");}

Log checkers• molti server (e talvolta processi generici) generano dei rapporti,

chiamati log o in alcuni casi audit, delle attività compiute dagli utenti quando si connettono ad essi

• questi rapporti possono essere esaminati da appositi programmi, i log-checkers appunto, per individuare comportamenti sospetti o dannosi

• i log checkers sono probabilmente la categoria di IDS più studiata

• in pratica questa tipologia di IDS non riesce a individuare gli attacchinella loro fase iniziale (poiche’ si lavora off-line sui log)

• ciò vuol dire che, se l' approccio è di tipo misuse detection, e quindi gli attacchi non noti non vengono individuati, una volta che unaggressore è riuscito ad evitare questi IDS grazie ad un attacco nonconosciuto, questi IDS non hanno più la possibilità di intercettarlo sia perché un aggressore può corrompere gli eseguibili dell' IDS o la sua configurazione o i log stessi

Network IDS (NIDS)•il NIDS è posto su una macchina dedicata che ascolta (in gergo sniffa) tutto il traffico di rete e controlla se le stringhe di bitinviate sulla rete corrispondono ad attacchi già noti

•l'approccio è quindi di tipo misuse detection puro

•gli IDS di questa categoria possono funzionare su 3 livelli dellostack di rete

a livello IPa livello TCPa livello applicazione

•se il NIDS opera a livello IP, le ``firme'' degli attacchi vengono cercate soltanto nei singoli pacchetti IP, il NIDS quindi non rileva attacchi in cui le firme sono poste a cavallo di più pacchetti

• se l' IDS non è in grado di riassemblare i pacchetti frammentati, non è nemmeno in grado di individuare firme interne ad unsingolo pacchetto ma suddivise in più frammenti

• i NIDS che operano a livello TCP riassemblano i pacchetti che appartengono ad una medesima connessione TCP, evitando il problema della presenza di firme a cavallo dei pacchetti

• normalmente sono implementati come uno strato aggiuntivo posto sopra un IDS che opera a livello IP

• l' IDS che opera a livello IP cerca le firme di attacchi nei pacchetti che non rappresentano una connessioneTCP (come i pacchettiUDP), effettua delle elaborazioni preliminarie passa il pacchetto allo strato superiore, che riassembla i pacchettidi una stessa connessione TCP e controlla la presenza di firme nel flusso dibyte della connessione

Intrusion Prevention System• sono una particolare categoria di sistemi per la sicurezza

che hanno il compito di riconscere un tentativo di attacco in tempo reale e bloccarlo

• tipicamente questi sistemi vengono cablati nel Kernel di sistemi operativi sicuri

• i moduli aggiuntivi del Kernel che compongono il sistema di sicurezza vengono collettivamente denominati come reference monitor

• questi moduli effettuano il monitoraggio delle system call e permettono loro l’esecuzione solo se i parametri hanno un matching con cio’ che e’ specificato in un Access Control Database (si lavora quindi su domini di protezione)

Schema per un Reference Monitor

Un esempio• e’ possibile tentare di apportare un attacco di tipo buffer

overflow ad una applicazione SETUID

• se l’applicazione non e’ attivata dal root, si puo’ decidere di negare l’esecuzione di system call pericolose dal punto di vista della sicurezza (ad esempio per aprire il bit SETUID su altri programmi)

• questo puo’ essere fatto in real-time dal reference monitor tramite strutture dati del kernel standard e strutture dati per la ACL

• ad esempio, per trattare user id ed effective user id sull’applicazione che subisce buffer overflow si puo’ ricorrere alla seguente macro applicata a current

#define IS_SETUID_TO_ROOT(proc) !((proc)->euid)&&(proc->uid)