Unauthenticated credential leak and business logic flaw in Kaseya VSA <= v9.5.6
Corrija agora. Ela está sob exploração confirmada pelo CISA e tem exploit funcional público.
Apply updates per vendor instructions.
Resumo
Kaseya VSA on-premise até 9.5.6 expõe credenciais de agente através da página de download não autenticada dl.asp, e o próprio dl.asp aceita essas credenciais via GET para devolver um cookie sessionId válido em contextos que não deveriam aceitar autenticação de agente. Foi um dos elementos usados pelo REvil no ataque de cadeia de suprimentos de julho de 2021 contra clientes de MSPs que usam Kaseya VSA, atingindo cerca de 1.500 empresas em 17 países. O CVSS 10.0 reflete o pior caso (servidor VSA on-premise exposto à internet, cenário comum entre MSPs na época), não uma condição universal — a falha depende de o painel dl.asp estar acessível externamente.
Detalhamento técnico
A vulnerabilidade combina um problema de exposição de credenciais (CWE-522, conforme classificado pela CISA no KEV) com uma falha de lógica de negócio. A página /dl.asp, servida sem autenticação por padrão em instalações on-premise do VSA, distribui o instalador do cliente Windows. Ao instalar esse cliente, é gerado localmente o arquivo KaseyaD.ini (em C:\Program Files (x86)\Kaseya\XXXXXXXXXX\), contendo um Agent_Guid e um AgentPassword em texto acessível.
O problema de lógica de negócio está em como esse par de credenciais é usado: o mesmo endpoint dl.asp aceita Agent_Guid e AgentPassword via parâmetros de GET (un e pw) e, ao validá-los, devolve um cookie sessionId. Esse cookie foi projetado para autorizar apenas operações do próprio agente, mas o servidor não distinguia adequadamente esse escopo — o sessionId obtido por credenciais de agente podia ser reaproveitado em serviços administrativos do VSA não destinados a agentes, criando um bypass de autenticação por escalonamento de contexto.
Aceitar credenciais via GET agrava o problema: parâmetros de URL ficam expostos em logs de servidor, histórico de navegador, proxies e cabeçalhos Referer, ampliando a superfície de vazamento além do vetor principal.
A DIVD (Dutch Institute for Vulnerability Disclosure), que descobriu e reportou a falha, optou por divulgação limitada mesmo após o patch, por considerar os detalhes completos perigosos demais para publicar enquanto a base instalada não estivesse suficientemente atualizada — por isso a cadeia de exploração completa usada pelo REvil não foi detalhada publicamente por eles.
Como é explorada
Pré-requisito real: acesso de rede ao endpoint dl.asp de uma instância VSA on-premise exposta (a DIVD identificou mais de 2.200 instâncias acessíveis pela internet antes do incidente, número que caiu para menos de 140 em 48 horas após a resposta coordenada). Não é necessário ser cliente Kaseya nem ter conta — o download do instalador é público por design.
O mecanismo de abuso: o atacante baixa e instala o cliente Windows disponível em dl.asp, extrai Agent_Guid e AgentPassword do KaseyaD.ini gerado localmente, e reenvia essas credenciais ao mesmo dl.asp via GET para obter um sessionId. Esse cookie, que deveria valer apenas para operações de agente, era aceito também em rotas administrativas — permitindo bypass de autenticação da interface de gestão.
No ataque de julho de 2021, essa falha foi combinada com pelo menos uma outra vulnerabilidade (não detalhada publicamente pela DIVD, que declarou que 'uma das duas vulnerabilidades usadas no ataque foi uma que já havíamos relatado') para acessar a interface administrativa do VSA e empurrar, via o próprio mecanismo legítimo de procedimentos do VSA, uma rotina maliciosa ("Kaseya VSA Agent Hot-fix") para todos os agentes gerenciados. Essa rotina desativava proteções do Windows Defender e baixava um payload (agent.crt, decodificado via certutil para agent.exe) que fazia DLL side-loading do encryptor REvil (mpsvc.dll) disfarçado de MsMpEng.exe. O resultado final documentado foi ransomware distribuído em massa a clientes finais de MSPs, sem qualquer interação do usuário além de o VSA estar acessível e não corrigido — a exploração ocorreu antes que clientes on-premise pudessem aplicar o patch, forçando a Kaseya a desligar seu SaaS e recomendar o desligamento de todos os servidores VSA on-premise em 2 de julho de 2021.
Versões
Como se proteger
A correção definitiva é atualizar para a versão 9.5.7, que resolveu CVE-2021-30116 e CVE-2021-30119 (disponibilizada no SaaS em 26 de junho de 2021, com patch on-premise associado ao mesmo número de versão conforme a descrição oficial 'before 9.5.7'). Ela deve ser aplicada em sequência às correções anteriores: 9.5.5 (10 de abril de 2021, resolveu CVE-2021-30118) e 9.5.6 (8 de maio de 2021, resolveu CVE-2021-30117, CVE-2021-30121 e CVE-2021-30201) — ambientes que pararam em versões intermediárias seguem vulneráveis a esta CVE especificamente.
Se a atualização imediata não for possível, o paliativo real é tirar a interface administrativa e o endpoint dl.asp do VSA do acesso público à internet, restringindo-o via VPN, firewall dedicado ou allowlist de IPs — foi exatamente essa a orientação de emergência da CISA/FBI durante o incidente, junto com habilitar MFA em todas as contas administrativas e revisar allowlists de comunicação para as capacidades de RMM. Esse controle tem custo operacional real: MSPs que dependem de acesso remoto amplo ao VSA para gerenciar clientes perdem conveniência ao restringir origem de acesso.
O que não funciona como mitigação: proteger apenas os endpoints gerenciados (antivírus, EDR nos agentes) não impede o vetor, porque o compromisso ocorre no servidor VSA e se propaga por um canal de gerenciamento legítimo e confiável para os agentes — a superfície a proteger é o próprio painel administrativo exposto, não os terminais individuais.
Como detectar
Indicadores de comprometimento documentados pela Huntress Labs durante o ataque de julho de 2021: requisições GET e POST usando o user-agent curl/7.69.1 originadas de um conjunto específico de IPs (AWS, DigitalOcean, Google Cloud, Sapioterra) registradas nos logs KaseyaEdgeServices (%ProgramData%\Kaseya\Log\KaseyaEdgeServices\KaseyaEdgeServices-YYYY-MM-DDTHH-MM-SSZ.log); upload dos arquivos agent.crt e Screenshot.jpg registrado em KUpload.log (que os atacantes podem ter apagado ou criptografado); presença de um procedimento VSA chamado 'Kaseya VSA Agent Hot-fix' e outro 'Archive and Purge Logs'; e a chave de registro HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\BlackLivesMatter nos endpoints comprometidos, além dos hashes MD5 de agent.crt, agent.exe, cert.exe e mpsvc.dll listados pela SecPod/Huntress. Esses IOCs são específicos da campanha REvil de 2021 e os IPs de origem estão obsoletos para detecção atual.
Para a exploração isolada da falha em si (sem o payload de ransomware), o sinal a procurar é requisições GET a /dl.asp contendo parâmetros un e pw seguidos de reautenticações repetidas com credenciais de agente vindas de IPs fora do range esperado de endpoints legítimos — mas como esse é exatamente o padrão de tráfego normal de um agente se autenticando, não há um sinal confiável e específico sem uma baseline prévia do comportamento normal de autenticação de agentes na instância.