Sistemi di autenticazione non crittografici

L'autenticazione non crittografica è uno strumento usato quotidianamente da chiunque utilizzi internet o anche solo il computer, anche senza esserne direttamente cosciente. Esempi possono essere:

• le e-mail
• le connessioni TCP
• il DNS

Questo tipo di autenticazione si basa, di solito, su

• indirizzi IP;
• porte TCP;
• meccanismi specifici di ogni applicazione

• transaction ID;
• numeri di sequenza.

Il motivo per cui si usa questo tipo di autenticazione è la facilità con cui può essere implementata, l'assoluta mancanza di problemi riguardanti la distribuzione delle chiavi e sicuramente un risparmio notevole in termini di potenza computazionale.

La differenza tra l'autenticazione crittografica e quella non crittografica è che quest'ultima protegge soltanto per quegli attacchi che non provengono da un nodo sul percorso tra un computer e l'altro; al contrario, se Trudy si trova sul percorso tra Alice e Bob, qualsiasi forma di protezione non crittografica sarà vana.

Il metodo principe con cui si possono portare gli attacchi ai protocolli non crittografici è l'address spoofing, cioè immettere nella rete dei pacchetti che hanno come mittente un indirizzo falso.

Il protocollo TCP

I pacchetti TCP posseggono un campo SYN (più precisamente un flag), che viene usato quando si vuole inizializzare una connessione, ed un campo SEQ, che è un numero di sequenza; i numeri SEQ, all'inizio della connessione, dovrebbero essere definiti in maniera casuale, nonostante questo le vecchie implementazioni dello stack TCP/IP di BSD usavano numeri SEQ deterministici e facilmente prevedibili.

L'autenticazione del client viene fatta in base al suo indirizzo IP ed al numero di sequenza:

Three-way handshake

Se i numeri di sequenza successivi al primo risultano sbagliati, allora la connessione verrà rifiutata (o i messaggi sbagliati saranno scartati); in teoria, soltanto il client ed il server (e tutti coloro che sono sul percorso dei pacchetti) dovrebbero essere a conoscenza del numero di sequenza: questo è un meccanismo di autenticazione e protezione della connessione mirato ad impedire che chi non si è collegato al server possa sfruttare la connessione altrui per far eseguire dei comandi al server.

La stessa protezione avviene nel senso inverso, dove il client rifiuterà i pacchetti non corretti, impedendo per esempio che venga caricata una pagina web falsa.

Predizione del numero di sequenza

Ipotizziamo che un attaccante voglia far sì che un server esegua dei comandi, facendo in modo di non essere scoperto (e facendo ricadere la colpa su qualcun altro).

Il primo passo da fare, come anche nel caso di connessioni con protezione crittografica, è studiare il bersaglio, aprendo e chiudendo un numero sufficiente di connessioni a capire qual è la logica con cui il server assegna i numeri che-dovrebbero-essere-casuali SEQ.

File:Sicurezza TCP attacco SEQ predizione.png

A questo punto, una volta che l'attaccante ha capito la logica ed ha una ragionevole probabilità di successo, farà sì che il client da incolpare non sia più in grado di operare nella rete, per esempio con un attacco DoS. Lo step successivo è inizializzare una connessione con il server, facendo IP spoofing con l'indirizzo del client: potendo prevedere i numeri di sequenza assegnati dal server, riuscirà a bypassare il meccanismo di autenticazione e potrà impartire dei comandi al server TCP.

È da notare che tutti i messaggi di risposta dei comandi saranno mandati all'indirizzo del client vittima dell'attacco DoS che, proprio a causa dell'attacco, non potrà mandare un pacchetto RST per chiudere la connessione fittizia, né accorgersi del fatto che qualcuno sta usando il suo indirizzo per portare attacchi nella rete. Di conseguenza, nemmeno l'attaccante potrà avere un riscontro diretto degli effetti del suo attacco, non può sapere se sono andati a buon fine.

Quando invece l'attaccante è sul percorso tra il suo bersaglio e l'IP che vuole simulare, allora può tranquillamente aprire una connessione con il server senza preoccuparsi di nulla: sarà in grado di intercettare (e bloccare) tutti i pacchetti e potrà ricevere le conferme delle sue azioni.

Questo esempio serve a far capire che le connessioni non crittografate possono certo essere usate, ma non per qualcosa di serio ed importante. Ecco perché, per esempio, è meglio usare SSH piuttosto che il suo omologo non cifrato RSH (Remote shell), così come è meglio usare il TLS per le connessioni nelle quali transitano dati importanti come password, dati bancari, dati postali, messaggi di chat privati, ...

Il protocollo DNS

Il resolver risolve iterativamente l'indirizzo simbolico in indirizzo IP

Nel protocollo DNS, i client chiedono ad un resolver della rete locale di tradurre per loro un indirizzo simbolico www.wikipedia.org in un indirizzo IP. Il resolver contatta i root server DNS attraverso i quali, per step successivi, ottiene:

• l'indirizzo IP del server DNS di .org;
• l'indirizzo IP del server DNS di wikipedia.org;
• l'indirizzo IP della macchina www all'interno del dominio wikipedia.org.

A questo punto, il resolver dice al client qual è l'indirizzo IP del server richiesto ed il suo lavoro è finito.

Osserviamo più da vicino lo scambio dei messaggi:

File:Sicurezza DNS scambio messaggi ok.png

Gli strumenti che permettono di autenticare i messaggi sono

• l'indirizzo di destinazione
• la porta sorgente
• il transaction ID

Fintanto che questi numeri sono giusti, la risposta è considerata attendibile. Il problema è che, se Trudy è sul percorso, può modificare la risposta ed ingannare il resolver.

Ipotizziamo che Trudy non sia sul percorso, ma che voglia comunque attaccare il resolver. Il server (software) per DNS da sempre più usato è BIND; questo server, fino al 1997, utilizzava il transaction ID, che il protocollo prevede casuale, come un contatore. Inoltre, fino alla versione 8, BIND ha sempre usato la stessa porta sorgente per fare le richieste. Con un comportamento di questo tipo, le protezioni usate diventano, in un sol colpo, perfettamente inutili.

Quello che deve fare Trudy, a questo punto, è studiare il resolver DNS, per capire i suoi comportamenti. Se il server è implementato male come lo erano le vecchie versioni di BIND, bastava una semplice richiesta DNS (legittima) per avere tutte le informazioni necessarie per preparare l'attacco.

File:Sicurezza DNS attacco fuori percorso.png

Passiamo all'attacco vero e proprio. Trudy fa una richiesta DNS al resolver, chiedendo per esempio un dominio celebre (e redditizio) come poste.it; prima ancora che il server root DNS possa aver risposto, Trudy invierà una serie di pacchetti con IP spoofing e i valori di porta e transaction ID corretti: in questo modo, il resolver DNS accetterà come valido l'IP fornito da Trudy, sul quale lei ha preventivamente installato un server che simula il sito in questione.

Il risultato di questo attacco è che, per un tempo arbitrariamente lungo (scelto da Trudy stessa), il resolver DNS risponderà a tutte le richieste DNS per poste.it indirizzando gli utenti verso il sito-truffa di Trudy, invece che verso il vero sito richiesto dagli utenti.

Il fatto che il resolver DNS abbia la possibilità di mettere in cache la risposta di Trudy non fa che accentuare, a questo punto, la portata dell'attacco, dirottando un numero probabilmente elevato di utenti verso il sito truffa.

Fino al 2002, anno in cui è stato rilasciato BIND v9, praticamente tutti i resolver usavano la stessa porta per le richieste DNS.

Esercizio: Calcolo della probabilità di successo per l'attacco descritto

Sfruttiamo il paradosso del compleanno per calcolare la probabilità di successo del nostro attacco.

La distribuzione di probabilità descritta dal paradosso del compleanno indica una probabilità di successo

$P(A)=1-e^{-{\frac {x^{2}}{n}}}$

dove $n=2^{16}$ è la dimensione dello spazio generato con i 16 bit a disposizione del transaction ID. Allora, immettendo $x=213$ pacchetti nella rete, si ottiene

$1-e^{-{\frac {213^{2}}{2^{16}}}}=0,49956$

cioè, praticamente il 50% di probabilità di successo. Con $x=600$ pacchetti, si ha

$1-e^{-{\frac {600^{2}}{2^{16}}}}=0,99589$

cioè, praticamente il 100% di probabilità di successo. Per vedere la curva completa, si può usare il codice octave

 x= [1:700]; % numero di pacchetti immessi nella rete
 b = 16 % numero di bit del campo transaction ID
 prob = 1 - exp(-x^2/2^b);
 plot(t,prob)

Da questi risultati, si devono considerare alcuni fatti:

• quando un protocollo prevede un campo random, questo deve essere davvero casuale;
• anche se si disponesse del generatore di numeri casuali perfetto, la dimensione del numero è fondamentale per non esporre il proprio protocollo a rischi inutili;
• ad oggi, non esiste il generatore di numeri casuali perfetto.

Ad oggi, ancora molte reti usano vecchie versioni di BIND, quindi i problemi visti si possono incontrare, anche con grossi operatori nel campo delle telecomunicazioni.

Una soluzione che permette di abbassare moltissimo il rischio di attacchi è quella di impostare un firewall, affinché il servizio DNS risponda soltanto alle richieste interne e non a quelle esterne; se non altro, si limita il numero di calcolatori dal quale può provenire un attacco, ed osservando i log si riesce a stabilire da quale di questi è partito l'operazione di studio del resolver. Per questo scopo, è fondamentale che il resolver DNS ed il server authoritative per il dominio siano due calcolatori diversi: si espone all'esterno soltanto il server authoritative e non il resolver.

Quindi, in conclusione, è preferibile non usare l'autenticazione non crittografica, o almeno è utile affiancarla ad un firewall che divida in maniera chiara chi ha diritto ad accedere ai servizi di un server e chi, invece, non può accedervi.