CVE-2012-3152

CVE-2012-3152 afeta o componente Report Server do Oracle Reports Developer, dentro do Oracle Fusion Middleware, permitindo que um atacante remoto e não autenticado leia e grave arquivos arbitrários no servidor através do parâmetro URLPARAMETER do endpoint rwservlet. A gravidade real da falha só aparece quando combinada com CVE-2012-3153: juntas permitem execução remota de código via upload de um shell JSP. Apesar de datar de 2012, está no catálogo KEV da CISA, tem exploit público desde 2014 e EPSS próximo de 1 — é ativamente varrida e explorada até hoje em instalações legadas expostas à internet.

O rwservlet do Oracle Reports processa jobs de relatório através de parâmetros HTTP (report, desformat, destype, desname, JOBTYPE, URLPARAMETER) sem validação adequada de destino de escrita. A combinação destype=file com desname permite definir um caminho de saída no filesystem do servidor; JOBTYPE=rwurl faz o Report Server buscar um recurso externo através de URLPARAMETER e gravar o conteúdo retornado no destino especificado. É essa gravação de arquivo controlada pelo atacante — sem autenticação e sem restrição de extensão ou diretório — que a Oracle descreve de forma genérica na CPU de outubro de 2012 como 'unspecified vulnerability... affect confidentiality and integrity related to Report Server Component'. Trata-se essencialmente de um upload/escrita arbitrária de arquivo (CWE-434/CWE-22), não uma falha de lógica isolada.

O pesquisador original (Dana Taylor, netinfiltration.com) foi além da descrição oficial da Oracle: afirmou que a mesma funcionalidade URLPARAMETER permite tanto leitura quanto upload de arquivos arbitrários via rwservlet, e que o problema não está limitado às versões listadas na CPU, alcançando também releases muito mais antigas (9iAS, 9iDS, 10g AS/DS). A Oracle nunca confirmou publicamente esse alcance estendido — é uma afirmação do pesquisador, não do fornecedor.

A cadeia completa de exploração depende de uma função não documentada chamada parsequery, atribuída ao par CVE-2012-3153, que expõe credenciais de conexão ao banco (userid/senha) e identificadores de servidor sem autenticação, acessível também via rwservlet. Essas duas peças — escrita arbitrária de arquivo via URLPARAMETER e vazamento de credenciais/paths via parsequery/showenv — se encaixam: uma revela onde e como escrever, a outra escreve o payload.

O vetor é inteiramente HTTP, sem autenticação, sem interação do usuário: o atacante só precisa de acesso de rede ao endpoint /reports/rwservlet exposto. O exploit público (Exploit-DB 31253, autoria de Mekanismen, baseado na disclosure original de Dana Taylor) automatiza a cadeia: consulta /reports/rwservlet/showmap para enumerar keymaps configurados no servidor, usa /reports/rwservlet/parsequery para extrair identificador de servidor e credenciais associadas a cada keymap, consulta /reports/rwservlet/showenv com esses dados para descobrir o caminho físico local do diretório de relatórios, e então dispara uma requisição ao rwservlet com JOBTYPE=rwurl e URLPARAMETER apontando para uma URL controlada pelo atacante — fazendo o Report Server baixar esse conteúdo e gravá-lo como arquivo .jsp dentro de um diretório publicamente acessível (.../images/). O arquivo gravado é então executado normalmente pelo container Java do servidor de aplicação, dando execução remota de código completa.

A complexidade prática varia: a escrita de arquivo via URLPARAMETER funciona de forma direta contra qualquer instância vulnerável exposta, mas a automação completa (localizar automaticamente um caminho gravável via parsequery/showenv) depende de o servidor ter keymaps configurados de um jeito que a enumeração automática encontre — o próprio autor do exploit nota que a falta de keymap 'aproveitável' não significa que o alvo não é vulnerável, apenas que a exploração automatizada falha e exige reconhecimento manual.

A presença no catálogo KEV da CISA confirma exploração ativa observada em campo, e a combinação de exploit público maduro desde 2014, ausência de exigência de credenciais e amplo histórico de instalações Oracle Reports/Forms esquecidas na internet explicam o EPSS próximo do topo da escala.

A Oracle tratou a falha na CPU de outubro de 2012, cobrindo as versões 11.1.1.4, 11.1.1.6 e 11.1.2.0 do Reports Developer — aplicar essa CPU e as CPUs subsequentes é o caminho oficial. Nenhuma das fontes consultadas especifica um número de versão de correção pontual (ex.: 11.1.1.7) além da referência genérica à CPU; trate 'aplicar a CPU de outubro de 2012 ou posterior' como o dado concreto disponível.

Há um alerta relevante do pesquisador original: segundo ele, o patch/workaround da Oracle não eliminou de fato o problema de parsequery, apenas suprimiu a saída de diagnóstico que expunha as credenciais — ou seja, aplicar só a CPU pode dar falsa sensação de resolução completa da cadeia de ataque. Isso não é confirmado pela Oracle, mas é uma reivindicação pública específica e verificável em testes, não deve ser descartada sem validação própria. A mesma fonte afirma que a reescrita de código na linha 12g mitigou a vulnerabilidade — novamente, afirmação do pesquisador, não declaração oficial da Oracle sobre esta CVE.

Como controle compensatório real quando a atualização não é viável: não expor o endpoint /reports/rwservlet diretamente à internet, restringindo acesso por rede a hosts de gerência confiáveis; se a versão permitir, desabilitar ou restringir JOBTYPE=rwurl e a funcionalidade URLPARAMETER; monitorar e restringir permissão de escrita do processo do Report Server sobre diretórios servidos publicamente (como .../images/). Um WAF genérico não é mitigação confiável aqui porque o abuso ocorre através de parâmetros legítimos da aplicação (report, destype, desname, JOBTYPE, URLPARAMETER), não de payloads facilmente assinaturáveis.

Em logs de acesso web, procurar requisições a /reports/rwservlet contendo os parâmetros JOBTYPE=rwurl, URLPARAMETER, destype=file e desname apontando para subdiretórios como .../images/ — esse é o padrão de gravação de arquivo característico do exploit público. Também vale procurar chamadas não autenticadas a /reports/rwservlet/showmap, /reports/rwservlet/parsequery e /reports/rwservlet/showenv, usadas na fase de reconhecimento/enumeração de credenciais que precede o upload. A presença de arquivos .jsp com nomes aleatórios (padrão de 8 caracteres alfabéticos, no exploit conhecido) dentro de diretórios de imagens do Reports Server é indício direto de comprometimento. Ambientes sem logging de acesso HTTP dedicado ao Report Server (muitas instalações antigas não centralizam esses logs) têm baixa capacidade de detecção retroativa — a ausência de sinal não significa ausência de exploração.