
Sondes HTTP/2 légères pour la validation contrôlée des vecteurs DoS CVE-2019-9511 (Data Dribble) et CVE-2019-9513 (Priority Churn) dans des environnements autorisés.
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 | Nom | Script | Description |
|---|---|---|---|
CVE-2019-9511 | HTTP/2 Data Dribble | data_dribble_probe.py | Valide le comportement de contrôle de flux HTTP/2 en libérant de petits volumes de données de manière contrôlée. |
CVE-2019-9513 | HTTP/2 Priority Churn / Resource Loop | priority_churn_probe.py | Valide le comportement de traitement des trames PRIORITY à faible intensité. |
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 :
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 :
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é.
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.
| Script | CVE associée | Objectif | Quand l'utiliser |
|---|---|---|---|
data_dribble_probe.py | CVE-2019-9511 | Valider le comportement associé au Data Dribble en utilisant le contrôle de fenêtre pour libérer de petits blocs de données | À utiliser lorsque le serveur prend en charge HTTP/2 et qu'il est nécessaire de vérifier le comportement de livraison des trames DATA avec une fenêtre réduite. |
priority_churn_probe.py | CVE-2019-9513 | Valider le comportement associé au Priority Churn en utilisant des trames PRIORITY à faible intensité | À utiliser lorsque le serveur prend en charge HTTP/2 et qu'il est nécessaire de vérifier s'il traite les changements de priorité des flux. |
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
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é.
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.
PING ;PRIORITY à faible intensité ;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.
Le script reçoit les valeurs via des arguments de ligne de commande :
--host
--port
--paths
--shuffles