CVE-2013-2251
Corrija agora. Ela está sob exploração confirmada pelo CISA e tem exploit funcional público.
Apply updates per vendor instructions.
Resumo
Falha de OGNL injection no core do Apache Struts 2 (advisory S2-016): parâmetros de requisição com prefixo "action:", "redirect:" ou "redirectAction:" não são sanitizados e o texto que vem depois do prefixo é avaliado como expressão OGNL contra a ValueStack da aplicação. Como qualquer aplicação Struts2 expõe esse mecanismo de mapeamento de ação por padrão, o resultado é execução remota de código sem autenticação, o que justifica o CVSS 9.8 e a presença no catálogo KEV da CISA com exploração ativa documentada.
Detalhamento técnico
O DefaultActionMapper do Struts2 usa prefixos especiais em parâmetros de requisição para funcionalidades internas: "action:" para encadear chamadas de outra action, "redirect:" e "redirectAction:" para redirecionamentos client-side/server-side. O valor que segue esses prefixos deveria ser tratado como texto simples (nome de action ou URL), mas o código passa esse valor para o interpretador OGNL, que o avalia como expressão contra a ValueStack — a estrutura interna que dá acesso ao contexto da aplicação, ao ActionContext, e por extensão a objetos Java arbitrários (HttpServletRequest, HttpServletResponse, Runtime, ProcessBuilder etc). Isso é uma injeção de linguagem de expressão (CWE-917 / OGNL injection) clássica: o atacante controla integralmente a string que é interpretada como código, sem qualquer whitelist ou escape.
Como a OGNL do Struts2, nesse contexto, permite chamadas de método em cadeia sobre objetos do contexto, um payload bem formado consegue obter referências a HttpServletResponse/Request via #context.get(...), e a partir daí instanciar java.lang.ProcessBuilder ou java.lang.Runtime para executar comandos do sistema operacional, escrever a saída de volta na resposta HTTP e devolver o resultado ao atacante — tudo dentro de uma única requisição GET/POST.
O ponto crítico é que esse comportamento está no processamento de mapeamento de URLs do próprio framework, não em código de aplicação: qualquer app Struts2 na faixa de versões afetada é vulnerável independentemente da lógica de negócio implementada, desde que o endpoint action seja acessível.
Como é explorada
O vetor é uma requisição HTTP simples (GET ou POST) para qualquer endpoint ".action" da aplicação, incluindo um parâmetro cujo nome comece com "action:", "redirect:" ou "redirectAction:" seguido da expressão OGNL maliciosa entre chaves/URL-encoded. Não é necessária autenticação — nos exemplos documentados contra Apache Continuum e Apache Archiva, o payload foi disparado contra endpoints públicos como login.action e groupSummary.action, sem sessão prévia. A complexidade é baixa: basta montar a URL com o payload OGNL correto; não há necessidade de bypass adicional, CSRF, ou interação do usuário.
Há exploração documentada publicamente: um writeup de outubro de 2013 mostra RCE contra um servidor de build da própria Apache (vmbuild.apache.org, rodando Continuum) via parâmetro "redirect:" com um payload que usa ProcessBuilder para executar "whoami" e ler /etc/passwd. Em janeiro de 2014 outro PoC (0day na época, mas na prática já é a mesma CVE-2013-2251) demonstrou o mesmo mecanismo contra Apache Archiva 1.3.6, usando o parâmetro "redirect:" no endpoint /archiva/security/login.action para executar netstat e escrever a saída direto na resposta HTTP.
O resultado final é execução de comando arbitrário com os privilégios do processo da aplicação (usuário que roda o servlet container), o que normalmente permite leitura de arquivos, reconhecimento de rede interna, e pivotagem lateral — a exploração observada confirma isso com whoami/ifconfig/cat de arquivos de sistema logo após a injeção.
Versões
Como se proteger
A correção do framework é a atualização do Apache Struts para 2.3.15.1 ou posterior, versão em que o tratamento dos prefixos "action:", "redirect:" e "redirectAction:" passou a sanitizar/validar o conteúdo antes de repassá-lo ao OGNL. Qualquer aplicação embutindo Struts2 na faixa 2.0.0–2.3.15 precisa trocar a biblioteca, não apenas configurar algo por fora — a falha está no core do mapeamento de actions.
Para distribuições que empacotam Struts internamente, como o Apache Archiva (afetado nas versões 1.2 a 1.3.6, incluindo as já não suportadas 1.2–1.2.2), o fornecedor recomenda upgrade direto para Archiva 2.0.1 ou 1.3.8 — versões que não são afetadas por essa issue segundo o próprio advisory do Archiva. Não há patch binário isolado distribuído pela Apache para essas versões; a atualização de versão completa é o único caminho suportado.
Se a atualização imediata não for viável, o controle compensatório real é isolar o acesso à aplicação Struts2 (restringir exposição de rede aos endpoints .action, colocar autenticação em camada anterior, ou bloquear via WAF/regra de borda requisições cujo parâmetro contenha os prefixos "action:", "redirect:" ou "redirectAction:" seguidos de sintaxe OGNL como "${" ou "%{"), mas isso é mitigação de perímetro, não correção — qualquer bypass de encoding pode contornar filtros de assinatura simples. Não confiar em WAF genérico como solução definitiva: o padrão de exploração já demonstrado usa URL-encoding padrão e não depende de técnica sofisticada de evasão, então qualquer regra frouxa é insuficiente; a única mitigação que elimina a causa raiz é a troca de versão do Struts/Archiva.
Como detectar
Procurar em logs de acesso HTTP por requisições para endpoints ".action" contendo parâmetros cujo nome comece com "action:", "redirect:" ou "redirectAction:" seguidos de conteúdo com sintaxe OGNL — indícios claros são sequências como "${", "%{", "#context", "#_memberAccess", referências a "com.opensymphony.xwork2.dispatcher.HttpServletResponse/Request", ou instanciação de "java.lang.ProcessBuilder"/"java.lang.Runtime" no valor do parâmetro, tipicamente URL-encoded. Presença desses tokens em qualquer parâmetro de query string ou body é um forte indicador de tentativa de exploração desta classe de falha (S2-016), independentemente de sucesso.
Não há um único log de aplicação que confirme exploração bem-sucedida sem análise de resposta: como o payload pode escrever a saída de comando diretamente na resposta HTTP, revisar respostas anômalas (conteúdo de /etc/passwd, saída de comandos de sistema) em endpoints que normalmente devolveriam HTML de login/redirecionamento é o sinal mais confiável de comprometimento efetivo, não apenas tentativa.