CVE-2022-35405

Falha de deserialização insegura (CWE-502) no endpoint XML-RPC do ManageEngine Password Manager Pro e PAM360, explorável sem autenticação para execução remota de código. No Access Manager Plus a mesma vulnerabilidade existe mas exige autenticação. Está no catálogo KEV da CISA com exploração confirmada em campo, tem PoC pública, módulo Metasploit e template Nuclei — combinação que a torna prioridade de patch imediata para qualquer instância exposta.

A vulnerabilidade está no parser XML-RPC exposto pelo endpoint /xmlrpc dos três produtos. O serviço aceita chamadas XML-RPC e desserializa objetos Java a partir do payload recebido sem validação adequada de tipo ou origem — um caso clássico de deserialização insegura (CWE-502). Um atacante que controle o conteúdo enviado a esse endpoint pode forjar um payload que, ao ser desserializado pela JVM do servidor, dispare a instanciação de classes com efeitos colaterais (gadget chain), resultando em execução arbitrária de código no contexto do processo da aplicação.

O título da análise técnica publicada (Zoho Password Manager Pro XML-RPC Java Deserialization) confirma esse mecanismo: a superfície de ataque é o parser XML-RPC em si, não uma lógica de negócio específica do gerenciador de senhas. Por isso a Zoho não corrigiu com validação de entrada, mas removendo componentes inteiros — o parser vulnerável em Password Manager Pro, e os componentes vulneráveis completos em PAM360 e Access Manager Plus.

A diferença de pré-condição entre produtos é o ponto central: em Password Manager Pro e PAM360 o endpoint XML-RPC é acessível sem autenticação, tornando o ataque trivial contra qualquer instância exposta à rede. Em Access Manager Plus a mesma classe de falha exige uma sessão autenticada antes de atingir o parser, o que reduz drasticamente o risco em ambientes onde o acesso à interface é restrito.

O vetor é uma requisição HTTP POST ao endpoint /xmlrpc contendo um payload XML-RPC malicioso. Contra Password Manager Pro e PAM360 não é necessária nenhuma credencial nem passo de reconhecimento além de localizar a instância na rede — qualquer atacante com acesso à porta HTTPS do serviço pode enviar a requisição. Contra Access Manager Plus é preciso primeiro obter uma sessão autenticada válida, o que muda o perfil de risco de crítico para dependente de comprometimento prévio de credenciais.

A existência de PoC pública, módulo Metasploit e template Nuclei desde pouco depois da divulgação tornou a exploração acessível a qualquer operador de scanner automatizado, o que explica a entrada no catálogo KEV da CISA por exploração confirmada em campo. O resultado da exploração bem-sucedida é execução de código no contexto do processo do servidor de aplicação — em um cofre de senhas privilegiadas, isso significa potencial exposição de todas as credenciais, chaves e segredos armazenados, além de pivô lateral usando as próprias credenciais geridas pela ferramenta.

A CISA classifica a exploração como não vinculada a nenhuma campanha de ransomware conhecida até o momento do registro, mas trata a falha como confirmada em uso ativo, o que justificou prazo de correção obrigatório para agências federais dos EUA (13/10/2022, para vulnerabilidade adicionada em 22/09/2022).

A correção do fornecedor não é uma configuração ou flag — é atualização de versão obrigatória, pois a Zoho removeu o parser/componente vulnerável do código em vez de tentar saneá-lo. Não existe mitigação equivalente por configuração que neutralize o risco com o componente antigo em execução; restringir acesso de rede ao endpoint /xmlrpc reduz a superfície mas não elimina o risco em Password Manager Pro e PAM360, já que o serviço continua vulnerável a quem alcançar a porta.

Para quem não pode atualizar imediatamente, o único paliativo real é isolar a interface de rede do produto — bloquear acesso externo/não confiável à porta do serviço e restringir a rede de gestão a hosts administrativos conhecidos — e monitorar os logs conforme indicado pelo fornecedor. Isso reduz mas não fecha a janela de exposição, especialmente em redes internas já comprometidas.

Após atualizar, é indispensável verificar logs históricos (ver seção de detecção) para confirmar se a instância foi explorada antes do patch, já que a atualização não reverte comprometimento anterior — se houver evidência de exploração, o fornecedor recomenda isolar a máquina e tratá-la como comprometida, não apenas corrigi-la.

O próprio fornecedor publicou o indicador de comprometimento: nos logs de acesso da instalação (diretório logs/access_log_.txt), buscar ocorrências de requisições POST para /xmlrpc. A presença dessas requisições não confirma exploração por si só — é necessário verificar também, nos logs de aplicação, a linha de erro 'org.apache.xmlrpc.server.XmlRpcErrorLogger - InvocationTargetException: java.lang.reflect.InvocationTargetException' associada a um processo /xmlrpc-, que indica que o payload foi processado pelo parser vulnerável e é o sinal mais forte de tentativa (ou sucesso) de exploração.

Se nenhuma dessas ocorrências aparecer nos logs, o fornecedor considera o ambiente não afetado por tentativa registrada — mas isso depende de retenção de log adequada; ambientes com rotação agressiva de logs podem não ter histórico suficiente para essa verificação retroativa.