L'azienda Google ha registrato il più grande attacco DDoS alla sua infrastruttura, con un'intensità di 398 milioni di richieste al secondo. Questo nuovo attacco è sette volte più intenso del precedente record di attacco DDoS, in cui i criminali sono riusciti a generare un flusso di 47 milioni di richieste al secondo. A titolo di confronto, tutto il traffico dell'intero Web è stimato a livelli di 1-3 miliardi di richieste al secondo. Oltre a Google, anche le aziende Amazon e Cloudflare hanno subito l'attacco. La possibilità di effettuare un nuovo attacco è legata alla scoperta di una vulnerabilità nel protocollo HTTP/2 (CVE-2023-44487), che consente di inviare un enorme flusso di richieste al server con un carico minimo sull'utente.
La nuova tecnica d'attacco è stata denominata «Rapid Reset» e sfrutta il fatto che i mezzi di multiplexing dei canali di comunicazione forniti in HTTP/2 consentono di generare un flusso di richieste all'interno di una connessione già stabilita, senza aprire nuove connessioni di rete e senza attendere la conferma di ricezione dei pacchetti. La vulnerabilità è considerata una conseguenza della mancanza di ottimizzazione del protocollo HTTP/2, la cui specifica indica che, al tentativo di aprire un numero eccessivo di flussi, devono essere annullati solo i flussi che superano il limite, senza chiudere l'intera connessione di rete.
Analogamente ai metodi d'attacco precedentemente utilizzati su HTTP/2, nel nuovo attacco viene creato un gran numero di flussi all'interno di una singola connessione. La differenza principale del nuovo attacco è che invece di attendere una risposta, dopo ogni richiesta inviata viene inviato un frame con il flag RST_STREAM, che annulla immediatamente la richiesta. L'annullamento della richiesta in una fase precoce consente di evitare il traffico di ritorno verso il client e di aggirare i limiti presenti sui server HTTP riguardo al numero massimo di flussi aperti contemporaneamente all'interno di una singola connessione tramite HTTP/2. Di conseguenza, nel nuovo attacco il volume di richieste indirizzate al server HTTP non dipende più dai ritardi tra l'invio della richiesta e la ricezione della risposta (RTT, round-trip time), ma è limitato solo dalla larghezza di banda del canale di comunicazione.
Poiché per condurre l'attacco dal lato client è sufficiente inviare richieste senza ricevere risposte, l'attacco può essere effettuato con costi di gestione minimi. Ad esempio, l'attacco registrato da Cloudflare a 201 milioni di richieste al secondo è stato effettuato con un relativamente piccolo botnet di 20.000 computer. Sul lato server i costi per gestire le richieste in arrivo sono notevolmente più alti, nonostante la loro cancellazione, poiché è necessario eseguire operazioni come l'allocazione di strutture dati per i nuovi flussi, l'analisi della richiesta, la decompressione dell'intestazione e il confronto dell'URL con la risorsa. Quando si attacca un proxy inverso, l'attacco può diffondersi a backend, poiché il proxy potrebbe riuscire a reindirizzare la richiesta al backend prima che il frame RST_STREAM venga elaborato.
L'attacco può essere effettuato solo su server vulnerabili che supportano HTTP/2 (esiste uno script per verificare la manifestazione della vulnerabilità sui server, strumenti per eseguire l'attacco). Non sono ancora stati registrati attacchi su HTTP/3 e la possibilità di eseguirli non è stata completamente analizzata, ma i rappresentanti di Google raccomandano agli sviluppatori server di aggiungere nelle implementazioni di HTTP/3 misure di protezione simili a quelle realizzate per bloccare l'attacco su HTTP/2.
Vulnerabilità e disponibilità di patch per server HTTP e proxy:
- nginx (annuncio, spiegazione che la vulnerabilità non si manifesta completamente in nginx nella configurazione predefinita, poiché l'attacco si scontra con il limite sul numero di richieste per connessione (ossia, dopo ogni 1000 richieste, la connessione verrà resettata). Nel fix è stata aggiunta una protezione aggiuntiva per limitare l'intensità delle richieste tramite la direttiva «limit_req»).
- In HAProxy, una protezione efficace contro il superamento del limite del numero di flussi HTTP/2 è stata aggiunta già nel 2018 e funziona a partire dalla versione 1.9-dev.
- Apache httpd (si crea un certo carico su httpd, ma non si diffonde ai backend e rimane entro i limiti di connessione dei client in vigore dal 2016).
- mod_h2 per Apache httpd.
- caddy
- envoy
- golang (problema risolto nelle versioni Go 1.21.3 e 1.20.10).
- h2o (patch).
- grpc-go
- hyper (la vulnerabilità non si manifesta).
- jetty (risolto nelle versioni 12.0.2, 11.0.17, 10.0.17 e 9.4.53.v20231009).
- netty
- nghttp2 (risolto nella versione 1.57.0).
- Facebook proxygen
- .NET e ASP.NET Core (vulnerabile è il server http ASP.NET Core Kestrel).
- Node.js
- proxygen
- swift-nio-http2 (risolto nella versione 1.28.0).
- Apache Tomcat (risolto nelle versioni 11.0.0-M12, 10.1.14, 9.0.81, 8.5.94).
- Apache Traffic Server (risolto nel ramo 9.2.x).
Fonte: opennet.ru
