Possível vazamento de tráfego DNS para fora do túnel VPN no Android

 (mullvad.net)
2 pontos por GN⁺ 2024-05-04 | 1 comentários | Compartilhar no WhatsApp
  • Em algumas combinações de apps e estados no Android, consultas DNS podem sair para fora do túnel VPN, e a Mullvad considera que a causa é um bug no Android OS, não no app de VPN
  • O vazamento pode ocorrer em curtos períodos de transição, mesmo com a VPN ligada, como quando não há servidor DNS configurado, durante a reconfiguração do túnel, ou quando o app de VPN é encerrado à força ou falha
  • O impacto se concentra em apps que chamam getaddrinfo diretamente, e nenhum vazamento foi encontrado em apps que usam apenas a API DnsResolver do Android
  • Mesmo com Always-on VPN e “Block connections without VPN” ativados, o problema não é totalmente bloqueado, e foi confirmado em várias versões, incluindo o Android 14
  • Como mitigação temporária, a Mullvad pretende configurar um servidor DNS falso para aliviar alguns cenários, mas os vazamentos durante a reconexão são difíceis de bloquear completamente sem correção no sistema operacional

Condições de vazamento de DNS observadas no Android

  • Em 22 de abril, a Mullvad confirmou por meio de um relato de usuário no Reddit que pode haver vazamento de DNS ao desligar e religar a VPN com “Block connections without VPN” ativado
  • Na investigação interna, surgiram mais cenários em que o Android OS pode enviar tráfego DNS para fora da VPN
    • quando a VPN está ativa, mas nenhum servidor DNS está configurado
    • durante a reconfiguração do túnel pelo app de VPN
    • no curto intervalo em que o app de VPN é encerrado à força ou sofre falha
  • Esse comportamento não é o esperado do Android OS e precisa ser corrigido em um nível superior do sistema

Apps afetados e caminho de resolução de nomes

  • O vazamento parece ocorrer em apps que chamam diretamente a função C getaddrinfo para resolução de nomes de domínio
  • A Mullvad não encontrou vazamento em apps que usam apenas a API DnsResolver do Android
  • O navegador Chrome é um exemplo de app que pode usar getaddrinfo diretamente
  • O uso de getaddrinfo em si não é incorreto, e para proteger todos os usuários do Android é necessária uma solução no nível do sistema operacional

Limites do Always-on VPN e da configuração de bloqueio

  • Os vazamentos confirmados ocorrem independentemente de Always-on VPN e de “Block connections without VPN” estarem ativados
  • Com “Block connections without VPN” ativado, nada além de tráfego WireGuard criptografado deveria sair do dispositivo, mas no processo de reprodução foi observado DNS em texto puro no roteador
  • A Mullvad avalia que essa configuração não cumpre o que o nome ou o comportamento documentado prometem e apresenta várias falhas
    • o tráfego DNS pode vazar nas condições acima
    • como já havia sido relatado antes, o tráfego de verificação de conectividade também continua vazando

Mitigação temporária no app da Mullvad e problemas restantes

  • Atualmente, o app da Mullvad não configura servidor DNS no estado de bloqueio
    • se a configuração do túnel falhar de forma irrecuperável, o app entra em estado de bloqueio
    • nesse estado, ele impede que o tráfego saia do dispositivo, mas como o DNS fica vazio, pode surgir a condição para vazamento
  • Para contornar o bug do sistema operacional, a Mullvad pretende responder temporariamente configurando um servidor DNS falso, e planeja disponibilizar em breve uma versão com essa correção
  • Os vazamentos que ocorrem durante a reconexão do túnel são mais difíceis de mitigar no app
    • a Mullvad está buscando uma solução
    • pode haver redução no número de reconfigurações do túnel, mas no momento a empresa não considera possível bloquear completamente esse vazamento
  • A Mullvad reportou o problema e sugestões de melhoria ao Google

Observações reproduzidas com WireGuard e Chrome

  • O vazamento no segundo cenário, durante mudança na configuração do túnel VPN, pode ser reproduzido com o app WireGuard e o Chrome
    • o WireGuard é usado como caso de referência da implementação de VPN no Android
    • a Mullvad considera possível reproduzir o problema também em outros apps de VPN para Android
    • o Chrome foi usado para acionar o vazamento porque é um app com uso confirmado de getaddrinfo
  • O procedimento de reprodução inclui os seguintes elementos
    • baixar spam_get_requests.html
    • instalar o app WireGuard e o Chrome
    • importar wg1.conf e wg2.conf no WireGuard
    • ativar o túnel wg1 no WireGuard e conceder permissão de VPN
    • ativar Always-on VPN e “Block connections without VPN” para o WireGuard nas configurações de VPN do Android
    • iniciar a captura no roteador com tcpdump -i <INTERFACE> host <IP of android device>
    • abrir WireGuard e Chrome em tela dividida, executar spam_get_requests.html no Chrome e alternar entre os túneis wg1 e wg2 no WireGuard
  • No roteador, foram observadas consultas de registro A e respostas NXDomain vindas do dispositivo Android para a porta 53 do roteador OpenWrt
  • O vazamento de DNS pode ser usado para inferir a localização aproximada do usuário ou os sites e serviços que ele visita, o que pode ter grande impacto na privacidade
  • Dependendo do modelo de ameaça, pode ser necessário evitar o uso do Android em cenários sensíveis ou aplicar outras medidas de mitigação para impedir o vazamento
  • Usuários do app da Mullvad devem mantê-lo atualizado, já que versões recentes podem incluir mitigação parcial

Leituras relacionadas

1 comentários

 
GN⁺ 2024-05-04
Opiniões no Hacker News

  • Não uso Mullvad, mas passei a respeitá-los muito. A explicação do problema, a solução temporária de curto prazo, possíveis workarounds que outras pessoas podem usar e até o que precisa ser corrigido no Android estão bem organizados e com alta densidade de informação

    • Escolhi a Mullvad como serviço de VPN justamente por publicarem posts de blog como este, em vez de fazerem patrocínios intermináveis no YouTube como os concorrentes
    • Mesmo que você não use VPN, a Mullvad tem um serviço de DNS gratuito. O aumento de tráfego/uso também pode ser uma forma de apoio, e deve ajudar a fazer com que usuários da Mullvad VPN chamem menos atenção do ponto de vista das consultas DNS
      A desvantagem é que, no meu caso, o tempo de ping é bem maior do que no quad9 ou no cloudflare
      Coloquei neste thread algumas informações sobre bloqueio de anúncios em nível de DNS e sobre o cloudflare: https://news.ycombinator.com/item?id=40056162
    • Considerando os valores, a forma de pensar, a fidelidade às crenças centrais e as evidências consistentes de que mantêm seu lema há décadas, vejo como a melhor VPN
    • Como usuário da Mullvad, estou muito satisfeito. Uma vez mandei um e-mail ao suporte com uma dúvida sobre pagamento e acrescentei também uma pequena pergunta sobre iptables relacionada a um problema que eu estava enfrentando
      Resolveram rapidamente a questão do pagamento e também recebi uma resposta detalhada sobre iptables, incluindo prós e contras de várias soluções. Em uma palavra: excelente
    • Se você usa VPN, fico curioso para saber qual

  • Sou desenvolvedor do rethinkdns
    Sobre a frase “esses problemas precisam ser resolvidos no SO para proteger todos os usuários de Android, independentemente do app usado”, o networking paranoico do Android sempre abriu exceções para apps do sistema e apps de OEMs, ou seja, incluindo apps do Google
    É provável que a maioria dessas correções de bugs não mude essa premissa central. Código relacionado: https://github.com/celzero/rethink-app/issues/224
    Quanto à parte “vazamentos durante a reconexão do túnel são mais difíceis de mitigar no app; ainda estamos procurando uma solução”, o Android oferece suporte a uma transição contínua entre dois dispositivos TUN durante a reconfiguração. É complicado implementar corretamente, mas é possível

    • Não deixam nem desativar a permissão de internet de um app de lanterna; faz sentido quando se lembra que o SO é operado por uma empresa de publicidade na internet

  • É um problema antigo no Android. Mesmo que você queira usar apenas servidores DNS internos, se o Android decidir que precisa ou quer, ele muda para a rede celular e usa aquele DNS
    Recentemente fiquei observando o debug via adb para ver por que/quando a conexão sem fio caía, e no fim, se durante a verificação de conectividade ele não consegue ver ou interpretar alguma coisa, ativa os dados móveis e tenta por lá
    É especialmente frustrante quando se usam registros DNS que existem apenas internamente e o celular se comporta de forma imprevisível. O aparelho está conectado ao Wi-Fi que fornece o servidor DNS interno onde esses registros existem, mas por algum motivo o Android está resolvendo externamente
    Não sei como é no caso da Apple, mas considerando que, por padrão, eles tentam fazer proxy até do DNS via DoH por meio da “privacy” VPN deles, é difícil imaginar que seja melhor quando se usa algo que possa ser visto como produto concorrente, e também sabemos como a Apple trata esse tipo de produto

    • Vale conferir se esse “muda para a rede celular e usa quando precisa ou quer” não é porque o Wi-Fi Assist está ativado. Esse recurso foi explicitamente projetado para mudar para a rede celular quando o sinal do Wi-Fi está ruim
    • A Apple ou o iOS têm um método embutido bastante robusto, via perfis de configuração, para filtrar e bloquear tráfego. Não tenho certeza se dá para configurar por app, mas com certeza é possível definir listas de permissão/bloqueio de nomes de host
      Como exemplo real, veja este bloqueador de anúncios para o sistema todo: https://myxxdev.github.io/depictions/MYbloXXforiOS/MYbloXXfo...
    • O iOS jamais usa o Private Relay por padrão. Mesmo que esteja incluído na assinatura, você precisa ativá-lo explicitamente por conta própria
    • Fico curioso se você já tentou desativar “Dados móveis sempre ativos” nas opções de desenvolvedor
    • Já compilei o AOSP a partir do código-fonte. É algo que não deveria ter requisitos exclusivos do Google, e bloqueei o máximo possível de servidores do Google no arquivo hosts para impedir que ele se conectasse secretamente ao Google
      O único problema que tive foi o aparelho indicar que não havia internet mesmo estando conectado a um AP sem fio funcionando normalmente. Na prática funcionava, mas, para fins do ícone na barra de status e de outros códigos internos do sistema, ele parecia verificar se a internet estava funcionando usando servidores do Google
      Se você se importa com privacidade, é melhor manter distância do Android, e provavelmente tomar cuidado com tecnologia em geral

  • Alguns anos atrás, quando eu testava várias configurações de VPN para um projeto, eu costumava colocar um appliance de firewall MikroTik entre o computador e o roteador principal. O objetivo era simplesmente bloquear todo o tráfego cujo destino não fosse o endereço IP do servidor VPN ao qual o PC tentava se conectar
    Esse método funcionava muito bem para garantir que não houvesse vazamento de tráfego para fora do caminho do PC até o servidor VPN. O endereço IP do servidor VPN usado quase nunca muda e, se mudar, é fácil alterar no firewall MikroTik
    Se você não souber o IP do servidor ou se ele mudar, também dá para bloquear todo tráfego que não use o par porta/protocolo usado pelo servidor VPN. Por exemplo, dependendo do tipo de VPN, descartar tráfego cujo destino não seja UDP 1194
    Roteadores MikroTik também têm uma pequena ferramenta chamada torch, que permite visualizar o tráfego de forma rápida e fácil, além de oferecerem captura de pacotes. Os preços vão de 30 a 3000 dólares, não há licença de software, e eles são muito poderosos e capazes se você souber usá-los

    • Esse tipo de equipamento é chamado de network slug, e é uma ideia excelente
      Tecnicamente, um slug de verdade é um firewall transparente de camada 2 sem endereço IP definido, mas não precisamos entrar nesse detalhe aqui
      https://john.kozubik.com/pub/NetworkSlug/tip.html

  • A filtragem de saída com base em endereço e porta de origem/destino é um conceito básico de firewall e uma configuração padrão em todas as plataformas de firewall-roteamento. O roteamento baseado em políticas que filtra com base no gateway segue a mesma lógica: https://en.wikipedia.org/wiki/Policy-based_routing
    Em geral, só produtos de consumo ou semiprofissionais permitem todo o tráfego externo por padrão. Fico curioso para saber o que era o “roteador principal” nessa configuração. Era um equipamento fornecido pelo ISP?

    • Já que estamos recomendando, fico curioso para saber se também existe algum roteador barato e decente com firewall de camada 7
      Seria bom se também pudéssemos colocar um firewall entre os apps do celular e o modem

  • O problema de DNS do Android é que, nessa plataforma, não dá para configurar um servidor DNS IPv6 próprio. Ele muda sempre que acontece alguma alteração no Wi-Fi
    Mesmo em Android com root, não há app que impeça o sistema operacional de alterar isso
    Se você usa um roteador que sempre distribui endereços IPv6 e não permite desativar isso, basicamente fica travado
    Nem sei se dá para instalar um equipamento de firewall atrás desse roteador para remover o servidor DNS IPv6 anunciado por ele

    • Em vez de configurar o endereço IP do servidor DNS, talvez seja melhor usar o suporte a DNS-over-TLS em nível de sistema. Como é uma configuração global, deveria valer independentemente da rede em que você esteja e do que aconteça nela
      Se você se preocupa com vazamento de requisições DNS, de qualquer forma deveria usar DoT ou DoH
    • Não dá para alterar o DNS IPv6 com o rethink?
    • Parece que isso acontece quando o celular é a interface principal
      Fico curioso para saber se o mesmo acontece com tethering Wi-Fi. Se você usa uma VPN em um notebook conectado pelo Wi-Fi do celular, ela vaza da mesma forma?

  • A configuração mais segura parece ser desligar os dados móveis do celular e carregar um hotspot OpenWRT que trate a VPN acima do celular

    • Sim. No iOS é um pesadelo ainda maior
      “VPN sempre ativa” só pode ser configurada em dispositivos no estado “supervised” por uma solução MDM de uma organização aprovada pela Apple. Isso exige uma solicitação documentada e uma ligação telefônica com um funcionário atual
      Caso contrário, só usando o app Apple Configurator em um Mac para criar um perfil de configuração contendo a chave “always-on VPN”
    • Já fiz isso por meses com um GL.inet E750 e um iPhone sem SIM, e as operadoras GSM dos EUA frequentemente restringiam muito o tráfego UDP em portas estranhas. Às vezes caía para 64–128 kbps, ou seja, algo como 0,1 Mbps
      As notificações também atrasavam com frequência
    • Se você usa Wi-Fi público ou rede móvel, essa é a melhor solução. Se alguém operar uma estação rádio-base diretamente, o celular pode se conectar a ela
      Se a rede não for minha, é melhor não se conectar diretamente sem um roteador móvel
    • Como outras pessoas dizem que o Android reativa silenciosamente os dados celulares sob várias condições, esse método também não é uma solução garantida
      The Grugq criou uma ferramenta para esse fim há 10 anos. Infelizmente, ela não é mais mantida: https://github.com/grugq/portal
      Ela fazia parte de uma apresentação sobre segurança operacional para hackers, e vale assistir se você se interessa por casos de vários hackers famosos, ou infames, que achavam estar seguros mas acabaram sendo pegos: https://www.youtube.com/watch?v=9XaYdCdwiWU

  • Um sistema sem acesso root é, por definição, inseguro. Android e iOS são ridículos

    • Também dá para dizer que um sistema que tem o conceito de acesso root é, por definição, inseguro. Qualquer um pode fazer afirmações categóricas desse tipo
    • Daria para rir e deixar para lá se os celulares não tivessem substituído desktops/laptops para a maioria das pessoas
      Tenho pena das crianças que cresceram, ou vão crescer, tendo como computador apenas dispositivos projetados principalmente para consumo de mídia e coleta de dados pessoais
    • Os desenvolvedores do GrapheneOS são realmente muito contra root. Fico curioso para saber o que pensam sobre isso
    • O ponto é claro e também pertinente ao tema. É por isso que os projetos de dispositivos móveis com software e hardware open source só tendem a continuar aumentando
      https://en.wikipedia.org/wiki/PinePhone_Pro
    • Por essa definição, uma boa parte dos meus sistemas mais importantes seria “insegura”
      Se você conseguir obter uma cópia da minha chave privada SSH que está em um desses dispositivos, pago 100 mil dólares em dinheiro, sem perguntas
      Essa definição não tem sentido e não serve para raciocinar nem para se comunicar

  • “Bloquear conexões sem VPN” está se mostrando tão pouco confiável quanto meu autocontrole em um buffet. Se não me engano, esse tipo de vazamento de DNS pode revelar bastante sobre os sites visitados e até a localização, o que derrota o próprio objetivo da VPN
    Como o Android pode vazar informações de DNS mesmo com a VPN ligada, se você realmente é sensível a privacidade, é melhor pensar além de usar Android ou tirar as tarefas sensíveis do celular

  • Às vezes desconfio que esses “bugs” não foram colocados ali de propósito, e bem posicionados. Ainda mais considerando que grandes empresas de tecnologia já colaboraram com várias agências de inteligência
    Também não é a primeira vez que ouço falar desse tipo de bug no Android, então já está ficando difícil acreditar que tantos bugs assim entraram “sem querer”

    • “Uma vez é acaso, duas vezes é coincidence, três vezes é ação inimiga.” —Ian Fleming, Goldfinger

  • Já suspeitava há algum tempo que fosse assim. Mesmo com uma VPN ligada no Android, MMS e Visual Voicemail ainda funcionam
    Ambos podem exigir acesso móvel direto ou ser recusados em certos casos. Podem funcionar só na rede móvel, ou serem recusados se a solicitação não vier de dentro da rede móvel. Suspeito que o mesmo valha para VoLTE. Com uma VPN, esses recursos podem dar problema
    No Mobile Linux, você percebe isso porque, ao ligar a VPN, todos esses recursos quebram
    Não parece haver uma forma óbvia de corrigir isso no Android sem quebrar muitos recursos esperados

    • Ironicamente, SMS/MMS e VVS são algumas das poucas tarefas/funcionalidades em que faz sentido serem hardcoded para a conexão da operadora. Talvez atualizações do sistema também possam ser assim

Já tive de lidar com a equipe de suporte avançado da AT&T e com problemas de VVS no iOS com a VPN ativada, então posso confirmar que esse problema não se limita ao Android

  • VoLTE usa um bearer dedicado na pilha LTE, ou seja, uma interface de rede separada. Não é a interface usada para dados
    Bearers diferentes podem ter prioridades/QCI diferentes, ou seja, qualidade de serviço diferente. Em uma rede LTE congestionada, o VoLTE deve oferecer uma experiência melhor do que VOIP em um bearer de prioridade mais baixa