Gli attacchi di tipo MITM, o "Man In The Middle", rappresentano un paradigma fondamentale della sicurezza informatica dei giorni nostri. Concetti come trust-relationship, autorizzazione e autenticazione, integrità e confidenzialità sno onnipresenti in manuali, documenti online, tutorial di vario livello. Questa definizione, per quanto maschilista, rappresenta lo standard con cui enunciati alcuni scenari tipicii di attacco alla confidenzialità ed integrità dei dati. Dovendo presentare il concetto di attacchi mediante "uomo di mezzo" potrebbe essere utile raggiungere l'Hacking Lexicon.
Per quanto accurata, però, la definizione appare quanto meno sminuente. Secondo questo dizionario, infatti, gli attacchi MITM permettono all'attaccante di inserirsi tra due parti in gioco, creando la necessità di una mutua autenticazione. Questo è corretto, ma il Lexicon caratterizza questi concetti nel famigerato mondo del networking. Parla di client, di server, di connessioni in chiaro e/o cifrate. Ma l'orizzonte dei MITM non è assolutamente legato al solo mondo delle comunicazioni di rete. È abbastanza ovvio immaginare cosa succederebbe nel classico B-movie di spionaggio in tempo di guerra, se il corriere di un messaggio in codice fosse catturato e sostituito da un agente nemico. In quel caso non potremmo forse parlare di MITM? Certamente si. È d'altra parte altrettanto ovvio che nell'ambito della sicurezza informatica, questo paradigma non sia correlabile a molti scenari. Ma al di là del TCP Hijack, del Route Mangling e compagni bella esiste almeno un altrettanto importante ambito operativo: la crittografia. Almeno qualche migliaio di risultati attende l'audace uetnte dei motori di ricerca che decidesse di accostare le due stringhe secondo più o meno differenti ricette alchemiche. Cosa succederebbe qualora si inserissero, tra Alice e Bob, Doc o Mallory Quale potrebbe essere la fiducia residua relativamente alla confidenzialità delle informazioni ricevute? Vediamo dunque di introdurre almeno qualche scenario, sia esso relativo "All'arte della Cifratura" o al mondo ella suite TCP/IP, che possa gettare un poco di luce sull'universo del famigerato "uomo di mezzo".
L'ATTACCO UOMO DI MEZZO
Il paradigma dell'attacco Middle In The Man ben si addice al campo della Network Security. Anzi, molto spesso questo è l'unico campo applicativo conosciuto di questa tipologia di attacco. Le motivazioni di questa "cultura unilaterale" sono semplici.
→ immediata visualizzazione della distinzione tra le parti in gioco;
→ scarsa conoscenza degli algoritmi di cifratura e crittanalitici;
→ "hype" relativo alla suite di protocolli TCP/IP, considerati come la base di qualunque smanettamento in ambito Internet (in guide, tutorial, manuali, mailing list, etc).
D'altra parte, anche in questo caso, gli attacchi MITM sono spesso ridotti al semplice concetto di TCP Hijacking ("A Simple Active Attack Against TCP", Joncheray) in cui si delinea il semplice scenario di TCP SPOOFING VEDENTE. In realtà, come vedremo, gli attacchi di un uomo di mezzo relativi alle comunicazioni di rete mediante protocolli TCP/IP non sono limitati a questo esempio. Altrettanto evidentemente, non sono i soli protocolli basati su IP ad essere vulnerabili secondo questo paradigma generico. Per mostrare concretamente un tipico, ma semplice, scenario di MITM di rete IP, abbiamo bisogno dei seguenti tool:
tcpdump e dsniff e di almeno tre sistemi differenti per tradurre in pratica questo esempio senza troppi problemi. Lo scenario in questione mostra la possibilità di sniffare una connessione TCP all'interno di una LAN concentrata mediante switch. Non è questo il contesto in cui spiegare le differenze tra hub, switch e bridge: in un segmento switchato non è teoricamente possibile ottenere i frame ethernet destinati ad un altra interfaccia che non sia in nostro controllo. Con uno dei piu semplici approcci degli attacchi MITM, mostrerò come sia possibile invece ottenere questo risultato.
Alice, Bob e Doc
Presentiamo inanzitutto le tre parti in gioco:
Host Alice (192.168.1.1) appears to be up ... good.
Remote operating system guess: Windows Millennium Edition (Me), Win 2000, or WinXP
Host Bob (192.168.1.3) appears to be up ... good.
23/tcp open telnet
Remote operating system guess: OpenBSD 8.0 (x86 or SPARC)
Host Doc (192.168.1.13) appears to be up ... good
Remote operating system guess: Linux Kernel 2.6
Questi sono i tre protagonisti del nostro scenario. Un client telnet, su piattaforma Windows XP, un demone telnet, su piattaforma OpenBSD/SPARC, e un "uomo di mezzo" su piattaforma Linux 2.6. La LAN è concentrata mediante lo switch Catty:
Host Catty (192.168.1.201) appears to be up ... good
Remote operating system guess: Cisco IOS 12.0(5)WC3 - 12.0(16a)
Di norma, come affermato, non è possibile, per Doc, sniffare frame non destinati alle sue interfacce di rete. Infatti avviamdo una sessione telnet da Alice (192.168.1.1) a Bob (192.168.1.3) e sniffando contemporaneamente da Alice e Doc otterremo risultati palesemente differenti. Se facessimo lo sniffing su Alice vedremmo scorrere i pacchetti, idem da Bob, ma Doc?. Ecco quanto vede:
Doc-Bash# tcpdump -ni eth0 host 192.168.3
tcpdump: listening on eth0
16:38:26.501274 arp who-has 192.168.1.3 tell 192.168.1.1
Doc può vedere soltanto la risposta ARP proveniente da Alice, ma nessun pacchetto che appartiene alla connessione tra Alice e Bob. Doc sa che non esistono metodi "ufficiali" per poter ottenere i frame tanto agognati, quindi decide di operare un attacco MITM. Quali sono i punti su cui può fare leva senza troppi problemi?
ARP e Switched LAN
Esiste, come noto, una differnza sostanziale tra indirizzi IP ed indirizzi Ethernet, o "MAC Address". A livello IP, il kernel non sa a chi inviare "fisicamente" i datagrammi inerenti la connessione che intende stabilire. È necessaria perciò una conversione che possa accoppiare gli indirizzi IP agli indirizzi MAC del layer inferiore. Questa tipologia di servizio è garantita dal prorocollo ARP (Address Resolution Protocol, RCF826) in grado di richiedere a tutte le interfacce della LAN, la quale abbia l'indirizzo IP richiesto associato. In questo caso, Alice (192.168.1.1) richiede a tutta la LAN, chi disponga dell'indirizzo IP 192.168.1.3, l'indirizzo del demone telnet su Bob. Questa richiesta viene inviata a tutti i sistemi della LAN dallo switch, poichè l'indirizzo ethernet di destinazione, utilizzato per questa richiesta, è quello di broadcast (ff:ff:ff:ff:ff:ff) la risposta ufficiale di Bob non tarda a farsi sentire:
16:38:26.509581 arp reply 192.168.1.3 is-at 08:00:20:77:4d:db
Questa risposta compare però solo nei log di Alice e non in quelli di Doc. Come mai? Semplice. In questo caso l'indirizzo ethernet di destinazione, utilizzato nella risposta ARP, è quello di Alice, per cui Catty (lo switch) invia tale frame alla sola Alice. Doc ha quindi a disposizione solo due "appigli" per convincere lo switch, e quindi Alice e Bob, a mandargli i frame ethernet interessanti: la richiesta ARP ed il MAC Address di Alice, contenuto nel frame della richiesta stessa. A questo punto l'algoritmo di attacco è molto semplice, sapendo come funziona il protocollo ARP: Doc deve costringere Alice e Bob a ritenere che gli indirizzi MAC del peer della connessione siano uguali a quello della scheda di rete di Doc. Come è possibile questo? Il protocollo ARP gestisce una cache che di base non è statica. Ed è un bene che sia cosi, considerazioni sulla sicurezza a parte. Se infatti ad ogni indirizzo IP fosse associato un MAC statico, qualora decidessimo di modificare l'indirizzo di una scheda di rete, dovremmo aggiornare la tabella delle associazioni IP<>MAC su ogni sistema. Invece, la dinamicità del processo di richiesta e risposta ARP permette di ovviare a questo inconveniente. Per visualizzare su sistemi Linux o Windows la cache ARP è sufficiente digitare il comando arp.
Bash# arp -a
Alice (192.168.1.1) at 00:10:5A:18:68:34 [ether] on eth0
Catty (192.168.1.201) at 00:01:42:97:94:80 [ether] on eth0
Bob (192.168.1.3) at 08:00:20:77:4D:DB [ether] on eth0
Ciò che Doc deve fare è aggiornare la cache ARP sia di Alice che di Bob, affinchè su Alice ci sia una riga come questa, in cui sia specificato, cioè, il proprio MAC Address:
192.168.1.3 00-02-a5-a4-41-3c dinamico
e su Bob una come questa (le differenze nell'output sono relative alla differente piattaforma, come detto Windows per Alice e OpenBSD per Bob):
Alice (192.168.1.1) at 00:02:a5:a4:41:3c
In questo modo i frame ethernet inviati da Alice a Bob e da Bob a Alice utilizzeranno come MAC di destinazione quello di Doc (00:02:A5:A4:41:3C) e lo switch copierà tutti i pacchetti vero la porta cui è collagato Doc. Sarà poi compito di Doc completare la connessione tra Alice e Bob mediante fowarding. Lo strumento per corrompere la chache ARP dei due peer della sessione telnet è arpspoof, piccolo sfotware a riga di comando. La pagina man di arpspoof riporta esclicitamente: "arpspoof dirotta pacchetti da un sistema bersaglio (o da tutti i sistemi) in una LAN, forgiando risposte ARP. Questo è uno strumento estremamente efficace per sniffare traffico su uno switch". La sintassi d'uso è molto semplice:
sid@sid-laptop:~$ arpspoof -?
Version: 2.4
Usage: arpspoof [-i interface] [-t target] host
sid@sid-laptop:~$
Il target non è altro che il sistema di cui corrompere la cache ARP, mentre host è il sistema di cui vogliamo intercettare i pacchetti. Sarà quindi necessario, per ottenere "entrambi i lati" della connessione, aviare due sessioni di airspoof, una co ntro Alice ed una contro Bob. Ma non basta; è infatti indispensabile che i pacchetti in arrivoda Alice siano poi inviati a Bob e quelli in arrivo da Bob ad Alice. Per fare questo è sufficiente per Doc abilitare l'IP fowarding sulleinterfacce di rete mediante un semplice:
# echo 1 > /proc/sys/net/ipv4/ip_foward
per permettere ad Alice e Bob di stabilire la connessione. I comandi che Doc lancia sono quindi essensialmente due:
# arpspoof -i eth0 -t 192.168.1.1 192.168.1.3
# arpspoof -i eth0 -t 192.168.1.3 192.168.1.1
A questo punto, una sessione mediante un qualunque sniffer (tcpdump), permette a Doc di ottenere le credenziali di autenticazione dal traffico di una successiva sessione telnet tra Alice e Bob.
MITM, TCP/IP, Ettercap
Le operazioni di sniffing in una LAN concentrata mediante switch non sono che la punta dell'iceberg di ciò che è possibile ottenere mediante gli attacchi di MITM operati contro la siute di protocolli TCP/IP e le reti che ne fanno uso. Ettercap è il progetto principe dei software per operare MITM nelle reti IP. Routing, autenticazioni mediante SSL, tunnel per VPN, protocolli di bilanciamento e coordinamento di router e switch, sessioni SSH.... ogni possibile comunicazione può essere intercettata, modificata, ispezionata, socondo ovvi e differenti livelli di possibilità derivanti dalle caratteristiche intrinseche dei protocolli attaccati. Vediamo come ciò sia possibile e quali possono essere alcuni scenari concreti di utilizzo delle nostre reti, siano esse locali o geografiche.
IL SANTO GRAAL DELLE RETI: La crittografia
Oggi giorno non si sente parlare d'altro: SSL/TSL, IPSec e VPN, OpenSSH, PGP/GPG e chi più ne ha più ne metta. Dopo circa 20 anni ci si rende conto che le reti non siano sicure e si corre ai ripari, nell'attesa di chi sa quali caratteristiche di IPv6 tanto invocate, sotto l'unico ombrello capace di garantire sicurezza e fiducia: la crittografia. Considerata troppo spesso come un elisir universale, elargitore di ogni cura per qualunque problema, la crittografia si è sempre scontrata con "l'uomo di mezzo". A livello teorico i crittografi, soprattutto i crittanalisti, hanno sempre considerato molto concreti gli scenari di MITM relativi agli algoritmi ed ambiti dei cifrari, fossero essi relegati alla matematica pura, alla realtà fisica che si avvale del cifrato o agli uomini che ne fanno (cattivo?) uso. Quando parleremo di tool adatti per operare attacchi di uomo in mezzo contro le reti supportate dalla crittografia, avremo bisogno di capire come gli stessi scenari valenti per le reti e le implementazioni crittografiche informatiche, abbiano una controparte logica nella cosidetta "teoria crittografica". Vediamo dunque alcuni tipici scenari logici, per dischiudere questo affascinante quanto complesso mondo.
UN PROBLEMA ORIGINALE
Anche se la crittografia è spesso usata per limitare i danni causati dall'uomo nel mezzo negli attacchi informatici, essa non è purtroppo immune dalla facoltà di Doc, capace di leggere i messaggi che Alice e Bob si scambiano, tanto meno da quelle di Mallory, capace non solo di leggere, ma di modificare, cancellare i messaggi originali di Bob e Alice, e spedirne di nuovi creati da lui. Vale la pena di notare come la crittografia stessa esista in virtù del fatto che potenzialmente esiste qualcuno nel mezzo che può leggere i messaggi che Alice invia a Bob: Doc. Senza la presenza di Doc, non sarebbe molto interessante cifrare, da chi proteggersi se non c'è nessuno capace di leggere mentre il messaggio è in viaggio per raggiungere Bob? Purtroppo Doc esiste potenzialmente, e possiede il dono dell'ubiquità, infatti nessun canale non protetto può essere considerato sicurose esiste anche la più piccola possibilità che qualcuno legga i messaggi che trasporta, Doc è teoricamente dovunque fino a prova contraria. <<<<<<<<Bob spedisce la propria chiave pubblica ad Alice, che la utilizzerà per cifrare i messaggi da spedire a Bob (che solo lui, in possesso della chiave privata, potrà leggere). Ancora una volta l'unica possibilità di Doc di leggere i messaggi è quella di riuscire a rompere l'algoritmo utilizzato da Alice e Bob. Nonostante tutto, non è il caso di cantare vittoria: Doc ha poteri limitati, può soltanto ascoltare, leggere, spiare, ma non modificare i messaggi. Al contrario Mallory può modificarli e cancellarli, cosi come può spedirne di nuovi, in gergo si dice che Doc è un attaccante passivo, mentre Mallory è un attaccante attivo, che compie azioni e non si limita a trarre informazioni e conclusioni da quello che osserva. Ecco gli effetti della maggior potenza di Mallory: quando Bob spedisce la propria chiave pubblica ad Alice, Mallory la sostituisce con la propria, e la spedisce ad Alice. Quando Alice spedisce un messaggio a Bob, cifrato ocn la chiave pubblica di Mallory (ma Alice crede sia quella di Bob), tutto quello che deve fare Mallory è inteccettarlo, decifrarlo con la sua chiave privata, leggerlo, cifrarlo con la chiave pubblica di Bob, e spedirlo a quest'ultimo. Il procedimento è identico per intercettare comunicazioni che viaggiano nell'altro verso, da Bob ad Alice. Alice e Bob non si accorgeranno di nulla, e Mallory avrà accesso a tutte le loro comunicazioni. Tale attacco è probabilmente uno dei più famosi nella categoria del Man-In-The-Middle. Registrare le chiavi pubbliche in un database non migliora molto la situazione, infatti Mallory potrebbe intercettare le richieste per le chiavi fatte da Bob ed Alice e sostituirle con la propria, o violare la sicurezza del server e sostituire la chiave di Alice e Bob con la propria. Ciò che invece può aiutare è di "pubblicizzare" la propria chiave pubblica (ad esempio inserendo un "fingerprint" che la identifichi in maniera univoca in ogni email spedita), e creare un sistema di relazioni di fiducia facendo certificare la nostra chiave ai nostri amici e viceversa. Questi sistemi di protezione sono quelli adottati dalla comunità di utenti PGP e GPG in tutto il mondo. Tuttavia ci sono dei protocolli che riducono i problemi causati da Mallory.
MITM parte seconda
Nessun commento:
Posta un commento