Falha no Headscale 0.29.5 permite acesso root em redes Tailscale

Segurança

Vulnerabilidade no Headscale 0.29.5 expõe redes Tailscale a riscos de acesso root não autorizado.

Leia também: BlackX explora falha BlackLotus e atinge redes diplomáticas hoje

Vulnerabilidades graves no Tailscale SSH permitem que um invasor com controle de um dispositivo autorizado escale privilégios a root em outros servidores da rede quando o encaminhamento de portas está habilitado, segundo relatório publicado hoje pela pesquisadora Erica Windisch, da Cyberdione Labs. As falhas também afetam redes que usam o Headscale na versão 0.29.5.

Como as falhas no Tailscale podem permitir acesso root em outros servidores?

O relatório, batizado de Tailworm, descreve que o ataque aproveita o modo como o Tailscale SSH funciona: em vez de autenticar usuários por senha ou chave, o sistema identifica o dispositivo, e uma única regra de acesso decide se aquela máquina pode abrir sessão SSH no alvo. Assim, uma vez que o invasor já esteja dentro de um dispositivo autorizado, não precisa roubar credenciais para avançar.

Nos testes em laboratório, Windisch usou o Tailscale versão 1.104.2 e o Headscale 0.29.5. A partir de um dispositivo comprometido, ela configurou um encaminhamento de porta SSH aparentemente comum. Esse túnel levou o processo do Tailscale, que roda com privilégios de root, a se conectar a sockets do sistema que deveriam ser acessíveis apenas pelo administrador. Em poucos instantes, o ataque conseguiu privilégios de root e leu arquivos sensíveis, como o arquivo de senhas do sistema, sem exigir direitos de administrador no ponto inicial.

Em um segundo método, a pesquisadora substituiu um socket pertencente ao root por um socket controlado pelo invasor. Com isso, foi possível executar comandos com privilégios elevados diretamente contra determinados serviços. Um terceiro vetor explorou uma condição de corrida: entre a checagem do caminho de um arquivo e o momento em que ele é efetivamente usado, o atacante consegue trocar o alvo, driblando a proteção pensada para limitar o que o encaminhamento de portas pode alcançar.

Essa cadeia de ataque foi além: em laboratório, o código conseguiu capturar chaves usadas para inscrever novos dispositivos na rede e, com elas, adicionar uma máquina do invasor como se fosse um servidor confiável. Esse último passo só se completou em ambientes sem o recurso Tailnet Lock ativado; onde ele está ligado, os segredos chegaram a ser interceptados, mas a etapa final de inclusão do dispositivo malicioso não se concretizou.

Windisch classifica o resultado como “wormable”, ou seja, com potencial de se comportar como um verme digital capaz de se espalhar na rede. Segundo a pesquisadora, “o mesh converte uma única brecha em acesso privilegiado a toda a frota na velocidade das máquinas”, desde que as regras de acesso permitam conexões em cadeia entre os dispositivos-alvo. O cenário, porém, foi demonstrado apenas em laboratório, não em redes de produção.

O que é necessário para explorar as falhas de SSH no Tailscale?

Para que o ataque funcione, dois pré-requisitos precisam estar presentes: o Tailscale SSH configurado com encaminhamento de portas habilitado e um invasor que já tenha tomado o controle de um dispositivo autorizado a se conectar ao servidor-alvo.

Esse primeiro acesso, reforça o relatório, não é causado pelo Tailscale em si: ele pode vir de uma aplicação web vulnerável, de um pacote de software comprometido, de phishing ou de credenciais roubadas. Uma vez com essa “primeira pegada” em um laptop, servidor ou container autorizado, o atacante passa a explorar a forma como o Tailscale SSH encaminha conexões e como seu processo em nível de root interage com sockets e arquivos do sistema.

O caminho de exploração é facilitado pelo modelo de confiança baseado em dispositivo. Como o servidor de destino não pede senhas nem chaves do usuário, basta que o equipamento comprometido esteja na lista de máquinas permitidas para que o Tailscale aceite a sessão e permita o uso de port forwarding.

Headscale aumenta o risco em algumas redes

O impacto é diferente a depender de como a rede Tailscale é operada. No serviço hospedado pela própria Tailscale, o encaminhamento de portas pode ser desligado por regra de acesso, reduzindo a superfície de ataque. Já no Headscale 0.29.5, servidor open source usado por empresas que preferem rodar a infraestrutura por conta própria, o forwarding não pode ser desativado, o que, segundo o relatório, faz com que cada concessão de SSH deva ser encarada, na prática, como um acesso root potencial ao alvo.

Além da escalada de privilégios via SSH, Windisch identificou outras 11 vulnerabilidades em recursos complementares, como app connectors, a função serve, o relay DERP e o próprio Headscale. Em conversa com outro veículo especializado, ela afirmou que “a escalada de privilégios SSH é preocupante”, mas ponderou que “a falha do app connector pode ser mais impactante para algumas organizações”.

Entre essas falhas adicionais está um problema no recurso experimental de app connector conhecido como conn25, que, de acordo com o relatório, pode permitir que um usuário autorizado envie tráfego para serviços que não foram aprovados pela equipe de segurança — incluindo o serviço de metadados de provedores de nuvem, frequentemente usado para distribuir credenciais de servidores.

Entenda o contexto

Os testes descritos por Windisch foram conduzidos em ambiente de laboratório, ao longo de três dias, sobre a versão 1.104.2 do Tailscale e o Headscale 0.29.5, e não em redes reais de clientes. Até agora, não há relatos públicos de exploração das brechas fora desse cenário controlado, nem outros grupos de pesquisa disseram ter reproduzido integralmente os ataques descritos.

O código de prova de conceito desenvolvido para os experimentos não foi liberado publicamente. Segundo a pesquisadora, ele foi compartilhado apenas com o contato de segurança da Tailscale, justamente para limitar a possibilidade de uso imediato por criminosos enquanto não há correções disponíveis.

A divulgação do Tailworm também reacende discussões sobre o modelo de arquitetura adotado por ferramentas de rede em malha (mesh) com recursos de SSH integrado. Quando uma mesma camada de software concentra tanto a criação de túneis entre máquinas quanto a autenticação de dispositivos e o repasse de tráfego a processos privilegiados, qualquer falha em um dos pontos pode ter efeito em cascata.

Resposta da Tailscale e orientações iniciais

A Tailscale reconhece publicamente ter recebido o relatório de Windisch e afirma que já vinha investigando a mesma área de código com consultores externos. Em manifestação recente, o vice-presidente de engenharia da empresa, Mike Shaver, disse que a equipe está trabalhando em correções e ainda avalia com precisão quais cenários de configuração são afetados.

Mesmo diante da gravidade das descobertas, Shaver afirmou que, por ora, “não estamos recomendando que todos desativem o Tailscale SSH”. A companhia vem sugerindo medidas de mitigação, como endurecer as regras de acesso, limitar o uso de encaminhamento de portas, adotar o modo de verificação adicional no login SSH (check mode) e ativar atualizações automáticas. O próprio check mode, porém, não elimina a escalada de privilégios; ele apenas acrescenta mais uma barreira antes de a sessão ser estabelecida.

No caso do Headscale, a impossibilidade de desligar o port forwarding na versão 0.29.5 torna mais difícil aplicar uma mitigação equivalente. O relatório recomenda que administradores dessas redes avaliem cada permissão SSH como uma porta de acesso potencialmente total ao sistema de destino, até que uma atualização permita um controle mais granular.

Até o momento, não há boletim de segurança oficial com numeração de vulnerabilidades nem uma versão corrigida anunciada publicamente. Em redes sensíveis, a recomendação prática é revisar imediatamente as regras de acesso, reduzir onde possível o uso de SSH via Tailscale, ativar o Tailnet Lock para proteger o processo de inscrição de dispositivos e monitorar logs em busca de uso incomum de encaminhamento de portas.