Pesquisadores desenvolveram um ataque contra quase todas as aplicações de rede privada virtual que as obriga a enviar e receber parte ou todo o tráfego fora do túnel criptografado projetado para protegê-lo de espionagem ou adulteração.
O TunnelVision, como os pesquisadores chamaram o ataque, praticamente nega todo o propósito e ponto de venda das VPNs, que é encapsular o tráfego de Internet de entrada e saída em um túnel criptografado e ocultar o endereço IP do usuário. Os pesquisadores acreditam que isso afeta todas as aplicações de VPN quando estão conectadas a uma rede hostil e que não existem formas de prevenir tais ataques, exceto quando a VPN do usuário está em execução no Linux ou no Android. Eles também afirmaram que sua técnica de ataque pode ter sido possível desde 2002 e pode já ter sido descoberta e utilizada desde então.
O efeito do TunnelVision é que “o tráfego da vítima agora está desmascarado e está sendo roteado diretamente pelo atacante”, explicou uma demonstração em vídeo. “O atacante pode ler, descartar ou modificar o tráfego vazado e a vítima mantém sua conexão tanto com a VPN quanto com a Internet”.
O ataque funciona manipulando o servidor DHCP que aloca endereços IP para dispositivos que tentam se conectar à rede local. Uma configuração conhecida como opção 121 permite que o servidor DHCP substitua as regras de roteamento padrão que enviam o tráfego da VPN por um endereço IP local que inicia o túnel criptografado. Ao utilizar a opção 121 para rotear o tráfego da VPN através do servidor DHCP, o ataque desvia os dados para o próprio servidor DHCP. Pesquisadores da Leviathan Security explicaram:
“Nossa técnica é rodar um servidor DHCP na mesma rede que um usuário de VPN direcionado e também configurar nossa configuração DHCP para usar a si mesmo como gateway. Quando o tráfego atinge nosso gateway, usamos regras de encaminhamento de tráfego no servidor DHCP para passar o tráfego para um gateway legítimo enquanto o espionamos.
Utilizamos a opção 121 do DHCP para configurar uma rota na tabela de roteamento do usuário da VPN. A rota que configuramos é arbitrária e também podemos configurar várias rotas, se necessário. Ao empurrar rotas mais específicas do que um intervalo CIDR /0 usado pela maioria das VPNs, podemos criar regras de roteamento com uma prioridade superior às rotas para a interface virtual criada pela VPN. Podemos configurar várias rotas /1 para recriar a regra de todo o tráfego 0.0.0.0/0 estabelecida pela maioria das VPNs.
Ao empurrar uma rota, significa que o tráfego de rede será enviado pela mesma interface que o servidor DHCP em vez da interface de rede virtual. Este é um funcionamento intencional que não é claramente declarado no RFC. Portanto, para as rotas que configuramos, estas nunca são criptografadas pela interface virtual da VPN, mas sim transmitidas pela interface de rede que está se comunicando com o servidor DHCP. Como um atacante, podemos selecionar quais endereços IPs vão pelo túnel e quais endereços vão pela interface de rede falando com o nosso servidor DHCP.
Agora temos tráfego sendo transmitido fora do túnel criptografado da VPN. Esta técnica também pode ser usada contra uma conexão VPN já estabelecida quando o host do usuário da VPN precisa renovar um arrendamento de nosso servidor DHCP. Podemos artificialmente criar esse cenário definindo um tempo de arrendamento curto no arrendamento DHCP, para que o usuário atualize sua tabela de roteamento com mais frequência. Além disso, o canal de controle da VPN ainda está intacto porque já usa a interface física para sua comunicação. Em nossos testes, a VPN sempre continuou a relatar como conectada, e o kill switch nunca foi acionado para desconectar nossa conexão VPN.”
O ataque pode ser mais eficazmente executado por alguém que tenha controle administrativo sobre a rede à qual o alvo está conectando. Nesse cenário, o atacante configura o servidor DHCP para usar a opção 121. Também é possível para pessoas que podem se conectar à rede como um usuário não privilegiado executar o ataque configurando seu próprio servidor DHCP falso.
O ataque permite que parte ou todo o tráfego seja roteado através do túnel não criptografado. Em qualquer caso, a aplicação de VPN reportará que todos os dados estão sendo enviados através da conexão protegida. Qualquer tráfego que seja desviado desse túnel não será criptografado pela VPN e o endereço IP de Internet visível pelo usuário remoto pertencerá à rede à qual o usuário da VPN está conectado, em vez de um designado pelo aplicativo VPN.
Curiosamente, o Android é o único sistema operacional que imuniza completamente as aplicações de VPN contra o ataque porque não implementa a opção 121. Para todos os outros sistemas operacionais, não há correções completas. Quando os aplicativos rodam no Linux, há uma configuração que minimiza os efeitos, mas mesmo assim o TunnelVision pode ser usado para explorar um canal secundário que pode ser usado para desanonimizar o tráfego de destino e realizar ataques direcionados de negação de serviço. Firewalls de rede também podem ser configurados para negar o tráfego de entrada e saída para e da interface física. Esse remédio é problemático por duas razões: (1) Um usuário de VPN conectado a uma rede não confiável não tem a capacidade de controlar o firewall, e (2) ele abre o mesmo canal secundário presente na mitigação do Linux.
As correções mais eficazes são executar a VPN dentro de uma máquina virtual cujo adaptador de rede não esteja no modo ponte ou conectar a VPN à Internet através da rede Wi-Fi de um dispositivo celular. A pesquisa, dos pesquisadores da Leviathan Security Lizzie Moratti e Dani Cronce, está disponível aqui.
