CVE-2022-47966

RCE pré-autenticação em mais de vinte produtos on-premise da linha ManageEngine (Zoho), incluindo ServiceDesk Plus, Endpoint Central, ADManager Plus e ADSelfService Plus, decorrente do uso da biblioteca Apache Santuario xmlsec (XML Security for Java) na versão 1.4.1 ou anterior no processamento de respostas SAML. A falha está na CISA KEV com exploração confirmada em campo e PoC pública funcional — é crítica onde SAML SSO está habilitado, mas essa configuração não padrão é o pré-requisito que a manchete de CVSS 9.8 esconde.

O núcleo do problema não é um bug de código no ManageEngine, e sim uma decisão de design do xmlsec 1.4.1: essa versão da biblioteca permite que transformações XSLT sejam executadas durante a validação de assinatura XML (dentro do fluxo de verificação de SAML Response), e delega explicitamente à aplicação que a usa a responsabilidade de restringir quais transformações e funções de extensão podem rodar. As versões dos produtos ManageEngine listadas embutem o xmlsec 1.4.1 sem implementar essas restrições — nenhuma validação de que o `` referenciado na assinatura XML é seguro, nenhum bloqueio a extension functions Java dentro do XSLT.

O efeito prático é um XML External/XSLT injection (CWE-611/CWE-91, dependendo de como se classifica a transformação) que desemboca em execução arbitrária de código Java, porque motores XSLT como o Xalan embutido no JDK permitem invocar métodos Java arbitrários via extension functions dentro do próprio stylesheet — incluindo `java.lang.Runtime`. Quem controla o corpo da SAML Response controla, portanto, o stylesheet XSLT processado durante a verificação da assinatura, e por extensão controla a execução de código no servidor.

O vetor de entrada é o endpoint de consumo de asserção SAML do produto (ex.: `/samlLogin/` em produtos ligados a Active Directory, ou `/SamlResponseServlet` em outros). Como a verificação de assinatura ocorre antes de qualquer autenticação de sessão — é o próprio mecanismo de login SSO — o atacante não precisa de credencial alguma; ele só precisa que o endpoint SAML esteja acessível e que o produto tenha SSO via SAML configurado.

O pesquisador da Viettel Cyber Security (Khoa Dha) documentou a causa raiz original em múltiplas versões do xmlsec; o Horizon3.ai publicou uma análise técnica própria e um PoC que confirma o padrão em pelo menos quatro produtos (ServiceDesk Plus, Endpoint Central, ADManager Plus, ADSelfService Plus), destacando que outros produtos da lista podem exigir bypass de validações adicionais específicas de cada aplicação.

A exploração publicada consiste em enviar uma SAML Response HTTP POST manipulada para o endpoint de login SAML do produto, contendo um ``/stylesheet XSLT malicioso no bloco de assinatura. Quando a biblioteca xmlsec processa essa assinatura para validá-la, executa o XSLT embutido, que por sua vez invoca uma extension function Java para rodar comando via `Runtime.exec`. Não é necessária nenhuma credencial válida nem sessão prévia — o vetor é a própria etapa de SSO que precede a autenticação de sessão. É por isso que o CVSS marca AV:N/PR:N/UI:N.

O pré-requisito real, ausente da descrição curta, é que o produto tenha SAML SSO habilitado e configurado — isso não é o padrão de fábrica na maioria das instalações ManageEngine, que costumam usar autenticação local ou LDAP/AD direto. Em produtos ligados a Active Directory (ex.: ADManager Plus), a exploração também exige conhecer ou adivinhar o valor de `issuer` configurado para o provedor de identidade, o que em geral está em texto claro na configuração do IdP ou é obtido por reconhecimento prévio do ambiente. Para produtos que fazem validações adicionais sobre a SAML Response, a exploração direta do PoC publicado pode não funcionar sem engenharia reversa adicional daquele binário específico — o Horizon3.ai é explícito sobre essa limitação.

A CISA confirma exploração ativa no mundo real (entrada no catálogo KEV), e existe módulo Metasploit e template Nuclei disponíveis, o que baixa bastante a barreira técnica para quem só precisa varrer a internet por instâncias com SSO habilitado. O resultado final, quando bem-sucedido, é execução de código arbitrário com os privilégios do processo do serviço ManageEngine — tipicamente SYSTEM/Administrator no Windows, dado como esses produtos costumam ser instalados.

A mitigação definitiva é atualizar cada produto afetado para a versão corrigida publicada pelo fornecedor (lista abaixo, específica por produto — não existe uma versão-corte única porque cada linha do ManageEngine tem seu próprio ciclo de build). Isso substitui ou corrige o uso do xmlsec vulnerável e adiciona as validações que a versão 1.4.1 da biblioteca deixava a cargo da aplicação.

Se a atualização imediata não for possível, o paliativo real é desabilitar SAML SSO no produto — isso remove o endpoint de consumo de asserção usado como vetor, ao custo de forçar autenticação local ou outro mecanismo de login enquanto o patch não é aplicado. Restringir acesso de rede ao endpoint SAML (firewall, allowlist de IPs de IdP conhecidos) reduz a superfície mas não elimina o risco caso o atacante tenha posição de rede interna, que é o cenário mais comum para produtos ManageEngine expostos apenas internamente.

WAF genérico não é mitigação confiável aqui: o payload malicioso fica embutido dentro de um XML assinado (SAML Response), estruturalmente complexo, e regras de assinatura baseadas em palavras-chave simples tendem a gerar falsos negativos ou exigir parsing XML profundo que a maioria dos WAFs de borda não faz por padrão.

Procurar em logs de aplicação do produto ManageEngine por requisições POST aos endpoints de consumo SAML (padrões como `/samlLogin/` ou `/SamlResponseServlet`) contendo blocos XML com ``, `` referenciando XSLT, ou strings associadas a extension functions Java (ex.: referências a `java.lang.Runtime`, `java.lang.ProcessBuilder`) dentro do corpo da asserção — isso não é tráfego SAML legítimo. Erros ou stack traces de parsing XML/XSLT nos logs do produto em torno do horário de tentativas de login SSO também são indício, especialmente se acompanhados de processos filho anômalos (cmd.exe, powershell.exe, bash, ou binários incomuns) sendo criados pelo processo Java do serviço ManageEngine — o Horizon3.ai publicou um guia de IOCs específico para essa cadeia. Não existe um padrão de assinatura de rede único e confiável para todos os produtos, porque cada aplicação valida a SAML Response de forma um pouco diferente; a ausência de erro nos logs não garante ausência de exploração bem-sucedida.