Un bug in HTTP/2 moltiplica gli attacchi DDoS

Una vulnerabilità del protocollo HTTP/2 ha permesso agli hacker di sfruttare una sua funzionalità per esporre i server delle applicazioni web e i proxy web a attacchi DDoS (Distributed Denial of Service) di portata inedita negli ultimi due mesi. Google, Amazon Web Services, CloudFlare e altri operatori IT hanno lavorato in privato per elaborare delle soluzioni e delle patch prima di rendere pubblica la falla.

Gli attacchi DDoS, chiamati HTTP/2 Rapid Reset, si basano sulla capacità del protocollo HTTP/2 di gestire più flussi HTTP contemporaneamente. Il protocollo permette di inviare diverse richieste HTTP in parallelo sulla stessa connessione TCP, senza doverne aprire di nuove. Il punto debole è una funzione specifica: la possibilità di interrompere unilateralmente i flussi. Le aziende sono invitate a controllare se i loro partner IT hanno rilasciato delle patch o delle raccomandazioni di mitigazione per questa vulnerabilità.

Attacchi DDoS più efficaci

Nella vecchia versione 1 del protocollo HTTP, ancora supportata dalla maggior parte dei server e dei client web, è possibile inviare diverse richieste su una singola connessione TCP, ma ciò avviene in modo seriale e il server elabora le richieste e risponde nell’ordine in cui sono state ricevute. Nel caso di HTTP/2, diverse richieste, chiamate “stream” e costituite da frame di tipo HEADERS o DATA, possono essere inviate contemporaneamente e in modo disordinato su una connessione TCP. Con il multiplexing dei flussi, ogni flusso è associato a un identificatore, in modo che il server sappia sempre a quale flusso appartiene il frame e come rispondere.

Gli attacchi DDoS sfruttano le caratteristiche di efficienza del protocollo web

Questo multiplexing consente un uso più efficiente delle connessioni TCP e accelera i tempi di caricamento delle pagine. Immaginate una moderna pagina web contenente una moltitudine di risorse, script di terze parti e immagini caricate da diverse posizioni. Un browser che accede a questa pagina tramite HTTP/2 inizierà immediatamente a caricare queste risorse in parallelo, dando priorità a quelle visibili all’utente. Se l’utente fa immediatamente clic su un pulsante e lascia la pagina, il browser può chiudere i flussi anche se le risorse non sono state completamente caricate o renderizzate, senza chiudere completamente la connessione e aprire ulteriori richieste.

“Dalla fine del 2021, la maggior parte degli attacchi DDoS Layer 7 che abbiamo osservato sui servizi Google e sui progetti Google Cloud protetti da Cloud Armor si sono basati su HTTP/2, sia per il numero di attacchi che per la velocità massima delle richieste“, hanno dichiarato gli ingegneri di Google in un post sul blog che spiega il nuovo attacco. “Uno degli obiettivi principali di HTTP/2 era l’efficienza e, purtroppo, le caratteristiche che rendono HTTP/2 più efficiente per i clienti legittimi possono essere utilizzate anche per rendere più efficienti gli attacchi DDoS“, hanno aggiunto i ricercatori.

Eludere i limiti di flusso simultaneo

Dato che un server deve consumare cicli di CPU e memoria per elaborare ogni frame e flusso, gli sviluppatori del protocollo erano consapevoli fin dall’inizio che sarebbe stato possibile abusare dei flussi simultanei per esaurire le risorse di un server e quindi causare un denial of service. Per questo motivo hanno aggiunto un parametro chiamato SETTINGS_MAX_CONCURRENT_STREAMS. Il server lo comunica ai client endpoint alla prima connessione tramite un frame SETTINGS.

Per impostazione predefinita, il valore di questo parametro è illimitato, ma i progettisti del protocollo raccomandano che non sia inferiore a 100 per mantenere un parallelismo efficiente. Per questo motivo, in pratica, molti client non aspettano il frame SETTINGS e assumono semplicemente che il limite minimo sia 100 e inviano 100 frame fin dall’inizio. Il problema deriva da un’altra caratteristica chiamata RST_STREAM, che sta per “reset stream”. Si tratta di un tipo di frame che un client può inviare a un server per indicare che l’ID di uno stream precedentemente aperto deve essere annullato.

Come una funzione di ripristino rapido può diventare un’arma per gli attacchi DDoS

Ciò consente al client di annullare al volo le richieste di risorse che non sono più necessarie, ad esempio perché l’utente ha lasciato la pagina prima che la risorsa fosse caricata. È utile perché indica al server di smettere di rispondere a una richiesta precedente e di non sprecare larghezza di banda. Ma c’è un problema. Inviando un frame RST_STREAM, il flusso mirato non viene più conteggiato nel limite massimo di flussi contemporanei, quindi il client può aprire immediatamente un nuovo flusso dopo aver inviato un reset per un flusso precedente. Ciò significa che anche con un limite di 100 flussi simultanei, il client può aprire e resettare in rapida successione centinaia di flussi sulla stessa connessione TCP. Di conseguenza, il server deve spendere risorse per elaborare i frame RST_STREAM. Anche se non è molto, con milioni di richieste si accumula rapidamente.

Attacchi DDoS più potenti

Utilizzando questa tecnica, gli hacker sono riusciti a lanciare attacchi DDoS su una scala senza precedenti contro i server ospitati da Google, Cloudflare e AWS. “Quando un server HTTP/2 è in grado di elaborare i frame RST_STREAM inviati dai client e di smantellare lo stato abbastanza rapidamente, questi ripristini rapidi non rappresentano un problema“, spiegano gli ingegneri di Cloudflare nel loro rapporto. “I problemi iniziano a sorgere se c’è un ritardo o uno slittamento nell’elaborazione. Il client può inviare così tante richieste da accumulare un arretrato, causando un consumo eccessivo di risorse sul server“.

Il più grande attacco HTTP/2 Rapid Reset osservato da Google ha raggiunto un picco di oltre 398 milioni di richieste al secondo (rps). In confronto, il più grande attacco osservato dall’azienda nel 2022 ha raggiunto un picco di 46 milioni di richieste al secondo. L’attacco che ha preso di mira Cloudflare in agosto ha raggiunto 201 milioni di richieste al secondo, tre volte di più del più grande attacco DDoS precedentemente rilevato dal provider. Questo attacco HTTP/2 Rapid Reset è stato lanciato da una botnet di soli 22.000 computer, un numero ridotto rispetto ad altre botnet.

Misure di mitigazione

Le strategie di mitigazione per questi attacchi non sono semplici, poiché alcune richieste di cancellazione RST_STREAM possono essere legittime, quindi ogni proprietario di server deve decidere quando si verifica un abuso e come adattare la risposta in base alle statistiche di connessione e alla logica aziendale. Ad esempio, se una connessione TCP ha più di 100 richieste e il client ne annulla più del 50%, la connessione può essere considerata abusiva. Le risposte possono andare dall’invio forzato di frame GOAWAY alla chiusura immediata della connessione TCP. Un’altra risposta potrebbe essere quella di bloccare l’indirizzo IP incriminato dall’accesso al servizio HTTP/2 e di relegarlo solo temporaneamente all’HTTP 1.x.

Il problema dei filtri IP è che diversi client possono condividere lo stesso indirizzo IP e non tutti sono dannosi. Limitando le richieste all’HTTP 1.x, i client non dannosi che si trovano dietro un indirizzo IP filtrato potranno comunque accedere al servizio web, anche se le loro prestazioni saranno ridotte. Anche gli sviluppatori di Nginx, un popolare reverse-proxy e load balancer, hanno proposto misure di mitigazione basate su funzioni specifiche già implementate dal server, come keepalive_requests, limit_conn e limit_req.

Nei prossimi giorni verrà inoltre distribuita una patch che limiterà ulteriormente l’impatto di questi attacchi. Microsoft, AWS, F5 e altre società di infrastrutture, hanno pubblicato misure di mitigazione o patch. Gli utenti possono controllare regolarmente il modulo ufficiale nel CVE Tracker per trovare i link alle risposte aggiornate dei fornitori.