# Network Security Notes pt.2

## Intrusion Detection

Classi di Attaccanti
* **Cyber Criminali**, Est-Europei o cinesi, cercano profitto via furto o ricatto.
* **Hacktivists**, attaccano per ragioni politiche o sociali.
* **Organizzazzioni di Spionaggio** (State-Sponsored)
* Altri (Hobbisti)

Livelli di skill
* **Skiddies**, utilizzano script e vulnerabilità note. Facile difendersi
* **Journeyman**, modificano script già presenti per adattarli al tipo di attacco che si vuole eseguire
* **Master**, scoprono nuovi exploit per programmare nuovi script

Esempi di intrusione
* Compromissione shell remota
* Defacement del server Web
* Indovinare / decifrare le password
* Copia di database contenenti numeri di carta di credito
* Visualizzazione di dati sensibili senza autorizzazione
* Esecuzione di uno sniffer di pacchetti
* Distribuzione di software piratato
* Utilizzo di un modem non protetto per l'accesso interno della rete
* Impersonare un dirigente per ottenere informazioni
* Utilizzo di una workstation automatica

Passi di un attacco
1. **Acquisizione del bersaglio e Information Gathering**
2. **Accesso iniziale**, tramite tecniche di brute force o sfruttando exploit derivanti da vulnerabilità del CMS
3. **Privilege Escalation**, acquisire il controllo da amministratore
4. **Information gathering all'interno del sistema**, scansionamento dei file di interesse e trasferimento di documenti in repository esterne
5. **Mantenere l'accesso**, installare rootkit o backdoor
6. **Nascondere le tracce**, modificare i file di log e nascondere i file installati

### IDS
Un servizio di sicurezza che monitora e analizza gli eventi di sistema allo scopo di trovare, e fornire avvisi quasi in tempo reale, di tentativi di accesso non autorizzato alle risorse di sistema.

> Addirittura l'IETF mette a disposizione degli RFC dove sono definiti i formati per lo scambio e i protocolli per lo scambio di messaggi per l'Intrusion Detection.

Comprende tre componenti logiche:
* **Sensori**, collezionano dati
* **Analizzatori**, determinano se l'intrusione è avvenuta
* **Interfaccia utente**, mostra l'output o il comportamento del sistema di controllo

Esistono **due principali approcci**:
* **Anomaly Detection**, utilizza una collezione di dati relativi al comportamento di utenti legittimi per il sistema, rileva quindi anomalie basandosi su diversi approcci:
* *Approccio Statistico*
* *Knowledge based* (richiede esperti di sistema)
* *Machine-learning*
* **Signature/Heuristic detection**, utilizza una serie di modelli basati su dati di attacchi noti per confrontarli con il comportamento corrente del sistema (può solo identificare comportamenti anomali di cui si ha una regola)
* *Signature approaches*: effettua un matching di grandi collezioni di pattern già conosciuti per minimizzare il tasso di falsi positivi. Ampiamente usato dagli anti-virus, proxy di scansione del traffico di rete e in NIDS (Network IDS).
* *Rule-based heuristic identification*: utilizza delle regole per identificare attacchi noti. Le regole identificano quindi situazioni sospette e sono specifiche per ogni tipologia di sistema.
* **SNORT** è un *NIDS rule-based*, in accordo all'approccio di tipo signature detection, questo sistema può essere installato dietro un firewall e **funziona da sniffer o packet logger**, per individuare pacchetti sospetti attraverso regole (PulledPork fa pull di regole pre-fatte), può anche essere adoperato come un *Intrusion Prevention System*. Una regola SNORT è composta da:
* Action
* Alert
* Drop
* Reject (manda TCP RESET)
* Protocol (TCP, UDP, ICMP, IP)
* Source IP
* Ports (internal/external)
* Direction (entrata/uscita)
* Destination IP

Esistono tre tipologie di IDS:
* **Host-Based IDS** monitora le caratteristiche di un singolo host per rilevare attività sospetta. Viene inserito un livello software aggiuntivo per la sicurezza.
* Data Sources e Sensori: per rilevare attacchi si monitorano le system call, i logfile e le checksum dei file
* **Network-Based IDS**, monitora il traffico sulla rete per tutto lo stack protocollare allo scopo di identificare attività sospetta. Utilizza dei *sensori sparsi sulla rete* in modalità promiscua e dei server per la raccolta dei dati.
* Con la *Signature Detection* posso riconoscere attacchi a livello applicativo, di trasporto e di rete
* Con la *Anomaly detection* posso riconoscere i DoS, Scanning e worms
* Nello specifico la *Stateful Protocol Analysis* compara il traffico con dei profili messi a disposizione dai vendor (la ground truth mi è fornita). Usa molte risorse.
* Un NIDS tiene traccia di: timestamps, Soruce e Destination IP, Porti, ...
* Esistono anche **Hybrid IDS**, che sono un approccio misto

### Honeypot
Sistemi progettati per **attirare un potenziale attaccante** in un punto lontano dai sistemi critici, raccoglie informazioni sull'attività dell'attaccante. Allo stesso tempo incoraggia l'attaccante a restare sul sistema abbastanza a lungo permettendo agli amministratori di sitema di rispondere. Questi sistemi sono riempiti con informazioni e risorse fabbricate ad hoc, alle quali un utente legittimo non avrebbe mai l'accesso. Se queste risorse sono state manipolate suggeriscono che il sistema è stato compromesso. Esistono due classificazioni:
+ **Low Interaction Honeypot**: consiste in un pacchetto software che emula particolari servizi o sistemi IT in modo da fornire un'interazione iniziale realistica, ma lo fa non eseguendo una versione completa di tali servizi o sistemi. Spesso è sufficiente per l'uso come IDS distribuito in cui può avvertire dell'attacco imminente
+ **High Interaction Honeypot**: un sistema reale, con un sistema operativo completo, servizi e applicazioni, dove gli attaccanti possono accedervi. Essendo un bersaglio più realistico può impegnare l'attacante per un periodo di tempo più esteso, inoltre se compromesso potrebbe essere utilizzato per avviare attacchi su altri sistemi.

## Firewall
Rappresenta uno strumento per proteggere le LANs. Si inserisce tra la rete interna ed internet creando un collegamento controllato.
Tutto il traffico in entrata e in uscita deve passare attraverso un firewall, solo il traffico autorizzato (definito dalla policy di sicurezza locale) può passare attraverso di esso.

Una componente critica è proprio la pianificazione e implementazione della policy di accesso al firewall. Dovrebbe essere sviluppata con una specifica tipologia di traffico che l'organizzazione supporta. Questo comporta la definizione di liste di IP autorizzati, filtraggio dei protocolli e contenuti.

Per filtrare il traffico il firewall deve **ispezionare alcune caratteristiche** dei pacchetti:
* Indirizzo IP e Protocolli
* Livello applicativo
* Identità degli utenti (Gli utenti all'interno della rete sono autenticati)
* Attività di rete (orario, tasso delle richieste)

Esistono **varie tipologie** di Firewall
+ **Packet Filtering Firewall**: applica regole per ogni pacchetto IP entrante o uscente. Tipicamente tali pacchetti sono filtrati attraverso una lista di regole che eseguono il matching con un particolare tipo di header (ex. Source IP address, Destination IP address). Esistiono due politiche di default:
+ **Discard**: proibisce tutto il traffico tranne quello espressamente permesso
+ Forward: permette tutto il traffico tranne quello espressamente proibito
+ **Stateful Inspection Firewall**: restringe le regole per il traffico TCP, creando una directory di connessione TCP ammesse in uscita. Questo tipo di filtro consente l'ingresso del traffico solo a porte presenti nell'elenco. Tiene inoltre traccia del TCP sequence number per prevenire attacchi
+ **Application-Level Gateway**: Viene chiamato anche "application proxy", l'utente si autentica presso il gateway e servirà tutte le richieste abilitate verso l'host remoto per conto dell'utente interno. È richiesto che sia configurato per ogni applicativo ma allo stesso tempo è molto sicuro pagando dell'overhead.
+ **Circuit-Level Proxy**: Configura una connessione TCP con l'utente interno ed una con un utente esterno. Fa passare tutto il traffico ma sceglie accuratamente quali connessioni aprire. Usato quando gli utenti interni sono trusted. Socks v5 è un RFC utilizzato per queste comunicazioni.
+ **Bastion Hosts**: è un host critico all'interno dell'azienda, per proteggerlo, facciamo Application-level o Circuit-level Proxy verso di esso. Può essere richiesta autenticazione ed ogni proxy può restringere gli accessi al bastion host in qualsiasi momento.
+ **Host-Based Firewalls**: Protegge un singolo host e di solito è fornito insiema al SO, filtra e restringe i pacchetti.
+ **Personal Firewall**: Controlla il traffico tra un personal computer e Internet, tipicamente è un modulo software sul PC. Può essere inserito in un router che permette la connessione di tutti i PC interni alla rete. Ruolo primario è sempre di negare l'accesso a utenti non autorizzati, in alternativa può essere utilizzato per monitorare il traffico ed individuare worms o attività malware.

### Intrusion Prevention Systems (IPS)
Sono un estensione degli IDS che includono la capacità di bloccare o prevenire le attività malevole che vengono rilevate.

+ **Host-Based IPS (HIPS)**
Un insieme di tecniche che *prevengono* gli attacchi a singoli host. Utilizzo tecniche di tipo general purpose (ex. virutalizzazione per prevenire privilege escalation aka *approccio sandbox*). Dal momento che si è studiato che i desktop e i laptop sono gli elementi più vulnerabili all'interno delle aziende. Si spinge molto nel creare HIPS che siano integrati per la sicurezza totale dell'host.
+ **Network-Based IPS (NIPS)**
Sono dei NIDS con inoltre *la possibilità di scartare pacchetti* e chiudere connessioni TCP. Possono essere utilizzati metodi a firma o euristiche per la anomaly detection, a volte richiedono di ispezionare l'intero flow di una connessione. Si può utilizzare *SNORT Inline*, rendendo SNORT un NIPS, può anche conferire la possibilità non solo di scartare pacchetti ma modificarli e depistare un eventuale attaccante.

**Digital Immune System**
Rappresenta una difesa completa contro i comportamenti dannosi causati da malware. Sviluppata da IBM e rifinita da Symantec. La motivazione della nascita di questo progetto nasce dall'aumento di malware e la loro velocità di propagazione su Internet. Il successo dipende dall'abilità del sistema di individuare diversi ceppi di malware.

## IP Tables

Un *packet filter* è un software che guarda gli header dei pacchetti e decide cosa farne del pacchetto. Può decidere di scartare il pacchetto, lasciarlo passare o fare qualcosa di più complicato

Il **kernel** di Linux contiene un'infrastruttura che consente il filtraggio dei pacchetti (*netfilter*)
* Il tool **iptables** dialoga con il kernel e gli indica quali pacchetti filtrare, inserendo e rimuovendo regole dalla tabella di filtraggio del kernel

**INPUT**, **OUTPUT** e **FORWARD** sono tre *liste di regole*,
chiamate **catene**, presenti nella tabella filter.
Quando un pacchetto arriva ad uno di questi blocchi, la catena corrispondente lo esamina per deciderne il destino, se la catena dice di scartare (DROP) il pacchetto, questo sarà scartato al momento; se invece la catena dice di accettarlo (ACCEPT), il pacchetto potrà continuare a essere trasmesso.
Ogni regola dice 'se l'header del pacchetto appare in questo modo, allora ecco cosa bisogna fare'.
1) Se il pacchetto non soddisfa una certa regola, allora sarà consultata la regola successiva
2) Se non ci sono più regole da consultare, allora il kernel utilizza la *policy* della catena
* In un sistema per la sicurezza la policy indica al kernel di scartare il pacchetto

Il tool iptables mette a disposizione alcune **operazioni utili** per gestire intere catene:
- Crea una nuova catena (-N)
- Cancella una catena vuota che non è l'obiettivo di alcuna regola (-X)
- Cambia la tattica di una delle catene preesistenti (-P)
- Elenca le regole presenti in una catena (-L)
- Svuota una catena delle sue regole (-F)
- Azzera i contatori dei pacchetti e dei byte di tutte le regole di una catena (-Z)

Le catene preesistenti INPUT, FORWARD e OUTPUT non possono essere cancellate. Ci sono poi diversi modi per manipolare le regole di una catena:
- Appendi una nuova regola alla catena (-A)
- Inserisci una nuova regola in una determinata posizione della catena (-I)
- Sostituisci una regola presente in una certa posizione della catena (-R)
- Cancella una regola presente in una certa posizione della catena (-D)
- Cancella la prima regola di una catena (-D)

Come detto, una regola specifica un insieme di condizioni che il pacchetto deve soddisfare, e che cosa fare se le soddisfa (obiettivo). Gli obiettivi sono solitamente riconducibili ad IP sorgente o destinazione e tipo di protocollo:
+ IP sorgente ('-s', '--source', '--src') e destinazione ('-d','--destination', '--dst')
+ Il protocollo può essere specificato usando l'opzione '-p' (o '--protocol') ad esempio -p tcp

# Domande Gettonate

## Wifi-Hacking
* Hacking WEP;
* Autenticazione secondo lo standard 802.1X;
* Approcci al cracking in WPA (sia PSK che Enterprise); Rainbow Table;
### Cracking reti WEP
Attacco di tipo encryption, si sfrutta la vulnerabilità di codifica dei pacchetti di WEP. Questo protocollo infatti prevede per l'encryption l'utilizzo di frame IV.

L'obiettivo dell'attacco è raccogliere un elevato numero di:
* frame **IV (Inizialization vector)**
* frame poco variabili (ex. pacchetti ARP)
* possibilità di “indovinare” il “plain text”, il quale, combinato con il “cypher text” della frame iniziale, consente di identificare il “keystream”

Sono possibili due appricci:
* Approccio **passivo**: basato sul semplice “ascolto” delle frame trasmesse nell’etere. Utilizzato quando è già presente molto traffico e quindi non ho problemi a catturare un gran numero di frame (circa 50k).
* Approccio **attivo**: *ARP Replay con Fake Authentication*, nel caso in cui non è presente molto traffico possiamo "generarlo noi" in maniera sintetica.
* L'attaccante deve catturare almeno una *frame broadcast di tipo ARP Request*
* Reinvio più volte la frame ARP Request che ho catturato
* L'AP riceverà correttamente le frame ARP Request, le decodifica e risponde con un **ARP Replay**, generando nuovi pacchetti sulla rete con nuovi IV.
* Il tutto può avvienire anche in modalità *Open Authentication* se abilitata dall'AP. In questo caso mi asterrò dall'inviare frame dati per non essere estromesso dalla rete.
* I tool utilizzato sono:
* *airmon-ng* per mettere la scheda in modalità monitor
* *airodump-ng* per salvare le frame ascoltate
* *aircrack-ng* per crackare il plaintext con le frame IV catturate
* *airplay-ng* per l'attacco attivo ARP Replay

### Cracking reti WPA (Authentication attacks)
Il target di questi attacchi è il **processo di autenticazione**, fase in cui l’utente fornisce al sistema delle credenziali che vengono utilizzate per stabilire la sua identità.

**Brute-Force guessing su PSK**
Per reti di tipo PSK l'attacco parte dallo sniffing del *4-way hanshake*. Una volta che l'ho catturato posso eseguire *aircrack-ng* per derivare la chiave PSK a partire dai dati contenuti nel 4-way handshake appena registrato. Per avere successo la chiave deve essere presente nel mio database in input all'algoritmo di cracking.
Se non riesco ad ascoltare 4-way handshake posso sferrare un *de-authentication attack*, e forzare quindi una nuova autenticazione di un client sulla rete.

Per velocizzare il processo di brute-forcing posso utilizzare: Rainbow Tables e GPU Cracking.
Le **Rainbow Tables** sono una pre-elaborazione delle funzioni hash dei candidati per la PSK, pesano diversi GB, e devono contenere il valore del SSID. Vanno bene per SSID di default.

**WPA Enterprise**
In questo caso, gli attacchi sono rivolti al particolare tipo di protocollo di autenticazione:
* LEAP (Lightweight EAP)
* Basato su MSCHAPv2 (“challenge/response”)
* Abbastanza sicuro con password complesse
* EAP-TLS e PEAP (protected EAP)
* Crea un tunnel TLS tra il client che chiede l’autenticazione ed un server RADIUS su rete fissa
In generale per attaccare WPA Enterprise dovrei bucare TLS, che è molto sicuro.

**Impersonation Attack**
Per non dover bucare TLS utilizzo questa tipologia di attacco. Il trucco è **fingere di essere l’AP** al quale il client target intende connettersi e agire come punto terminale del tunnel TLS (server RADIUS).

Posso utilizzare i tool:
* *hostapd* crea un AP fittizzio
* *FreeRADIUS-WPE* accetta automaticamente qualsiasi richiesta di connessione e salva su un file di log tutti i dati relativi al protocollo interno di autenticazione.
* *asleap* mi permette di decodificare la challenge/response attraverso un dizionario.

### Standard 802.1x
**Autenticazione 802.1x-2004**

1. Il supplicant contatta (con una richiesta EAP Over Lan) l'authenticator (Access Point) e questo risponde con una richiesta di credenziali
2. Il supplicant risponde con le credenziali all'authenticator, questo re-inoltra una richiesta al server Radius
3. Il server Radius risponde con una challenge che il supplicant dovra risolvere
4. La challenge risolta viene reinoltrata al server radius che la confronta con la propria soluzione, se queste coincidono viene accettata l'autenticazione
5. Abbiamo ottenuto la **Primary Master Key** (PMK) condivisa dai 3 attori

**Generazione delle Temporal Keys (*4-way handshake*)**
A valle del processo di autenticazione, il server Radius non ci server più, e la STA e l'AP doveranno quindi accordarsi sulle chiavi temporali, utili per lo scambio di messaggi in maniera sicura.
Non basta la sola PMK, per il calcolo della *Pairwise Temporal Key* **PTK** servono inoltre:
+ PMK, la **Primary Master Key** stessa ottenuta dalla fase di autenticazione
+ **indirizzo STA**
+ **indirizzo AP**
+ **ANonce**, un numero generato casualmente dall'AP
+ **SNonce**, un numero generato casualmente dalla STA


La *Groupwise Temporal Key* **GTK** essendo una comunicazione di gruppo, non può dipendere da una info generata da una singola stazione quindi l’AP, dopo aver generato la PTK, manda la GTK a tutte le stazioni che si agganciano a quell’AP e che si sono autenticate con esso.

## IPsec
* Differenze tra AH e ESP; differenze modalità Transport e Tunnel
* Com’è fatto l’Header ESP? C’è un campo che ti dice la lunghezza? Si
* Differenze tra Diffie-Hellman e Oakley
* Creazione canale sicurezza IPSec (IKE) e cos’è la modalità Aggressive (perché è vulnerabile? cosa fa il tool IKE-scan?);
### Modalità operative di IPsec
**Modalità Transport**

È tipicamente utilizzata tra due **nodi terminali** (**end to end**) e richiede che entrambi siano in grado di gestire IPsec. Si occupa di offrire un protocollo di rete sicuro anche per i livelli superiori, ovvero garantendo ad esempio crittografia a questo livello essa sarà garantita anche ai livelli superiori. Il pacchetto IP sarà protetto a seconda dell'approccio scelto:

* **AH**: con questa modalità andremo ad autenticare il payload IP e determinate parti dell’intestazione IP. Solo alcune parti dell'header IP di origine possono essere autenticate ovvero le opzioni che non subiscono modifiche (ex. non posso auteticare il TTL).
* **ESP**: Esegue la crittografia, opzionalmente può autenticare il payload IP, ma non lavorerà mai sull’intestazione (header originario).


**Modalità Tunnel**
Prevede due elementi terminali che **non sono tutti e due end system**, ma che sono tipicamente dei gate che si trovano all'ingresso di due reti (*point-to-point*).
In questa modalità l'host non sarà in grado di applicare le funzionalità di sicurezza viste precedentemente, il compito verrà delegato al gateway. Questo vuol dire che il traffico tra host e gateway di una sottorete viaggerà in chiaro (IP)
* **AH**: *Autenticazione* dell’intero pacchetto IP interno ed alcune parti dell’intestazione IP esterna
* **ESP**: *Crittografia* e (opzionalmente) *autenticazione* dell’intero pacchetto IP interno, **compresa l'header IP originale (interno)**


Riassumendo le differenze tra i due metodi:

### Autentication Header (AH)
Avendo aggiunto lo strato di IPsec al pacchetto IP originale, sarà il campo di AH header a gestire l'incapsulamento con i livelli superiori.
Quindi nell'header IP setto protocollo 51 che sta ad indicare proprio AH, all'interno di AH incapsulo il codice del livello superiore (questo codice andrà nel campo next header)

Authentication Header possiede diverse proprietà:
* Supporto per l'**integrità dei dati**
* Supporto per l’**autenticazione** dei pacchetti IP
* Prevenzione *IP spoofing* e filtraggio traffico non autenticato
* Prevenzione di **attacchi replay**
* Autenticazione basata su **MAC** (*Message Authentication Code*)

I campi del pacchetto comprendono:
* **Next header** (8 bit): Tipo di intestazione che segue questa intestazione (TCP, UDP, ICMP, …)
* **Payload length** (8 bit) Lunghezza di Authentication Header in word di 32 bit
* **Reserved** (16 bit) Riservato per utilizzi futuri
* **Security Parameters Index** (32 bit) Identifica una *Security Association* lato ricezione, punta alla *Security Association Database*, cioè è un indice che punta ad una tabella
* **Sequence number** (32 bit) Contatore incrementale monotono, per far fronte a *replay attack*
* **Authentication data** (variabile) Campo di lunghezza variabile (multiplo di word di 32bit) che contiene il valore ICV (Integrity Check Value) o MAC (Message Authentication Code)

**Replay Attack**
Un estraneo ottiene la copia di un pacchetto autenticato, trasmette successivamente tale copia alla destinazione prevista. I pacchetti autenticati duplicati possono minare il corretto funzionamento della rete. Questo tipo di attacco (*Replay Attack*) viene evitato grazie al campo “*Sequence Numbe*r”.
* **Lato mittente**
Alla creazione di una nuova SA il mittente inizializza un **contatore a 0**, ad ogni pacchetto inviato in una SA il mittente incrementa il contatore ed inserisce il valore nel campo Sequence Number (il primo valore è pari ad 1).
Inoltre il mittente non deve consentire che i numeri di sequenza ricomincino **ciclicamente** dopo ($2^{32} – 1$) incrementi, ma al raggiungimento di questo valore, **la SA viene chiusa**, e ne viene **aperta una nuova**.

* **Lato destinatario**:
Implementa una **finestra scorrevole** di dimensione W = 64 (tipicamente). Il pacchetto con numero sequenziale compreso fra N-W+1 ed N sarà ricevuto correttamente, perchè all'interno della finestra. Nel caso in cui arrivasse un pacchetto con un sequence number inferiore al valore attuale della finestra (replay) questo verrà automaticamente scartato.

**Integrity Check Value**
E’ un controllo di integrità, che viene messo nel campo *Authentication Data*. Si ottiene applicando gli algoritmi più noti (HMACMD5-96, HMAC-SHA1-96, che usano una **chiave segreta** per l'hashing!).

I campi utilizzati per l'autenticazione in AH sono i seguenti:
* Campi dell’intestazione IP che non **cambiano durante la trasmissione**
* Internet Header Length, Source Address
* Campi dell’intestazione IP che hanno un **valore prevedibile** al punto terminale della SA AH
* Destination Address
* Campi **variabili** o non prevedibili vengono **considerati 0**
* Time to Live, Header Checksum
* **Header** di AH tranne Authentication Data stesso
* Authentication Data viene considerato 0
* Tutti i dati dei protocolli di **livello superiore**


**Struttura Datagrammi IPsec**
Come visto precedentempente lo strato di IPsec si interpone tra l'IP originale e il protocollo di livello superiore.
In modalità Tunnel avremo questo nuovo pacchetto IP dove il source address è sostituito dall'IP del gateway (proprio perchè c'è il tunneling).

### Encapsulating Security Payload (ESP)
ESP è il protocollo numero 50, quindi inseriamo questo numero nell'header IP original.
ESP prevede anche un *ESP Trailer*, dedito alla **crittografia**, ma se vogliamo garantire anche l'autenticità dopo il ESP Trailer ci sarà un *ESP Authentication*.
La differenza sostanziale rispetto ad AH è che la crittografia e l'autenticazione non saranno applicate all'header IP originale, questo perchè ESP si applica solo al payload (parte destra del pacchetto).

Gode di diverse proprietà:
* Servizi di **segretezza del contenuto** del messaggio
* Servizi di **segretezza** parziale **del flusso** di traffico, aggiungendo padding alla fine del payload
* Servizio opzionale di **autenticazione**


L'header di ESP è formato da:
* **Security Parameters Index** (SPI) (32 bit)
* Identifica una **SA** (*Security Assosiation*)
* **Sequence number** (32 bit)
* Contatore incrementale monotono per la funzione anti-replay
* **Payload data** (variabile)
* Segmento di dati (transport) o pacchetto IP (tunnel) protetto
* **Padding** (0-255 byte)
* Faccio padding perchè allineo il payload ad una dimensione standard per gli algoritmi di cifratura
* Faccio padding anche per nascondere la tipologia di traffico, oscurando la reale dimensione dei pacchetti
* **Pad length** (8 bit)
* Numero di byte di riempimento nel campo precedente
* **Next header** (8 bit)
* Tipo di dati contenuti in payload data
* **Authentication data** (variabile)
* Word di 32 bit. Contiene il valore **Integrity Check Value** o **Message Authtentication Code** (MAC) calcolato con i metodi (con chiave segreta):
+ HMAC-MD5-96
+ HMAC-SHA-1-96

* Il MAC è calcolato su
+ Security Parameters Index
+ Sequence Number
+ Payload Data
+ Padding
+ Pad Length
+ Next Header
+ **escluso** il campo AD stesso
* Diversamente da AH, il MAC non copre l’header IP precedente

**Algoritmi di Crittografia**
Algoritmi utilizzabili definiti nel documento DOI (Domain Of Interpretation). Per poterli utilizzare è necessario uno scambio di **vettori di inizzializzazione**, questi viaggiano in chiaro perchè non possono essere crittografati.

+ Triple DES a tre chiavi
+ RC5
+ IDEA
+ Triple IDEA a tre chiavi
+ CAST
+ Blowfish

**ESP in modalità transport**
La modalità transport prevede una connessione *end-to-end* tra due host terminali.
Facciamo **prima encryption** dell'header TCP/UDP, il payload e il trailer ESP. **Dopo faccio authentication** su header ESP e **su testo appena cifrato**.


**ESP in modalità tunnel**
La modalità tunnel prevede una connessione tra un host e un gateway (non terminale). Faccio **prima encryption** questa volta anche sull'**header IP originale**, payload e trailer ESP, poi **dopo faccio authentication** sull'header ESP e sul testo appena cifrato.

L’intestazione IP contiene informazioni relative agli indirizzi IP di mittente e destinatario (talvolta direttive di source routing ed opzioni hop-by-hop in IPV6).
A differenza della modalità transport è incapsulo l’intero blocco con una nuova intestazione IP, utile in presenza di firewall o security gateway.
Il pacchetto de-incapsulato dal gateway viaggerà in chiaro sulla rete interna, quindi gli host interni non devono utilizzare IPSec.


**Combinazione delle associazion di sicurezza**

Caso 1. **Host to Host security**

Caso 2. **Gateway to Gateway security**

Caso 3. **End to End Security**


Caso 4. **Host to Gatewat secuirty**

**Combinazioni di SA**

* **Combinazione ESP-AH**
1.  ESP in modalità transport senza autenticazione
2.  AH in modalità transport

* **Combinazione AH-ESP**
1. AH in modalità transport
2. ESP in modalità tunnel senza autenticazione

### Diffie-Hellman VS Oakley
Diffie-Hellman è lo scambio di base che avviene secondo la logica di chiave pubblica e chiave privata, mentre Oakley è un wrapper di D-H ovvero implementa lo stesso tipo di scambio ma aggiunge mecceanismi di prevezione di attacchi come ad esempio il clogging, aggiungendo un nonce allo scambio classico

## SSL
* SSL: Handshake e formati dei pacchetti dei vari protocolli; Heartbleed Attack
* SSL: Metodi per lo scambio di chiavi? D-H, Ephimeral DH, RSA
* Programmazione SSL: varie funzioni C e strutture dati (soprattutto SSL Context)
### Protocolli SSL
Analizziamo la struttura del protocoll SSL e dei suoi sotto-protocolli:


**SSL** è composto da **due livelli** protocollari:
* **SSL Record Protocol**
* Fornisce servizi di sicurezza di base ai protocolli di livello superiore
* **Protocolli di livello applicativo** per la gestione degli scambi SSL
* Handshake Protocol
* Change Cipher Spec Protocol
* Alert Protocol
* Heartbeat Protocol
* Applicazione (eg. HTTP)

**Header SSL Record**
* **Content type (8bit):** Il protocollo di livello superiore utilizzato per elaborare il frammento
* **Change_cipher_spec:** lo stato provvisorio venga copiato nello stato corrente (e provvisiorio settato a NULL),la tecnica di cifratura utilizzata nella connessione sia aggiornata ed attivata
* **Alert:** può essere warning o fatal, nel caso fatal la connessione è compromessa e sarà chiusa
* **Handshake:** si crea la sessione e si negoziano i parametri
* Dati applicazione
* Heartbeat
* Major Version (8 bit)
* La versione major di SSL in uso (per SSL v3 è 3)
* Minor Version (8 bit)
* La versione minor di SSL in uso (per SSL v3 è 0)
* Compressed Length (16 bit)
* La lunghezza in byte del frammento compresso

**Riepilogo dei protocolli SSL**

### Protocollo di Handshake
> I messaggi opzionali sono *tratteggiati*

1. La **fase 1** è di presentazione, nel primo messaggio *client_hello* vengono scambiati numeri random con sessioni id e l'elenco degli algoritmi che supporta, il *server_hello* è analogo con le stesse info ma passerà direttamente le info sugli algoritmi richiesti (non su tutti quelli supportati)

2. Nella **fase 2** il server può inviare dei certificati e la chiave per lo scambio dei messaggi. Può richiedere al client di inviare il proprio certificato. I messaggi si chiudono con *hello_done*
+ Lo scambio di **certificati** avviene con X.509 ed è obbligatorio per ogni scambio delle chiavi esclusa la modalità anonima di Diffie-Hellman (no auth). I certificati contengono il materiale pubblico per la generazione delle chiavi.
+ **Scambio delle chiavi**
+ **RSA**: La chiave segreta viene crittografata con la chiave pubblica RSA del destinatario
+ **Fixed Diffie-Hellman**
+ I parametri pubblici di D-H del server sono contenuti in un certificato firmato da una CA
+ Il client fornisce i propri parametri della chiave pubblica D-H in un certificato o attraverso un messaggio per lo scambio delle chiavi
+ A valle di FDH avrò una **chiave segreta fissa** fra i due nodi basata sul calcolo D-H, utilizzando chiavi pubbliche fisse
+ **Ephemeral Diffie-Hellman**, che a differenza del DH classico non mantiene sempre le stesse chiavi ma utilizza *chiavi temporanee* (cambiate ciclicamente)
+ Vengono scambiate le chiavi pubbliche D-H temporanee firmate utilizzando la chiave privata RSA
+ Il destinatario può verificare l’autenticità con la corrispondente chiave pubblica
+ I certificati vengono utilizzati per autenticare la chiave pubblica
+ Il più sicuro tra gli approcci DH, perché produce una chiave temporanea autenticata!
+ **Anonymous Diffie-Hellman**, è DH classico senza autenticazione delle parti
+ **Fortezza**, proprietario e alternativo a DH
> + #### Protocollo Diffie-Helman
> Questo è un metodo di scambio a **chiave asimmetrica**, e avviene nei seguenti passi:
> 1. Accordo iniziale fra A e B sui parametri globali
> + **g**: numero primo molto grande (generatore)
> + **p**: radice primitiva di g
> 2. **A trasmette** a B la sua **chiave pubblica**
> 3. **B trasmette** ad A la sua **chiave pubblica**
> 4. I due end-point **calcolano la chiave privata** di sessione
> 5. Le chiavi segrete vengono create solo quando necessario
> > Lo scambio di chiavi non richiede infrastrutture preesistenti, ma solo l’**accordo sui parametri** iniziali. Un attaccante che riesce a sniffare solo g, p, A, B **non può calcolare K** (gli manca appunto la chiave privata di uno dei due)
> 

**Vulnerabilità**
+ Vulnerabile all’**attacco clogging** in caso di richieste di numeri elevati di chiavi (**DoS**), richiedo la negoziazione delle chiavi di continuo solo per farlo lavorare
+ Nessuna informazione sull’identità delle parti, impossibile verificare l'**autenticità** del mittente
+ Vulnerabile all’**attacco man-in-the-middle** composto in questo modo:
+ C si finge B mentre comunica con A
+ C si finge A mentre comunica con B
+ A e B negoziano la chiave con C
+ C ascolta ed inoltra il traffico

3. Nella **fase 3** il client invia i certificati se sono stati richiesti. Il client poi chiude lo scambio di chiavi e la verifica del certificato ricevuto dal server.
+ *certificate* è la risposta da parte del client alla richiesta di certificato
+ *client_key_exchange* contiene le chiavi del client
+ *certificate_verify* contiene la verifica del certificato che il client ha ricevuto dal server nella fase 2
4. Nella **fase 4** viene scambiato il *change_cipher_spec* che rende operative le specifiche di crittografia definite nelle fasi precedenti. *Finished* chiude l'handshake ambo i lati e contiene un hash di tutti gli scambi avvenuti.

**Creazione del Master Secret**

Il valore del **master_secret** viene calcolato applicando la seguente funzione:
$$
master\_secret =
MD5(pre\_master\_secret || SHA( “A” || pre_master\_secret || client\_random || server\_random) ) \\
|| MD5(pre\_master_secret || SHA( “BB” || pre\_master\_secret || client\_random || server\_random) ) \\
|| MD5(pre\_master_secret || SHA(“CCC” || pre\_master\_secret || client\_random || server\_random) )
$$
> il pre_master_secret viene scambiato tar client e server tramite RSA o D-H
>
Per generare i segreti MAC di scrittura, le chiavi di scrittura e l’IV di scrittura sia per il client che per il server si utilizza il valore del segreto master secondo la seguente funzione hash:
$$
Key\_block =
MD5(master\_secret || SHA( “A” || master\_secret || client\_random || server\_random) ) \\
|| MD5(master\_secret || SHA( “BB” || master\_secret || client\_random || server_random) ) \\
|| MD5(master\_secret || SHA(“CCC” || master\_secret || client\_random || server_random) )
$$
In effetti, possiamo interpretare il **master_secret** come il **seme del generatore** pseudocasuale sopra descritto!

**Differenze TLS/SSL**
In base al tipo di versione cambia l'algoritmo utilizzato per il MAC e le suite crittografiche. Varia il messaggio “certificate_verify”:
* In TLS i codici hash sono calcolati soltanto sul messaggio “handshake_message”
* In SSL i calcoli hash includono anche il valore del “master secret” e i bit di riempimento

**HearthBleed**
Questo protocollo assomiglia a un ping, infatti consente nel mantenere attiva una connessione anche in assenza di trasmissione dati applicazione. Ha il seguente formato:
* Type (1 byte): 1 request, 2 response
* Payload Length (2 bytes)
* Payload (0,216-1), arbitrario
* Padding (>=16bytes), random

In una implementazione di SSL (OpenSSL) è presente la vulnerabilità **HeartBleed**, ovvero nel messaggio è possibile inserire la lunghezza del payload da restituire. Quindi il server prenderà quella lunghezza e restituisce attraverso il replay di Heartbeat i valori relativi alla locazione di memoria, rivelando potenziali segreti in chiaro.

### SSL Socket (SSL programming)
Una struttura Client-Server che comunica tramite SSL è realizzata in questo modo:

La **struttura SSL** è creata ogni volta che si crea una connessione ed eredita le informazioni da **SSL_CTX**

+ **SSL_CTX** è la struttura padre da cui vengono **ereditate** le strutture SSL e contiene **valori di default** e informazioni su **connessioni** e **sessioni** SSL:
+ Default cipher list
+ Session identifier cache
+ Certificate cache
+ Default session identifier time-out period
+ Certificate verification mode and callback
+ Information callback for state transition logging
+ Default **certificate/private key pair**
+ Default read ahead mode
+ Session identifier cache callback

+ **SSL_METHOD**: la libreria interna con metodi e funzioni che implementano le versioni dei vari protocolli (SSL V1,V2,V3, TLS V1)
+ **SSL_SESSION**: una struttura contenente i dettagli del TLS/SSL per la sessione corrente (certificati client e server, chiavi, etc)
+ **SSL_CIPHER**: mantine le informazioni sugli algoritmi per un particolare cipher scelto
* **CERT**: informazioni sul certificato X.509
* **BIO**: un astrazione per generiche operazioni di I/O

Quindi uno **pseudocodice lato Server** (concorrente):
1. Inizializzo *SSL_ctx*
2. Carico il certificato PEM (X.509)
3. Creo la socket del server con *OpenConnection*
4. faccio *Accept* e relativa *fork* sulle richieste in arrivo
5. Creo un nuovo tunnel SSL con *SSL_new(ctx)*
6. Faccio "attach" di SSL alla socket con *SSL_set_fd(ssl, client)*
7. Servo la connessione e ora posso fare *SSL_write* e *SSL_read*

Uno **pseudocodice lato Client** (concorrente):
1. Inizializzo *SSL_ctx*
2. Creo la socket con *OpenConnection*
3. Creo un nuova connessione SSL (*SSL_new*)
4. Faccio "attach" di SSL alla socket (*SSL_set_fd(ssl, server)*)
5. Ora posso fare (SSL_write e SSL_read)

**Funzione InitCTX(void)**

### SSH (Secure SHell)
Sostituito al protocollo Telnet in cui la fase di autenticazione viaggiava in chiaro, SSH risolve questo tipo di problema. In realtà fa molto di più e propone sullo stack **diversi protocolli**:


Nasce per controllare in remoto i dispotivi con diversi tipi di canali:
* **Sessione**
* Esecuzione remota di un programma
* Tipici programmi: shell, applicazioni quali trasferimento file ed e-mail, comandi di sistema, ecc.
* Una volta aperto un canale di sessione, richieste successive sono utilizzate per lanciare in esecuzione il programma
* **X11**
* Fa riferimento al sistema “X Window”, un modulo software di sistema ed un protocollo di comunicazione che forniscono un’interfaccia grafica per nodi di rete
* X consente alle applicazioni di essere eseguite su di un server di rete, ma di essere “mostrate” su un desktop remoto
* **Forwarded-TCP/IP**
* Funzionalità di port forwarding remoto
* **Direct-TCP/IP**
* Funzionalità di port forwarding locale

**Formato dei pacchetti**
* Packet length:
* lunghezza del pacchetto in byte, senza considerare i campi “packet length” e MAC
* Padding length:
* numero di byte generati casualmente ed impiegati come riempimento
* Payload:
* contenuto utile del pacchetto
* prima della negoziazione dell’algoritmo: non compresso
* a negoziazione avvenuta: compresso, qualora negoziato dalle parti
* Random padding:
* a negoziazione avvenuta, contiene byte random di padding, necessari per assicurarsi che la lunghezza totale del pacchetto (campo MAC escluso) sia:
* un multiplo della dimensione del “cypher block”
* 8 byte nel caso di stream cypher

Tra i metodi di **autenticazione** abbiamo:
* Publickey
+ Il client invia un messaggio al server contenente la sua chiave pubblica e firmato con la sua chiave privata
+ Alla ricezione del messaggio, il server verifica che la chiave sia accettabile per l’autenticazione in caso affermativo, verifica che la firma sia corretta
* Password
* Il client invia un messaggio contenente una password in chiaro, ma protetta crittograficamente dal **protocollo TLS sottostante**
* Hostbased:
+ L’autenticazione viene effettuata sull’host del client piuttosto che sul client (cioè, sull’utente) vero e proprio
+ Il client invia una **firma creata con la chiave privata dell’host** da cui si collega al server
+ Piuttosto che verificare l’identità dell’utente, il server SSH verifica l’**identita dell’host**

#### Port Forwarding
Tramite SSH è anche possibile effettuare il **Port Forwarding**:
Possiamo realizzare l'**SSH Tunnelling** convertendo una connessione TCP non sicura in una corrispondente sessione SSH. Posso assegnare anche i porti in maniera opportuna relativamente ai protocolli che voglio incapsulare.

* **Local:**
* connessioni dal **client** SSH sono inoltrate **tramite il server** SSH **verso un server** SSH remoto
* il client configura un processo “hijacker”, il quale:
* intercetta il traffico dell’applicazione non sicura
* lo redirige dalla connessione TCP (non sicura) verso un tunnel SSH (sicuro)
* all’altro capo del tunnel, il server SSH smista il traffico in ingresso alla porta destinazione indicata dall’applicazione client

* **Remote:**
* connessioni dal **server** SSH sono inoltrate **tramite il client** SSH **verso un server** SSH remoto
* il client SSH dell’utente funge da server
* riceve traffico con una determinata porta destinazione
* lo “assegna” alla porta corretta
* lo invia alla destinazione scelta dall’utente
* consente, ad esempio, di collegarsi, dal proprio server SSH, ad un computer nella propria Intranet aziendale!


## Web Hacking
* Reflected e DOM based Cross-Site Scripting (come funziona XSS e in quali modi? inietto codice JS)
* Cross-Site Request Forgery
* HTTP Response Splitting e Cache Poisoning: Si sfuttano input malformati per inserire due richieste HTTP consecutive, si può usare per avvelenare la cache

### Cross-Site Scripting (XSS)
Vulnerabilità legata ad imperfezioni nella validazione dei dati di input/output nelle applicazioni web. In questa tipologia di attacchi tipicamente, il target non è l’applicazione web, ma piuttosto gli altri utenti dell’applicazione stessa. (eg. applicazione web che offre una funzionalità di tipo “bacheca” di messaggi, dove un utente malevolo posta un messaggio contenente codice eseguibile (script); il browser di un utente target alla lettura del messaggio, lo interpreta ed esegue loscript di attacco! )

* **Stored XSS**: quando lo script malevolo è salvato sul server bersaglio attraverso qualche form (commenti, messaggi etc). Questo verrà eseguito in un secondo momento sulla macchina della vittima
* **Reflected XSS**: quando lo script è immediatamente restituito attraverso messaggi d'errore o risultati di ricerca senza che questi vengano salvati
* **DOM Based XSS**: Sfrutta la possibilità di scrivere nei DOM (Document Object Model) in maniera non safe, modificando il modo in cui viene renderizzata la pagina dal browser del bersaglio. Viene quindi renderizzata localmente una pagina versione dalla pagina con script malevolo al suo interno.

**Contromisure**
Filtraggio dei parametri di input, alla ricerca di caratteri speciali:
+ Caratteri da evitare (per quanto possibile): <, >, (?), #, ‘’
+ Codificare l’output in HTML, così da rendere i dati dell’applicazione (quanto più possibile) innocui per i successivi utenti del sistema (alternativa “drastica”)
+ Usare cookie del tipo “HttpOnly”: impossibilità di accedere al cookie via script!

### Cross-Site Request Forgery (CSRF)
Molte applicazioni web stabiliscono con gli utenti sessioni persistenti, autenticate, di lunga durata
Se un attaccante riesce a “convincere” il browser di un utente target a sottomettere una richiesta verso il server, egli può:
+ sfruttare la sessione persistente esistente tra il client target ed il server
+ effettuare azioni “in vece” del client target
+ modifica di password
+ acquisto di beni e servizi
+ esecuzione di bonifici o altri tipi di trasferimenti di denaro


> impatto attacco

**Contromisure**
Legare una richiesta in ingresso ad una sessione autenticata tramite una *nonce*. Ovvero introdurre valori random (collegati alla sessione in corso) per le richieste generate ed inviati all’utente finale
+ Se una nuova richiesta non contiene uno di tali valori posso:
+ rifiutare l’esecuzione dell’azione corrispondente o chiedere all’utente finale una riconferma mediante rinnovo dell’autenticazione

Oppure solito approccio: constrain, reject, **sanitize** (l’ultimo punto è particolarmente importante in questo caso)

### Http Response Splitting
Si basa su un'errata validazione dell’input da parte dell’applicazione web (mandando una richiesta ricevo due risposte), l’attaccante fa in modo che dati malevoli giungano (tramite una richiesta HTTP) ad un’applicazione vulnerabile. L’applicazione include (parte di) tali dati nell’header di una risposta HTTP.
Perché l’attacco abbia successo occorre che l’applicazione consenta dati di ingresso contenenti “*Carriage Return*” (CR, rappresentato anche come %0d o \r) e “*Line Feed*” (LF, %0a, o \n) nell’header della richiesta; la piattaforma sottostante sia vulnerabile all’iniezione di questo tipo di caratteri.
Scopo di questo vulnerabilità non è l'attacco, bensì un modo per rendere possibile altri attacchi. È possibile eseguire script, rubare cookie, fare redirection, etc.

#### Server Side Includes
Estensioni presenti in alcune web application ed utilizzate per inserire contenuti dinamici all’interno delle pagine web (esecuzionne di programmi da remoto).
Il server web analizza le direttive SSI prima di fornire la pagina di risposta all’utente finale, tipiche “feature” (o tag) SSI: “echo”, “include”, “exec”, “config”, “odbc”, “email”, “if”, “goto”, “label”, “break”, ecc.
Gli attacchi SSI consentono agli attaccanti di iniettare script nelle pagine HTML, o di eseguire, sul server, frammenti arbitrari di codice.

L’exploit avviene, solitamente:
+ manipolando codice SSI già presente in una pagina della web application
+ forzando l’esecuzione di “nuovi” script SSI attraverso opportuni campi di input

## Buffer Overflow
* Buffer Overflow sullo stack e tecniche di difesa
* Tecnica del canarino, quali problemi ha? dove lo conservi?
* Heap Overflow, (metto la shellcode nelle variabili)
* Approccio Return to System Call

### Tecninca del Buffer Overflow
Il **Buffer Overflow** è una condizione che avviene in un'interfaccia nella quale più input possono essere inseriti in un'area di memoria, rispetto alla capacità allocata. Sovrascrivendo cosi altre informazioni. Gli attaccanti sfruttano questa condizione per far crashare un sistema o iniettare codice che gli permette di ottenere il controllo.

Il buffer overflow può avvenire in diverse aree di memoria:
* su **Stack**
* su **Heap**
* nell'**Area dati** (più difficile)

Conseguenze:
+ Corruzione dei dati di un programma
+ Trasferimento del controllo
+ Violazioni sull'accesso di memoria
+ Esecuzione di codice scelto dall'attaccante

Per **identificare programmi vulnerabili** utilizziamo diverse tecniche:
* ispezione del codice sorgente
* tracing (attach di un debugger al processo con input )
* fuzzing

I linguaggi di livello più alto (Python, java, ...), al costo di un leggero overhead, sono immuni al buffer overflow. Linguaggi come C sono vulnerabili se utilizzati impropriamente.

Riprendiamo alcuni concetti sulla memoria, sfruttiamo questa vulnerabilità quando il buffer è allocato sullo stack (*stack smashing*). Quando una funzione ne chiama un'altra è **necessario salvare l'indirizzo di ritorno** proprio nello stack, inoltre c'è la necessità di salvare i parametri utilizzati dalla funzione chiamante sempre in area stack.

**Esempio**

void hello(char *tag)
{
char inp[16]; //stringa di 16 byte da riempire
printf("Enter value for %s: ", tag);
gets(inp);  /* funzione della libreria stdin vulnerbile
             * perchè accetta tutti i caratteri indipendentemente 
             * dalla size definita dalla variabile in input */
printf("Hello your %s is %s\n", tag, inp);
}

**Output**

$ ./buffer2
Enter value for name: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Segmentation fault (core dumped)

>Nella **prima esecuzione** digitando XXX... utilizziamo più dei 16 byte consentiti generando un *segmentation fault*

$ perl -e 'print pack("H*", "41424344454647485152535455565758616263646566676808fcffbf948304080a4e4e4e4e0a");' | ./buffer2
Enter value for name:
Hello your Re?pyy]uEA is ABCDEFGHQRSTUVWXabcdefguyu
Enter value for Kyyu:
Hello your Kyyu is NNNN
Segmentation fault (core dumped)

> Nella **seconda esecuzione** tramite la funzione *print pack* di perl utilizziamo i caratteri esadecimali per tradurli in lettere (ex 41=A), successivamente inseriamo il valore della locazione di memoria e8fcff.. sovrascrivendo di fatto il valore del **frame pointer** e forzando l'esecuzione di nuovo alla *funzione hello*
> Notiamo che il frame pointer è cambiato dopo l'esecuzione del programma (a destra), e fa riferimento proprio alla prima locazione di memoria del programma *hello*.

**Contromisure**

Abbiamo due principali strategie di difesa:
* **Compile-time**: mira a irrobustire i programmi che verranno eseguiti
* **Linguaggi moderni**: i linguaggi ad alto livello non sono vulnerabili ad attacchi di tipo buffer overflow, infatti vengono forzati controlli sui range ammissibili per gli indirizzi di memoria
* *Svantaggi*: oltre l'overhead dei vari controlli che faccio, perdo l'accesso diretto alle risorse hardware
* **Tecniche di coding Safe**: utilizzo tecniche automatizzate di ispezione del codice
* **Utilizzo di librerie Safe**: come in BSD, posso utilizzare librerie dinamiche come *libsafe* che permettono di sostituire primitive vulnerabili come gets, scanf, etc. con funzioni che impongono controlli sulla quantità di memoria da allocare. Basta sostituire le librerie vulnerabili con quelle safe e ricompilare.
* **Random Canary**: faccio un controllo di integrità sullo stack, oltre ai normali parametri alloco un'area random generata dal canarino. In questo modo se un attaccante sovrascrive anche il canarino, troverò che l'informazione di ritorno non coincide con quella inserita; faccio abort. Il canarino può essere salvato in area dati (variabili globali) per irrobustire la sua capacità.
* **Stackshield e RAD (Return Address Defender)**: è un'estensione di GCC che prevede di proteggere il return address scrivendolo in una locazione safe. Su ogni exit fa il controllo del return address
* **Run-time**: mira a rilevare e fare abort di programmi già exploitati
* **Executable Address Space Protection**: meccanismo che richiede la MMU, la quale virtualizza la memoria in regioni dove non è possibile eseguire codice. In pratica blocca via hardware la scrittura a certe aree di memoria restituendo un abort.
* **Address Space Randomization**: è un meccanismo che manipola la posizione di strutture dati critiche all'interno di stack, heap e dati globali. Viene applicato uno *spiazzamento random* per ogni processo, sacrificando un po' spazio degli indirizzi che può essere trascurato su sistemi moderni. (possono essere randomizzate anche le posizioni delle std libraries)
* **Guard Pages**: tra i vari blocchi di memoria utilizzati tipicamente in maniera contigua, si lacia spazio con pagine di guardia in cui non è possibile effettuare l'accesso. Anche in questo caso utilizziamo un supporto hardware per contrassegnare queste pagine come avviene per MMU. Costo aggiuntivo in termini di esecuzione quando sono mappate un grande numero di pagine
### Random canary
Random Canary: faccio un controllo di integrità sullo stack, oltre ai normali parametri alloco un’area random generata dal canarino. In questo modo se un attaccante sovrascrive anche il canarino, troverò che l’informazione di ritorno non coincide con quella inserita; faccio abort. Il canarino può essere salvato in area dati (variabili globali) per irrobustire la sua capacità.
### Heap Overflow

Nell'Heap Overflow attacchiamo la struttura dati heap che tipicamente si trova sopra l'area di codice. È utilizzata per allocare strutture dati dinamicamente. Di conseguenza non abbiamo alcun *indirizzo di ritorno da manipolare*, ma possiamo avere dei *puntatori a funzioni* da sfruttare.

Per *difendersi* da queste tipologie di attacchi pssoamo utilizzare le solite precauzioni: rendere l'heap *non eseguibil*e, e *randomizzare* l'allocazione sull'heap.

/* record type to allocate on heap */
typedef struct chunk {
char inp[64]; /* vulnerable input buffer */
void (*process)(char *); /* pointer to function to process inp */
} chunk_t;

void showlen(char *buf)
{
int len;
len = strlen(buf);
printf("buffer5 read %d chars\n", len);
}

int main(int argc, char *argv[])
{
chunk_t *next;
setbuf(stdin, NULL);
next = malloc(sizeof(chunk_t));
next->process = showlen;
printf("Enter value: ");
gets(next->inp);
next->process(next->inp);
printf("buffer5 done\n");
}

> Si esegue uno stack overflow tramite la vulnerabilità della funzione *gets*. Questa volta però essendo il puntatore next->inp allocato dinamicamente tramite la funzione malloc, non sovrascriviamo il frame pointer, ma sovrascriviamo il puntatore alla funzione (* process) che verrà eseguita subito dopo.
> Quindi nel caso stack overflow sovrascrivo il frame pointer per reindirizzare il program counter al codice malevolo. Nel caso heap overflow sovrascrivo l'area dati heap (a partire da uno stack overflow su dati allocati dinamicamente o variabili globali) ed eseguirò il codice malevolo proprio in quest'area

Le stesse tipologie di attacco possono essere eseguite anche sull'**area dati globale**.

### Approccio Return to System Call
**Return to System Call**: è una variante dello stack overflow che sostiutuisce il return address con una *funzione di libreria standard*. Se lo stack è protetto le uniche aree di memoria cui si potrà accedere sono proprio quelle relative alle librerie. Per sovrascrivere una libreria quello che si fa è passare dei parametri malevoli alla libreria stessa ad esempio posso inserire /bin/sh come parametro e chiamare la funzione system exec.

## Malware
* Differenza tra Virus e Trojan
* Sandboxing di Malware (Generic Decryption)
### Virus

È un software che *infetta i programmi*, li modifica per includere una copia del virus, si replica e continua a infettare altri contenuti, si diffonde facilmente negli ambienti di rete.
Se collegato a un programma eseguibile un virus può fare qualsiasi cosa il programma può fare, il virus viene eseguito segretamente quando viene eseguito il programma host. È specifico per i sistemi operativi e l'hardware su cui viene eseguito.
Le fasi di un virus sono:
* **Fase inattiva**: il virus è inattivo e lo sarà fino al verificarsi di un evento (non tutti i virus hanno questo compartamento)
* **Fase di Trigger**: il virus è attivato per eseguire la funzione per cui era previsto, può essere causato da vari eventi di sistema
* **Fase di propagazione**: il virus inserisce una copia di se stesso in altri programmi o in alcuni aree di sistema sul disco, potrebbe non essere identico alla versione propagante. Ogni programma infetto contiene un clone del virus che entrerà in fase di Trigger
+ **Fase di esecuzione**: la funzione viene eseguita e può essere innocua o dannosa

begin (* main action block *)
attach-to-program;
if trigger-condition then execute-payload;
goto main;
end;

>Il virus tramite attach si collega ad un programma e se si verifica un particolare evento (fase di trigger) viene attivato

**Classificazione**

* **Per bersaglio**
* Boot Sector Infector: infetta la MBR e parte quando il sistema stesso è avviato
* File Infector: Infetta i file eseguibili
* Macro Virus: sfrutta le macro e gli script interpretati da altre applicazioni (ex. MS Office)
* Multipartite Virus: infetta i file in diversi modi
* **Per strategia di occultamento**
* Virus Criptati: criptano se stessi con una chiave
* Virus Stealth: esplicitamente progettati per nascondersi dagli anti-virus
* Virus Polimorfi: muta ad ogni infezione
* Virus Metamorfi: muta e si riscrive completamente ad ogni infezione cambiando anche comportamento

### Worms

Programma che cerca attivamente altre macchine da infettare, e a loro volta queste macchine serviranno da trampolino per altri attacchi ad altre macchine. Sfruttano vulnerabilità software dei sistemi attaccati, e si **replicano** attraverso diversi modi:
* E-mail: Si inviano da soli tramite mail
* File sharing: infettano file che verranno condivisi
* Remote execution: esegue se stesso su un'altra macchina remota
* Remote file transfer: copia se stesso su un'altra macchina remota
* Remote login: si diffonde tramite login su un'altra macchina remota

I worm fanno **target discovery** in diversi modi:
* Random: invia probe casualmente ad indirizzi presenti nello spazio IP
* Hit-List: genera prima una lista di potenziali macchine vulnerabili
* Topological: fa una scansione topologica della rete partendo da se stessa
* Local Subnet: cerca host nella rete locale che stanno dietro un firewall altrimenti inaccessibile dall'esterno

Tra i worm più famosi il primo è **Morris Worm** (1988) per sistemi UNIX. Crackava le credenziali locali per diffondersi sulla rete locale sfruttando una vulnerabilità di *finger*.

**Mobile Code**
Programmi che possono essere spediti, **cosi come sono scritti**, su una varietà di piattaforme. Può essere trasmesso da un sistema remoto a un sistema locale e quindi eseguito sul sistema locale, spesso funge da innesco per un virus, un worm o un Trojan. I veicoli di infezione più popolari includono applet *Java*, *ActiveX*, *JavaScript* e VBScript; proprio perchè non dipendono dal particolare hardware su cui vengono eseguiti. Il primo worm per smartphone è stato Cabir, diffuso tramite connessioni wireless Bluetooth o MMS. Permette di disabilitare completamente il telefono, eliminare i dati o imporre al dispositivo di inviare messaggi.

**Drive-by-Downloads**
Sfrutta le **vulnerabilità del browser** per il download e installa malware sul sistema quando l'utente visualizza una pagina Web controllata dall'aggressore. Nella maggior parte dei casi non si propaga attivamente, ma si diffonde quando gli utenti visitano la pagina Web dannosa.

**Clickjacking**
Vulnerabilità utilizzata da un attaccante per raccogliere informazioni. Un utente può essere *indotto a digitare la password* dell'e-mail o conto bancario, ma digitandola in un invisibile frame controllata dall'attaccante. Sfrutta Adobe Flash, o JavaScript ad esempio posizionando un pulsante sotto o sopra ad un pulsante legittimo che lo rende difficile da rilevare.
Per attacchi di questo tipo si utilizzano tecniche di social engineering come spam tramite email o Trojan horse.

### Contromisure malware
La soluzione ideale è la *prevenzione* nello specifico applicare policy e awareness, e mitigare le vulnerabilità e i threat. Altrimenti se la prevenzione fallisce applico: Detection &rarr; Identification &rarr; Removal.

**Antivirus**
Gli **antivirus** si sono molto evoluti nel tempo. All'inizio erano semplici scanner per firma, poi si è passato alle euristiche. Le ultime iterazioni includono diversi meccanismi di protezione incluse le *activity traps*, che monitorano le azioni compiute dai programmi in esecuzione.

L'approccio **Generic Decryption** consente al programma antivirus di rilevare facilmente virus *polimorfici* complessi e altri malware mantenendo alte velocità di scansione. Usa una aproccio di tipo **sandboxing**, tramite uno scanner GD che contiene i seguenti elementi:
+ Emulatore CPU
+ Scanner delle firme antivirali
+ Modulo di controllo dell'emulazione

L'approccio **Host based Behaviour-blocking** monitora in real-time le azioni dei software bloccandole prima di compromettere il sistema

L'approccio **Perimeter Scanning** posiziona sul perimetro della rete un antivirus che può bloccare comportamenti sospetti (eg. IDS)

## DoS
* Che tecniche può usare TCP per evitare attacchi DoS? SYN Cookie nel Sequence Number del Server
* Attacco Slowloris
### SlowLoris
**Hypertext Transfer Protocol (HTTP) Attacks**:
Mando un gran numero richieste legittime verso un servizio che utilizza HTTP (tipicamente un web server) consumando lato server un gran numero di risorse. Si può fare anche Spidering dove dei bot seguono i link di una pagina web in maniera ricorsiva.
L’attacco **Slowloris** fa in modo che un server riceva un flusso di richieste sufficiente per saturare il pool massimo che può gestire, in particolare manda delle richieste http che non terminano, senza il carattere di terminazione \n (intepretate come legittime). Spesso Slowloris non viene riconosciuto dagli IDS.

## IDS
* IDS e approcci
* Anomaly Detection e Signature Detection (pro e contro delle due tecniche)
* SNORT (cos'è? Regole?)
### IDS & SNORT
Un servizio di sicurezza che monitora e analizza gli eventi di sistema allo scopo di trovare, e fornire avvisi quasi in tempo reale, di tentativi di accesso non autorizzato alle risorse di sistema.

> Addirittura l'IETF mette a disposizione degli RFC dove sono definiti i formati per lo scambio e i protocolli per lo scambio di messaggi per l'Intrusion Detection.

Comprende tre componenti logiche:
* **Sensori**, collezionano dati
* **Analizzatori**, determinano se l'intrusione è avvenuta
* **Interfaccia utente**, mostra l'output o il comportamento del sistema di controllo

Esistono **due principali approcci**:
* **Anomaly Detection**, utilizza una collezione di dati relativi al comportamento di utenti legittimi per il sistema, rileva quindi anomalie basandosi su diversi approcci:
* *Approccio Statistico*
* *Knowledge based* (richiede esperti di sistema)
* *Machine-learning*
* **Signature/Heuristic detection**, utilizza una serie di modelli basati su dati di attacchi noti per confrontarli con il comportamento corrente del sistema (può solo identificare comportamenti anomali di cui si ha una regola)
* *Signature approaches*: effettua un matching di grandi collezioni di pattern già conosciuti per minimizzare il tasso di falsi positivi. Ampiamente usato dagli anti-virus, proxy di scansione del traffico di rete e in NIDS.
* *Rule-based heuristic identification*: utilizza delle regole per identificare attacchi noti. Le regole identificano quindi situazioni sospette e sono specifiche per ogni tipologia di sistema.
* **SNORT** è un NIDS rule-based, in accordo all'approccio di tipo signature detection, questo sistema può essere installato dietro un firewall e funziona da sniffer o packet logger, per individuare pacchetti sospetti attraverso regole (PulledPork fa pull di regole pre-fatte), può anche essere adoperato come un IPrevention System. Una regola SNORT è composta da:
* Action
* Alert
* Drop
* Reject (manda TCP RESET)
* Protocol (TCP, UDP, ICMP, IP)
* Source IP
* Ports
* Direction (entrata/uscita)
* Destination IP
* Ports

Esistono tre tipologie di IDS:
* **Host-Based IDS** monitora le caratteristiche di un singolo host per rilevare attività sospetta. Viene inserito un livello software aggiuntivo per la sicurezza.
* Data Sources e Sensori: per rilevare attacchi si monitorano le system call, i logfile e le checksum dei file
* **Network-Based IDS**, monitora il traffico sulla rete per tutto lo stack protocollare allo scopo di identificare attività sospetta. Utilizza dei *sensori sparsi sulla rete* in modalità promiscua e dei server per la raccolta dei dati.
* Con la *Signature Detection* posso riconoscere attacchi a livello applicativo, di trasporto e di rete
* Con la *Anomaly detection* posso riconoscere i DoS, Scanning e worms
* Nello specifico la *Stateful Protocol Analysis* compara il traffico con dei profili messi a disposizione dai vendor (la ground truth mi è fornita). Usa molte risorse.
* Un NIDS tiene traccia di: timestamps, Soruce e Destination IP, Porti, ...
* Esistono anche **Hybrid IDS**, che sono un approccio misto

## Firewall
* Firewall, per evitare flooding, per evitare ADT (APT?) onerosi?