mod_proxy SSRF

Falha de Server-Side Request Forgery (SSRF) no mod_proxy do Apache HTTP Server: uma requisição HTTP com uri-path manipulado pode forçar o proxy a encaminhar a conexão para um servidor de origem escolhido pelo atacante, não pelo administrador. O CVSS de 9.0 é alto, mas o vetor traz AC:H (complexidade de ataque alta) porque a exploração depende de o servidor estar configurado como proxy reverso com mod_proxy ativo e diretivas de encaminhamento (ProxyPass/ProxyPassMatch) — a maioria das instalações padrão de Apache, sem proxy reverso configurado, não está exposta mesmo rodando uma versão vulnerável.

O problema está na lógica do mod_proxy que decide para qual worker (servidor de origem) uma requisição proxied deve ser roteada. O advisory oficial da Apache Software Foundation descreve o mecanismo de forma direta: um uri-path forjado consegue influenciar essa decisão de roteamento e faz o mod_proxy encaminhar a requisição para um destino escolhido pelo cliente remoto, em vez do destino fixado pela configuração do administrador. Isso é classificado como CWE-918 (Server-Side Request Forgery).

O fornecedor não detalhou publicamente, nas fontes analisadas, o trecho de código exato ou a rotina interna responsável (não há changelog técnico linha a linha nas fontes disponíveis). O que se sabe com certeza, a partir do advisory da Apache e das réplicas em Debian LTS e Fedora, é que a falha afeta o componente mod_proxy em si, dentro do núcleo do httpd, e não um módulo de terceiros — por isso qualquer build que compile mod_proxy é potencialmente afetada até a versão-limite anunciada.

O atacante controla o conteúdo do uri-path da requisição HTTP enviada ao proxy. O impacto documentado é o desvio do destino de encaminhamento (SSRF), o que na prática dá ao atacante uma via para alcançar hosts e serviços que só deveriam ser acessíveis pelo próprio servidor proxy — cenário clássico de bypass de segmentação de rede via um serviço web exposto publicamente.

A exploração ocorre via requisição HTTP única enviada ao endpoint que o Apache expõe como proxy reverso — não há necessidade de autenticação (PR:N) nem interação do usuário (UI:N). O pré-requisito real, que a nota do CVSS 9.0 esconde, é a configuração: o servidor precisa ter mod_proxy habilitado e operando como proxy reverso, com diretivas como ProxyPass/ProxyPassMatch ativas. Servidores Apache usados só como servidor web estático, sem proxy reverso configurado, não apresentam a superfície de ataque descrita.

Existe PoC pública e template Nuclei documentados, o que reduz a barreira de exploração para quem já identificou um Apache com proxy reverso exposto — a varredura automatizada em massa é viável. A CVE está no catálogo KEV da CISA, confirmando exploração ativa observada no mundo real, não apenas risco teórico.

O resultado final para o atacante é a capacidade de fazer o servidor Apache atuar como intermediário forçado (proxy involuntário) contra um destino de escolha do atacante — usado tipicamente para sondar rede interna, alcançar serviços que não deveriam estar acessíveis externamente (bancos de dados internos, painéis administrativos, endpoints de metadados de nuvem) ou driblar controles de firewall que confiam na origem do tráfego do proxy.

A correção definitiva do fornecedor é atualizar para Apache HTTP Server 2.4.49 ou versão posterior — a atualização foi distribuída em pacotes como httpd-2.4.49-1.fc34 (Fedora). Distribuições com ramos de suporte estendido publicaram backports próprios: Debian 9 (stretch), sob LTS, corrigiu em apache2 2.4.25-3+deb9u11. Produtos que empacotam Apache internamente também precisaram de patch dedicado — por exemplo, o Tenable.sc atualizou seu Apache embutido para a versão 2.4.51 para endereçar esta falha junto com outras.

Se a atualização não for viável de imediato, o controle compensatório real é reduzir a superfície: revisar e restringir as diretivas de proxy reverso (ProxyPass/ProxyPassMatch) para que não aceitem padrões de URI abertos ou pouco constrangidos, e limitar por rede quais destinos o processo do Apache pode alcançar (segmentação/egress filtering), já que a essência do risco é o servidor virar um pivô de rede. Desabilitar mod_proxy em instâncias que não usam proxy reverso remove a exposição por completo.

Não existe mitigação via WAF genérica confiável documentada nas fontes analisadas — como o vetor é o próprio uri-path de uma requisição legítima ao proxy, regras de bloqueio por assinatura tendem a gerar falsos negativos ou positivos sem conhecimento da configuração específica do ambiente. Tratar isso como suficiente sem corrigir a versão é o equívoco mais comum.

Procurar em logs de acesso do Apache requisições com uri-path incomum direcionadas a endpoints configurados como proxy reverso — padrões fora do esperado para as rotas normais da aplicação, incluindo tentativas de manipulação de path que buscam desviar o worker de destino. Do lado de rede, monitorar conexões de saída do processo httpd para destinos internos ou externos não previstos na configuração de proxy (IPs fora da allowlist de backends legítimos) é o sinal mais confiável de exploração bem-sucedida, já que não há uma assinatura única e estável de payload documentada nas fontes analisadas — a presença de PoC pública e template Nuclei sugere variações de payload que dificultam uma regra de detecção única e definitiva.