CVE-2025-12480

Falha de controle de acesso (CWE-284) no Triofox, plataforma de acesso remoto a arquivos da Gladinet, permite que um usuário não autenticado acesse as páginas de setup inicial mesmo depois que a instalação já foi concluída. Isso possibilita criar uma nova conta de administrador nativa e, a partir dela, encadear o abuso do recurso antivírus integrado do produto para obter execução de código no host. A CISA confirmou exploração ativa em campo (KEV, adicionada em 12/11/2025, prazo de correção 03/12/2025) e a Mandiant documentou um cluster de ameaça (UNC6485) explorando a falha desde pelo menos 24 de agosto de 2025 — antes da publicação da CVE.

A causa raiz está na função CanRunCriticalPage(), na classe GladPageUILib.GladBasePage, dentro de GladPageUILib.dll. Essa função decide se uma requisição pode acessar páginas 'críticas' de configuração comparando Request.Url.Host com a string 'localhost': se o Host da URL for igual a 'localhost', o acesso é concedido incondicionalmente, pulando qualquer outra verificação. Só se essa comparação falhar o código cai para uma checagem secundária baseada em um IP confiável configurável (TrustedHostIp no web.config) — e se esse parâmetro não estiver definido, não há proteção alguma.

O problema é que, em ASP.NET, Request.Url.Host é derivado diretamente do cabeçalho HTTP Host enviado pelo cliente, e esse cabeçalho é totalmente controlado pelo atacante. Não há verificação de que a conexão realmente se originou da própria máquina (por exemplo, via IP de loopback real). Isso é um ataque clássico de HTTP Host Header: basta enviar uma requisição externa com o cabeçalho 'Host: localhost' para satisfazer a condição de acesso.

Com esse bypass, o atacante alcança páginas como AdminDatabase.aspx (configuração inicial de banco de dados), que redireciona para AdminAccount.aspx e depois InitAccount.aspx — o fluxo original de primeira instalação, que deveria estar bloqueado após o setup já ter sido concluído. Ao completar esse fluxo, cria-se uma conta de administrador nativa nova, totalmente sob controle do atacante.

De posse dessa conta administrativa na WebUI, o segundo estágio da cadeia não é mais falha de controle de acesso, e sim abuso de funcionalidade legítima: o Triofox permite configurar um caminho arbitrário de executável como 'scanner de antivírus' para escaneamento de uploads. Apontando esse caminho para um arquivo malicioso enviado pelo próprio atacante e depois disparando o gatilho de scan (upload de qualquer arquivo em um share), o produto executa o binário indicado — resultando em execução de código no host, com os privilégios do processo que executa o antivírus configurado.

O vetor é puramente de rede, sem autenticação prévia: um cabeçalho Host forjado como 'localhost' em uma requisição HTTP comum é suficiente para a primeira etapa (acesso às páginas de setup). Não há pré-requisito de configuração especial do lado da vítima — pelo contrário, a exposição existe justamente quando TrustedHostIp não foi configurado no web.config, o que parece ser o cenário comum observado. A complexidade técnica é baixa: qualquer cliente HTTP capaz de alterar o cabeçalho Host alcança o fluxo de criação de administrador.

A Mandiant documentou exploração real desde 24 de agosto de 2025 (antes da divulgação pública) por um agente rastreado como UNC6485, contra Triofox na versão 16.4.10317.56372. O indício observado no log HTTP foi uma requisição GET externa para /management/CommitPage.aspx com Referer contendo 'http://localhost/management/AdminAccount.aspx' — evidência de que o Host header havia sido manipulado para completar o fluxo de setup. Após criar a conta administrativa (nomeada 'Cluster Admin' no incidente observado), o ator abusou do recurso de antivírus configurável para executar payloads arbitrários, e na sequência usou PLINK para tunelar RDP externamente e baixou artefatos para C:\WINDOWS\Temp — atividade pós-exploração específica desse incidente, não parte necessária da vulnerabilidade em si.

O resultado final da cadeia completa é execução de código no servidor Triofox com controle administrativo total da aplicação e, dependendo dos privilégios do processo, potencial movimento lateral na rede onde o servidor está integrado (o produto tipicamente conecta com Active Directory, storage de arquivos e SSO corporativo).

A correção do fornecedor é atualizar para Triofox 16.7.10368.56560 ou versão superior — a Mandiant validou que a vulnerabilidade está resolvida nessas versões. Não há indicação de outra flag de configuração que neutralize completamente a falha; o mecanismo defeituoso (comparação de Host header) é parte do código da aplicação e foi corrigido no patch, não é algo que se desative por configuração do administrador.

Como controle compensatório até a atualização, é possível configurar o parâmetro TrustedHostIp no web.config para restringir o fluxo de fallback baseado em IP — mas isso não fecha o buraco principal, já que a checagem de Host == 'localhost' continua tendo precedência incondicional no código vulnerável; um Host header forjado ainda passa direto, independente de TrustedHostIp estar configurado ou não. Um controle mais efetivo, embora não seja solução do fornecedor, é normalizar ou reescrever o cabeçalho Host em qualquer proxy reverso ou balanceador na frente da aplicação, rejeitando ou sobrescrevendo requisições externas que cheguem com Host: localhost (ou qualquer valor de loopback) antes de repassá-las ao Triofox.

Não funciona como mitigação: apenas restringir acesso à porta de gerência via firewall de perímetro sem tratar o cabeçalho Host, pois a exploração ocorre na mesma porta/endpoint usado para acesso normal da WebUI — não é um serviço de administração separado e isolável por porta.

Em logs de acesso HTTP/IIS, procurar por requisições externas para endpoints de setup e administração — AdminDatabase.aspx, AdminAccount.aspx, InitAccount.aspx, CommitPage.aspx — especialmente quando o cabeçalho Referer ou Host contém 'localhost' mas a origem da conexão é um IP externo (nunca deveria acontecer em tráfego legítimo). A Mandiant identificou o incidente justamente por essa anomalia num log IIS. Vale também auditar a criação de contas de administrador nativas fora do fluxo normal de gestão de usuários, e revisar a configuração do recurso de antivírus integrado (caminho do executável de scan) por qualquer valor apontando para diretórios de upload de usuário ou arquivos incomuns.

Atividade pós-exploração observada no incidente documentado — uso de PLINK para tunelamento externo de RDP e artefatos baixados para C:\WINDOWS\Temp — é específica desse ator (UNC6485) e não deve ser tratada como assinatura confiável da vulnerabilidade em si; sua ausência não indica que o sistema não foi comprometido por outro caminho pós-acesso administrativo.