nghttp2 è una libreria C open-source fondamentale che implementa il protocollo HTTP/2. È ampiamente integrata nell’infrastruttura critica di Internet, inclusi server web (come Apache e NGINX), content delivery network (CDN), bilanciatori di carico e proxy di applicazioni. L’ubiquità della libreria implica che una vulnerabilità possa avere un impatto diffuso sul web.

Questa vulnerabilità rappresenta un rischio elevato per qualsiasi organizzazione che gestisca servizi esposti al pubblico che utilizzano la libreria nghttp2. Un exploit riuscito consente a un attaccante remoto non autenticato di innescare un Denial of Service (DoS), causando il crash di applicazioni web e API critiche. La complessità dell’attacco è bassa, richiedendo solo la capacità di inviare traffico HTTP/2 appositamente costruito.

Questa falla è una variante della tecnica di attacco “HTTP/2 CONTINUATION Flood”, divulgata pubblicamente e oggetto di discussione attiva tra i ricercatori di sicurezza. Sebbene non sia stato confermato alcun kit di exploit pubblico specifico, la semplicità del vettore di attacco indica un’alta probabilità di weaponization e un potenziale sfruttamento in ambienti reali. Tutti i sistemi esposti a Internet che utilizzano una versione vulnerabile della libreria devono essere considerati a rischio immediato.

Riassunto tecnico

La causa principale di questa vulnerabilità è classificata come CWE-400: Uncontrolled Resource Consumption. Essa deriva dal modo in cui la libreria nghttp2 gestisce i frame HEADERS HTTP/2 in arrivo che superano i limiti configurati sul server.

La sequenza tecnica dell’attacco è la seguente:

1. L’attaccante stabilisce una connessione HTTP/2 con un server di destinazione che esegue una versione vulnerabile della libreria nghttp2.
2. L’attaccante invia un flusso continuo di frame HEADERS, violando intenzionalmente i limiti di flusso preconfigurati.
3. La libreria riconosce correttamente la violazione e si prepara a inviare una risposta di errore 413 Payload Too Large. Tuttavia, per generare questa risposta, inizia a memorizzare in buffer gli header in arrivo, che sono eccessivi.
4. Il client dell’attaccante evita deliberatamente di leggere la risposta del server. Questo mantiene la connessione aperta e consente al client di continuare a inviare un numero illimitato di header.
5. Il buffer lato server all’interno della libreria nghttp2 cresce senza limiti man mano che accoda gli header dell’attaccante, portando a un’allocazione incontrollata della memoria.
6. Questa rapida e continua allocazione di memoria esaurisce infine tutta la memoria disponibile per il processo del server, causando la sua terminazione da parte del sistema operativo e provocando un Denial of Service definitivo.

Versioni interessate: Tutte le versioni di nghttp2 precedenti alle release correttive sono vulnerabili. Consultare gli avvisi specifici dei fornitori per i prodotti che includono la libreria.

Versioni correttive: La vulnerabilità è stata risolta nelle versioni più recenti della libreria nghttp2. Gli amministratori devono aggiornare all’ultima release sicura fornita dai rispettivi vendor upstream.

Raccomandazioni

• Applicare la patch immediatamente: Aggiornare tutti i sistemi che utilizzano la libreria nghttp2 a una versione corretta. Consultare gli avvisi dei fornitori di software (es. provider di server web, distributori di sistemi operativi) per ottenere gli aggiornamenti di sicurezza adeguati.

• Mitigazioni:

  • Se l’aggiornamento immediato non è possibile, considerare l’applicazione di regole di rate-limiting al perimetro di rete (es. WAF, load balancer) per limitare il numero di nuove connessioni HTTP/2 o la frequenza dei dati in ingresso da un singolo indirizzo IP.
  • Come ultima risorsa per i sistemi critici, la disabilitazione temporanea del protocollo HTTP/2 e il ritorno a HTTP/1.1 può mitigare questa specifica minaccia, sebbene possa avere implicazioni sulle prestazioni.

• Caccia alle minacce e monitoraggio:

  • Monitorare l’utilizzo della memoria sui server esposti al web per picchi improvvisi e inspiegabili. Correlare questi picchi con il processo server che gestisce il traffico HTTP/2.
  • Analizzare il traffico di rete per individuare un tasso anormalmente elevato di frame HEADERS HTTP/2 provenienti da un singolo indirizzo IP senza dati correlati o completamento del flusso.
  • Verificare i log dei server web o delle applicazioni per modelli di connessioni ripetute che vengono aperte ma mai chiuse correttamente.

• Risposta agli incidenti:

  • Se si sospetta un attacco DoS, implementare immediatamente un blocco temporaneo degli indirizzi IP sorgente coinvolti tramite il firewall o WAF.
  • Prima di riavviare il servizio andato in crash, se possibile acquisire un dump di memoria del processo, in quanto può essere utile per l’analisi forense.
  • Conservare i capture di pacchetti di rete e i log di server pertinenti al momento dell’incidente per ulteriori indagini.

• Difesa in profondità:

  • Assicurarsi che i servizi critici siano configurati con capacità di riavvio automatico (es. tramite systemd o altri gestori di servizio) per ridurre al minimo il downtime in caso di crash.
  • Implementare sistemi di monitoraggio e allerta dell’utilizzo delle risorse per fornire un avviso precoce in caso di attacchi di esaurimento memoria.