Mullvad-Exit-IPs sind überraschend gut identifizierbar

 (tmctmt.com)
1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Mullvad weist einem einzelnen Server mehrere Exit-IPs zu, ordnet sie aber anhand des WireGuard-Schlüssels deterministisch zu, statt sie bei jeder Verbindung zufällig zu wechseln
  • 3.650 Datenpunkte, gesammelt auf 9 Servern durch wiederholtes Ändern des Pubkeys, wurden nur 284 Kombinationen zugewiesen – bei theoretisch 8,2 Billionen möglichen Kombinationen
  • Die Exit-IPs jedes Servers liegen innerhalb ihres Pools an ähnlichen Perzentil-Positionen; eine Kombination landet auf mehreren Servern meist ungefähr beim 81. Perzentil
  • Die Ursache scheint eine seed-basierte RNG zur Auswahl des Exit-IP-Index zu sein, die Pubkey oder Tunnel-Adresse als Seed und die Pool-Größe als Obergrenze verwendet
  • Wenn sich Float-Bereiche in IP-Logs überschneiden, werden Korrelationen zwischen Konten möglich, selbst wenn unterschiedliche Mullvad-Server genutzt wurden – das erhöht das Anonymitätsrisiko

Wie Mullvad-Exit-IPs zu einem Fingerprinting-Vektor werden

  • Mullvad bietet pro Server mehrere Exit-IPs an; zwei Nutzer, die sich mit demselben Server verbinden, erhalten normalerweise unterschiedliche öffentliche IPs
  • Die Zahl der Server liegt bei 578, deutlich weniger als Proton VPNs 20.000. Vertikale Skalierung, bei der Nutzer nicht auf dieselbe IP gedrängt werden, ist vorteilhaft, um übermäßige IP-Sperren und Throttling zu vermeiden
  • Allerdings wechselt die Exit-IP nicht bei jeder Verbindung zufällig, sondern wird deterministisch auf Basis des WireGuard-Schlüssels ausgewählt
  • WireGuard-Schlüssel werden zwar alle 1 bis 30 Tage rotiert, bei Drittanbieter-Clients geschieht diese Rotation jedoch nicht
  • Wenn jedem Server unabhängig eine feste Exit-IP zugewiesen wird, kann schon die IP-Kombination über einige Server hinweg ausreichen, um einen Nutzer von anderen Mullvad-Nutzern zu unterscheiden

Auf 9 Servern beobachtete Exit-IP-Kombinationen

  • Ein Skript, das den Pubkey wiederholt ändert und die Exit-IPs von 9 Servern einsammelt, lief über Nacht und lieferte 3.650 Pubkey-Datenpunkte
  • Die Exit-IP-Bereiche dieser Server wurden wie folgt beobachtet
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
  • Multipliziert man die Pool-Größen dieser Server, scheinen mehr als 8,2 Billionen Exit-IP-Kombinationen möglich zu sein
  • In den tatsächlichen Tests wurde jeder Pubkey jedoch nur einer von 284 Kombinationen zugewiesen
  • Die Zahl der beobachteten Kombinationen ist im Verhältnis zu den theoretisch möglichen extrem klein – ein Hinweis darauf, dass die IP-Auswahl pro Server nicht unabhängig erfolgt

Das Muster: unterschiedliche IPs liegen im selben Perzentil

  • Die numerische Position einer Exit-IP lässt sich als Abstand zur Start-IP des jeweiligen Pools berechnen
  • Auf au-syd-wg-101 hat zum Beispiel 103.136.147.53, von 103.136.147.5 aus gezählt, einen 1-basierten Index von 49
  • Teilt man die beobachteten IP-Positionen durch die jeweilige Pool-Größe des Servers, ergibt sich auch auf unterschiedlichen Servern nahezu derselbe Anteil
Server IP Position Pool-Größe Verhältnis
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
  • Jede IP liegt also an einem ähnlichen Perzentil innerhalb ihres Pools; das obige Beispiel entspricht grob dem 81. Perzentil
  • Aufgrund dieses Musters wirkt es so, als würde Mullvad auf allen Servern nur Exit-IPs aus benachbarten Positionen zuweisen

Vermutete Ursache: seed-basierte Zufallsauswahl

  • cl-scl-wg-001 und za-jnb-wg-002 teilen sich in allen beobachteten 284 IP-Kombinationen stets denselben IP-Index
  • Gemeinsam ist beiden Servern eine Pool-Größe von 11, was zu einem Zufallsaufruf mit identischem Seed und identischen Bounds passt, der denselben Wert liefert
  • Wird eine RNG mit einem statischen Seed initialisiert und anschließend in demselben Bereich eine Zufallszahl gezogen, wiederholt sich dasselbe Ergebnis
  • Offenbar wählt Mullvad den Exit-IP-Index mit einer seed-basierten RNG, die Pubkey oder Tunnel-Adresse als Seed nutzt und die Pool-Größe als Obergrenze verwendet
  • Auch wenn sich die Bounds ändern, scheint der Entropie-Pool der RNG nicht beeinflusst zu werden; in Rust passt das zu einem Verhalten, bei dem beim ersten Aufruf derselbe Float erzeugt und mit den Bounds multipliziert wird
  • Das lässt sich vereinfacht als min + round((max - min) * float) ausdrücken, auch wenn diese Darstellung eine starke Vereinfachung sein kann
  • Dadurch wird derselbe aus dem Seed abgeleitete Float trotz unterschiedlicher Pool-Größen auf ähnliche relative Positionen in den Server-Pools abgebildet
  • Der Mullvad-Client ist in Rust geschrieben, daher könnte auch das Backend Rust verwenden – mehr als eine Vermutung auf Basis der Client-Implementierung ist das jedoch nicht
  • Wie genau sich random_range bei veränderten Bounds verhält, ist schwer präzise vorherzusagen; intuitiv würde man erwarten, dass größere Bounds mit der Entropie vermischt werden und andere Werte erzeugen, doch die Beobachtungen sprechen dagegen

Anonymitätsrisiko durch Korrelation von IP-Logs

  • Ein Werkzeug zur Schätzung der minimalen und maximalen möglichen Float-Werte für eine bestimmte IP-Kombination steht als mullvad-seed-estimator bereit
  • Die im Screenshot gezeigte IP-Menge wird als Float-Wert zwischen 0.2909 und 0.2943 interpretiert; die Differenz beträgt 0.0034
  • Das bedeutet, dass 0,34 % der Mullvad-Nutzer diese IPs teilen; bei einer groben Schätzung von 100.000 aktiven Nutzern entspräche das 340 Personen
  • Es ist also nicht ganz so einzigartig wie zunächst angenommen, aber eine Genauigkeit von über 99 % ist keineswegs gering
  • Wenn etwa ein Forenadministrator prüfen will, ob ein neuer Account ein Sockpuppet eines am Vortag gesperrten Nutzers ist, und die IP-Logs der beiden Konten überlappende Float-Bereiche wie 0.4334 - 0.4428 und 0.4358 - 0.4423 zeigen, liegt die Wahrscheinlichkeit, dass beide derselben Person gehören, bei über 99 % – selbst wenn unterschiedliche Mullvad-Server verwendet wurden
  • Dieselbe Art von Korrelation lässt sich auch auf IP-Logs anwenden, die durch Datenlecks oder rechtliche Verfahren erlangt wurden; dadurch könnten Nutzer hinter einem VPN ihre Anonymität verlieren

Schutzmaßnahmen

  • Empfohlen wird, pro Pubkey den Server nicht mehr als einmal zu wechseln
  • In der Mullvad-App kann man sich abmelden, um eine erzwungene Rotation des Pubkeys auszulösen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Hacker-News-Kommentare

  • Ich bin Co-CEO und Mitgründer und arbeite bei Mullvad. Ein Teil des im Artikel beschriebenen Verhaltens ist beabsichtigt, ein Teil nicht, und die Ursache ist nicht exakt so, wie sie im Blogpost beschrieben wird
    Als Gegenmaßnahme testen wir für das unbeabsichtigte Verhalten bereits einen Patch auf Teilen der Infrastruktur, daher können die Ergebnisse verwirrend sein, wenn man heute versucht, es zu reproduzieren
    Auch das beabsichtigte Verhalten werden wir erneut daraufhin prüfen, ob es akzeptabel ist; dabei gibt es Abwägungen zwischen verschiedenen Privacy-Aspekten und der User Experience
    Das ist meine aktuelle Einschätzung, nachdem ich vor einer Stunde davon erfahren und sofort mit dem Betriebsteam über eine Reaktion gesprochen und beim Schreiben dieses Kommentars meine Gedanken sortiert habe; sie kann sich also noch ändern
    Wer Sicherheitsforschung betreibt, sollte Administratoren oder den Hersteller bitte zuerst informieren, wenn Sicherheits- oder Privacy-Probleme gefunden werden, selbst wenn eine unmittelbare Veröffentlichung geplant ist

    • Beim Mullvad-Client beträgt das Schlüsselrotationsintervall standardmäßig vermutlich 72 Stunden, und mit etwas Anpassung lässt sich der CLI-Client in den meisten Szenarien mit nativem WireGuard ebenfalls verwenden
      Das lässt sich mit mullvad tunnel get prüfen und mit mullvad tunnel set rotation-interval ändern; das ist auch die im Artikel bevorzugte Gegenmaßnahme
      Ich persönlich halte semistatische IPs nicht für ein großes Problem. Das Ziel ist, Netzwerküberwachung auf ISP- und Regierungsebene zu verhindern, und manche Anbieter verkaufen feste IPv4-Adressen sogar als Feature
      Bei einem Privacy-VPN kann ein kleinerer IP-Adressraum sogar ein Vorteil sein, weil sich aus externer Sicht mehr Nutzer hinter einer einzelnen IP mischen. In Kombination mit Techniken wie DAITA, die Dummy-Traffic in den Tunnel einfügen, und Multi-Hop-Einstiegspunkten kann das es für einen Beobachter, der den ganzen Tag NetFlow-Daten analysiert, tatsächlich schwerer machen
    • Ich bin Carl, CEO von Obscura und einer der Partner von Mullvad. Interessanter Fund, aber wie kfreds sagte, wäre es besser gewesen, den Hersteller vor der Veröffentlichung zu informieren
      Der zentrale Fund, nämlich die Korrelation der Position im IP-Pool zwischen Servern, scheint tatsächlich unbeabsichtigtes Verhalten zu beinhalten. Nach meiner Erfahrung aus der Zusammenarbeit mit dem Mullvad-Team wird das wohl bald behoben
      Wenn man unterschiedliche „Identitäten“ möchte, muss man den WireGuard-Schlüssel rotieren oder unterschiedliche Schlüssel verwenden
      Im Artikel heißt es: „Bei jeder Verbindung zu einem Server wird die Exit-IP nicht zufällig gewählt, sondern deterministisch anhand des WireGuard-Schlüssels, und dieser Schlüssel wird alle 1 bis 30 Tage rotiert. Bei Drittanbieter-Clients passiert das nicht.“ Aber WireGuard ist laut Design https://www.wireguard.com/protocol/ ein verbindungsloses Protokoll, es gibt also keinen Verbindungsbegriff; es gibt nur alle 2 bis 3 Minuten einen Re-Keying-Handshake, wenn Traffic fließt
      Wenn sich bei demselben WireGuard-Schlüssel die Exit-IP bei jeder „Verbindung“ ändern würde, etwa bei jedem Re-Keying-Handshake oder alle 15 Minuten, dann würden auf der Transportschicht fast alle Verbindungen innerhalb des Tunnels außer QUIC abbrechen und neu aufgebaut werden müssen, und auf der Anwendungsschicht würden Dienste, die „gleiches Cookie, neue IP“ verdächtig finden, Logouts, CAPTCHAs und Risikobewertungen auslösen
      Beides ist schlecht für die User Experience und könnte noch schlimmer dazu führen, dass Nutzer eindeutiger fingerprintbar werden, etwa nach dem Muster „diese Person verbindet sich ständig von anderen IPs neu, also ist sie Mullvad-Nutzer“

  • Das Beispiel „Ein Forenbetreiber sah in die IP-Logs, weil er vermutete, dass es sich um einen Zweitaccount eines am Vortag gesperrten Nutzers handelte, und obwohl unterschiedliche Mullvad-Server verwendet wurden, ließen sich beide Accounts auf überlappende Fließkomma-Bereiche von 0,4334–0,4428 und 0,4358–0,4423 abbilden, sodass man mit über 99 % Wahrscheinlichkeit von derselben Person ausgehen könne“ vermittelt das Gefühl, dass ein Geheimdienst ein VPN genau so bauen würde

    • Ich verstehe nicht, warum. Wenn ein Geheimdienst ein VPN bauen würde, würde er sich nicht auf Exit-Node-Statistiken verlassen, sondern einfach Logs aller IPs führen, die sich mit dem VPN verbinden
      Außerdem hängt diese Methode davon ab, dass Nutzer unterschiedliche Server auswählen, also erst recht kein plausibler Ansatz
    • Irgendwann wird wohl herauskommen, dass auch Cloudflare Verbindungen zu Geheimdiensten hat. Wenn die Lösung für „plötzliche DDoS-Angriffe“ darin besteht, Websites hinter Cloudflare zu stellen, fragt man sich schon, wer zu solchen plötzlichen Angriffen überhaupt in der Lage ist
    • Trotzdem bleibt das kleine Detail, dass keine Logs gespeichert werden
      Für mich ist das ein großes Problem, und es ermöglicht Korrelationsanalyse zwischen mehreren VPN-Exit-Nodes, aber auch nicht mehr. Es erlaubt keine automatische Identifizierung von Nutzern
      Es senkt aber die Schwierigkeit der Identifizierung deutlich, während die Anforderungen weiterhin hoch bleiben. Hoffentlich wird es bald behoben
      Ich kann kaum glauben, dass der Fehler „wir machen das mit einem sensiblen Wert wie einem Hash“ immer noch passiert, und dann auch noch bei Mullvad. Warum nicht einfach randomisieren?
    • Mullvad existierte schon einige Jahre vor den Snowden-Enthüllungen und tauchte in keinem dieser Dokumente auf
      Natürlich gibt es auch andere Geheimdienste, aber das wäre diejenige Seite, die mir am meisten Sorgen machen würde. Entweder weil sie es direkt betreiben, die Idee kennen und übernommen haben oder Zugriff auf einen Dienst eines Partnerdienstes hätten. Andernfalls wäre es für mich keine relevante Bedrohung
      Außerdem gibt es keine bekannten öffentlichen Fälle, in denen Mullvad-Nutzer über das VPN deanonymisiert wurden; bekannt sind vielmehr nur Fälle, in denen sie durch andere Fehler in der operativen Sicherheit entdeckt wurden. Wenn ein Geheimdienst diese Fähigkeit hätte, dann hätte er die Daten fast 20 Jahre lang besessen, ohne sie einzusetzen, und das fällt schwer zu glauben
    • Wenn ein Geheimdienst ein VPN kontrolliert, kann er den Traffic einfach direkt überwachen. Es gibt keinen Anreiz, es externen Beobachtern leichter zu machen, zu erraten, welcher Nutzer hinter welcher Exit-IP steckt

  • Ich verstehe nicht, wie allein aus den Zahlen im Artikel eine Wahrscheinlichkeit von über 99 % abgeleitet wird. Selbst wenn man stark annimmt, dass sowohl der Seed der ersten gesperrten IP als auch der zweite Seed im Bereich 0,4423–0,4358 liegen, bedeutet das nur, dass dieser Bereich 0,65 % aller Mullvad-Nutzer umfasst
    Bei 100.000 Nutzern wären das 650 Personen, also wurde die Zahl der „Verdächtigen“ um mehr als 99 % reduziert, aber keine einzelne Person mit über 99 % Genauigkeit über mehrere Exit-IPs hinweg identifiziert
    Bayesianisch betrachtet ist die Überlappung potenzieller Seeds starke Evidenz dafür, dass zwei IPs zur selben Person oder zumindest zu demselben Mullvad-Konto gehören, aber das scheint nicht das zu sein, was der Autor behauptet

    • Wenn das Forum eher groß ist, sagen wir 1000 aktive Nutzer hat und täglich eine Person dazukommt, wie hoch ist dann die Wahrscheinlichkeit, dass sich am Tag nach einer Sperre jemand anmeldet, der dieses VPN nutzt und IPs aus einem ähnlichen Bereich hat?
      Für die meisten kleinen Websites wäre das schon ziemlich starke Evidenz

  • Zum Zweck eines VPN gehört es nicht, Nutzer gegenüber den besuchten Websites zu anonymisieren, daher ist es nicht überraschend, dass Mullvad keine eindeutigen Exit-IPs erzwingt. Wer Anonymität möchte, sollte ein Netzwerk wie Tor verwenden

    • Ich verstehe nicht, warum nicht. Es gibt keinen Grund, warum das nicht der Zweck eines bestimmten VPN-Dienstes sein könnte
    • Ist Tor nicht ein US-Regierungsprojekt, bei dem bereits gezeigt wurde, dass Deanonymisierung möglich ist?
    • Genau das ist der Zweck eines öffentlichen VPN
      Wenn ich ein öffentliches VPN nutze, möchte ich, dass niemand weiß, wer die Requests sendet, einschließlich der Endpunkt-IP
      Nach dieser Logik dürfte man ein VPN auch nicht für Torrents verwenden, denn es dürfte ja nicht gegenüber der Endpunkt-IP anonymisieren. Tatsächlich funktioniert das bei Torrents aber sehr gut
      Wenn du ein privates VPN meinst: Mullvad ist keines

  • Ich nutze Mullvad seit langer Zeit und werde den Mullvad-VPN-Dienst weiterhin mit einer auf meinen Namen ausgestellten Kreditkarte kaufen und verwenden, solange das in meinem Land legal ist
    Ein VPN ist nicht 100 % anonym und wurde auch nie so entworfen. Es soll gesetzestreuen Erwachsenen vielmehr ein gewisses Maß an Privacy bieten
    Den meisten Menschen wäre es peinlich, wenn Kollegen und Nachbarn über ihr Privatleben, ihre Vorlieben, Käufe und Aktivitäten Bescheid wüssten. Deshalb sollten die meisten zum Schutz ihrer Privatsphäre ein VPN verwenden
    Per Definition wollen oder erwarten „die meisten Menschen“ online keine 100%ige Anonymität, sondern nur ein wenig Privacy in ihrem persönlichen Leben und in ihren Beziehungen
    Ein VPN schützt keine Kriminellen, die online Straftaten begehen und gegenüber dem Staat 100%ige Anonymität wollen, und es ist auch nicht dafür gedacht. Diese Unterscheidung ist wichtig. „Die meisten Menschen“ sind keine Kriminellen und haben solche unrealistischen Erwartungen weder an Mullvad noch an andere VPN-Anbieter

    • VPNs sind nicht anonym, die Leute tun nur so. Trotzdem zeigt dieser Bericht Erkenntnisse, die Nutzeridentifikation leichter machen als erwartet
      Allein mit der obigen Logik kann man den Bericht nicht verwerfen. Der Fund an sich bleibt valide

  • Da fehlt etwas. Ich frage mich, ob Mullvad kontaktiert wurde. Es wäre auch interessant gewesen zu sehen, wie das Sicherheitsteam reagiert hat

    • Soweit ich weiß, gab es keinen Kontakt, und ich habe sowohl beim Betriebsteam als auch beim Support nachgefragt. Wenn ich falsch liege, aktualisiere ich diesen Kommentar
      Später habe ich bereut, diesen Kommentar geschrieben zu haben. Er war unnötig, aber wenn ich ihn jetzt lösche, wirkt das vielleicht seltsam
    • Nein, aber der am höchsten bewertete Top-Level-Kommentar in diesem Thread ist die Antwort eines Mullvad-Mitgründers

  • Es überrascht mich, dass Menschen erwarten, ein VPN sei Tor ähnlich
    So ausgeschrieben wirkt das unsinnig, und man sollte auch bedenken, dass selbst Tor-Nutzer deanonymisiert werden können, wenn man Exit-Nodes kontrolliert

    • Das ist nicht überraschend, wenn die meisten großen Consumer-VPNs in ihrem Marketing „Privacy“ als Anonymität andeuten
    • War es nicht Teil des Tor-Designs, dass der Traffic über mehrere Relay-Nodes läuft, sodass auch der Exit-Node die ursprüngliche IP nicht sehen kann?
    • Vielleicht wird das nicht erwartet, aber man nimmt doch an, dass ein Anbieter, wenn möglich, alles tun würde, um Privacy zu bieten

  • Der Teil „Die Exit-IP wird bei jeder Verbindung nicht randomisiert, sondern deterministisch anhand des WireGuard-Schlüssels gewählt, und dieser Schlüssel wird alle 1 bis 30 Tage rotiert. Bei Drittanbieter-Clients geschieht das nie“ ist etwas verwirrend
    Wenn im Repository die Methode detailliert beschrieben ist, verstehe ich nicht, was Drittanbieter daran hindern sollte, wie der Standard-App-Client ebenfalls Schlüsselrotation umzusetzen

    • Zu Drittanbieter-Clients gehört zum Beispiel auch der WireGuard-Treiber im Linux-Kernel. Es kann nicht Aufgabe eines Netzwerk-Treibers sein, Angriffe auf einen bestimmten kommerziellen Dienst abzumildern
    • Vor allem verhindert es, dass man überhaupt weiß, dass man das tun sollte

  • Der Autor hat das gut herausgefunden, und ich halte es für völlig glaubhaft, dass es ein Fehler von Mullvad war. Dass so etwas Simples durchgerutscht ist, ist ziemlich schockierend, aber ich hätte es wahrscheinlich auch übersehen können
    Lässt man die IP-Korrelation zwischen mehreren Servern außen vor, habe ich mich zuerst auch gefragt, warum Nutzer-IPs auf einem einzelnen Server überhaupt stabil gehalten werden. Aber die Erklärung des Autors, dass damit andere VPNs nachgeahmt werden, die üblicherweise nur eine IP pro Server haben, ergibt Sinn
    Wenn ein Nutzer einen Server findet, der Zugang zu einem bestimmten Dienst erlaubt, hat es den Vorteil, dass er bei einer erneuten Verbindung zu diesem Server wahrscheinlich wieder dieselbe IP bekommt und es erneut funktioniert
    Die IP-Korrelation über mehrere Server hinweg sollte man allerdings etwa mit rand.seed(user_pub_key + server_id) beheben

    • Aber umgekehrt: Wenn jemand wegen lauter Nachbarn auf derselben IP bei einem Dienst gesperrt wurde, hat der Nutzer dann überhaupt keine Möglichkeit, das zu umgehen?

  • Ich arbeite bei IPinfo. Wir sind im Geschäft mit VPN-Erkennung, aber ehrlich gesagt würde ich Mullvad hier wohlwollende Absichten unterstellen
    Mullvad war einer von drei VPN-Anbietern, die nicht versucht haben, bei Anbietern wie uns absichtlich falsche IP-Geolokalisierungsdaten einzureichen. Ich bin sicher, dass sie auch dieses Problem beheben werden

    • Wer waren die anderen?