1

Sicurezza e privatezza
1. Storia della Computer Security
Anni ‘70 – Mainframe
I mainframe venivano usati principalmente in ambienti militari e governativi e possedevano dei sistemi
multi-utente. Era perciò necessario far sì che gli utenti fossero tra loro separati, eccezion fatta per i dati
condivisi quando necessario, e che non fossero in grado di interferire con la gestione del sistema.

I principali problemi riguardano:

 Crittografia come protezione dei dati salvati in memoria (DES – Data Encryption Standard)
 Query a database
 Privacy

Anni ‘80 – Personal Computer

I computer divennero poi molto più piccoli, più facili da utilizzare (grazie alle GUI) e più economici, al punto
di poter essere acquistati da utenti singoli senza dover passare dall’IT department. A questo punto la
sicurezza multi-utente non serviva più.

Principali problemi:
 Worm: attacchi automatici in grado di autocopiarsi sulla macchina infetta e diffondersi nella rete
 Virus: malware che infettano dei file e danneggiano il software della macchina che li ospita

1988: primo worm (Morris), sfrutta buffer overflow, debolezze delle password e della configurazione del
sistema.

Anni ‘90 – Internet

Internet diventa una tecnologia disponibile a tutti ed aperta all’uso commerciale.

Principali problemi:
 Come sistema di comunicazione necessita di crittografia per proteggere le conversazioni
 I PC non sono più entità a sé stanti, ma sono tra loro connessi tramite Internet: non si può più
controllare chi invia cosa alla macchina (problemi di identificazione e buffer overrun)
 Digital Rights Management (DRM) per la tutela dei diritti d’autore in ambito digitale
 Attacchi DOS (Denial Of Service) vengono combattuti tramite firewall e intrusiondetection system
 Protocolli sicuri: IPsec, SSL/TLS
 Sandbox: prigione in cui viene eseguita un’applicazione al fine di limitare il numero di operazioni che
può fare

Anni 2000 – Web

Sebbene la tecnologia del web risalga agli anni ’90, nei 2000 aumenta il numero di persone che lo
utilizzano, principalmente privati, con un accesso regolare. In questo modo le compagnie sono in grado di
mettersi in contatto diretto con i consumatori, dando il via all’e-commerce.
2

Cambia anche il tipo di attaccante: negli anni ’90 gli attacchi venivano fatti da hacker, in genere ragazzi che
volevano dimostrare la loro abilità in ambito informatico, ma nei 2000 si vengono a formare delle vere e
proprie organizzazioni criminali con lo scopo di rubare dati sensibili o di utilizzare i computer delle vittime
all’interno di botnet (aggregazioni di computer compromessi) al fine di guadagnare denaro. Tuttavia, non
solo i cyber criminali sono autori di attacchi informatici, ma anche attivisti e governi.

Principali attacchi:
 SQL injection: attacchi a database
 Cross-site scripting al fine di rubare le credenziali di un utente
 Attacchi al DNS per fare reindirizzamento sostituendo l’indirizzo IP
 Attacchi APT (Advanced PersistentThread): attacchi rivolti ad un target specifico (es.: per spionaggio)

3. Fondamenti della Computer Security

Strategie di sicurezza
Classificazione delle strategie di sicurezza:
 Prevention (prevenzione): sistema che prende delle misure per prevenire l’attacco, ovvero in grado di
bloccarlo prima che questo avvenga
 Detection (rilevazione): sistema che rileva l’attacco nel momento in cui avviene
 Reaction (reazione): sistema in grado di reagire all’attacco e di ristabilirsi

Obiettivi di sicurezza
Obiettivi di sicurezza:
 Confidentiality (riservatezza): prevenire l’esportazione delle informazioni da parte di chi non è
autorizzato (prevenire la lettura di dati senza autorizzazione)
- Privacy: protezione dei dati personali
- Secrecy: protezione dei dati di un’organizzazione
 Integrity: prevenire la modifica di informazioni da parte di chi non ne ha l’autorità (prevenire la
scrittura di dati senza autorizzazione)
 Availability (disponibilità): proprietà di essere sempre disponibile e accessibile
Problemi:
- Denial of Service (DoS): impedire che gli utenti legittimi possano accedere al sistema (ad
esempio, saturando la banda con continue richieste)
- Distributed Denial of Service (DDos): DoS che utilizza una botnet
- Smurfattack: l’attaccante invia dei pacchetti di rete ICMP echo in broadcast con l’IP sorgente
della vittima (addressspoofing), così che tutte le risposte arrivino alla vittima, saturandone la
banda (flooding)
 3

 Authenticity: si conosce l’identità di chi fa ogni azione

 Accountability (non-repudiation):
 Accountability (responsabilità): log di controllo che permettono di registrare ed identificare le azioni
che sono state fatte e le identità associate ad esse (gli utenti sono responsabili delle loro azioni)
 Non-repudiation: fornire prove evidenti che una specifica azione è avvenuta (ciò non significa che
siano inconfutabili)

Altre proprietà meno collegate alla sicurezza:

 Reliability (affidabilità): il software viene testato secondo le operazioni di utenti normali, è quindi
connessa a problemi accidentali e più comuni. Per far sì che il software sia sicuro è però necessario
testarlo anche secondo pattern non comuni (che vengono utilizzati per gli attacchi)
 Safety: misura l’assenza di influenze catastrofiche sull’ambiente (sicurezza fisica)

Principi della Computer Security

Dimensioni della Computer Security:

Decisioni fondamentali di design:

1. Dove focalizzare i controlli di sicurezza?

Il focus può essere posto su:
 Dati: formato e contenuto dei dati
 Operazioni che possono essere fatte sui dati
 Utenti: dati a cui i vari tipi di utenti possono accedere

2. Dove mettere i controlli di sicurezza?

Man-machine scale: scala dall’utente verso la macchina (modello a cerchi di protezione o a cipolla)

I software maggiormente esposti agli attacchi sono il web browser e le e-mail (applicazioni), ma
andando sempre più verso l’hardware la superficie di attacco diminuisce. Tuttavia, spostarsi verso
l’hardware comporta uno svantaggio: la semantica dei dati ha poco significato, mentre in user-space
essa è molto più ricca di informazione. Ciò comporta che i meccanismi hardware siano molto più
generici rispetto a quelli nei livelli più esterni.
4

3. Conviene adottare meccanismi semplici oppure complessi?

Meccanismi generici (spostati verso l’hardware, secondo il modello man-machine scale) sono più
semplici e portano ad una maggiore garanzia di sicurezza, mentre meccanismi più specifici danno un
più alto numero di feature di sicurezza, ma sono anche più complessi.

4. Sistema di difesa centralizzato o decentralizzato?

 Sistema centralizzato: avere una singola entità che si occupa della sicurezza del sistema rende
semplice raggiungere uniformità (tutto il sistema segue la stessa policy), tuttavia può diventare un
collo di bottiglia a livello di performance
Es. Antivirus con database all’interno della macchina
 Soluzione distribuita: più efficiente, ma bisogna garantire che tutte le componenti abbiano una policy
consistente
Es. Smartphone: i dati e le informazioni di sicurezza vengono inviati ad un server

5. Come bloccare l’accesso al livello sottostante (layerbelow)?

Ogni meccanismo di protezione definisce un perimetro di sicurezza, all’interno del quale risiede la
parte di sistema che può disabilitare il meccanismo. Ciò che cerca di fare l’attaccante è di accedere
all’interno del perimetro passando da una strada non controllata (che passa per i livelli sottostanti), è
perciò necessario controllare e bloccare queste strade alternative.

Esempi di accesso al layerbelow:

 Recovery tools: permettono di recuperare file cancellati leggendo direttamente la memoria.
Questi tool possono essere utilizzati per eludere il controllo logico di accesso, poiché ignorano la
struttura logica di memoria
 Unix considera i device di I/O come dei file: se si definiscono male i permessi di accesso,
l’attaccante può fare azioni che non dovrebbe
 Buffer overrun: il valore assegnato ad una variabile supera la dimensione del buffer allocato per
quella variabile, quindi la variabile viene scritta oltre ai limiti, sovrascrivendo altri dati
 Object reuse: quando avviene un context switch in un sistema monoprocessore potrebbe
accadere che ci siano degli storage residues, ovvero dati lasciati nella memoria dal processo
precedente. Se il nuovo processo potesse leggere tali dati, non ci sarebbe più separazione logica
tra i processi
 Backup: chiunque abbia accesso al backup ha accesso ai dati che contiene
 5

 Core dumps: quando in sistema crasha crea un core dump del suo stato interno. Se tali fossero
contenuti in file accessibili a chiunque, un attaccante potrebbe avere accesso ad informazioni
riservate
 Side channelanalysis: attacco che mira ad ottenere informazioni osservando le conseguenze
dell’implementazione fisica di un meccanismo di crittografia, come il consumo energetico,
informazioni sui tempi, …
 SSL: messaggi che possono essere decifrati calcolando i tempi di risposta dei server SSL

6. Reference Monitors
Reference Monitor, Security Kernel e TCB
 Reference monitor: sistema che media gli accessi
 Security kernel: elementi hardware, firmware e software che implementano il concetto di reference
monitor
 Trusted Computing Base (TCB): insieme dei meccanismi di protezione di un computer la cui
combinazione fa valere la politica di sicurezza

Il reference monitor è un concetto astratto, il security kernel è la sua implementazione e il TCB contiene il
security kernel ed altri meccanismi di protezione (TCB: insieme di tutte le componenti che fanno parte del
reference monitor). Più piccola è la TCB e meglio è. Tutte le componenti della TCB sono da considerare
trusted.

Posizionamento del Reference Monitor

Il reference monitor può essere posto in diversi livelli:
 Hardware: circuiti di sicurezza nei microprocessori
 Kernel o hypervisor (livello -1): l’hypervisor è una macchian virtuale che emula il computer su cui gira
e può essere usato per separare utenti o applicazioni, fornendo a ciascuno una macchina virtuale
 Sistema operativo (livello 0): controllo degli accessi
 Librerie: controllo degli accessi nei database, nella Java Virtual Machine (JVM), …
 Applicazioni: controlli di sicurezza nel codice delle applicazioni

Posizionamento del reference monitor rispetto al programma che controlla:

 RM nel kernel: codice che intercetta tutte le system call del processo
 RM nell’interprete: l’interprete media tutte le richieste di accesso fatte dal programma (es. JVM)
 RM all’interno del programma (in-line RM): i controlli sono all’interno del codice del programma

La terza soluzione è quella più veloce (la velocità di esecuzione dei controlli è pari alla velocità di esecuzione
del programma), mentre la prima è quella più lenta (ogni volta che viene fatta una system call si deve fare
6

un contest switch per eseguire il controllo). Tuttavia, il modello più sicuro è invece il primo: gli altri due
sono in user-space e per questo sono maggiormente esposti agli attacchi.

Integrità del sistema operativo

Anche il sistema operativo in sé è un oggetto di controllo degli accessi, pertanto non deve poter essere
modificato dagli utenti.

Requisiti di un sistema operativo sicuro:

 Gli utenti devono essere in grado di invocare alcune operazioni del sistema operativo
 Gli utenti non devono essere in grado di fare un uso sbagliato del sistema operativo

Concetti fondamentali:
 Modes of operation: quali azioni possono essere eseguite sul sistema.
Un sistema può lavorare in:
- User mode: si possono fare solo operazioni che non sono critiche per la sicurezza
- Supervisor mode: possono essere eseguite anche delle operazioni privilegiate che non possono
essere eseguite in user mode
Per sapere in che modalità si sta eseguendo, l’informazione viene salvata in un registro hardware
(status flag)
 Invocazioni controllate (o privilegi ristretti): quando un utente vuole eseguire un’operazione che
richiede la supervisor mode, è necessario cambiare modalità.

Feature di sicurezza nei microprocessori

La cosa migliore è porre i sistemi di sicurezza negli strati più bassi del sistema:
 È ragionevolmente semplice per implementare meccanismi di sicurezza senza eccessiva difficoltà
 Riduce l’overhead causato dalla sicurezza tramite un’attenta scelta di un set di operazioni di sicurezza
particolarmente utili

Gestione della memoria

Tipi di memoria:
 Volatile: perde il suo contenuto quando il computer viene spento, ma può succedere che parte del
contenuto sia ancora presente al riavvio o che possa essere ricostruito tramite tecniche elettroniche.
Per evitare ciò è necessario sovrascrivere la memoria svariate volte con un determinato pattern di bit.
 Non volatile: la memoria conserva il suo contenuto anche dopo che il computer è stato spento. È
pertanto necessario prendere delle misure di sicurezza a livello crittografico o fisico, poiché un
attaccante potrebbe bypassare il controllo della CPU.
 7

Esempi storici: Intel 80386/80486

4 livelli di privilegio:
 0: sistema operativo
 2: user space
 1 e 3: macchine virtuali

Le informazioni riguardanti gli oggetti del sistema sono contenute in decriptors, all’interno di una
descriptortable e possono essere acceduti tramite dei selettori, campi da 16 bit contenenti l’indice della
tabella e il RPL.

Si definiscono i seguenti campi:

 RPL (RequestedPrivilege Level): livello di privilegio del software chiamante
 CPL (CurrentPrivilege Level): livello di privilegio del codice che è correntemente in esecuzione
 DPL (DesriptorPrivilege Level): livello di privilegio necessario per accedere ad una determinata risorsa
contenuta nella descriptortable

Per accedere alla tabella si utilizza un selettore contenete CPL, si controlla quindi che sia 𝐶𝑃𝐿 ≤ 𝐷𝑃𝐿 (chi
accede deve avere un permesso maggiore o uguale a quello richiesto dalla risorsa: permessi maggiori
corrispondono a livelli di permesso minori).

L’invocazione controllata viene fatta attraverso una system call: il processo chiamante si trova in user mode
(livello 2), ma è poi il sistema operativo (livello 0) che, eseguendo la richiesta, accede alla risorsa. In questo
caso si ha RPL=2 e CPL=0.

Gate: oggetto di sistema che punta ad una procedura che ha un livello di privilegio differente dal gate
stesso. Permette l’esecuzione di procedure di livello inferiore da parte di una procedura che si trova allo
stesso livello del gate. Quando una procedura invoca un subroutine attraverso ad un gate, il CPL (che
inizialmente ha lo stesso valore di RPL) cambia e diventa il livello del codice a cui il gate punta. Alla fine CPL
torna uguale a RPL (non può mantenere il privilegio anche dopo).

ConfusedDeputyProblem
Una procedura con permessi più bassi potrebbe chiedere ad una con permessi più alti di copiare degli
oggetti con alto privilegio in una zona di memoria a basso privilegio alla quale può accedere.

AdjustRequestedPriviledge Level (ARPL): istruzione che imposta gli RPL di tutti i selettori uguali ai CPL dei
processi chiamanti. Il sistema compara poi gli RPL nei selettori con i DPL nei descrittori.
8

Protezione della memoria

Per far sì che i processi siano tra loro indipendenti è necessario che ciascuno di essi sia confinato in uno
spazio di indirizzamento separato.

3 opzioni per controllare l’accesso alla memoria:

 Il sistema operativo modifica gli indirizzi che riceve dal processo utente.
Es.: Addresssandboxing: gli indirizzi consistono in un identificatore ed in un offset. Quando al sistema
operativo arriva un indirizzo, viene fatta una AND bit a bit tra l’indirizzo ed una maschera che cancella
l’identificatore, dopo di che si fa una OR bit a bit con un’altra maschera che mette l’identificatore
dell’indirizzo corretto (operazione svolta dalla MMU).

 Il sistema operativo costruisce gli indirizzi effettivi dagli indirizzi relativi che riceve dal processo
utente.
Indirizzo relativo: offset a partire da un indirizzo base. Il sistema operativo utilizza gli indirizzi relativi
per calcolare gli indirizzi effettivi sommando ad essi l’indirizzo base del programma, controllando che
il risultato sia all’interno dello spazio accessibile dai programmi utente.

 Il sistema operativo controlla se l’indirizzo che riceve dal processo utente è interno ai confini della
porzione di memoria affidata a quel processo
Es.: Motorola 68000 functioncodes: indicano lo stato del processore così che il decoder degli indirizzi
potesse scegliere tra memoria utente e memoria supervisor.

Sandbox (prigione): la memoria viene divisa in finestre, ognuna visibile solo ad un processo
 Do al processo una partizione limitata del file system
 Do una limitazione alle operazioni che il processo può fare

4. Identificazione e autenticazione
Autenticazione degli utenti
Un sistema sicuro deve poter tracciare le identità degli utenti che fanno uso dei suoi servizi:
 L’identità dell’utente è un parametro d’accesso alle decisioni di sistema: permette di associare
l’utente ad una persona vera e propria tramite autenticazione
 L’identità dell’utente permette di loggare le operazioni che svolge

Identificazione e autenticazione
Fasi:
 9

1. Identificazione: l’utente annuncia chi è (username)

2. Autenticazione: processo per verificare l’identità di un utente (password)

Password
Bootstrapping password
Processo di bootstrapping: come viene creata la password per la prima volta.
 L’utente va fisicamente dall’amministratore di sistema che ne controlla l’identità e fa creare la
password
 Creazione della password da remoto: è possibile farlo su più canali, come e-mail, telefono, …

Password dimenticate
Le password vengono facilmente dimenticate, quindi serve un modo per poterle recuperare o resettare.
Per far ciò viene in genere fatta una domanda di sicurezza alla quale solo il vero utente dovrebbe saper
rispondere. Se la risposta è corretta la password viene mandata per e-mail (ciò però significa che è salvata
in chiaro sul sistema), oppure viene inviato un link per crearne una nuova (più sicuro).

Password guessing
Diverse tecniche per indovinare la password di un utente:
 Brute force: si provano tutte le possibili combinazioni dei simboli validi fino ad una certa lunghezza
 Intelligentsearch: si prova un ristretto numero di possibili password che potrebbero essere in qualche
modo associate all’utente (esistono delle password o dei pattern che sono particolarmente popolari)
 Attacchi dizionario: si provano tutte le password contenute in un dizionario (è possibile trovarli on-
line)

Protezioni da questi attacchi:

 Cambiare la password di default
 Utilizzare password lunghe e con caratteri di diverso tipo (maiuscole, minuscole, numeri e caratteri
non alfabetici): il brute force dipende dalla lunghezza della password e dall’alfabeto. Bisogna però
evitare password eccessivamente complesse che non si riescono a ricordare, perché scriverle da
qualche parte potrebbe essere altrettanto pericoloso
 Definire un tempo di scadenza dopo il quale si richiede di modificare la password ed impedire agli
utenti di utilizzare password già usate in precedenza. Anche memorizzare in continuazione password
differenti può essere complicato per gli utenti
 Dare un limite ai tentativi di log-in: il brute force consiste nel provare tutte le possibili combinazioni,
ma in questo modo non può provarle tutte
 Informare l’utente sul numero di tentativi falliti prima di riuscire a fare il log-in

Password manager: applicazione che mantiene traccia di tutte le password sul sistema. È protetto da
un’unica password che funziona come chiave di cifratura per le altre. Quando si vuole loggare ad un sito, il
password manager cerca la password salvata in cloud ed accede automaticamente.

Password spoofing
10

Spoofing: l’attaccante avvia un programma che presenta un finto login che impersonifica il vero sistema di
autenticazione. Quando poi l’utente inserisce le sue credenziali, queste vengono catturate dal programma,
che mostra poi un finto messaggio di errore e ritorna al vero sistema.

Contromisure:
 Mostrare il numero di login falliti
 Trustedpath: modo sicuro in cui è possibile interfacciarsi con la schermata di login
Es.: Windows: CTRL+ALT+CANC (per modificare il programma a cui punta, si dovrebbe accedere alla
Interrupt DescriptionTable, ma se si riesce ad arrivare a questo punto ci sono altri modi per
recuperare le password)
 Mutualauthentication: anche il sistema deve identificarsi verso l’utente

Phishing: l’attaccante impersonifica il sistema per convincere l’utente a rilasciargli la password. In genere si
invia una e-mail all’utente chiedendo di inserire le proprie credenziali su un sito finto creato ad hoc per
essere scambiato per quello originale.

Social engineering: l’attaccante si finge un operatore e contatta l’utente per chiedergli la password al fine di
fare dei controlli fasulli.

Compromettere il file delle password

I sistemi operativi salvano in un file gli username e le password degli utenti (Unix: /etc/shadow). Un
attaccante potrebbe voler accedere a questo file, compromettendone la confidenzialità e l’integrità,
pertanto tale file deve essere protetto:
 Crittografia
 Permessi di accesso

One-way function (hashfunction): dato un input x genera un output f(x), ma dato un output y è difficile
trovare una x tale che y=f(x) (non si riesce a tornare indietro dall’output all’input). Nel file delle password si
salva il valore f(x) corrispondente alla password x ed ogni volta che un utente cerca di loggare si calcola la
hash della password che inserisce e si confronta il risultato al contenuto del file.

Password salting: si aggiunge un salt alla password prima che questa vada in input alla funzione di hash. In
questo modo, se due utenti avessero la stessa password avrebbero comunque due hash della password
diversi.

Sistemi biometrici
Si può essere autenticati sulla base di:
 Qualcosa che si conosce (es.: password, informazioni personali, …): chiunque conosce il segreto è
considerato come il proprietario dell’account e non ci sono prove del passaggio di tale segreto a
qualcun altro
 Qualcosa che si possiede (es.: chiavi, carte, smartcards, …): oggetti fisici possono essere perso o
rubati, pertanto sono solitamente utilizzati in combinazione con qualcosa che si conosce (es.: PIN)
 Chi si è: le tecniche biometriche utilizzano delle caratteristiche fisiche (es.: impronte digitali, iride, …)
per identificare una persona. Non sono tuttavia deterministiche, ma bensì soggette ad errori:
 11

- Falsi positivi: capita che vengano accettate le persone sbagliate (problema di sicurezza)
- Falsi negativi: può succedere che neghi l’accesso ad utenti legittimi (problema di inefficienza)
Queste caratteristiche sono uniche, ma non sono dei segreti: le impronte digitali vengono lasciate in
giro di continuo
 Cosa si fa (es.: scrittura a mano)
 Dove si è (es.: accesso solo da un determinato terminale, GPS)

7. Unix Security
Unix security – background
Obiettivi della sicurezza di Unix:
 Proteggere gli utenti l’uno dall’altro
 Proteggere gli utenti da attacchi provenienti dalla rete

Principi, soggetti, oggetti

Principi
Principi:
 UID (user identifier): numero a 16 bit che identifica un utente, o 0 corrisponde sempre al superuser
(root)
 GID (group identifier): numero a 16 bit che identifica un gruppo

Queste informazioni sono contenute nel file /etc/passwd, in particolare a ciascun account corrisponde
una stringa (account format): username:password:UID:GID:name:homedir:shell

Le informazioni inerenti ai gruppi sono invece contenute nel file /etc/group, le cui entry sono del
formato: groupname:password:GID:list of users. Ogni utente appartiene ad un gruppo primario, tuttavia
può appartenere a più di un gruppo. Gli utenti che appartengono allo stesso gruppo sono soggetti alle
stesse regole.

Soggetti
In Unix i soggetti sono i processi, a ciascuno dei quali è associato un identificativo (PID – processidentifier). I
processi hanno diversi tipi di UID/GID:
 UID/GID reale: vengono ereditati dal genitore e sono il UID ed il GID dell’utente che lancia
l’applicazione in quel momento
 UID/GID effettivo: UID e GID effettivi che vengono utilizzati per l’accesso alle risorse
 UID/GID salvato: serve per poter tornare indietroal UID/GID originale

Es.:
12

Il file /etc/passwd può essere letto da molti programmi che hanno bisogno dei dati degli account. Per
questa ragione le password non sono salvate in /etc/passwd, ma in /etc/shadow, un file che può
essere accessibile solo da root.

Oggetti
In Unix gli oggetti su cui si possono fare delle operazioni si chiamano risorse e sono tutte rappresentati
come file. Sono organizzate in una struttura ad albero (file system) cui ogni nodo (directory o i-node)
contiene informazioni relative ai file che punta, comprese quelle di controllo d’accesso:
 Carattere che indica il tipo del file:
- -: file semplice
- d: directory
 Permessi: 9 caratteri divisi in triplette, ognuna delle quali fa riferimento a degli utenti:
- Prima tripletta: permessi del proprietario del file
- Seconda tripletta: permessi del gruppo del proprietario
- Terza tripletta: permessi per tutti gli altri
Ogni tripletta rappresenta tre diversi tipi di permesso (se non si ha un permesso allora c’è un -):
- r (read): permesso di lettura del file (o di cercare file nella directory)
- w (write): permesso di scrittura del file (o di aggiungere/rimuovere file nella directory)
- x (execute): permesso di eseguire il file (o di aprire i file presenti nella directory)
 Link counter: numero di riferimenti a questo file
 Username del proprietario (in genere l’utente che lo ha creato)
 Nome del gruppo del proprietario
 Dimensione del file
 Data dell’ultima modifica
 Nome del file

Es.:

Altri permessi che possono essere aggiunti:

 set UID (SUID): permette di modificare l’effective UID (se servisse avere dei permessi maggiori)
 set GID (SGID): permette di modificare l’effectiove GID
 sticky bit (S): viene utilizzato nelle directory temporanee dove tutti hanno tutti i permessi, serve per
impedire che un utente cancelli un file di cui non è proprietario

Rappresentazione ottale: per rappresentare 3 bit bastano 8 numeri in decimale (0-7), pertanto è possibile
scrivere ciascuna tripletta di permessi con un numero e tutti i permessi con 3.

Es.: rw-r--r--equivale a 110 100 100 in binario ed a 644 in decimale.

Viene aggiunto poi in testa un quarto numero a rappresentare i tre permessi che possono essere aggiunti:
 4: set UID
 2: set GID
 13

 1: set sticky bit

Comandi:
 chmod: permette al proprietario del file di modificare i permessi (es.: chmod 0754 filename)
 chowm: permette a root di modificare il proprietario del file (es.: chownnOwner:nGroupfilename)

Di default vengono dati i permessi 666 alla creazione di un file e 777 alla creazione di una nuova directory.
Tali possono essere poi modificati utilizzando la umask (numero ottale di 3 cifre rappresentati i permessi
che devono essere negati) in AND bit a bit con i permessi di default.

Security pattern
Invocazioni controllate (programmi SUID)
I programmi SUID girano con lo user ID del loro proprietario, dando accesso controllato ai file che
normalmente non potrebbero essere acceduti da altri utenti, ma che possono farlo eseguendo il
programma.

Quando si mostrano i permessi di un programma SUID, al posto della x del proprietario viene mostrata una
s (minuscola). Analogamente, per i programmi SGID il permesso di esecuzione x del gruppo viene sostituito
con una S (maiuscola).

Un attaccante potrebbe eseguire un programma SUID il cui proprietario è root per accedere ai permessi del
superuser e fare azioni inaspettate. Per questa ragione bisogna processare questi programmi con estrema
cura, controllando gli input e monitorando l’integrità del programma.

Rappresentazione fisica e logica degli oggetti: cancellare i file

Cosa succede quando viene cancellato un file?
 Cancellazione logica: può succedere che, quando viene cancellato un file, si cancelli in realtà solo una
istanza del file stesso, ma questi potrebbe avere delle copie che continuano a persistere. Se il file non
ha copie, la memoria che era prima allocata ad esso diventa ora nuovamente disponibile, tuttavia,
finché effettivamente non viene sovrascritta, continua a contenere il file cancellato
 Cancellazione fisica: è possibile fare una rimozione vera e propria del file sovrascrivendo il suo
contenuto con un pattern apposito

Accesso al layerbelow: mettere al sicuro la memoria ed i dispositivi

Unix considera i dispositivi come file: accedere ad un dispositivo è come accedere ad un file. I dispositivi si
trovano nella directory /dev. Alcuni di questi file sono molto pericolosi dal punto di vista della sicurezza
(es.: /dev/kmem contiene la mappa della memoria del kernel, /dev/hd0 è invece l’hard disk). Se i
permessi non fossero settati a dovere, l’attaccante potrebbe accedere o modificare questi dati.

Importare i dati: file system montati

È possibile montare file system creati esternamente, questo significa che il file system remoto viene
agganciato all’albero principale e il tutto viene visto nel sui insieme.
14

Problema: nel file system remoto possono esserci dei controlli di accesso pericolosi, come dei programmi
con SUID-root per poter avere i permessi del superuser una volta collegati al file system principale. È
dunque necessario eseguire il comando mount con delle opzioni di sicurezza:
 -r: read-onlymount
 nonsuind: disattiva i bit SUID e GID del file system montato
 nonexec: impedisce l’esecuzione di file binari
 nodev: impedisce l’accesso a device

Variabili d’ambiente
Variabili d’ambiente: variabili utilizzare per configurare il comportamento di un programma. Quando viene
creato un processo, esso eredita di default le variabili d’ambiente del processo padre, ma possono essere
poi modificate da un altro programma. Questo può essere un problema poiché il chiamante di un
programma SUID/SGID è in controllo delle sue variabili d’ambiente e potrebbe impostarle a valori
pericolosi.

Il controllo degli accessi potrebbe essere implementato facendo girare i processi sospetti all’interno a delle
sandbox: in genere un programma ha visione di tutto il file system, a partire dalla root directory. Tuttavia,
una sandbox crea un ambiente minimale contenente solo i file strettamente necessari all’esecuzione del
programma, riducendo la visione che esso ha del file system.

Per creare una sandbox si utilizza il comando chroot (change root), che fa vedere ad un programma la
directory indicata come root (non può risalire l’albero oltre a quella directory).

Path di ricerca: possibile eseguire un programma scrivendo il suo nome senza specificare il suo path
(posizione del programma all’interno del file system). La shell cerca il programma seguendo i path
specificati all’interno delle variabili d’ambiente. Quando trova una directory che contiene il programma col
nome specificato lo esegue.

Per inserire un Trojan (malware che si nasconde all’interno di un programma apparentemente innocuo) è
necessario dargli lo stesso nome di un programma esistente ed inserirlo all’interno della directory che viene
controllata prima di quella contente il programma originale.

Wrapper
Inetd (InterNETservicesDaemon): servizio di rete che sta in ascolto di connessioni alla rete (TELNET).
Quando viene fatta una connessione, inetd controlla il file di configurazione e crea un nuovo processo con
lo stesso nome del chiamante che esegue un programmwrapper che esegue dei controlli di sicurezza. Se i
controlli vengono superati allora si procede con l’esecuzione della connessione effettiva.

Gestione della sicurezza di Unix

Proteggere l’account root
Se un attaccante riesce ad ottenere lo status del superuserpuò prendere il controllo di tutto il sistema,
pertanto è essenziale proteggerlo al meglio.

Accorgimenti per prevenire questo problema:

 15

 Dividere i compiti di mantenimento del sistema tra più utenti: se un utente fosse compromesso non
lo sarebbe l’intero sistema, ma solo quello che lui è in grado di controllare
 L’amministratore di sistema non dovrebbe usare root come suo account principale
 Quando bisogna cambiare utente per diventare root conviene specificare l’intero path del comando
(/bin/su): evitare possibili variabili d’ambiente compromesse
 Registrare tutti i tentativi di esecuzione del comando su in un file di log
 Proteggere /etc/passwd e /etc/group con permessi che impediscono la scrittura: in questo
modo un attaccante non può impostare il suo UID a 0

Trustedhost
Gli utenti provenienti da un trustedhost possono loggarsi al sistema senza password, ma è sufficiente che
abbiano lo stesso username su entrambi gli host. Tali sono salvati nel file /etc/hosts.equiv.

Audit log
Non sempre i meccanismi di difesa di un sistema sono sufficientemente adeguati, quindi ci sono dei file di
log per registrare automaticamente alcuni eventi rilevanti a livello di sicurezza (audit log):
 /usr/adm/lastlog: registra quando ciascun utente ha effettuato il login l’ultima volta
 /var/adm/utmp: registra le informazioni del comando who (mostra tutti gli utenti collegati
correntemente al sistema)
 /var/adm/wtmp: registra tutti i tempi di quando un utente fa login e logout
 /var/adm/acct: registra tutti i comandi eseguiti

10.aAttacchi software
Sicurezza software
Sicurezza software: proteggere l’integrità del sistema runtime.

Il software è sicuro se riesce a gestire degli input appositamente malformatiBisogna considerare gli accessi
al programma come untrusted ed applicare dei filtri.

Modelli di visualizzazione del software:

 Black box: non si conosce niente, ma è possibile dare degli input ed osservarne il comportamento
 White box: è possibile vedere l’applicazione anche internamente

Reliability (affidabilità): il software deve comportarsi bene rispetto all’utilizzo dell’utente medio, ovvero
deve evitare fallimenti accidentali dovuti ad azioni che ci si potrebbe aspettare.

Sicurezza: il software deve saper reagire anche a utilizzi atipici (ma tipici per gli attaccanti) e pericolosi.

Pericolo di astrazione
Quando scrivono codice, i programmatori usano concetti elementari con un significato astratto, ma per
eseguire un programma sono necessarie delle implementazioni concrete di questi concetti. I problemi di
16

sicurezza software insorgono nel momento in cui l’implementazione concreta e l’intuizione dovuta
all’astrazione divergono.

Es.: il programmatore può pensare che un intero sia un numero infinito, ma in realtà una macchina lo
rappresenta con un numero finito di bit.

Validazione dell’input
Es.: un’applicazione vuole dare accesso agli utenti solo alla directory A/B/C e si aspetta che l’utente medio
inserisca il nome del file come input. Un attaccante potrebbe invece risalire l’albero inviando come input la
stringa ‘/..’ un po’ di volte, arrivando così alla root directory ed inserire poi qualsiasi path (es.:
/../../../../etc/passwd).

Questa tecnica si chiama directory trasversal: l’utente accede ad una parte di file system di cui non ha
accesso.

Input validation: bisogna filtrare tutti gli input che potrebbero essere pericolosi (non bisogna mai fidarsi che
gli input siano quelli che ci si aspetta).

IntegerOverflow
In matematica gli interi sono infiniti (ed in genere anche i programmatori tendono a pensarla così), mentre i
sistemi informatici li rappresentano in binario con un numero finito di bit, quindi il numero di interi
rappresentabili è finito.

Cosa succede quando si va oltre il massimo numero rappresentabile?

 Interi senza segno: il numero successivo è 0
 Interi con segno: il numero successivo è il minore rappresentabile (numero negativo)

Es.: combine: funzione che prende in input due vettori,

questi vengono poi concatenati e salvati nel buffer
creato precedentemente. Prima di far ciò
si controlla che la somma della lunghezza dei vettori sia
minore della dimensione del buffer finale.

Se i due buffer in input fossero tanto grandi in modo tale che la loro somma vada oltre al massimo
rappresentabile, tale numero sarebbe negativo e passerebbe il controllo dell’if, andando così a
scrivere dei dati in un buffer troppo piccolo per contenerli con la conseguenza di scrivere in una zona
di memoria assegnata ad altro (buffer overflow).

Memory allocation: Buffer Overflow

Quando un programma viene eseguito, il sistema operativo predispone una zona di memoria divisa in:
 Stack: contiene i returnaddress, le variabili locali e gli argomenti delle funzioni chiamate. Quando una
funzione termina, l’esecuzione riprende a partire dal returnaddress specificato.
 Heap: memoria allocata dinamicamente
Sia stack che heap crescono dinamicamente.
 17

Buffer overflow: un buffer è una implementazione concreta di una variabile. Se il valore assegnato alla
variabile eccede la dimensione del buffer, le locazioni di memoria successive vengono sovrascritte e cambia
il valore della variabile a cui erano assegnate. Un attaccante potrebbe quindi generare di proposito un
buffer overflow per modificare delle variabili a suo vantaggio.

Linguaggi come il Java sono type-safe e memory-safe, ovvero impediscono che una variabile possa accedere
ad una zona di memoria allocata ad un’altra variabile. Il risultato è però un linguaggio molto lento.

Linguaggi come il C o il C++ lasciano al programmatore il compito di allocare e deallocare la memoria e non
offrono questo tipo di controlli. Hanno però prestazioni maggiori, necessarie per un sistema operativo.

La struttura dello stack è fissa ed è semplice capire in anticipo dove un particolare buffer verrà posizionato
nello stack.

 Return address: una volta che è terminata, si riprende l’esecuzione dall’indirizzo puntato dal
returnaddress (in genere codice eseguibile)
 Stackpoienter: puntatore all’ultimo elemento dello stack

Stack-basedoverflow: durante l’esecuzione di un programma viene chiesto un input dall’utente. La variabile

corrispondente a tale input viene salvata nello stack, al di sotto di altre variabili (altre variabili del
programma, returnaddress e stack pointer). L’attaccante potrebbe inserire volontariamente un input
troppo grande per essere contenuto nel buffer della variabile corrispondente, generando così un buffer
overflow e sovrascrivendo le altre variabili, compresa returnaddress. A questo punto, quando il programma
termina, l’esecuzione riprende dalla locazione di memoria puntata dal returnaddress, che però ora è quella
scritta dall’attaccante.

Es.: L’input viene scritto all’interno di un buffer di 128 posti (ci si aspetta che sia
18

minore), tuttavia non si fanno controlli sulla sua lunghezza effettiva. Se l’attaccante inviasse un input
maggiore, supererebbe la dimensione del buffer assegnatoli e sovrascriverebbe stack pointer e
returnaddress.

Se la locazione di memoria a cui punta ora returnaddress non esiste, il programma crasha. L’attaccante
vuole però indurre la macchina vittima ad eseguire il suo codice. Per far ciò scrive il programma in
linguaggio macchina (shellcode scritto come sequenze di byte) e lo inserisce come input, così che venga
copiato all’interno dello stack (zona di memoria per i dati, ma nelle architetture Intel è anche eseguibile).
Alla fine aggiunge poi la locazione di memoria dello stack da cui partirà il suo programma in maniera tale
che venga sovrascritta nel returnaddress.

Es. di input: XAB/XCC/XEP/0xbfffff (la prima parte è la sequenza di byte dello shellcode, mentre alla
fine c’è un indirizzo di memoria). In genere il shellcodeaddress viene replicato molteplici volte alla fine
dell’input, così da riempire eventuale spazio rimanente all’interno del buffer.

Se il programma originale in esecuzione avesse i permessi di root, anche lo shellcode dell’attaccante

avrebbe tali permessi e l’attaccante avrebbe il completo controllo della macchina.

Ma come fa l’attaccante a conoscere lo specifico indirizzo a cui saltare? Grazie alla memoria virtuale un
processo usa gli stessi indirizzi sia sulla macchina della vittima che su quella dell’attaccante (sarà poi la
MMU ad occuparsi di tradurli in indirizzi fisici). L’attaccante può dunque fare delle prove in locale sulla sua
macchina per arrivare a scoprire l’indirizzo desiderato.

TypeConfusion
Typesafety: proprietà di un linguaggio di programmazione (come il Java) che assegna un tipo alle variabili e
se queste poi cercano di cambiare tipo senza le dovute chiamate genera errore. Quando un programma
Java referenzia una variabile (o un oggetto) genera un puntatore all’indirizzo di memoria contenente la
variabile.

Typeconfusion: attacco che induce il linguaggio ad avere due puntatori (che dovrebbero puntare ad oggetti
di diverso tipo) alla stessa zona di memoria.

Il linguaggio fa solo un controllo a livello software, pertanto questo tipo di attacchi sono a livello hardware:
magneti, calore, infrarossi, rowhammer (scritture costanti in memoria): per fare typeconfusion basta
cambiare pochi bit che possono essere osservati in maniera deterministica.

SQL Injection
SQL injection: permette di modificare la query al fine di leggere tutte le informazioni presenti all’interno del
database.
 19

Es.: SELECT * FROM client WHERE name=‘$name’

Ci si aspetta che l’utente inserisca il proprio nome. L’attaccante però potrebbe inserire, invece del
nome, la stringa “Bob’ OR 1=1”, in tal modo la query diventerebbe:
SELECT * FROM client WHERE name=‘Bob’ OR 1=1
In questa query la condizione del WHERE è sempre vera (1=1), quindi restituirebbe l’intera tabella
client.

Come contromisura è possibile utilizzare dei sistemi di filtering: controllano che non ci siano caratteri
pericolosi come gli apici.

10.b Difese software

Il buffer overflow è un attacco in memoria basato su 3 principi:
 Possibilità di iniettare codice nello stack
 Conoscenza dell’indirizzo di memoria del buffer dove inizia lo shellcode
 Possibilità di sovrascrivere il returnaddress

Secure Return AddressStack (SRAS)

Il returnaddress della funzione non viene salvato solo all’interno dello stack, ma anche in un altro registro
che si trova in una zona di memoria diversa. Quando la funzione termina, l’hardware rimpiazza il
returnaddress dello stack con quello salvato nel registro separato e subito dopo il programcounter assume
il valore del returnaddress. In questo modo, se l’attaccante lo avesse modificato, verrebbe nuovamente
sostituito con quello originale.

Limiti:
 Esecuzione di applicazioni multithread: non si sa quale thread termini prima, pertanto potrebbe
essere stato salvato nel registro esterno il returnaddress del thread sbagliato. Tuttavia, creare un
registro esterno per ogni thread sarebbe troppo costoso
 Esecuzione di funzioni ricorsive innestate

Stack non eseguibile

Stack non eseguibile (DEP – Data ExecutionPrevention): zona di memoria esclusivamente per i dati che non
può essere eseguita.

Codice polimorfico: ha bisogno di avere delle zone di dati che siano anche eseguibili. È possibile dare a
questo tipo di programmi dei permessi speciali.

Return-to-libc: DEP impedisce all’attaccante di eseguire il codice iniettato nello stack, ma non di modificare
il returnaddress. Pertanto l’attaccante può sostituirlo con l’indirizzo di memoria della routine di libreria di
sistema (LIBC) che gli serve, passando come parametri i valori che inserisce nello stack (non può eseguire,
ma può ancora scrivere).
20

In risposta a questo nuovo attacco è possibile limitare la libreria, caricando solo le funzioni che servono allo
specifico programma in esecuzione. Se l’attaccante avesse bisogno di una funzione che non serve al
programma, non potrebbe dunque puntare ad essa.

ROP (Return-Oriented Programming): anche se LIBC è limitata solo ad alcune funzioni, queste sono
composte da istruzioni. L’attaccante, invece di puntare all’inizio della funzione come in return-to-libc, può
saltare alla singola istruzione di cui ha bisogno, dopo di che può saltare ad un’altra e così via, fino a
comporre la funzione di cui ha bisogno. Queste funzioni si chiamano istruzioni gadget e terminano sempre
con una ret (serve per andare al returnaddress).

Tipi di architettura:
 RISC (ReducedInstruction Set Computer): architettura semplice e lineare. Es.: Android.
 CISC(Complete Instruction Set Computer): contiene istruzioni in grado di eseguire operazioni
complesse in una singola istruzione. Es.: Intel.
In questo tipo di architettura è possibile non solo saltare all’inizio di un’istruzione, ma anche in mezzo,
avendo così la possibilità di individuare ed utilizzare istruzioni disallineate non presenti nel set iniziale
(viene cambiato il valore semantico dell’istruzione)

Canarini
Canarini: sequenza di 4 byte che viene messa a protezione del returnaddress. Quando viene chiamata una
funzione il compilatore inserisce i suoi parametri all’interno dello stack e posiziona subito sotto al
returnaddress un canarino di valore casuale. Se l’attaccante fa un buffer overflow, per poter sovrascrivere il
returnaddress deve sovrascrivere anche il canarino, ma non ne conosce il valore (poiché è casuale). Quando
la funzione termina, sempre il compilatore controlla che il canarino attuale sia uguale a quello inserito
all’inizio. Solo se i valori corrispondono allora si procede con l’esecuzione.

Per poter utilizzare questa tecnica, il compilatore deve aggiungere due macroistruzioni e deve mantenere
una memoria temporanea dove salvare il canarino. Questa zona di memoria è considerata trusted (TCB).

ASLR (Address Space Layout Randomization)

 21

Gli attacchi buffer overflow e return-to-libc si basano sul fatto di conoscere l’indirizzo virtuale del codice nel
buffer o delle routine della libreria standard. È facile ottenere queste informazioni, poiché spesso si
utilizzano gli stessi indirizzi su molte macchine diverse.

ASLR: tecnica di randomizzazione degli indirizzi per far sì che gli indirizzi dello stack e delle routine di libreria
siano diversi per ciascuna macchina (sposta gli indirizzi di un certo offset).

Attacchi conseguenti a questo tipo di difesa:

 Brute force: si provano in continuazione degli indirizzi random differenti
 Sprayingattack: si riempie la memoria del processo dei pezzi di codice (shellcode) tutti uguali e si
sovrascrive il returnaddress con un valore casuale. Con grande probabilità questo indirizzo
corrisponderà ad una locazione di memoria in cui c’è lo shellcode, che verrà quindi eseguito.
Questo attacco è però piuttosto evidente, poiché genera un picco costante di allocazione di zone di
memoria.

Es. storico: PaX ASLR

Funzioni sicure
C è un linguaggio famoso per avere molte funzioni pericolose. Sarebbe dunque necessario rimpiazzarle con
funzioni che specificano in numero di byte o caratteri.

Es.: strcpy non controlla la dimensione dei buffer, ma può essere sostituita con strncpy.

Filtering
Gran parte degli attacchi software è dovuta al fatto che non viene fatto un giusto controllo degli input a
livello di codice. È possibile filtrare gli input per rendere più difficile inserire input volutamente pericolosi:
 Whitelisting: liste che specificano quali input sono permessi. Funziona bene quando si richiede un
input specifico.
 Blacklisting: liste che specificano quali input respingere (es.: caratteri speciali per l’inserimento di
codice).
 Taintanalysis: quando arriva un input da una sorgente non sicura lo si marchia. Se questo input accede
a qualche funzione critica per la sicurezza viene bloccata l’esecuzione. Il problema di questo tipo di
analisi è che rallenta parecchio il sistema.

Caratteri pericolosi possono essere sanitizzati usando delle codifiche sicure oppure tramite dei caratteri di
escape.

14. Crittografia
Introduzione
Crittografia: scienza che studia la scrittura segreta. In particolare studia tecniche matematiche relative alla
sicurezza delle informazioni (aggiunge confidenzialità ai dati).

Cryptoanalysis: scienza che studia i metodi con cui rompere la crittografia.

22

 Vecchio paradigma: due enti fidati vogliono comunicare tra di loro attraverso un canale non sicuro,
l’attaccante può leggere, cancellare ed inserire messaggi all’interno del canale. Con la crittografia i
due enti costruiscono un canale sicuro sopra una rete non sicura.
 Nuovo paradigma: i due enti comunicanti non si fidano l’un l’altro. Bisogna proteggere si da una frode
tra i due che da enti esterni alla conversazione. Per far ciò si richiede il controllo di una Trusted Third
Parties (TTP)
 Applicazione della legge: legge che regola come la polizia possa intercettare il traffico decriptato (può
chiedere la chiave crittografica)

Proprietà:
 Data confidentiality: gli algoritmi di cifratura nascondono il contenuto del messaggio
 Data integrity: funzioni che controllano che il messaggio non sia stato modificato
 Data originauthentication: gli algoritmi di firma digitale verificano la sorgente e l’integrità del
messaggio (un messaggio modificato non arriva più dalla sorgente originale)

La crittografia rinchiude i segreti in una cassaforte e per aprirla è necessaria una chiave.

Principio di Kerckhoff: gli algoritmi di cifratura non sono mai segreti, ma lo sono le chiavi (sono le chiavi che
vanno protette).

Shiftingproblem: il problema prima era che le comunicazioni avvenivano su un canale non sicuro, ora invece
i canali sono sicuri, ma è necessario proteggere le chiavi di cifratura.

Tipologie di sistemi crittografici:

 Sistema simmetrico: c’è una chiave unica che deve essere condivisa tra le entità che vogliono
comunicare. È molto veloce, ma c’è il problema di trovare un modo sicuro per scambiare la chiave.
 Sistema a chiave pubblica/privata: più lenta, ma non c’è bisogno di scambiarsi la chiave.

Funzioni di controllo dell’integrità

La crittografia è basata sulle hashfunction: per proteggere un programma x si calcola la hashh(x) e la si salva
dove non può essere modificata. Il calcolo della hash non richiede informazioni segrete.

Es.: quando si effettua il login si invia la password in chiaro. A questa viene applicata la funzione hash e
viene confrontata con il valore contenuto nel file /etc/shadow.

Le funzioni hash sono dette anche funzione one-way:

 Sono facili da calcolare
 Applicano algoritmi di compressione
 Pre-image resistance: dato un valore y, è computazionalmente impossibile trovare una x tale che
h(x)=y

Un attaccante potrebbe però cambiare un programma x in x’ maligno in modo tale che h(x’)=h(x). In questo
caso si dice che c’è una collisione tra gli input x e x’. Pertanto, la protezione dell’integrità necessita di
funzioni hash che siano collision-resistant:
 2nd pre-image resistance (weakcollisionresistance): dato un input x e la sua h(x), è
computazionalmen-te impossibile trovare un altro input x’≠x tale che h(x)=h(x’)
 23

 Collisionresistance (strong collisionresistance): è computazionalmente impossibile trovare due input x

e x’, con x’≠x, tali che h(x)=h(x’)

ManipulationDetection Code (MDC): utilizzati per individuare le modifiche di un documento. Ne esistono di

due tipi:
 One-Way HashFunction (OWHF): facili da calcolare, fanno compressione, pre-image resistance e 2nd
pre-image resistance
 CollisionResistantHashFunction (CRHF): facili da calcolare, fanno compressione, 2nd pre-image
resistance e collisionresistance

Il core di una funzione hash è la funzione di compressione f che funziona su input di dimensione fissa. Un
input x di lunghezza arbitraria viene suddiviso nei blocchi 𝑥1 , …, 𝑥𝑚 della dimensione degli input di f
(l’ultimo blocco deve essere riempito con dei bit cuscinetto). A questo punto si applica la funzione di
compressione: sia ℎ0 un valore iniziale fissato, si calcola ℎ𝑖 = 𝑓(𝑥1 ||ℎ𝑖−1 ) per i=1, …, m(il simbolo || sta per
concatena-zione).ℎ𝑚 sarà infine il valore hash di x.

Message Authentication Code (MAC): famiglia di funzioni ℎ𝑘 (𝑥) che vengonocalcolate dati due input: il
messaggio x e la chiave k(funzione hsah autenticata). Per verificare il messaggio, la chiave deve essere
condivisa tra mittente e destinatario. Un MAC deve inoltre avere le seguenti proprietà:
 Facile da calcolare
 Compressione
 Computatonresistance: per ogni valore di k, data una o più coppie (𝑥𝑖 , ℎ𝑘 (𝑥𝑖 )), è
computazionalmente impossibile calcolare ℎ𝑘 (𝑥) per ogni nuovo input x.

Un algoritmo MAC può essere derivato da un algoritmo MDC h usando il costrutto HMAC: per ogni chiave k
e per ogni messaggio x, si calcola 𝐻𝑀𝐴𝐶(𝑥) = ℎ(𝑘||𝑝1 ||ℎ(𝑘||𝑝2 ||𝑥)) dove 𝑝1 e 𝑝2 sono stringhe di bit
(padding) che estendono k per farla arrivare alla dimensione di un blocco nella funzione di compressione f.

Firma digitale
I meccanismi di firma digitale hanno 3 componenti:
 Generazione delle chiavi
 Procedura di firma (privata)
 Procedura di verifica (pubblica)

L’utente A utilizza la chiave privata per firmare il documento m e fornisce la chiave pubblica all’utente B
perché B possa controllare la firma sul documento m che ha ricevuto. Chiunque abbia la chiave pubblica
può verificare che il messaggio sia inviato da colui che possiede la chiave privata.
24

Entrambi gli enti possiedono la chiave pubblica di tutti e due, inoltre ognuno possiede la sua chiave privata.
A invia a B il documento M firmato con la sua chiave privata, quindi PrA (M) e B può verificarlo con la chiave
pubblica di A: PA (PrA (M)) = M.

Man In The Middle (MITM): un attaccante potrebbe intercettare l’invio della chiave pubblica di A,
sostituen-dola con la sua (PATK ), e fare lo stesso con la chiave pubblica di B. Ora sia A che B hanno la chiave
pubblica dell’attaccante, ma pensano di avere quella l’uno dell’altro. Pertanto, se A invia un documento
firmato a B, in realtà lo invia all’attaccante, che può sostituirlo con il suo, firmarlo con la sua chiave ed
inviarlo a B, che penserà di averlo ricevuto da A.

Per risolvere questo problema si utilizzano dei certificati digitali, i quali contengono le chiavi pubbliche dei
due interlocutori e sono firmati da una trusted authority.

RSA (Rivest, Shamir, Adleman): algoritmo di generazione delle chiavi basato sulla scelta di due numeri
primip e qmolto grandi e distanti tra loro. Le chiavi sono:
 Chiave privata: un intero d tale che mcd(d, p-1)=1 e mcd(d, q-1)=1
 Chiave pubblica: un intero n=p∙q ed un esponente e tale che e∙d=1 modmcm(p-1, q-1)

MAC e firma digitale sono meccanismi di autenticazione.

Cifratura
Cifratura: protezione della confidenzialità dei dati.
 Cifratura: un testo in chiaro x viene convertito in un testo cifrato attraverso una chiave K
 Decifratura: utilizzando la chiave K è possibile ricavare il testo in chiaro da quello cifrato y

Si distingue in due tipi di cifratura:

 Cifratura simmetrica: la chiave è la stessa per cifratura e decifratura
 Cifratura asimmetrica: le chiavi sono diverse ed è computazionalmente impossibile ricavare la chiave
privata di decifratura dalla corrispondente chiave pubblica di cifratura

La cifratura simmetrica è più efficiente, ma ha il problema di dover scambiare la chiave. Essendo la chiave
un valore molto piccolo rispetto a tutto il documento allora è possibile scambiare solo quella con una
cifratura asimmetrica senza perdere troppo in performance.

A e B devono condividere la loro chiave condivisa K per potersi inviare messaggi cifrati. A invia quindi la
chiave utilizzando la chiave pubblica di B (PB (𝐾)) e B potrà decifrare il messaggio utilizzando la sua chiave
privata: PrB (PB (𝐾)) = 𝐾.L’attaccante non può decifrare il messaggio (non conosce K), ma può sostituire il
 25

messaggio contenente la chiave condivisa con la sua chiave 𝐾ATK , inviando PB (𝐾ATK ) (conosce la chiave
pubblica di B). Per evitare ciò è necessario che A firmi il messaggio con la sua chiave privata: PrA (PB (𝐾)). In
questo modo A certifica di essere A ed il messaggio può essere letto solamente da B.

Diffie e Hellman: schema che permette di scambiare la stessa chiave simmetrica senza usare chiave
pubblica e privata.

Due tipi di algoritmi:

 A blocchi (block): vengono cifrate delle sequenze di blocchi di dati piuttosto grandi senza cambiare la
chiave. La sicurezza si concentra sul design di funzioni di cifratura.
 A flusso (stream): vengono cifrate delle sequenze di blocchi piccoli dopo di che si cambia chiave. La
sicurezza di concentra sul design del generatore di chiavi, anche se la cifratura è piuttosto semplice.

Problema delle chiavi asimmetriche: come si fa ad ottenere la chiave pubblica dell’ente a cui voglio
mandare un messaggio? Esistono dei server appositi per la verifica e l’autenticazione delle chiavi (Public
KeyInfrastructure - PKI).

17. Network Security

Botnet: aggregato di macchine compromesse collegate con una sottorete e controllate da un attaccante.

Un attaccante può fare le seguenti azioni:

 Leggere messaggi
 Applicare tecniche di spoofing (falsificazione dell’identità)
 Tentare di indovinare i campi di un messaggio che non può vedere

Attacchi TCP
TCP three way handshake:
1. Il mittente invia un flag SYN ed un valore casuale x(numero di sequenza del mittente)
2. Il destinatario risponde anche lui con un SYN ed un ACK più i valori x+1 (per indicare che il prossimo
segmento che si aspetta di ricevere) e y (numero di sequenza del destinatario)
3. Il mittente risponde con un ACK, y+1 (prossimo segmento che si aspetta) e x+1 (numero di sequenza
del nuovo segmento)

TCP Session Hijacking

1. L’attaccante inizia la connessione cambiando il suo indirizzo sorgente (spoofing) con uno trusted dal
computer vittima (poiché sta nella sua stessa sottorete, quindi non ne richiede l’autenticazione), invia
quindi un segmento TCP con flag SYN alzato ed un valore x
2. La vittima riceve il messaggio ed invia la risposta non all’attaccante, ma al computer cui l’attaccante
ha rubato l’identità
26

3. Nonostante l’attaccante non veda la risposta, può provare lo stesso ad indovinare il valore y (ha dietro
delle regole che lo rendono meno casuale di quanto dovrebbe) ed invia il terzo messaggio di
connessione con questo valore

Se il valore di y è stato indovinato, la vittima pensa di aver iniziato una connessione sicura con un host
fidato quando in realtà sta comunicando con l’attaccante. L’attaccante non può ricevere messaggi (vengono
inviati al vero computer fidato), ma può comunque inviare comandi alla vittima con i privilegi del computer
a cui ha rubato l’identità.

TCP SYN Fload

L’attaccante invia un messaggio di sincronizzazione alla vittima, sempre con un indirizzo non suo tramite
spoofing. Quando alla vittima arriva il messaggio, questa crea una struttura di memoria dove mantiene i
numeri di sequenza x e y (più altre informazioni), dopo di che invia la risposta. L’attaccante continua quindi
a mandare sempre il messaggio di sincronizzazione, cambiando il numero di sequenza, e la vittima continua
ad allocare zone di memoria finché non la satura e non è più in grado di iniziare una conversazione (denial
of service).

In C non esistono funzioni per fare solo la SYN iniziale, ma fanno direttamente tutte e 3 le connessioni.

SYN cookie: la memoria con le informazioni necessarie viene allocata solo dopo al three way handshake,
quando la macchina sa di star comunicando con qualcuno di reale. Tuttavia c’è bisogno di quelle
informazioni anche prima, allora vengono mando cifrate in piggybacking e, se arrivano all’interlocutore
reale, verranno rimandate indietro sul terzo messaggio e il computer sarà in grado di decifrarle (poiché
conosce la chiave, visto che l’ha creata lui).

Attacchi DNS
DNS: servizio essenziale per il funzionamento di Internet, poiché permette di risolvere i nomi in indirizzi IP e
vice versa.

L’infrastruttura DNS comprende:

 13 root server: contengono al loro interno tutti i nomi dei top level domain server
 Global Top Level Domain (GLDT) server: corrispondono ai domini di primo livello (es.: .com, .net, …)
 Authoritativename server: mappano gli hostname e gli indirizzi IP della loro zona
 Recursive name server: primi server che vengono contattati dai client quando questi devono risolvere
un indirizzo
 27

Ogni name server mantiene una cache ed ogni volta che gli viene fatta una richiesta controlla prima nella
cache se già possiede la risposta. Le risposte rimangono nella cache per un tempo definito dal campo time-
to-live (TTL) definito dal mittente.

Ogni volta che si fa una richiesta viene generato un QID (numero di sequenza) in modo tale da potervi
associare una risposta. Se il QID della risposta che arriva non corrisponde a nessuno dei QID delle domande
inviate, la risposta viene scartata.

Un attaccante potrebbe voler sostituire il suo indirizzo IP con quello di un nome simbolico molto usato, così
che gli utenti si connettano al suo sito invece di quello richiesto (l’utente si fida del sito ritornato dal DNS).
Ciò rende il DNS un protocollo tanto sensibile quanto pericoloso.

Debolezze del protocollo:

 L’unica autenticazione che si ha delle risposte che si ricevono è data dal QID. Se l’attaccante riuscisse
ad indovinarlo potrebbe inviare come risposta ad una richiesta di risoluzione di un nome il proprio
indirizzo IP prima che arrivi la risposta del server autoritativo. Il name server, vedendo che il QID è lo
stesso della sua richiesta, inoltra la risposta al client.
 Cache poisoning: se l’attaccante riuscisse ad inviare il suo indirizzo ed a farlo accettare dal name
server, questo verrebbe salvato all’interno della cache e vi rimarrebbe fino allo scadere del TTL. In
questo tempo accadrebbe che chiunque cerchi di connettersi al dominio il cui valore è stato falsificato
nella cache si connetterebbe in realtà al sito dell’attaccante.

È importante generare dei QID che siano il meno possibile predicibili.

L’attaccante potrebbe inoltre cercare di rallentare il server autoritativo generando un DoS, in mondo tale
da aumentare le probabilità che la sua risposta arrivi prima di quella autentica.

Dan Kaminski’s Attack

L’attaccante invia al recursive server una richiesta per l’indirizzo ‘random.foo.com’. Questo è un indirizzo
inesistente, poiché non si vuole che sia già presente nella cache, quindi il recursive server deve inoltrare la
richiesta agli altri server. Ora l’attaccante vuole inviare la risposta prima dei server autoritativi, ma non
conosce il QID, pertanto continua ad inviare messaggi provando con tanti QID diversi e, se riesce a trovare
quello giusto prima che arrivi la risposta reale, il suo indirizzo viene salvato all’interno della cache del
recursive server.

Tuttavia nessuno andrà mai a cercare l’indirizzo random.

28

Ogni volta che viene inviata una risposta si mandano anche altre informazioni, tra cui l’indirizzo del server
di riferimento (serve per velocizzare la ricerca nel caso si presenti una nuova richiesta per un determinato
dominio, in questo modo si evitano tutte le richieste ai server intermedi). Ciò che fa l’attaccante è, quindi,
inviare insieme alla risposta l’indirizzo del server DNS salvato sul suo computer. In questo modo, tutte le
richieste che verranno fatte per il dominio ‘foo.com’ saranno in realtà inoltrare al server DNS
dell’attaccante.

Contromisure:
 Fare le varie richieste su varie porte, in questo modo l’attaccante non solo deve indovinare il QID, ma
anche il numero di porta
 Restringere l’accesso ai local recursive name server
 Eseguire controlli d’accesso per prevenire la sovrascrittura non autorizzata di dati autoritativi
 DNSSec: autenticazione crittografica attraverso firma digitale

DNS Rebinding Attack

Sameorigin policy (proprietà di sicurezza): uno script web può essere collegato solo al server da cui è stato
scaricato.

L’attaccate crea un nuovo dominio (es.: attacker.org). Per far ciò deve fare una richiesta ad un’autorità e,
una volta accettata, il dominio viene automaticamente aggiunto ai DNS. Tra le varie opzioni è possibile
associare al dominio diversi indirizzi IP ed assegnare loro un time-to-live, scaduto il quale l’indirizzo IP
cambia. Gli indirizzi che l’attaccante associa al suo dominio (con TTL breve) sono il suo e quello del suo
target. Quando la vittima visita la pagina, scarica anche uno script malevolo che attende la scadenza del TTL
prima fare di connettersi ad attacker.org. Scaduto il TTL, il dominio non è più connesso al computer
dell’attaccante, ma a quello della vittima, pertanto lo script può essere eseguito dato che non infrange la
sameorigin policy.

Firewall
Sistema di prevenzione: filtra il traffico che può entrare nel sistema (filtro in ingresso) e quello che può
uscire dal sistema (filtro in uscita). Le decisioni di controllo degli accessi sono basate su informazioni come
l’indirizzo ed il numero di porta.

In genere, il firewall viene installato tra la rete di un’organizzazione ed Internet, in questo modo tutto il
traffico da e per la rete privata deve passare attraverso il firewall.

Tipi di firewall:
 29

 Packetfilter: controlla gli header dei pacchetti IP ed il numero di porta di TCP ed UDP e decide,
secondo delle regole specifiche, quali pacchetti lasciar passare e quali no. Le regole controllano il
traffico in entrambe le direzioni.
 Statefulpacketfilter: packetfilter che capisce richieste e risposte (es. in TCP: SYN, SYN-ACK, ACK). Le
regole specificano solo i pacchetti in una direzione, dopo di che le risposte vengono processate
automaticamente.

Politiche di firewall (una politica di firewall è un insieme di regole):

 Permissivi: di default permettono ai pacchetti di entrare, le regole specificano chi deve essere
bloccato
 Restrittivi: di default bloccano i pacchetti, le regole definiscono chi può passare (più sicuro)

Un firewall può bloccare solo il traffico che passa attraverso esso, pertanto deve essere posizionato in
maniera attenta.

Es.: dove posizionare il mail server? Bisogna controllare le mail che arrivano dall’esterno, quindi deve
essere all’interno della zona protetta. Bisogna però controllare anche ciò che arriva dalla rete, quindi deve
trovarsi anche all’esterno.

Soluzione: DMZ (perimeter network) contenete i server, in modo tale da controllare il flusso sia in ingresso
che in uscita attraverso due firewall.

Limiti dei firewall:

 I firewall non proteggono dai problemi interni alla rete
 Bloccare i servizi potrebbe creare problemi per gli utenti
 Alcuni protocolli sono più difficili da supportare
 Protocoltunnelling: inviare dati di un protocollo attraverso un altro protocollo per evitare i firewall
(es.: la porta 80 viene spesso lasciata aperta, quindi molti protocolli fanno tunnelling attraverso http)
 Non è possibile esaminare e filtrare il traffico criptato

IntrusionDetectionSystem (IDS)
Due principali approcci per fare detection:
 Knowledge-based (misusedetection): hanno un database di pattern che indicano un comportamento
sospettoso che potrebbe indicare pericoli (es.: un numero molto alto di tentativi di login falliti su un
host sensibile).
Questo tipo di sistema non è però in grado di individuare nuove tipologie di attacco, poiché non
presenti nel database. Tali dovrebbero quindi essere costantemente aggiornati, diventando talmente
grandi da rendere lento il sistema IDS.
30

 Behaviour-based (anomalydetection): cercano di stabilire quale sia il comportamento normale del

sistema, collezionano poi dei dati statistici per capire quanto il sistema si distacchi dal
comportamento base. Quando una determinata soglia viene superata, allora genera un allarme.
È possibile che vengano generati dei falsi positivi (si riscontrano degli attacchi quando in realtà non ce
ne sono) o dei falsi negativi (non vengono individuati degli attacchi perché il loro effetto viene
percepito come comportamento normale).

Architettura IDS: set di sensori distribuito in modo da ottenere dati connessi ad una console centrale che
gestisce i sensori, analizza i dati e riporta le anomalie. Bisogna proteggere tutta l’infrastruttura, altrimenti
un attaccante potrebbe manipolarla per non far rivelare un suo possibile attacco.

Tipi di IDS:
 Network-based IDS (NIDS): controllano eventuali attacchi nel traffico di rete (analisi in tempo reale)

 Host-based IDS (HIDS): controllano eventuali attacchi nei file di log degli host

Esistono degli attacchi che possono essere individuati dai NIDS ma non dagli HIDS (es.: SYN flood) e vice
versa (es.: Trojan login script). L’ideale sarebbe quindi combinare i due tipi di IDS.

Honeypot
Per scoprire nuovi attacchi è possibile mettere online dei sistemi appositi che fanno finta di essere dei
sistemi contenenti dati sensibili al fine di attirare gli attaccanti, ma in realtà tali dati sono falsi. Questi
sistemi vengono tenuti sotto controllo per vedere se qualcuno cerca di attaccarli in qualche modo.

Honeypot: tecnologia per tracciare, apprendere e raccogliere informazioni sulle attività degli hacker.

Livelli di coinvolgimento:
 Low interaction: monitorano semplicemente le porte
 Midinteraction: programmi che emulano sistemi operativi e servizi
 High interaction: veri e propri computer, applicazioni o servizi

Al crescere del livello di interazione cresce anche la qualità delle informazioni che si possono ottenere, ma
sono sistemi più complessi da realizzare.

Honeynet: rete di honeypot.

 31

Honeywall: honeynet comprensiva anche di firewall e IDS

16. Communications Security

Threat model
L’attaccante ha accesso al canale di comunicazione tra due end point: può sia vedere che modificare i
messaggi.

Un attaccante può essere:

 Passivo: ascolta solamente il traffico.
- Sniffing: l’attaccante è interessato al contenuto del messaggio
- Trafficanalysis: il traffico viene analizzato al fine di identificare dei pattern di comunicazione
 Attivo: interviene modificando i messaggi o inserendo nuovi messaggi
- Spoofing: l’attaccante falsifica l’indirizzo del mittente
- Flooding: vengono inviati moltissimi messaggi alla vittima
- Squatting: l’attaccante finge di trovarsi nella posizione della vittima

Securetunnels
Secure tunnel: connessione logica sicura tra due end point all’interno di una rete non sicura.

I tunnel sicuri sono costruiti nel seguente modo: un protocollo stabilisce un segreto tra le due entità e
successivamente vengono derivate delle chiavi simmetriche dal segreto condiviso. Tutto il traffico
successivo sarà protetto da queste chiavi.

Vengono utilizzati algoritmi asimmetrici costosi solo per lo scambio della chiave, dopo di che la
comunicazione vera e propria viene fatta con algoritmi simmetrici (che usano la chiave scambiata in
precedenza) in maniera tale da essere più veloce.

Replyattack: l’attaccante può osservare i pacchetti ma non può cambiarne il contenuto (integrità), allora li
salva sulla propria macchina per poi reinviarli. Per evitare questo tipo di attacco si utilizzano i nonces,
ovvero dei numeri casuali che permetto di identificare se un messaggio è vecchio oppure nuovo.

IPsec
IPsec è uno standard che fornisce sicurezza a livello rete (non è necessario riscrivere o modificare le
applicazioni). È opzionale per IPv4, ma obbligatorio per IPv6.

Ha due modi di funzionamento:

 Transport mode: gli host sono consapevoli di comunicare con IPsec (sicurezza host-to-host). L’host
che genera il messaggio aggiunge direttamente l’header di IPsec e l’host destinatario sa interpretarlo.
32

 Tunnel mode: gli host non sanno di star comunicando con IPsec. Il mittente crea un pacchetto IP
normale e lo invia. Questo arriva poi al gateway, il quale si occupa di cifrare l’intero pacchetto e di
metterlo come payload di un pacchetto IPsec (incapsulamento), dopo di che lo invia nella rete. La
comunicazione tra host e gateway resta però in chiaro.

Ci sono due modalità in cui il pacchetto può essere costruito:

 AH (AuthenticationHeader): protocollo più vecchio, non viene quasi più utilizzato.
- Data integrity
- Data originauthentication
- Previene lo spoofing degli indirizzi IP (indirizzi IP autenticati)
- Crea un canale statefull usando numeri di sequenza (numeri di sequenza autenticati)
 ESP (Encapsulation Security Payload): protocollo più giovane.
- Payloadconfidentiality
- Data originauthentication
- Data integrity
- Payloadauthentication
- Cifratura simmetrica basata su chiavi condivise dagli end point

ESP
Quando si utilizza ESP vengono aggiunti al datagramma IP un header ed un tailer specifici:
 Header:
- SPI (Security Parameter Index): identifica quale algoritmo e quale chiave si devono utilizzare
- Numero di sequenza
 Tailer:
- Padding necessario all’algoritmo di cifratura
- Lunghezza del padding
- Dati di autenticazione: serve per poter fare un check di integrità
 33

ESP può essere utilizzato in due modi:

 In transport mode (host-to-host): in genere il pacchetto di un protocollo di livello superiore (es.: TCP o
UDP) viene incapsulato all’interno di un pacchetto IP per essere inviato. In transport mode l’host è
consapevole di star utilizzando IPsec, quindi costruisce il pacchetto in maniera differente. Il pacchetto
di livello superiore viene incapsulato all’interno di ESP, dopo di che viene aggiunto in testo lo header
IP originale.

 In tunnel mode:l’host invia il pacchetto IP standard. Il gateway incapsula l’intero pacchetto all’interno
di ESP ed aggiunge poi in testo lo header IP esterno (viene ulteriormente incapsulato in un pacchetto
IP)

MAC scope: l’attaccante non può cambiare i dati (autenticazione).

Encryption scope: l’attaccante non può vedere il contenuto (cifratura).

IPsec Security Association (SA): associazione unidirezionale tra mittente e destinatario.Al fine di tener
traccia di tutte le SA attive, si utilizza un apposito database, chiamato SAD (Security Association Database),
che mantiene, per ciascuna SA, le seguenti informazioni:
 Gli indirizzi IP dei peer coinvolti nella comunicazione
 Il protocollo che verrà utilizzato per il tunnel (AH o ESP)
 L’algoritmo di cifratura e la chiave
 L’SPI (Security Parameter Index), che viene inserito nello header ESP

Più SA possono essere combinate tra loro, ad esempio, in caso si debbano innestare multipli livelli di tunnel
IPsec. Ogni tunnel può iniziare/finire in un gratewayIPsec diverso lungo la rotta.

Es.: due host remoti hanno accesso ad un gateway. Il traffico dall’host al server viene protetto da un tunner
interno. Il traffico su Internet viene protetto da un tunnel esterno.
34

IKE
IKE (Internet Key Exchange): protocollo per lo scambio di chiavi su Internet. Viene utilizzato da IPsec per
scambiare, tra i due host, un segreto dai quale poi è possibile derivare la chiave necessaria per instaurare
un canale sicuro tramite SA.

DoS (Denial-of-Service): l’attaccante manda un messaggio finto alla vittima, la quale fa operazioni di
crittografia molto costose (es.: controllo della firma digitale). Gli attacchi DoS non possono essere evitati,
ma è possibile mitigarne gli effetti creando dei protocolli tali per cui il costo delle operazioni che fa
l’attaccate sia comparabile con il costo delle operazioni della vittima.

DoS su IKE(contro chi inizia la conversazione): il mittente invia un IKE_SA_INIT per iniziare ad accordarsi sul
segreto, l’attaccante risponde allora con un messaggio finto. La vittima, ricevendo il messaggio
dell’attaccante, creerà una la SA e la chiave che ne ricava, che tuttavia non saranno utilizzabili ed IKE fallirà.
Contromisura: l’iniziatore accetta molteplici risposte al suo primo messaggio e, all’arrivo di una risposta
valida, scarta tutte le altre.

DoS su IKE (contro il destinatario della conversazione): alla richiesta di apertura di una sessione la macchina
crea una struttura di memoria iniziale dove salvare i dati che le servono. Se l’attaccante continua ad inviare
richieste finte (flooding), prima o poi la memoria del destinatario si satura.
Contromisura: utilizzare un meccanismo stateless attraverso l’utilizzo di cookie.

Il protocollo IKE utilizza UDP.

Security Policy
È possibile definire delle regole di filtraggio dei pacchetti (es.: un host consapevole di IPsec deve sapere
quando scartare un determinato pacchetto). Tali regole sono salvate all’interno di un Security Policy
Database (SPD). Ogni volta che arriva un pacchetto, i suoi campi vengono confrontati con le entry del SPD
per vedere se coincidono ed in tal caso viene identificata una Security Association (SA).

NAT
NAT (Network AddressTranslation): sistema per mascherare più indirizzi privati su un unico indirizzo
pubblico.

NAT dovrebbe essere trasparente a tutte le applicazioni, ma in realtà non è così:

 AH è incompatibile con NAT, poiché fa autenticazione sull’indirizzo IP.
 Il calcolo del checksum di TCP include l’indirizzo IP contenuto nello pseudo header, ma NAT lo
modifica, rendendo invalida la verifica del checksum. Si utilizza allora il NAT Trasversal (NAT-T):
aggiunge un header UDP che incapsula lo header ESP.

SSL/TLS
 35

SSL (SecureSocketLayer) e TLS (TransportLayer Security) sono protocolli largamente utilizzati nel web per
supportare l’e-commerce sicuro su http (HTTPs).

Le applicazioni devono essere consapevoli di star usando SSL (cifratura end-to-end).

Architettura a due livelli:

 SSL handshakeprotocol: promette ai due enti di autenticarsi a vicenda e di negoziare un algoritmo di
cifratura ed un segreto condiviso (dal quale poi verranno ricavate le chiavi)
 SSL record protocol: utilizzato per incapsulare i dati provenienti dai livelli superiori (comunicazione
vera e propria)

Sessione: creata dal protocollo handshake, definisce il set di parametri crittografici (cifratura, funzione
hash, segreto master e certificati). Al suo interno possono esserci più connessioni per questioni di
efficienza.

Connessione: definita dai nonces. Le chiavi vengono derivate da un singolo segreto master creato durante
la fase di handshake (si utilizza una chiave diversa per ogni connessione).

Handshakeprotocol:
1. Il client invia ‘hello’: inizia la connessione.Invia la sua versione del protocollo, il client nonce (numero
random) e propone una lista di suite di cifratura per la generazione delle chiavi
2. Il server risponde al saluto ed invia il certificato firmato da un’autorità (comprensivo della catena di
certificati che validano quello in uso).Invia inoltre la sua versione del protocollo, il server nonce e la
suite di cifratura scelta tra quelle proposte dal client. Finito di inviare tutto avvisa di aver concluso con
la fase di ‘hello’.
3. Il client invia il segreto master utilizzando la chiave pubblica del server (che ha ottenuto dal certificato
del server) ed indica di star cambiando la suite di cifratura che utilizzerà in questa sessione. Alla fine
dichiara di aver terminato.
4. Il server utilizza il segreto master per ricavare la chiave simmetrica (solo lui possiede la chiave privata
per decifrarlo), indica anche lui di star cambiando cifratura e manda il messaggio di fine.

Il client non si autentica mai: non interessa poiché è il client a chiedere i servizi del server e quindi è lui che
deve essere sicuro di starsi connettendo al server giusto.

Applicazioni di SSL: e-commerce sicuro. SSL permette di utilizzare un canale sicuro per inviare le
informazioni della propria carta di credito. L’autenticazione del client viene fatta quando inserisce il pin
della carta di credito.

Attacchi:
 Flame: malware che crea certificati basati sulla collision
 Hearthbleed: buffer overflow in cui l’attaccante riesce a prendere la zona di memoria del browser
contenente le chiavi
36

EAP
EAP (ExtensibleAuthenticationProtocol): definisce protocolli di autenticazione al livello di flussi di messaggi
astratti chiamati metodi. I metodi possono essere implementati utilizzando una varietà di meccanismi
sottostanti.

Le applicazioni ed il protocollo di autenticazione vedono solo un flusso astratto di messaggi. Pertanto il

meccanismo di autenticazione può essere scelto indipendentemente dall’applicazione e può essere
cambiato senza necessità di riscrivere l’applicazione.

Flusso di messaggi generico:

I messaggi EAP generici scambiano le identità ed incapsulano messaggi di protocolli di autenticazione.

Questi protocolli sono detti metodi e provvedono almeno all’autenticazione in un verso.

EAP Tunnelled TLS (EAP-TTLS): un client si connette ad un server certificato utilizzando TLSper stabilire un
tunnel sicuro. Gli utenti si autenticano attraverso una password.

Algoritmo asimmetrico basato sulle chiavi del server

per verificare l’identità del server e creare il tunnel di
cifratura simmetrica

Verifica dell’identità del client attraverso l’invio della

password all’interno del tunnel

18. Web Security

Introduzione
Due vettori di attacco principali:
 E-mail
 Browser

Web 1.0
Web 1.0: nasce per condividere elementi (pagine statiche) in rete attraverso i link.
 37

 Il browser invia una richiesta HTTP al server.

 Il server riceve la richiesta, ricerca la risposta all’interno di un sistema back-end ed infine restituisce la
pagina HTML al client.

HTTP è un protocollo di trasposto (a livello applicazione) che possiede due metodi principali per eseguire
una richiesta:
 GET: richiede una risorsa al web server. Una risorsa è identificata da una URI (Uniform Resource
Identifier) che è il percorso di tale risorsa all’interno del server. Alla fine della URI può esserci anche
una query contenente alcuni dati.
Es.:

 POST: richiede una risorsa attraverso una URI ed invia contemporaneamente dei dati (pensato per
mandarne di più rispetto ad una query GET).

Attacco: l’attaccante crea un hostname contenente un carattere che somiglia ad uno slash. Un utente che
invia al browser la stringa pensa che l’hostname sia quello che precede il falso slash, ma in realtà non è così
e si collega al sito dell’attaccante invece di quello che voleva veramente.

Difesa: è possibile bloccare caratteri pericolosi oppure mostrare all’utente in che punto il browser divide
l’hostname dalla URI.

Le risposte che il server invia al client sono delle pagine HTML (ovvero delle pagine web) e vengono
mandate attraverso HTTP. Spesso alle pagine HTML sono associati dei fogli di stile in CSS che danno
informazioni su come visualizzare la pagina. Nelle versioni successive del web si è aggiunta la possibilità di
inviare, insieme alla pagina HTML, anche degli script in JavaScript o in altri linguaggi di scripting lato client.
Tali non hanno la facoltà di agire su tutto il sistema, pertanto sono eseguiti all’interno di sandbox.

DOM (Document Object Model): rappresentazione della pagina web utilizzata dai browser (necessaria per il
JavaScript). È una struttura di memoria che salva al suo interno tutte le informazioni relative alla pagina
attuale (es.: document.body contiene tutto l’HTML della pagina, document.URL salva l’URL della pagina e
così via).

Thread model
L’attaccante può vedere solo i messaggi che gli arrivano ed i dati ottenuti da end system compromessi
acceduti attraverso il browser. L’attaccante potrebbe anche cercare di indovinare dei campi predicibili
all’interno di un messaggio che non può vedere.

Sessioni
38

Con l’avvento dell’e-commerce si è reso necessario mantenere lo stato di una sessione di lavoro. È possibile
fare delle sessioni autenticate grazie a TLS.

La prima volta che un client si connette ad un server, quest’ultimo genera un cookie (numero random
identificativo della sessione di un utente - SID), lo salva in un suo database e lo invia al client insieme alla
risposta. Quando il client lo riceve, lo salva nel browser. La prossima volta che accede al sito, invia con la
richiesta il cookie che aveva salvato, il server lo confronta con quelli contenuti nel suo database e, se trova
un match, ripristina la sessione (sa che conosce il client). I cookie vengono salvati anche nel DOM:
document.cookie.

I cookie possono essere utilizzati per identificare gli utenti, così che non sia necessario richiedere loro
username e password per autenticarsi ad ogni connessione.

Cookie poisoning: se l’attaccante riuscisse a prendere il cookie di un altro utente, allora sarebbe in grado di
connettersi al sito come tale utente senza bisogno di conoscere username e password. Un attaccante
potrebbe cercare di indovinare un cookie, oppure rubarlo dal client o dal server. È quindi necessario far sì
che i coockie non siano predicibili e che vengano salvati in posti sicuri.

Man-in-the-middle attack: in uno scenario EAP-TTLS all’inizio si crea una sessione in cui il server si autentica
al client, dopo di che si crea un tunnel per far sì che anche il client si autentichi al server. L’attaccante
potrebbe però ingannare il client, inducendolo a creare una sessione TLS con lui invece che con il server.
L’attaccante crea poi anche lui una connessione TLS, ma verso il server. Il server invia all’attaccante la
richiesta delle credenziali dell’utente, che viene poi inoltrata al client. Questo risponderà con le sue
credenziali, ma non al server, bensì all’attaccante che le userà per autenticarsi al server e riceverà come
risposta il cookie. L’attaccante può ora impersonificare l’utente.

Difesa: il server può controllare se le credenziali sono state inviate nella stessa sessione in cui lui è stato
identificato dall’utente. Se è così allora sa di star comunicando con lo stesso end system, altrimenti
potrebbe essere in atto un attacco. L’attaccante potrebbe però intercettare anche la prima connessione,
così risulterebbe sempre lo stesso autore dei messaggi.

In risposta a questo nuovo attacco sono state cambiate le specifiche di TLS per la negoziazione della
sessione: tutte le sessioni sono connesse tra loro tramite crittografia.

SameOrigin Policy
Sameorigin policy: tutti gli script che vengono ricevuti da un determinato sito si possono collegare solo a
quel determinato sito. Uno script può quindi accedere solo ad un determinato dominio e non può, ad
esempio, richiedere i cookie di altri.

Due pagine hanno la stessa origine se condividono il protocollo, il dominio ed il numero di porta.
 39

La sameorigin policy può però essere troppo restrittiva in determinati casi, quindi vengono concesse delle
eccezioni.

Parent Domain Traversal (PDT): i nomi di dominio possono essere accorciati eliminando la prima parte (es.:
www.my.orgpuò essere accorciato a my.org). Questo potrebbe essere un problema per determinati
domini, pertanto vengono salvate delle eccezioni all’interno del browser e vengono controllate nel
momento di esecuzione dello script.

Cross Site Scripting (XSS)

Obiettivo dell’attaccante: rubare il cookie di un utente. L’attaccante inserisce uno script malevolo
all’interno di una pagina che il server invia alla vittima (non viola la sameorigin policy), così che il browser lo
esegua e possa recuperare i cookie da inviare poi all’attaccante.

Due diversi tipi di cross site scripting:

 Reflected XSS: l’attaccante deve indurre la vittima a clickare sul suo link
 Stored XSS (+ variante): non c’è più necessità di inviare il link alla vittima

ReflectedXSS
1. L’attaccante induce la vittima a clickare sul suo link attraverso tecniche di phishing: invia una mail
fingendosi il sito e componendo il link in maniera particolare (il link contiene dello script).
Es.: www.banca.it/risorsa<script> JS… </script>
2. La vittima clicka sul link. Il browser fa una richiesta al server per quella determinata risorsa.
Es.: GET risorsa <script> JS… </script>)
3. Il server non trova la risorsa (non esiste) e ritorna al client una pagina HTML d’errore dove specifica a
quale richiesta non ha saputo rispondere (invia quindi anche il nome della risorsa contenente lo
script).
4. Il browser riceve la pagina e vede che c’è del JavaScript, quindi lo esegue. Tale script era stato
preparato dall’attaccante appositamente per recuperare il cookie (dal DOM: document.cookie).
5. Lo script, dopo aver rubato il cookie, fa una connessione verso il computer dell’attaccante e glie lo
invia.

StoredXSS
I dati che vengono prodotti dagli utenti vengono conservati all’interno del server (in database, file system,
…) per poter poi essere mostrati a video (es.: un sito di messaggistica deve salvare il messaggio inviato da A
per farlo vedere a B).
40

1. L’attaccante scrive un messaggio da pubblicare su un sito e lo struttura in maniera tale che contenga
uno script (dello stesso tipo dell’attacco precedente).
Es.: Ciao! <script> JS… </script>
2. Il server riceve l’input dell’attaccante e lo salva nel suo database.
3. Quando un utente richiede la pagina in cui è stato pubblicato il messaggio dell’attaccante riceve
anche lo script che viene eseguito dal browser. Tale script accede al cookie e lo invia all’attaccante.

Per evitare questo attacco sarebbe necessario filtrare gli input, bloccando tutti quelli contenenti script.
Sono nati però di conseguenza degli attacchi al parsing: si scrivono script in moltissimi modi ed in maniera
tale da nasconderlo. In questo modo non è semplice per il server riconoscerli tutti.

DOM-based XSS
DOM: l’HTML della pagina viene salvato all’interno di document.body, ma ci sono altri campi del DOM (es.:
document.URL, document.location, document.referrer) che contengono altre informazioni. Un’attaccante
potrebbe scrivere allora degli script riferiti a questi altri oggetti.

DOM-based XSS: attacco cross site scripting in cui l’attaccante mira a modificare il DOM nel browser della
vittima attraverso l’esecuzione di uno script lato client. In questo modo la pagina non cambia, ma lo script
dell’attaccante viene comunque eseguito.

Es.: codice conteneste uno script che permette all’utente di selezionare la propria lingua preferita. Una di
queste opzioni viene scelta di default, pertanto, la richiesta della pagina corrisponde alla seguente URL:
http://www.some.site/page.html?default=French
L’attaccante manda invece il seguente link alla sua vittima:
http://www.some.site/page.html?default=<script>alert(document.cookie)</script>
Quando la vittima clicka sul link, il browser manda la richiesta al server, il quale risponde inviando
page.html, la quale contiene lo script di scelta della lingua. Il browser crea quindi l’oggetto DOM associato
alla pagina ed inserisce, all’interno di document.location, il link inviato dall’attaccante. Infine il browser
esegue gli script, compreso quello contenuto in document.location, il quale recupera il cookie.

Cross Site RequestForgery (XSRF)

Obiettivo dell’attaccante: eseguire malware verso un sito web utilizzando i permessi di un determinato
utente.

Per questioni di sicurezza si potrebbe bloccare l’accesso a document.cookie, in questo modo l’attaccante
non sarebbe più in grado di rubarlo. È però sempre possibile impersonificare l’utente: invece che inviare
uno script per prendere il cookie se ne può inviare uno che faccia direttamente le operazioni che
l’attaccante vuole svolgere sul sito con i permessi di quell’utente (es.: effettuare un bonifico bancario).

Due modalità:
 Reflected XSRF: la vittima deve visitare il sito web dell’attaccante, il quale contiene delle azioni
nascoste verso il sito target. Contemporaneamente, la vittima aver stabilito una connessione sicura
verso il sito target, così che le operazioni svolte dallo script dell’attaccante arrivino al server passando
attraverso a questa connessione sicura.
 41

 Stored XSRF: l’attaccante mette la sua pagina all’interno del server. Quando un client visita la sua
pagina, il browser del client viene rediretto verso il server trusted e le operazioni inserite
dall’attacante vengono eseguite come se arrivassero da quel client.

Underground Economy
Introduzione
Negli ultimi anni si è potuta notare una notevole diversificazione del mercato nero associato ai malware ed
alla sovversione di sistemi connessi ad Internet, dalla creazione alla monetizzazione. Il cuore di questo
ecosistema risiede nel contagio di computer-vittime. In particolare ha acquistato importanza un servizio
chiamato Pay-Per-Install (PPI), il quale provvede un modo per esternalizzare (pagare qualcuno per fare
qualcosa) la disseminazione globale del malware.

L’ecosistema PPI è costituito da tre attori:

 Clienti: entità che vogliono installare il loro malware su un numero di target host (non hanno un
vettore di infezione, ma cercano qualcuno che diffonda il malware per loro).
 PPI provider (o services): viene pagato dai clienti per installare il loro malware sui target host
(permette anche di scegliere una regione geografica). Per far ciò sviluppa un programma, chiamato
downloader, che quando viene installato recupera l’eseguibile del cliente e lo esegue. Il PPI provider
potrebbe fare lui stesso l’installazione, oppure pagare una terza parte (affiliati) per distribuire il
downloader.
 Affiliati: vengono pagati dal PPI provider per ogni host su cui riescono ad eseguire il downloader del
provider. Una volta che il downloader viene eseguito, si connette al PPI provider per scaricare il
malware del cliente.
42

Se un antivirus riuscisse ad individuare e a bloccare uno qualsiasi dei programmi della catena, l’installazione
del malware non avverrebbe con successo. Pertanto, sia i PPI provider che i clienti devono creare degli
eseguibili che agiscano di nascosto. Per far ciò utilizzano dei programmi detti packer venduti da terze parti.

Infiltrazione nell’infrastruttura PPI

Al fine di studiare l’infrastruttura PPI sono state portate avanti delle azioni di infiltrazione in quattro di
questi sistemi.

1. Milking PPI Services

Un downloader PPI ha tre compiti principali da svolgere:
 Scaricare il malware del cliente
 Eseguire il malware
 Comunicare al PPI service che l’installazione è avvenuta con successo
Gli infiltrati hanno costruito dei loro programmi, detti milker, che imitano la comunicazione di rete utilizzata
dai downloader al fine di scaricare i malware dei clienti, ma che non implementano le altre due funzionalità
(l’esecuzione del malware e la comunicazione dell’installazione).

Ciascun PPI downloader usa diversi metodi per scaricare il malware del cliente, tuttavia questi sono
riducibili a due classi principali:
 Downloader basici: usano HTTP e possiedono un set di URL hardcoded che forniscono il programma
del cliente
 Downloader avanzati: contattano una infrastruttura e da essa ricevono la lista delle URL da cui
scaricare il programma dell’utente. Anche questi usano HTTP per scaricare il programma.

I PPI services cambiano spesso le URL di download per evitare che vengano bloccate in delle blocklist.

2. Esecuzione dei malware

I milker sono stati eseguiti all’interno di una farm di contenimento di malware, una infrastruttura protetta
che permette di controllare l’esecuzione dei programmi. In particolare è stato monitorato il traffico di rete,
bloccando tutte le connessioni di rete e ridirigendole verso a dei sink server interni alla farm, eccezion fatta
per le connessioni al DNS.
 43

3. Classificazione dei malware

I malware eseguiti sono stati classificati in base al traffico di rete che producono.

Caratteristiche di rete analizzate:

 Protocolli usati
 Lista di end point con cui il software comunica
 Lista di porte TCP/UDP di destinazione
 Caratteristiche di payload

Sono stati così individuati 57 cluster di cui 35 individuabili con un tag.

PPI business
Distribuzione geografica
Per la maggior parte delle famiglie di malware sono state osservate delle preferenze geografiche:
 Europa e Stati Uniti
 Stati Uniti o altri paesi singoli
 Nessuna particolare preferenza geografica

Ci sono vari fattori per cui un cliente dovrebbe scegliere un determinato paese: la classe di attività del
malware, il prezzo (varia in base al paese in cui si vuole installare il malware) e limiti legali.

Interazioni tra affiliati e PPI services

Capita non di rado che un affiliato sia esso stesso un cliente di un PPI service: l’affiliato cerca di guadagnare
sulla differenza di prezzo che i PPI service pagano per una determinata regione (es.: PPI 1 compra 1000
installazioni in Grecia per 60$, mentre PPI 2 le vende per 40$).

Download tree
Un downloader non si limita a scaricare l’eseguibile del cliente, ma si porta dietro una catena di download,
rappresentabile attraverso un albero:
 I nodi rappresentano i programmi
 Gli archi indicano quali programmi sono stati installati da un unico programma padre.
44

Android Security
Android
Android è un sistema operativo open source per smartphone, sviluppato da Google e basato su Linux. Nel
suo campo è il sistema operativo più diffuso (ricopre il 60% dei dispositivi mobili) e per questo è anche il più
attaccato (rapporto tra malware Android e malware di altri sistemi mobili del 9:1).

Il principale problema di sicurezza di Android è la frammentazione: il sistema operativo e l’hardware sono

fatti da due entità diverse, ciò implica che siano largamente diffuse versioni non recenti del sistema
operativo (aggiornare il sistema operativo non è priorità del vendor). Inoltre esistono moltissimi modelli di
smartphone di molti produttori diversi, tutti che girano lo stesso sistema operativo. Non è ovviamente
possibile ottimizzare il sistema operativo per ciascun modello.

Rooting del device: di solito gli smartphone vengono venduti senza la possibilità di accedere ai privilegi di
amministratore (sono pensati per tutti, anche per chi non è specializzato), tuttavia è possibile acquisite tali
permessi (l’utente diventa root).

Vantaggi a livello di configurazione:

 Sostituzione della ROM originale (es.: per disinstallare software promozionale)
 Regolazione del comportamento dell’hardware (es.: frequenza della CPU)
 Personalizzazione del software

Svantaggi:
 Tutte le applicazioni installate girano con i privilegi di root
 In caso di attacco, anche l’attaccante ha i privilegi di root

Architettura Android a strati:

 Kernel Linux
 Librerie di funzionamento
 Android runtime: le applicazioni Android sono scritte in Java e comunicano con questa porzione del
sistema per poter funzionare
- Librerie core
- Java Virtual Machine
 Application framework: gestione delle applicazioni
 Applicazioni vere e proprie

Le applicazioni Android sono suddivisibili in quattro categorie:

 Activitie: classiche applicazioni utente definite attraverso un’interfaccia grafica
 45

 Broadcast Receiver: applicazioni che richiedono l’intento di ricevere particolari messaggi (ricevono
input dai diversi canali di comunicazione
 Content Provider: condividono dati tra più applicazioni
 Service: applicazioni senza UI che vengono eseguite in backgroud

Permessi App
Ogni applicazione viene eseguita all’interno di una sandbox e possiede un sistema di permessi simile a
quello di Linux.

Ogni applicazione nel momento dell’installazione richiede un elenco di Access Permission Label (ogni
componente del dispositivo ne ha una) che ritiene necessarie per l’esecuzione, ovvero richiede all’utente di
darle il permesso di accedere a quelle risorse. Una volta che l’utente accetta, l’app viene configurata in
modo tale che possa accedere alle risorse attraverso il sistema di permessi di UNIX.

I permessi Android sono controllati da tre principali oggetti:

 API Permission: permessi che vengono controllati per l’accesso alle risorse tramite Android
Framework (definiti dalle API chiamate). Questi permessi vengono controllati runtime
 File System Permission: permessi utilizzati per l’implementazione della sandbox e servono per
defiinire l’accesso alle risorse sul file system
 IPC Permission: permessi relativi alla comunicazione tra differenti applicazioni. Ogni app definisce
anch’essa un Access Permission Label e per comunicare tra loro devono utilizzare il protocollo Binder.

Caso Kakao Talk

Kakao Talk è un client di messaggistica istantanea in voga nella comunità tibetana famoso per essere stato
oggetto di un attacco volto a rubare i dati personali degli utenti.

Gli attaccanti hanno diffuso un messaggio di posta elettronica contenente l’applicazione maligna, ovvero
una copia dell’applicazione originale, ma che richiedeva una notevole quantità di permessi sul telefono.
Accade spesso che gli utenti accettino i permessi senza leggerli o senza chiedersi se siano ragionevoli, in
questo modo l’applicazione è stata in grado di memorizzare la rubrica dell’utente, la cronologia degli SMS
ed il registro delle chiamate, per poi contattare un server per salvare informazioni come URL e credenziali
utilizzate dal telefono. Inoltre intercettava SMS ed inviava coordinate GPS per geolocalizzare il device.

Sistemi di difesa
Google Bouncer
Google Bouncer è un sistema di scansione automatica delle applicazioni pubblicate sul Play Store.

Tecniche di scansione:
 Analisi statistica delle applicazioni per ricercare minacce note
 Esecuzione del software in un emulatore virtuale
 Analisi dei dati immessi nel sistema da parte degli sviluppatori

Google Bouncer è stato soggetto ad un’analisi di sicurezza da parte di alcuni ricercatori che ne hanno
dedotto il comportamento:
46

 Analisi dell’applicazione inviata allo store

 Ricerca di pattern sospetti all’interno dell’app
 Interazione automatica con l’interfaccia grafica
 Controllo della provenienza delle app solo da certi indirizzi di rete
 Utilizzo di blocchi di rete ben definiti

È stata poi sviluppata un’applicazione in grado di eludere i meccanismi di controllo del Bouncer, tale ha le
seguenti caratteristiche:
 Quando riconosce un blocco di rete adibito al Bouncer disabilita le sue funzionalità
 All’inizio non ha funzioni JavaScript, ma le scarica automaticamente quando viene installata
 Ha in più delle funzionalità benigne che richiedono dei permessi

Problematiche del Bouncer:

 Code coverage non totale: non è possibile controllare tutto il codice
 Facilità di rilevazione dell’emulatore
 Gli IP dei dispositivi sono blocchi fissi

SELINUX
Security Enhanced Android SELINUX: sistema che permette di impostare dei permessi più sofisticati. Tali
possono anche essere settati dinamicamente.

Di default si nega ogni permesso esplicito, soprattutto per le applicazioni system (che girano a più basso
livello).

Il sistema avrà poi due principali repository:

 Permission repository: contiene i singoli permessi richiesti e gli insiemi dei permessi concessi
dall’utente
 Policy repository: contiene i pattern riconosciuti come dannosi

Tale sistema presenta comunque alcune debolezze:

 Alcune sequenze dannose sono invece lecite (falsi positivi)
 Necessità di aggiornare costantemente il policy repository
 Non copre tutto lo spettro di attacchi

CopperDroid
CopperDroid: piattaforma per l’analisi dinamica di malware basato su tre principi:
 Analisi a basso livello (OS kernel) e ad alto livello
 Stimolazione delle applicazioni per raggiungere tutte le entry point del sistema e consentire code
coverage
 Testing su database di malware noti e scansioni via web di applicazioni segnalate da utenti

Questo sistema è invisibile alle applicazioni in esecuzione nel guest, non modifica il flusso di esecuzione e fa
analisi approfondita delle chiamate tra le applicazioni (IPC), controllando la comunicazione tra esse.
 47

Native Client
Introduzione
Native Client è una sandbox che permette di eseguire codice nativo (es. C, molto pericoloso) all’interno del
browser.

Motivazioni:
 Performance maggiori dei linguaggi di basso livello
 Esistenza di legacy code (codice sorgente correlato ad un sistema operativo non più in produzione)
 Utilizzo di altri linguaggi diversi da Java

Un’applicazione è composta sia da componenti trusted che da componenti untrusted. In genere c’è
un’interfaccia utente implementata in JavaScript eseguita nel browser ed una porzione di codice scritta in
codice nativo che gira all’interno della sandbox NaCl (Native Client). Sia il JavaScript che il codice nativo
sono untrusted, ma sono eseguite nel browser e nella sandbox che sono trusted.

Come si fa ad assicurare del codice nativo?

 Fidarsi dello sviluppatore facendo firmare il codice per sapere che arriva da sorgenti trusted
 Attraverso sistemi di OS/HW isolation: sandbox implementate a livello di sistema operativo. Tuttavia
un sistema operativo è molto ampio e potrebbe quindi avere un’ampia interfaccia di attacco. Inoltre,
ogni sistema operativo ha la sua sandbox
 Progettare una nuova sandbox da zero: soluzione migliore

Il codice nativo arriva al browser in binario: si fa un primo controllo già sul binario stesso.

Safety:
 Evitare o controllare operazioni unsafe
 Memory boundry: impedire al codice di uscire dalla zona in cui è confinato

Tipologie di istruzioni:
 Safe: istruzioni che non fanno operazioni di memoria (es: operazioni aritmetiche)
 Unsafe: memory access, istruzioni privilegiate, system call, …
 Critiche: jump:
- Dirette: viene indicato l’indirizzo dove saltare direttamente nel binario
- Indirette: l’indirizzo dove saltare è salvato all’interno di un registro (jump %eax), pertanto il
valore effettivo sarà conosciuto solo in fase di esecuzione

Un salto è legittimo se non esce dallo spazio di indirizzamento del Native Client.

Il codice nativo deve poter fare delle system call, ma sono delle istruzioni unsafe. Viene dunque predisposto
un trustedenviroment contenente le system call. Se il codice ha bisogno di farne una deve chiedere al
trustedenviroment.
48

L’esecuzione del binario avviene in una zona di memoria ben definita e bisogna impedire che possa saltare
ad una zona di memoria esterna. Vengono quindi controllare tutte le istruzioni per controllare che siano
safe.

Potrebbe accedere che una jump non esca dalla zona di memoria adibita al binario, ma potrebbe non
puntare all’inizio di un’istruzione, bensì in mezzo, andando a creare nuove istruzioni non viste dallo
scanning lineare. C’è però un problema in caso di jump indirette: non si sa quale sia il valore del registro
%eax (si conosce il valore solo in esecuzione).

Le celle sono tutte di dimensioni diverse, ma è possibile uniformarle prendendo la dimensione della cella
più grande (32 bit nelle architetture Intel x32) e far sì che tutte le istruzioni abbiano tale dimensione,
aggiungendo NOP (No OPeration) fino a riempire i bit mancanti (padding). Per fare questa operazione si
utilizza una maschera:

AND $0xffffffe0, %eax

{
JMP %eax

In tal modo la jump può saltare solo ad un’istruzione a 32 bit (se non fa così viene allora forzata). Questa
operazione viene chiamata pseudo instruction.

Proprietà del binario:

1. Il binario non è scrivibile
2. Il linking deve partire da 64k
3. Le indirectjump devono essere pseudo instructions (AND e JMP atomica)
4. Tutte le istruzioni devono essere raggiungibili dal motore disassembly
5. Tutti i salti diretti devono essere anch’essi allineati
6. Quando è finito il binario, questo deve terminare con un’istruzione di ALT

Per evitare che si esca all’esterno, è necessario restringere la visione che il Native Client ha della sua
memoria. è possibile fare quindi uso della segmentazione (caratteristica Intel).

SegmentDescriptionTable: ogni linea della tabella definisce una zona di memoria (segmento). Si crea quindi
un segmento apposito per il binario (si definisce base e lunghezza del segmento). Quando un processo
cerca di uscire dal suo segmento viene bloccato dall’hardware.

È possibile fare jump verso il trustedenviroment, ma attraverso un trampolino: il binario salta al

trampolino, il quale esegue l’istruzione richiesta e ritorna poi al binario.
 49

Sommario
1. Storia della Computer Security ...................................................................................................................... 1
3. Fondamenti della Computer Security ............................................................................................................ 2
6. Reference Monitors ....................................................................................................................................... 5
4. Identificazione e autenticazione.................................................................................................................... 8
7. Unix Security ................................................................................................................................................ 11
10.a Attacchi software ..................................................................................................................................... 15
10.b Difese software........................................................................................................................................ 19
14. Crittografia................................................................................................................................................. 21
17. Network Security ....................................................................................................................................... 25
16. Communications Security .......................................................................................................................... 31
18. Web Security ............................................................................................................................................. 36
Underground Economy ................................................................................................................................... 41
Android Security .............................................................................................................................................. 44
Native Client .................................................................................................................................................... 47