• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Ip sec vulnerability
 

Ip sec vulnerability

on

  • 857 views

 

Statistics

Views

Total Views
857
Views on SlideShare
853
Embed Views
4

Actions

Likes
1
Downloads
0
Comments
0

2 Embeds 4

http://www.slideshare.net 2
http://cesena.ing2.unibo.it 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Ip sec vulnerability Ip sec vulnerability Document Transcript

    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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