DNS-Traffic kann unter Android möglicherweise außerhalb des VPN-Tunnels austreten

 (mullvad.net)
2 Punkte von GN⁺ 2024-05-04 | 1 Kommentare | Auf WhatsApp teilen
  • Bei bestimmten Kombinationen aus Apps und Zuständen unter Android können DNS-Anfragen außerhalb des VPN-Tunnels gesendet werden; Mullvad sieht die Ursache eher in einem Bug des Android-OS als in VPN-Apps
  • Das Leck kann in kurzen Übergangsphasen auftreten, etwa wenn trotz aktiviertem VPN kein DNS-Server eingetragen ist, der Tunnel neu konfiguriert wird oder die VPN-App zwangsbeendet wird bzw. abstürzt
  • Betroffen sind vor allem Apps, die getaddrinfo direkt aufrufen; bei Apps, die ausschließlich die Android-API DnsResolver verwenden, wurde kein Leck festgestellt
  • Always-on VPN und „Block connections without VPN“ verhindern das Problem nicht vollständig; es wurde in mehreren Versionen einschließlich Android 14 bestätigt
  • Mullvad will vorübergehend einen Fake-DNS-Server setzen, um einige Situationen abzumildern; Lecks während der Wiederverbindung lassen sich ohne OS-Fix jedoch nur schwer vollständig verhindern

Bedingungen für DNS-Lecks unter Android

  • Mullvad bestätigte am 22. April durch den Bericht eines Reddit-Nutzers, dass beim Aus- und erneuten Einschalten des VPNs bei aktivierter Option „Block connections without VPN“ ein DNS-Leck auftreten kann
  • Interne Untersuchungen ergaben weitere Szenarien, in denen Android OS DNS-Traffic außerhalb des VPNs senden kann
    • Wenn das VPN aktiv ist, aber kein DNS-Server konfiguriert ist
    • Während die VPN-App den Tunnel neu konfiguriert
    • In der kurzen Zeit, in der die VPN-App zwangsbeendet wird oder abstürzt
  • Dieses Verhalten entspricht nicht dem erwarteten Verhalten von Android OS und muss auf einer höheren OS-Ebene behoben werden

Betroffene Apps und Pfade der Namensauflösung

  • Das Leck scheint bei Apps aufzutreten, die für die Auflösung von Domainnamen die C-Funktion getaddrinfo direkt aufrufen
  • Bei Apps, die ausschließlich die Android-API DnsResolver verwenden, wurde kein Leck festgestellt
  • Der Chrome-Browser ist ein Beispiel für eine App, die getaddrinfo direkt verwenden kann
  • Die Verwendung von getaddrinfo ist an sich nicht falsch; um alle Android-Nutzer zu schützen, ist eine Lösung auf OS-Ebene erforderlich

Grenzen von Always-on VPN und Blockier-Einstellungen

  • Die bestätigten Lecks treten unabhängig davon auf, ob Always-on VPN und „Block connections without VPN“ aktiviert sind
  • Wenn „Block connections without VPN“ aktiviert ist, sollte außer verschlüsseltem WireGuard-Traffic nichts das Gerät verlassen; bei der Reproduktion wurde jedoch unverschlüsseltes DNS am Router beobachtet
  • Mullvad bewertet diese Einstellung so, dass sie weder ihrem Namen noch dem dokumentierten Verhalten gerecht wird und mehrere Mängel aufweist
    • Unter den genannten Bedingungen kann DNS-Traffic austreten
    • Wie zuvor gemeldet, tritt auch Traffic zur Verbindungsprüfung weiterhin aus

Vorübergehende Abmilderung in der Mullvad-App und verbleibende Probleme

  • Die Mullvad-App setzt derzeit im blockierten Zustand keinen DNS-Server
    • Wenn die Tunnel-Einrichtung auf nicht wiederherstellbare Weise fehlschlägt, wechselt die App in den blockierten Zustand
    • In diesem Zustand wird verhindert, dass Traffic das Gerät verlässt; weil der DNS-Server jedoch leer ist, kann eine Leck-Bedingung entstehen
  • Mullvad will den OS-Bug vorerst umgehen, indem ein Fake-DNS-Server gesetzt wird, und plant, in Kürze ein Release mit dieser Korrektur bereitzustellen
  • Lecks während der erneuten Tunnelverbindung lassen sich in der App schwerer abmildern
    • Mullvad sucht nach einer Lösung
    • Möglicherweise lässt sich die Anzahl der Tunnel-Neukonfigurationen reduzieren; derzeit geht Mullvad jedoch nicht davon aus, dieses Leck vollständig verhindern zu können
  • Mullvad hat das Problem samt Verbesserungsvorschlägen an Google gemeldet

Beobachtungen bei Reproduktion mit WireGuard und Chrome

  • Das zweite Szenario, ein Leck während Änderungen an der VPN-Tunnelkonfiguration, lässt sich mit der WireGuard-App und Chrome reproduzieren
    • WireGuard wird als Referenzbeispiel für die Android-VPN-Implementierung verwendet
    • Mullvad hält es für wahrscheinlich, dass es auch mit anderen Android-VPN-Apps reproduzierbar ist
    • Chrome wurde zum Auslösen des Lecks verwendet, da die Nutzung von getaddrinfo für diese App bestätigt ist
  • Die Reproduktion umfasst folgende Elemente
    • Download von spam_get_requests.html
    • Installation der WireGuard-App und von Chrome
    • Import von wg1.conf und wg2.conf in WireGuard
    • Aktivieren des wg1-Tunnels in WireGuard und Erteilen der VPN-Berechtigung
    • Aktivieren von Always-on VPN und „Block connections without VPN“ für WireGuard in den Android-VPN-Einstellungen
    • Starten eines Mitschnitts am Router mit tcpdump -i <INTERFACE> host <IP of android device>
    • Öffnen von WireGuard und Chrome im geteilten Bildschirm, Ausführen von spam_get_requests.html in Chrome und anschließendes abwechselndes Umschalten zwischen wg1 und wg2 in WireGuard
  • Am Router wurden A-Record-Anfragen vom Android-Gerät an Port 53 des OpenWrt-Routers sowie NXDomain-Antworten beobachtet
  • DNS-Lecks können genutzt werden, um den ungefähren Standort eines Nutzers oder besuchte Websites und Dienste zu ermitteln, und können daher erhebliche Privacy-Auswirkungen haben
  • Je nach Threat Model sollte man für sensible Einsatzzwecke Android meiden oder andere Maßnahmen zur Verhinderung von Lecks anwenden
  • Nutzer der Mullvad-App sollten die App aktuell halten, da eine teilweise Abmilderung enthalten sein kann

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-05-04
Meinungen auf Hacker News

  • Ich nutze Mullvad nicht, aber ich habe großen Respekt davor bekommen. Die Problembeschreibung, der kurzfristige Workaround, potenzielle Workarounds, die andere nutzen können, und sogar die Stellen, die in Android behoben werden müssen, sind sehr informationsdicht und gut strukturiert

    • Ich habe mich für Mullvad als VPN-Dienst entschieden, weil sie statt endloser YouTube-Sponsorings wie die Konkurrenz solche Blogbeiträge veröffentlichen
    • Auch wenn man kein VPN nutzt, bietet Mullvad einen kostenlosen DNS-Dienst an. Mehr Traffic/Nutzung kann ebenfalls eine Form von Unterstützung sein, und aus Sicht der DNS-Anfragen dürfte es auch helfen, Mullvad-VPN-Nutzer weniger auffällig wirken zu lassen
      Der Nachteil ist, dass die Ping-Zeiten bei mir deutlich höher sind als bei quad9 oder cloudflare
      In diesem Thread habe ich etwas zu DNS-basiertem Adblocking und Informationen zu cloudflare geschrieben: https://news.ycombinator.com/item?id=40056162
    • Gemessen an Werten, Denkweise, Treue zu den Kernüberzeugungen und dem über Jahrzehnte hinweg konsistenten Beleg, dem eigenen Motto treu geblieben zu sein, halte ich sie für das beste VPN
    • Als Mullvad-Nutzer bin ich sehr zufrieden. Ich habe dem Support einmal wegen einer Zahlungsfrage geschrieben und dabei auch eine kleine iptables-Frage zu einem Problem angehängt, das ich hatte
      Das Zahlungsproblem wurde schnell gelöst, und zu iptables bekam ich ebenfalls eine ausführliche Antwort mit Vor- und Nachteilen mehrerer Lösungswege. Kurz gesagt: hervorragend
    • Falls du ein VPN nutzt: Mich würde interessieren, welches

  • Ich bin Entwickler von rethinkdns
    Zu der Aussage „Diese Probleme müssen im Betriebssystem behoben werden, um alle Android-Nutzer unabhängig von der verwendeten App zu schützen“: Androids paranoides Networking hatte schon immer Ausnahmen für System-Apps und OEM-Apps, also auch für Google-Apps
    Die meisten Fixes für solche Bugs werden diese Grundannahme vermutlich ebenfalls nicht ändern. Siehe den relevanten Code: https://github.com/celzero/rethink-app/issues/224
    Zu „Leaks während der Tunnel-Neuverbindung sind in der App schwieriger abzumildern. Wir suchen noch nach einer Lösung“: Android unterstützt bei einer Neukonfiguration einen unterbrechungsfreien Wechsel zwischen zwei TUN-Geräten. Das ist knifflig korrekt zu implementieren, aber möglich

    • Dass man nicht einmal der Taschenlampen-App die Internetberechtigung entziehen kann, ergibt Sinn, wenn man bedenkt, dass das Betriebssystem von einem Internet-Werbeunternehmen betrieben wird

  • Das ist ein Problem, das es unter Android schon seit langer Zeit gibt. Selbst wenn man nur interne DNS-Server verwenden will, wechselt Android auf Mobilfunk und nutzt dieses DNS, sobald es meint, dass es nötig oder gewünscht ist
    Kürzlich habe ich per adb-Debugging beobachtet, warum/wann die Funkverbindung abbricht; am Ende schaltet es mobile Daten ein und versucht es darüber, wenn es bei der Erreichbarkeitsprüfung etwas nicht sehen oder interpretieren kann
    Besonders frustrierend ist es, wenn man DNS-Einträge nutzt, die nur intern existieren, und das Handy dann willkürlich nicht funktioniert. Das Gerät hängt in einem WLAN, das den internen DNS-Server mit diesem Eintrag bereitstellt, aber aus irgendeinem Android-Grund wird er extern aufgelöst
    Ich weiß nicht, wie Apple damit umgeht, aber da sie DNS grundsätzlich per DoH über ihr „privacy“-VPN proxyen wollen, fällt es mir schwer, mir vorzustellen, dass es besser ist, wenn man etwas nutzt, das als Konkurrenzprodukt gelten könnte; außerdem weiß man ja, wie Apple solche Produkte behandelt

    • Man sollte prüfen, ob „auf Mobilfunk wechseln und ihn nutzen, wenn es nötig oder gewünscht ist“ nicht daran liegt, dass WLAN-Unterstützung aktiviert ist. Diese Funktion ist ausdrücklich dafür gedacht, bei schlechtem WLAN-Signal auf Mobilfunk umzuschalten
    • Apple bzw. iOS hat über Konfigurationsprofile eine recht robuste eingebaute Möglichkeit, Traffic zu filtern und zu blockieren. Ich bin nicht sicher, ob das pro App einstellbar ist, aber Allowlists/Blocklists für Hostnamen lassen sich definitiv konfigurieren
      Ein echtes Beispiel ist dieser systemweite Werbeblocker: https://myxxdev.github.io/depictions/MYbloXXforiOS/MYbloXXfo...
    • iOS verwendet Private Relay niemals standardmäßig. Selbst wenn es im Abo enthalten ist, muss man es ausdrücklich selbst einschalten
    • Ich frage mich, ob du in den Entwickleroptionen „Mobile Daten immer aktiv“ ausgeschaltet hast
    • Ich habe AOSP aus dem Quellcode gebaut. Es sollte eigentlich keine Google-spezifischen Anforderungen enthalten, und ich habe in der hosts-Datei so viele Google-Server wie möglich blockiert, damit es nicht heimlich Google kontaktiert
      Das einzige Problem, das ich hatte: Das Gerät zeigte an, es habe kein Internet, obwohl es mit einem funktionierenden WLAN-AP verbunden war. Tatsächlich funktionierte es, aber für das Statusleisten-Icon und andere interne Systemzwecke schien es über Google-Server zu prüfen, ob das Internet funktioniert
      Wenn einem Datenschutz wichtig ist, sollte man Android meiden – und wahrscheinlich generell bei Technik vorsichtig sein

  • Als ich vor ein paar Jahren für ein Projekt mehrere VPN-Konfigurationen testete, hatte ich zwischen Computer und Hauptrouter ein MikroTik-Firewall-Gerät stehen. Der einzige Zweck war, sämtlichen Traffic zu blockieren, dessen Ziel nicht die IP-Adresse des VPN-Servers war, zu dem der PC eine Verbindung herstellen wollte
    Das funktionierte sehr gut, um sicherzustellen, dass vom PC kein Traffic außerhalb des Pfads zum VPN-Server leakt. Die IP-Adresse des verwendeten VPN-Servers ändert sich kaum, und wenn doch, lässt sie sich in der MikroTik-Firewall leicht anpassen
    Wenn man die Server-IP nicht kennt oder sie sich ändert, kann man auch sämtlichen Traffic blockieren, der nicht dem vom VPN-Server verwendeten Port/Protokoll-Paar entspricht. Je nach VPN-Typ würde man zum Beispiel Traffic verwerfen, dessen Ziel nicht UDP 1194 ist
    MikroTik-Router haben außerdem ein kleines Tool namens torch, mit dem man Traffic schnell und einfach ansehen kann, und sie unterstützen Packet Capture. Die Preise reichen von 30 bis 3000 Dollar, es gibt keine Softwarelizenz, und wenn man damit umgehen kann, sind sie sehr leistungsfähig und kompetent

    • Diese Art von Gerät nennt man network slug, und es ist eine ausgezeichnete Idee
      Streng genommen ist ein echter Slug eine transparente Layer-2-Firewall ohne definierte IP-Adresse, aber diese Details müssen wir hier nicht ausdiskutieren
      https://john.kozubik.com/pub/NetworkSlug/tip.html

  • Outbound-Filtering anhand von Quell-/Zieladresse und Port ist ein Grundkonzept von Firewalls und eine Standardkonfiguration aller Firewall-Routing-Plattformen. Policy-based Routing, das anhand des Gateways filtert, gehört in denselben Kontext: https://en.wikipedia.org/wiki/Policy-based_routing
    Üblicherweise erlauben nur Consumer- oder Prosumer-Produkte standardmäßig sämtlichen ausgehenden Traffic. Mich würde interessieren, was in dieser Konfiguration der „Hauptrouter“ war. Ein vom ISP bereitgestelltes Gerät?

    • Wenn wir schon bei Empfehlungen sind: Gibt es auch günstige und brauchbare Router mit Layer-7-Firewall?
      Es wäre schön, wenn wir auch zwischen Smartphone-App und Modem eine Firewall schalten könnten.

  • Das DNS-Problem von Android besteht darin, dass man auf dieser Plattform keinen eigenen IPv6-DNS-Server festlegen kann. Jedes Mal, wenn sich am WLAN etwas ändert, wird das wieder überschrieben.
    Selbst auf einem gerooteten Android gibt es keine App, die das Betriebssystem daran hindert, es zu ändern.
    Wenn man einen Router verwendet, der ständig IPv6-Adressen verteilt und sich nicht abschalten lässt, steckt man schlicht fest.
    Ich weiß nicht einmal, ob man hinter diesem Router ein Firewall-Gerät installieren kann, um den vom Router angekündigten IPv6-DNS-Server zu entfernen.

    • Statt die IP-Adresse des DNS-Servers festzulegen, könnte man die systemweite Unterstützung für DNS-over-TLS verwenden. Das ist eine globale Einstellung und sollte unabhängig davon gelten, in welchem Netzwerk man ist und was dort passiert.
      Wenn einem DNS-Leaks wichtig sind, sollte man ohnehin DoT oder DoH verwenden.
    • Kann man mit rethink nicht den IPv6-DNS ändern?
    • Es klingt so, als passiere das, wenn das Smartphone das Hauptinterface ist.
      Mich würde interessieren, ob dasselbe beim WLAN-Tethering passiert. Wenn man auf einem über das Smartphone-WLAN verbundenen Laptop ein VPN nutzt, leakt es dann auf dieselbe Weise?

  • Die sicherste Konfiguration scheint zu sein, die mobilen Daten des Smartphones abzuschalten und einen OpenWRT-Hotspot mitzunehmen, der das VPN oberhalb des Smartphones abwickelt.

    • Stimmt. Unter iOS ist es ein noch größerer Albtraum.
      „Always-on VPN“ lässt sich nur auf Geräten einrichten, die über eine von Apple genehmigte MDM-Lösung im „supervised“-Zustand sind. Dafür braucht es einen dokumentierten Antrag und ein Telefonat mit einem aktuellen Mitarbeiter.
      Oder man muss auf einem Mac die Apple-Configurator-App verwenden, um ein Konfigurationsprofil mit dem Schlüssel „always-on VPN“ zu erstellen.
    • Ich habe das früher monatelang mit einem GL.inet E750 und einem iPhone ohne SIM gemacht, und US-GSM-Anbieter haben UDP-Traffic auf ungewöhnlichen Ports oft stark eingeschränkt. Teilweise ging es auf 64–128 kbps herunter, also etwa 0,1 Mbps.
      Benachrichtigungen kamen auch häufig verzögert an.
    • Wenn man öffentliches WLAN oder Mobilfunk nutzt, ist das die beste Lösung. Wenn jemand eine eigene Basisstation betreibt, kann sich das Smartphone damit verbinden.
      Wenn es nicht mein Netzwerk ist, würde ich mich ohne mobilen Router lieber nicht direkt verbinden.
    • Andere berichten, dass Android unter verschiedenen Bedingungen stillschweigend Mobilfunkdaten wieder einschaltet, daher ist auch diese Methode keine sichere Lösung.
      The Grugq hat vor 10 Jahren ein Tool für genau diesen Zweck gebaut. Leider wird es heute nicht mehr gepflegt: https://github.com/grugq/portal
      Es war Teil eines Vortrags über operative Sicherheit für Hacker; sehenswert, wenn man sich für Fälle interessiert, in denen mehrere bekannte oder berüchtigte Hacker sich für sicher hielten, am Ende aber doch erwischt wurden: https://www.youtube.com/watch?v=9XaYdCdwiWU

  • Ein System ohne root-Zugriff ist per Definition unsicher. Android und iOS sind lächerlich.

    • Man könnte auch sagen, ein System, in dem es das Konzept von root-Zugriff gibt, sei per Definition unsicher. Solche apodiktischen Sätze kann jeder formulieren.
    • Wenn Smartphones für die meisten Menschen nicht Desktops/Laptops ersetzt hätten, könnte man darüber lachen und weitergehen.
      Mir tun die Kinder leid, die mit Geräten aufgewachsen sind oder aufwachsen werden, die als Computer hauptsächlich für Medienkonsum und das Sammeln privater Daten konzipiert wurden.
    • Die GrapheneOS-Entwickler sind wirklich stark gegen root. Mich würde interessieren, was sie dazu denken.
    • Der Punkt ist klar und passt zum Thema. Deshalb werden Open-Source-Software- und Hardware-Projekte für mobile Geräte zwangsläufig weiter zunehmen.
      https://en.wikipedia.org/wiki/PinePhone_Pro
    • Nach dieser Definition wären viele meiner wichtigsten Systeme „unsicher“.
      Wenn jemand an eine Kopie meines privaten SSH-Schlüssels auf solchen Geräten kommt, zahle ich ohne Wenn und Aber 100.000 Dollar in bar.
      Diese Definition ist bedeutungslos und weder zum Schlussfolgern noch zur Kommunikation nützlich.

  • „Verbindungen ohne VPN blockieren“ erweist sich gerade als ungefähr so verlässlich wie meine Selbstbeherrschung am Buffet. Wenn ich mich nicht täusche, können solche DNS-Leaks ziemlich viel über die besuchten Websites und sogar den Standort verraten, womit sie den eigentlichen Zweck eines VPN untergraben.
    Android kann selbst bei eingeschaltetem VPN DNS-Informationen durchsickern lassen; wer also wirklich stark auf Privatsphäre angewiesen ist, sollte über die Nutzung von Android hinausdenken oder sensible Aufgaben vom Smartphone fernhalten.

  • Manchmal frage ich mich, ob solche „Bugs“ nicht absichtlich gut platziert sind. Besonders angesichts der Tatsache, dass große Tech-Unternehmen mit verschiedenen Nachrichtendiensten zusammengearbeitet haben.
    Es ist auch nicht das erste Mal, dass ich von dieser Art Bug in Android höre; inzwischen fällt es mir schwer zu glauben, dass so viele Bugs „unbeabsichtigt“ hineingeraten sind.

    • „Einmal ist Zufall, zweimal ist coincidence, dreimal ist Feindeinwirkung.“ —Ian Fleming, Goldfinger

  • Ich hatte schon länger den Verdacht, dass es so sein könnte. Selbst wenn man unter Android ein VPN aktiviert, funktionieren MMS und Visual Voicemail weiterhin.
    Beide brauchen teils direkten Mobilfunkzugriff oder werden andernfalls abgelehnt. Sie sind entweder nur im Mobilfunknetz erreichbar, oder Anfragen werden abgelehnt, wenn sie nicht aus dem Inneren des Mobilfunknetzes kommen. Ich vermute, dass es bei VoLTE ähnlich ist. Mit einem VPN können solche Funktionen durcheinandergeraten.
    Unter Mobile Linux merkt man das, weil all diese Funktionen kaputtgehen, sobald man ein VPN einschaltet.
    Es scheint keinen offensichtlichen Weg zu geben, das unter Android zu beheben, ohne viele erwartete Funktionen zu beschädigen.

    • Ironischerweise gehören SMS/MMS und VVS zu den wenigen Aufgaben/Funktionen, bei denen es gerechtfertigt sein kann, sie hart an die Verbindung des Mobilfunkanbieters zu koppeln. Systemupdates vielleicht ebenfalls.

Da ich iOS mit aktiviertem VPN schon einmal mit dem erweiterten Support-Team von AT&T wegen VVS-Problemen durchgefochten habe, kann ich bestätigen, dass dieses Problem nicht nur auf Android beschränkt ist.

  • VoLTE verwendet im LTE-Stack einen dedizierten Bearer, also ein separates Netzwerk-Interface. Es ist nicht das Interface für Daten.
    Unterschiedliche Bearer können unterschiedliche Prioritäten/QCI haben, also eine unterschiedliche Servicequalität. In einem überlasteten LTE-Netz sollte VoLTE ein besseres Erlebnis bieten als VOIP über einen Bearer mit niedrigerer Priorität.