Breve spiegazione della falla che affligge TCP e dei reali rischi.

Questo testo è estratto da un mio post su di un forum. Potrebbe contenere errori di concetto, di battitura, grammatica, sintassi HTML o altro. Se foste così; gentili da riportarli all’autore, sarebbe un atto di estrema gentilezza.

La falla di TCP di cui stiamo parlando, è nota da parecchio tempo. Darò una breve spiegazione di come funziona TCP per fare chiarezza a chi non conosce questo protocollo, prima di iniziare con la spiegazione della falla.

TCP, o Transmission Control Protocol, è un protocollo (un sistema di regole) che permette la connessione tra due host, che fa parte dello stack TCP/IP. Per la bontà del protocollo, e soprattutto dell’interoperabilità tra i vari protocolli dello stack, il TCP/IP è diventato lo standard DE FACTO di tutte le trasmissioni a commutazione di pacchetto. In sè, TCP è un protocollo orientato alla connessione. Per intenderci, è quell’insieme di regole che ci permettono di “connetterci” ad un server, e dialogare con lui utilizzando un protocollo di livello superiore (ad esempio HTTP, piuttosto che SMTP ecc ecc). Ora, non importa sapere come una connessione TCP ha inizio e come evolve, ma sicuramente questa è una buona occasione per impararlo no? Allora cominciamo: Abbiamo due host (sistemi) A e B, che vogliono comunicare tra di loro.

Per prima cosa, 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 (e l’origine dei nostri guai). 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 il SEQ_NUM ricevuto da A, incrementato di 1. Il campo AN, per la cronaca, indica il prossimo pacchetto che l’host si aspetta di ricevere.

Quando A riceve il SYN/ACK, risponderà con un ACK finale (con flag ACK settato ad 1, non starò a ripeterlo 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. Uno “dolce”, e uno “violento”. Inutile dire che la disconnessione violenta avviene quando insorge un errore, mentre il “tear down” (disconnessione “dolce”) è la prassi. Come funziona il tear down. A (supponendo che sia lui a voler chiudere la connessione) manda a B un pacchetto FIN (bla bla bla… flag FIN=1… bla bla bla). 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 metodo brusco invece, è dato dal flag RST. un po’ come il Reset del computer, questo pacchetto chiude immediatamente la connessione, ed è superfluo persino l’invio del solito ACK da parte dell’altro end-point della connessione. Questo,(molto) in breve, il funzionamento di una connessione TCP.

Veniamo ora ai guai del nostro beneamato trasmission protocol. Se 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, in quanto, in pratica, irrealizzabile. Tutto questo fino a quando Paul A. Watson non si è messo a studiare per bene le specifiche del protocollo e 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 è fondamentale in quanto 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 abbiamo parlato prima.

Ora, la cosa gia cosi è drammatica, in quanto un attaccante può causare la disconnessione di una comunicazione in corso. Ma i guai non sono finiti. Chi tra voi sa cos’è un router, saprà anche che questi router usano scambiarsi messaggi di controllo, sfruttando un protocollo che si chiama BGP, e che si appoggia a connessioni TCP permanenti (o cmq di lunghissima durata), e quindi particolarmente esposte ad un attacco di questo tipo. Ora, chi tra noi conosce anche la struttura intima della rete di Internet, sa che ci sono dei *cardini* attorno ai quali transita una notevole quantità del traffico prodotto dalla rete, e sono le così dette backbone, o dorsali oceaniche. Queste 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. Mettiamo ora il caso che una di queste connessioni venga a mancare, perchè subisce un attacco di questo tipo. Il carico di traffico sulle altre backbone salirebbe enormemente, portandole al crash. A questo punto, si avrebbe una reazione a catena. Il traffico, poco a poco (nel giro di qualche minuto), porterebbe al crash la maggior parte dei router, paralizzando completamente la rete.

Ora, vogliamo evitare allarmismi inutili. Per proteggere le backbone, sono stati implementati, ormai da parecchio tempo, degli algoritmi di cifratura e firma dei pacchetti TCP tramite l’hash md5 che impedisce il banale ip spoofing tra quegli host che usano il protocollo BGP. Ma capiamo tutti che questo non è piu sufficiente, e la “nuova” riapertura di questa falla, puo essere davvero critica, in alcuni casi, e deve essere risolta (il fatto che non ci siano pericoli imminenti, non significa che si possa lasciare tutto come sta). L’advisory di NISCC, propone l’utilizzo di IPsec, per patchare questa falla, e invito tutti quelli che fossero interessati, a leggersi tutorial e FAQ su questo interessante protocollo.

Annunci

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione /  Modifica )

Google photo

Stai commentando usando il tuo account Google. Chiudi sessione /  Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione /  Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione /  Modifica )

Connessione a %s...