t1499-003-application-exhaustion-flood

# T1499.003 - Application Exhaustion Flood ## Descrição **Application Exhaustion Flood** (Inundação por Exaustão de Aplicação) é uma sub-técnica de [[t1499-endpoint-denial-of-service|T1499 - Endpoint Denial of Service]] em que adversários exploram funcionalidades específicas e **computacionalmente intensivas** de aplicações web ou de serviço para causar negação de serviço (DoS), sem necessáriamente gerar volumes massivos de tráfego de rede. Diferentemente do [[t1498-network-denial-of-service|T1498 - Network Denial of Service]], que satura a banda de rede, o Application Exhaustion Flood **opera na camada de aplicação (Layer 7)**, fazendo requisições aparentemente legítimas a endpoints que consomem recursos desproporcionais no servidor. O objetivo é esgotar CPU, memória RAM, conexões de banco de dados ou threads de processamento disponíveis no servidor, tornando a aplicação inacessível a usuários legítimos. Esta técnica é particularmente insidiosa porque: - **Baixo volume de tráfego:** Pode causar indisponibilidade com relativamente poucas requisições por segundo, dificultando a detecção por sistemas baseados em volume - **Tráfego aparentemente legítimo:** As requisições usam métodos HTTP válidos (GET, POST), passam por verificações de protocolo e podem contornar WAFs mal configurados - **Difícil distinguir de picos legítimos:** Uma campanha de marketing pode gerar padrão similar de carga - **Amplificação pelo design da aplicação:** Funcionalidades como pesquisa full-text, relatórios complexos e operações de machine learning são alvos ideais ### Funcionalidades-alvo Típicas | Funcionalidade | Por que é cara | Exemplo de abuso | |---------------|----------------|-----------------| | Pesquisa full-text | Varrida de índices grandes | Consultas com wildcards ou termos ambíguos | | Geração de relatórios | Queries SQL complexas, joins pesados | Relatório de período extenso solicitado em loop | | Processamento de imagens | CPU/memória intensiva | Upload de imagens gigantes seguido de redimensionamento | | Renderização de PDF | CPU e memória | Geração de documentos longos em paralelo | | APIs de machine learning | GPU/CPU + memória | Requisições de inferência em loop | | Autenticação/login | Hashing bcrypt, PBKDF2 | Brute-force com senhas longas (hash stretching) | | Operações criptográficas | CPU intensiva | Handshakes TLS com renegociação forçada | | GraphQL introspection | Parsing + resolução de graph | Queries aninhadas profundamente (GraphQL DoS) | | Webhooks / callbacks | I/O e processamento assíncrono | Callbacks em loop para endpoints lentos | --- ## Como Funciona ### Fase 1 - Identificação de Endpoints Vulneráveis O adversário primeiro realiza reconhecimento ([[t1595-active-scanning|T1595 - Active Scanning]]) para identificar endpoints da aplicação que respondem lentamente ou consomem recursos desproporcionais: - Varredura automatizada de respostas HTTP com tempo de resposta > 500ms - Análise do código-fonte JavaScript do frontend para mapear endpoints de API não documentados - Revisão de documentação pública (Swagger/OpenAPI, GraphQL schema introspection) - Testes manuais com ferramentas como Burp Suite, curl ou ferramentas customizadas ### Fase 2 - Craft das Requisições de Exaustão O adversário elabora requisições que maximizam o consumo de recursos: **Exemplo - GraphQL Nested Query DoS:** ```graphql query { users { posts { comments { author { posts { comments { author { name } } } } } } } } ``` Uma query como essa pode resultar em centenas de queries SQL no backend, causando latência extrema ou timeout de banco de dados. **Exemplo - Search Endpoint com Wildcards:** ``` GET /api/search?q=*&category=*&daté_from=2000-01-01&daté_to=2026-12-31&limit=10000 ``` Uma busca com parâmetros amplos pode resultar em full-table scan em banco de dados com milhões de registros. **Exemplo - Hash Exhaustion (Login Endpoint):** Envio de tentativas de login com senhas de 1.000+ caracteres. Algoritmos como bcrypt processam senhas longas lentamente por design, permitindo que poucos RPS causem 100% de CPU. ### Fase 3 - Execução do Flood O adversário envia as requisições elaboradas em volume suficiente para esgotar os recursos do servidor. As ferramentas variam: - **Ferramentas de stress testing abusadas:** Apache JMeter, Locust, k6, Artillery - **Ferramentas específicas de DoS Layer 7:** SlowHTTPTest, HULK, R.U.D.Y. (R-U-Dead-Yet) - **Scripts customizados:** Python com asyncio/aiohttp para máxima concorrência - **Botnets:** Distribuição do ataque para contornar raté limiting por IP ### Fase 4 - Esgotamento de Recursos Dependendo da funcionalidade atacada, o esgotamento pode ocorrer em: - **CPU:** 100% de utilização por processamento de queries complexas ou operações criptográficas - **Memória RAM:** Alocação de grandes buffers para processar dados retornados (ex.: 10.000 registros por query) - **Conexões de banco de dados:** Connection pool esgotado por queries longas que mantêm conexões abertas - **File descriptors:** Conexões HTTP keep-alive mantidas abertas artificialmente (Slowloris) - **Threads:** Pool de threads do servidor web (Tomcat, Gúnicorn) saturado por requisições lentas --- ## Attack Flow ```mermaid graph TB A["Reconhecimento Identificação de endpoints lentos e funcionalidades intensivas"] --> B["Análise Mapeamento de API, Swagger, GraphQL schema introspection"] B --> C["Elaboração Craft de requisições que maximizam consumo de CPU/RAM/DB"] C --> D["Distribuição Ferramentas de stress test, scripts async, botnets"] D --> E1["Exaustão de CPU Queries complexas, hashing, ML inference"] D --> E2["Exaustão de Memória Large dataset responses, buffer overflow lógico"] D --> E3["Exaustão de Conexões DB connection pool, HTTP keep-alive flood"] E1 --> F["Indisponibilidade Aplicação para de responder 503 Service Unavailable"] E2 --> F E3 --> F F --> G["Impacto de Negócio Perda de receita, SLA violado, dano reputacional"] ``` --- ## Exemplos de Uso ### Caso 1 - GraphQL Batching DoS (2019-presente) APIs GraphQL sem raté limiting de query depth ou complexity são vulneráveis a ataques de **query batching** e **nested queries**. Em 2019, pesquisadores demonstraram que APIs GraphQL populares podiam ser derrubadas com menos de 100 requisições por segundo usando queries com profundidade de 10-15 níveis. O problema afetou plataformas de e-commerce, redes sociais e fintechs globais. No Brasil, plataformas de marketplace adotaram GraphQL em 2020-2022 sem controles adequados de complexity limiting, tornando-se alvos potenciais. ### Caso 2 - SSL/TLS Renegotiation DoS (CVE-2009-3555 e variantes) A vulnerabilidade de renegociação TLS permite que um cliente forçe múltiplas renegociações de sessão SSL/TLS, cada uma consumindo recursos de CPU do servidor (operações de handshake RSA são computacionalmente custosas). Mesmo com o CVE original patchado, técnicas similares (como o ataque **THC-SSL-DOS**) continuaram efetivas em implementações que não limitavam a taxa de renegociação. Servidores HTTPS de bancos e e-commerces brasileiros foram alvos documentados em 2012-2015. ### Caso 3 - ReDoS - Regular Expression Denial of Service **ReDoS** ocorre quando uma expressão regular mal construída na aplicação é exposta a input do usuário. Certas entradas podem causar **catastrophic backtracking** no engine de regex, consumindo CPU exponencialmente. Por exemplo, a expressão `(a+)+` aplicada a uma string como `aaaaaaaaaaaaaaab` pode travar a thread por segundos. Vulnerabilidades ReDoS foram documentadas em bibliotecas populares usadas por aplicações Node.js e Python no ecossistema de startups brasileiras. ### Caso 4 - Search Endpoint Abuse em E-commerce LATAM (2024) Plataformas de e-commerce na América Latina com motores de busca full-text (Elasticsearch, OpenSearch) foram alvejadas por requisições com parâmetros extremamente amplos (datas retroativas a 2010, wildcards em múltiplos campos). Cada requisição resultava em queries de alta latência ao cluster Elasticsearch, esgotando o connection pool do backend. O ataque foi detectado pelo padrão de User-Agent incomum (sem cookies de sessão válidos) e pela distribuição geográfica anômala dos IPs de origem. ### Caso 5 - Hash Exhaustion em Portais Governamentais Brasileiros (2023) Durante período eleitoral, portais de consulta de resultados e serviços governamentais de autenticação foram alvejados com tentativas de login com credenciais contendo senhas de comprimento extremo (512-1024 caracteres). Como os sistemas utilizavam bcrypt com fator de custo elevado, cada tentativa de verificação de senha consumia 200-500ms de CPU, permitindo que poucos terminais causassem degradação perceptível. O [[cert-br|CERT.br]] emitiu alerta sobre o vetor em outubro de 2023. --- ## Detecção ### Indicadores de Comportamento Anômalo - Aumento súbito de latência de resposta em endpoints específicos sem aumento proporcional de CPU total (sinal de connection pool exhaustion) - Queries de banco de dados com tempo de execução > 10x da baseline em endpoints de busca - Taxa de erro 503/504 escalando em endpoint específico enquanto outros endpoints continuam funcionando - Requisições com parâmetros incomuns: datas retroativas, campos em branco com wildcards, profundidade excessiva em queries JSON - Alto volume de conexões TCP no estado ESTABLISHED de origens geograficamente concentradas - Threads do servidor web em estado "waiting for DB connection" (esgotamento de connection pool) ### Regra Sigma - Detecção de Application Layer DoS via Latência ```yaml title: Application Exhaustion Flood - Abnormal Endpoint Latency Spike status: experimental logsource: category: webserver product: nginx detection: selection: request_time|gt: 5 status: - 200 - 500 - 503 filter_known_slow: uri_path|contains: - '/reports/download' - '/export' timeframe: 5m condition: selection and not filter_known_slow | count() by uri_path > 100 level: high tags: - attack.impact - attack.t1499.003 falsepositives: - Degradação de performance por causa de manutenção de banco de dados - Picos de uso legítimo durante campanhas de marketing ``` ### Regra Sigma - Detecção de GraphQL Deep Query ```yaml title: Possible GraphQL DoS - Excessive Query Depth status: experimental logsource: category: webserver product: generic detection: selection: request_uri|contains: '/graphql' request_method: 'POST' request_body|re: '(\{[^{}]*){10,}' timeframe: 1m condition: selection | count() by src_ip > 50 level: medium tags: - attack.impact - attack.t1499.003 falsepositives: - Ferramentas de desenvolvimento e testes de integração - Queries legítimas complexas de dashboards internos ``` ### Regra Sigma - Detecção de Hash Exhaustion (Login Flood com Senhas Longas) ```yaml title: Possible Hash Exhaustion - Login Attempts with Extremely Long Passwords status: experimental logsource: category: webserver product: generic detection: selection: request_method: 'POST' request_uri|contains: - '/login' - '/auth' - '/signin' request_body_length|gt: 500 timeframe: 1m condition: selection | count() by src_ip > 10 level: high tags: - attack.impact - attack.t1499.003 falsepositives: - Sistemas de autenticação com tokens longos em campos de senha (raro) ``` ### Fontes de Dados para Monitoramento | Fonte | O que monitorar | |-------|----------------| | Web server logs (Nginx/Apache) | `request_time`, status 503/504, URIs com alta latência | | APM (Datadog, New Relic, Elastic APM) | Traces de operações lentas, DB query time, thread pool status | | Database logs (slow query log) | Queries acima do threshold de tempo, full table scans | | Load balancer metrics | Request raté por backend, active connections, error raté | | WAF logs | Requisições bloqueadas por regras de raté limit ou anomalia | | GraphQL APM | Query complexity score, depth, execution time | --- ## Mitigação | ID | Mitigação | Descrição | |----|-----------|-----------| | M1037 | [[m1037-filter-network-traffic\|M1037 - Filter Network Traffic]] | Implementar WAF com regras para detectar padrões anômalos de requisição (wildcards excessivos, parâmetros de data muito amplos, payloads grandes em endpoints de login) | | M1030 | Raté Limiting por Endpoint | Configurar raté limiting granular por URI e por IP, não apenas global. Endpoints de busca, login e relatórios devem ter limites mais restritivos que endpoints estáticos | | Query Complexity Limiting | GraphQL / API Controls | Implementar limite de profundidade (max depth), complexidade (query complexity score) e custo de execução em APIs GraphQL e REST com query language | | Connection Pooling | Gerenciamento de Recursos | Configurar connection pools de banco de dados com timeout adequado e máximo de conexões por instância; implementar circuit breakers (padrão Hystrix) | | M1035 | Limitação de Acesso a Recursos | Definir limites de CPU e memória por requisição usando cgroups (Linux) ou resource quotas em containers; matar requisições que excedam o timeout | | CAPTCHA / Challenge | Verificação Humana | Implementar desafios CAPTCHA em endpoints de login e busca; usar Cloudflare Turnstile ou hCaptcha para distinguir bots de usuários legítimos | | Caching | Redução de Carga | Cachear resultados de operações custosas (busca, relatórios) com Redis ou Memcached; TTL adequado reduz drasticamente o impacto de floods repetidos | | Input Validation | Sanitização de Parâmetros | Validar e limitar os valores de parâmetros de entrada: tamanho máximo de strings de busca, range máximo de datas, profundidade máxima de objetos JSON | ### Recomendações Específicas por Tecnologia **Para APIs GraphQL:** - Implementar `graphql-depth-limit` (profundidade máxima 5-7 níveis) - Usar `graphql-query-complexity` com budget por query - Desabilitar introspection em produção (expõe schema para reconhecimento) - Implementar query whitelisting em APIs de produção **Para aplicações com autenticação:** - Limitar o comprimento máximo de senha aceito (512 chars é mais que suficiente para bcrypt) - Implementar account lockout progressivo (exponential backoff) - Usar CAPTCHA após N tentativas falhas por IP **Para endpoints de pesquisa:** - Limitar tamanho máximo de query string e número de termos - Requerer pelo menos N caracteres (ex.: mínimo 3) antes de executar busca - Implementar query timeout no banco de dados (statement_timeout no PostgreSQL) --- ## Contexto Brasil/LATAM O Application Exhaustion Flood é uma ameaça particularmente relevante para o ecossistema digital brasileiro, que combina alta adoção de serviços web com desafios históricos de maturidade em segurança de aplicações: **Setor financeiro brasileiro:** O Brasil possui um dos sistemas de pagamento em tempo real mais avançados do mundo (Pix), com volumes de transação que tornam os backends extremamente sensíveis a aumentos de latência. Ataques de Application Exhaustion a APIs do ecossistema Pix (PSPs, fintechs, bancos digitais) podem causar falhas em cascata com impacto direto em processamento de pagamentos. O [[bacen|Banco Central do Brasil]] exige, na Resolução BCB 85/2021, testes de resiliência que cubram cenários de DDoS de camada de aplicação. **E-commerce e Black Friday:** Durante períodos de alta demanda como Black Friday e Cyber Monday, plataformas de e-commerce brasileiras são alvos de ataques que se aproveitam da dificuldade de distinguir pico legítimo de flood malicioso. O prejuízo para empresas de médio porte pode ser significativo, com perda direta de receita durante as horas de pico comercial. **GraphQL e APIs modernas:** A adoção acelerada de GraphQL por startups e scale-ups brasileiras (fintechs, healthtechs, edtechs) criou uma superfície de ataque expressiva. Pesquisas da comunidade de segurança brasileira (H2HC, Roadsec) documentam regularmente instâncias de APIs GraphQL brasileiras sem controles de complexity limiting. **LGPD e responsabilidade por disponibilidade:** Sob a [[lgpd|LGPD]], a indisponibilidade de serviços que processam dados pessoais pode gerar obrigações de notificação à ANPD se resultar em comprometimento do acesso a dados ou violação de direitos dos titulares. Ataques de Application Exhaustion que causem indisponibilidade prolongada de serviços de saúde, financeiros ou governamentais podem ter implicações regulatórias diretas. **Setor de saúde digital:** Com a expansão de telemedicina e prontuário eletrônico no Brasil, sistemas de saúde tornaram-se alvos de Application Exhaustion com motivação de extorsão. Indisponibilidade de sistemas de prontuário pode ter impacto direto na segurança de pacientes, elevando a criticidade do vetor. **Infraestrutura de governo digital:** Portais como o Gov.br, e-CAC e sistemas de previdência social (INSS) processam milhões de requisições por dia. Ataques de Application Exhaustion a funcionalidades específicas (consulta de benefícios, declaração de IR) durante períodos de pico (meses de declaração do imposto de renda) têm causado degradação documentada de serviços públicos brasileiros. --- ## Técnica Pai e Técnicas Relacionadas - **Técnica pai:** [[t1499-endpoint-denial-of-service|T1499 - Endpoint Denial of Service]] - [[t1499-001-os-exhaustion-flood|T1499.001 - OS Exhaustion Flood]] - Esgotamento de recursos do sistema operacional - [[t1499-002-service-exhaustion-flood|T1499.002 - Service Exhaustion Flood]] - Esgotamento de serviços de rede (SYN flood, SSL exhaustion) - [[t1498-network-denial-of-service|T1498 - Network Denial of Service]] - DoS volumétrico de rede (Layer 3/4) - [[t1595-active-scanning|T1595 - Active Scanning]] - Reconhecimento para identificar endpoints vulneráveis --- ## Referências - [MITRE ATT&CK - T1499.003](https://attack.mitre.org/techniques/T1499/003) - [OWASP - Denial of Service Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html) - [GraphQL.org - Security - Limiting Query Complexity](https://graphql.org/learn/best-practices/#security) - [CERT.br - Alertas de Segurança 2023-2024](https://www.cert.br/docs/alertas/) - [Cloudflare - Application Layer DDoS Attack Insights 2024](https://blog.cloudflare.com/) - [BACEN - Resolução BCB 85/2021 - Política de Segurança Cibernética](https://www.bcb.gov.br/) - [[t1499-endpoint-denial-of-service|T1499 - Endpoint Denial of Service]] (técnica pai) - [[t1498-network-denial-of-service|T1498 - Network Denial of Service]] (técnica relacionada) - [[m1037-filter-network-traffic|M1037 - Filter Network Traffic]] - [[t1595-active-scanning|T1595 - Active Scanning]] - [[lgpd|LGPD - Lei Geral de Proteção de Dados]] - [[cert-br|CERT.br]] - [[bacen|Banco Central do Brasil]]