Lenti, poco costosi, difficili da individuare, non banali da prevenire: identikit degli attacchi "pigri", la nuova minaccia per i sistemi informatici

Nelle ultime settimane sulla rete GARR abbiamo avuto esperienza di un tipo di DDoS non nuovo ma non comune, utilizzato sempre più spesso causando parecchi disservizi.

La caratteristica principale di questi DDoS è che possono essere effettuati anche da un solo dispositivo attaccante, non hanno bisogno di molte risorse o grandi botnet.

Inoltre, non vengono rilevati facilmente poiché generano pochissimo traffico di rete composto da pochissimi pacchetti scambiati: i normali sistemi di rilevamento DoS e DDoS che si basano sul superamento di soglie (di flussi o pacchetti) non si attivano in caso di questi tipi di attacchi.

Simona Venuti
GARR
Servizio GARR CERT
This email address is being protected from spambots. You need JavaScript enabled to view it.

Uno dei motivi per cui stanno aumentando rapidamente è l’utilizzo sempre più diffuso del protocollo HTTP/2, adottato di recente e supportato da vari siti web famosi (Twitter, Facebook, Google). Essendo relativamente nuovo, il protocollo non è ancora maturo e presenta alcune vulnerabilità. Un’altra ragione della loro rapida diffusione è che possono venir lanciati da qualsiasi dispositivo, anche sistemi embedded, quali lavatrici, frigoriferi, stampanti, insomma, tutto il nuovo mondo IoT e soprattutto da telefoni cellulari infettati. Dal momento che spesso riescono a superare i sistemi di rilevamento, mandano pacchetti con calma e non hanno bisogno di CPU potenti, vengono chiamati slow DoS, o lazy DoS.

Attacchi slow HTTP

Questi attacchi vengono veicolati atmotraverso il protocollo HTTP/1 e HTTP/2 e sfruttano diverse vulnerabilità, sia del protocollo in sé che dei server web sviluppati per supportarlo. Spesso sono vulnerabilità intrinseche in alcuni server web, che è difficile correggere, perché sono inerenti all’architettura stessa del codice o del protocollo.

SlowLoris (CVE-2016-1546)

Questo tipo di attacco di tipo DDoS fu creato da Robert “RSnake” Hansen e fu largamente utilizzato durante le elezioni presidenziali in Iran nel 2009. Sta tornando nuovamente alla ribalta perché sfrutta vulnerabilità di apache 1.x e apache 2.x che, per problemi architetturali, non possono essere corrette dagli sviluppatori. L’attacco funziona così: il client malevolo apre una connessione HTTP col server tramite il noto sistema del 3-way handshake del TCP/IP, composto dalla sequenza dei pacchetti di tipo SYN, ACK, SYN-ACK. Una volta che la connessione è aperta, il client chiede una pagina web tramite una GET, per esempio GET index.html

Il malware fa in modo che questa richiesta abbia tutti gli header HTTP in regola, ma sia incompleta: il server può solo restare in attesa del completamento, e la connessione rimane “appesa”. Dal momento che i server solitamente dopo un certo tempo di timeout chiudono d’ufficio tutte le connessioni rimaste appese, il malware richiede prima di essere tagliato fuori un’altra pagina con una GET incompleta, aumentando il numero dei thread del processo cosicché, indipendentemente dal valore del timeout impostato sul server, i thread non potranno mai essere azzerati. Il server, da parte sua, continuerà ad assegnare risorse a questo client malevolo fino a quando non avrà impegnato tutte le sue risorse e non sarà più in grado di accettare nuove richieste. Ed ecco servito il DoS.

Questo attacco è semplicemente geniale, perché non è facilmente identificabile dai sistemi di rilevamento oggi disponibili. In pratica non viene rilevato dalle sonde DoS e DDoS, perché genera pochissimo traffico, solo semplici GET che non si concludono mai; non viene rivelato da Intrusion Detection System dal momento che la richiesta è una richiesta legittima e conforme allo standard del protocollo, come ci si aspetta da un client normale; infine funziona su moltissimi web server con HTTP/1 e su tutti quelli con HTTP/2.

Per mitigare SlowLoris esistono comunque alcune contromisure. L’idea è di limitare le sessioni sul server tenendole al di sotto del massimo di quelle che può supportare, cercando di eliminare prima possibile quelle che restano appese molto a lungo. Purtroppo però ogni sito web deve valutare il numero massimo di connessioni che può supportare e in base a quello giocare con alcuni parametri di configurazione. Dal punto di vista del malware utilizzato, riscontriamo che ultimamente è stata fatta anche una versione che funziona su piattaforma Android: si suppone che sia la più utilizzata perché dai log delle macchine attaccate si nota una preponderanza di device mobili fra gli attaccanti.

R.U.D.Y. (R-U-Dead-Yet?)

R.U.D.Y è un altro sistema a basso costo per bloccare i server web, che si basa sullo stesso meccanismo di SlowLoris, cioè sottomettere al web server richieste lecite, ma che in questo caso sono HTTP POST molto lunghi. In pratica il malware si connette al web server e manda gli header dei comandi HTTP completi, ma tramite una qualsiasi form, manda col comando POST un file di grandi dimensioni (campo content-lenght: dell’header HTTP) limitando al massimo la velocità nell’inviare pacchetti, per esempio spedendo solo 1 byte per pacchetto ed un pacchetto ogni 110 secondi. Supponendo che il file da spedire sia di 1GB la connessione HTTP potrebbe restare attiva anche per circa un anno. Le informazioni inviate al server web, scomposte in pacchetti molto piccoli ed inviati a bassa velocità, non possono essere rifiutate dal server web, perché sta aspettando tutti i dati dichiarati nel content-lenght. Basterà quindi mandare un certo numero di connessioni di questo tipo, lecite e normali, che restano attive molto a lungo, per ottenere lo scopo di esaurire le risorse del server e impedirgli di accettare nuove connessioni

Esistono molte varianti di R.U.D.Y., che nel tempo si sono adattate in maniera molto intelligente ai possibili sistemi di individuazione e mitigazione, le ultime versioni supportano anche connessioni a proxy tramite SOCKS, l’utilizzo di cookies di connessione e la possibilità di spedire pacchetti a velocità casuale (ma sempre bassa) per simulare una latenza non costante nella connessione di rete col server. Anche in questo caso gli unici sistemi possibili di mitigazione sono nel limitare il numero di connessioni, limitare la grandezza dei file trasmissibili mediante il comando POST e definire i timeout per la durata della connessione opportuni.

È opinione comune che il trend delle minacce si sposti sempre più su questi tipi di attacchi DoS che coinvolgono risorse e applicazioni specifiche (Layer7 DoS attack) perché sono sufficienti all’attacco molte meno risorse dei classici attacchi DoS e DDoS, che invece causano la saturazione di tutta la capacità di banda della vittima. Inoltre la diffusione esponenziale di device mobili e IoT, sistemi che hanno singolarmente pochissima banda e CPU, ma sono praticamente infiniti nel numero, favorisce l’utilizzo e lo sfruttamento da parte degli attaccanti di questo tipo di tecnologia.

Ne sentiremo sicuramente ancora parlare.

Genio del Male

Esempio del funzionamento di SlowLoris in un’immagine. Il meccanismo illustrato si riferisce ad apache; sugli altri server come ngnix, IIS, Jetty (Application Server) il funzionamento può essere un po’ diverso, ma il principio è lo stesso.