CVE-2010-1428

Falha de bypass de controle de acesso no Web Console do JBoss Application Server, distribuído dentro do Red Hat JBoss Enterprise Application Platform (JBEAP) 4.2 e 4.3. A restrição de acesso ao console (/web-console) só era aplicada para os métodos HTTP GET e POST; qualquer requisição usando outro verbo era processada sem autenticação, expondo informações sensíveis sobre a aplicação e o servidor. Está no catálogo KEV da CISA, confirmando exploração ativa, e existe módulo Metasploit público.

O Web Console do JBoss AS é protegido por um security-constraint declarado no web.xml, que restringe acesso via . A configuração vulnerável listava explicitamente apenas GET e POST como métodos protegidos. Containers servlet (JBossWeb/Tomcat) aplicam a constraint apenas aos métodos enumerados; uma requisição com um verbo diferente (por exemplo HEAD ou um método arbitrário) não caía na constraint e era roteada diretamente ao handler padrão do console, que normalmente atende como GET, sem passar pela checagem de autenticação. O resultado é um bypass de controle de acesso — mais precisamente uma variação de CWE-288 (Authentication Bypass Using an Alternate Path or Channel), já que existe um 'caminho alternativo' (verbo HTTP não coberto) para acessar o mesmo recurso protegido.

A falha é estrutural na configuração de segurança, não no código da aplicação em si: o erro está em listar métodos permitidos em vez de proteger todos os métodos por padrão (allow-list invertida). O mesmo padrão de erro afetou, na mesma janela de tempo, o JMX Console (CVE-2010-0738) e o Status Servlet (CVE-2010-1429) — as três foram corrigidas nos mesmos advisories RHSA-2010:0376/0377/0378/0379, o que indica um problema sistêmico na forma como os componentes administrativos do JBoss AP eram protegidos nessa geração.

O atacante não controla parâmetros de aplicação nem payload — ele controla apenas o verbo HTTP da requisição enviada ao endpoint /web-console. Não há necessidade de autenticação prévia nem de conhecimento de credenciais.

O vetor é uma requisição HTTP direta ao endpoint /web-console usando um método diferente de GET ou POST (o report original do Red Hat Bugzilla descreve genericamente 'verbos' não cobertos). Não há pré-requisito de autenticação, de configuração não padrão ou de acesso privilegiado: basta que o Web Console esteja deployado (o que ocorria por padrão em várias instalações de JBEAP 4.2/4.3 e em produtos de terceiros que empacotavam o JBoss AS) e que a porta HTTP do servidor de aplicação seja alcançável pela rede do atacante.

O impacto direto é divulgação de informação (C:H no vetor CVSS informado) — dados sobre a aplicação deployada, configuração do servidor e metadados administrativos ficam expostos sem autenticação. Por si só a falha não concede execução de código, mas historicamente foi usada como etapa de reconhecimento em cadeias de ataque contra instalações JBoss daquele período, junto com o companheiro CVE-2010-0738 (bypass equivalente no JMX Console), que sim permite escalada até execução remota de código via deploy de MBeans/WAR maliciosos.

A presença no catálogo KEV da CISA e a existência de módulo Metasploit confirmam exploração em campo e baixa complexidade de ataque — qualquer scanner ou ferramenta de exploração automatizada consegue detectar e abusar a falha, já que não exige nada além de trocar o verbo HTTP da requisição.

A correção oficial está nas versões JBEAP 4.2.0.CP09 e 4.3.0.CP08, que reconfiguram o Web Console para não restringir a proteção a métodos específicos — a autenticação passa a valer para todas as requisições, independente do verbo. A atualização foi distribuída via RHSA-2010:0376 (4.2.0.CP09/RHEL4), RHSA-2010:0378 (4.2.0.CP09/RHEL5), RHSA-2010:0377 (4.3.0.CP08/RHEL4) e RHSA-2010:0379 (4.3.0.CP08/RHEL5). Antes de aplicar, o próprio advisory recomenda backup do diretório server/[configuration]/deploy/ e de arquivos de configuração customizados.

Se a atualização não for viável de imediato, o paliativo real e documentado (usado inclusive por produtos de terceiros que empacotam JBoss AS, como HP Business Availability Center/Business Service Management) é desabilitar o Web Console removendo-o do deploy — renomeando o artefato do console (por exemplo, o .war correspondente dentro do console-mgr.sar) para que pare de ser carregado pelo servidor. Esse workaround tem custo: qualquer funcionalidade administrativa via console deixa de estar disponível, exigindo administração por outros meios (linha de comando, JMX local, etc.).

O que não funciona como mitigação: bloquear apenas os métodos GET e POST em um proxy ou WAF na frente do JBoss reproduz exatamente o erro original — o atacante simplesmente usa outro verbo. Restrição de rede (firewall/VPN) reduz a superfície de exposição, mas não corrige a causa raiz caso o atacante já tenha alcance à porta HTTP do servidor de aplicação; é controle compensatório, não correção.

Em logs de acesso HTTP do JBoss/JBossWeb (access log), procurar requisições ao caminho /web-console usando métodos diferentes de GET e POST (HEAD, PUT, OPTIONS, TRACE ou verbos não padrão) que retornaram código de sucesso (200) sem uma sessão autenticada associada — isso é o padrão da técnica de bypass descrita. A ausência de autenticação nesses acessos, combinada com o método HTTP anômalo, é o indicador mais confiável disponível.

Não há assinatura de payload a procurar, já que a exploração não injeta dados — é a manipulação do verbo HTTP que caracteriza a tentativa. Ferramentas de scanner de vulnerabilidades e o módulo Metasploit conhecido tendem a gerar requisições repetidas e sistemáticas ao /web-console testando diferentes métodos, o que pode aparecer como rajada de requisições semelhantes vindas do mesmo IP em curto intervalo.