Originariamente pubblicato il 29 settembre 2023 | aggiornato il 10 ottobre 2023
Di: Dave Andrews, Marcus Hildum, Sergio Ruiz
Aggiornamento: Attacco di ripristino rapido HTTP/2 – CVE-2023-44487
In seguito al breve blog iniziale riportato di seguito, Edgio si è impegnato con colleghi di tutto il settore per la definizione e la divulgazione responsabile di un attacco CVE-2023-44487 – reimpostazione rapida HTTP/2.
Il problema sottostante riguarda molte implementazioni di server HTTP/2, il che rende le implicazioni dell’attacco molto più ampie di quanto si fosse precedentemente realizzato da Edgio. Edgio consiglia a tutti i clienti che eseguono un’infrastruttura pubblica di eseguire l’aggiornamento alle versioni con patch dei server non appena diventano disponibili e/o disattivare temporaneamente HTTP/2.
Edgio è disponibile anche per contribuire a ridurre i rischi per i nostri clienti eseguendo la terminazione HTTP/2 e il proxy HTTP/1,1 all’infrastruttura dei clienti. Contattateci per avviare questo processo.
Il 28 agosto 2023 alle 18:43, PST, gli ingegneri di Edgio hanno osservato un aumento dell’utilizzo della memoria sui nostri edge server, delle percentuali di richieste a diverse grandi proprietà web e del volume di log generati all’edge.
Il traffico, ben presto identificato come un attacco, era nuovo perché era osservabile solo nei registri del nostro bilanciamento del carico di livello 7. Edgio esegue il nostro motore di caching e proxy HTTP personalizzato, Sailfish, sia come bilanciamento del carico di livello 7 (che chiamiamo “frontend”) sia come livello di caching e proxy (il “backend”). In questo modo è possibile utilizzare strumenti e registrazioni comuni a entrambi i livelli, rendendo banali i confronti tra di loro.
Quando abbiamo scavato nei registri del frontend, abbiamo osservato alcuni comportamenti interessanti che indicano un attacco:
- Il numero di richieste per i singoli client era molto più alto del solito: Durante l’attacco abbiamo visto istanze di oltre 20.000 richieste su un singolo socket.
- Nessun byte inviato ai client.
- Il tempo totale di richiesta, dall’inizio alla fine, è stato compreso tra 1 e 2 millisecondi, tutti utilizzati per avviare una nuova connessione proxy ai backend.
- Tutte le connessioni che mostravano il comportamento erano connessioni HTTP/2.
Sulla base di queste osservazioni iniziali, abbiamo teorizzato che l’utente malintenzionato abbandonasse le richieste utilizzando il frame RST_STREAM DI HTTP/2 e avviasse nuove richieste sullo stesso socket, molto rapidamente.
Successivamente, abbiamo suddiviso i nostri sforzi in tre flussi di lavoro distinti:
- Indagare su eventuali problemi che potrebbero influire sulla libreria HTTP/2 utilizzata, nghttp2, che potrebbero dimostrare la causa principale.
- Creazione di variabili Sailfish per esporre i fondamenti di questo comportamento e consentire mitigazioni.
- Creazione di nuove metriche, dashboard e avvisi per identificare più rapidamente questo tipo di attacco.
1) inviato… ma davvero nghttp2
Dopo una piccola ricerca, abbiamo trovato in questo numero Envoy, un proxy di servizio che Edgio non utilizza sull’edge, e il corrispondente CVE. Dopo una revisione più approfondita del diff, abbiamo capito che questo problema non era solo nell’inviato, ma in realtà in nghttp2, che usiamo.
Poco dopo la divulgazione sono state rilasciate una richiesta pull e un tag point per nghttp2, affrontando il problema sottostante. La mancanza di una specifica CVE allocata per nghttp2 aveva fatto sì che il nostro sistema di scansione CVE automatizzato, che utilizziamo per tenere traccia delle vulnerabilità nel software chiave che utilizziamo, non avesse risolto il problema in origine.
Abbiamo immediatamente avviato il processo di aggiornamento e distribuzione di questa dipendenza, che è stato completato alcune settimane fa.
2. Percentuale di ripristino richiesta
Parallelamente, abbiamo lavorato per identificare il comportamento dell’attacco a livello di programmazione, all’interno di Sailfish stesso, al fine di poter intervenire immediatamente per prevenire problemi di prestazioni o affidabilità. Abbiamo deciso di implementare una variabile di configurazione (h2_remote_reset_percent) all’interno di Sailfish, che avrebbe monitorato la percentuale di richieste su una determinata connessione che è stata reimpostata dal client.
L’aggiunta, insieme a una variabile esistente per il conteggio delle richieste su una singola connessione, ci ha consentito di creare una regola che chiudesse immediatamente una connessione a un client che aveva superato la soglia di richiesta e che aveva reimpostato più di una percentuale di richieste configurata. Abbiamo integrato questa configurazione in normali casseforti funzionanti, che ci consentono di disattivarla per posizioni o clienti specifici.
Nello pseudocodice questo aspetto è:
if request_count > 1000 and
h2_remote_reset_percent > 99 and
pop ~ ".*" and
customer_id not in () then
connection.silent_close();
fi
Dopo un’attenta convalida per evitare qualsiasi impatto involontario sul traffico dei nostri clienti, la nuova regola è stata implementata e gli ingegneri di Edgio hanno continuato a monitorare eventuali ulteriori anomalie.
3. Conteggi e rapporti
Per identificare più rapidamente quando si verificano attacchi di questo tipo, abbiamo configurato un nuovo dashboard e un nuovo avviso in base al numero di frame HTTP/2 RST_STREAM ricevuti dai client in una posizione. Questo, insieme a una visione singolare della disponibilità della memoria e dei controlli dello stato, ci ha dato un chiaro segnale di potenziale degradazione dovuta a questo tipo specifico di attacco:
Tuttavia, siamo rimasti preoccupati per altri potenziali tipi di attacco che potrebbero interessare solo i frontends in modo specifico. Per fornire visibilità su questo problema più generale, abbiamo iniziato a monitorare il rapporto tra il tasso di transazione tra i frontend e i backend in una determinata posizione. I dati di base per questo confronto sono stati una parte fondamentale del nostro monitoraggio per molto tempo.
Osservando il comportamento normale, è possibile vedere la forte striatura intorno a 1, il rapporto previsto, poiché ogni richiesta che arriva a un front-end si traduce in una singola richiesta di back-end. Inoltre, è visibile una banda più vicina a 0,5 e 0,25, che si verifica principalmente in luoghi di test inattivi, dove sistemi come purge e controllo dello stato causano l’elaborazione di più transazioni interne da parte dei backend:
Durante l’attacco iniziale, tuttavia, è possibile vedere chiaramente l’effetto su questo rapporto:
Gli avvisi correnti sono configurati in modo da attivarsi quando il rapporto supera un determinato valore, creando un incidente per i tecnici del supporto Edgio per eseguire il triage e avviare le fasi di mitigazione.
Riepilogo
Si trattava di un nuovo tipo di attacco interessante, che sfruttava una vulnerabilità divulgata relativamente di recente in una libreria ampiamente utilizzata. Fortunatamente, il team di Edgio ha lavorato rapidamente per migliorare la nostra consapevolezza operativa, mitigare la causa principale specifica dell’attacco e introdurre mitigazioni generiche e modificabili per questa classe di attacchi.
Naturalmente, stiamo lavorando sempre a miglioramenti come questo, come nuovi modi per identificare gli attori cattivi tramite le impronte digitali, e integrare questo lavoro nella nostra suite di prodotti per la sicurezza per consentire un blocco e una limitazione della velocità più persistenti.
Mai un momento noioso a Edgio.
Per saperne di più sulla nostra protezione DDoS a spettro completo, parte della premiata soluzione WAAP (Web Application and API Protection) di Edgio, contattate i nostri esperti qui.
