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.
Denominado TunnelVision, o ataque praticamente anula 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 afeta todas as aplicações de VPN quando estão conectadas a uma rede hostil e que não há maneiras de evitar tais ataques, exceto quando a VPN do usuário roda em Linux ou 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 na natureza desde então.
O efeito do TunnelVision é que “o tráfego da vítima agora está desmascarado e está sendo roteado diretamente pelo atacante”, como explicou uma demonstração em vídeo. “O atacante pode ler, interromper 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 aos dispositivos que tentam se conectar à rede local. Uma configuração conhecida como opção 121 permite ao servidor DHCP substituir as regras de roteamento padrão que enviam o tráfego da VPN através de um endereço IP local que inicia o túnel criptografado. Ao usar 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 é executar um servidor DHCP na mesma rede que um usuário de VPN-alvo e também configurar nossa configuração de DHCP para usar a si mesmo como um 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 espionamos nele.
Estamos utilizando a opção DHCP 121 para definir uma rota na tabela de roteamento do usuário VPN. A rota que definimos é arbitrária e também podemos definir várias rotas, se necessário. Ao empurrar rotas que sejam mais específicas do que um intervalo CIDR /0 que a maioria das VPNs utiliza, podemos criar regras de roteamento que tenham uma prioridade mais alta do que as rotas para a interface virtual que a VPN cria. Podemos definir várias rotas /1 para recriar a regra de tráfego 0.0.0.0/0 definida pela maioria das VPNs.
A inclusão de uma rota também significa que o tráfego de rede será enviado pela mesma interface que o servidor DHCP em vez da interface de rede virtual. Essa é uma funcionalidade pretendida que não está claramente declarada no RFC. Portanto, para as rotas que empurramos, elas nunca são criptografadas pela interface virtual da VPN, mas, em vez disso, são transmitidas pela interface de rede que está se comunicando com o servidor DHCP. Como atacantes, podemos selecionar quais endereços IP passam pelo túnel e quais endereços passam pela interface de rede que se comunica com nosso servidor DHCP.
Agora temos tráfego sendo transmitido fora do túnel criptografado da VPN. Essa técnica também pode ser usada contra uma conexão VPN já estabelecida uma vez que o host do usuário VPN precisa renovar um contrato de arrendamento do nosso servidor DHCP. Podemos criar artificialmente esse cenário definindo um tempo de arrendamento curto no contrato de 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 se reportar como conectada e o kill switch nunca foi ativado para encerrar nossa conexão VPN.
O ataque pode ser realizado de forma mais eficaz por uma pessoa que tenha controle administrativo sobre a rede à qual o alvo está conectado. Nesse cenário, o atacante configura o servidor DHCP para usar a opção 121. Também é possível que pessoas que possam se conectar à rede como um usuário sem privilégios realizem o ataque configurando seu próprio servidor DHCP falso.
O ataque permite que parte ou todo o tráfego seja roteado pelo túnel não criptografado. Em ambos os casos, a aplicação de VPN reportará que todos os dados estão sendo enviados pela conexão protegida. Qualquer tráfego desviado desse túnel não será criptografado pela VPN e o endereço IP da 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 os aplicativos VPN contra o ataque porque não implementa a opção 121. Para todos os outros SOs, não há correções completas. Quando os aplicativos são executados no Linux, há uma configuração que minimiza os efeitos, mas mesmo assim o TunnelVision pode ser usado para explorar um canal lateral 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 tráfego de entrada e saída para e da interface física. Esse remédio é problemático por dois motivos: (1) Um usuário de VPN conectando-se a uma rede não confiável não tem a capacidade de controlar o firewall e (2) abre o mesmo canal lateral 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 está no modo bridged ou conectar a VPN à Internet por meio da rede Wi-Fi de um dispositivo celular. A pesquisa, dos pesquisadores de segurança da Leviathan Security, Lizzie Moratti e Dani Cronce, está disponível aqui.
Este texto foi primeiramente publicado no Ars Technica.
