harley-ghostie/cve-2019-9511_priority-churn-data-dribbleSondas HTTP/2 leves para validação controlada dos vetores DoS CVE-2019-9511 (Data Dribble) e CVE-2019-9513 (Priority Churn) em ambientes autorizados.
Repositório com scripts de validação controlada para comportamentos associados às CVEs CVE-2019-9511 e CVE-2019-9513, ambas relacionadas a vetores de negação de serviço em implementações HTTP/2.
Os scripts foram criados para apoiar validações técnicas em ambientes autorizados, permitindo observar se o servidor negocia HTTP/2 e responde a padrões específicos relacionados a Data Dribble e Priority Churn, sem executar ataque de negação de serviço.
A proposta é comprovar o vetor de forma leve e segura, com baixo volume de requisições e sem objetivo de indisponibilizar o ambiente.
| CVE | Nome | Script | Descrição |
|---|
CVE-2019-9511 | HTTP/2 Data Dribble | data_dribble_probe.py | Valida comportamento de controle de fluxo HTTP/2 liberando pequenos volumes de dados de forma controlada. |
CVE-2019-9513 | HTTP/2 Priority Churn / Resource Loop | priority_churn_probe.py | Valida comportamento de processamento de frames PRIORITY em baixa intensidade. |
A CVE-2019-9511, conhecida como HTTP/2 Data Dribble, afeta algumas implementações de HTTP/2 que não tratam de forma eficiente a manipulação da janela de fluxo e da entrega gradual de dados.
Nesse cenário, um atacante pode solicitar dados ao servidor e manipular o controle de fluxo para fazer com que a resposta seja mantida aberta e entregue em pequenos blocos, como pacotes de 1 byte. Dependendo da implementação, esse comportamento pode gerar consumo excessivo de CPU, memória ou recursos de conexão, resultando em risco de negação de serviço.
Neste repositório, o script relacionado é:
data_dribble_probe.py
O objetivo do script é validar o comportamento de forma leve, sem gerar carga agressiva e sem tentar causar indisponibilidade.
Referências:
A CVE-2019-9513, conhecida como HTTP/2 Priority Churn ou Resource Loop, afeta algumas implementações de HTTP/2 que processam alterações contínuas na árvore de prioridade dos streams de forma custosa.
Nesse cenário, um atacante pode criar múltiplos streams e alterar repetidamente a prioridade entre eles, causando churn na árvore de prioridades. Dependendo da implementação, esse comportamento pode gerar consumo excessivo de CPU e levar à negação de serviço.
Neste repositório, o script relacionado é:
priority_churn_probe.py
O objetivo do script é validar se o servidor aceita e processa frames PRIORITY, usando baixa intensidade e sem executar um ataque de DoS.
Referências:
As CVEs CVE-2019-9511 e CVE-2019-9513 não estão associadas a uma única versão específica de servidor web, como apenas nginx, Apache ou Tomcat.
Elas afetam determinadas implementações HTTP/2 em diferentes produtos, bibliotecas, proxies, balanceadores e servidores. Por isso, a validação deve considerar qual componente está negociando e processando HTTP/2 no ambiente analisado.
Exemplos de componentes que podem estar envolvidos:
nginx
Apache HTTP Server
Envoy
HAProxy
Tomcat
Jetty
Node.js
Go net/http2
nghttp2
CDN
WAF
Load Balancer
Ingress Controller Kubernetes
O primeiro critério técnico é confirmar se o serviço negocia HTTP/2 via ALPN. Caso o serviço não negocie h2, estes scripts não são aplicáveis.
A confirmação de vulnerabilidade por versão deve ser feita com base no advisory oficial do fabricante do componente identificado.
Antes de executar os scripts, valide se o alvo negocia HTTP/2 via ALPN.
Use somente o domínio no comando, sem https://.
openssl s_client -alpn h2 -connect exemplo.com.br:443 </dev/null 2>/dev/null | grep -i "ALPN"
Também é possível usar com placeholder:
openssl s_client -alpn h2 -connect <HOST>:443 </dev/null 2>/dev/null | grep -i "ALPN"
Saída esperada:
ALPN protocol: h2
Se a saída indicar h2, o serviço negocia HTTP/2 e os scripts podem ser aplicáveis.
Se não houver retorno ou o protocolo negociado for outro, como http/1.1, os scripts não são aplicáveis para aquele endpoint.
| Script | CVE relacionada | Objetivo | Quando usar |
|---|---|---|---|
data_dribble_probe.py | CVE-2019-9511 | Validar comportamento associado ao Data Dribble usando controle de janela para liberar pequenos blocos de dados | Usar quando o servidor suporta HTTP/2 e há necessidade de verificar comportamento de entrega de DATA frames com janela reduzida. |
priority_churn_probe.py | CVE-2019-9513 | Validar comportamento associado ao Priority Churn usando frames PRIORITY em baixa intensidade | Usar quando o servidor suporta HTTP/2 e há necessidade de verificar se ele processa alterações de prioridade de streams. |
A ordem mais lógica para utilização dos scripts é:
1. Pré-validação HTTP/2 com openssl
↓
2. priority_churn_probe.py
↓
3. data_dribble_probe.py
Primeiro, use o comando com openssl para confirmar se o alvo negocia HTTP/2. Depois, use o priority_churn_probe.py para validar se o servidor aceita e processa frames de prioridade. Em seguida, use o data_dribble_probe.py para observar o comportamento do servidor diante de uma janela de fluxo reduzida, liberando pequenos volumes de dados de forma controlada.
Ambos os scripts são probes leves. Eles não têm como objetivo causar indisponibilidade, mas sim gerar uma evidência técnica do comportamento observado.
O priority_churn_probe.py é uma PoC leve para validação de comportamento relacionado à CVE-2019-9513, conhecida como HTTP/2 Priority Churn.
O script estabelece uma conexão HTTP/2 via TLS, abre pequenos streams HTTP e envia alterações de prioridade por meio de frames PRIORITY. Em seguida, mede a latência antes e depois do envio desses frames para observar se há variação no processamento.
PING;PRIORITY em baixa intensidade;Use este script quando for necessário validar se um servidor HTTP/2 aceita e processa frames de prioridade relacionados ao vetor Priority Churn, sem executar um teste agressivo de DoS.
Ele é indicado para validação controlada em pentests, análise de exposição HTTP/2 e comprovação técnica de comportamento vulnerável ou potencialmente sensível.
O script recebe os valores por argumento de linha de comando:
--host
--port
--paths
--shuffles
| Parâmetro | Descrição |
|---|---|
--host | FQDN do alvo autorizado. Não incluir https://. |
--port | Porta TLS onde o serviço HTTP/2 está disponível. Padrão: 443. |
--paths | Lista de paths simples para abrir streams HTTP/2. |
--shuffles | Quantidade de ciclos de alteração de prioridade. Manter baixo para teste seguro. |
Use paths leves, públicos e de baixo impacto, como:
/
/robots.txt
/favicon.ico
/health
/login
Evite paths que executem operações pesadas, consultas complexas, geração de relatório, upload, busca avançada ou qualquer funcionalidade que gere carga no backend.
python3 priority_churn_probe.py --host exemplo.com.br --port 443 --paths / /robots.txt /favicon.ico --shuffles 10
Exemplo de saída:
[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).
Se o script conseguir negociar HTTP/2, abrir streams e enviar frames PRIORITY, isso indica que o servidor processa esse tipo de comportamento.
Um aumento sutil de latência após o churn pode ser usado como evidência técnica de que o vetor existe, mas não deve ser interpretado sozinho como prova de impacto severo. A classificação final depende do contexto, versão do servidor, arquitetura, mitigadores, WAF/CDN e configuração HTTP/2.
O data_dribble_probe.py é uma PoC leve para validação de comportamento relacionado à CVE-2019-9511, conhecida como HTTP/2 Data Dribble.
O script estabelece uma conexão HTTP/2 via TLS, abre um único stream e manipula a janela de controle de fluxo para liberar pequenos volumes de dados, simulando o comportamento de entrega gradual de DATA frames.
Use este script quando for necessário validar se o servidor HTTP/2 responde a um padrão de controle de fluxo reduzido, associado ao vetor Data Dribble, sem executar carga agressiva.
Ele é indicado para comprovação técnica controlada, especialmente quando ferramentas automatizadas apontam possível exposição e é necessário validar manualmente com menor risco operacional.
O script recebe os valores por argumento de linha de comando:
--host
--path
--port
--bytes
| Parâmetro | Descrição |
|---|---|
--host | FQDN do alvo autorizado. Não incluir https://. |
--path | Path que será requisitado no teste. |
--port | Porta TLS onde o serviço HTTP/2 está disponível. Padrão: 443. |
--bytes | Total de bytes liberados durante o teste. Manter baixo para validação segura. |
Use um path simples, estático ou de baixo custo para o servidor, como:
/
/robots.txt
/favicon.ico
/health
/login
Evite endpoints que façam consulta em banco, autenticação pesada, processamento assíncrono, geração de documentos ou chamadas para sistemas internos.
python3 data_dribble_probe.py --host exemplo.com.br --path / --port 443 --bytes 12
Exemplo de saída:
[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).
Se o script negociar HTTP/2 e receber DATA frames pequenos conforme a janela de fluxo é liberada, isso indica que o servidor processa esse padrão de controle de fluxo.
Esse comportamento pode ser usado como evidência técnica do vetor, mas a criticidade deve considerar o contexto real do ambiente, como servidor utilizado, versão, limites de conexão, balanceador, CDN, WAF, timeout e proteções contra abuso.
Os scripts requerem Python 3 e a biblioteca h2.
python3
pip
h2
ssl
socket
argparse
As bibliotecas ssl, socket, time, argparse e select fazem parte da biblioteca padrão do Python.
A dependência externa principal é:
h2
Instalação direta:
python3 -m pip install h2
Instalação usando ambiente virtual:
python3 -m venv venv
source venv/bin/activate
pip install h2
Valide a instalação:
python3 -c "import h2; print('h2 instalado com sucesso')"
Os scripts dependem de negociação HTTP/2 via ALPN.
Antes de executar, confirme se o servidor suporta HTTP/2:
openssl s_client -alpn h2 -connect exemplo.com.br:443 </dev/null 2>/dev/null | grep -i "ALPN"
Saída esperada:
ALPN protocol: h2
Se o servidor não negociar h2, os scripts não serão aplicáveis.
--hostNão informe https:// no parâmetro --host.
Correto:
--host exemplo.com.br
Incorreto:
--host https://exemplo.com.br
Prefira paths simples:
/
/robots.txt
/favicon.ico
/health
Evite endpoints sensíveis ou pesados:
/relatorios
/export
/search
/upload
/api/processamento
A ideia é validar o comportamento HTTP/2, não estressar o backend.
Use valores conservadores:
Para priority_churn_probe.py:
--shuffles 10
Para data_dribble_probe.py:
--bytes 12
Não aumente esses valores em ambiente produtivo sem autorização explícita.
openssl s_client -alpn h2 -connect exemplo.com.br:443 </dev/null 2>/dev/null | grep -i "ALPN"
python3 priority_churn_probe.py --host exemplo.com.br --port 443 --paths / /robots.txt /favicon.ico --shuffles 10
python3 data_dribble_probe.py --host exemplo.com.br --path / --port 443 --bytes 12
Para reduzir riscos associados a ataques HTTP/2 DoS, recomenda-se manter servidores web, proxies, balanceadores e bibliotecas HTTP/2 atualizados, aplicar limites de conexão, configurar timeouts adequados, limitar quantidade de streams simultâneos, restringir abuso de frames HTTP/2, monitorar anomalias de latência e avaliar a desativação de HTTP/2 em serviços que não precisam desse protocolo.
Também é recomendado validar a proteção em camadas como CDN, WAF, reverse proxy, ingress controller e load balancer, pois muitas vezes a exposição real depende mais da borda do que da aplicação final.
A confirmação de correção deve ser feita com base no componente que realmente termina e processa HTTP/2 no ambiente, como servidor web, proxy, balanceador, CDN ou ingress controller.
Estes scripts devem ser utilizados apenas em ambientes autorizados.
Embora tenham sido escritos para execução leve, eles interagem diretamente com mecanismos HTTP/2 relacionados a vetores de DoS. Portanto, o uso deve estar alinhado ao escopo formal do teste, às regras de engajamento e aos limites operacionais definidos com o responsável pelo ambiente.
Antes de executar em produção, confirme:
O uso destes scripts contra sistemas sem autorização é proibido.
A finalidade deste repositório é exclusivamente apoiar atividades legítimas de segurança, como pentest autorizado, validação controlada de vulnerabilidades, laboratório, estudo técnico e demonstração segura de risco.