Allarme su Internet

Recentemente è gravitata su Internet e sui giornali la notizia di una pericolosa falla del TCP\IP, il protocollo di trasmissione più diffuso nel web, che metterebbe a repentaglio la Rete. Il ricercatore americano Paul Watson che si occupa di sicurezza, ha presentato un articolo, "Slipping in the Window: TCP Reset Attacks", nella conferenza tenutasi a Vancouver: il CanSecWest Security Conference 2004 dal 21 al 23 Aprile scorso.

La scoperta riguarda un codice che permette di colpire una falla interna al TCP. Tale vulnerabilità del protocollo è già nota da tempo, ma fino ad oggi si è ritenuto che riuscire a sfruttarla equivalesse a indovinare un numero su una combinazione di 4,3 miliardi possibili, ovvero 124 anni di tentativi.
Studiando la struttura della tecnologia nucleo del Web, Watson ha identificato un metodo per forzare la chiusura della connessione tra due apparecchiature che siano in comunicazione tra loro tramite l'utilizzo del protocollo TCP. Ha scoperto in pratica, che qualsiasi numero compreso in una certa finestra di valori può permettere l'identificazione, all'interno di una sequenza, del prossimo pacchetto TCP. Questa tecnica renderebbe di fatto possibile indovinare la giusta sequenza di numeri in appena 15 secondi e con un semplice codice, fattibile da un programmatore in 5 minuti.

Inizialmente le preoccupazioni sono state vicine ad un generale stato di allarme, poichè secondo quanto comunicato dal National Infrastructure Security Co-ordination Centre (NISCC) , l'exploit, sarebbe in grado di agire sulle macchine connesse in Rete, ivi compresi i router, causando pericolosi Denial of Service (DoS), ponendo dunque le basi per un possibile blocco della navigazione. L'ente britannico ha affermato inoltre che il problema interessa "ogni servizio di rete o applicazione che si basa su di una connessione TCP".

Il TCP permette la connessione tra due host, che utilizzano lo stack TCP/IP. Per l'interoperabilità tra i vari protocolli dello stack, il TCP/IP è diventato lo standard di tutte le trasmissioni a commutazione di pacchetto. In sè, il TCP è un protocollo orientato alla connessione, ossia è quell'insieme di regole che permettono di "connetterci" ad un host e dialogare con lui utilizzando un protocollo di livello superiore, ad esempio HTTP, piuttosto che SNMP e così via. "Orientato alla connessione" riferito ai protocolli, significa che esiste una sorta di collegamento logico tra i due host di modo che il colloquio avvenga in maniera sicura con la conferma di cio' che si e' ricevuto, a differenza dei protocolli non orientati alla connessione che non garantiscono la corretta ricezione dei pacchetti, vedi UDP.

Per capire ciò, si può paragonare il colloquio tra due apparecchiature host ad una partita a scacchi, i cui giocatori si trovino in luoghi diversi e comunichino le proprie mosse per posta. A causa di possibili disguidi del servizio postale, le lettere con le rispettive mosse potrebbero non arrivare in sequenza, per ovviare a ciò, si decide di numerare le varie mosse in maniera tale che i giocatori possano rispondere alla mossa dell'avversario nella giusta sequenza; per cui banalmente, la lettera spedita con il numero 2 indica la seconda mossa eseguita in ordine cronologico. Se un giocatore si stanca, spedisce una lettera con scritto non gioco più. Chi la riceve, non trattandosi di una mossa del gioco, non controlla la sequenza ed interrompe la partita. A questo punto chiunque conoscesse l'indirizzo dei due giocatori potrebbe divertirsi a spedire una siffatta lettera per il gusto di interrompere il gioco.
Nel colloquio tramite TCP il meccanismo è simile: si numerano i messaggi in modo che possano poi essere riordinati, e si controlla che la sequenza nella quale vengono ricevuti sia corretta. Esiste quindi la possibilità di interrompere la connessione con quello che si chiama pacchetto di reset, che è previsto nel protocollo TCP per permettere di abbattere una determinata connessione quando qualcosa non va correttamente. Questo non rispetta il controllo della sequenza dei messaggi, per cui se "il numero" del pacchetto che contiene il messaggio di reset è compreso in una data sequenza, causa l'immediata chiusura della connessione.
Tornando ai nostri scacchisti può succedere che:
1-Esiste il telefono, per cui immediatamente si possono contattare e chiedere all'altro il motivo dell'interruzione del gioco.
2-Non esiste il telefono, si spedisce una lettera in cui si chiedono i motivi dell'interruzione.
Nel primo caso, una volta rilevate le cause (uno scherzo di un amico burlone), si riprende il gioco immediatamente, nel secondo caso passa molto più tempo.
Altrettanto succede nella rete, lo "scherzo" a seconda di chi colpisce può causare problemi più o meno gravi. Se un reset colpisce due PC che scambiano posta elettronica non si fa sentire, diverso è il discorso se colpisce un router che utilizza protocolli quali il BGP che in caso di reset possono impegnare l'apparecchio in un complesso ricalcolo di algoritmi di routing che a loro volta mettono in lista d'attesa coloro i quali utilizzano questi router per comunicazioni tra aree spesso molto distanti tra loro.

I dispositivi maggiormente a rischio sono infatti i router che si servono del Border Gateway Protocol (BGP), un protocollo utilizzato sulle dorsali Internet per far comunicare fra loro i router appartenenti a differenti domini. Il protocollo BGP è particolarmente vulnerabile perché prevede che i vari peer (ponti), costituiti dai border router, comunichino fra loro attraverso connessioni TCP permanenti. Il problema riguarda in sintesi l'implementazione di quasi tutti gli stack TCP, in quanto questi non verificano che i pacchetti cadano tra ACK e ACK+CWND-1, ovvero la window di trasmissione TCP, questo implica che, se viene inviato un RST con il sequence number nella windows, esso viene accettato. Quindi tutte le questioni sulla randomizzazione dei sequence number saltano, perché il largo spazio dei numeri di sequenza viene diviso per la dimensione della finestra del TCP, rendendo fattibile un attacco esaustivo.

Per l'attacco servono dunque SRC_IP, DST_IP, DST_PORT, e SRC_PORT. Quest'ultimo dato non è così banalmente ottenibile, ma studiando il comportamento di vari sistemi operativi, da quelli di base come Windows e Linux a quelli specializzati come l'IOS di Cisco, si scopre che i parametri non sono generati casualmente, fatto salvo OpenBSD.
Sapendo il numero di neighbor del router che usa il BGP, si prevede che in media metà delle sessioni le inizia questo e metà i suoi peer, e sapendo, o indovinando l'uptime, si riducono a una cinquantina i tentativi per indovinare la porta. A questo punto, presa una, le successive sono deterministiche, quindi la connessione resta poi disattivata per un tempo indefinito. Lo stesso problema si può trasferire dal BGP ai database, ai DNS zone transfer e così via.

E' stata inoltre verificata l'esistenza di un altro problema, potenzialmente più grave. Sull'invio di un SYN su connessione già aperta viene rimbalzato un RST che non dovrebbe esserci. O meglio, che dovrebbe esserci solo se il SYN ricade nella finestra di trasmissione, come per l'altra vulnerabilità. Pare che l'unico modo per risolvere il problema sia mettere effettivamente mano all'RFC del TCP.

Esemplificando: A invia a B un pacchetto con il flag SYN settato ad 1, e nel campo SN (serial number) un valore scelto a caso, che sarà l'origine da cui numerare i successivi pacchetti. Questo permette di rendere univoco ogni pacchetto della connessione. B, ricevuto il pacchetto SYN, risponderà con un SYN/ACK (flags SYN e ACK settati ad 1) che contiene nei campi SN e AN, rispettivamente, il suo SEQ_NUM (sequence number, generato anche in questo caso randomly) e in AN, che indica il prossimo pacchetto che l'host si aspetta di ricevere, il SEQ_NUM ricevuto da A, incrementato di 1. Quando A riceve il SYN/ACK, risponderà con un ACK finale (con flag ACK settato ad 1 per i pacchetti FIN e RST), con il campo SN = SEQ_NUM[A]+1 (che poi è l'AN ricevuto da B, in questo caso), AN = SEQ_NUM[B]+1 (A si aspetta di ricevere il pacchetto con quel numero di serie) e nel PDA (package data unit) cominceranno ad esserci i dati della connessione (segmenti).

Una volta terminato lo scambio di informazioni, quando si desidera chiudere la connessione, ci sono due modi: il "tear down" che è la prassi e che funziona nel seguente modo: quando A vuole chiudere la connessione manda a B un pacchetto FIN (flag FIN=1), B invia un ACK, e la connessione da A a B si chiude. Quando anche B ha finito di trasmettere, invia il suo FIN al quale A risponderà con un ACK finale. Allo scadere di un timeout, a questo punto, la connessione sarà chiusa.
Il secondo metodo, che avviene quando insorge un errore, è dato dal flag RST. Questo pacchetto chiude immediatamente la connessione, ed è superfluo persino l'invio del solito ACK da parte dell'altro end-point della connessione.

Se dunque, un eventuale attaccante riesce a sostituirsi ad A durante la connessione, inviando un pacchetto di RST con i dati di A (ip address, port number e SN), questo chiuderà la connessione tra A e B. Ora, il SN è un valore di 32 bit, deciso casualmente durante la fase di SET-UP della connessione, e, variando velocemente, è molto difficile da scoprire e da duplicare, anche perchè TCP è congegnato per scartare i pacchetti doppi che gli giungono (doppio è il pacchetto con stesso SN). Si è quindi pensato, per molto tempo, che il problema fosse solo teorico, fino a quando Paul A. Watson non ha scoperto che i pacchetti di RST (e piu in generale gli altri pacchetti) non devono necessariamente avere il numero di SN esatto, ma devono ricadere in un certa "vicinanza" (la Window, o Finestra di trasmissione) rispetto al numero di serie. La window serve a permettere il controllo dell'errore e del flusso da parte di TCP, facendo fronte ad eventi di congestione e/o perdita di pacchetti. Purtroppo, questo aumentare delle probabilità che un certo pacchetto venga accettato e quindi processato dallo stack ricevente, rende attuabile l'attacco di cui sopra, causando la disconnessione di una comunicazione in corso.
Inoltre i router usano scambiarsi messaggi di controllo, sfruttando il protocollo BGP, che si appoggia a connessioni TCP permanenti, o comunque di lunghissima durata, e quindi particolarmente esposte ad un attacco di questo tipo. Se l'attacco viene perpetrato ai backbone, o dorsali oceaniche, che sono reti in fibra ottica che collegano, ad esempio, Europa ed America, e che scaricano un'enorme parte del net-load tra i vari continenti e una di queste connessioni viene a mancare, il carico di traffico sulle altre backbone salirebbe enormemente, portandole al crash. A questo punto, si avrebbe una reazione a catena e il traffico, poco a poco nel giro di qualche minuto, porterebbe al crash la maggior parte dei router, paralizzando completamente la rete.

Tutto ciò se non fossero stati implementati, ormai da parecchio tempo, degli algoritmi di cifratura e firma dei pacchetti TCP per proteggere le backbone, e cioè l'hash md5 che impedisce il banale ip spoofing tra quegli host che usano il protocollo BGP. L'advisory di NISCC, propone inoltre l'utilizzo di IPsec, per patchare questa falla.

Un attacco di ampia scala che sfruttasse la vulnerabilità descritta e paventata dal NISCC potrebbe portare al black-out di ampie porzioni della Rete. Di fatto è solo il protocollo BGP ad essere vulnerabile per cui si potrebbero avere attacchi isolati e contro piccole reti.

Inoltre le dimensioni dei possibili effetti di questi attacchi non sono poi così devastanti considerando che al momento della conferenza Watson aveva reso noto in precedenza alle autorità di sicurezza questo rischio, e diversi fra i maggiori produttori di apparati di rete come Symantec e Cisco erano già corse ai ripari aggiornando i propri dispositivi per rafforzare la "falla".

La falla può essere risolta in vari modi, tra i quali c'è l'adozione del protocollo IP Security per la cifratura del traffico di rete e la riduzione della finestra TCP e tutti i maggiori provider di Internet avrebbero collaborato fra loro per adottare, fra i propri border router, connessioni sicure.