Tailscale corrige falhas no SSH que transformam um dispositivo comprometido em root nos restantes servidores

A Tailscale lançou a versão 1.104.4 do seu cliente para fechar um conjunto de fragilidades no Tailscale SSH, o servidor SSH integrado no agente de VPN em malha. Num nó Linux sem a correção, um atacante que já controle um dispositivo de confiança para a política da rede podia abusar do reencaminhamento SSH para alcançar recursos reservados ao root noutra máquina, e em laboratório isso bastou para obter uma shell de root.

O que aconteceu

O Tailscale SSH não autentica com palavras-passe nem chaves. Decide quem pode iniciar sessão a partir da identidade do dispositivo que se liga e das regras do ficheiro de políticas da tailnet. O desenho é cómodo, mas significa também que um intruso não precisa de credenciais roubadas. Um ponto de apoio em qualquer dispositivo a que a política já permita abrir uma sessão SSH, com reencaminhamento autorizado nessa regra, é o único requisito.

O ponto fraco é o reencaminhamento de sockets. O daemon tailscaled corre como root e, quando uma sessão SSH autorizada lhe pedia para reencaminhar uma ligação para um socket Unix no servidor, o daemon validava o caminho pedido e executava depois o reencaminhamento com os seus próprios privilégios de root. Uma condição de corrida entre a verificação e a utilização permitia à sessão substituir o caminho por outro depois de a validação passar, o que anulava a salvaguarda que devia limitar os sockets alcançáveis.

Nos testes, reencaminhar para o socket de controlo do Docker no nó alvo produziu uma shell de root e acesso de leitura ao ficheiro shadow de palavras-passe do sistema, sem qualquer direito administrativo nessa máquina. O aviso da Tailscale descreve o impacto de forma mais restrita, como acesso a sockets exclusivos do root, tais como o socket do Docker ou a API local do tailscaled, mas qualquer dos resultados equivale ao controlo total do nó.

A empresa sublinha que as falhas não permitem a um desconhecido sem autenticação ligar-se a servidores Tailscale SSH arbitrários. O alcance é delimitado pela política: o atacante só chega às máquinas a que a política já deixa o dispositivo comprometido aceder por SSH. O servidor SSH só é incluído na compilação para Linux e na compilação de código aberto para macOS, embora o dispositivo atacante possa correr qualquer plataforma.

A versão 1.104.4 altera o servidor para executar o reencaminhamento como o utilizador autenticado e não como root, e apoia-se nas permissões de ficheiro normais do sistema operativo em vez da antiga verificação de caminho. O lançamento cobre quatro boletins de segurança da Tailscale:

• TS-2026-014: as fragilidades de reencaminhamento de sockets descritas acima, que deixam uma sessão autorizada alcançar sockets exclusivos do root.
• TS-2026-015: uma forma de uma sessão SSH autorizada esgotar a memória do servidor e fazer cair o tailscaled, cortando toda a conectividade Tailscale nesse nó.
• TS-2026-016: uma falha no tailscale serve em que um reencaminhamento para um socket Unix podia alcançar a API local do tailscaled e assumir o controlo remoto do nó, além de um problema relacionado de substituição de socket.
• TS-2026-017: com TLS serve e dois ou mais mounts configurados, um pedido podia receber os cabeçalhos de permissões de outro mount.

À data de publicação, os boletins não têm identificadores CVE nem pontuações de severidade, e nenhum indica a versão afetada mais antiga. A Tailscale diz ter reproduzido os principais problemas de escalada de privilégios, classifica-os como sérios e continua a apurar que configurações estão afetadas.

Porque é que importa

A divulgação gerou uma disputa em torno da palavra "wormable". A investigadora que reportou os problemas demonstrou uma cadeia em que um único dispositivo comprometido se propagava a todos os nós permitidos pela política, sem palavras-passe, sem chaves roubadas e sem interação do utilizador, com cada salto a demorar bem menos de 1 s. A Tailscale rejeita esse enquadramento: não se trata de malware que se replica sozinho, defende a empresa, mas de movimento lateral confinado às ligações que a política já autoriza. Ambos os lados podem ter razão ao mesmo tempo. Em muitas tailnets reais, a política é tão permissiva que "todos os dispositivos que a política permite" são simplesmente todos os dispositivos.

Dois pontos merecem atenção redobrada:

• Aplicar a correção não expulsa um atacante que já está dentro. Uma chave de dispositivo roubada continua válida até o nó ser eliminado do plano de controlo. Reinstalar a máquina não a revoga, e os avisos da Tailscale não abordam este cenário.
• O headscale auto-alojado está em pior situação. No headscale, o reencaminhamento SSH é concedido em todas as sessões aceites e não pode ser desligado na política, pelo que cada autorização SSH aí deve ser tratada como uma autorização de root. A versão mais recente do headscale, a 0.29.5 de 13 de outubro, não corrige os problemas reportados.

A divulgação foi reportada, mas não coordenada. A Tailscale afirma ter recebido o relatório na manhã de sábado, 24 de outubro, cerca de duas horas antes da sua publicação, e que os seus engenheiros já estavam a analisar a mesma zona do código. Nenhuma das partes tem conhecimento de exploração em ataques reais, e o código de prova de conceito foi partilhado apenas com a equipa de segurança da Tailscale. Uma falha distinta no mesmo caminho de reencaminhamento de sockets Unix tinha sido corrigida em junho, na versão 1.98.9, e o relatório abrangeu também os conectores de aplicações da Tailscale e as funcionalidades serve e funnel. A descoberta nos conectores está no conn25, uma funcionalidade experimental ainda não lançada, pelo que os conectores que os clientes usam hoje não são afetados. Das cinco descobertas sobre serve e funnel, a Tailscale corrigiu três e considera que as outras duas funcionam como previsto.

O que fazer

1. Atualize todos os nós Linux e macOS de código aberto para a 1.104.4 ou posterior, começando pelos servidores que expõem o socket do Docker ou correm outros serviços pertencentes ao root.
2. Se um nó ainda não puder ser atualizado, defina TS_SSH_DISABLE_FORWARDING=1 no ambiente do serviço tailscaled e reinicie o serviço. Isto desativa o reencaminhamento sem desligar o Tailscale SSH e bloqueia várias das descobertas mais graves.
3. Aperte a secção SSH do ficheiro de políticas. Conceda SSH apenas aos utilizadores e dispositivos que realmente precisam e prefira pares explícitos dispositivo-a-dispositivo em vez de regras amplas por grupos. As regras por pares foram um dos dois controlos que travaram a cadeia de movimento lateral nos testes.
4. Ligue as chaves de dispositivo ao hardware, por exemplo a um TPM, onde a plataforma o permita, para que uma identidade roubada não possa ser reutilizada a partir de outro sítio. Foi o outro controlo que resistiu.
5. Não conte com o modo check do SSH como correção. A reautenticação protege o início da sessão; o abuso do reencaminhamento acontece dentro de uma sessão já aprovada. Ainda assim, vale a pena ativar o modo check nos sistemas sensíveis.
6. Se suspeitar que um nó foi comprometido, elimine-o do plano de controlo e volte a inscrevê-lo. Só aplicar a correção ou reinstalar deixa a chave utilizável.
7. Os operadores de headscale devem assumir que cada autorização SSH equivale a root até surgir uma versão corrigida, e reduzir essas autorizações em conformidade.

Fragilidades como estas raramente aparecem numa análise de portas: a exposição vive na política de acesso e naquilo que uma máquina de confiança consegue alcançar a partir de outra. Um teste de penetração interno que parta de um único nó assumido como comprometido e mapeie até onde consegue chegar é a forma mais fiável de saber se a sua tailnet conteria o raio de impacto ou entregaria as chaves. Esse tipo de exercício de movimento lateral faz parte do serviço de penetration testing que a nossa equipa realiza.