Il vero cuore pulsante
di ogni azienda che si rispetti e' la sua rete. All'interno di essa (e dei suoi
cavi) ogni giorno transitano centinaia di password, di e-mail e di dati assolutamente
riservati. Prendere possesso di questi dati significa, ovviamente, controllare
l'intera azienda.
Per quasi vent'anni
i tradizionali supporti condivisi (Ethernet e Token Ring) hanno permesso
una facile intercettazione del traffico di rete, consentendo, ad ogni nodo
presente sul segmento, di ricevere le stesse informazioni che arrivavano
al destinatario. La tecnologia a commutazione, invece, pur continuando a
mantenere lo stesso nome di quella condivisa, ha completamente rivoluzionato
la tecnica di instradamento del traffico e, sinteticamente, attraverso una
tabella di indirizzi MAC (Media Access Control), ha permesso che il pacchetto
arrivi soltanto al legittimo destinatario, rimanendo invisibile (almeno
in teoria) a chiunque altro. Cosi' concepita, questa indiscussa innovazione
logica, prim'ancora che tecnologica, ha fatto si che molti"esperti"
identificassero gli switch come strumenti rivolti alla sicurezza della rete,
piuttosto che mezzi per migliorarne le prestazioni. Ma pensare che gli switch
(da soli) possano rendere immune una rete dagli sniffer, e' pura illusione!
Quest'articolo nasce proprio dopo aver assistito su IRC ad un monologo di
due di questi "esperti" di rete... ed e' a loro che voglio dedicarlo.
Il punto di partenza per la nostra indagine sull'intercettazione dei dati
attraverso gli switch e', naturalmente, il protocollo ARP. L'Address Resolution
Protocol (ARP), infatti, viene usato per stabilire l'indirizzo MAC di un
computer destinazione. In linea di principio, il procedimento e' molto semplice.
Quando si vuole stabilire una comunicazione tra due computer, il protocollo
ARP, qualora non possieda gia' l'indirizzo fisico del destinatario nella
sua cache, si incarica di inviare alla rete locale un messaggio di broadcast
contenente la richiesta dell'indirizzo hardware associato all'indirizzo
IP di destinazione. Se l'host in questione e' presente nella rete locale,
allora rispondera' direttamente alla richiesta di ARP che, a sua volta,
aggiungera' l'informazione nella propria cache affinche', in futuro, non
debba ripetere questa procedura. Se l'host, invece, si trova su una rete
remota, sara' il gateway di default a rispondere con il suo MAC e tutti
i pacchetti saranno inviati a questo indirizzo. Questo e', in breve, quanto
succede. Per informazioni dettagliate tanto sui procedimenti, quanto sui
tempi di conservazione delle informazioni nella cache ARP, potete comunque
fare riferimento alla RFC 826.
Vediamo ora come compromettere questo equilibrio. Bene, diciamo subito che
il traffico ARP e' facilmente contraffabile e puo' essere reindirizzato,
anche in ambienti commutati, verso un qualsiasi sistema. Di conseguenza,
attraverso un analizzatore di rete, si potra' visualizzare il contenuto
della trasmissione e, quindi, inoltrare nuovamente il tutto verso il destinatario
originario. I piu' attenti ed informati avranno gia' capito che si tratta
semplicemente di un attacco del tipo "man_in_the_middle" sfruttando
il protocollo ARP. Per tentare di dare all'argomento che stiamo trattando
un approccio un po' piu' pratico, prendiamo in considerazione, attraverso
un esempio, tre sistemi ed inseriamoli in un'ipotetica rete filtrata da
uno switch...
------------ ------------
| | | |
| RAUL | | JACKAL |
| | | |
------------ ------------
Sistema obiettivo Attacker
128.131.1.10 128.131.1.100
| |
| |
| ____________________ |
_____________ |_______SWITCH_______| ____________
|
|
|
------------
| |
| SARDANAP |
| |
------------
Gateway di default
128.131.1.1
La parte del "cattivo",
in questo caso, la fa il sistema JACKAL (ho davvero una grande fantasia!!),
che si trova all'indirizzo 128.131.1.100 Su questo sistema l'attacker eseguira'
l'ottima utility ARPREDIRECT, presente nel pacchetto dsniff (http://www.monkey.org/~dugsong/dsniff/),
che permettera' l'intercettazione sulla rete dei pacchetti che l'host bersaglio
(il sistema RAUL all'indirizzo 128.131.1.10) invia al gateway di default
SARDANAP (128.131.1.1). Inoltre, affinche' la catena non venga interrotta
e le informazioni arrivino comunque al destinatario originale, e' necessario
che il sistema JACKAL supporti il servizio di IP forwarding. Il metodo piu'
veloce per farlo, e' utilizzare l'utility FRAGROUTER, l'altro, invece, consiste
nell'implementarlo a livello kernel. Il sistema JACKAL ora e' pronto ed
avvia anche l'analizzatore di pacchetti (uno vale l'altro, a voi la scelta).
Vediamo ora come avviene l'attacco. Dopo aver registrato gli indirizzi hardware
degli altri due sistemi (basta anche solo un ping), JACKAL, attraverso ARPREDIRECT,
comincia a spacciarsi per il gateway di default, mandando a RAUL delle risposte
ARP contraffatte. RAUL, a sua volta, credera' che SARDANAP abbia cambiato
il suo indirizzo hardware e aggiornera' la sua tabella ARP con il nuovo
indirizzo (che, in realta', sappiamo essere quello del sistema JACKAL).
1. JACKAL invia pacchetti
ARP contraffatti all'host RAUL
------------ <<--------------------------- ------------
| | | |
| RAUL | 2. RAUL e' stato ingannato e | JACKAL |
| | invia tutto il traffico a JACKAL | |
------------ ---------------------------->> ------------
Sistema obiettivo Attacker
| |
| |
| ____________________ |
X |_______SWITCH_______| <--------------
|
|
Da questo momento, una ipotetica
sessione telnet o ftp aperta sull'host bersaglio, verra' inviata direttamente
al sistema dell'attacker che potra' analizzarla con Hunt o con qualsiasi
tool precedentemente predisposto. Inoltre, poiche' e' stato attivato il
servizio di IP forwarding, l'host JACKAL si comportera' come se fosse un
router, reinstradando l'intera sessione verso il sistema originario... Come
abbiamo visto, gli switch non sono, in fin dei conti, tanto sicuri come
si vorrebbe far credere!
Diverse sono poi le contromisure adottabili per arginare gli attacchi di
ARP Forcing. Il metodo piu' efficace, e purtroppo anche quello piu' scomodo
da attuare, consiste nel rendere statiche le tabelle ARP in modo da evitare
la circolazione di richieste e di risposte sia legittime che contraffatte.
Come si puo' facilmente immaginare, la soluzione e' abbastanza laboriosa.
Infatti, al variare di un indirizzo hardware o nel momento in cui si renda
necessario aggiungere un host alla rete, si dovranno anche aggiornare i
file /etc/ethers di tutti i sistemi. Inoltre, non sara' sfuggito, l'utilizzo
da parte mia del termine "arginare". Infatti, se l'attacker si
trovera', non piu' sulla stessa rete, ma su una interposta tra l'host bersaglio
e il gateway, potra' comunque effettuare lo spoofing ARP, sfruttando un
punto della rete che non puo' essere controllato dall'amministratore. Il
metodo piu' semplice e sicuro di aggirare il problema (dato che non si tratta
di una vera soluzione), e' allora, ancora una volta, l'uso della crittografia.
L'attacker, in questo caso, pur potendo portare a termine con successo l'attacco
fin ora discusso, non riuscira' in ogni caso a visualizzare i dati della
sessione e, l'immissione nello streaming di comandi non crittografati, provochera'
la semplice chiusura prematura della connessione. Alle soluzioni ora prospettate,
potra' poi essere affiancata l'utility ARPWATCH. Questo programmino si occupera'
di notificare via e-mail qualsiasi cambiamento dei vostri mapping Ethernet/IP,
e, registrando anche tutti i dati in file di log, vi permettera' di individuare
facilmente chi vi vuole male!! ;)
Dimenticavo, ecco alcuni link per approfondire alcuni aspetti:
http://chocobospore.org/arpspoof/
http://www.ziobudda.net/Recensioni/vedi_recensione.php?ff=76
http://www.faqs.org/rfcs/rfc-index.html
