ETTERCAP-NG (MITM parte seconda)

ETTERCAP-NG (MITM parte seconda).
CONTINUA L'AVVENTURA NEI PANNI DEL CATTIVO.....

Ettercap, un tool completamente e totalmente Italiano. La suite per eccelenza prediletta per gli attacchi MITM (uomo di mezzo), la quale offre diverse modalità per operare in qualunque condizione e su ogni interfaccia disponibile. Ettercap nasce come strumento di analisi ma può essere utilizzato in modo molto diverso a seconda di chi lo impiega. Del resto per operare nel bene si utilizzano da sempre strumenti offensivi, quindi bene e male si possono definire tranquillamente le due facce della stessa medaglia. ETTERCAP è presente nei pacchetti di ogni distribuzione, in particolare su sistemi di analisi e testing delle reti, le sue dipendenze vengono cosi risolte automaticamente durante l'installazione ma alcune librerie è meglio verificarle in quanto ettercap potrebbe farne a meno proprio a seconda dell'impiego. Per un tool di attacco dobbiamo verificare lcune librerie importanti come libnet, libtool, openssl e naturalmente libpcap. Dopo aver installato ettercap possiamo utilizzarlo lanciandolo da terminale con i privilegi di root, e possiamo usufruire di più interfacce a seconda del comando lanciato, ad esempio:

# ettercap -T per avviarlo in modalità testo
# ettercap -C per avviarlo con le ncurses
# ettercap -G per avviarlo su X utilizzando una GUI

Quindi se siete su un terminale lanciatelo con -C , se invece avete una sessione grafica avviata potete tranquillamente utilizzare -G. Nel caso dell'interfaccia con ncurses ricordate che potrete navigare tra le finestre con il tasto TAB mentre per uscire oltre dal menu possiamo utilizzare Ctrl-Q, da notare che se ettercap -C viene lanciato su xterm possiamo anche utilizzare il mouse.



ANALISI DI ETTERCAP
Vediamo adesso alcune delle sue funzioni ed il suo utilizzo in genere, non rinunciate proprio adesso. Sotto il menù "Sniff" troverete due possibilità: "Unified Sniffing" e "Bridged Sniffing", analizziamoli entrambi per capire il loro significato.



UNIFIED SNIFFING
Scegliendo questa opzione Wttwrcap prenderà tutti i pacchetti in transito sul cavo, ne verificherà la destinazione e se non sono diretti alla macchina dalla quale stiamo operando, li direzionerà direttamente sulla rete. Scegliendo questo tipo di di sniffing l'IP Fowarding verrà logicamente disabilitato, questo per evitare che un pacchetto venga rimandato all'host di destinazione due volte, una da Ettercap e una dal Kernel. Gli autori ci avvisano anche di utilizzare con attenzione questa modalità se ci troviamop su un Gateway, questo perchè Ettercap ascolta il traffico su una singola interfaccia di rete e su una macchina dotata di più interfacce, non sarebbe possibile ri-routare il traffico nelle giuste direzioni. Quindi, se vi trovate su un Gateway, prima di iniziare lo sniffing, andate sul menù Optins e selezionate l'opzione "Unoffensive" (che dice ad Ettercap di NON disabilitare il packet fowarding del kernel). Una volta avviato lo sniffing dal menù "Start" potremo operare tutti i tipi di attachhi MITM (man-in-the-middle) che il programma mette a nostra disposizione.



BRIDGED SNIFFING
Come suggerisce il nome stesso, in questa modalità sarà possibile effettuare lo sniffing del traffico utilizzando la nostra scheda di rete in modalità bridge, avremo quindi bisogno di due interfacce dal momento che quella che viene posta in bridged mode diventerà completamente trasparente al traffico, e quindi non sarà possibile utilizzarla per manipolare i pacchetti. Questa opzione, sebbene presenti lo "svantaggio" di dover disporre di due schede di rete, rende le nostre operazioni assolutamente invisibili agli altri.... Ma prima di entrare nel dettaglio, abbiamo bisogno di conoscere le basi di una rete di computer.



RETI LAYER E HUB
Una rete, supponiamo per il momento che sia solo la nostra LAN o quella che abbiamo in ufficio, è un insieme di layer (cioè livelli), ognuno dei quali svolge un compito diverso. A seconda dei casi una rete può essere considerata come un sandwich di 5 o 7 layer differenti, ma nel nostro caso avremo bisogno soltanto di conoscerne i primi 4, che in ordine sono:


Layer 4 Trasporto
Layer 3 Network
Layer 2 Datalink
Layer 1 Fisico

Il primo layer viene utilizzato per il trasporto dei segnali elettrici che rappresentano i dati che viaggiano sulla rete, questi segnali (che in genere sono onde quadre) viaggiano da una parte all'altra tramite cavi, raggi laser, onde elettromagnetiche o raggi infrarossi, quindi la trasmissione del segnale fa parte del Layer Fisico. Questo Layer si occupa del controllo dei segnali, verifica che non ci siano stati problemi e si accorge se un segnale è arrivato disturbato a causa di collisioni o problemi sul mezzo di trasporto. Il secondo Layer diventa un pochino più astratto, su questo livello viaggiano i pacchetti Datalink, nel caso di una LAN Ethernet (ne esistono svariati altri tipi) questi pacchetti hanno una lunghezza fissa e contengono, oltre la parte riservata ai dati, un indirizzo sorgente e uno destinazione detti MAC Address (Media Access Control Address), lunghi 48 bit, ad esempio:

0A:55:84:F2:68:51.

Ogni scheda di rete ha un MAC Address unico in tutto il mondo, ed esistono alcune normative per evitare che due aziende producono schede con lo stesso numero. È molto importante che il MAC sia univoco per evitare che sulla rete LAN vengano a crearsi problemi. Questo livello si preoccupa di effettuare un controllo sui dati dei pacchetti, per vedere se sono arrivati come ci si aspettava, in caso contrario ne richiede il rinvio. Il terzo LAyer è quello su cui dimora IP, il protocollo IP serve esclusivamente per la consegna del pacchetto, IP non conosce porte ne servizi, il suo unico scopo è quello di consegnare il pacchetto, se i dati sono rovinati o non arrivano, a lui non importa, diciamo che IP è una sorta di postino, lui fa di tutto per consegnare il pacco, ma se durante il tragitto viene derubato, allora non dice nulla (IP non può semplicemente sapere che un pacchetto è andato perso). Un pacchetto IP è formato da un header con varie opzioni, un indirizzo sorgente e uno di destinazione lunghi 32bit, che sicuramente avrete visto, ad esempio: 192.168.1.1 è un indirizzo IP, anche se abbiamo rappresentato l'indirizzo MAC separato da ":" e l'indirizzo IP separato da ".", ci terrei a ricordare che è una convenzione per noi umani, alle macchine questo non interessa perchè nel pacchetto, a seconda del livello in cui si trovano, non faranno altro che leggere un numero più o meno lungo. Il quarto Layer, detto anche Layer di Trasporto, è rappresentato dal protocollo che si occupa di portare a destinazione, integri, tutti i bit del payload. I più noti, e che sicuramente conoscerete sono: TCP e UDP. Quando sentite qualcuno che vi chiede di collegarvi ad una macchina sulla porta XX, allora si sta sicuramente riferendo al Layer 4, è infatti questo livello che "conosce" ed utilizza le "porte". Mentre TCP e UDP in particolare si preoccupano di consegnare i dati con una sostanziale differenza: TCP instaura una connessione, e alla ricezione di ogni pacchetto invia una conferma, grazia a queste procedure il TCP garantisce la consegna dei dati (sempre che la linea non sia interrotta, o la macchina spenta, ma in questo caso TCP ce lo direbbe immediatamente). UDP, invece, consegna i dati su una determinata porta senza preoccuparsi se arrivino o meno a destinazione, se un pacchetto UDP si perde, non lo sapremo mai, ma se arriva siamo sicuri che i dati in esso contenuti sono esattamente quelli inviati e non contengono alterazioni. L'assenza di una connessione con conferma di arrivo rende UDP più veloce, e quindi appetibile su protocolli dove la latenza è importante (protocolli realtime o di online gaming), mentre TCP è preferibile dove è necessario sapere si i dati sono arrivati o meno (immaginate di inviare una mail e sentirvi dire che è arrivata a pezzetti, non ne sareste di certo felici). Tenete a mente che l'assenza di una connessione con conferma rende l'UDP molto più vulnerabile ad attacchi di tipo MITM rispetto al TCP.



RETE A CIPOLLA
Se non conoscevate questa distinzione sono sicuro che ora la vostra concezione di rete è leggermente cambiata, perchè messa sotto quest'ottica i pacchetti diventano delle cipolle più che dei contenitori di dati. Vi siete chiesti il perchè? Immaginate una rete formata da un PC collegato ad un router collegato su Internet, noi stimao navigando su unn sito Web e vogliamo scaricare un file, al momento del click sul nome del fle all'interno del nostro browser, viene costruito un pacchetto di richiesta, le fasi sono queste: a livello 4 il pacchetto verrà marcato con la porta di destinazione 80 (Web), verrà riempito con la nostra richiesta di download e quindi il controllo verrà passato al Layer 3, questo layer metterà un etichetta sul pacchetto scrivendoci sopra il nostro IP come sorgente, e quello del sito in questione come destinazione. Ora si scende a Layer 2, dove il pacchetto viene imbustato in un pacchetto datalink sul quale verrà scritto come indirizzo sorgente il nostro MAC e come destinazione non verrà scritto l'indirizzo MAC del sito perchè noi non possiamo conoscerlo (sappiamo infatti solo il suo IP), ma verrà scritto l'indirizzo MAC della macchina che invierà sulla rete Internet il nostro pacchetto, in questo caso quello del router. Ed ora il Layer 1 invierà un segnale che verrà inoltrato sul cavo. La scheda di rete del router vedrà il segnale (Layer 1), lo leggerà, e verificherà che si tratta di un pacchetto datalink (Layer 2)destinato a lui (in caso contrario verrebbe ignorato), quindi prende nota del mittente, scarta l'intestazione MAC e ne legge l'IP, preleva questo pacchetto (a layer 3) e lo invia su Internet. Dopo pochi millisecondi il server del sito lo vedrà in arrivo sulla porta 80 (di nuovo layer 4), scarterà l'intestazione del TCP, leggerà il contenuto del pacchetto e ci invia il file. Tutto questo in pochissimi millisecondi. Considerate ora una LAN con più di due PC, per collegarli tra loro saprete che è necessario un Hub o uno Switch. Guardandolo, a meno che non ci sia scritto sopra, non potrete capire se si tratta di un Hub o uno Switch, anche se potrebbe sembrare un dettaglio da nulla la differenza tra questi due dispositivi è enorme. Un Hub innanzitutto funziona soltanto a Layer 1, è praticamente un ripetitore di segnali, non si preoccupa di leggere il pacchetto in se, lui ascolta per un segnale e poi lo ripete su tutte le porte. Se su un Hub il segnale arriva sulla porta 2, verrà amplificato e ritrasmesso su tutte le altre porte ad eccezione di quella sorgente. Sapete questo cosa vuol dire? Che con pochi accorgimenti, possiamo leggere il traffico di tutti gli altri, anche quello non destinato a noi. Uno Switch invece funziona a Layer 2 (i più costosi anche a Layer 3), ciò vuol dire che il dispositivo deve poter leggere il pacchetto per poterne trovare il MAC sorgente e il MAC di destinazione, se vi state chiedendo a cosa serve leggere il pacchetto, presto detto: sapendo a chi è destinato non siamo costretti a ritrasmettere il segnale su tutte le porte, ma lo invieremo soltanto sulla porta dove è attaccato il nostro destinatario. Su uno Switch non è quindi possibile (con le conoscenze acquisite fino a questo punto) ascoltare il traffico che arriva sul PC degli altri utenti, semplicemente perchè questo traffico non giunge mai sul nostro cavo. Uno Switch, inoltre, consente di ottenere una LAN più efficente perchè non si hanno più collisioni sui pacchetti, come, invece, avviene spessissimo con gli Hub. E un Bridge? Un Bridge è un dispositivo molto simile ad uno Switch, lavora a Layer 2 ma serve (in genere) a collegare tra loro due LAN che usano protocolli diversi, è completamente trasparente al traffico perchè non è raggiungibile tramite un indirizzo IP o MAC, ed il suo lavoro è "semplicemente" quello di tradurre i pacchetti da un protocollo all'altro, se necessario, e metterli sulla giusta rotta. È molto importante conoscere il funzionamento di una rete se vogliamo capire come fa a funzionare uno sniffer, e cos'è un attacco MITM, ora che tutto è stato spiegato, possiamo tornare a divertirci coin Ettercap.



SNIFFING E MITM
Per sniffare il traffico è necessario un solo accorgimento, a Layer 2 la nostra scheda di rete semplicemente ignora i pacchetti che non hanno come MAC di destinazione il nostro MAC. Come ovviare? Basterà mettere la scheda in modalità promiscua, tale modalità farà si che la scheda invii al kernel tutti i pacchetti che attraversano il cavo, siano essi destinati a noi o meno. Non è assolutamente difficile, dotatevi dei privilegi di root e fate:
# ifconfig eth0 (eth0 varia con il nome della propria interfaccia)
naturalmente l'output elencherà la vostra scheda di rete elencando il MAC e IP associato, inoltre altri dati tra cui la voce "UP BROADCAST MULTICAST" la quale indica che la scheda non è in modalità promiscua, e quindi rimediamo con:

# ifconfig eth0 promisc

a questo punto noteremo che la scheda è in modalità promiscua visualizzando con ifconfig eth0 la voce precedente cambia in "UP BROADCAST PROMISC MULTICAST" quindi da questo momento tutti i pacchetti saranno letti dalla scheda di rete, non è comunque necessario fare questo a mano, Ettercap lo farà per noi, perciò rimediamo e togliamo la modalità promiscua inserita pre l'esempio con:

# ifconfig eth0 -promisc

ecco fatto, tutto tornato come prima. Proviamo quindi ad avviare una sessione di sniffing, apriamo una console e digitiamo:

# ettercap -Tp (avvia in modalità testo e promiscua)

Tutti i pacchetti saranno stampati a schermo, bloccate tutti i vostri download e cercate di guardare gli indirizzi, se vedete dei pacchetti in cui voi NON siete presenti nè nella destinazione nè nel sorgente, allora vi trovate su un Hub, se, invece, non vedete del traffico "estraneo" allora siete su uno Switch, cosa si fa allora? Nessun problema, con un pò di intuito scoprirete che trovare una soluzione non è affatto difficile. Mettetevi nei panni del router appena acceso, le sue tabelle saranno vuote, in quel medesimo istante arriva un pacchetto dalla rete Internet destinato ad un IP pubblico presente nella sua LAN ....Cosa fa? Crea un pacchetto particolare, destinato a tutti (tale pacchettosi chiama broadcast e da "tutti" è identificato con questo indirizzo FF:FF:FF:FF:FF:FF) con scritto dentro "who-has ip" cioè "chi ha questo ip?", tutte le macchine leggeranno il pacchetto ma risponderà soltantoquella che possiede l'IP cercato dicendo: "reply l'ip è a 01:02:03:04:05:06". Il router saprà quindi a quale MAC appartiene quell'IP e sarà in grado di creare un pacchetto Layer 2 per inviare la richiesta proveniente da Internet sulla rete LAN, verso l'IP cercato. La cosa è ura sicuramente più chiara, se su uno Switch non possiamo leggere il traffico destinato agli altri, perchè non ce lo facciamo mandare che è più comodo? Supponiamo quindi di voler ricevere tutto il traffico che la macchina "A" manda su Internet tramite il Gateway "G", noi siamo "B", come facciamo?



INDIRIZZI IP E MAC
Chiariamo la situazione disegnandoci una tabella dei corrispondenti IP e MAC:

Macchina MAC IP
A 01:02:03:04:05:06 192.167.1.10
B 11:12:13:14:15:16 192.167.1.31
G 21:21:23:24:25:26 192.167.1.1

Possiamo risolvere brillantemente il problema in due soli step:

Inviamo un pacchetto ad A dicendo: "reply 192.167.1.1 is at 11:12:13:14:15:16"
Inviamo un pacchett a G dicendo: "reply 192.167.1.10 is at 11:12:13:14:15:16"

I pacchetti vengono accettati? Certo! Non è necessario un arp-request perchè un computer modifichi la sua arp-cache (la tabella dove vengono mantenute le corrispondenze mac-ip) e se anche fosse necessario, bsterebbe poco per fargliene mandare uno. Dopo di che, G saprà che l'IP di A corrisponde al nostro MAC, e A saprà che l'IP di G corrisponde al nostro MAC. Perciò A invierà a noi credendo di inviare a G, e G invierà a noi credendo di inviare ad A. Manca qualcosa? Si, tutto il traffico che arriva a noi da uno dei due Host andrà reindirizzato verso l'altro, altrimenti non potrà instaurarsi nessuna connessione, questo si chiama: attacco MITM. Ovvero, qualcuno è nel mezzo della connessione..... E, ovviamente, può fare quello che vuole, se invece facciamo arp-poisoning su tutte le macchine della rete senza modificare il traffico, allora si tratta solo di sniffing.



ATTACCO MITM
Proviamo quindi ad effettuare un attacco MITM per sniffare una sessione IRC di una macchina della LAN, per far ciò dobbiamo aver chiaro in mente cosa succede: la macchina vittima si collegherà ad un server irc su Internet, ma, come abbiamo già spiegato, i pacchetti arriveranno al gateway e da li verranno inviati su Internet, quindi dovremo fare un attacco MITM tra la macchina vittima e il gateway, sulle porte classiche del servizio IRC, ciò in genere quelle che vanno da: 6666 a 6669, facciamo cosi (è indifferente l'interfaccia grafica usata, quindi non prendetela in considerazione perchè i comandi sono gli stessi), supponiamo che la macchina vitima sia 192.167.1.3:

# ettercap -T -L irc.log -M arp /192.167.1.3/ //6666-6669

In questa maniera diciamo a ettercap di avviarsi n modalità testuale (-T), loggare tutto il traffico sul file irc.log (-L irc.log), effettuare un attacco MITM tramite arp-poisoning, perchè nel mio lab la rete è cablata da uno Switch, altrimenti non potrei sniffare nulla (-M arp) e di leggere tutto il traffico proveniente dalla vittima (/192.167.1.3/) direttto a qualunque host (//) sulle porte che vanno da 6666 a 6669. Una volta avviato Ettercap colleghiamoci ad un qualunque server irc, mandiamo qualche messaggio di test, in seguito premiamo "q" sul prompt dove sta girando Ettercap ed esaminiamo il log, per farlo dovremo solo usare etterlog:

# etterlog irc.log.ecp

etterlog NG-0.7.3 copyright 2001-2004 ALoR & NaGA

Log file version : NG-0.7.3
Timestamp : Mon Mar 15 18:05:23 2010
Type : LOG_PACKET

True Jan 26 18:48:50 2009 [765199]
TCP *.*.*.*:6666 --> 192.167.1.3:1958 | AP
:test!~test@P.it PRIVMSG test
:ciao.


True Jan 26 18:48:51 2009 [766219]
TCP *.*.*.*:6666 --> 192.167.1.3:1958 | AP
:test!~test@P.it PRIVMSG test
:come va tutto bene?.


True Jan 26 18:48:58 2009 [765199]
TCP *.*.*.*:6666 --> 192.167.1.3:1958 | AP
:test!~test@P.it PRIVMSG test
:test sniffing.


Sulla prima riga troviamo la data, sulla seconda il tipo di connessione, l'ip sotgente, la porta di provenienza e l'ip di destinazione, "AP" sono i flag tcp. Grazie al logging siamo in grado di seguire per intero una conversazione che avviene su irc, e non solo, in maniera simile possiamo anche monitorare le password che, ad esempio, vengono utilizzate su un server ftp:

# ettercap -Tq -M arp /192.167.1.3/ //21

Cosi facendo diciamo ad Ettercap di avviarsi in modalità testo (-T) ma aggiungiamo il parametro "q" che serve a dire di non stampare tutto il traffico, verranno quindi stampate soltanto le password, ovviamente richiediamo il solito attacco MITM sull'host vittima verso qualunque ftp, ecco cosa succede alla prima sessione ftp:

FTP : 212.84.*.*:21 -> USER: mirko PASS: my_pass

Viene mostrata a schermo solo la password del server e questo grazie all'FTP dissector, ovviamente Ettercap supporta una serie di altri protocolli che sono: telnet, pop, rlogin, ssh1, icq, smb, mysql, http, nntp, x11, napster, irc, rip, bgp, socks 5, imap 4, vnc, ldap, nfs, snmp, half life, quake 3, msn, ymsg. A questo punto dovreste aver notato una cosa interessante..... È possibile visualizzare in chiaro anche il traffico ssh1, ma come si fa? ssh1 utilizza un meccanismo di scambio a chiave pubblica (o asimmetrica), che funziona in questa m,aniera:
Il client genera un numero casuale di 128-256 bit che sarà la chiave con cui verrà cifrato tutto il traffico. Il client richiede al server la propria chiave pubblica. Il client cifra il numero generato, con la chiave pubblica del server e gliela invia. Il serrver decifra con la sua chiave privata questo numero ed inizializza la sessione. Il precedente post con l'esempio di Bob, Alice e Mallory descrive questo meccanismo... ricordate?

Il meccanismo di scambio viene detto a chiave "asimmetrica" perchè tutto ciò che si cifra con la chiave pubblica di qualcuno, può essere desifrato solo con la sua chiave privata. Provate ora ad entrare nell'ottica dell'attacco MITM, questo meccanismo non garantisce affatto che la chiave ricevuta sia proprio quella del client.... Perciò sfruttiamo questa falla nell'autenticazione e comportiamoci in questo modo:

Arp-poisoniamo il client e redigeriamo su di noi il suo traffico. Arp-poisoniamo il server e facciamo la stessa cosa. Quando il client invia la sua chiave pubblica, al server inviamo la NOSTRA chiave. Quando il server invia al client la sua chiave pubblica, noi gli inviamo la nostra. Registriamo sia chiave pubblica del server che del client.

In questo modo il client cifrerà il traffico verso il server con la nostra chiave pubblica, e cosi farà anche il server. Saremo quindi in grado di spiare la connessione sia da client-server che da server-client (questo si dice Full-Duplex MITM), ovviamente tutto il traffico in arrivo su di noi verrà decifrato, loggato e quindi cifrato di nuovo con la chiave del server o del client. I due computer non noteranno nulla se quella è la loro prima connessione, ma se invece si tratta della seconda o successive, ssh in automatico ci avviserà che la chiave è cambiata, tuttavia molti utenti non tengono conto dell'avviso (pensando magari che la chiave è cambiata a causa di un aggiornamento di ssh) e quindi si espongono a questo tipo di attacco.


LA PRATICA
Ma vediamo in pratica come è possibile loggare le password o il traffico su un server ssh1. Nell'esempio vedremo un attacco MITM tra una macchina (192.167.1.8) e un server ssh1, avviamo Ettercap con questi parametri:

# ettercap -Tq -M arp /192.167.1.8/ //22

Diciamo cosi al programma di avviarsi in modalità testo, senza stampare tutti i pacchetti, di far un attacco MITM tramite arp-poisoning (sempre perchè il lab si trova su uno Switch) tra l'host 192.167.1.8 e tutte le connessioni che questo host fa sulla porta 22. Portiamoci quindi sull'host 192.167.1.8 ed apriamo una connessione ssh:

# ssh HYPERLINK "mailto:mirk@192.167.1.10"mirk@192.167.1.10

Vediamo subito che SSH ci avverte del cambiamento della chiave (perchè durante la prima connessione la chiave viene registrata), tuttavia scegliendo di accettare la chiave possiamo comunque procedere, ed eccone il risultato:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST
IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

IT IS POSSIBLE THAT SOMEONE IS
DOING SOMETHING NASTY!
Someone could be eavesdropping on
you right now (man-in-the-middle attack)!
It is also possible that the RSA
host key has just been changed.
The fingerprint for the RSA key
sent by remote host is
44:16:b4:d8:11:4d:cf:10:87:11:a0:58:25:63:c5:fa.
Please contact your system administrator.

Come da copione la password di ssh viene loggata all'istante:

SSH : 192.167.1.10:22 -> USER: mirk PASS: p4ssw0rD


CONCLUDENDO
Ma volendo anche tutto il traffico ssh sarebbe visibile, perciò potremmo spiare senza alcun problema tutta la sessione che sta facendo l'utente. E questo vale con ssh1, ma per ssh2? In questo caso viene utilizzato il Diffie-Hellman come algoritmo di scambio delle chiavi. Diffie-Hellman complica le cose perchè include dei check (firma digitalmente una chiave di scambio) per verificare che effettivamente la chiave ricevuta sia quella del client o del server, ma......
Per il momento fermiamoci quà, vedremo più avanti approfondimenti per vari protocolli ed altro, in particolare Ettercap che, ricordo a tutti, è un tool esclusivamente Italiano.... poi venitemi a dire che nessuno ficca il naso negli affari degli altri, non è cosi. Noi abbiamo inventato lo spionaggio e ce ne serviamo sempre, perciò qualunque cosa facciamo è pur sempre cosa "pubblica" sotto serti punti di vista, quindi sapere che questo avviene ci fa prendere altrettante precauzioni, a presto.

PS
Per visualizzare il comportamento di una sessione ssh vi rimando ad un esaudiente lezione: Come_effettuare_una_connessione_remota_SSH_da_Windows_a_Linux

Heracleum blog & web tools
NEI PANNI DEL CATTIVO
Per una volta mettiamoci dall'altra parte della barricata e vestiamo i panni dell'aggressore. L'obbiettivo è scoprire eventuali vulnerabilità nascoste nel sistema. Se è vero, come tanti sostengono, che a volte la miglior difesa è l'attacco, allora non esiste metodo migliore per verificare la sicurezza di un sistema, che calarsi nei panni di un potenziale aggressore. L'obbiettivo è sfruttare eventuali vulnerabilità per riuscire ad aggirare i sistemi di proezione presenti su un computer, o più di uno, ad esempio quelli presenti all'interno di una rete, per prenderne possesso. Tutto questo ci consentirà di conoscere in modo più approfondito alcune tra le tecniche di intrusione più utilizzate, con la speranza che, apprendere come opera il nemico, in futuro ci consentirà di predisporre le strategie di difesa più adeguate per protteggere efficacemente i nostri computer.



ESPERTI DI SICUREZZA
Le tecniche che permettono di scoprire potenziali vulnerabilità presenti in un sistema, sono note come auditing, di cui fanno parte anche i penetration test. Solitamente, si tratta di utilizzare strumenti e applicare tecniche molto sofisticate, appannaggio di utenti esperti, profondi conoscitori dei sistemi operativi, delle dinamiche di rete e delle debolezze di cui soffrono i PC in generale. Questa almeno è la regola, ma come tutte le regole, ha le sue eccezioni. Con il passare del tempo, infatti, sono stati creati strumenti di verifica sempre più raffinati, ma allo stesso tempo facili da usare, che permettono di eseguire test di sicurezza anche ad utenti con una conoscenza relativa a reti e computer di base. Le alternative sono tante, anche per quanto riguarda l'Open Source, ma tra le soluzioni disponibili, selezioniamo Metaexploit Framework, per la sua efficenza e immediatezza d'uso. In pratica, si tratta di una piattaforma di test che, grazie ad una serie di strumenti per lo sviluppo ed esecuzione di exploit, offre praticamente a tutti la possibilità di testare la sicurezza di un sistema. Cosa sono gli exploit, l'arte di sfruttare bug e vulnerabilità. In Informatica il termine exploit identifica un codice, all'atto pratico un programma che, sfruttando una vulnerabilità o un bug eventualmente presenti all'interno di un altra applicazione, ma anche dello stesso sistema operativo, permette di prendere possesso della macchina sulla quale questi sono in esecuzione. Ovviamente, rende possibili anche altri tipi di attacco. Metasploit Framework, in sintesi, spinge il concetto di penetration test all'estremo, offrendo la possibilità di eseguire numerosi tipi di attacchi informatici, ad esempio per verificare la tenuta di un firewall, di un IDS e di altri strumenti sistemati a protezione di un computer o di un intera rete. Inoltre, al termine dei test, genera un accurato report di ciò che è avvnuto in modo da dare la possibilità a chi lo utilizza di prendere i provvedimenti indispensabili alla messa in sicurezza dei sistemi. I tipi di attacco preconfezionati messi a disposizione da Metasploit sono stati sviluppati per testare vari sistemi operativi, GNU/Linux e Windows compresi, questo indipendentemente dalla piattaforma sulla quale il tool è in esecuzione.



INTERFACCIA: QUESTIONE DI GUSTI
Al termine della procedura di installazione, il programma è pronto all'uso. Prima però bisogna scegliere il tipo d'interfaccia da utilizzare: Metasploit Framework, ne offre ben quattro. La varietà di interfacce è necessaria per fare in modo che il programma si adatti perfettamente ad ambienti di esecuzione diversi. Ad esempio, un server potrebbe non disporre di ambiente grafico, per cui l'unica possibilità di usare Metasploit sarebbe la riga di comando. Per avviare l'interfaccia a console bisogna eseguire il comando msfconsole. Per rendere però piu facile l'utilizzo di questo potente strumento, soprattutto per gli utenti meno esperti, è stata introdotta, a partire dalla varsione 3.1, anche una versione grafica dell'interfaccia, avviabile con il comando msfgui. L'aspetto più interessante di questa GUI è che, sebbene sia estremamente potente (implementa quasi tutte le funzioni da riga di comando), il suo utilizzo è molto semplice, perchè basato interamente su procedure guidate. L'unico requisito richiesto è l'installazione di alcuni pacchetti della piattaforma di sviluppo Ruby segnalati al momento della sua esecuzione tramite il comando msfgui. Il concetto è simile per quanto riguarda l'interfaccia di tipo web. In questo caso, mediante il comando msfweb, viene avviato un server web integrato in Metasploit, il quale si occupa di rendere disponibile (caricare) l'interfaccia vera e propria che cosi diventa accessibile da un qualsiasi browser. Infine, troviamo l'interfaccia avviabile tramite il comando msfcli. Si tratta di un'altra interfaccia a riga di comando sviluppata principalmente per permettere di automatizzare i test. Ma in questo caso, i comandi, completi di tutti i parametri necessari all'azione che vogliamo svolgere, possono essere inseriti tutti insieme, senza più richiedere l'intervento dell'utente. In pratica, è come scrivere una sorta di script che automatizza tutte le operazioni. Ovviamente, quest'ultimo metodo è indicato solo ed esclusivamente per utenti esperti, i quali devono conoscere perfettamente il funzionamento di ogni singolo exploit e i parametri richiesti.



PRIMO APPROCCIO
La procedura per sferrare un attacco a un sistema è relativamente semplice. A scopo di esempio, avviamo l'interfaccia a console con msfconsole e, per prima cosa, scegliamo un exploit: l'elenco è visualizzabile eseguendo show all nella console di Metasploit. Per individuare quello più adatto alle nostre esigenze, bisogna controllare i payload associati ad ognuno di essi: si tratta del cosiddetto carico utile, in pratica il codice che attiva l'exploit e porta a termine l'attacco vero e proprio. A questo punto, possiamo utilizzarlo contro il sistema obbiettivo. L'iter è molto semplice: Metasploit, tramite l'exploit, sfrutta una falla nella sicurezza del sistema vittima per iniettare al suo interno il codice (payload) appositamente sviluppato, con lo scopo di eseguirlo e prendere il controllo della macchina. Ovviamente consiglio di eseguire i test su uno o più sistemi di vostra proprietà.



L'IMPORTANZA DEGLI AGGIORNAMENTI
Sebbene gli exploit integrati in Metasploit siano ben 491 (più 230 ausiliari), molti di questi non hanno effetto nel momento in cui i sistemi operativi e le applicazioni coinvolte sono correttamente aggiornati. Per loro natura, infatti, gli exploit hanno un esistenza effimera. In genere, quando si scopre una vulnerabilità e il relativo exploit per sfruttarla, passa poco tempo affinchè gli sviluppatori rendano disponibile una patch con la quale chiudere una falla. Proprio per questo motivo, se unn sistema è ben aggiornato, è sempre molto difficile da violare. È anche vero, però, che vengono scoperte nuove falle ed exploit di continuo, per cui un sistema può risultare vulnerabile anche subito dopo un aggiornamento. Alla luce di tutto ciò, è chiaro come è importante tenere sempre aggiornato il proprio sistema, per mantenere l'efficacia e l'efficenza di Metasploit come strumento per monitorare la sicurezza, è necessario procurarsi sempre gli exploit appena scoperti. Per eseguire questo aggiornamento è sufficiente eseguire il comando msfupdate, oppure abilitare gli aggiornamenti automatici durante la fase d'installazione.



UN ATTACCO REALE
Per collaudare Metasploit, come machcina di test (la vittima dell'attacco) ci serviremo di un computer con Windows XP senza service pak (il test di un exploit obsoleto per non rischiare in caso di errori, di colpire una occasionale vittima in rete), mentre nel ruolo di attaccante utilizeremo il PC con GNU/Linux sul quale prima abbiamo installato Metasploit (se volete il pacchetto basta chiedere). come interfaccia ci serviremo di quella grafica (avviandola subito con msfgui), ma nulla vieta di utilizzare la console o lìinterfaccia web. Prima di iniziare è consigliabile chiudere anche la connessione a Internet per un ulteriore sicurezza ed evitare, in caso di errore durante la digitazione di qualche parametro, di attaccare inavvertitamente un computer remoto.





RADIOGRAFIA DI UN EXPLOIT
Per utilizzare al meglio Metasploit, bisogna conoscere bene come funziona e cosa fa l'exploit di cui vogliamo serverci e il relativo payload. Conoscerli tutt è impossibile, ma è possibile approfondire l'argomento consultando l'archivio disponibile all'indirizzo www.metasploit.com/framework/modules . Al suo interno, ogni exploit è descritto dettagliatamente ed è fornito anche di chiari esempi di utilizzo. Purtroppo sono relativi alla sola interfaccia a riga di comando, ma è sempre possibile, con piccole variazioni, applicare le stesse tecniche agli altri casi.





DATABASE DELLE VULNERABILITÀ
Per cercare un exploit tra quelli gestiti da Metasploit, abbiamo detto che si possono utilizzare i campi ricerca OSVD, CVE, BID, MSB e TEXT. Quest'ultimo rappresenta il nome effettivo utilizzato da metasploit, mentre gli altri fanno riferimento a nomenclature utilizzate da diversi database accessibili on-line, che contengono l'elenco di tutte le vulnerabilità scoperte:

→ OSVDB (http://osvdb.org)
È un database indipendente e Open Source che descrive circa 60.850 vulnerabilità

→ CVE (http://cve.mitre.org)
Acronimo di Common Vulnerabilities and Exposure, è una sorta di dizionario pubblico che contiene informazioni relative alle falle di sicurezza

→ BID (http://www.securityfocus.com)
Database di varie vulnerabilità e di facile consultazione. A sua volta permette ricerche per "prodotto", versione oppure appoggiandosi al numero CVE.

Il Virus Invisibile

IL VIRUS INVISIBILE
Mebroot (anche noto come Sinowal o Maobroot), è un Trojan del 2008, sviluppato su un meccanismo che punta a corrompere il file MBR (Master Boot Record) del sistema vittima per utilizzarlo come vettore per un payload virale basato su rootkit e poi su un trojan. La novità assoluta di questo tipo di virus multistage è l'adozione di questa tecnica mista all'uso di una scrittura del virus stesso a basso livello, posizionandolo in una zona "nascosta" dell'hard disk nella quale vengono salvati i file (una o più .dll, ad esempio) utili ad assicurare la "persistenza" nel sistema vittima attraverso l'ausilio di ulteriori componenti quali " trojan backdoor" o i "trojan keylogger". Come accennato, Mebroot non è nuovo, ma quella rilevata oggi è una pericolosa variante non segnalata dagli antivirus più comuni che è stata scritta a basso livello (in linguaggio Assembler) proprio per rendere la sua individuazione ancora più problematica.

COME FUNZIONA IL VIRUS
L'MBR è il primo settore fisico del disco fisso e contiene il codice che per primo viene caricato ed eseguito dal disco durante il processo di boot. Come si può immaginare, nella corsa tra i rootkit e rivelatori di rootkit (antirootkit), il primo che viene eseguito ha il sopravvento. Da questo principio sono partiti i coderz di Mebroot. Evidentemente non è possibile eseguire qualcosa prima del codice presente nell'MBR e quindi qualunque virus riuscisse a partire dal Master Boot Record avrebbe vita facile nei confronti dei suoi cacciatori.

DOV'È LA NOVITÀ
Già negli anni novanta i virus per DOS andavano a scriversi nell'MBR (tipica vittima era il MBR dei floppy disk). La "novità" di Mebroot non sta quindi nell'uso del MBR per attivarsi, quanto nel fatto che l'MBR non è il contenitore del virus quanto, piuttosto, la sua rampa di lancio. Infatti Mebroot non altera il record più di tanto e soprattutto non inserisce l'eseguibile nello stesso record (facilmente individuabile dagli antivirus). Nell'MBR il virus inserisce solo un puntamento statico ad una porzione del disco ad esclusivo appannaggio del Sistema, spazio nel quale non può mettere il naso neanche l'antivirus. Cosi facendo la sua componente rootkit viene eseguita prima di qualunque altro elemento di Sistema durante il caricamento del Sistema Operativo stesso. Il rootkit è caricato dalla porzione nascosta del File System sul disco fisso. Tutto ciò comporta che Mebroot può attivarsi solo in presenza di macchine Microsoft Windows, gli altri sistemi pur avendo partizioni shadowed, nascoste, hanno puntamenti diversi e diverse modalità di gestione degli stessi.

LE FASI DELL'INFEZIONE
Allo start del sistema in modalità protetta (dopo il boot) l'MBR viene caricato e l'interprete, il kernel e i moduli principali vengono caricati dal disco fisso. Insieme a queste procedure il processo di caricamento dei file prosegue attraverso il descrittore dell'MBR caricando i file puntati dalle entry malevole. Una Call di Sistema viene invocata dal processo "ntoskrnl.exe", un module hook che esegue il "kernel-mode-payload-downloader". Con quest'ultima chiamata in fase di INIT, ovvero di inizializzazione del Sistema, la Call attiva il caricatore di puntamento del payload malevolo e, completata questa fase, esegue una cancellazione dalla memoria evitando di lasciare segnali della sua esecuzione. Il rootkit memorizza i propri dati necessari alla sua sopravvivenza a seguito dei riavvii di Sistema tipici del mondo Microsoft, attraverso la sua scrittura in settori fisici in forma di record e non di file. Ciò significa che i dati, compreso il payload, non sono visibili o in alcun modo accessibili alle normali applicazioni. In genere, in questo tipo di infezioni è sufficiente ripristinare il MBR originale per avere di nuovo un sistema "clean", ma nel caso l'operazione non vada a buon fine si rischia il funzionamento dell'intero Sistema Operativo (che da quel momento non riuscirà più a fare il boot correttamente). Se in ambito domestico la cosa non ha grandi ripercussioni a patto di svolgere regolarmente dei backup, in ambiente aziendale, soprattutto se la struttura è distribuita territorialmente, comporta pesanti ripercussioni sul supporto tecnico. Inoltre, oggi, le operazioni più semplici come il fixmbr non risolvono definitivamente il problema essendo spesso il virus capace di intervenire sull'operazione impedendo la scrittura sul disco. E le nuove varianti del virus non sono facilmente intercettabili e individuabili dai comuni sistemi di protezione.

Un intruso nella rete MITM

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

L'ATTACCO CLASSICO

Come accade spesso la risoluzione di un problema ne pone uno nuovo e altrettanto difficile. Cosa possono Alice e Bob contro Doc se abitano in città diverse e non possono incontrarsi in alcun modo? Lo scambio della chiave di persona non può avvenire, qualunque mezzo di comunicazione nasconde la possibilità di un uomo nel mezzo che può ascoltare tale chiave e utilizzarla per decifrare tutti i messaggi successivi. Questa esigenza ha portato alla nascita della crittografia a chiave pubblica. In questo modello crittografico la chiave per cifrare un messaggio è diversa da quella che serve per decifrarlo. Ogni utente ha dunque una coppia di chiavi, quella pubblica (che serve per cifrare) e quella privata (utilizzata per decifrare). Poichè quella pubblica è l'unica necessaria ad Alice per spedire un messaggio segreto a Bob, e per definizione non necessita di essere protetta da occhi indiscreti, Alice e Bob hanno ora una soluzione efficace per difendersi da Doc, anche se non possono incontrarsi di persona:
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