{"id":110728,"date":"2023-10-11T03:10:14","date_gmt":"2023-10-11T01:10:14","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-protokole-http-2-zadejstvovannaya-v-krupnejshej-ddos-atake"},"modified":"2023-10-11T03:10:14","modified_gmt":"2023-10-11T01:10:14","slug":"uyazvimost-v-protokole-http-2-zadejstvovannaya-v-krupnejshej-ddos-atake","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/uyazvimost-v-protokole-http-2-zadejstvovannaya-v-krupnejshej-ddos-atake","title":{"rendered":"Vulnerabilit\u00e0 nel protocollo HTTP\/2, utilizzata nel pi\u00f9 grande attacco DDoS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Google ha registrato il pi\u00f9 grande attacco DDoS sulla sua infrastruttura, con un'intensit\u00e0 di 398 milioni di richieste al secondo. Il nuovo attacco supera di 7 volte l'intensit\u00e0 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 \u00e8 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\u00e0 di un nuovo attacco \u00e8 collegata alla scoperta di una vulnerabilit\u00e0 nel protocollo HTTP\/2 (CVE-2023-44487), che consente di indirizzare un enorme flusso di richieste al server con un carico minimo sul client. <\/p>\n

Una nuova tecnica di attacco \u00e8 stata chiamata \"Rapid Reset\" e sfrutta gli strumenti di multiplexing forniti da HTTP\/2, consentendo di formare un flusso di richieste all'interno di una connessione gi\u00e0 stabilita, senza aprire nuove connessioni di rete e senza aspettare la conferma di ricezione dei pacchetti. La vulnerabilit\u00e0 \u00e8 considerata una conseguenza di un difetto nel protocollo HTTP\/2, il quale specifica che nel 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. <\/p>\n

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 \u00e8 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\u00e0 di banda del canale di comunicazione.

\"Vulnerabilit\u00e0<\/center> <\/p>\n

Poich\u00e9 per condurre un attacco dal lato client \u00e8 sufficiente inviare richieste senza ricevere risposte, l'attacco pu\u00f2 essere effettuato con costi minimi. Ad esempio, un attacco registrato dalla societ\u00e0 Cloudflare di 201 milioni di richieste al secondo \u00e8 stato realizzato utilizzando un botnet relativamente piccolo di 20.000 computer. Dalla parte server<\/a> i costi per elaborare le richieste in ingresso sono significativamente pi\u00f9 elevati, nonostante la loro cancellazione, poich\u00e9 \u00e8 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\u00f2 estendersi ai backend, poich\u00e9 il proxy potrebbe essere in grado di reindirizzare la richiesta al backend prima che il frame RST_STREAM venga elaborato. <\/p>\n

Un attacco pu\u00f2 essere effettuato solo su server vulnerabili che supportano HTTP\/2 (uno script per verificare la presenza di vulnerabilit\u00e0 nei server, un toolkit per effettuare l'attacco). Attacchi su HTTP\/3 non sono stati ancora registrati e la possibilit\u00e0 di effettuarli non \u00e8 stata completamente analizzata, ma i rappresentanti di Google raccomandano agli sviluppatori server<\/a> di aggiungere implementazioni di protezione per HTTP\/3 simili a quelle implementate per bloccare gli attacchi su HTTP\/2. <\/p>\n

Sensibilit\u00e0 alla vulnerabilit\u00e0 e disponibilit\u00e0 di patch per i server HTTP e i proxy: <\/p>\n