Vulnerabilidade TunnelVision (CVE 2024-3661) no Tailscale

Após a divulgação da vulnerabilidade TunnelVision (CVE 2024-3661) pela Leviathan Security, muitos utilizadores questionaram se esta afeta o Tailscale e de que forma. A resposta curta é: depende. Embora não consideremos que o TunnelVision represente uma grande ameaça para a maioria dos utilizadores do Tailscale, alguns podem ser afectados. A resposta mais detalhada depende de vários factores, incluindo a forma como utiliza o Tailscale, o ambiente em que está inserido e o sistema operativo que está a utilizar.

A Leviathan Security não avisou previamente o Tailscale antes da divulgação pública da vulnerabilidade no início deste mês.¹ Este post resume várias semanas de testes extensivos realizados desde então.

Contextualização

Os sistemas de VPN, redes sobrepostas e redes em malha têm diferentes casos de uso, cada um com modelos de ameaça e objectivos de segurança e funcionalidade distintos. Dois dos casos de uso mais comuns são:

  1. Aceder a serviços numa rede privada, como numa rede empresarial ou doméstica.
  2. Proteger contra escutas ou adulterações, considerando tipicamente apenas atacantes na LAN (por exemplo, Wi-Fi público), embora atacantes possam influenciar qualquer router ou rede entre o seu computador e o par remoto.

A vulnerabilidade TunnelVision afecta principalmente o segundo caso de uso.

O Tailscale pode ser utilizado para ambos os casos de uso mencionados. A utilização mais directa do Tailscale é o acesso a serviços em redes privadas. No entanto, funcionalidades como routers de sub-rede, nós de saída, conectores de aplicações e integração com Mullvad complicam a análise do impacto do TunnelVision no Tailscale.

Impacto por Plataforma e Tipo de Tráfego

  • Linux: A gestão de rotas do Tailscale substitui a rota fornecida pelo DHCP, prevenindo o ataque.
  • Android: O cliente DHCP do Android não implementa a opção 121 do DHCP, necessária para o ataque, tornando o Tailscale no Android não vulnerável.
  • Windows: Parcialmente afectado. Ataques contra IPs CGNAT dos pares do Tailscale não são eficazes e o tráfego é correctamente encaminhado pela interface WireGuard. Ataques contra IPs não-Tailscale, com os Nós de Saída activados, fazem com que os pacotes sejam descartados, criando uma condição de negação de serviço (DoS).
  • iOS e macOS: Mais afectados, pois as rotas fornecidas pelo DHCP têm precedência sobre as fornecidas pelo Tailscale. Um atacante pode se fazer passar por pares do tailnet e nós de saída, contornando a interface WireGuard. No entanto, não é possível realizar um ataque Man-in-the-Middle (MitM) no tráfego entre nós legítimos do tailnet, pois o nó receptor espera uma conexão completa do WireGuard.
  • tvOS: Não conseguimos reproduzir o ataque, mas devido ao acesso limitado aos internos do sistema no tvOS, não podemos verificar se a opção 121 do DHCP é totalmente propagada para a tabela de rotas do sistema.

Actualmente, não existe uma solução para o problema no macOS ou iOS.

Recomendações

  • Verificação Manual de Rotas Fornecidas pelo DHCP: No macOS, pode-se utilizar o comando ipconfig getsummary en0 para verificar se algum endereço ou intervalo de IP CGNAT, Tailscale ou outros foram adicionados pelo seu servidor DHCP para a interface en0. Na saída, procure por uma linha iniciada por classless_static_route.
  • Utilização de Protocolos de Aplicação Seguros: Ao utilizar nós de saída do Tailscale, recomendamos fortemente o uso de sites HTTPS e a não transmissão de dados sensíveis via HTTP simples. A maioria dos navegadores modernos permite impor um requisito HTTPS. Apesar de, idealmente, os nós de saída protegerem o tráfego da Internet da LAN local e do ISP a montante, este tráfego passa por muitos routers, cada um capaz de monitorizar o tráfego não encriptado. Protocolos encriptados como HTTPS, DNS encriptado, SSH, entre outros, são práticas recomendadas para o tráfego na Internet.
  • Routers de Sub-Rede e Conectores de Aplicações: A mesma recomendação de utilização de protocolos seguros aplica-se. As aplicações ou serviços devem implementar HTTPS no lado de recepção e, onde possível, configurar listas de IPs permitidos que incluam o IP de saída do seu nó de Conector de Aplicações.

Estas medidas ajudam a mitigar os riscos associados à vulnerabilidade TunnelVision enquanto trabalhamos em soluções permanentes.

Deixe um comentário