Sondes légères HTTP/2 CVE-2019-9511 & CVE-2019-9513

Dépôt contenant des scripts de validation contrôlée pour les comportements associés aux CVE CVE-2019-9511 et CVE-2019-9513, toutes deux liées à des vecteurs de déni de service dans les implémentations HTTP/2.

Les scripts ont été créés pour appuyer les validations techniques dans des environnements autorisés, permettant d'observer si le serveur négocie HTTP/2 et répond à des schémas spécifiques liés à Data Dribble et Priority Churn, sans exécuter d'attaque par déni de service.

L'objectif est de prouver le vecteur de manière légère et sûre, avec un faible volume de requêtes et sans viser à rendre l'environnement indisponible.

CVE concernées

Résumé des vulnérabilités

CVE-2019-9511 — HTTP/2 Data Dribble

La CVE-2019-9511, connue sous le nom de HTTP/2 Data Dribble, affecte certaines implémentations de HTTP/2 qui ne gèrent pas efficacement la manipulation de la fenêtre de flux et la livraison progressive des données.

Dans ce scénario, un attaquant peut demander des données au serveur et manipuler le contrôle de flux pour que la réponse reste ouverte et soit livrée en petits blocs, comme des paquets de 1 octet. Selon l'implémentation, ce comportement peut entraîner une consommation excessive de CPU, de mémoire ou de ressources de connexion, entraînant un risque de déni de service.

Dans ce dépôt, le script associé est :

data_dribble_probe.py

L'objectif du script est de valider le comportement de manière légère, sans générer de charge agressive et sans tenter de provoquer une indisponibilité.

Références :

• 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, connue sous le nom de HTTP/2 Priority Churn ou Resource Loop, affecte certaines implémentations de HTTP/2 qui traitent de manière coûteuse les modifications continues de l'arbre de priorité des flux.

Dans ce scénario, un attaquant peut créer plusieurs flux et modifier à plusieurs reprises la priorité entre eux, provoquant un churn dans l'arbre de priorités. Selon l'implémentation, ce comportement peut entraîner une consommation excessive de CPU et conduire à un déni de service.

Dans ce dépôt, le script associé est :

priority_churn_probe.py

L'objectif du script est de valider si le serveur accepte et traite les trames PRIORITY, en utilisant une faible intensité et sans exécuter d'attaque DoS.

Références :

• 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

Remarque concernant les versions affectées

Les CVE CVE-2019-9511 et CVE-2019-9513 ne sont pas associées à une version spécifique unique de serveur web, comme uniquement nginx, Apache ou Tomcat.

Elles affectent certaines implémentations HTTP/2 dans différents produits, bibliothèques, proxys, répartiteurs de charge et serveurs. Par conséquent, la validation doit tenir compte du composant qui négocie et traite HTTP/2 dans l'environnement analysé.

Exemples de composants pouvant être impliqués :

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

Le premier critère technique est de confirmer si le service négocie HTTP/2 via ALPN. Si le service ne négocie pas h2, ces scripts ne sont pas applicables.

La confirmation de la vulnérabilité par version doit être effectuée sur la base de l'avis officiel du fabricant du composant identifié.

Pré-validation : vérifier le support HTTP/2

Avant d'exécuter les scripts, validez si la cible négocie HTTP/2 via ALPN.

Utilisez uniquement le domaine dans la commande, sans https://.

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

Il est également possible d'utiliser un placeholder :

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

Sortie attendue :

ALPN protocol: h2

Si la sortie indique h2, le service négocie HTTP/2 et les scripts peuvent être applicables.

S'il n'y a pas de retour ou si le protocole négocié est un autre, comme http/1.1, les scripts ne sont pas applicables pour ce point de terminaison.

Vue d'ensemble des scripts

Flux d'utilisation recommandé

L'ordre le plus logique pour utiliser les scripts est :

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

Explication rapide du flux

Tout d'abord, utilisez la commande avec openssl pour confirmer si la cible négocie HTTP/2. Ensuite, utilisez priority_churn_probe.py pour valider si le serveur accepte et traite les trames de priorité. Puis, utilisez data_dribble_probe.py pour observer le comportement du serveur face à une fenêtre de flux réduite, en libérant de petits volumes de données de manière contrôlée.

Les deux scripts sont des sondes légères. Ils n'ont pas pour objectif de provoquer une indisponibilité, mais de générer une preuve technique du comportement observé.

Scripts

priority_churn_probe.py

Description

priority_churn_probe.py est une PoC légère pour la validation du comportement lié à la CVE-2019-9513, connue sous le nom de HTTP/2 Priority Churn.

Le script établit une connexion HTTP/2 via TLS, ouvre de petits flux HTTP et envoie des modifications de priorité au moyen de trames PRIORITY. Ensuite, il mesure la latence avant et après l'envoi de ces trames afin d'observer s'il y a une variation dans le traitement.

Ce que fait le script

• Négocie HTTP/2 via ALPN ;
• Établit une connexion TLS avec l'hôte indiqué ;
• Envoie de simples requêtes GET vers jusqu'à trois chemins ;
• Mesure la latence initiale à l'aide de PING ;
• Utilise un repli (fallback) avec GET si le PING n'est pas suffisant ;
• Envoie des trames PRIORITY à faible intensité ;
• Mesure la latence après le churn de priorité ;
• Affiche une comparaison entre le temps avant et après le test.

Cas d'utilisation

Utilisez ce script lorsqu'il est nécessaire de valider si un serveur HTTP/2 accepte et traite les trames de priorité liées au vecteur Priority Churn, sans exécuter de test DoS agressif.

Il est indiqué pour la validation contrôlée lors de pentests, l'analyse d'exposition HTTP/2 et la preuve technique d'un comportement vulnérable ou potentiellement sensible.

Champs/paramètres à modifier

Le script reçoit les valeurs via des arguments de ligne de commande :

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

Explication des paramètres

Chemin idéal pour le test

Utilisez des chemins légers, publics et à faible impact, comme :

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

Évitez les chemins qui exécutent des opérations lourdes, des requêtes complexes, la génération de rapports, l'upload, la recherche avancée ou toute fonctionnalité générant de la charge sur le backend.

Exemple d'utilisation sûre

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

Sortie attendue

Exemple de sortie :

[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).

Interprétation du résultat

Si le script parvient à négocier HTTP/2, à ouvrir des flux et à envoyer des trames PRIORITY, cela indique que le serveur traite ce type de comportement.

Une légère augmentation de la latence après le churn peut être utilisée comme preuve technique de l'existence du vecteur, mais ne doit pas être interprétée seule comme une preuve d'impact grave. La classification finale dépend du contexte, de la version du serveur, de l'architecture, des mesures d'atténuation, du WAF/CDN et de la configuration HTTP/2.

data_dribble_probe.py

Description

data_dribble_probe.py est une PoC légère pour la validation du comportement lié à la CVE-2019-9511, connue sous le nom de HTTP/2 Data Dribble.

Le script établit une connexion HTTP/2 via TLS, ouvre un seul flux et manipule la fenêtre de contrôle de flux pour libérer de petits volumes de données, simulant le comportement de livraison progressive des trames DATA.

Ce que fait le script

• Négocie HTTP/2 via ALPN ;
• Établit une connexion TLS avec l'hôte indiqué ;
• Envoie une requête GET vers le chemin défini ;
• Ajuste la fenêtre de flux initiale ;
• Libère de petits volumes de données de manière contrôlée ;
• Compte les trames DATA reçues ;
• Affiche la quantité d'octets libérés, les trames reçues et le temps total.

Cas d'utilisation

Utilisez ce script lorsqu'il est nécessaire de valider si le serveur HTTP/2 répond à un modèle de contrôle de flux réduit, associé au vecteur Data Dribble, sans exécuter de charge agressive.

Il est indiqué pour une preuve technique contrôlée, en particulier lorsque des outils automatisés signalent une exposition possible et qu'il est nécessaire de valider manuellement avec un risque opérationnel moindre.

Champs/paramètres à modifier

Le script reçoit les valeurs via des arguments de ligne de commande :

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

Explication des paramètres

Chemin idéal pour le test

Utilisez un chemin simple, statique ou à faible coût pour le serveur, comme :

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

Évitez les endpoints qui effectuent des requêtes en base de données, une authentification lourde, un traitement asynchrone, la génération de documents ou des appels vers des systèmes internes.

Exemple d'utilisation sûre

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

Sortie attendue

Exemple de sortie :

[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).

Interprétation du résultat

Si le script négocie HTTP/2 et reçoit de petites trames DATA au fur et à mesure que la fenêtre de flux est libérée, cela indique que le serveur traite ce modèle de contrôle de flux.

Ce comportement peut être utilisé comme preuve technique du vecteur, mais la criticité doit tenir compte du contexte réel de l'environnement, comme le serveur utilisé, la version, les limites de connexion, le répartiteur de charge, le CDN, le WAF, le timeout et les protections contre les abus.

Dépendances

Les scripts nécessitent Python 3 et la bibliothèque h2.

python3
pip
h2
ssl
socket
argparse

Les bibliothèques ssl, socket, time, argparse et select font partie de la bibliothèque standard de Python.

La principale dépendance externe est :

h2

Installation des dépendances

Installation directe :

python3 -m pip install h2

Installation à l'aide d'un environnement virtuel :

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

Validez l'installation :

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

Réglages nécessaires avant l'exécution

1. Confirmer le support HTTP/2

Les scripts dépendent de la négociation HTTP/2 via ALPN.

Avant d'exécuter, confirmez si le serveur prend en charge HTTP/2 :

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

Sortie attendue :

ALPN protocol: h2

Si le serveur ne négocie pas h2, les scripts ne seront pas applicables.

2. Utiliser uniquement le FQDN dans le paramètre --host

Ne fournissez pas https:// dans le paramètre --host.

Correct :

--host exemplo.com.br

Incorrect :

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

3. Choisir des chemins légers

Privilégiez les chemins simples :

/
/robots.txt
/favicon.ico
/health

Évitez les endpoints sensibles ou lourds :

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

L'idée est de valider le comportement HTTP/2, pas de stresser le backend.

4. Maintenir des valeurs faibles

Utilisez des valeurs prudentes :

Pour priority_churn_probe.py :

--shuffles 10

Pour data_dribble_probe.py :

--bytes 12

N'augmentez pas ces valeurs dans un environnement de production sans autorisation explicite.

Exemples d'utilisation

Pré-validation HTTP/2

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

Priority Churn — CVE-2019-9513

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

Data Dribble — CVE-2019-9511

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

Recommandations d'atténuation

Pour réduire les risques associés aux attaques DoS HTTP/2, il est recommandé de maintenir à jour les serveurs web, proxys, répartiteurs de charge et bibliothèques HTTP/2, d'appliquer des limites de connexion, de configurer des timeouts appropriés, de limiter le nombre de flux simultanés, de restreindre l'abus de trames HTTP/2, de surveiller les anomalies de latence et d'envisager la désactivation de HTTP/2 sur les services qui n'ont pas besoin de ce protocole.

Il est également recommandé de valider la protection sur des couches telles que CDN, WAF, reverse proxy, ingress controller et load balancer, car souvent l'exposition réelle dépend davantage de la périphérie que de l'application finale.

La confirmation de la correction doit être basée sur le composant qui termine et traite réellement HTTP/2 dans l'environnement, comme le serveur web, le proxy, le répartiteur de charge, le CDN ou l'ingress controller.

Remarque de sécurité

Ces scripts doivent être utilisés uniquement dans des environnements autorisés.

Bien qu'ils aient été écrits pour une exécution légère, ils interagissent directement avec des mécanismes HTTP/2 liés à des vecteurs de DoS. Par conséquent, l'utilisation doit être alignée sur le périmètre formel du test, les règles d'engagement et les limites opérationnelles définies avec le responsable de l'environnement.

Avant d'exécuter en production, confirmez :

• domaine autorisé ;
• fenêtre de test autorisée ;
• limite d'intensité ;
• chemins autorisés ;
• contacts de contingence ;
• preuves attendues ;
• critères d'interruption du test.

Avis légal

L'utilisation de ces scripts contre des systèmes sans autorisation est interdite.

La finalité de ce dépôt est exclusivement de soutenir des activités de sécurité légitimes, telles que le pentest autorisé, la validation contrôlée de vulnérabilités, le laboratoire, l'étude technique et la démonstration sûre du risque.