SysAid On-Prem <= 23.3.40 Checkin Proceessing XML External Entity Injection
Corrija agora. Ela está sob exploração confirmada pelo CISA e tem exploit funcional público.
Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable.
Resumo
Falha de XML External Entity (XXE) não autenticada no endpoint /mdm/checkin do SysAid On-Prem, usado pelo fluxo de checkin de dispositivos móveis (MDM). O parsing de XML sem restrição a entidades externas permite leitura de arquivos do servidor e, segundo a pesquisa que descobriu a falha, serve como primitivo inicial para takeover de conta de administrador. Está no catálogo KEV da CISA com exploração confirmada e há PoC pública e template Nuclei, o que eleva a urgência prática além do que o CVSS 9.3 já indica.
Detalhamento técnico
A vulnerabilidade (CWE-611, Improper Restriction of XML External Entity Reference) está na classe com.ilient.mdm.GetMdmMessage, método doPost, dentro do sysaid.jar que compõe o núcleo da aplicação Java do SysAid On-Prem. Quando a requestURI termina em 'checkin', o método processa o corpo da requisição HTTP POST chamando PropertyListParser.parse(byteArray) sobre os bytes recebidos diretamente do cliente, sem qualquer validação ou sanitização do XML antes do parsing.
Como o parser de property list (formato Apple-style plist em XML) não desabilita resolução de entidades externas, um atacante controla integralmente o corpo XML enviado ao endpoint /mdm/checkin e pode declarar um DOCTYPE com ENTITY externa apontando para arquivos locais do servidor (via file://) ou para endereços controlados pelo atacante (para exfiltração out-of-band). O endpoint /mdm/checkin é parte do fluxo de check-in de dispositivos móveis gerenciados via MDM, mas não exige autenticação para ser alcançado — é isso que torna a falha pré-autenticada.
A equipe da watchTowr identificou essa XXE como a primeira de uma cadeia de três XXEs relacionadas (CVE-2025-2775, -2776, -2777) no mesmo produto, que combinadas com outras falhas (incluindo CVE-2024-36394, usada para o RCE final) permitiram atingir execução remota de comando pré-autenticada como SYSTEM. A CVE-2025-2775 especificamente corresponde ao primitivo de leitura de arquivo/XXE no endpoint de checkin, que é a peça usada para obter dados sensíveis (ex.: tokens ou configurações) que viabilizam o takeover de conta administrativa.
Como é explorada
O vetor é uma requisição HTTP POST não autenticada para /mdm/checkin, acessível por qualquer atacante com acesso de rede à interface do SysAid On-Prem — não há necessidade de credenciais, interação do usuário ou configuração não padrão além de o serviço estar exposto e em versão vulnerável. O atacante envia um corpo XML malicioso com uma entidade externa declarada; a resposta do servidor (ou um callback out-of-band, dependendo da técnica usada) permite recuperar conteúdo de arquivos do sistema de arquivos do servidor Windows onde o SysAid roda.
A watchTowr documentou publicamente essa falha como parte de uma cadeia de exploração completa que termina em RCE pré-autenticado como SYSTEM, combinando os três XXEs descobertos com uma vulnerabilidade adicional de execução de comando pós-autenticação. Isoladamente, CVE-2025-2775 entrega leitura de arquivo e, segundo o fornecedor e a CISA, um caminho para takeover de conta de administrador — presumivelmente por meio da leitura de arquivos de configuração ou de dados de sessão/credenciais armazenados no servidor.
A CISA confirma exploração ativa no mundo real (inclusão no KEV em 2025-07-22, prazo de correção 2025-08-12) e há template Nuclei e PoC pública, o que reduz a barreira de exploração massiva — qualquer scanner automatizado pode identificar instâncias vulneráveis expostas na internet. A nota da CISA indica que não há confirmação de uso em campanhas de ransomware especificamente ligadas a esta CVE ('Unknown'), mas o histórico do produto (alvo de ransomware anteriormente) e a natureza da falha (instância unauthenticated, internet-facing, ITSM crítico) tornam o risco de uso oportunista alto.
Versões
Como se proteger
O fornecedor publicou correção referenciada em sua documentação (link abaixo); a página trata de release notes de uma versão corrigida, mas o conteúdo específico da página não foi verificado nesta pesquisa além do link citado pelo próprio fornecedor e pela CISA. A ação recomendada é atualizar o SysAid On-Prem para a versão corrigida indicada nas release notes oficiais mais recentes do fornecedor — não use a versão 23.3.40 ou anterior.
Se a atualização imediata não for possível, o controle compensatório real é restringir o acesso de rede ao endpoint /mdm/checkin (e, de forma mais ampla, a toda a superfície /mdm/) a apenas os dispositivos MDM legítimos, via firewall, VPN ou segmentação de rede — isso reduz drasticamente a exposição sem quebrar funcionalidade para quem não usa o módulo MDM. Se a organização não usa gerenciamento de dispositivos móveis via SysAid, desabilitar ou bloquear completamente o caminho /mdm/ é uma mitigação eficaz e de baixo custo.
O que NÃO funciona: como a falha é pré-autenticada, qualquer controle baseado em permissões de usuário, políticas de senha ou MFA na aplicação não tem efeito — o atacante nunca chega a se autenticar antes de explorar a XXE. Um WAF genérico só ajuda se tiver regra específica para bloquear estruturas DOCTYPE/ENTITY em corpos XML recebidos nesse caminho, o que exige configuração dedicada, não proteção padrão.
Como detectar
Procure em logs do servidor de aplicação (não em logs de autenticação, já que a exploração é pré-auth) requisições POST para /mdm/checkin cujo corpo contenha declarações DOCTYPE, ENTITY ou SYSTEM referenciando file:// ou URLs externas — esse é o padrão característico de payload XXE. Monitore também conexões de saída inesperadas originadas do processo Java do SysAid (para IPs/domínios externos não relacionados à operação normal do produto), que indicariam uma técnica de exfiltração out-of-band.
Não há um indicador único e confiável além do padrão de payload no corpo da requisição — como o endpoint é legítimo e usado normalmente pelo fluxo MDM, tráfego para /mdm/checkin por si só não é anômalo; o que diferencia exploração é a presença de construções XML de definição de entidade externa no corpo da requisição.