Secondo Cloudflare, una vulnerabilità zero-day nel protocollo HTTP/2 è stata sfruttata per lanciare il più grande attacco DDoS mai registrato con 398 milioni di richieste al secondo, cinque volte di più del precedente record di 71 milioni di richieste al secondo. Google, Cloudflare e AWS hanno condotto un’analisi coordinata delle vulnerabilità per la falla identificata come CVE-2023-44487 o Rapid Reset, monitorando per mesi attacchi di livello applicativo (livello 7) molto più grandi di quelli considerati normali (il picco di attività si è avuto ad agosto). L’analisi di Cloudflare ha rivelato che i cybercriminali stavano sfruttando la suddetta vulnerabilità HTTP/2 utilizzando una rete di bot più piccola del solito, il che spiega in parte l’enorme numero di richieste al secondo.

“Una cosa fondamentale da notare riguardo all’attacco è che ha coinvolto una botnet di dimensioni modeste, composta da circa 20.000 macchine. Cloudflare rileva regolarmente botnet di ordini di grandezza superiori, con centinaia di migliaia o addirittura milioni di macchine”, ha dichiarato l’azienda. “Il fatto che una botnet relativamente piccola sia in grado di produrre un volume così elevato di richieste, con il potenziale di mettere fuori uso quasi tutti i server o le applicazioni che supportano HTTP/2, sottolinea quanto sia minacciosa questa vulnerabilità per le reti non protette”.

Tutti e tre i fornitori di servizi hanno pubblicato mitigazioni e implementato nuove tecnologie per proteggersi dagli attacchi Rapid Reset in futuro.

Come funziona Rapid Reset

Il metodo si basa sullo stream multiplexing, una caratteristica del protocollo HTTP/2 che consente di inviare più richieste HTTP a un server su una singola connessione TCP. Queste richieste vengono inviate in serie al server lungo quell’unica connessione; il server raccoglie i flussi di richieste, li elabora e risponde. In questo modo, quando il browser apre una pagina, può inviare richieste separate per tutti i contenuti della pagina in modo seriale su quell’unica connessione. Questo approccio dovrebbe essere più efficiente rispetto a quello tradizionale di HTTP/1.x, che in genere comporta l’impiego di tempo e risorse per stabilire più connessioni TCP parallele per recuperare i contenuti da un server. HTTP/2 fa tutto con un’unica connessione.

Una caratteristica della capacità di streaming del protocollo è la possibilità di inviare una richiesta e subito dopo annullarla, un’azione nota come azzeramento del flusso della richiesta. Quando un client effettua una richiesta e poi la annulla, il server rinuncia all’elaborazione della richiesta mantenendo la connessione HTTP/2 aperta. Questo evita di dover aprire e chiudere più connessioni TCP ed è utile, ad esempio, per recuperare un carico di immagini su una pagina e poi annullare quelle non visibili se la finestra le ha già superate.

2023_worlds_largest_rapid_reset_diagram.max-1616x909

Un normale attacco DDoS basato su HTTP/2 prevede che gli aggressori aprano il maggior numero possibile di questi flussi e attendano le risposte ad ogni richiesta da parte del server o del proxy prima di lanciare un’altra raffica di richieste, ripetendo il tutto più volte. Un server può consentire un numero massimo di flussi su una connessione TCP, quindi potrebbe accettare solo 100 flussi alla volta. L’aspetto fondamentale è che l’aggressore attende le circa 100 risposte prima di inviare un altro carico di richieste.

Gli attacchi Rapid Reset aggirano questo limite, permettendo a molte, molte più richieste di inondare un server. È semplice inviare una richiesta in un flusso e poi resettare rapidamente il flusso, annullando la richiesta e mantenendo la connessione aperta. Il server inizia a elaborare queste richieste e poi le interrompe; poiché ogni richiesta è stata annullata, non viene conteggiata nel numero massimo di flussi consentiti.

“Il client apre un gran numero di flussi in una volta sola, come nell’attacco HTTP/2 standard, ma invece di attendere la risposta del server o del proxy a ogni flusso di richieste, il client annulla immediatamente ogni richiesta”, come affermano gli ingegneri di Google Juho Snellman e Daniele Iamartino. Queste richieste annullate richiedono una grande quantità di lavoro inutile da parte del server, costandogli tempo e denaro per elaborare le richieste senza mai inviare nulla in risposta, mentre il cliente, o in questo caso l’attaccante, non paga quasi nessun costo per l’invio.

Mitigazioni

Cloudflare ha apportato modifiche al suo servizio di mitigazione DDoS per contrastare gli attacchi Rapid Reset, rendendolo disponibile a tutti i clienti. AWS ha dichiarato che coloro che hanno sviluppato una solida architettura resistente ai DDoS utilizzando CloudFront e AWS Shield avranno visto la disponibilità delle loro applicazioni inalterata grazie alle misure adottate da Amazon per sconfiggere gli attacchi Rapid Reset quando hanno iniziato a manifestarsi.

Google ha spiegato che esistono diversi modi per implementare le mitigazioni per gli attacchi Rapid Reset, ma ha sconsigliato l’uso dei frame GOAWAY, come raccomandato dalle specifiche HTTP/2 per la chiusura delle connessioni. Secondo Google, questi frame non sono stati creati per gestire il tipo di attività che si riscontra negli attacchi Rapid Reset e non dovrebbero essere utilizzati da soli, ma possono e devono essere utilizzati per limitare la creazione di flussi.

“Le mitigazioni per questo vettore di attacco possono assumere diverse forme, ma per lo più sono incentrate sul monitoraggio delle statistiche delle connessioni e sull’utilizzo di vari segnali e logiche aziendali per determinare l’utilità di ogni connessione”, hanno dichiarato i ricercatori di Google. “Ad esempio, se una connessione ha più di 100 richieste e più della metà è stata cancellata, potrebbe essere candidata a una risposta di mitigazione. L’entità e il tipo di risposta dipendono dal rischio per ogni piattaforma, ma le risposte possono andare da un’energica azione di GOAWAY, come discusso in precedenza, alla chiusura immediata della connessione TCP”.