Um único dispositivo comprometido em uma rede Tailscale pode ser usado para obter acesso de administrador a outros servidores que estejam ao seu alcance, segundo uma pesquisadora de segurança que publicou as descobertas nesta semana.
O ataque depende de dois fatores: o Tailscale SSH precisa estar configurado para permitir o encaminhamento de portas, e o invasor já deve controlar um dispositivo autorizado pelas regras de acesso da rede a se conectar ao alvo.
As descobertas foram publicadas em 25 de outubro, em um relatório chamado Tailworm, por Erica Windisch, da Cyberdione Labs. Durante três dias, em um laboratório, Windisch testou a versão 1.104.2 do Tailscale e a versão 0.29.5 do headscale, um servidor auto-hospedado usado por algumas redes para operar o Tailscale no lugar do serviço hospedado pela empresa.
O relatório descreve testes com esses programas, não ataques contra redes reais. Até a publicação, a Tailscale não havia divulgado um comunicado de segurança, atribuído um identificador CVE ao problema nem lançado uma versão corrigida.
A Tailscale se manifestou publicamente. Mike Shaver, vice-presidente de engenharia da empresa, escreveu no Reddit que a Tailscale havia recebido o relatório, já analisava as mesmas áreas com especialistas externos em segurança e identificara problemas que estava trabalhando para corrigir. Shaver afirmou que a empresa ainda avalia quais configurações são afetadas e que “não está recomendando que todos desativem o Tailscale SSH”.
O Tailscale SSH não funciona como um servidor SSH convencional. Em vez de verificar a senha ou a chave de quem se conecta, ele identifica o dispositivo. Uma única regra de acesso determina se esse dispositivo pode abrir uma sessão SSH com um alvo.
Por isso, o ataque não exige senhas ou chaves roubadas. Primeiro, porém, é necessário obter acesso a um dispositivo, algo que, segundo o relatório, pode ocorrer por meios conhecidos, como uma aplicação web vulnerável, um pacote de software adulterado, phishing ou credenciais roubadas. O Tailscale não é responsável por criar esse acesso inicial.
As medidas disponíveis para os administradores dependem de onde a rede é operada. No serviço hospedado da Tailscale, o encaminhamento pode ser desativado em cada regra. Na versão 0.29.5 do headscale, não é possível desativá-lo. Por isso, o relatório recomenda tratar cada autorização de SSH nessa versão como se concedesse acesso de administrador ao alvo.
No laboratório, Windisch demonstrou o problema em etapas. Com o encaminhamento de portas padrão do SSH, uma sessão comum levou o processo do Tailscale, executado com privilégios de administrador, a se conectar a um soquete do sistema que deveria ser acessível apenas por um administrador. Com isso, obteve privilégios de administrador e leu o arquivo de senhas do sistema quase imediatamente, sem precisar de direitos administrativos prévios.
Um segundo método substituiu um soquete pertencente ao administrador por um controlado pelo invasor, permitindo executar comandos diretamente com privilégios de administrador em determinados serviços.
Um terceiro método contornou uma verificação de segurança que deveria limitar os arquivos acessíveis pelo encaminhamento. Para isso, o sistema foi manipulado durante uma condição de corrida entre a verificação do caminho de um arquivo e seu uso. Segundo o relatório, essa sequência foi além no laboratório: capturou uma chave usada para cadastrar novos dispositivos e a utilizou para conectar à rede, como servidor confiável, uma máquina controlada pelo invasor.
Essa última etapa só foi concluída do início ao fim em redes sem o recurso Tailnet Lock do Tailscale. Nas redes que o utilizavam, os segredos necessários foram capturados durante a transmissão, mas a etapa final não foi concluída.
Windisch descreve o resultado geral como “capaz de se propagar como um worm”. No laboratório, um dispositivo comprometido conseguiu se espalhar para todos os dispositivos permitidos pelas regras de acesso, sem senhas, chaves roubadas ou qualquer ação dos usuários, em menos de um segundo por etapa.
Nas palavras do relatório, “a rede em malha transforma um acesso inicial comum em privilégios elevados em toda a frota, à velocidade das máquinas”. Essa propagação foi medida em laboratório e não foi observada em redes reais.
O relatório aponta dois fatores que limitaram a propagação: regras de acesso configuradas como pares individuais de origem e destino, que por si só impediram o avanço nos testes, e chaves de dispositivos vinculadas a componentes de hardware, como TPM ou Secure Enclave.
Alguns pesquisadores que leram o relatório questionaram publicamente a descrição de que o ataque poderia se propagar como um worm, enquanto outros consideraram grave a descoberta de acesso com privilégios de administrador.
O problema no SSH é uma das 11 descobertas do relatório, que também aborda os conectores de aplicações do Tailscale, o recurso Serve, o retransmissor DERP usado na comunicação entre dispositivos e o headscale. Segundo reportagem do The Hacker News, Windisch afirmou que a escalada de privilégios no SSH “é preocupante”, mas que a descoberta sobre o conector de aplicações “pode ter mais impacto para algumas organizações”. Essa descoberta envolve o recurso experimental conn25, que permite a um usuário autorizado enviar tráfego para destinos não aprovados pela equipe de segurança, incluindo o serviço de metadados de um provedor de cloud, capaz de fornecer credenciais de servidores.
Todas as descobertas se baseiam apenas no relatório de Windisch. Nenhum outro pesquisador as reproduziu publicamente, e a Tailscale não confirmou as alegações técnicas específicas. Windisch afirmou que o código de prova de conceito por trás das descobertas não é público e que o forneceu apenas ao contato de segurança da Tailscale.
Windisch descreveu a divulgação como “reportada, mas não coordenada” em uma publicação no Y Combinator Hacker News. Pelo menos um comentarista do site considerou irresponsável publicar as informações sem antes comunicá-las à Tailscale. Segundo reportagem do The Hacker News, Windisch afirmou que havia enviado uma cópia do relatório e o código de prova de conceito à empresa antes da publicação, encaminhando o material ao contato de segurança no sábado anterior. Ela também disse que já havia levantado preocupações sobre a arquitetura do Tailscale com o diretor-executivo da empresa e publicado um hash de arquivo, além de recomendar que os usuários desativassem o Tailscale SSH.
O relatório é o mais recente de uma série de problemas na mesma área do Tailscale. No início de 2026, a empresa corrigiu várias falhas no Tailscale SSH e no tratamento de soquetes do servidor, incluindo uma que permitia que o encaminhamento de soquetes Unix via SSH alcançasse um soquete privilegiado. A correção foi lançada na versão 1.98.9.
O que fazer agora
Como ainda não há um patch, as medidas disponíveis envolvem alterar a configuração do Tailscale SSH e de recursos relacionados. O relatório e as recomendações da própria Tailscale coincidem em boa parte das orientações.
- Revise as regras de acesso do Tailscale SSH. Configure pares individuais de origem e destino, especificando um dispositivo e um alvo, e remova regras amplas que concedam acesso com base em identidade ou etiqueta. Segundo o relatório, regras individuais por par foram a única medida que impediu a propagação nos testes.
- Desative o encaminhamento de portas SSH sempre que possível. No serviço hospedado da Tailscale, essa opção pode ser configurada em cada regra. Na versão 0.29.5 do headscale, não é possível desativá-la. Portanto, trate cada autorização de SSH como se concedesse acesso de administrador ao alvo.
- Remova as permissões de conector de aplicações dos dispositivos que não precisam delas.
- Remova qualquer encaminhamento do recurso Serve do Tailscale que aponte para um soquete Unix.
- Ative a expiração das chaves dos nós para impedir que uma chave de dispositivo roubada permaneça válida indefinidamente.
- Se um dispositivo for comprometido, exclua-o no plano de controle. Reinstalar o sistema da máquina não revoga as chaves que o invasor talvez já tenha copiado.
A Tailscale também recomenda ativar o modo de verificação do SSH, que acrescenta uma etapa de autenticação antes do início da sessão, e habilitar as atualizações automáticas. O modo de verificação não corrige a escalada de privilégios, apenas acrescenta uma barreira antes dela.
Publicidade
Nossa audiência é formada por analistas, pentesters, decisores e entusiastas que consomem nossas notícias todo dia pelo Site, Newsletter e Instagram. Fale com quem realmente importa para o seu negócio. Anuncie aqui. Saiba mais...