HTTP/2 CVE-2019-9511 & CVE-2019-9513: sonde leggere

Repository con script di validazione controllata per i comportamenti associati alle CVE CVE-2019-9511 e CVE-2019-9513, entrambe relative a vettori di denial of service nelle implementazioni HTTP/2.

Gli script sono stati creati per supportare validazioni tecniche in ambienti autorizzati, consentendo di osservare se il server negozia HTTP/2 e risponde a pattern specifici relativi a Data Dribble e Priority Churn, senza eseguire un attacco di denial of service.

L'obiettivo è dimostrare il vettore in modo leggero e sicuro, con un basso volume di richieste e senza l'intento di rendere indisponibile l'ambiente.

CVE contemplate

Riepilogo delle vulnerabilità

CVE-2019-9511 — HTTP/2 Data Dribble

La CVE-2019-9511, nota come HTTP/2 Data Dribble, colpisce alcune implementazioni HTTP/2 che non gestiscono in modo efficiente la manipolazione della finestra di flusso e la consegna graduale dei dati.

In questo scenario, un attaccante può richiedere dati al server e manipolare il controllo di flusso per mantenere aperta la risposta e consegnarla in piccoli blocchi, come pacchetti da 1 byte. A seconda dell'implementazione, questo comportamento può causare un consumo eccessivo di CPU, memoria o risorse di connessione, con conseguente rischio di denial of service.

In questo repository, lo script correlato è:

data_dribble_probe.py

L'obiettivo dello script è validare il comportamento in modo leggero, senza generare carico aggressivo e senza tentare di causare indisponibilità.

Riferimenti:

• https://nvd.nist.gov/vuln/detail/CVE-2019-9511
• https://www.cve.org/CVERecord?id=CVE-2019-9511
• https://ubuntu.com/security/CVE-2019-9511

CVE-2019-9513 — HTTP/2 Priority Churn / Resource Loop

La CVE-2019-9513, nota come HTTP/2 Priority Churn o Resource Loop, colpisce alcune implementazioni HTTP/2 che elaborano in modo dispendioso le modifiche continue all'albero di priorità degli stream.

In questo scenario, un attaccante può creare più stream e modificare ripetutamente la priorità tra di essi, causando churn nell'albero delle priorità. A seconda dell'implementazione, questo comportamento può generare un consumo eccessivo di CPU e portare al denial of service.

In questo repository, lo script correlato è:

priority_churn_probe.py

L'obiettivo dello script è validare se il server accetta ed elabora i frame PRIORITY, utilizzando una bassa intensità e senza eseguire un attacco DoS.

Riferimenti:

• https://nvd.nist.gov/vuln/detail/CVE-2019-9513
• https://www.cve.org/CVERecord?id=CVE-2019-9513
• https://ubuntu.com/security/CVE-2019-9513

Nota sulle versioni interessate

Le CVE CVE-2019-9511 e CVE-2019-9513 non sono associate a un'unica versione specifica di server web, come solo nginx, Apache o Tomcat.

Esse colpiscono determinate implementazioni HTTP/2 in diversi prodotti, librerie, proxy, bilanciatori e server. Per questo, la validazione deve considerare quale componente sta negoziando ed elaborando HTTP/2 nell'ambiente analizzato.

Esempi di componenti che possono essere coinvolti:

nginx
Apache HTTP Server
Envoy
HAProxy
Tomcat
Jetty
Node.js
Go net/http2
nghttp2
CDN
WAF
Load Balancer
Ingress Controller Kubernetes

Il primo criterio tecnico è confermare se il servizio negozia HTTP/2 tramite ALPN. Se il servizio non negozia h2, questi script non sono applicabili.

La conferma della vulnerabilità per versione deve essere effettuata sulla base dell'advisory ufficiale del produttore del componente identificato.

Pre-validazione: verificare il supporto HTTP/2

Prima di eseguire gli script, verifica se il target negozia HTTP/2 tramite ALPN.

Usa solo il dominio nel comando, senza https://.

openssl s_client -alpn h2 -connect esempio.com.br:443 </dev/null 2>/dev/null | grep -i "ALPN"

È anche possibile usare un segnaposto:

openssl s_client -alpn h2 -connect <HOST>:443 </dev/null 2>/dev/null | grep -i "ALPN"

Output atteso:

ALPN protocol: h2

Se l'output indica h2, il servizio negozia HTTP/2 e gli script possono essere applicabili.

Se non c'è risposta o il protocollo negoziato è un altro, come http/1.1, gli script non sono applicabili per quell'endpoint.

Panoramica degli script

Flusso d'uso consigliato

L'ordine più logico per l'utilizzo degli script è:

1. Pré-validação HTTP/2 com openssl
   ↓
2. priority_churn_probe.py
   ↓
3. data_dribble_probe.py

Spiegazione rapida del flusso

Prima, usa il comando con openssl per confermare se il target negozia HTTP/2. Poi, usa priority_churn_probe.py per validare se il server accetta ed elabora i frame di priorità. Successivamente, usa data_dribble_probe.py per osservare il comportamento del server con una finestra di flusso ridotta, rilasciando piccoli volumi di dati in modo controllato.

Entrambi gli script sono probe leggeri. Non hanno l'obiettivo di causare indisponibilità, ma di generare un'evidenza tecnica del comportamento osservato.

Script

priority_churn_probe.py

Descrizione

priority_churn_probe.py è una PoC leggera per la validazione del comportamento correlato alla CVE-2019-9513, nota come HTTP/2 Priority Churn.

Lo script stabilisce una connessione HTTP/2 via TLS, apre piccoli stream HTTP e invia modifiche di priorità tramite frame PRIORITY. Successivamente, misura la latenza prima e dopo l'invio di questi frame per osservare se c'è una variazione nell'elaborazione.

Cosa fa lo script

• Negozia HTTP/2 tramite ALPN;
• Apre una connessione TLS con l'host indicato;
• Invia semplici richieste GET fino a tre path;
• Misura la latenza iniziale usando PING;
• Usa un fallback con GET se il PING non è sufficiente;
• Invia frame PRIORITY a bassa intensità;
• Misura la latenza dopo il churn di priorità;
• Mostra un confronto tra il tempo prima e dopo il test.

Scenario d'uso

Usa questo script quando è necessario validare se un server HTTP/2 accetta ed elabora i frame di priorità correlati al vettore Priority Churn, senza eseguire un test DoS aggressivo.

È indicato per la validazione controllata in pentest, l'analisi dell'esposizione HTTP/2 e la dimostrazione tecnica di un comportamento vulnerabile o potenzialmente sensibile.

Campi/parametri da modificare

Lo script riceve i valori tramite argomenti da riga di comando:

--host
--port
--paths
--shuffles

Spiegazione dei parametri

Path ideale per il test

Usa path leggeri, pubblici e a basso impatto, come:

/
/robots.txt
/favicon.ico
/health
/login

Evita path che eseguono operazioni pesanti, query complesse, generazione di report, upload, ricerca avanzata o qualsiasi funzionalità che generi carico sul backend.

Esempio di utilizzo sicuro

python3 priority_churn_probe.py --host esempio.com.br --port 443 --paths / /robots.txt /favicon.ico --shuffles 10

Output atteso

Esempio di output:

[OK] PING antes: 45.20 ms; após churn: 52.80 ms; shuffles=10
Sinal 9513: PRIORITY frames aceitos e processados; aumento sutil pós-churn evidencia o vetor (sem DoS).

Interpretazione del risultato

Se lo script riesce a negoziare HTTP/2, aprire stream e inviare frame PRIORITY, ciò indica che il server elabora questo tipo di comportamento.

Un lieve aumento della latenza dopo il churn può essere usato come evidenza tecnica dell'esistenza del vettore, ma non deve essere interpretato da solo come prova di un impatto grave. La classificazione finale dipende dal contesto, dalla versione del server, dall'architettura, dalle mitigazioni, da WAF/CDN e dalla configurazione HTTP/2.

data_dribble_probe.py

Descrizione

data_dribble_probe.py è una PoC leggera per la validazione del comportamento correlato alla CVE-2019-9511, nota come HTTP/2 Data Dribble.

Lo script stabilisce una connessione HTTP/2 via TLS, apre un singolo stream e manipola la finestra di controllo del flusso per rilasciare piccoli volumi di dati, simulando il comportamento di consegna graduale dei frame DATA.

Cosa fa lo script

• Negozia HTTP/2 tramite ALPN;
• Apre una connessione TLS con l'host indicato;
• Invia una richiesta GET per il path definito;
• Regola la finestra iniziale del flusso;
• Rilascia piccoli volumi di dati in modo controllato;
• Conta i frame DATA ricevuti;
• Mostra la quantità di byte rilasciati, i frame ricevuti e il tempo totale.

Scenario d'uso

Usa questo script quando è necessario validare se il server HTTP/2 risponde a un pattern di controllo del flusso ridotto, associato al vettore Data Dribble, senza eseguire un carico aggressivo.

È indicato per una verifica tecnica controllata, soprattutto quando strumenti automatizzati segnalano una possibile esposizione ed è necessario validare manualmente con un minor rischio operativo.

Campi/parametri da modificare

Lo script riceve i valori tramite argomenti da riga di comando:

--host
--path
--port
--bytes

Spiegazione dei parametri

Path ideale per il test

Usa un path semplice, statico o a basso costo per il server, come:

/
/robots.txt
/favicon.ico
/health
/login

Evita endpoint che eseguano query al database, autenticazione pesante, elaborazione asincrona, generazione di documenti o chiamate a sistemi interni.

Esempio di utilizzo sicuro

python3 data_dribble_probe.py --host esempio.com.br --path / --port 443 --bytes 12

Output atteso

Esempio di output:

[OK] HTTP/2 negociado; DATA frames recebidos: 12; bytes liberados: 12; tempo(ms): 1450
Sinal 9511: múltiplos DATA minúsculos entregues sob janela=1 (prova do caminho 'dribble' sem stress).

Interpretazione del risultato

Se lo script negozia HTTP/2 e riceve piccoli frame DATA man mano che la finestra di flusso viene rilasciata, ciò indica che il server elabora questo pattern di controllo del flusso.

Questo comportamento può essere usato come evidenza tecnica del vettore, ma la criticità deve considerare il contesto reale dell'ambiente, come il server utilizzato, la versione, i limiti di connessione, il bilanciatore, la CDN, il WAF, il timeout e le protezioni contro gli abusi.

Dipendenze

Gli script richiedono Python 3 e la libreria h2.

python3
pip
h2
ssl
socket
argparse

Le librerie ssl, socket, time, argparse e select fanno parte della libreria standard di Python.

La principale dipendenza esterna è:

h2

Installazione delle dipendenze

Installazione diretta:

python3 -m pip install h2

Installazione usando un ambiente virtuale:

python3 -m venv venv
source venv/bin/activate
pip install h2

Verifica l'installazione:

python3 -c "import h2; print('h2 instalado com sucesso')"

Regolazioni necessarie prima di eseguire

1. Confermare il supporto HTTP/2

Gli script dipendono dalla negoziazione HTTP/2 tramite ALPN.

Prima di eseguire, conferma che il server supporti HTTP/2:

openssl s_client -alpn h2 -connect esempio.com.br:443 </dev/null 2>/dev/null | grep -i "ALPN"

Output atteso:

ALPN protocol: h2

Se il server non negozia h2, gli script non saranno applicabili.

2. Usare solo l'FQDN nel parametro --host

Non inserire https:// nel parametro --host.

Corretto:

--host esempio.com.br

Errato:

--host https://esempio.com.br

3. Scegliere path leggeri

Preferisci path semplici:

/
/robots.txt
/favicon.ico
/health

Evita endpoint sensibili o pesanti:

/relatorios
/export
/search
/upload
/api/processamento

L'idea è validare il comportamento HTTP/2, non stressare il backend.

4. Mantenere valori bassi

Usa valori prudenti:

Per priority_churn_probe.py:

--shuffles 10

Per data_dribble_probe.py:

--bytes 12

Non aumentare questi valori in un ambiente di produzione senza un'autorizzazione esplicita.

Esempi di utilizzo

Pre-validazione HTTP/2

openssl s_client -alpn h2 -connect esempio.com.br:443 </dev/null 2>/dev/null | grep -i "ALPN"

Priority Churn — CVE-2019-9513

python3 priority_churn_probe.py --host esempio.com.br --port 443 --paths / /robots.txt /favicon.ico --shuffles 10

Data Dribble — CVE-2019-9511

python3 data_dribble_probe.py --host esempio.com.br --path / --port 443 --bytes 12

Raccomandazioni di mitigazione

Per ridurre i rischi associati agli attacchi DoS HTTP/2, si raccomanda di mantenere aggiornati server web, proxy, bilanciatori e librerie HTTP/2, applicare limiti di connessione, configurare timeout adeguati, limitare il numero di stream simultanei, limitare l'abuso dei frame HTTP/2, monitorare le anomalie di latenza e valutare la disattivazione di HTTP/2 nei servizi che non necessitano di questo protocollo.

È inoltre consigliato validare la protezione a livelli come CDN, WAF, reverse proxy, ingress controller e load balancer, poiché spesso l'esposizione reale dipende più dal perimetro che dall'applicazione finale.

La conferma della correzione deve essere basata sul componente che realmente termina ed elabora HTTP/2 nell'ambiente, come server web, proxy, bilanciatore, CDN o ingress controller.

Nota di sicurezza

Questi script devono essere utilizzati solo in ambienti autorizzati.

Sebbene siano stati scritti per un'esecuzione leggera, interagiscono direttamente con meccanismi HTTP/2 correlati a vettori DoS. Pertanto, l'uso deve essere allineato all'ambito formale del test, alle regole di ingaggio e ai limiti operativi definiti con il responsabile dell'ambiente.

Prima di eseguire in produzione, conferma:

• dominio autorizzato;
• finestra di test consentita;
• limite di intensità;
• path consentiti;
• contatti di contingenza;
• evidenze attese;
• criteri per l'interruzione del test.

Avviso legale

L'uso di questi script contro sistemi senza autorizzazione è proibito.

Lo scopo di questo repository è esclusivamente supportare attività di sicurezza legittime, come pentest autorizzati, validazione controllata delle vulnerabilità, laboratorio, studio tecnico e dimostrazione sicura del rischio.