CVE-2013-0422

Falha crítica no plugin Java 7 (até a Update 10) que permite a um applet não confiado, executado dentro do navegador, escapar da sandbox e obter execução de código arbitrário sem interação além de visitar uma página maliciosa. Foi explorada ativamente in the wild a partir de janeiro de 2013, incorporada em kits de exploração como Blackhole, Nuclear Pack, Cool EK, Redkit, Sakura e SofosFO antes mesmo de existir patch. O CVSS 9.8 reflete bem o risco real: não exige autenticação, não exige configuração não padrão — só Java habilitado no navegador.

A vulnerabilidade é, na prática, duas falhas encadeadas dentro do subsistema de reflection/JMX da JVM. A primeira (CWE-284, controle de acesso impróprio) está no método público getMBeanInstantiator() da classe com.sun.jmx.mbeanserver.JmxMBeanServer, que devolve uma referência ao objeto interno MBeanInstantiator — supostamente privado. A partir dele, o método findClass() permite carregar qualquer classe restrita via Class.forName() sem passar pelas checagens normais de Class Loader, dando ao código do applet acesso a classes de sistema que deveriam estar fora de alcance.

A segunda falha explora o uso recursivo da nova Reflection API (java.lang.invoke.*) para contornar a checagem feita por java.lang.invoke.MethodHandles.Lookup.checkSecurityManager. O problema de raiz é que sun.reflect.Reflection.getCallerClass não sabe pular os frames de pilha inseridos pela nova API de reflection, então a verificação de 'quem está chamando' acaba examinando o frame errado — no caso, um frame confiável — e libera a chamada. Isso é reaproveitamento de um vetor já usado por pesquisadores da Security Explorations contra o 'Issue 32', cujo fix de outubro de 2012 (relacionado à mesma família de bugs) foi incompleto: o bloqueio de APIs sensíveis via isCallerSensitive cobria a Core Reflection API (Class.forName, getMethods etc.) mas não a nova Reflection API baseada em MethodHandle.

Combinando as duas: o atacante usa o MBeanInstantiator para obter referência a classes de sistema privilegiadas (por exemplo sun.org.mozilla.javascript.internal.GeneratedClassLoader) e usa o bypass de Reflection API para invocar métodos restritos dessas classes via invokeWithArguments, sem precisar de applet assinado. O objetivo final típico é chamar setSecurityManager(null) ou equivalente, desligando completamente o Security Manager da JVM e ganhando privilégios plenos no processo Java, de onde se derruba um payload nativo (.exe) no disco.

O próprio CVE, segundo o NOTE oficial, cobre as duas vertentes (JMX/MBean e Reflection API) e é distinto de CVE-2012-4681 e CVE-2012-3174, apesar de alguma confusão de mapeamento na comunidade nesse período.

Vetor é drive-by download: a vítima visita (ou é redirecionada para) uma página HTML com um applet Java malicioso embutido — vista em exploit kits como Blackhole, Nuclear Pack, Cool EK, Redkit, Sakura, SofosFO e ProPack já em janeiro de 2013, entregando ransomware (Reveton, CBeplay) e outros payloads via arquivo .jar seguido de um executável baixado. Não há autenticação, não há necessidade de configuração especial: basta ter o plugin Java 7 (até Update 10) habilitado no navegador. A cadeia de exploração roda inteiramente dentro da JVM sandbox e não depende de engenharia social sofisticada além de fazer a vítima carregar a página/applet.

A CISA lista a falha no catálogo KEV, confirmando exploração ativa documentada, e existe módulo Metasploit e PoC pública, o que baixa ainda mais a barreira de reprodução — qualquer operador de exploit kit da época conseguia reproduzir a cadeia sem pesquisa própria.

Um ponto crítico levantado por pesquisadores (Immunity, Security Explorations) é que o patch oficial da Oracle (Update 11) corrigiu apenas a parte da Reflection API (isCallerSensitive e sun.reflect.misc.MethodUtil), mas não tocou nas classes do pacote com.sun.jmx.mbeanserver — ou seja, o MBeanInstantiator.findClass continuava funcional mesmo após a atualização. Isso significa que um atacante com uma segunda vulnerabilidade de bypass de Reflection (substituindo a parte já corrigida) poderia reconstruir a cadeia completa mesmo em sistemas 'corrigidos' com Update 11.

O fornecedor lançou Java 7 Update 11, que também endureceu o nível de segurança padrão do painel de controle Java para 'High' (exige confirmação do usuário antes de rodar applets não assinados ou autoassinados). Ainda assim, pesquisadores demonstraram que esse update corrigiu apenas o componente de Reflection API do exploit encadeado, deixando o findClass do MBeanInstantiator intacto — não trate a atualização como fechamento total do vetor de abuso via JMX/MBean.

O paliativo mais efetivo, recomendado inclusive pelo CERT/CC, é desabilitar Java como plugin do navegador inteiramente (a partir da Update 10 isso é possível via o applet Java Control Panel, ou via instalador com a opção de linha de comando que desativa o componente web) — a menos que exista dependência de negócio que exija Java no navegador. Isso neutraliza não só esta falha como qualquer outra vulnerabilidade futura de plugin, ao custo de quebrar aplicações internas legadas baseadas em applet.

Onde desabilitar Java não é viável, um controle compensatório de rede é filtrar/bloquear requisições para arquivos .jar e .class em proxies, e inspecionar/bloquear o User-Agent característico do Java Web Start, restringindo o uso a intranets confiáveis. Isso reduz superfície de ataque via exploit kits externos mas não elimina o risco caso o atacante já tenha ponto de apoio interno. Para ambientes OpenJDK/IcedTea, o fix correspondente está nas versões 2.1.4, 2.2.4 e 2.3.4.

Não há assinatura confiável de exploração no nível de log da aplicação Java em si; os sinais úteis estão na camada de rede/proxy: requisições HTTP com download sequencial de páginas de 'landing' seguidas de arquivo .jar e depois um executável Windows (.exe) vindo do mesmo host ou domínio associado — padrão característico de exploit kits da época (Blackhole, Nuclear Pack, Cool EK, Redkit, Sakura, SofosFO, ProPack, todos documentados explorando esta CVE em janeiro de 2013). User-Agent contendo string de cliente Java (Java Web Start/plugin) fazendo requisições a domínios externos incomuns é outro indicador.

Hashes de payload e domínios de C2 específicos das campanhas de 2013 (Reveton, CBeplay, Zaccess) estão documentados nas fontes de threat intel da época, mas são artefatos daquela onda de campanhas, não indicadores genéricos da vulnerabilidade — não servem para detectar reuso atual do bug.