harley-ghostie/cve-2019-9511_priority-churn-data-dribbleSondas ligeras HTTP/2 para validación controlada de vectores DoS CVE-2019-9511 (Data Dribble) y CVE-2019-9513 (Priority Churn) en entornos autorizados.
Repositorio con scripts de validación controlada para comportamientos asociados a las CVEs CVE-2019-9511 y CVE-2019-9513, ambas relacionadas con vectores de denegación de servicio en implementaciones HTTP/2.
Los scripts fueron creados para apoyar validaciones técnicas en entornos autorizados, permitiendo observar si el servidor negocia HTTP/2 y responde a patrones específicos relacionados con Data Dribble y Priority Churn, sin ejecutar un ataque de denegación de servicio.
La propuesta es comprobar el vector de forma ligera y segura, con bajo volumen de peticiones y sin objetivo de indisponibilizar el entorno.
| CVE | Nombre | Script | Descripción |
|---|
CVE-2019-9511 | HTTP/2 Data Dribble | data_dribble_probe.py | Valida comportamiento de control de flujo HTTP/2 liberando pequeños volúmenes de datos de forma controlada. |
CVE-2019-9513 | HTTP/2 Priority Churn / Resource Loop | priority_churn_probe.py | Valida comportamiento de procesamiento de frames PRIORITY en baja intensidad. |
La CVE-2019-9511, conocida como HTTP/2 Data Dribble, afecta a algunas implementaciones de HTTP/2 que no tratan de forma eficiente la manipulación de la ventana de flujo y la entrega gradual de datos.
En este escenario, un atacante puede solicitar datos al servidor y manipular el control de flujo para hacer que la respuesta se mantenga abierta y se entregue en pequeños bloques, como paquetes de 1 byte. Dependiendo de la implementación, este comportamiento puede generar consumo excesivo de CPU, memoria o recursos de conexión, resultando en riesgo de denegación de servicio.
En este repositorio, el script relacionado es:
data_dribble_probe.py
El objetivo del script es validar el comportamiento de forma ligera, sin generar carga agresiva y sin intentar causar indisponibilidad.
Referencias:
La CVE-2019-9513, conocida como HTTP/2 Priority Churn o Resource Loop, afecta a algunas implementaciones de HTTP/2 que procesan cambios continuos en el árbol de prioridad de los streams de forma costosa.
En este escenario, un atacante puede crear múltiples streams y cambiar repetidamente la prioridad entre ellos, causando churn en el árbol de prioridades. Dependiendo de la implementación, este comportamiento puede generar consumo excesivo de CPU y llevar a la denegación de servicio.
En este repositorio, el script relacionado es:
priority_churn_probe.py
El objetivo del script es validar si el servidor acepta y procesa frames PRIORITY, usando baja intensidad y sin ejecutar un ataque de DoS.
Referencias:
Las CVEs CVE-2019-9511 y CVE-2019-9513 no están asociadas a una única versión específica de servidor web, como solo nginx, Apache o Tomcat.
Afectan a determinadas implementaciones HTTP/2 en diferentes productos, bibliotecas, proxies, balanceadores y servidores. Por eso, la validación debe considerar qué componente está negociando y procesando HTTP/2 en el entorno analizado.
Ejemplos de componentes que pueden estar involucrados:
nginx
Apache HTTP Server
Envoy
HAProxy
Tomcat
Jetty
Node.js
Go net/http2
nghttp2
CDN
WAF
Load Balancer
Ingress Controller Kubernetes
El primer criterio técnico es confirmar si el servicio negocia HTTP/2 via ALPN. Si el servicio no negocia h2, estos scripts no son aplicables.
La confirmación de vulnerabilidad por versión debe hacerse con base en el advisory oficial del fabricante del componente identificado.
Antes de ejecutar los scripts, valide si el objetivo negocia HTTP/2 via ALPN.
Use solo el dominio en el comando, sin https://.
openssl s_client -alpn h2 -connect ejemplo.com.br:443 </dev/null 2>/dev/null | grep -i "ALPN"
También es posible usar con placeholder:
openssl s_client -alpn h2 -connect <HOST>:443 </dev/null 2>/dev/null | grep -i "ALPN"
Salida esperada:
ALPN protocol: h2
Si la salida indica h2, el servicio negocia HTTP/2 y los scripts pueden ser aplicables.
Si no hay retorno o el protocolo negociado es otro, como http/1.1, los scripts no son aplicables para ese endpoint.
| Script | CVE relacionada | Objetivo | Cuándo usar |
|---|---|---|---|
data_dribble_probe.py | CVE-2019-9511 | Validar comportamiento asociado a Data Dribble usando control de ventana para liberar pequeños bloques de datos | Usar cuando el servidor soporta HTTP/2 y hay necesidad de verificar comportamiento de entrega de DATA frames con ventana reducida. |
priority_churn_probe.py | CVE-2019-9513 | Validar comportamiento asociado a Priority Churn usando frames PRIORITY en baja intensidad | Usar cuando el servidor soporta HTTP/2 y hay necesidad de verificar si procesa cambios de prioridad de streams. |
El orden más lógico para la utilización de los scripts es:
1. Pre-validación HTTP/2 con openssl
↓
2. priority_churn_probe.py
↓
3. data_dribble_probe.py
Primero, use el comando con openssl para confirmar si el objetivo negocia HTTP/2. Luego, use priority_churn_probe.py para validar si el servidor acepta y procesa frames de prioridad. A continuación, use data_dribble_probe.py para observar el comportamiento del servidor ante una ventana de flujo reducida, liberando pequeños volúmenes de datos de forma controlada.
Ambos scripts son probes ligeros. No tienen como objetivo causar indisponibilidad, sino generar una evidencia técnica del comportamiento observado.
El priority_churn_probe.py es una PoC ligera para validación de comportamiento relacionado a la CVE-2019-9513, conocida como HTTP/2 Priority Churn.
El script establece una conexión HTTP/2 via TLS, abre pequeños streams HTTP y envía cambios de prioridad mediante frames PRIORITY. Luego, mide la latencia antes y después del envío de esos frames para observar si hay variación en el procesamiento.
PING;PRIORITY en baja intensidad;Use este script cuando sea necesario validar si un servidor HTTP/2 acepta y procesa frames de prioridad relacionados con el vector Priority Churn, sin ejecutar una prueba agresiva de DoS.
Está indicado para validación controlada en pentests, análisis de exposición HTTP/2 y comprobación técnica de comportamiento vulnerable o potencialmente sensible.
El script recibe los valores por argumento de línea de comandos:
--host
--port
--paths
--shuffles
| Parámetro | Descripción |
|---|---|
--host | FQDN del objetivo autorizado. No incluir https://. |
--port | Puerto TLS donde el servicio HTTP/2 está disponible. Por defecto: 443. |
--paths | Lista de paths simples para abrir streams HTTP/2. |
--shuffles | Cantidad de ciclos de cambio de prioridad. Mantener bajo para prueba segura. |
Use paths ligeros, públicos y de bajo impacto, como:
/
/robots.txt
/favicon.ico
/health
/login
Evite paths que ejecuten operaciones pesadas, consultas complejas, generación de informes, subidas, búsqueda avanzada o cualquier funcionalidad que genere carga en el backend.
python3 priority_churn_probe.py --host ejemplo.com.br --port 443 --paths / /robots.txt /favicon.ico --shuffles 10
Ejemplo de salida:
[OK] PING antes: 45.20 ms; después del churn: 52.80 ms; shuffles=10
Señal 9513: frames PRIORITY aceptados y procesados; aumento sutil post-churn evidencia el vector (sin DoS).
Si el script consigue negociar HTTP/2, abrir streams y enviar frames PRIORITY, esto indica que el servidor procesa ese tipo de comportamiento.
Un aumento sutil de latencia después del churn puede usarse como evidencia técnica de que el vector existe, pero no debe interpretarse solo como prueba de impacto severo. La clasificación final depende del contexto, versión del servidor, arquitectura, mitigadores, WAF/CDN y configuración HTTP/2.
El data_dribble_probe.py es una PoC ligera para validación de comportamiento relacionado a la CVE-2019-9511, conocida como HTTP/2 Data Dribble.
El script establece una conexión HTTP/2 via TLS, abre un único stream y manipula la ventana de control de flujo para liberar pequeños volúmenes de datos, simulando el comportamiento de entrega gradual de DATA frames.
Use este script cuando sea necesario validar si el servidor HTTP/2 responde a un patrón de control de flujo reducido, asociado al vector Data Dribble, sin ejecutar carga agresiva.
Está indicado para comprobación técnica controlada, especialmente cuando herramientas automatizadas señalan posible exposición y es necesario validar manualmente con menor riesgo operacional.
El script recibe los valores por argumento de línea de comandos:
--host
--path
--port
--bytes
| Parámetro | Descripción |
|---|---|
--host | FQDN del objetivo autorizado. No incluir https://. |
--path | Path que será solicitado en la prueba. |
--port | Puerto TLS donde el servicio HTTP/2 está disponible. Por defecto: 443. |
--bytes | Total de bytes liberados durante la prueba. Mantener bajo para validación segura. |
Use un path simple, estático o de bajo coste para el servidor, como:
/
/robots.txt
/favicon.ico
/health
/login
Evite endpoints que hagan consultas a base de datos, autenticación pesada, procesamiento asíncrono, generación de documentos o llamadas a sistemas internos.
python3 data_dribble_probe.py --host ejemplo.com.br --path / --port 443 --bytes 12
Ejemplo de salida:
[OK] HTTP/2 negociado; DATA frames recibidos: 12; bytes liberados: 12; tiempo(ms): 1450
Señal 9511: múltiples DATA minúsculos entregados bajo ventana=1 (prueba del camino 'dribble' sin estrés).
Si el script negocia HTTP/2 y recibe DATA frames pequeños según se libera la ventana de flujo, esto indica que el servidor procesa ese patrón de control de flujo.
Este comportamiento puede usarse como evidencia técnica del vector, pero la criticidad debe considerar el contexto real del entorno, como servidor utilizado, versión, límites de conexión, balanceador, CDN, WAF, timeout y protecciones contra abuso.
Los scripts requieren Python 3 y la biblioteca h2.
python3
pip
h2
ssl
socket
argparse
Las bibliotecas ssl, socket, time, argparse y select forman parte de la biblioteca estándar de Python.
La dependencia externa principal es:
h2
Instalación directa:
python3 -m pip install h2
Instalación usando entorno virtual:
python3 -m venv venv
source venv/bin/activate
pip install h2
Valide la instalación:
python3 -c "import h2; print('h2 instalado con éxito')"
Los scripts dependen de negociación HTTP/2 via ALPN.
Antes de ejecutar, confirme si el servidor soporta HTTP/2:
openssl s_client -alpn h2 -connect ejemplo.com.br:443 </dev/null 2>/dev/null | grep -i "ALPN"
Salida esperada:
ALPN protocol: h2
Si el servidor no negocia h2, los scripts no serán aplicables.
--hostNo informe https:// en el parámetro --host.
Correcto:
--host ejemplo.com.br
Incorrecto:
--host https://ejemplo.com.br
Prefiera paths simples:
/
/robots.txt
/favicon.ico
/health
Evite endpoints sensibles o pesados:
/relatorios
/export
/search
/upload
/api/procesamiento
La idea es validar el comportamiento HTTP/2, no estresar el backend.
Use valores conservadores:
Para priority_churn_probe.py:
--shuffles 10
Para data_dribble_probe.py:
--bytes 12
No aumente esos valores en entorno productivo sin autorización explícita.
openssl s_client -alpn h2 -connect ejemplo.com.br:443 </dev/null 2>/dev/null | grep -i "ALPN"
python3 priority_churn_probe.py --host ejemplo.com.br --port 443 --paths / /robots.txt /favicon.ico --shuffles 10
python3 data_dribble_probe.py --host ejemplo.com.br --path / --port 443 --bytes 12
Para reducir riesgos asociados a ataques HTTP/2 DoS, se recomienda mantener servidores web, proxies, balanceadores y bibliotecas HTTP/2 actualizados, aplicar límites de conexión, configurar timeouts adecuados, limitar cantidad de streams simultáneos, restringir abuso de frames HTTP/2, monitorear anomalías de latencia y evaluar la desactivación de HTTP/2 en servicios que no necesiten ese protocolo.
También se recomienda validar la protección en capas como CDN, WAF, reverse proxy, ingress controller y load balancer, pues muchas veces la exposición real depende más del borde que de la aplicación final.
La confirmación de corrección debe hacerse con base en el componente que realmente termina y procesa HTTP/2 en el entorno, como servidor web, proxy, balanceador, CDN o ingress controller.
Estos scripts deben utilizarse únicamente en entornos autorizados.
Aunque han sido escritos para ejecución ligera, interactúan directamente con mecanismos HTTP/2 relacionados con vectores de DoS. Por lo tanto, el uso debe estar alineado con el alcance formal de la prueba, las reglas de engagement y los límites operativos definidos con el responsable del entorno.
Antes de ejecutar en producción, confirme:
El uso de estos scripts contra sistemas sin autorización está prohibido.
La finalidad de este repositorio es exclusivamente apoyar actividades legítimas de seguridad, como pentest autorizado, validación controlada de vulnerabilidades, laboratorio, estudio técnico y demostración segura de riesgo.