TunnelCrack contra TunnelVision: o que cada um quebra de facto

Dois nomes de investigação são usados indistintamente para qualquer tráfego VPN que sai do túnel, mas os mecanismos por trás deles não são os mesmos. O TunnelCrack descreve duas famílias de exceções de encaminhamento; o TunnelVision descreve uma rota fornecida por DHCP no equipamento terminal. Nenhum dos dois quebra a cifra, e nenhum dos dois lhe diz o que faz hoje uma compilação concreta do cliente. Cinco verificações separam os mecanismos do título.

Primeiro passo: nomeie o mecanismo que está a rever

A divulgação do TunnelCrack de agosto de 2023 descreve duas famílias de ataques. No caso da rede local, o tráfego que o cliente considera pertencer à rede local recebe uma exceção de acesso local e sai do túnel. No caso do endereço do servidor, a rota de que o cliente precisa para chegar ao próprio servidor VPN fica fora do túnel, e um adversário que controla esse endereço pode explorar a exceção.

O TunnelVision é um relatório separado sobre rotas estáticas sem classe entregues por DHCP. Um servidor DHCP malicioso pode dar ao equipamento terminal rotas que mudam o caminho do tráfego, incluindo o caminho para o servidor VPN. O relatório reconhece trabalho anterior sobre efeitos de encaminhamento relacionados, o que recorda que o mecanismo subjacente é mais antigo do que o nome.

Mantenha os nomes ligados aos seus mecanismos. Aplicar uma correção a um porque o outro está nas notícias é a forma como uma revisão produz movimento sem cobertura.

Segundo passo: veja a exceção de acesso local

A maioria dos clientes isenta o tráfego da rede local para que impressoras, transmissão de ecrã e partilha de ficheiros continuem a funcionar enquanto o túnel está ativo. Essa exceção é uma decisão de política com um custo de segurança: um adversário na mesma rede pode apresentar-se como anfitrião local, e o tráfego que chega até ele nunca entrou no túnel.

Pergunte se o perfil implementado precisa mesmo da exceção. Uma equipa remota que nunca usa a descoberta local pode muitas vezes desativá-la, e os serviços locais restantes podem ser alcançados por um caminho documentado. Onde a exceção é necessária, indique que destinos cobre em vez de a descrever como tráfego local.

A verificação é uma questão de configuração, não uma captura de pacotes. Leia a definição do perfil e a documentação do cliente para a compilação que implementa, porque o valor predefinido difere entre produtos e entre versões do mesmo produto. Escreva a resposta ao lado do perfil, para que o revisor seguinte não tenha de a deduzir do comportamento. Uma exceção que ninguém documentou é uma exceção que ninguém revê.

Terceiro passo: veja como se aprende o endereço do servidor

O cliente tem de chegar ao servidor VPN antes de existir qualquer túnel, por isso esse destino é encaminhado fora do túnel por conceção. Se o endereço for aprendido a partir de um nome, o passo de resolução faz parte do caminho de confiança, e um adversário que consiga responder a essa consulta pode apontar o cliente para um anfitrião que controla.

Fixar o endereço, usar um certificado verificado com o nome correto e recusar recuar para um servidor não verificado reduzem todos a exposição. Nenhum deles elimina a necessidade de chegar ao servidor fora do túnel; mudam quem pode responder por esse endereço.

resolvectl query vpn.lab.example
ip route get 198.51.100.24
ip rule show

A consulta de rota mostra a interface que o cliente usaria para o endereço do servidor, e essa é a exceção em forma concreta. Se essa consulta devolver a interface do túnel, o cliente não consegue sequer estabelecer o túnel, por isso espera-se uma rota externa e a questão é apenas como é escolhido o seu destino.

Quarto passo: veja as rotas fornecidas por DHCP

As rotas estáticas sem classe permitem que um servidor DHCP distribua entradas da tabela de encaminhamento, e o equipamento terminal aceita-as normalmente sem perguntar. Numa rede onde um adversário consegue responder ao DHCP mais depressa do que o servidor legítimo, essas entradas podem redirecionar tráfego que o utilizador julga estar dentro do túnel.

Compare as rotas no equipamento terminal com as rotas que espera. Uma rota predefinida ou um prefixo largo que aponta para o gateway local enquanto o túnel está ativo é a assinatura que merece investigação, e é visível sem qualquer tráfego de ataque.

ip route show table all
ip route get 203.0.113.55
nmcli -g ipv4.ignore-auto-routes con show "Wired connection 1"

A última definição é o controlo do lado do equipamento terminal que muitos clientes e plataformas expõem de alguma forma: ignorar as rotas fornecidas pela rede. Desativar a aceitação automática de rotas é um compromisso, porque também desativa o encaminhamento dividido legítimo de um servidor DHCP empresarial, por isso decida por classe de rede e não globalmente.

Quinto passo: separe o aviso da compilação atual

Um ataque publicado descreve comportamento observado em versões concretas do cliente num momento concreto. Não estabelece que o portátil à sua frente esteja afetado, nem estabelece que esteja corrigido. Ambas as afirmações exigem o número de compilação real e o aviso atual do fornecedor.

Registe a versão do cliente, a plataforma, as definições do perfil que governam as exceções acima e a data em que verificou. Esse registo envelhece com honestidade, ao passo que uma nota a dizer que a VPN foi corrigida por causa do TunnelCrack não envelhece com honestidade. Releia-o sempre que o cliente for atualizado, porque um valor predefinido do perfil pode mudar sob uma versão que não tocou.

Quando validar a sério, use um plano aprovado contra o seu próprio equipamento terminal e um destino inofensivo. Reproduzir o ataque contra outros utilizadores numa rede partilhada não é um teste, e desativar a verificação de pares ou a cifra da aplicação para facilitar uma observação remove a proteção que tentava medir.

Por fim, mantenha a proteção ao nível da aplicação na imagem. Uma exceção de encaminhamento pode expor tráfego que o túnel teria transportado, e o TLS da aplicação continua a proteger esse tráfego de ponta a ponta. As duas camadas falham de forma independente, e é por isso que um canal de controlo ligado não é prova de que cada fluxo seguiu o caminho previsto.