1. IP-Sec Vulnerability
Dott. Ing. Marco Ramilli
Introduzione.
Durante gli anni ottanta, per la precisione il 13 gennaio 1983 (anno dell
ufficializzazione del protocollo TCP/IP), la sicurezza informatica non era una
‘scienza’ ben definita, pertanto durante la creazione del protocollo piu’ famoso al
mondo non tennero conto delle sei parole che oggi fanno tremare qualsiasi security-
manager. RAIDAN è l’acronimo di: ‘Riservatezza Autenticazione Integrità
Disponibilità Autorizzazione Non ripudio’ sono le principali caretteristiche che un
protocollo sicuro deve essere in grado di gestire al meglio. L’enorme errore che si
fece durante la creazione del TCP/IP (non si vuole accusare nessuno ma soltanto
sottolineare quanto al tempo non si fosse pronti a problemi riguardanti la sicurezza
informatica) porto’ in seguito ad applicare diversi sistemi di sicurezza in tutto lo stack
di rete:
• A livello applicativo venne creato il PGP
• A livello sessione applicarono TLS/SSL
• A livello di rete venne creato il protocollo IPsec
Il compito fondamentale di tale protocollo è quello di proteggere i dati durante la
transazione da una macchina all’altra, esso non risolve tutti i problemi di sicurezza di
fatto mira a risolvere i problematiche legate allo ‘sniffing’ e al ‘Man In The Middle’.
1. I Protocolli.
IPsec in realtà è una serie di protocolli atti a rendere sicura la transazione di dati da
una macchina ‘A’ verso una macchina ‘B’, essi sono parte integrante del protocollo
IPv6 ma possono essere implementati anche come estensione di IPv4.
• AH (Autentication Header) è un protocollo della suite IPsec che garantisce
Autenticazione ed Integrità
• ESP (Encapsuling Security Payload ) è un protocollo della suite IPsec che
garantisce Riservatezza Autenticazione Integrità
• IKE (Internet Key Exchange) è un protocollo della suite IPsec atto allo
scambio di chiavi
1

2. Per poter utilizzare il protocollo AH oppure ESP i due host remoti devono avere
negoziato una SA (Security Association) la quale rappresenta un “contratto” che
specifica gli algoritmi crittografici e le chiavi utilizzate per rendere la comunicazione
sicura. Tale contratto viene stipulato grazie al’ IKE con il quale è possibile
concordare le rispettive chiavi di crittografia.
1.1 Security Association.
Senza reintrodurre il concetto di SA definiremo una Security Association come
l’insieme di tre concetti fondamentali:
1) Security Parameter Index (SPI)
2) Ip Destination address (IPD)
3) Securit Protocol (AH o ESP)
Esistono due particolari tipi di SA (in base alle combinazioni):
1) Tunnel SA
2) Transport SA
La TuSA è considerata come un IP Header esterno che esprime come il pacchetto
deve essere processato dal ‘IPsec’ in ricezione, esso protegge tutti i dati inviati a
livello di rete, mentre la TrSA non protegge tutti i dati essa è un ‘semplice’ accordo
tra due host atto a proteggere opzioni dell header IP.
Un ruolo rilevante nel SA è in possesso dalle due basi dati:
1) SPD (Security Polici DataBase): è ingrado, grazie alla presenza di
particolari selettori, di affermare quali trasformazioni vadano applicate a
quale particolare traffico.
2) SAD (Security Association DataBase): contiene tutti i dati relativi alle SA
come; Chiavi, parametri, standard crittografici ecc..
Grazie a questi due DB, è possibile associare ad ogni particolare IP una struttura di
sicurezza differente, in questo modo è possibile avere piu’ ‘tunnel’ (questa parola non
è da intendere come tunnel-IPsec, ma come modo per rendere sicura una
comunicazione; di fatto la comunicazione puo’ essere ‘Tunnel’ o ‘Trasport’) aperti
contemporaneamente verso l’esterno.
Poiché all’interno di una SA viene riportato IP address destinazione (il sorgente è ben
noto, chi invia conosce il proprio address) ogni SA è in grado di proteggere una sola
2

3. direzione in una comunicazione full-duplex ergo sono necessarie due SA per
proteggere totalmente una comunicazione full-duplex.
SPD SAD
Come Cosa
Proteggere Proteggere
Il settaggio a mano di una SA è molto rischioso in quanto è veramente probabile
generare errori involontari, ogni singolo parametro di una Virtual Private Network
(chiamata cosi grazie all’ opzione di tunneling di IPsec) deve necessariamente essere
contrattato immediatamente prima della connessione; ma come è possibile cambiarsi
le chiavi senza avvalersi di una comunicazione già criptata ?
Per risolvere questo problema è stato crato l’ IKE.
1.2 Internet Key Exchange.
L’ IKE è un protocollo di livello Applicazione il quale ha il compito di negoziare le
Chiavi crittografiche per formare una SA la quale a sua volta darà direttive ai
protocolli AH/ESP su come agire in quella particolare condizione.
L’ HandShake avviene in due fai distinte :
1) Si crea una SA per l’ IKE stesso (spesso chiamata IKE SA o ISAKMP )
2) Sfruttando la IKE SA si creano le SA IPsec (nel caso si voglia coprire per
intero una comunicazione full-duplex)
All’interno della ISAKMP, vengono definite le procedure ed i formati dei pacchetti
per stabilire, negoziare, modificare e cancellare una SA. Essa fornisce inoltre
un’architettura di riferimento per la gestione delle chiavi, indipendente dal protocollo
utilizzato per o scambio delle stesse, dal metodo di autenticazione nonché dagli
algoritmi crittografici ipegati. Attualmente ISAKMP preede l’uso combinato di due
protocolli:
1) OAKLEY : un protocollo con il quale due parti autenticate possono
giungere ad un accordo circa quale chiave utilizzare.
2) SKEME : un protocollo simile al precedente, ma IKE di questo protocollo
sfrutta la caratteristica di crittografia a chiave pubblica ed il rinnovo veloce
di chiave.
3

4. Un elemento molto importante da notare è che IKE è un protocollo assolutamente
generico, esso potrebbe essere utilizzato per la creazione di una SA per differenti
protocolli, vi è quindi la necessità di introdurre un Dominio (Domain of
Interpretation) DOI. Il DOI da noi utilizzato è quello standard è per quello che fino
ad ora non ne avevamo accennato l’esistenza, pertanto si continuerà a parlare di IPsec
e non di IPsec DOI (nel quale andrebbe specificato i dominio di appartenenza)
Di seguito un semplice disegno illustrativo sul funzionamento dell’ IKE.
Figura 1.2.1: Protocollo IKE
4

5. 1.3 Autentication Header.
Il protocollo AH protegge l'integrità del datagramma IP, calcola un HMAC (rfc
2104) del pacchetto in base ad una chiave segreta, al payload e le parti del header IP
che non possono cambiare, ad esempio i campi con gli indirizzi IP. Quindi aggiunge
l'header AH all'header del pacchetto.
Figura 1.3.1: Autentication Header
L'header AH è lungo 24 bytes. Il primo byte è detto Next Header, contiene il
protocollo dell'header seguente. In tunnel mode viene incapsulato un intero
datagramma IP: il valore di questo campo è dunque 4. Quando invece in transport
mode viene incapsulato un pacchetto TCP, il valore è 6. Il byte seguente indica la
lunghezza del payload. Quindi vi sono 2 byte riservati. Seguono 32 bit contenenti il
Security Parameter Index (SPI), che indicano quale SPI utilizzare per interpretare
correttamente il pacchetto al momento della ricezione. I successivi 32 bit sono per il
Sequence Number, per proteggersi da attacchi di tipo replay. Infine gli ultimi 96 bit
contengono l'hash message authentication code (HMAC). Quest'ultimo protegge
l'integrità del pacchetto poichè solo chi conosce la chiave segreta può crearlo e
verificarne l'esattezza.Poichè il protocollo AH calcola l'HMAC in base ad alcune
parti non mutabili del datagramma IP, tra le quali gli indirizzi, il NAT non si sposa
bene con IPsec. Il Network address translation (NAT) sostituisce infatti un IP (di
solito il sorgente) con uno differente. Quindi l'HMAC viene invalidato subito.
Un'estensione al protocollo detta NAT-Traversal extension riesce però a superare
questa limitazione.
5

6. 1.4 Encapsule Secure Payload.
Il protocollo ESP può garantire sia l'integrita di un pacchetto utilizzando HMAC sia
la confidenzialità della trasmissione utilizzando la cifratura. Dopo aver cifrato il
pacchetto e calcolato l'HMAC viene generato ed aggiunto l'header ESP.
Figura 1.4.1: ESP Header
I primi 32 bit sono il Security Parameter Index (SPI), indicano quale SA utilizzare
per interpretare correttamente il pacchetto ESP al momento della ricezione. I
successivi 32 bit contengono il Sequence Number, per proteggersi da attacchi di tipo
replay. Seguono 32 bit per l'Initialization Vector (IV), utilizzato durante le operazioni
di cifratura. Gli algoritmi di crittografia simmmetrica sono vulnerabili ad attacchi
statistici se non viene utilizzato un IV. Quest'ultimo infatti assicura che due payload
in chiaro identici producano due versioni cifrate differenti.Psec utilizza cifrari a
blocchi per il processo di cifratura. Dunque il payload deve essere completato
(padding) nel caso in cui non risulti un multiplo della dimensione del blocco. Quindi
6

7. la lunghezza dell'eventuale pad viene inserita nell'header. Subito dopo 2 byte indicano
quale sia l'header del protocollo sottostante, Next Header. Infine vengono aggiunti 96
bit con l'HMAC per garantire l'integrità del pacchetto. L'HMAC è calcolato sul
payload, l'header IP non viene considerato.L'utilizzo del NAT non rende inutilizzabile
il protocollo ESP. Ma nonostante questo il NAT nella maggior parte dei casi non può
essere utilizzato in combinazione con IPsec. Il NAT-Traversal è una possibile
soluzione al problema incapsulando i pacchetti all'interno di pacchetti UDP.
1.5 Modalità.
Nella modalità “trasporto”, possibile soltanto tra host, gli Header HA/ESP vengono
inseriti tra l’header IP e quello di trasporto (nella fattispecie TCP).Nella seguente
figura tratta dalle slide di Davide Cerri viene evidenziato come agisce la modalità
trasporto.
Figura 1.5.1: Modalità Trasporto
7

8. Di seguito viene fornito un diagramma esplicito di IPsec in HA transport mode, esso
mette in evidenzia come avviene la creazione del nuovo Header IP.
Figura 1.5.2: IP Header Evolution in HA Transport mode
Di seguito viene fornito un diagramma esplicito di IPsec in ESP transport mode, esso
mette in evidenzia come avviene la creazione del nuovo Header IP.
Figura 1.5.3: IP Header Evolution in ESP Transport mode
8

9. Nella modalità Tunnel, il pacchetto IP originale viene incapsulato in un nuovo
pacchetto IP. Nel seguente disegno tratto dalle slide di Davide Cerri viene
evidenziato come agisce la modalità tunnel.
Figura 1.5.4: Modalità Tunnel
Analogamente vengono forniti I diagrammi illustrativi sul relativo cambiamento del
pacchetto IP. Di seguito viene fornito il diagramma esplicito di come avviene la
trasformazione del pacchetto IP utilizzando IPsec HA in Tunnel mode.
Figura 1.5.5: IP Header Evolution in HA Tunnel mode
9

10. Di seguito viene fornito un diagramma esplicito di IPsec in ESP tunnel mode, esso
mette in evidenzia come avviene la creazione del nuovo Header IP.
Figura 1.5.6: IP Header Evolution in ESP Tunnel mode
Come si puo’ notare nei datagram soprastanti, non esiste un campo specifico di
“modalità” per distinguerese se siamo di fronte ad un tunneling o ad un trasport IPsec.
Come distinguere allora le due differenti comunicazioni ?
La distinzione è possibile grazie al caampo ‘NEXT’, se tale campo ha come valore la
stringa “IP” allora significa che il protocollo seguente è l’ IP(3 stack OSI), pertanto si
è inglobato tale protocollo all’interno dell Header IPsec: siamo in Tunneling mode.
Diferentemente se all’interno di tale campo troviamo stringhe differenti “TCP”,
“UDP”,ecc.. significa che l’header IPsec è stato assimilato all’interno dell header IP
pertanto saremo in presenza del Transport mode.
1.6 HA and NAT.
Un NAT, Network Address Tranlsation viene impegato per mappare un vasto range di
IP privati avendo a disposizione pochi IP pubblici, per fare questo deve modificare ‘al
volo’ l’header IP del pacchetto. Le modifiche medie che effettua sono 3:
1) Modifica l’indirizzo IP del destinatario
10

11. 2) Modifica l’indirizzo IP del mittente
3) Modifica il Time To Live (TTL)
Nel miglior caso possibile (nel caso in cui il pacchetto sia indirizzato al NAT stesso)
esso deve manipolare solamente il TTL che comunque è parte dell Header IP.
Modificando tali campi, ogni NAT deve forzare il ricalcolo del CheckSun dell’header
il quale varia in base al ‘valore’ dell’header stesso. Il protocollo HA non tiene conto
del cambiamento del TTL durante il calcolo dell’integrity check (inquanto esso
cambia ad ogni router incontrato) ma tiene fortemente conto (per risolvere il problema
di spoofing) del cambiamento dell’ IP-address, pertanto se il NAT modificherà tale/I
campi il pacchetto giunto a destinazione non riuscirà a passare il controllo di integrità
e verrà scartato dal ricevente. In realtà il problema è ben più vasto in quanto spesso e
volentieri un NAT non modifica solo gli IP-address e il TTL ma modifica anche il
numero di port a cui connettersi e cosi via. Pertanto è necessario utilizzare un NAT
leggermente piu’ intelligente per poter modificare, per risolvere tale problema è nato
un nuovo protocollo per il NAT, chiamato NAT-Traversal (rfc 39487).
1.7 Vulnerabilità.
Utilizzando il protocollo ESP in Tunnel mode, il pacchetto IP viene criptato
totalmente e successivamente utilizzato dal Payload per la creazione del nuovo
pacchetto da inviare (outer packet), il protocollo ESP utilizza una cifratura di tipo
CBC-mode per criptare il pacchetto, non utilizzando nessuna protezione di integrità,
è possibile sostituire in blocco tutto il pacchetto criptato eseguendo un injection di
dati. Modificando con attenzione definite porzioni dell’ outer packet un attaccante
puo’ effettivamente controllare I cambiamenti dell’ header dell’ inner packet (Quello
cifrato). Piu’ in dettaglio un attaccante puo’ :
• Modificare la destinazione del pacchetto (IP-Spoofing)
• Modificare le opzioni dell intestazione IP
• Modificare campi del protocollo IPsec (basti pensare alla modifica del ‘protocol
field’)
11

12. 2.0 Visione di Attacco.
Prendiamo in considerazione due host che vogliano trasmettere dati.
Definiamo host ‘A’ il primo terminale da cui partono i dati, host ‘B’ il
terminale che li riceve e host ‘H’ il terminale che cerca di intercettare la
connessione. Se la connessione fosse priva di IP-Sec, attraverso semplici
operazioni di Man In the middle l’host ‘H’ avrebbe la possibilità di captare I
dati trasmessi. ’A’ e ‘B’ utilizzano IP-sec pertanto tutto cio’ che ‘H’
intercetta è crittato e apparentemente privo di ogni significato.
Figura 2.0.1: Scenario Attacco.
Abbiamo dimostrato nel capitolo precedente come è complicato potere
ridirezionare il traffico in un pacchetto IP-Sec, lo scopo di questo attacco non è fare
injection o dirottare pacchetti per iniziare una nuova connessione, ma è
semplicemente quello di catturare dati sensibili.
Immaginiamo ancora una volta che ‘A’ comunichi a ‘B’ I propri dati sensibili per
eseguire un pagamento (se risulta più semplice possiamo immaginare che ‘A’,
succursale, invii una parte di lavoro eseguito a ‘B’,ccentrale, il quale assemblerà I vari
progetti in un unico software finale ) fidandosi della comunicazione sicura che vige
tra I due. Partendo da uno scenario iniziale di Figura 2.0.1, al momento iniziale della
comunicazione, l’host ‘H’ è pronto a captare ogni singolo pacchetto. Come illustrato
nel capitolo precedente la prima azione del protocollo IPSec è lo scambio di chiavi
12

13. per la crtittazione della comuincazione. Cosa accade se ‘H’ è a conoscenza della
chiave di crtittazione ? Chiaramente ogni singolo pacchetto che ora intercetta senza
nessun particolare significato potrebbe risultare leggibile e con un elevato contenuto
informativo. Risulta ovvio che lo scopo di questo Attacco virtuale (è stato chiamato
virtuale in quanto ancora mai testato) è quello di intercettare le chiavi di crittazione in
modo da potere comprendere I dati scambiati tra gli host ‘A’ e ‘B’.
Per potere intercettare le chiavi di crittazione bisogna conoscere a fondo il protocollo
è inoltre necessario conoscere l’ esatta posizione di queste chiavi all’interno del
protocollo IKE. Conoscendo l’esatta posizione delle chiavi, è possibile estrarrle e
grazie alla crittoanalisi risalire alla chiave originale. Una volta ottenuta la chiave
originale è possibile decrittare tutto il contenuto della comunicazione. Per il momento
lasciamoci alle spalle il problema dello sniffing, immaginiamo di essere in una rete
BroadCast (WiFi) o in presenza di un Hub di rete o ancora meglio sopra ad un Nat-
Traversal.
2.1 Attacco.
Settiamo su due macchine IPSec e avviamo uno sniffer di rete su una terza macchina
interconnessa in BroadCast con le prime due.
• Fissiamo una chiave ben nota.
• Avviamo lo sniffer di rete.
• Trasportiamo da ‘A’ verso ‘B’ un Kbyte di testo utilizzando IPSec.
• Interrompiamo la cattura dati.
• Contemporaneamente codifichiamo la chiave.
• Andiamo a cercare la codifica di chiave all’interno dei log di sniffing
Ripetendo queste operazioni ‘n’ volte, possiamo stabilire se esiste una locazione fissa
in cui la chiave viene salvata. Se la locazione è fissa, siamo in grado di prelevare la
13

14. chiave IKE codificata e decrittarla con comodità; una volta decrittata sarà possibile
aprire la comuniczione intercettata.
Di seguito un Activity Diagram illustrerà il procedimento da iterare.
Figura 2.1.1: Activity Diagram Attacco.
Prove e test efettuati in laboratorio confermeranno o negheranno questa ipotesi. Per il
momento vi lascio con questa curiosità.
14

15. 3.0 Bibliografia e Sitografia.
[1] RFC 2401 (Security Architecture for IPSec)
[2] RFC 2402 (AH: Autentication Header)
[3] RFC 2406 (ESP: Encapsulatione Security Payload)
[4] RFC149 (IKE: Internet Key Exchange)
[5] http://www.unixwiz.net/ (Sezione IPsec, per I disegni)
[6] http://www.ipsec-howto.org/ (Sezione ricca di guide pratiche)
[7] http://www.niscc.gov.uk/ (Vulnerabilità dell’ IPSec)
Autore: Dott. Ing. Marco Ramilli.
15