CVE-2024-13159

Falha de path traversal absoluto não autenticado em um endpoint de gerenciamento de vulnerabilidades do Ivanti Endpoint Manager (EPM), que permite a um atacante remoto sem credenciais forçar o servidor a se conectar a um compartilhamento UNC controlado por ele. O NVD descreve o impacto como 'vazamento de informação sensível', mas a pesquisa que originou o achado (Horizon3.ai) demonstra algo mais grave: coerção da credencial de máquina do servidor EPM para uso em ataques de relay NTLM contra o Active Directory. Está no catálogo KEV da CISA com exploração confirmada, o que eleva a urgência independentemente de qual das duas leituras de impacto se aplica ao seu ambiente.

A vulnerabilidade está na DLL WSVulnerabilityCore.dll do EPM (caminho típico C:\Program Files\LANDesk\ManagementSuite\), no namespace LANDesk.ManagementSuite.WSVulnerabilityCore, classe VulCore, que expõe endpoints web API não autenticados relacionados a gerenciamento de vulnerabilidades de endpoints. O método GetHashForWildcardRecursive() recebe um parâmetro de string chamado wildcard e o passa para HashCalculator.GetHashForWildcardRecursive(), que chama Path.GetDirectoryName() sobre esse valor controlado pelo usuário e monta um rootPath via Path.Combine(). Esse rootPath é então usado em HashCalculator.GetDirectories(), que faz o servidor listar e calcular hash de todos os arquivos em um diretório.

O problema (CWE-36, Absolute Path Traversal) é a ausência de validação do parâmetro wildcard: ele pode ser construído como um caminho UNC absoluto (\\host\share\...) em vez de um caminho local relativo esperado. Path.Combine() no .NET, quando recebe um segundo argumento que já é um caminho absoluto/UNC, ignora o primeiro segmento — efeito clássico de bypass de sanitização por concatenação de caminho. O resultado é que o processo do EPM Core Server tenta acessar um recurso de rede arbitrário definido pelo atacante.

O endpoint GetHashForWildcardRecursive não exige autenticação para ser chamado, o que combinado com a falta de validação de entrada permite que qualquer atacante com acesso de rede à interface do Core Server dispare a requisição sem possuir credenciais.

O vetor é uma requisição HTTP não autenticada diretamente ao endpoint vulnerável da API VulCore do EPM Core Server, sem necessidade de interação do usuário. O único pré-requisito real é acesso de rede à interface do servidor EPM — não há necessidade de conta, sessão ou configuração não padrão, o que explica a nota AV:N/PR:N/UI:N no vetor CVSS.

Na prática demonstrada pelos pesquisadores, o atacante aponta o parâmetro wildcard para um caminho UNC sob seu controle. Ao tentar acessar esse caminho para calcular hashes, o processo do EPM (rodando com a conta de máquina do servidor) inicia autenticação NTLM contra o host do atacante. Um listener de relay NTLM (ferramentas como ntlmrelayx, citadas no relatório de origem) captura essa autenticação e a redireciona (relay) para outro serviço da rede, como LDAP/LDAPS de um controlador de domínio, permitindo, por exemplo, criar uma conta de computador no Active Directory ou conceder delegação — abrindo caminho para escalada até comprometimento de domínio.

A CVE está no catálogo KEV da CISA com exploração confirmada em ambientes reais (data de inclusão 10/03/2025, prazo de remediação 31/03/2025), há PoC pública e template Nuclei disponíveis, o que reduz drasticamente a barreira técnica para exploração em massa contra servidores EPM expostos.

A correção oficial é aplicar o Security Update de janeiro de 2025 do Ivanti EPM: para a linha EPM 2024, o 'January-2025 Security Update'; para a linha EPM 2022, o 'SU6 January-2025 Security Update'. O advisory do fornecedor não especifica números de build adicionais nas fontes consultadas — confirme a versão pós-patch diretamente no console/instalador do EPM antes de considerar o ambiente corrigido.

Se a atualização não puder ser aplicada imediatamente, o controle compensatório mais efetivo é reduzir a exposição de rede do EPM Core Server: não expor a interface administrativa à internet, restringir acesso apenas a redes de gerenciamento confiáveis, e bloquear tráfego SMB/CIFS de saída (portas 445/139) do servidor EPM para redes não confiáveis, o que impede a coerção NTLM mesmo que o endpoint permaneça vulnerável. Habilitar SMB signing e LDAP signing/channel binding no domínio reduz o impacto de um relay bem-sucedido, mas não corrige a vulnerabilidade em si.

WAF não é mitigação confiável aqui: a falha está na lógica de manipulação de caminho dentro da aplicação .NET, não em um padrão de payload facilmente identificável por assinatura — path traversal absoluto via UNC pode ser codificado de várias formas que escapam a regras genéricas.

Monitore o Core Server EPM por conexões SMB/UNC de saída para IPs externos ou não catalogados na rede — esse é o sinal mais direto de tentativa de coerção via este endpoint, já que o comportamento normal do serviço não gera tráfego SMB para hosts arbitrários. Em logs de aplicação/IIS do EPM, procure requisições não autenticadas aos endpoints da API VulCore (GetHashForWildcardRecursive, GetHashForWildcard, GetHashForSingleFile, GetHashForFile) contendo parâmetros com caminhos UNC (prefixo \\) em vez de caminhos locais esperados. No Active Directory, alerte para criação de contas de computador fora do processo normal de provisionamento e concessões de delegação inesperadas, sinais consistentes com relay NTLM bem-sucedido. Não há assinatura de payload única confiável — a exploração é uma requisição HTTP legítima em formato, distinguível apenas pelo conteúdo do parâmetro e pelo comportamento de rede resultante.