Atacantes podem expor VPNs com base em roteamento

 (leviathansecurity.com)
3 pontos por GN⁺ 2024-05-07 | 1 comentários | Compartilhar no WhatsApp
  • TunnelVision (CVE-2024-3661) explora um recurso existente do DHCP para desviar o tráfego do usuário para fora do túnel VPN, e nesse processo os pacotes não são criptografados pela VPN
  • O atacante pode injetar rotas mais específicas com a opção 121 do DHCP para criar caminhos que têm prioridade sobre a interface virtual da VPN e enviar o tráfego pela interface física
  • O ataque é possível se o alvo aceitar um lease DHCP controlado pelo atacante e se o cliente implementar a opção 121; nos testes, Windows, Linux, iOS e macOS foram afetados, enquanto o Android ficou de fora
  • O canal de controle da VPN continua ativo, então o usuário ainda vê a conexão como estabelecida; nos casos observados, o kill switch também não impediu o vazamento de tráfego
  • Os namespaces de rede do Linux podem ser uma solução robusta, mas mitigações baseadas em firewall podem criar negação seletiva de serviço e canais laterais para inferência de destino do tráfego

TunnelVision e o decloaking de VPN

  • TunnelVision é uma técnica de rede que contorna o encapsulamento da VPN e força o tráfego do usuário a sair fora do túnel
  • O atacante pode usar o DHCP (Dynamic Host Configuration Protocol) para fazer com que os pacotes do alvo sejam transmitidos sem criptografia pela VPN
  • Como o canal de controle da VPN permanece ativo, o usuário continua vendo que está conectado à VPN; esse efeito é chamado de decloaking
  • Essa técnica pode ser possível desde 2002, e após a divulgação foi confirmado que já existiam pesquisas anteriores sobre a opção 121 do DHCP e seu impacto em VPNs desde pelo menos 2015

Por que o roteamento da VPN vira superfície de ataque

  • A VPN cria um túnel para o tráfego entre o dispositivo host e um servidor em outra rede, e o cliente VPN criptografa e descriptografa o tráfego na interface de rede virtual
  • Uma configuração que envia todo o tráfego pela VPN é chamada de full-tunnel VPN; quando há exceções, como a rede local, isso é chamado de split-tunnel VPN
  • Como a VPN precisa manter a conexão com o servidor, é necessária uma rota de exceção que envie pela interface física o tráfego destinado ao IP do servidor VPN
  • A tabela de roteamento determina o caminho do tráfego conforme o destino e, na maioria das pilhas de rede, um CIDR prefix length mais específico tem prioridade maior
    • Uma rota /32 tem prioridade sobre /24 ou /0
    • Muitas VPNs full-tunnel enviam o tráfego para a interface VPN usando 0.0.0.0/0 ou duas rotas /1

Injeção de rotas com a opção 121 do DHCP

  • O DHCP fornece leases de endereços IP dinamicamente para dispositivos na rede local e também entrega configurações como gateway padrão e servidor DNS por meio de options
  • O fluxo comum é o cliente transmitir DHCPDISCOVER em broadcast e o servidor responder com DHCPOFFER, propondo um lease com tempo limitado
  • Introduzida na RFC 3442, a opção 121 do DHCP implementa classless static routes, permitindo que o servidor DHCP adicione rotas estáticas à tabela de roteamento do cliente
  • A opção 121 não permite que o servidor DHCP indique diretamente qual interface de rede deve ser usada para instalar a rota
    • O servidor DHCP especifica o intervalo CIDR e o roteador
    • O cliente seleciona implicitamente como interface da rota aquela pela qual está se comunicando com o servidor DHCP
  • Por causa desse comportamento, o tráfego das rotas injetadas pode sair pela interface física de rede que se comunica com o servidor DHCP, e não pela interface virtual da VPN

Condições do ataque e forma de execução

  • O ataque TunnelVision exige duas condições
    • O host alvo precisa aceitar um lease do servidor DHCP controlado pelo atacante
    • O cliente DHCP do host alvo precisa implementar a opção 121 do DHCP
  • Um atacante na mesma rede pode se tornar o servidor DHCP do alvo de várias formas
    • Realizando um ataque de DHCP starvation contra o servidor DHCP legítimo e depois respondendo a novos clientes
    • Respondendo primeiro ao broadcast DHCPDISCOVER e explorando o comportamento de seleção da primeira oferta do cliente DHCP
    • Interceptando o tráfego entre o servidor DHCP legítimo e o cliente por ARP spoofing e esperando a renovação do lease
  • O atacante executa um servidor DHCP na mesma rede do usuário da VPN e se define como gateway
  • Depois, usa a opção 121 do DHCP para adicionar rotas arbitrárias à tabela de roteamento do usuário da VPN e insere rotas mais específicas que /0 da VPN, dando a elas prioridade sobre a interface virtual da VPN
    • Com várias rotas /1, é possível reproduzir a regra de tráfego total 0.0.0.0/0 usada pela maioria das VPNs
    • O atacante pode escolher quais endereços IP vão pelo túnel VPN e quais vão pela interface que se comunica com o servidor DHCP malicioso
  • Também funciona em conexões VPN já estabelecidas; se o tempo de lease DHCP for curto, é possível forçar atualizações mais frequentes da tabela de roteamento

PoC e cenários de teste

Sistemas operacionais e VPNs afetados

  • Nos testes, foram afetados os sistemas operacionais que implementam um cliente DHCP conforme a RFC e suportam rotas da opção 121 do DHCP
    • Impacto observado: Windows, Linux, iOS, macOS
    • Exceção: Android não foi afetado porque não suporta a opção 121 do DHCP
  • VPNs que dependem apenas de regras de roteamento para proteger o tráfego do host são vulneráveis
  • Administradores que operam seu próprio servidor VPN também podem estar vulneráveis se não tiverem reforçado a configuração do cliente VPN
  • A força dos algoritmos de criptografia não influencia esse problema
    • TunnelVision não quebra os próprios protocolos de VPN, como WireGuard, OpenVPN ou IPsec
    • Em vez disso, altera a configuração de roteamento da pilha de rede do sistema operacional para fazer o usuário deixar de usar o túnel VPN

Correções e mitigações

  • Os namespaces de rede do Linux podem corrigir completamente esse comportamento
    • A documentação do WireGuard mostra como tratar o tráfego de aplicações que precisam usar a VPN em um namespace separado e depois enviá-lo para outro namespace com a interface física
    • Não está claro se existe uma solução igualmente robusta em Windows, macOS e outros sistemas operacionais
  • Alguns provedores de VPN usam uma mitigação baseada em firewall que bloqueia todo o tráfego de entrada e saída na interface física
    • São necessárias exceções para DHCP e para o IP do servidor VPN, a fim de manter a LAN e a conexão com o servidor VPN
    • Também é possível permitir apenas DHCP e protocolos de VPN com inspeção profunda de pacotes, mas isso pode trazer penalidade de desempenho
  • Mitigações via firewall podem criar negação seletiva de serviço no tráfego que usa rotas DHCP e adicionar canais laterais
    • O atacante pode analisar mudanças no volume de tráfego criptografado da VPN para comprovar estatisticamente se o usuário alvo está enviando tráfego para determinados destinos
    • Ele pode comparar com uma lista predefinida, realizar bloqueio seletivo como mecanismo de censura ou usar bloqueio de espaço de IP como uma busca binária para encontrar a conexão atual em tempo logarítmico
  • Também é possível ignorar a opção 121 durante o uso da VPN, mas esse recurso pode ser necessário para conexões legítimas de rede e causar falhas de conectividade
    • Se essa mitigação for opcional, o atacante pode negar acesso à rede para induzir a VPN ou o usuário a reativar a opção 121
  • Hotspots e VMs também podem ajudar na mitigação
    • Uma LAN protegida por senha e controlada por um dispositivo celular ajuda a impedir o acesso do atacante à rede local
    • Uma VM se comporta de forma semelhante, desde que o adaptador de rede não esteja em modo bridged

Medidas necessárias para usuários e operadores

  • Para tráfego sensível, deve-se evitar redes não confiáveis e, quando isso não for possível, usar um provedor de VPN com mitigação eficaz contra TunnelVision
  • Mesmo que ocorra um decloak de VPN, ao acessar sites HTTPS a maior parte dos dados do usuário não ficará visível para o atacante na rede local, mas destino e protocolo ainda podem ser expostos
  • Se uma VPN corporativa for usada em cafés, hotéis, aeroportos etc., os administradores de rede devem alertar sobre o risco e orientar a evitar esse uso sempre que possível
    • Se isso não for prático, devem orientar o uso de uma VPN com mitigação ou correção aplicada
    • Também é possível usar um hotspot confiável antes de se conectar à VPN ou executar a VPN dentro de uma VM que receba lease de um servidor DHCP virtual
  • Empresas que operam sua própria rede ou VPN site-to-site devem verificar os switches e ativar proteções de Layer 2 como DHCP snooping e proteção contra ARP
    • Essas proteções ajudam a reduzir servidores DHCP rogue, mas não eliminam o cenário de administrador malicioso
    • Aplicar HTTPS ou outros protocolos criptografados aos recursos internos ajuda a evitar vazamento de dados de usuários de VPN que acessam a partir de redes não confiáveis
  • Provedores de VPN podem adicionar ao cliente uma função de firewall para bloquear pacotes de saída pela interface de rede, mas isso impede o usuário de interagir com recursos da rede local
  • Clientes VPN full-tunnel para Linux devem considerar isolamento com namespaces de rede
  • Mantenedores de sistemas operacionais devem avaliar adicionar ou fortalecer recursos relacionados a namespaces de rede em sistemas além do Linux
  • Está em desenvolvimento uma biblioteca de infraestrutura adversarial chamada ArcaneTrickster para pesquisa de segurança em LAN e demonstração prática de ataques, com divulgação planejada para o futuro

Leituras relacionadas

1 comentários

 
GN⁺ 2024-05-07
Comentários do Hacker News

  • Isso é uma pequena variação do ataque PoisonTap do Samy Kamkar, de 2016. Faz a mesma coisa com um adaptador de rede USB/Thunderbolt: basta conectá-lo ao dispositivo da vítima e anunciar duas rotas mais específicas, como 0.0.0.0/1 e 128.0.0.0/1, para capturar todo o tráfego com prioridade sobre outras interfaces do sistema, independentemente da ordem das interfaces: https://github.com/samyk/poisontap
    Provavelmente há outros precedentes, mas este é um caso bem conhecido. O título do artigo diz que todos os clientes VPN são afetados, mas, como o próprio texto admite, muitos clientes VPN configuram regras de firewall para bloquear tráfego que passa por interfaces físicas
    VPNs que prometem anonimato, ou nas quais esse anonimato é importante, geralmente implementam isso. Muitas talvez não deixem isso ativado por padrão, mas teria sido mais produtivo documentar qual porcentagem das principais soluções de VPN pessoais/comerciais/empresariais deixa isso ativado por padrão
    A explicação para leitores em geral é boa, mas, considerando que muitos clientes evitam a maior parte dos vazamentos de dados com essas regras de firewall e que o texto não reconhece os precedentes nessa área, o título parece um pouco exagerado

    • Boa observação. Tirando as VPNs que provavelmente já vazam bastante por nem terem regras básicas de firewall, isso é uma vulnerabilidade sem grande importância
      A expressão “ataque de canal lateral” quase me fez cuspir a bebida
      Edit: pelo que vi, o NordVPN, pelo menos no macOS, aparentemente não tem essas regras básicas de firewall e parece ser vulnerável a este ataque

  • Não entendo por que esse artigo é tão longo
    A DHCP Option 121 permite que um servidor DHCP configure regras de roteamento para intervalos CIDR específicos, e, por ter um prefixo mais longo, ganha prioridade sobre a regra padrão 0.0.0.0/0

    • Sou um dos autores do artigo. Achei que leitores sem formação técnica também entrariam, então a intenção era explicar antes alguns tópicos relacionados
      Metade das informações sobre VPN na internet é escrita pelos próprios provedores de VPN, e costuma ser imprecisa ou não suficientemente técnica para explicar como isso realmente funciona
      Eu queria colocar no início uma frase com link dizendo “se você já sabe disso, pule para a seção de POC”, mas vou atualizar para ficar mais visível
    • E, para o atacante provocar esse ataque, ele precisa estar na mesma rede de camada 2 que a vítima
      É um palpite baseado apenas no comentário acima, sem ter lido o artigo

  • Achei que já tinha lido sobre esse ataque antes, de outro autor, então fui procurar e, depois de abrir caminho por uma enxurrada de spam de empresas de VPN nos resultados, encontrei o trabalho anterior [1]
    Este artigo entra mais a fundo em como explorar a falha e também traz código útil para uma prova de conceito
    1: https://www.usenix.org/conference/usenixsecurity23/presentat...

    • Esse artigo é citado no apêndice
      Mas nenhuma das duas técnicas do artigo de agosto de 2023 usava DHCP option 121 para empurrar rotas. Empurrar rotas via DHCP aumenta muito o impacto a partir da mesma posição do atacante. Por exemplo, estando em uma posição em que se pode distribuir leases de IP fora do intervalo RFC1918 ou falsificar respostas DNS
    • Esse “ataque” é amplamente conhecido e também é usado pela opção de configuração do cliente OpenVPN redirect-gateway def1

  • O modelo de ameaça é que um atacante arbitrário consiga, de algum modo, virar um servidor DHCP na minha LAN; é improvável, mas não impossível
    Por outro lado, se você usa o gateway fornecido pelo ISP, a conversa muda

    • Se “um atacante arbitrário vira um servidor DHCP na minha LAN” é improvável, mas não impossível, então o Wi‑Fi de cafeteria não é exatamente esse cenário?
      Esse é o principal argumento de venda de muitos produtos de VPN
      Nesse caso, a resposta correta é usar conexão 4G/5G e não se conectar a redes suspeitas em que você não confia
    • A expressão “aquele servidor DHCP” pressupõe que haja algum dispositivo especial separado na rede, mas essa premissa está errada. DHCP é um protocolo de broadcast, e o dispositivo aceita a primeira oferta que receber
      Em casas comuns, o DHCP vem do roteador e por isso normalmente responde primeiro, mas isso é secundário. Qualquer dispositivo malicioso dentro da rede pode explorar essa vulnerabilidade
    • Um dos grandes casos de uso de VPN não é justamente quando eu não posso confiar na rede à qual estou conectado?
    • Ou o caso em que eu viro um servidor DHCP no Wi‑Fi de terceiros ao qual estou conectado
    • Proteger você em redes Wi‑Fi não confiáveis é um dos motivos mais comuns usados para anunciar VPNs

  • No Linux, também dá para mitigar isso colocando a interface da VPN em uma VRF. Por exemplo, o systemd-networkd oferece suporte nativo a isso
    O ponto de atenção é que, ao ativar a VRF, a entrada ip rule para l3mdev fica em 1000, mas a regra de tráfego local fica em 0. É preciso mover a regra local para 1000 ou mais

    • Hoje em dia existe alguma forma de executar apps em uma VRF específica?

  • Esse “ataque” é apenas um uso esperto da DHCP option 121. É um ataque válido contra configurações de cliente seriamente mal projetadas
    Alterar a rota padrão ou sobrescrevê-la com duas rotas /1 e adicionar uma rota de host para o endpoint da VPN não é seguro. Para isolar corretamente o tráfego encapsulado da rede subjacente, é preciso usar roteamento baseado em políticas. Por exemplo: namespaces de rede no Linux, vnet no FreeBSD, rdomains no OpenBSD
    Essa tentativa de amarrar filtros de pacotes e “kill switches” em espaço de usuário é quebrada desde a concepção e mostra o quanto os provedores comuns de hospedagem de VPN entendem pouco — ou simplesmente não se importam — com aquilo que dizem ser sua competência principal. É mais um caso do velho problema de “listar coisas ruins”

  • Não é exatamente novidade
    Eu me preocuparia mais com pessoas cujo sistema tem IPv6 ativado, mas que usam um serviço de VPN só para IPv4
    Isso sim pode dar muito errado

  • Há muitas formas de contornar uma VPN no dispositivo cliente. Por isso, quando a VPN é necessária, prefiro colocar entre o cliente e a internet um roteador que encerre o túnel VPN e não tenha outro caminho possível
    Esses roteadores de viagem podem ser configurados com muita facilidade para serem levados a qualquer lugar, e é exatamente isso que faço

    • Em casa, recomendo fortemente um roteador VPN dedicado em que cada roteador tenha sua própria rede Wi‑Fi. Acho mais fácil de conectar e mais estável do que rodar software de VPN localmente em cada dispositivo
      Por exemplo, há um roteador Wi‑Fi “work” que mantém sempre uma conexão VPN com a intranet do trabalho, um Wi‑Fi “Australia” que se conecta a um servidor na Austrália sempre que eu quero assistir TV australiana, e por fim o Wi‑Fi normal da internet residencial
      Dá para fazer isso com muita facilidade usando alguns roteadores Wi‑Fi antigos, e parece que hoje em dia até roteadores domésticos baratos têm algum nível de suporte a VPN. Além de centralizar a configuração da VPN e reduzir espaço para erros, há a grande vantagem de que qualquer dispositivo pode usar a VPN só de se conectar àquele Wi‑Fi
      Eu uso vários roteadores antigos dessa forma, mas na verdade parece que poderia existir um mercado para um único roteador doméstico que fechasse VPNs para vários lugares do mundo e oferecesse redes Wi‑Fi diferentes por localização. A ideia seria fazer com que TV/Roku/iPad parecessem acessar facilmente a partir de outras regiões
    • Esse ataque só é possível quando há dispositivos não confiáveis na LAN local. Se você já estiver carregando diretamente um gateway com a VPN ativa, dispositivos LAN não confiáveis provavelmente não são uma preocupação tão grande
      Ainda assim, se houver um dispositivo não confiável na LAN e você usar DHCP, esse dispositivo poderá bisbilhotar tráfego não criptografado* com essa técnica. Mesmo assim, não conseguirá descobrir o IP real, porque o gateway o oculta
      O cenário mais realista para esse ataque é algo como o Wi‑Fi de um café. Nesses lugares, é pouco provável que a pessoa leve o próprio roteador
      Aqui, “tráfego não criptografado” significa tráfego que não foi encapsulado para ser enviado ao provedor de VPN. Hoje em dia, como a maior parte das conexões usa HTTPS, o conteúdo desse tráfego em si ainda deve continuar criptografado
    • Seria útil listar algumas opções de hardware e software que realmente valham a pena
    • A maioria dos roteadores de viagem provavelmente ainda é vulnerável a esse problema

  • Para quem é técnico, isso deveria ser bem óbvio, mas é uma boa introdução a redes e VPN. Já montei algumas vezes uma VM gateway de VPN em Linux, e uma arquitetura que depende apenas da tabela de roteamento sempre me pareceu frágil, especialmente quando roda na mesma máquina que usa essa conexão
    Além de namespaces de rede e roteadores físicos de gateway VPN, uma arquitetura baseada em VMs também pode resolver esse problema. No meu homelab, o firewall bloqueia tráfego inesperado saindo da VM gateway de VPN. Os dispositivos da VLAN da VPN não podem se conectar diretamente para fora, e a VM gateway tem uma VLAN separada para conectividade externa
    Como solução pessoal, o QubesOS permite configurar algo parecido com relativamente pouco atrito, mas ainda exige mais conhecimento técnico do que um sistema operacional comum

  • Achei interessante a parte de que “o Android foi o único não afetado porque não implementou suporte à opção 121 do DHCP”
    Fico curioso se isso foi uma decisão deliberada do Google por conhecer esse problema, ou se foi completamente acidental

    • Olhando https://issuetracker.google.com/issues/117544989, parece que o Google basicamente ignorou essa solicitação de recurso sem nem explicar o motivo. Também tenho a mesma curiosidade. Talvez algum funcionário do Google com acesso ao Buganizer interno saiba mais
      Meu palpite é que a equipe de redes do Android é muito favorável ao IPv6. Parece não ter muito interesse em recursos de nicho ausentes no IPv4. Mesmo no IPv6, existe uma visão específica de como ele deve ser usado, o que acaba resultando na falta intencional de suporte a coisas como DHCPv6 com estado
    • Existem muitas opções de DHCP, então, no caso do Android, faz sentido adotar uma estratégia de começar suportando só o mínimo e adicionar suporte apenas quando surgir demanda por uma opção específica
      Como essa opção de DHCP não é comumente usada, com uma estratégia dessas ela provavelmente teria ficado sem suporte mesmo sem qualquer preocupação de segurança
    • O Android nem implementou a nova versão do DHCP definida pela primeira vez há 21 anos: https://www.rfc-editor.org/rfc/rfc3315
      Então não é tão surpreendente assim