Visualizza wikitesto di Sistemi di autenticazione non crittografici

{{Risorsa|tipo=lezione|materia1=Sicurezza nelle reti|avanzamento = 80%}}
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 [[w:Posta_elettronica|e-mail]]
* le connessioni [[w:Transmission_Control_Protocol|TCP]]
* il [[w:Domain Name System|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'[[w:Address_Resolution_Protocol#IP_Spoofing|''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:

[[Immagine:Tcp-handshake.svg|thumb|left|300px|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.

[[Immagine: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 [[w:Denial_of_service|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 [[w:Secure shell|SSH]] piuttosto che il suo omologo non cifrato RSH (''Remote shell''), così come è meglio usare il [[w:Transport Layer Security|TLS]] per le connessioni nelle quali transitano dati importanti come password, dati bancari, dati postali, messaggi di chat privati, ...

== Il protocollo DNS ==

[[Immagine:An_example_of_theoretical_DNS_recursion.svg|thumb|left|500px|Il resolver risolve iterativamente l'indirizzo simbolico in indirizzo IP]]

Nel protocollo [[w:Domain Name System|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:

[[Immagine: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 è [[w:BIND|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.

[[Immagine: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.

{{Matematica voce|Esercizio|Calcolo della probabilità di successo per l'attacco descritto|Sfruttiamo il [[w:Paradosso del compleanno|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

:<math>P(A) = 1 - e^{-\frac{x^2}{n}}</math>

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

:<math>1-e^{-\frac{213^2}{2^{16}}} = 0,49956</math>

cioè, praticamente il 50% di probabilità di successo. Con <math>x=600</math> pacchetti, si ha

:<math>1-e^{-\frac{600^2}{2^{16}}} = 0,99589</math>

cioè, praticamente il 100% di probabilità di successo. Per vedere la curva completa, si può usare il codice [[w:GNU_Octave|octave]]

<source lang="matlab">
 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)
</source> }}

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.