VoIP and Hacking | Consulenza Documentazione

TOR (The Onion Router) è un network di Nodi, che viene usato per creare un tunnel criptato nel quale stabilire connessioni anonime, dato che la loro origine risulta essere quella del nodo di uscita (exit node) della rete Tor, anzichè quella reale.
Sarebbe tuttavia una grave leggerezza confondere, in ragione di queste caratteristiche, tale anonimato con una soluzione completamente sicura.
Il motivo è molto semplice.
Il network TOR comprende due categorie principali, TOR Servers e TOR users. Qualsiasi TOR user può essere un TOR server. In tal modo nessuno ‘possiede’ la totalità dei server.
Se da un lato questo costituisce una garanzia, occorre tuttavia tenere presente che i proxy anonimizzanti, inclusi i tor exit nodes, possono catturare tutto il traffico in uscita, ed inevitabilmente alcuni nodi tor nodes (e numerosi proxies di altro tipo) vengono allestiti proprio con tale obiettivo.

Nel Settembre 2007, un esperto di sicurezza svedese ha revelato che operando e monitorando dei Tor exit nodes aveva intercettato usernames e passwords di un gran numero di accounts di email. Dato che Tor non cripta il traffico tra exit node e target, qualsiasi exit node è in grado di catturare il traffico che passa attraverso di esso e che non faccia uso di crittazione end-to-end, ad esempio SSL.

Più in dettaglio:

TOR crea delle catene di 3 nodi ciascuna e modifica tali catene dopo qualche minuto. Le catene sono composte casualmente a partire da una Directory di nodi gestita da un piccolo numero di nodi principali.

TOR apre  una connessione tra il client ed il primo nodo (detto perciò anche EntryNode), quindi invia un segnale per aprire una connessione al secondo nodo, e successivamente al terzo nodo (perciò detto ExitNode).

In tal modo, la visita di un sito web viene attuata attraverso tre nodi differenti sparsi nel mondo.

Noi -> Nodo1 -> Nodo2 -> Nodo3 -> www.voipandhack.it

La crittazione operata da TOR è di tipo telescopico, vale a dire che ogni nodo può solamente conoscere le informazioni che lo riguardano, ma non ha la possibilità di decrittare completamente i dati che lo attraversano.

Nodo1
Il proprietario del primo nodo può sapere chi sia la persona (indirizzo IP) che intende navigare anonimamente, ma non pùò vedere i dati, che sono crittati. In breve: Nodo1 non può sapere cosa ho richiesto, ma può sapere chi sono.

Nodo2
Il proprietario del secondo nodo non può proprio venire a conoscenza di nulla di utile. Egli non sa chi abbia richiesto i dati, dato che tutte le richieste vengono “tunnelizzate” attraverso il primo nodo (che non fornisce alcuna informazione circa l’ origine della richiesta), e nemmeno può catturare i dati, dato che sono crittati.

Node3
Il proprietario del terzo nodo non sa chi abbia fatto la richiesta, dato che tutte le richieste vengono “tunnelizzate” attraverso il primo nodo, ma è in grado di vedere i dati richiesti, poiché il terzo nodo li può, anzi li deve, decrittare.
Il terzo nodo possiede la chiave per decrittare i dati per il semplice motivo che deve comunicare con il sito web richiesto (che in genere non utilizza alcun tipo di crittazione).

Se il proprietario di Nodo1 (o Nodo3) possedesse anche Nodo2, la cosa non comporterebbe per lui alcun vantaggio.
Controllare Nodo1 e Nodo3 offre più possibilità.
Nodo1 conosce l’ identità della persona che fa la richiesta, Nodo3 sa come decrittare i dati.
Collegare le due cose è ancora molto difficile.

Supponiamo di controllare Nodo1 e Nodo3, e che il nostro amico Pippo voglia navigare anonimamente Google. Di conseguenza noi veniamo a sapere che Nodo1 riceve una richiesta da Pippo, ma non sappiamo cosa Pippo abbia richiesto. Contemporaneamente, vediamo che qualcuno (non possiamo affermare che sia Pippo), ha richiesto la homepage di Google tramite Nodo3. Mettere in relazione i due fenomeni affermando che Pippo è la persona che ha richiesto la homepage di Google è pressoché impossibile.
Il solo modo di collegare l’identita di un utente con i dati richiesti consiste nell’ usare una tecnica che considera la temporizzazione e calcola il tempo medio necessario a qualcuno per connettersi tramite Nodo1 ad un secondo nodo sconosciuto e quindi a Nodo3, ed assume che chiunque impieghi lo stesso tempo medio sia lo stesso utente di entrambi i nodi.
Ovviamente, se qualcuno controllasse tutti e tre i nodi, potrebbe conoscere sia l’ identità dell’utente che i dati richiesti, e potrebbe mettere facilmente in relazione entrambi. Tuttavia è estremamente improbabile che una sola persona riesca a controllare tutti e tre i nodi a causa del fatto che le catene sono costituite casualmente dal client TOR  e che vi è sempre un numero ragionevolmente alto di nodi TOR (circa 1800)

TOR offre anche una soluzione ad un problema ben noto che di solito non viene prestata attenzione da altre applicazioni anonimizzanti, e cioè il fatto che i DNS servers vengono a conoscenza di qualunque utente abbia fatto una richiesta DNS attraverso di essi. Questo significa in pratica che se volessi visitare google.com anonimamente ed utilizzassi un qualsiasi tipo di anonymizer, Google non potrebbe venire a conoscenza della mia identità dall’esame dei logs del Web server, ma ci riuscirebbe esaminando i logs del DNS server, dato che ogni volta si effettua una ricerca, una query DNS, non anonima, viene inviata ai DNS servers di Google. TOR risolve questo  problema con l’ausilio di Privoxy, che consente che le queries DNS vengano instradate attraverso i tunnel anonimizzanti della rete TOR.

Da quanto visto si può ben affermare che le reti Tor forniscano un altissimo livello di anonimato, eppure occorre menzionare ancora due particolari vulnerabilità, per così dire indirette:

1. La prima tecnica consente ad un website di conoscere la reale identità di un visitatore che utilizzi TOR rilasciando una speciale applet Java che invii un pacchetto ICMP (TOR non supporta il tunneling ICMP) al website rivelando in tal modo il reale indirizzo del visitatore.
2. Il secondo metodo richiede all’attaccante il controllo dell’ ExitNode, in modo da poter iniettare codice javascript oppure una applet Java nelle pagine restituite all’utente e che secondo lo schema precedente ne rivelino l’ identità.

Send post as PDF to