Os IPs de saída da Mullvad são surpreendentemente identificáveis

 (tmctmt.com)
1 pontos por GN⁺ 3 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Mullvad mantém vários IPs de saída por servidor, mas a atribuição é determinística com base na chave do WireGuard, então não muda aleatoriamente a cada conexão
  • 3.650 pontos de dados coletados em 9 servidores, alterando repetidamente a pubkey, foram atribuídos a apenas 284 combinações entre mais de 8,2 trilhões de combinações possíveis
  • Os IPs de saída de cada servidor ficam em posições percentuais semelhantes dentro do pool, e uma combinação tende a se alinhar por volta do 81º percentil em vários servidores
  • A causa parece ser uma estrutura que escolhe o índice do IP de saída com um RNG baseado em seed, usando a pubkey ou o endereço do túnel como seed e o tamanho do pool como limite superior
  • Se os intervalos de float nos logs de IP se sobrepõem, é possível correlacionar contas mesmo usando servidores Mullvad diferentes, aumentando o risco para o anonimato

Como o IP de saída da Mullvad vira um vetor de identificação

  • A Mullvad oferece vários IPs de saída por servidor, e dois usuários conectados ao mesmo servidor normalmente recebem IPs públicos diferentes
  • O número de servidores é 578, menos que os 20.000 da Proton VPN, então a escala vertical, que evita concentrar usuários em um único IP, ajuda a escapar de bloqueios excessivos de IP e limitação de velocidade
  • Porém, o IP de saída não muda aleatoriamente cada vez que você se conecta ao servidor, e sim é selecionado de forma determinística com base na chave do WireGuard
  • A chave do WireGuard gira a cada 1 a 30 dias, mas em clientes de terceiros ela não gira
  • Se cada servidor atribuir um IP de saída fixo de forma independente, apenas a combinação de IPs de alguns servidores já pode diferenciar um usuário dos demais usuários da Mullvad

Combinações de IPs de saída observadas em 9 servidores

  • Um script foi executado durante a noite alterando repetidamente a pubkey e coletando os IPs de saída de 9 servidores, resultando em 3.650 pontos de dados de pubkeys
  • O intervalo de IPs de saída de cada servidor foi observado da seguinte forma
Hostname Start IP End IP # IPs
au-syd-wg-101 103.136.147.5 103.136.147.64 60
cl-scl-wg-001 149.88.104.4 149.88.104.14 11
de-ber-wg-007 193.32.248.245 193.32.248.252 8
dk-cph-wg-002 45.129.56.196 45.129.56.226 31
fi-hel-wg-201 185.65.133.10 185.65.133.75 66
us-lax-wg-001 23.234.72.36 23.234.72.126 91
us-nyc-wg-602 146.70.168.132 146.70.168.190 59
us-sjc-wg-302 142.147.89.212 142.147.89.224 13
za-jnb-wg-002 154.47.30.145 154.47.30.155 11
  • Multiplicando o tamanho dos pools desses servidores, parece haver mais de 8,2 trilhões de combinações possíveis de IPs de saída
  • Na prática, todas as pubkeys testadas foram atribuídas a apenas uma entre 284 combinações
  • O número de combinações observadas é extremamente pequeno em relação ao número de combinações possíveis, o que sugere que a escolha de IP por servidor não é independente

O padrão em que IPs diferentes caem no mesmo percentil

  • É possível calcular a posição numérica de um IP de saída medindo sua distância a partir do IP inicial do pool
  • Por exemplo, em au-syd-wg-101, o 103.136.147.53 fica no índice 49 em base 1 contando a partir de 103.136.147.5
  • Se dividirmos a posição do IP observado pelo tamanho do pool de cada servidor, surge praticamente a mesma proporção mesmo em servidores diferentes
Server IP Position Pool size Ratio
au-syd-wg-101 103.136.147.53 49 60 0.816
cl-scl-wg-001 149.88.104.12 9 11 0.818
de-ber-wg-007 193.32.248.251 7 8 0.875
dk-cph-wg-002 45.129.56.220 25 31 0.806
fi-hel-wg-201 185.65.133.63 54 66 0.818
us-lax-wg-001 23.234.72.109 74 91 0.813
us-nyc-wg-602 146.70.168.179 48 59 0.813
us-sjc-wg-302 142.147.89.222 11 13 0.846
za-jnb-wg-002 154.47.30.153 9 11 0.818
  • Cada IP fica em um percentil semelhante dentro do respectivo pool, e o exemplo acima corresponde em geral ao 81º percentil
  • Por causa desse padrão, parece que a Mullvad atribui apenas IPs de saída em posições vizinhas em todos os servidores

A causa provável: seleção pseudoaleatória baseada em seed

  • cl-scl-wg-001 e za-jnb-wg-002 sempre compartilham o mesmo índice de IP em todas as 284 combinações observadas
  • O ponto em comum entre os dois servidores é o tamanho do pool 11, o que bate com uma estrutura em que chamadas aleatórias com a mesma seed e os mesmos limites produzem o mesmo resultado
  • Se um RNG for inicializado com uma seed estática e gerar um número aleatório dentro do mesmo intervalo, o resultado se repete
  • Aparentemente, a Mullvad escolhe o índice do IP de saída com um RNG baseado em seed, usando a pubkey ou o endereço do túnel como seed e o tamanho do pool como limite superior
  • Mesmo que os limites mudem, o pool de entropia do RNG não é afetado; em Rust, isso também combina com a ideia de que a primeira chamada gera o mesmo float, que depois é multiplicado pelos limites
  • Esse comportamento pode ser simplificado como min + round((max - min) * float), embora isso possa ser uma representação simplificada demais
  • Por causa dessa característica, mesmo com tamanhos de pool diferentes, o mesmo float gerado a partir da mesma seed acaba mapeado para pontos proporcionais semelhantes em cada pool de servidor
  • Como o cliente da Mullvad é escrito em Rust, é possível que Rust também seja a linguagem do backend, embora isso seja apenas uma inferência baseada na implementação do cliente
  • É difícil prever exatamente como random_range se comporta quando os limites mudam; é fácil imaginar que ampliar os limites se misturaria com a entropia e produziria outro número, mas isso não foi o observado

Risco ao anonimato por correlação de logs de IP

  • Há uma ferramenta, mullvad-seed-estimator, para estimar os valores mínimo e máximo possíveis de float para uma determinada combinação de IPs
  • O conjunto específico de IPs do screenshot é interpretado como um float entre 0,2909 e 0,2943, uma diferença de 0,0034
  • Isso significa que 0,34% dos usuários da Mullvad compartilham esses IPs; em uma estimativa aproximada de 100.000 usuários ativos, isso corresponderia a 340 pessoas
  • Não é tão único quanto se imaginou no início, mas uma precisão acima de 99% ainda está longe de ser baixa
  • Por exemplo, se um administrador de fórum quiser verificar se uma nova conta é um sockpuppet de um usuário banido no dia anterior, e os logs de IP das duas contas indicarem intervalos de float sobrepostos como 0.4334 - 0.4428 e 0.4358 - 0.4423, então a probabilidade de serem a mesma pessoa passa de 99%, mesmo que as duas contas tenham usado servidores Mullvad diferentes
  • A mesma correlação pode ser aplicada a logs de IP obtidos em vazamentos de dados ou por procedimento legal, e o usuário por trás da VPN pode perder o anonimato

Como se proteger

  • A recomendação é não trocar de servidor mais de uma vez com a mesma pubkey
  • É possível sair da conta no app da Mullvad para forçar a rotação da pubkey

Leituras relacionadas

1 comentários

 
GN⁺ 3 시간 전
Comentários do Hacker News

  • Sou co-CEO e cofundador, e trabalho na Mullvad. Parte do comportamento descrito no texto foi intencional e parte não, e a causa não é exatamente a mesma explicada no post do blog
    Como mitigação, já estamos testando um patch para o comportamento não intencional em parte da infraestrutura, então, se você tentar reproduzir hoje, os resultados podem ficar confusos
    Também vamos reavaliar se o comportamento intencional é aceitável, e aqui há um equilíbrio entre vários aspectos de privacidade e a experiência do usuário
    Esse entendimento é minha avaliação atual, organizada enquanto escrevo isto e após ter tomado conhecimento há uma hora e discutido uma resposta imediata com a equipe de operações, então pode mudar
    Para quem faz pesquisa de segurança: ao encontrar problemas de segurança ou privacidade, mesmo que pretenda divulgar imediatamente, por favor avise antes os administradores ou o fornecedor

    • O cliente da Mullvad, por padrão, provavelmente tem um intervalo de rotação de chaves de 72 horas, e o cliente CLI também pode ser ajustado para funcionar na maioria dos cenários que usam WireGuard nativo
      Você pode verificar com mullvad tunnel get e alterar com mullvad tunnel set rotation-interval , e esse também é o método de mitigação preferido no texto
      Pessoalmente, não vejo IPs semiestáticos como um grande problema. O objetivo é bloquear vigilância em nível de rede por ISPs e governos, e algumas empresas até vendem IPv4 fixo como recurso
      Em uma VPN de privacidade, quanto menor o espaço de IPs, mais usuários podem se misturar atrás de um único IP visível externamente, o que também é uma vantagem. Combinando isso com técnicas como DAITA, que injetam tráfego falso no túnel, e pontos de entrada multihop, acho que isso realmente pode dificultar mais a vida de um observador que passa o dia inteiro analisando netflow
    • Sou Carl, CEO da Obscura e um dos parceiros da Mullvad. É uma descoberta interessante, mas, como kfreds disse, teria sido melhor avisar o fornecedor antes de publicar
      A descoberta principal, a correlação de posição no pool de IPs entre servidores, realmente parece incluir comportamento não intencional. Pela minha experiência trabalhando com a equipe da Mullvad, acho que isso será resolvido em breve
      Se você quer “identidades” diferentes, precisa rotacionar a chave do WireGuard ou usar chaves diferentes
      O artigo diz que “cada vez que você se conecta a um servidor, o IP de saída não é escolhido aleatoriamente, mas de forma determinística com base na chave WireGuard, e essa chave é rotacionada a cada 1–30 dias. Se você usa um cliente de terceiros, ela não é rotacionada”. Mas o WireGuard, por projetohttps://www.wireguard.com/protocol/, é um protocolo sem conexão, então não existe conceito de conexão; há apenas handshakes de rekeying a cada 2–3 minutos quando há tráfego
      Se o IP de saída mudasse a cada “conexão” mesmo com a mesma chave WireGuard — por exemplo, a cada handshake de rekeying ou a cada 15 minutos — então, na camada de transporte, quase todas as conexões dentro do túnel, exceto QUIC, cairiam e precisariam ser restabelecidas; e, na camada de aplicação, serviços que suspeitam de “mesmo cookie, IP novo” provocariam logout, CAPTCHA e pontuação de risco
      Ambos degradam a experiência do usuário e, pior, podem tornar o usuário mais fácil de identificar por fingerprint, algo como “essa pessoa continua se reconectando de IPs diferentes, então é usuário da Mullvad”

  • O exemplo de “um administrador de fórum suspeitou que uma conta nova era a conta alternativa de um usuário bloqueado no dia anterior, olhou os logs de IP e viu que, apesar de usarem servidores diferentes da Mullvad, as duas contas mapeavam para faixas sobrepostas de ponto flutuante, 0.4334~0.4428 e 0.4358~0.4423, então é possível considerar com mais de 99% de probabilidade que sejam a mesma pessoa” passa a sensação de que, se uma agência de inteligência projetasse uma VPN, faria algo assim

    • Não entendo por quê. Se uma agência de inteligência projetasse uma VPN, não dependeria de estatísticas dos nós de saída; simplesmente registraria em log todos os IPs que se conectam à VPN
      Além disso, esse método depende de o usuário escolher servidores diferentes, então haveria ainda menos motivo para isso
    • Acho que algum dia vai aparecer que a Cloudflare também tinha ligação com agência de inteligência. Se a solução para um “DDoS repentino” é colocar o site atrás da Cloudflare, dá vontade de perguntar quem seria capaz de provocar esse tipo de ataque repentino
    • Ainda sobra o pequeno detalhe de não armazenar logs
      Para mim isso é um problema grande, e permite análise de correlação entre vários nós de saída de VPN, mas é só isso
      Não torna possível identificar usuários automaticamente
      Mas reduz bastante a dificuldade de identificação, embora os requisitos ainda sejam altos. Espero que corrijam logo
      Não dá para acreditar que um erro do tipo “vamos fazer isso com um valor sensível, tipo um hash” ainda aconteça, ainda mais na Mullvad. Será que não dava para simplesmente randomizar?
    • A Mullvad existe desde alguns anos antes das revelações do Snowden, e não apareceu em nenhum daqueles materiais
      Claro que existem outras agências de inteligência, mas é com aquela que mais se deve preocupar. Porque ela poderia operar diretamente, conhecer a ideia e copiá-la, ou ter acesso a serviços operados por agências parceiras. Caso contrário, não seria uma ameaça para mim
      Além disso, não há casos públicos conhecidos de usuários da Mullvad desanonimizados por meio da VPN; o que se conhece são casos em que foram descobertos por outras falhas de segurança operacional. Se uma agência de inteligência tivesse essa capacidade, seria difícil acreditar que teria dados por quase 20 anos sem usar isso
    • Se uma agência de inteligência controlasse a VPN, bastaria monitorar o tráfego diretamente. Não há incentivo para facilitar a vida de um observador externo que quer adivinhar qual usuário sai por qual IP de saída

  • Não entendo como se chega a “mais de 99% de probabilidade” apenas com os números do texto. Mesmo assumindo fortemente que a seed do primeiro IP bloqueado e a seed do segundo estejam ambas no intervalo 0.4423~0.4358, isso só significaria que esse intervalo inclui 0,65% de todos os usuários da Mullvad
    Se houver 100 mil usuários, são 650 pessoas; ou seja, você eliminou mais de 99% dos “suspeitos”, mas não identificou um indivíduo com mais de 99% de precisão em vários IPs de saída
    Em termos bayesianos, a sobreposição de seeds potenciais é uma evidência forte de que os dois IPs pertencem à mesma pessoa, ou pelo menos à mesma conta Mullvad, mas não parece ser isso que o autor estava afirmando

    • Se o fórum for relativamente grande, com 1000 usuários ativos e 1 novo cadastro por dia, qual seria a probabilidade de alguém se cadastrar no dia seguinte a um banimento usando essa VPN e cair numa faixa de IP parecida?
      Para a maioria dos sites pequenos, isso seria uma evidência bastante forte

  • O objetivo de uma VPN não inclui anonimizar o usuário para os sites que visita, então não é surpreendente que a Mullvad não force IPs de saída únicos. Usuários que querem anonimato deveriam usar uma rede como Tor

    • Não vejo por que não. Não há motivo para que o objetivo de um serviço VPN específico não possa ser esse
    • O Tor não é um projeto do governo dos EUA, e não já foi mostrado que ele pode ser usado para desanonimização?
    • Esse é exatamente o propósito de uma VPN pública
      Se você usa uma VPN pública, quer que ninguém saiba quem está enviando a requisição, inclusive o IP de origem
      Por essa lógica, VPN não deveria ser usada para torrent, porque isso significaria que ela não deveria anonimizar o IP de origem. Mas, na prática, funciona muito bem para torrent
      Se você está falando de uma VPN privada, a Mullvad não é isso

  • Uso a Mullvad há muito tempo e vou continuar comprando e usando o serviço Mullvad VPN com meu cartão de crédito em meu nome, enquanto isso for legal no meu país
    VPN não é 100% anônima, e nem foi projetada para isso. Em vez disso, serve para oferecer algum nível de privacidade a adultos que cumprem a lei
    A maioria das pessoas ficaria constrangida se colegas e vizinhos soubessem sobre sua vida privada, do que gosta, o que compra e o que faz. Por isso, a maioria deveria usar VPN para proteger sua privacidade
    Por definição, “a maioria das pessoas” não quer nem espera 100% de anonimato online; só quer um pouco de privacidade na vida pessoal e nos relacionamentos
    VPN não protege criminosos que querem cometer crimes online e serem 100% anônimos diante do governo, nem foi feita para isso. Essa distinção é importante. “A maioria das pessoas” não é criminosa e não tem esse tipo de expectativa irrealista em relação à Mullvad ou a outros provedores de VPN

    • VPN não é anonimato, embora as pessoas finjam que seja. Ainda assim, a descoberta deste relatório mostra um fator que torna a identificação de usuários mais fácil do que o esperado
      Não dá para descartar o relatório só com a lógica acima. A descoberta em si continua válida

  • Falta uma coisa. Fiquei curioso se entraram em contato com a Mullvad. Também teria sido interessante ver como a equipe de segurança respondeu

    • Até onde eu sei, não houve contato, e confirmei isso tanto com a equipe de operações quanto com a de suporte. Se eu estiver errado, vou atualizar este comentário
      Depois acabei me arrependendo de ter feito este comentário. Foi desnecessário, mas agora apagar pareceria estranho
    • Não, mas o comentário mais votado no topo desta postagem é justamente a resposta do cofundador da Mullvad

  • Acho surpreendente que as pessoas esperem que uma VPN seja parecida com o Tor
    Quando você coloca assim por extenso, parece não fazer sentido, e também é preciso lembrar que, se você controlar o nó de saída, até usuários do Tor podem ser desanonimizados

    • Não é surpreendente, já que a maioria das grandes VPNs de consumo sugere em seu marketing “privacidade” como se fosse anonimato
    • Parte do design do Tor não é justamente passar por vários nós de relay, de forma que o nó de saída também não veja o IP de origem?
    • Pode não ser esperado, mas, se for possível, eu esperaria que tentassem fazer o que desse para oferecer privacidade

  • A parte que diz “o IP de saída não é randomizado a cada conexão, mas escolhido de forma determinística com base na chave WireGuard, e essa chave é rotacionada a cada 1–30 dias. Se você usa um cliente de terceiros, ela nunca é rotacionada” é um pouco confusa
    Se o repositório detalha o método, não entendo o que impede terceiros de fazer rotação de chaves como o cliente oficial faz

    • Clientes de terceiros incluem, por exemplo, o driver WireGuard do kernel Linux. Não dá para esperar que um driver de rede assuma a tarefa de mitigar ataques contra um único serviço comercial específico
    • Principalmente, o que impede é saber que isso precisa ser feito

  • O autor encontrou isso muito bem, e é totalmente crível que tenha sido um erro da Mullvad. É bem chocante que algo tão simples tenha passado batido, embora eu mesmo pudesse ter deixado passar
    Tirando a correlação de IP entre vários servidores, no começo também me perguntei por que manter o IP do usuário estável dentro de um mesmo servidor. Mas a explicação do autor faz sentido: é uma forma de imitar outras VPNs, que normalmente têm um IP por servidor
    Se o usuário encontra um servidor que consegue acessar um determinado serviço, há a vantagem de que, ao se reconectar àquele servidor, pode receber o mesmo IP e voltar a funcionar
    Já a correlação de IP entre vários servidores deveria ser corrigida com algo como rand.seed(user_pub_key + server_id)

    • Por outro lado, se um vizinho barulhento no mesmo IP fizer você ser bloqueado em algum serviço, então o usuário não teria como contornar isso, certo?

  • Trabalho na IPinfo. Nós atuamos no mercado de detecção de VPN, mas, honestamente, quero interpretar isso de forma benevolente no caso da Mullvad
    A Mullvad foi um dos três provedores de VPN que não tentaram enviar dados falsos de geolocalização de IP para provedores como nós. Tenho certeza de que também vão corrigir esse problema

    • Quais foram os outros?