CVE-2010-0738

A JMX-Console do JBoss (JBoss AS e JBoss Enterprise Application Platform 4.2/4.3) restringe autenticação apenas para os métodos HTTP GET e POST no web.xml, deixando qualquer outro verbo HTTP passar sem checagem de credenciais. Isso não é RCE por si só, mas destranca o acesso à console de gerência JMX, que por padrão em muitas instalações da época expunha MBeans capazes de fazer deploy remoto de aplicações — daí a exploração massiva em campanhas de webshell e cryptomining ao longo da década seguinte, o que levou a falha ao catálogo KEV da CISA muito depois da publicação original.

A causa é um erro de configuração de access control (CWE-264) no descritor web.xml da aplicação jmx-console.war. O definia explicitamente GET e POST dentro do , e a especificação de Servlets trata essa lista como um filtro positivo: a restrição de auth-constraint só é aplicada às requisições que casam com os métodos listados. Qualquer requisição usando um verbo diferente — não necessariamente exótico, pode ser um método HTTP válido mas não coberto, dependendo da pilha HTTP na frente do container — não é interceptada pelo filtro de segurança, mas ainda é roteada ao HtmlAdaptor servlet subjacente, que processa a chamada como faria com um GET normal.

O atacante não precisa de nenhuma credencial nem de conhecimento de sessão: só precisa que a jmx-console esteja acessível na rede e que o container aceite a requisição com o método alternativo antes de qualquer proxy/filtro upstream normalizá-la. O controle exposto pelo atacante é essencialmente o verbo HTTP da requisição, mantendo o restante do request (path, parâmetros de action=invokeOp, name do MBean, methodIndex, argumentos) idêntico ao que seria usado numa chamada legítima autenticada via GET.

O impacto direto da falha, isolado, é disclosure/acesso não autorizado à interface (por isso o CVSS 3.1 declarado marca apenas confidencialidade parcial, sem integridade nem disponibilidade). O impacto catastrófico que tornou essa CVE notória na prática vem da combinação com MBeans de deployment expostos por padrão na jmx-console de várias versões de JBoss AS/EAP — nesse cenário, o bypass de autenticação abre caminho para invocar operações administrativas sem qualquer credencial.

Na prática, o vetor é enviar à jmx-console (endpoint HtmlAdaptor) uma requisição usando um método HTTP diferente de GET/POST, contornando o security-constraint. Como o handler subjacente processa a chamada normalmente, o atacante ganha acesso não autenticado ao mesmo conjunto de operações que um administrador autenticado teria via jmx-console — incluindo, em instalações que não removeram/protegeram o MBean jboss.deployment:type=DeploymentScanner (comportamento padrão em várias versões da época), a operação addURL, usada para apontar o scanner de deployment para um WAR malicioso hospedado externamente. O deploy automático desse WAR entrega execução de código arbitrário no contexto do processo JBoss.

Pré-requisitos reais: a jmx-console precisa estar acessível pela rede (não bloqueada por firewall/reverse proxy) e a instalação precisa expor os MBeans de deployment sem controles adicionais — que era o padrão em builds vulneráveis não puxadas para o hardening documentado pela comunidade JBoss. Não é necessária nenhuma autenticação prévia, nem interação de usuário, e a complexidade é baixa: ferramentas e provas de conceito públicas automatizam a descoberta do methodIndex correto via inspeção de MBean e a invocação subsequente.

Há exploração ativa confirmada (presença no catálogo KEV da CISA) e módulo Metasploit disponível, além de múltiplos PoCs públicos — inclusive variantes que abusam diretamente do DeploymentScanner mesmo quando a jmx-console já está tecnicamente 'aberta' por outras causas, mostrando que o padrão de ataque (bypass de método + deploy via MBean) permaneceu relevante muito depois de 2010, sobretudo contra instalações antigas/esquecidas expostas à internet.

A correção do fornecedor está nos cumulative patches JBoss EAP 4.2.0.CP09 e 4.3.0.CP08, distribuídos pela Red Hat via RHSA-2010:0376, RHSA-2010:0377 (EAP para RHEL 4) e RHSA-2010:0378, RHSA-2010:0379 (EAP para RHEL 5). Para a comunidade JBoss AS, o problema foi endereçado a partir da versão 6.0.0.M3.

Quando não é possível atualizar, o paliativo documentado (inclusive por fornecedores que empacotam JBoss, como confirmado em bulletin da HP para o NNMi) é editar manualmente o web.xml da jmx-console.war e remover as tags GET e POST do security-constraint, fazendo a restrição de auth-constraint valer para todos os métodos HTTP, não apenas para os dois listados. Esse ajuste é de baixo custo operacional mas exige reiniciar o serviço e validar que nenhuma automação interna dependia de acesso não autenticado à console. Um controle compensatório adicional, independente do patch, é remover ou desabilitar completamente a jmx-console em produção e restringir seu acesso por rede (bind em interface interna, ACL de firewall) — é a mitigação mais eficaz porque elimina a superfície inteira, incluindo outras falhas de deployment não cobertas por esta CVE específica.

O que não funciona: confiar apenas na autenticação padrão da jmx-console sem revisar o web.xml, já que o próprio mecanismo de auth-constraint é o que falha aqui — trocar senha ou usuário do realm JBossAdmin não impede o bypass de método HTTP.

Procure em logs de acesso do JBoss/Apache/proxy requisições ao endpoint /jmx-console/HtmlAdaptor usando métodos HTTP diferentes de GET e POST — qualquer verbo fora desse par nesse path é fortemente suspeito, já que aplicações legítimas usam GET para a interface e POST para invokeOp. Combine com a busca por parâmetros action=invokeOp referenciando MBeans de deployment (jboss.deployment:type=DeploymentScanner ou similares) e por deploys inesperados de arquivos .war com nomes genéricos ou timestamps fora de padrões de release conhecidos, seguidos de acesso a JSPs recém-criados fora do diretório de deploy usual — sinal característico de webshell entregue via addURL.

Se a jmx-console nunca esteve exposta à rede externa e não há logs de acesso a esse path, não há indício de tentativa; ausência de log não é garantia de segurança se a instalação estiver dentro de perímetro sem telemetria de borda.