Attacchi DoS nei protocolli di trasporto TCP e UDP
Le limitazioni intrinseche presenti sia in UDP che in TCP relative all’autenticazione dei partecipanti rendono possibili numerose forme di attacchi di tipo Denial Of Service (DoS).
Per ottenere il proprio risultato l’attaccante cerca di sfruttare effetti che possano “amplificare” le sollecitazioni inviate al target.
In seguito vengono descritte due tecniche sfruttabili per ottenere attacchi DoS contro il protocollo UDP:
- Ping Pong Attack
L’attaccante invia un pacchetto UDP con un indirizzo IP falso al primo target (stazione A). Se la stazione A possiede un servizio in ascolto sulla porta richiesta, produce una risposta e la invia al possessore legittimo dell’indirizzo IP utilizzato dall’attaccante.
Se il secondo target (stazione B) prevede un servizio UDP sulla porta indicata come destinazione nel pacchetto ricevuto, anche esso produce un messaggio di risposta, instaurando così un traffico dati non legittimo che ha termine solo quando un datagramma UDP viene scartato dalla rete (per saturazione dei collegamenti o in seguito a un errore in trasmissione).
Conseguenza diretta di un simile attacco è il consumo delle risorse locali delle stazioni coinvolte e delle risorse di rete (bandwidth) per i collegamenti utilizzati nello scambio dati.
La migliore contromisura a un Ping Pong Attck è disabilitare ogni servizio UDP che possa essere utilizzato in maniera non legittima/non autenticata.
Per proteggere tutte le stazioni di una rete locale da simili attacchi è consigliabile filtrare i datagrammi relativi a tali servizi direttamente in ingresso alle interfacce dei propri gateway IP.
- Fraggle Attack
L’attaccante invia un flusso di richieste UDP (esempio servizio Echo) utilizzando come indirizzo IP destinazione l’indirizzo IP broadcast di una rete (che agisce da sistema amplificatore).
Le stazioni attestate alla rete amplificatrice per le quali è attivo il servizio Echo rispondono alla richiesta.
Se l’indirizzo IP sorgente utilizzato dall’attaccante è il risultato di un IP Spoofing, la vittima (il legittimo possessore dell’indirizzo IP), verrà investita da un cospicuo flusso di pacchetti UDP non sollecitati.
Conseguenza diretta di un simile attacco è la saturazione del collegamento a Internet in dotazione della rete amplificatrice, di quello della rete cui è attestata la stazione vittima, oltre al blocco o crash del sistema scelto come vittima.
La migliore contromisura è disabilitare ogni servizio UDP che possa essere utilizzato in maniera non legittima/non autenticata, e filtrare i datagrammi relativi a tali servizi, in special modo se indirizzati all’indirizzo IP broadcast della rete locale, direttamente in ingresso alle interfacce dei propri gateway IP.
La conduzione di attacchi DoS può essere effettuata anche contro il protocollo TCP.
Esistono numerose tecniche per ottenere una condizione di denial of service inviando segmenti TCP malconfigurati a una stazione target.
La ricezione di tali pacchetti genera nelle implementazioni del TCP/IP disponibili su sistemi operativi più datati, eccezioni non correttamente gestite che possono portare al blocco o al crash della stazione.
Nel seguito sono invece descritte tecniche di attacco DoS che non dipendono dalla particolare implementazione del protocollo TCP.
- SYN Flooding
L’attaccante può mettere fuori servizio un server inviando un consistente numero di segmenti TCP con flag SYN settato.
A questi messaggi il server risponde, dopo aver allocato le risorse necessarie a gestire la nuova sessione, con un secondo segmento TCP con flag SYN e ACK entrambi settati.
Un simile messaggio viene generalmente riscontrato dal client, che ha fatto richiesta di una nuova sessione TCP.
In caso di attacco l’hacker ignora semplicemente i segmenti TCP spediti dal server, senza inviare altri pacchetti.
In questa maniera le sessioni TCP sul server permangono in stato half-open per un tempo indefinito.
All’aumentare del numero di sessioni TCP pendenti, le risorse disponibili del server diminuiscono, fino al punto che la stazione non è più in grado di aprire nuove connessioni TCP, comprese quelle relative a richieste legittime inviate da client realmente interessati al servizio.
Un numero elevato di richieste pendenti può causare il blocco del sistema operativo o il crash del server.
Per proteggere le stazioni server di una rete locale da simili attacchi è consigliabile limitare superiormente il numero di segmenti TCP, con SYN settato, destinati per unità di tempo a un singolo server.
Ciò può essere ottenuto impostando filtri selettivi direttamente in ingresso alle interfacce dei propri gateway.
Se il sistema operativo lo consente, alla protezione precedentemente descritta, può essere affiancato un meccanismo in grado di limitare il numero di sessioni TCP pendenti complessive, che interessano ciascun server.
Tale valore deve essere inferiore del limite di richieste accettabili dal server prima che questo esaurisca tutte le risorse allocabili.
Potendo l’attaccante avvalersi di tecniche di IP Spoofing, l’indicazione del client richiedente il servizio non è molto utile per filtrare efficientemente i SYN destinati a un sistema target.
Esistono due possibili reazioni a un attacco di SYN Flooding che persiste nel tempo: eliminare le sessioni pendenti più datate rilasciando le risorse allocate, o mettere semplicemente in “quarantena” il server per un tempo prestabilito, dopo aver eliminato tutte le sessioni pendenti.
- TCP Session Desynchronization
Durante l’apertura di una nuova sessione TCP, le applicazioni coinvolte stabiliscono ogni volta una nuova coppia di sequence number di partenza (ISN).
Gli ISN garantiscono la sincronizzazione dei due partecipanti e costituiscono di fatto una primitiva forma di mutua autenticazione.
Il protocollo prevede infatti lo scarto di ogni segmento TCP ricevuto che non rispetta la sequenza stabilita.
Se un attaccante è in grado di iniettare segmenti TCP falsi nel flusso di pacchetti scambiato tra le applicazioni, può creare situazioni di desincronizzazione che possono portare ad attacchi di tipo DoS o di sostituzione di una delle due stazioni.
La desincronizzazione può avvenire durante la fase di apertura di una nuova sessione TCP o nella fase di trasferimento dati.
La prima tecnica viene generalmente utilizzata per sostituirsi ad uno dei due partecipanti creando scenari di tipo man-in-the-middle.
La seconda è più spesso impiegata per ottenere un attacco di tipo DoS.
In molte applicazioni è relativamente semplice inserire blocchi di dati o comandi che non producono effetti apparenti (per esempio il comando NOOP per il protocollo Telnet), oltre quello di incrementare il valore atteso del sequence number del ricevente.
In questo modo è possibile spingere una stazione a ignorare i dati successivamente inviati dall’altro partecipante.
Per ottenere la desincronizzazione permanente della sessione TCP corrente è sufficiente che l’attaccante invii una quantità di byte superiore all’ampiezza della finestra mobile del ricevente.
Questa tecnica può essere in teoria utilizzata anche da un hacker per accedere in modo illegittimo a un servizio, sfruttando magari il varco aperto da un utente legittimo dopo che questo ha superato con successo la prevista fase di autenticazione.
Se le credenziali utilizzate per l’accesso al servizio possono essere riutilizzate più volte non occorre desincronizzare una sessione TCP già aperta.
L’attaccante può usufruire del servizio semplicemente “mimando” il comportamento dell’utente legittimo a livello applicativo, non appena questo ha completato il proprio accesso al server.
- Reset della Sessione TCP
Un attacco DoS relativamente semplice (conducibile previo IP Spoofing) consiste nel “resettare” le connessioni TCP, legittimamente instaurate tra client e server.
In realtà non basta inviare un segmento TCP con campo RST = 1 per ottenere lo scopo.
È necessario che il ricevente giudichi valido il sequence number contenuto nell’intestazione.
Se l’attaccante può predire tale valore o semplicemente ne è a conoscenza grazie ad un packet sniffing di pacchetti legittimi scambiati tra stazioni finali, confezionare il reset è banale.
In caso di attacco DoS condotto in modalità “blind” il target può essere centrato con probabilità crescente all’aumentare della ampiezza della finestra mobile stabilita tra le stazioni finali.
Sono note in letteratura particolari condizioni di lavoro per cui l’ampiezza della finestra mobile può divenire così grande da rendere statisticamente semplice centrare un valore di Sequence Number corretto.
Questo scenario si verifica quando due entità finali mantengono la stessa connessione TCP molto a lungo, senza registrare errori e scambiandosi molti dati.
Per esempio tra due router di frontiera che scambiano corpose tabelle BGP sttraverso collegamenti punto-punto dedicati, affetti da bassissimo tasso di errore.
