CVE-2017-12149

Falha de desserialização insegura (CWE-502) no HTTP Invoker do JBoss Application Server, como distribuído no Red Hat JBoss Enterprise Application Platform 5.2. O método doFilter da classe ReadOnlyAccessFilter aceita e desserializa objetos Java arbitrários enviados via HTTP sem qualquer whitelist de classes, permitindo execução remota de código sem autenticação. É crítica porque não exige login, não exige configuração especial além do componente estar exposto, e tem exploração ativa documentada (KEV da CISA, módulo Metasploit, template Nuclei, PoC pública).

O HTTP Invoker é um componente do JBoss AS 5.x que expõe endpoints HTTP para invocação remota de EJBs e outros serviços via serialização Java nativa — um mecanismo de RMI-sobre-HTTP típico da época. O filtro ReadOnlyAccessFilter, que deveria apenas controlar acesso de leitura a esses endpoints, desserializa o corpo da requisição para extrair os objetos de invocação antes de qualquer verificação de classe permitida. Isso significa que o atacante controla o stream de bytes serializado inteiro, e a JVM instancia qualquer classe presente no classpath do servidor durante a desserialização — inclusive classes de bibliotecas comuns (Apache Commons Collections, Spring, etc.) que podem ser encadeadas em gadget chains para forçar execução arbitrária de comandos do sistema operacional.

O problema é estrutural ao design do HTTP Invoker em EAP 5.2, não um bug isolado de parsing: qualquer endpoint que aceite ObjectInputStream sem restrição de classes é vulnerável, e o ReadOnlyAccessFilter foi o ponto de entrada identificado. A Red Hat confirma que o EAP 6 e o EAP 7 não embarcam o http-invoker e portanto não são afetados — a exposição é específica da linha 5.x.

O CVSS 9.8 reflete corretamente a ausência de pré-condições: rede, sem privilégio, sem interação do usuário, e impacto total em confidencialidade, integridade e disponibilidade, já que RCE na JVM do servidor de aplicação geralmente equivale a controle total do processo e, por extensão, do host.

O vetor é uma requisição HTTP (tipicamente POST) para o contexto do http-invoker (as URLs variam conforme o profile/deploy — default, web, all — mas seguem o padrão dos serviços expostos em http-invoker.sar) contendo um stream de objeto Java serializado malicioso. O atacante monta esse payload usando ferramentas de geração de gadget chains (o mesmo ecossistema usado em outras falhas de desserialização Java da época, como ysoserial), aproveitando classes já presentes no classpath do JBoss AS 5.2 para encadear chamadas até execução de comando no sistema operacional.

Não há pré-requisito de autenticação nem de configuração não padrão: basta o http-invoker.sar estar deployado e acessível na rede, o que é o comportamento padrão de instalação do EAP 5.2. A complexidade de exploração é baixa — existem PoCs públicas, módulo Metasploit e template Nuclei prontos, o que reduz a barreira técnica a quase zero e explica a presença no catálogo KEV da CISA com exploração confirmada em ambiente real.

O resultado da exploração bem-sucedida é execução arbitrária de código com os privilégios do processo JBoss, o que na prática costuma significar shell completo no servidor de aplicação e, a partir daí, movimento lateral dependendo de como o servidor está integrado ao restante do ambiente.

A correção do fornecedor está nos pacotes jbossas-5.2.0-24.ep5 (el5 e el6), distribuídos via RHSA-2018:1607 e RHSA-2018:1608. Quem roda EAP 5.2 sem suporte comercial ativo ou sem acesso a esses patches precisa avaliar migração para EAP 6 ou 7, que não embarcam o http-invoker e portanto não têm essa superfície de ataque.

Se a atualização não for viável no curto prazo, a própria Red Hat descreve dois paliativos reais: (1) restringir o acesso a todo o contexto do http-invoker adicionando um /* nos security-constraints do web.xml de cada http-invoker.sar deployado (o caminho do arquivo varia conforme o profile em uso — default, web, all etc.); ou (2) remover completamente o http-invoker.sar dos profiles em uso, para quem não depende desse mecanismo de invocação remota. Ambos eliminam a exposição do endpoint, mas a remoção quebra qualquer integração que dependa do HTTP Invoker — é preciso confirmar que nada consome esse serviço antes de remover.

Controles de rede (isolar a porta/contexto do invoker, WAF bloqueando content-type de objeto serializado Java) reduzem exposição mas não corrigem a falha — servem como camada até a atualização ou a desativação do componente, não como solução definitiva.

Sinal mais direto: requisições HTTP para os contextos do http-invoker (paths dentro de http-invoker.sar/invoker.war) com corpo em formato de objeto serializado Java (content-type application/x-java-serialized-object ou binário iniciando com o magic bytes de stream serializado 0xACED). Presença de strings associadas a gadget chains conhecidos (por exemplo, referências a org.apache.commons.collections.functors.InvokerTransformer ou a ferramentas como ysoserial) no corpo da requisição é forte indicador de tentativa de exploração.

No host, processos filhos inesperados gerados pela JVM do JBoss (shells, comandos do sistema) fora do padrão de operação da aplicação são o indicador pós-exploração mais confiável — não há padrão de log de aplicação garantido, já que a falha ocorre na camada de desserialização antes de qualquer log de negócio ser gerado, então monitoramento de rede e EDR no processo do servidor de aplicação é mais confiável do que log de aplicação isolado.