DNS-Traffic kann außerhalb des VPN-Tunnels auf Android auslaufen

 (mullvad.net)
2 Punkte von GN⁺ 2024-05-04 | 1 Kommentare | Auf WhatsApp teilen

DNS-Traffic kann außerhalb des VPN-Tunnels auf Android auslaufen

Mehrere DNS-Leck-Szenarien bestätigt

  • Kürzlich wurde festgestellt, dass auf Android mehrere DNS-Leaks möglich sind.
  • Das Problem geht auf einen Fehler im Android-Betriebssystem selbst zurück und betrifft nur bestimmte Apps.
  • Am Montag, den 22. April, wurde der DNS-Leak über eine Meldung eines Reddit-Nutzers bekannt.
    • Ein Nutzer entdeckte, dass DNS-Abfragen auslaufen, wenn er bei aktivierter Einstellung „Verbindungen ohne VPN blockieren“ VPN deaktiviert und wieder aktiviert.
  • Wir haben sofort mit einer internen Untersuchung begonnen und konnten das Problem verifizieren.
  • Die Untersuchung ergab weitere Szenarien, die zu DNS-Leaks auf Android führen können.

Beobachtete Funde

Identifizierte Szenarien, in denen auf Android DNS-Traffic auslaufen kann:

  • Wenn ein VPN aktiviert wird, obwohl kein DNS-Server konfiguriert ist.
  • Für kurze Zeit, während eine VPN-App den Tunnel neu aufbaut oder zwangsweise gestoppt bzw. abgestürzt wird.

Der Leak scheint auf direkte Aufrufe der C-Funktion getaddrinfo beschränkt zu sein.

  • In den oben genannten Szenarien führen Apps, die diese Methode zur DNS-Auflösung verwenden, zu DNS-Leaks.
  • Bei Apps, die ausschließlich Android-APIs wie DnsResolver nutzen, haben wir keine Leaks festgestellt.
  • Ein Beispiel für eine App, die getaddrinfo direkt nutzen kann, ist der Chrome-Browser.

Der folgende Abschnitt gilt unabhängig davon, ob Always-on VPN und Block connections without VPN aktiviert sind:

  • Dies entspricht nicht dem erwarteten Verhalten des OS und sollte im Upstream des OS behoben werden.

Wir konnten solche Leaks in mehreren Android-Versionen beobachten, einschließlich der neuesten Version Android 14.

Verbesserungen

Aktuell setzt die App im blockierten Zustand keinen DNS-Server:

  • Wenn die App den Tunnel nicht auf wiederherstellbare Weise einrichten kann, wechselt sie in den blockierten Zustand.
  • In diesem Zustand stoppt sie den ausgehenden Verkehr vom Gerät.
  • Da in diesem Zustand kein DNS-Server gesetzt wird, kann es zu dem oben beschriebenen DNS-Leak kommen.
  • Wir planen vorübergehend, einen Fake-DNS-Server zu setzen, um den OS-Bug zu umgehen.
  • Mit einem Release, das diesen Fix enthält, kann in Kürze gerechnet werden.

DNS-Leaks während einer Tunnel-Reverbindung durch die App zu mildern ist schwieriger:

  • Wir suchen weiterhin nach einer Lösung.
  • Wir können zwar die Anzahl der Tunnel-Rekonfigurationen reduzieren, aber davon ausgehend, dass wir diesen Leak aktuell nicht vollständig verhindern können.

Es sollte klar sein, dass keine VPN-App Workarounds wie diese benötigen sollte:

  • Es ist nicht falsch, wenn eine App getaddrinfo für die DNS-Auflösung verwendet.
  • Stattdessen muss dieses Problem vom OS behoben werden, um alle Android-Nutzer zu schützen, unabhängig davon, welche App sie verwenden.

Wir haben das Problem Google gemeldet und Verbesserungsvorschläge gemacht und hoffen auf eine schnelle Lösung.

Reproduktionsschritte

Die folgenden Schritte reproduzieren das zweite oben genannte Szenario, bei dem VPN-Benutzer die Tunnelkonfiguration ändern (z. B. auf einen anderen Server wechseln oder den DNS-Server ändern):

  • Die WireGuard-App wird verwendet, da sie die Referenzimplementierung von Android VPN ist.
  • Beachten Sie, dass der Leak wahrscheinlich auch mit anderen Android-VPN-Apps reproduziert werden kann.
  • Chrome wird verwendet, da es eine der Apps ist, bei denen getaddrinfo verwendet wird, um den Leak auszulösen.

  1. spam_get_requests.html herunterladen

  2. WireGuard-App und Chrome installieren

  3. wg1.conf und wg2.conf in WireGuard importieren

  4. In der WireGuard-App das wg1-Tunnel aktivieren und VPN-Berechtigung erteilen

  5. In den Android-VPN-Einstellungen für WireGuard „Always-on VPN“ und „Block connections without VPN“ aktivieren

  6. Auf dem Router mit tcpdump den Datenverkehr erfassen
    $ tcpdump -i <INTERFACE> host <IP of android device>

  7. WireGuard und Chrome nebeneinander anzeigen lassen

  8. Öffnen Sie spam_get_requests.html in Chrome und klicken Sie auf „Start“

  9. In der WireGuard-App zwischen wg1 und wg2 wechseln und diesen Schritt wiederholen, bis der Leak in Schritt 10 sichtbar ist

  10. Auf dem Router den folgenden DNS-Traffic beobachten:

    11:50:27.816359 IP Pixel-Tablet.lan.53353 > OpenWrt.lan.53: 11200+ A? 307lf5rgn6-19282-11-50-27-519z.mullvad.test.lan. (65) 11:50:27.816359 IP Pixel-Tablet.lan.48267 > OpenWrt.lan.53: 44347+ A? 307lf5rgn6-19284-11-50-27-579z.mullvad.test.lan. (65) 11:50:27.816396 IP Pixel-Tablet.lan.16747 > OpenWrt.lan.53: 44584+ A? 307lf5rgn6-19289-11-50-27-729z.mullvad.test. (61) 11:50:27.816458 IP OpenWrt.lan.53 > Pixel-Tablet.lan.53353: 11200 NXDomain 0/0/0 (65) 11:50:27.816476 IP Pixel-Tablet.lan.45727 > OpenWrt.lan.53: 40503+ A? 307lf5rgn6-19290-11-50-27-759z.mullvad.test. (61) 11:50:27.816542 IP OpenWrt.lan.53 > Pixel-Tablet.lan.48267: 44347 NXDomain 0/0/0 (65) 11:50:27.816588 IP Pixel-Tablet.lan.43821 > OpenWrt.lan.53: 36295+ A? 307lf5rgn6-19291-11-50-27-789z.mullvad.test. (61) 11:50:27.816625 IP OpenWrt.lan.53 > Pixel-Tablet.lan.16747: 44584 NXDomain 0/0/0 (61)

Da „Block connections without VPN“ aktiviert war, sollte außer verschlüsseltem WireGuard-Verkehr nichts das Gerät verlassen, hier ist jedoch sichtbar, dass Klartext-DNS aus dem Gerät austritt.

Fazit und Empfehlungen

DNS-Leaks können die Privatsphäre der Nutzer massiv beeinträchtigen und können verwendet werden, um den ungefähren Standort der Nutzer zu bestimmen oder festzustellen, welche Websites und Dienste sie verwenden.

Diese Ergebnisse zeigen erneut, dass „Block connections without VPN“ weder dem Namen noch der Dokumentation entspricht und mehrere Schwachstellen hat:

  • Unter den oben genannten Bedingungen können Apps weiterhin DNS-Traffic auslaufen lassen.
  • Wie bereits berichtet, tritt weiterhin Verbindungsprüfverkehr aus.

Je nach Bedrohungsmodell müssen Anwender möglicherweise auf Android für sensible Aufgaben verzichten oder zusätzliche Mitigationen ergreifen, um Leaks zu verhindern:

  • Da die App nur darauf abzielt, solche Probleme auf App-Ebene teilweise zu mildern, ist es wichtig, die App auf dem neuesten Stand zu halten.

GN⁺-Meinung

  • Dieses Problem ist im Kern ein Fehler im Android-Betriebssystem, den Google daher kurzfristig beheben sollte. Es wäre nicht sinnvoll, wenn alle VPN-App-Entwickler versuchen würden, dieses Problem zu beheben.
  • Dass die Option „Block connections without VPN“ nicht so funktioniert, wie ihr Name (bzw. die Dokumentation) es nahelegt, und dass es DNS-Leaks gibt, ist aus Nutzersicht ein gravierendes Problem. Ein Hauptgrund für die Nutzung einer VPN-App ist der Datenschutz; DNS-Leaks können deshalb Einblicke in die Webnutzung von Nutzern geben.
  • Die Sicherheit von VPN-Tunneling-Technologie bleibt insgesamt hoch, aber um unbeabsichtigte Leaks auf OS-Ebene zu verhindern, kann es sinnvoll sein, neben VPN zusätzliche Sicherheits-/Datenschutzlösungen einzusetzen.
  • App-Entwickler kompensieren derzeit einen OS-Bug mit kurzfristigen Workarounds in ihren Apps, aber eine nachhaltige Lösung erfordert ein OS-Upgrade im Sinne einer grundlegenden Behebung.
  • Mit zunehmender Verbreitung und Reife der VPN-Technologie treten solche Sicherheitsfragen immer stärker in den Vordergrund. Auch künftig werden Sicherheitsprüfungen und kontinuierliche Verbesserungen bei den Netzwerk- und VPN-Funktionen mobiler OSs erforderlich sein.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-05-04
Hacker News Kommentar
  • Mullvad wurde gelobt, weil es reichhaltige Informationen sowie eine gute Beschreibung des Problems, kurzfristige Workarounds, potenzielle Lösungsansätze und Punkte aufzeigte, die auf Android behoben werden müssen.
  • Ein Entwickler von rethinkdns meint, Androids „paranoides Networking“ habe Ausnahmen für System- und OEM-Apps; die meisten Bugfixes würden diese Grundannahme jedoch nicht ändern.
  • Android unterstützt ein „nahtloses Handover“ zwischen zwei TUN-Devices, ist aber schwierig korrekt zu implementieren.
  • In Android gibt es seit langem das Problem, dass das System beim Versuch, nur interne DNS-Server zu verwenden, bei Bedarf auf Mobilfunkdaten umschaltet und dabei externe DNS-Server nutzt.
  • Bei Apple versucht ein „Privacy“-VPN standardmäßig, alles durch das VPN zu proxyen, daher ist zu erwarten, dass es bei konkurrierenden Produkten nicht besser ist.
  • Auf Android können keine IPv6-DNS-Server direkt konfiguriert werden und sie ändern sich bei jeder Änderung der WLAN-Verbindung.
  • Durch den Einsatz eines MikroTik-Firewall-Geräts kann man DNS-Leaks verhindern, indem man sämtliche Verbindungen blockiert, die nicht auf die IP-Adresse des VPN-Servers ausgerichtet sind.
  • Alle Systeme ohne Root-Zugriff sind grundsätzlich nicht sicher, und Android und iOS wirken hierbei geradezu lächerlich.
  • Die sicherste Konfiguration ist es, die mobilen Daten des Telefons zu deaktivieren und über einen OpenWRT-Hotspot den VPN-Tunnel upstream aufzubauen.
  • DNS-Leaks können den Browserstandort eines Nutzers und sogar dessen echten Standort offenlegen und damit den Zweck eines VPNs zunichte machen.
  • Auch auf iOS wird APNS-Traffic außerhalb des VPNs geleakt (ausgenommen ein vom Betriebssystem unterstütztes VPN, das per Provisioning-Profil installiert wurde).
  • Es stellt sich die Frage, ob solche „Bugs“ absichtlich platziert wurden; angesichts der Zusammenarbeit großer Technologieunternehmen mit Nachrichtendiensten erscheint es schwer zu glauben, dass die vielen Android-Bugs einfach nur „zufällig“ existieren.