Debolezze TCP e UDP

Attacchi per sostituzione di un partecipante

La categoria di attacchi che generalmente causa maggiori danni (minando l’integrità e la riservatezza dei dati, ma anche la fiducia degli utenti nel servizio) è rappresentata da quelli in cui l’attaccante riesce a sostituirsi a uno dei sistemi legittimi.

Pur essendo più frequente che simili attacchi siano condotti sfruttando i bug presenti negli applicativi e/o nelle configurazioni dei software che implementano il servizio sulle stazioni finali, esiste tecnicamente la possibilità di portare attacchi del genere traendo vantaggio dalle limitazioni intrinseche dei protocolli di trasporto UDP e TCP.

La sostituzione di un partecipante può essere tentata durante l’accesso di un utente legittimo al servizio (sostituzione on-the-fly) o a posteriori (replay attack), tramite replica di una sequenza prestabilita di pacchetti.

Se il protocollo di trasporto utilizzato è UDP, fondamentalmente stateless, gli attacchi basati su replica possono essere condotti con successo anche riproducendo la registrazione (ottenuta per esempio tramite un comune packet sniffer) della sequenza di datagrammi scambiati precedentemente tra client e server.

Nel caso del TCP, questa semplice tecnica è pressochè impraticabile a causa dell’elezione pseudocasuale dei numeri di sequenza da parte dei partecipanti.

Con il TCP vengono preferite altre tecniche di sostituzione più efficaci, denominate TCP Session Hijacking e Initial Sequence Number Prediction.

• TCP Session Hijacking
  si tratta di fatto di una tecnica di desincronizzazione di una sessione TCP che mira a creare una situazione di man-in-the-middle che permette all’attaccante di interagire con il flusso di segmenti TCP (leggere e/o alterare i pacchetti) scambiati tra client e server.
  Generalmente la desincronizzazione viene effettuata durante la fase di apertura della sessione TCP tra client e server.
  L’attaccante attende la risposta del server alla richiesta di apertura invocata dal client.
  Il segmento prodotto dal server conitiene i flag SYN e ACK entrambi settati. Intercettato tale segmento TCP, che viene regolarmente lasciato passare, l’attaccante invia un RST al server.
  In questa maniera il server ritiene chiusa la sessione half-open con conseguente deallocazine delle risorse impegnate (numeri di sequenza compresi).
  Il client invece, ricevuto il segmento inviato dal server, è indotto a credere che la fase di negoziazione della nuova sessione TCP proceda regolarmente, e invia il proprio acknowledgement.
  Per preservare l’illusione costruita, da qui in avanti la stazione dell’attaccante deve rispondere a ogni nuovo segmento TCP trasmesso dal client , compresi quelli contenenti dati, inviando regolarmente i riscontri positivi attesi.
  Il server ritenendo chiusa la sessione TCP scarta invece ogni segmento, a questa relativo, inviato dal client.Piuttosto che condurre la nuova sessione TCP con il client simulando le risposte del server (intervento attivo) l’attaccante può preferire un intervento passivo e redirigere i segmenti ai sistemi legittimi.
  Questo è possibile se, non appena inviato il RST, l’attaccante richiede l’apertura di una nuova sessione TCP con il server, anche usando le stesse porte, e gli stessi indirizzi IP (previo IP Spoofing), scelti in precedenza dal client, ma eleggendo numeri di sequenza iniziali diversi.
  In questo modo l’attaccante riesce a negoziare l’apertura di una seconda sessione TCP con il serve.
  Per preservare l’illusione costruita, da qui in avanti la stazione dell’attaccante deve rispondere a ogni nuovo segmento TCP trasmesso dal server, compresi quelli contenenti dati, inviando regolarmente i riscontri positivi attesi.
  Il client operando con la prima sessione TCP aperta scarta ogni segmento relativo alla seconda sessione TCP inviato dal server.

  In questa condizione l’attaccancte è generalmente in grado di leggere e/o alterare i pacchetti scambiati tra client e server senza che gli utenti ne siano consapevoli e le applicazioni coinvolte generino allarmi.
  Ciò è dovuto al comportamento standard seguito dalle stazioni alla ricezione di un segmento TCP fuori dall’intervallo definito dal meccanismo della finestra mobile.
  A differenza di quanto accade quando si utilizzano le porte e indirizzi non associati a una sessione TCP al momento attiva sulla stazione, in questo caso la stazione ricevente scarta semplicemente il paccchetto arrivato fuori sequenza.

  La possibilità di rilevare tempestivamente una condizione di TCP Session Hijacking è condizionata alla capacità della stazione (o di un eventuale dispositivo di monitoring dedicato) di rilevare la presenza di un numero insolitamente elevato di segmenti TCP fuori sequenza.

• Initial Sequence Number Prediction
  La tecnica di sostituzione precedentemente descritta produce risultati ottimali se l’attaccante si trova in una condizione di man-in-the-middle.
  In questa condizione può infatti leggere i segmenti TCP scambiati e inserirsi in maniera fraudolenta nel flusso di pacchetti o sostituirsi a uno dei due sistemi dopo aver completato, al posto del partecipante legittimo, la negoziazione della nuova sessione TCP.Se l’attaccante non è in condizione

  di intercettare il flusso di pacchetti può comunque cercare di sostituirsi a un partecipante tentando la predizione del sequence number iniziale (ISN).
  Questa tecnica è la più complessa tra quelle presentate e consente di condurre attacchi si a di tipo DoS sia di sostituzione.
  La predizione del valore ISN può essere utilizzata sia per sostituirsi ad un server sia per sostituirsi ad un client.Un attaccante può sostituirsi ad un server operando come segue.
  Il primo compito dell’hacker è mettere fuori servizio il server a cui intende sostituirsi.
  Una volta ottenuto questo risultato preliminare, l’attaccante invia al client, a intervalli regolari, segmenti TCP con i flag SYN e ACK entrambi settati, segnalando che la richiesta di apertura per una nuova sessione TCP è stata accordata.
  Ovviamente il client processa con successo il segmento inviato dall’attaccante se e solo se ha prodotto una richiesta di apertura di una nuova sessione TCP proprio con i parametri contenuti nel falso segmento TCP.

  Il client scarta regolarmente tutti gli altri messaggi inviati dall’hacker che non sono associabili a richieste di apertura reali. Loscarto può avvenire secondo modalità diverse:
  – il client scarta i messaggi silenziosamente;
  – il client registra la ricezione in un file interno;
  – il client avvisa in tempo reale l’utente, e/o l’amministratore della stazione locale, della ricezione di messaggi che possono essere interpretati come tentativi di attacco da parte di hacker.

  In ogni caso, l’invio diretto di messaggi rivolti ad allarmare il server è generalmente poco efficace, in quanto difficilmente l’avviso potrà essere processato se la macchina server è stata resa indisponibile dall’attaccante, se non addirittura controproducente, complicando di fatto lo stato di congestione del server.

  La possibilità di rilevare tempestivamente una simile condizione di ISN prediction è condizionata alla capacità della stazione client (o di un eventuale dispositivo di monitoring dedicato) di rilevare la ricezione di un numero insolitamente elevato di segmenti TCP con SYN e ACK entrambi settati.

  Se invece il client ha appena inviato una richiesta di apertura, trasmettendo al server un segmento TCP con flag SYN settato, l’unica possibilità che gli rimane per non finire nella trappola tesa dall’hacker è legata al controllo del parametro trasportato nel campo acknowledgement number dei segmenti TCP ricevuti.
  Se tale valore non coincide con il precedente ISN inviato dal client, la stazione scarta il segmento TCP appena ricevuto, ed esegue la procedura stabilita.
  La riuscita dell’attacco di sostituzione del server è legata essenzialmente alla difficoltà di prevedere il valore ISN fissato dal client.
  Se l’hacker è in grado di fare questa predizione, può inserire il valore estrapolato nel segmento TCP inviato al client e completare l’apertura della sessione TCP.Nel caso di una corretta predizione la stazione client accetta il segmento TCP come se fosse prodotto dal server, decretando il successo dell’attacco.
  A questo punto, per sostituirsi completamente al server, l’hacker deve solo “imitare” il protocollo applicativo associato al servizio richiesto ed emulare le risposte del server.
  Generalmente è sufficiente una buona conoscenza del protocollo e la registrazione di precedenti sequenze di messaggi scambiati tra applicazioni client e server, simili a quelle oggeto dell’attacco, per investire il client di informazioni false.

Predizione del ISN

La predizione del ISN emesso dal client, è un compito più semplice di quello che sembra.

Molti sistemi prevedono infatti, semplici procedure pseudocasuali per la selezione degli ISN; procedure che producono risultati estremamente facili da estrapolare.

In alcuni sistemi i valori degli ISN sono funzione del solo valore segnato dall’orologio interno (clock) della stazione client al momento della generazione della nuova richiesta di apertura sessione TCP.

In tal caso, il valore del nuovo ISN può essere determinato conoscendo:

• Il valore di un precedente ISN;
• l’istante T₀ in cui è stato generato il precedente ISN;
• il ritardo ∆T con cui viene generato il nuovo ISN.

Se l’hacker conosce la funzione utilizzata dal client per generare ISN a partire da T_i, può facilmente predire il nuovo ISN, adottando la seguente procedura:

1. l’hacker invia al client una richiesta di apertura di una nuova sessione TCP per un servizio supportato dalla macchina che ospita il client target;
2. il client risponde normalmente alla richiesta emettendo un regolare segmento TCP con SYN e ACK settati e un proprio ISN (che può essere utilizzato come punto di partenza per ricavare il valore del clock interno della stazione client);
3. l’hacker ricava, invertendo la funzione pseudocasuale utilizzata per produrre il valore ISN appena ricevuto, il valore T₀ (sincronizandosi con l’orologio interno del client);
4. l’hacker calcola una sequenza di ISN, per ogni possibile T_i = T₀ + i∆T, nel tentativo di completare il suo attacco;
5. l’hacker invia a intervalli regolari ∆T, un segmento TCP, con flag SYN e ACK settati, con al suo interno il valore ISN oggetto della estrapolazione.

Se l’hacker non conosce precedentemente la funzione usata dal client per generare ISN a partire da T, il suo compito è più complesso ma non impossibile.

In tal caso risulta necessario inviare al client molteplici segmenti TCP per l’apertura di una nuova sessione.

In questo modo l’hacker riesce a determinare empiricamente l’andamento di ISN al variare di Ti.

Per poter estrapolare dai risultati sperimentali i nuovi ISN, è comunque indispensabile riuscire a misurare il tempo necessario per coprire il cammino di andata e ritorno tra la stazione client e la stazione controllata dall’attaccante.

Un attaccante può tentare di utilizzare la tecnica di predizione del valore ISN di un server per sostituirsi a un client.

Questo approccio per sostituirsi a un utente legittimo risulta efficace anche quando l’attaccante non è in condizioni di man-in-the-middle.

Generalmente gli attacchi basati su la predizione del ISN del server mirano a inserire informazioni flase sul server stesso e/o creare una situaizone di denial of service per gli altri utenti legittimi.

La riuscita di una sostituzione del client condotta a livello TCP/IP è il modo ideale per un hacker per far ricadere la responsabilità dell’attacco sul legittimo possessore dell’indirizzo IP associato al client e utilizzato per tutta la durata dell’attacco.

Anche in tal caso la possibilità di rilevare tempestivamente una condizione di ISN prediciton è condizionata alla capacità della stazione server (o di un eventuale dispositivo di monitoring dedicato) di rilevare la ricezione di un numero insolitamente elevato di segmenti TCP con SYN e ACK entrambi settati.

Per ridurre le probabilità di successo di questa forma di attacco è bene provvedere anche alla sostituzione del meccanismo pseudocasuale utilizzato nel calcolo dei valori di ISN, con un meccanismo in grado di generare numeri veramente casuali.

Meccanismi del genere sono implementati nei sistemi operativi più moderni, nonchè all’interno dei dispositivi che svolgono funzioni di gateway applicativo e che sono generalmente utilizzati per innalzare il livello di protezione perimetrale delle reti locali che ospitano server e client.

Ogni elemento che implementa lo stack TCP/IP, a prescindere dal suo ruolo in Internet dovrebbe disporre di un generatore di numeri casuali, per scongiurare il verificarsi di una sostituzione direttamente a livello TCP.

La presenza di un generatore di numeri casuali affidabile, è componente indispensabile anche per garantire il corretto funzionamento di elementi crittografici eventualmente utilizzati dal sistema.