Les IP de sortie de Mullvad sont étonnamment faciles à identifier

 (tmctmt.com)
1 points par GN⁺ 3 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Mullvad place plusieurs IP de sortie sur un même serveur, mais leur attribution est déterministe à partir de la clé WireGuard et ne change donc pas aléatoirement à chaque connexion
  • Sur 9 serveurs, 3 650 points de données collectés en modifiant à répétition la clé publique n’ont été attribués qu’à 284 combinaisons parmi 8,2 billions de combinaisons possibles
  • Les IP de sortie de chaque serveur se situent à une position percentile similaire dans leur pool, et une même combinaison tombe globalement autour du 81e percentile sur plusieurs serveurs
  • La cause semble être une structure où l’index d’IP de sortie est choisi par un RNG basé sur une seed, utilisant la clé publique ou l’adresse du tunnel comme seed et la taille du pool comme borne supérieure
  • Si les plages de flottants issues des journaux IP se chevauchent, il devient possible de corréler des comptes même en utilisant différents serveurs Mullvad, ce qui augmente le risque pour l’anonymat

Comment les IP de sortie de Mullvad deviennent un vecteur d’identification

  • Mullvad propose plusieurs IP de sortie par serveur, et deux utilisateurs connectés au même serveur reçoivent généralement des IP publiques différentes
  • Le nombre de serveurs est de 578, contre 20 000 pour Proton VPN ; cette montée en charge verticale, qui évite de concentrer trop d’utilisateurs sur une même IP, aide à limiter les blocages d’IP excessifs et le throttling
  • Mais à chaque connexion à un serveur, l’IP de sortie ne change pas aléatoirement : elle est sélectionnée de manière déterministe à partir de la clé WireGuard
  • La clé WireGuard est renouvelée tous les 1 à 30 jours, mais ce n’est pas le cas avec les clients tiers
  • Si chaque serveur attribue indépendamment une IP de sortie fixe, il devient possible de distinguer un utilisateur des autres utilisateurs de Mullvad rien qu’avec la combinaison d’IP de quelques serveurs

Combinaisons d’IP de sortie observées sur 9 serveurs

  • Un script a tourné toute la nuit en modifiant la clé publique de façon répétée pour collecter les IP de sortie sur 9 serveurs, ce qui a permis d’obtenir 3 650 points de données de clés publiques
  • Les plages d’IP de sortie observées sur ces serveurs sont les suivantes
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
  • En multipliant la taille des pools de ces serveurs, on pourrait penser qu’il existe plus de 8,2 billions de combinaisons possibles d’IP de sortie
  • En pratique, toutes les clés publiques testées n’ont été attribuées qu’à l’une des 284 combinaisons
  • Le très faible nombre de combinaisons observées par rapport au nombre théorique constitue un indice que la sélection des IP n’est pas indépendante d’un serveur à l’autre

Le motif de différentes IP situées au même percentile

  • La position numérique d’une IP de sortie peut être calculée selon sa distance par rapport à l’IP de début du pool
  • Par exemple, sur au-syd-wg-101, 103.136.147.53 a un index 1-based de 49 si l’on compte à partir de 103.136.147.5
  • Si l’on divise la position des IP observées dans chaque combinaison par la taille du pool du serveur correspondant, on obtient presque le même ratio sur des serveurs différents
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
  • Chaque IP se situe à un percentile similaire dans son pool, et l’exemple ci-dessus correspond globalement au 81e percentile
  • Ce motif donne l’impression que Mullvad n’attribue, sur tous les serveurs, que des IP de sortie situées à des positions voisines

Une cause probable : une sélection pseudo-aléatoire basée sur une seed

  • cl-scl-wg-001 et za-jnb-wg-002 partagent toujours le même index d’IP dans l’ensemble des 284 combinaisons observées
  • Leur point commun est une taille de pool de 11, ce qui correspond bien à un appel pseudo-aléatoire produisant le même résultat à partir d’une seed identique et de bornes identiques
  • Si un RNG est initialisé avec une seed statique puis tire un nombre aléatoire dans la même plage, le même résultat se répète
  • Mullvad semble choisir l’index d’IP de sortie via un RNG basé sur une seed, en utilisant la clé publique ou l’adresse du tunnel comme seed et la taille du pool comme borne supérieure
  • Même si les bornes changent, le pool d’entropie du RNG ne semble pas affecté ; en Rust, cela correspond à un fonctionnement où le même flottant est généré au premier appel puis multiplié par les bornes
  • Ce comportement peut se résumer grossièrement par min + round((max - min) * float), même si cette formulation est probablement très simplifiée
  • À cause de cette propriété, même lorsque la taille des pools diffère, le flottant issu d’une même seed est mappé vers un point de ratio similaire dans le pool de chaque serveur
  • Comme le client Mullvad est écrit en Rust, il est possible que Rust soit aussi utilisé côté back-end, mais cette hypothèse repose uniquement sur l’implémentation cliente
  • Il est difficile de prédire précisément le comportement de random_range lorsque les bornes changent ; on pourrait penser qu’une borne plus grande se mélange à l’entropie pour produire un autre nombre, mais ce n’est pas ce que montrent les observations

Risque pour l’anonymat via la corrélation des journaux d’IP

  • Un outil permettant d’estimer les valeurs flottantes minimales et maximales possibles pour une combinaison donnée d’IP est disponible ici : mullvad-seed-estimator
  • Dans la capture d’écran, un ensemble précis d’IP est interprété comme une valeur flottante comprise entre 0.2909 et 0.2943, soit un écart de 0.0034
  • Cela signifie que 0,34 % des utilisateurs de Mullvad partagent ces IP ; avec une estimation grossière de 100 000 utilisateurs actifs, cela représenterait 340 personnes
  • Ce n’est pas aussi unique qu’on aurait pu l’imaginer au départ, mais une précision supérieure à 99 % reste loin d’être négligeable
  • Par exemple, si un modérateur de forum veut vérifier si un nouveau compte est le sockpuppet d’un utilisateur banni la veille, et que les deux comptes utilisent des serveurs Mullvad différents, la probabilité qu’il s’agisse de la même personne dépasse 99 % si les journaux IP montrent des plages de flottants qui se chevauchent, comme 0.4334 - 0.4428 et 0.4358 - 0.4423
  • Le même type de corrélation peut aussi s’appliquer à des journaux d’IP obtenus via une fuite de données ou une procédure judiciaire, ce qui peut faire perdre leur anonymat à des utilisateurs pourtant derrière un VPN

Comment se protéger

  • Il est recommandé de ne pas changer de serveur plus d’une fois par clé publique
  • On peut forcer la rotation de la clé publique en se déconnectant de l’application Mullvad

À lire aussi

1 commentaires

 
GN⁺ 3 시간 전
Commentaires Hacker News

  • Je suis co-CEO et cofondateur de Mullvad. Une partie du comportement décrit dans l’article est intentionnelle, une autre ne l’est pas, et la cause n’est pas exactement celle expliquée dans le billet de blog
    Côté atténuation, nous testons déjà un correctif pour le comportement non intentionnel sur une partie de l’infrastructure, donc si vous essayez de reproduire aujourd’hui, les résultats pourraient être déroutants
    Nous allons aussi réévaluer si le comportement intentionnel reste acceptable, car il y a ici un compromis entre plusieurs aspects de confidentialité et l’expérience utilisateur
    C’est ma compréhension actuelle, construite en une heure depuis que je l’ai appris, en discutant immédiatement de la réponse avec l’équipe opérations et en rédigeant ce message ; elle peut donc évoluer
    J’aimerais que les chercheurs en sécurité, lorsqu’ils trouvent des problèmes de sécurité ou de confidentialité, préviennent d’abord les administrateurs ou l’éditeur, même s’ils prévoient de publier rapidement ensuite

    • Le client Mullvad a par défaut une période de rotation des clés d’environ 72 heures, et le client CLI peut aussi fonctionner dans la plupart des cas avec du WireGuard natif, avec quelques ajustements
      On peut le vérifier avec mullvad tunnel get et le modifier avec mullvad tunnel set rotation-interval ; c’est aussi la méthode d’atténuation privilégiée dans l’article
      Personnellement, je ne considère pas qu’une IP semi-stable soit un gros problème. L’objectif est d’empêcher la surveillance au niveau réseau par les FAI et les gouvernements, et certains fournisseurs vendent même une IPv4 fixe comme fonctionnalité
      Pour un VPN orienté confidentialité, plus l’espace d’adresses IP est petit, plus il y a d’utilisateurs mélangés derrière une même IP vue de l’extérieur, ce qui peut aussi être un avantage. En combinant des technologies comme DAITA, qui injectent du trafic factice dans le tunnel, avec des points d’entrée multihop, je pense qu’on peut réellement compliquer la tâche d’un surveillant qui examine les netflows toute la journée
    • Je suis Carl, CEO d’Obscura et l’un des partenaires de Mullvad. C’est une découverte intéressante, mais comme l’a dit kfreds, il aurait été préférable de prévenir l’éditeur avant la publication
      La découverte principale, à savoir la corrélation de position dans le pool d’IP entre serveurs, semble effectivement inclure un comportement non intentionnel. Pour avoir déjà travaillé avec l’équipe Mullvad, je pense que ce sera traité rapidement
      Si vous voulez des « identités » différentes, il faut faire tourner la clé WireGuard ou utiliser des clés différentes
      L’article dit que « l’IP de sortie n’est pas choisie aléatoirement à chaque connexion au serveur, mais déterministement à partir de la clé WireGuard, et cette clé est remplacée tous les 1 à 30 jours. Avec un client tiers, elle n’est pas remplacée ». Mais WireGuard est, par conception https://www.wireguard.com/protocol/, un protocole sans connexion ; il n’y a donc pas de notion de connexion, seulement un handshake de rekeying toutes les 2 à 3 minutes lorsqu’il y a du trafic
      Si, avec la même clé WireGuard, l’IP de sortie changeait à chaque « connexion » — par exemple à chaque handshake de rekeying ou toutes les 15 minutes — alors, au niveau transport, presque toutes les connexions à l’intérieur du tunnel, sauf QUIC, seraient interrompues puis devraient être rétablies ; et au niveau applicatif, les services qui suspectent le schéma « même cookie, nouvelle IP » provoqueraient déconnexion, CAPTCHA et score de risque
      Dans les deux cas, l’expérience utilisateur serait mauvaise et, pire encore, cela pourrait rendre l’empreinte de l’utilisateur plus distinctive : « cette personne se reconnecte sans cesse depuis des IP différentes, c’est donc un utilisateur de Mullvad »

  • L’exemple disant que « l’administrateur d’un forum a soupçonné qu’un nouveau compte était le double compte d’un utilisateur banni la veille, a regardé les logs d’IP et a constaté que, bien que les deux comptes utilisent des serveurs Mullvad différents, ils se projettent dans les plages flottantes qui se chevauchent 0.4334~0.4428 et 0.4358~0.4423, ce qui permet de conclure avec plus de 99 % de probabilité qu’il s’agit de la même personne » donne l’impression que c’est ainsi qu’un service de renseignement concevrait un VPN

    • Je ne vois pas pourquoi. Si un service de renseignement concevait un VPN, il ne s’appuierait pas sur des statistiques de nœuds de sortie ; il journaliserait simplement toutes les IP qui se connectent au VPN
      En plus, comme cette méthode dépend du fait que l’utilisateur choisisse différents serveurs, il y aurait encore moins de raison de faire ça
    • J’ai l’impression qu’un jour on découvrira aussi que Cloudflare avait des liens avec les services de renseignement. Si la solution à une « DDoS soudaine » consiste à mettre un site derrière Cloudflare, on peut aussi se demander qui est capable de lancer ce genre d’attaque soudaine
    • Il reste quand même ce petit détail de ne pas conserver de logs
      Pour moi, c’est un problème important, et cela permet une analyse de corrélation entre plusieurs nœuds de sortie VPN, mais pas plus. Cela ne permet pas d’identifier automatiquement les utilisateurs
      En revanche, cela réduit fortement la difficulté d’identification, même si les prérequis restent élevés. J’espère que ce sera corrigé rapidement
      J’ai du mal à croire qu’une erreur du type « faisons-le à partir d’une valeur sensible comme un hash » arrive encore, et chez Mullvad en plus. Pourquoi ne pas avoir simplement randomisé ?
    • Mullvad existait plusieurs années avant les révélations de Snowden, et n’apparaît dans aucun de ces documents
      Bien sûr, il existe d’autres services de renseignement, mais c’est celui-là qui serait le plus préoccupant. Soit ils l’exploiteraient directement, soit ils auraient connu l’idée et l’auraient reproduite, soit ils auraient un accès à un service exploité par une agence partenaire. Sinon, cela ne constituerait pas une menace pour moi
      Par ailleurs, il n’existe pas d’exemple public connu d’utilisateur Mullvad désanonymisé via le VPN ; les cas connus ont été découverts à cause d’autres échecs d’opsec. Si un service de renseignement avait eu cette capacité, il est difficile de croire qu’il aurait conservé ces données pendant presque 20 ans sans s’en servir
    • Si un service de renseignement contrôle un VPN, il lui suffit de surveiller directement le trafic. Il n’a aucun intérêt à faciliter les déductions d’un observateur externe sur l’IP de sortie utilisée par tel utilisateur

  • Je ne vois pas comment on obtient « plus de 99 % de probabilité » à partir des seuls chiffres de l’article. Même en supposant fortement que la seed de la première IP bannie et la seconde seed se situent toutes deux dans l’intervalle 0.4423~0.4358, cela veut seulement dire que cette plage couvre 0,65 % de l’ensemble des utilisateurs Mullvad
    Sur 100 000 utilisateurs, cela en fait 650, donc cela élimine « plus de 99 % » des suspects, mais n’identifie pas une personne donnée à plus de 99 % de précision à travers plusieurs IP de sortie
    Raisonné en termes bayésiens, le chevauchement de seeds potentielles constitue bien une preuve solide que les deux IP appartiennent à la même personne, ou au moins au même compte Mullvad, mais cela ne semble pas être ce que l’auteur affirme

    • Si le forum est assez grand, avec 1 000 utilisateurs actifs et 1 nouvel inscrit par jour, je me demande quelle est la probabilité que, le lendemain d’un bannissement, quelqu’un utilisant ce VPN s’inscrive et obtienne une IP dans une plage similaire
      Pour la plupart des petits sites web, cela reste un indice assez fort

  • L’objectif d’un VPN n’inclut pas l’anonymisation de l’utilisateur vis-à-vis des sites visités, donc il n’y a rien d’étonnant à ce que Mullvad ne force pas des IP de sortie uniques. Les utilisateurs qui veulent de l’anonymat doivent utiliser un réseau comme Tor

    • Je ne vois pas pourquoi ce ne serait pas possible. Rien n’empêche qu’un service VPN donné ait justement cet objectif
    • Tor est un projet du gouvernement américain, et on n’a pas déjà montré qu’il était possible de désanonymiser ses utilisateurs ?
    • C’est précisément l’objectif d’un VPN public
      Quand on utilise un VPN public, on voudrait que personne ne sache qui envoie les requêtes, y compris l’IP terminale
      Avec cette logique, il ne faudrait pas utiliser de VPN pour le torrent, puisqu’il ne devrait pas anonymiser l’IP terminale. Pourtant, en pratique, ça fonctionne très bien pour ça
      Si vous parlez d’un VPN privé, alors Mullvad n’est pas de cette catégorie

  • J’utilise Mullvad depuis longtemps, et tant que c’est légal dans mon pays, je continuerai à acheter et utiliser le service Mullvad VPN avec une carte bancaire à mon nom
    Un VPN n’est pas anonyme à 100 %, et il n’a jamais été conçu pour l’être. En revanche, il vise à offrir un certain niveau de confidentialité à des adultes respectueux de la loi
    La plupart des gens seraient gênés si leurs collègues et leurs voisins connaissaient leur vie privée, ce qu’ils aiment, ce qu’ils achètent et ce qu’ils font. C’est pourquoi la plupart des gens devraient utiliser un VPN pour protéger leur vie privée
    Par définition, « la plupart des gens » ne veulent ni n’attendent un anonymat total en ligne ; ils veulent simplement un peu de confidentialité dans leur vie personnelle et leurs relations
    Un VPN ne protège pas, et n’a pas vocation à protéger, des criminels qui veulent commettre des délits en ligne tout en restant anonymes à 100 % face au gouvernement. Cette distinction est importante. « La plupart des gens » ne sont pas des criminels et n’ont pas ce type d’attentes irréalistes envers Mullvad ou d’autres fournisseurs de VPN

    • Un VPN n’est pas anonyme, même si les gens font comme si. Cela dit, les découvertes de ce rapport montrent des éléments qui rendent l’identification des utilisateurs plus facile qu’attendu
      On ne peut pas écarter le rapport sur la seule base de cette logique. La découverte elle-même reste valide

  • Il manque quelque chose. Je me demande si Mullvad a été contacté. Il aurait aussi été intéressant de voir comment l’équipe sécurité a réagi

    • À ma connaissance, il n’y a eu aucun contact ; j’ai vérifié à la fois auprès de l’équipe opérations et de l’équipe support. Si je me trompe, je mettrai ce message à jour
      Après coup, je regrette d’avoir posté ce commentaire. C’était inutile, mais le supprimer maintenant semblerait bizarre
    • Non, mais le commentaire le plus voté tout en haut de ce billet est justement la réponse du cofondateur de Mullvad

  • Je trouve surprenant que des gens s’attendent à ce qu’un VPN soit similaire à Tor
    Présenté ainsi, cela paraît absurde, et il faut aussi garder à l’esprit qu’il est possible de désanonymiser même des utilisateurs de Tor si l’on contrôle les nœuds de sortie

    • Ce n’est peut-être pas une attente justifiée, mais quand la plupart des grands VPN grand public suggèrent en marketing que la « confidentialité » équivaut à de l’anonymat, ce n’est pas si surprenant
    • Une partie du design de Tor n’est-elle pas justement de passer par plusieurs nœuds relais, de sorte que même le nœud de sortie ne voit pas l’IP d’origine ?
    • Ce n’est peut-être pas ce qu’on devrait attendre, mais on peut penser qu’ils essaieraient de faire ce qu’ils peuvent pour offrir de la confidentialité quand c’est possible

  • Le passage disant que « l’IP de sortie n’est pas randomisée à chaque connexion, mais sélectionnée déterministement à partir de la clé WireGuard, laquelle est remplacée tous les 1 à 30 jours. Avec un client tiers, elle n’est jamais remplacée » est un peu déroutant
    Si la méthode est décrite en détail dans le dépôt, je ne vois pas ce qui empêcherait un tiers de faire la rotation des clés comme le client applicatif par défaut

    • Les clients tiers incluent par exemple le pilote WireGuard du noyau Linux. On ne peut pas demander à un pilote réseau de prendre en charge l’atténuation d’une attaque visant un service commercial spécifique
    • Ce qui bloque surtout, c’est de savoir qu’il faut le faire

  • L’auteur a bien trouvé le problème, et il est tout à fait crédible qu’il s’agisse d’une erreur de Mullvad. C’est assez choquant qu’une chose aussi simple soit passée à travers, même si j’aurais moi aussi pu ne pas la voir
    En dehors de la corrélation d’IP entre plusieurs serveurs, je me demandais au départ pourquoi ils maintenaient aussi une IP utilisateur stable sur un même serveur. Mais l’explication de l’auteur — à savoir imiter les autres VPN qui ont généralement une IP par serveur — se tient
    Cela a l’avantage que si un utilisateur trouve un serveur qui accède à un service donné, il a des chances d’obtenir à nouveau la même IP en se reconnectant à ce serveur, et donc que cela refonctionne
    En revanche, la corrélation d’IP entre plusieurs serveurs devrait être corrigée avec quelque chose comme rand.seed(user_pub_key + server_id)

    • À l’inverse, si l’utilisateur est bloqué d’un service à cause d’un voisin bruyant sur la même IP, il n’a alors aucun moyen de contourner ça, non ?

  • Je travaille chez IPinfo. Nous faisons de la détection de VPN, mais honnêtement, j’ai envie d’accorder à Mullvad le bénéfice du doute
    Mullvad faisait partie des trois seuls fournisseurs VPN qui n’essayaient pas de soumettre de fausses données de géolocalisation IP à des fournisseurs comme nous. Je suis certain qu’ils corrigeront aussi ce problème

    • Qui étaient les autres ?