CVE-2017-1000486

PrimeFaces, biblioteca de componentes UI para JSF muito usada em aplicações Java corporativas, usa uma chave de criptografia hard-coded ('primefaces') e um esquema DES/CBC sem verificação de integridade para proteger o parâmetro 'pfdrid' do StreamedContentHandler. Um atacante não autenticado consegue forjar ou decifrar esse parâmetro via ataque de padding oracle e injetar Expression Language (EL) arbitrária, resultando em execução remota de código no servidor de aplicação. O CVSS 9.8 é justificado: não exige autenticação, não exige configuração especial além do uso padrão da biblioteca, e a falha está confirmada em exploração ativa (KEV da CISA).

O sink vulnerável é '/org/primefaces/application/resource/StreamedContentHandler.java', que decifra o parâmetro 'dynamicContentId' (enviado como 'pfdrid') e passa o resultado diretamente para 'ExpressionFactory.createValueExpression()', avaliando-o como EL. Não há sanitização entre a decifragem e a avaliação: qualquer texto que decifre corretamente é executado como código EL pelo motor JSF.

Há duas falhas de criptografia que permitem controlar esse texto decifrado, batizadas pelos pesquisadores da Minded Security de 'PrimeSecret' e 'PrimeOracle'. PrimeSecret (CWE-326, força de criptografia inadequada): em '/org/primefaces/config/ConfigContainer.java', quando o desenvolvedor não configura explicitamente uma chave, o valor padrão hard-coded 'primefaces' é usado como chave de criptografia — igual em toda instalação PrimeFaces não customizada. PrimeOracle: em '/org/primefaces/util/StringEncrypter.java', a chave é derivada via PBEWithMD5AndDES com um salt estático (8 bytes fixos no código) e IV estático, cifrando em modo CBC sem HMAC ou qualquer verificação de autenticidade — condição clássica para ataque de padding oracle.

Com qualquer uma das duas, o atacante consegue produzir um valor cifrado válido para 'pfdrid' cujo plaintext é uma expressão EL arbitrária. A ausência de HMAC no PrimeOracle permite recuperar esse cifrado byte a byte observando as respostas de erro/sucesso do servidor (diferença detectável no padding), sem nunca conhecer a chave. O EL avaliado tem acesso total ao contexto de aplicação Java: 'facesContext', 'session', e a partir daí a qualquer classe Java via reflection — incluindo 'ProcessBuilder' para executar comandos do sistema.

O vetor é HTTP, sem autenticação: uma requisição (GET ou POST, dependendo da versão/target) para o endpoint de recurso dinâmico do PrimeFaces, tipicamente algo como '.../javax.faces.resource/dynamiccontent.properties.xhtml', com parâmetros 'pfdrt=sc', 'ln=primefaces' e 'pfdrid='. Não há pré-condição de configuração incomum — a falha existe no comportamento padrão da biblioteca; só não é explorável se a aplicação não expõe esse recurso ou já corrigiu.

Dois caminhos de exploração coexistem. O mais simples (PrimeSecret) assume que o desenvolvedor nunca trocou a chave padrão 'primefaces' — nesse caso o atacante cifra o EL diretamente com essa chave conhecida e envia, sem necessidade de qualquer ataque criptográfico adicional (é o que o módulo Metasploit faz por padrão, com PASSWORD='primefaces'). O caminho mais complexo (PrimeOracle) funciona mesmo com chave customizada: usando uma ferramenta de padding oracle (a técnica original documentada usa PadBuster), o atacante envia múltiplas requisições manipulando bytes do cifrado e observa diferenças de resposta HTTP (erro 500 vs. comportamento de sucesso) para reconstruir, byte a byte, um cifrado válido correspondente a um EL escolhido — sem nunca precisar da chave.

Há exploração confirmada em campo (listada no catálogo KEV da CISA desde janeiro de 2022) e existe módulo público no Metasploit Framework, além de PoC no Exploit-DB, o que torna a barreira de exploração praticamente nula para quem já tem acesso de rede ao endpoint. O resultado final é execução de comando arbitrário no contexto do processo da aplicação Java (geralmente com privilégios elevados do servidor de aplicação).

O fornecedor corrigiu removendo a chave/salt hard-coded e adicionando verificação de integridade na criptografia usada pelo StreamedContentHandler. As versões corrigidas, segundo o próprio issue tracker e o advisory usado pelo módulo Metasploit, são as séries 5.2.21, 5.3.8 e 6.0 em diante (o milestone do fix no GitHub também referencia um backport para 4.0.25). Atualizar para uma dessas versões ou posterior elimina a falha.

Se a atualização não é viável imediatamente, o paliativo mínimo é configurar explicitamente uma chave de criptografia forte e não-padrão para o parâmetro 'primefaces.SECRET' (ou equivalente na versão em uso), o que neutraliza o ataque PrimeSecret — mas não neutraliza necessariamente o PrimeOracle se a versão ainda usa o esquema DES/CBC sem HMAC, já que o padding oracle não depende de conhecer a chave. Bloquear ou restringir acesso ao endpoint '.../javax.faces.resource/dynamiccontent.properties.xhtml' via proxy/WAF reduz a superfície, mas é contorno frágil porque o path pode variar por aplicação.

Não funciona como mitigação apenas trocar a senha sem atualizar a biblioteca em versões vulneráveis ao PrimeOracle, nem confiar em obscuridade do endpoint — o padding oracle não exige conhecimento prévio da chave, só acesso de rede ao endpoint vulnerável.

Em logs de acesso web, procurar requisições para caminhos de recurso dinâmico do JSF/PrimeFaces (padrão '.../javax.faces.resource/...properties.xhtml' ou variantes) contendo os parâmetros 'pfdrt=sc', 'ln=primefaces' e um valor 'pfdrid' longo em base64/URL-encoded — especialmente em volume alto e repetido com pequenas variações de byte, característico de um ataque de padding oracle automatizado (centenas a milhares de requisições muito similares em curto intervalo, cada uma testando um byte do cifrado). Respostas HTTP 500 intercaladas com 200 para essas requisições no mesmo padrão de URL são o sinal mais forte de tentativa de padding oracle em andamento.

Para a variante PrimeSecret (chave padrão), uma única requisição bem-sucedida já basta e não deixa padrão de volume — nesse caso o sinal fica limitado a qualquer 'pfdrid' que decodifique/decifre para EL malicioso, o que exige inspeção de payload e não apenas de metadados de tráfego; sem isso, não há sinal confiável de detecção pós-fato.