2/19/2010


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.

2/18/2010

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.

2/17/2010

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