Google ha registrato il più grande attacco DDoS sulla sua infrastruttura, con un'intensità di 398 milioni di richieste al secondo. Il nuovo attacco supera di 7 volte l'intensità del precedente attacco DDoS record, in cui gli aggressori erano riusciti a generare un flusso di 47 milioni di richieste al secondo. A titolo di confronto, tutto il traffico del Web è stimato tra 1 e 3 miliardi di richieste al secondo. Oltre a Google, anche le aziende Amazon e Cloudflare hanno subito l'attacco. La possibilità di un nuovo attacco è collegata alla scoperta di una vulnerabilità nel protocollo HTTP/2 (CVE-2023-44487), che consente di indirizzare un enorme flusso di richieste al server con un carico minimo sul client.
La nuova tecnica di attacco è stata battezzata "Rapid Reset" e sfrutta il fatto che i mezzi di multiplexing forniti in HTTP/2 permettono di creare un flusso di richieste all'interno di una connessione già stabilita, senza aprire nuove connessioni e senza attendere la conferma della ricezione dei pacchetti. La vulnerabilità è considerata una conseguenza di una lacuna nel protocollo HTTP/2, nella cui specifica è indicato che, nel tentativo di aprire un numero eccessivo di flussi, dovrebbero essere annullati solo i flussi che superano il limite, senza chiudere l'intera connessione di rete.
Analogamente ai metodi precedentemente utilizzati per attacchi su HTTP/2, nel nuovo attacco viene creato un gran numero di flussi all'interno di una sola connessione. La principale differenza del nuovo attacco è che, invece di attendere una risposta, dopo ogni richiesta inviata viene inviato un frame con il flag RST_STREAM, annullando immediatamente la richiesta. L'annullamento della richiesta in una fase iniziale consente di eliminare il traffico di ritorno verso il client e di eludere le limitazioni presenti sui server HTTP riguardo al numero massimo possibile di flussi aperti contemporaneamente all'interno di una connessione HTTP/2. In questo modo, nel nuovo attacco, il numero di richieste inviate al server HTTP smette di dipendere dai ritardi tra l'invio della richiesta e la ricezione della risposta (RTT, round-trip time) e si limita esclusivamente alla capacità di banda del canale di comunicazione.
Poiché per condurre un attacco dal lato client è sufficiente inviare richieste senza ricevere risposte, l'attacco può essere effettuato con costi minimi. Ad esempio, un attacco registrato dalla società Cloudflare di 201 milioni di richieste al secondo è stato realizzato utilizzando un botnet relativamente piccolo di 20.000 computer. Dalla parte server i costi per elaborare le richieste in ingresso sono significativamente più elevati, nonostante la loro cancellazione, poiché è necessario eseguire operazioni quali l'assegnazione di strutture dati per i nuovi flussi, l'analisi della richiesta, la decompressione dell'intestazione e la corrispondenza dell'URL con la risorsa. Durante un attacco a proxy inversi, l'attacco può estendersi ai backend, poiché il proxy potrebbe essere in grado di reindirizzare la richiesta al backend prima che il frame RST_STREAM venga elaborato.
Un attacco può essere effettuato solo su server vulnerabili che supportano HTTP/2 (uno script per verificare la presenza di vulnerabilità nei server, un toolkit per effettuare l'attacco). Attacchi su HTTP/3 non sono stati ancora registrati e la possibilità di effettuarli non è stata completamente analizzata, ma i rappresentanti di Google raccomandano agli sviluppatori server di aggiungere implementazioni di protezione per HTTP/3 simili a quelle implementate per bloccare gli attacchi su HTTP/2.
Sensibilità alla vulnerabilità e disponibilità di patch per i server HTTP e i proxy:
- nginx (annuncio, spiegazione che la vulnerabilità non si manifesta pienamente in nginx con la configurazione predefinita, poiché l'attacco si fermerà al limite sul numero di richieste per connessione (cioè dopo ogni 1000 richieste la connessione verrà resettata). Nella patch è stata aggiunta ulteriore protezione per limitare l'intensità delle richieste tramite la direttiva 'limit_req').
- In HAProxy è stata aggiunta una protezione efficace contro il superamento del limite sul numero di flussi HTTP/2 già nel 2018 e funziona dalla versione 1.9-dev.
- Apache httpd (viene creata una certa pressione su httpd, ma non si diffonde ai backend ed è limitata dai limiti di connessione per i client in vigore dal 2016).
- mod_h2 per Apache httpd.
- caddy
- envoy
- golang (il problema è stato risolto nelle versioni Go 1.21.3 e 1.20.10).
- h2o (patch).
- grpc-go
- hyper (la vulnerabilità non si manifesta).
- jetty (corretto nelle versioni 12.0.2, 11.0.17, 10.0.17 e 9.4.53.v20231009).
- netty
- nghttp2 (corretto nella versione 1.57.0).
- Facebook proxygen
- .NET e ASP.NET Core (la vulnerabilità colpisce il server http ASP.NET Core Kestrel).
- Node.js
- proxygen
- swift-nio-http2 (corretto nella versione 1.28.0).
- Apache Tomcat (corretto nelle versioni 11.0.0-M12, 10.1.14, 9.0.81, 8.5.94).
- Apache Traffic Server (corretto nella branch 9.2.x).
Fonte: opennet.ru
