Android verrät die echte IP am VPN vorbei, und Google behebt es nicht

Android hat einen Schalter namens "Verbindungen ohne VPN blockieren". Zusammen mit dem dauerhaft aktiven VPN verspricht das System damit, dass nichts das Gerät außerhalb des Tunnels verlässt. Zwei voneinander unabhängige Funde aus diesem Jahr zeigen, dass jede gewöhnliche App an diesem Schalter vorbeigeht und Ihre echte IP-Adresse einem selbst gewählten Server übergibt. Google hat beide Meldungen geschlossen, ohne etwas zu reparieren.

Was der Schalter garantieren soll

Kommt unter Android ein VPN hoch, schreibt das System seine Routing-Regeln so um, dass erfasste Apps das Netz nur noch durch den Tunnel erreichen. Jeder Socket trägt eine Markierung, an der der Kernel erkennt, zu welchem Netz er gehört, und versucht eine App, einen Socket direkt an die physische WLAN-Schnittstelle zu binden, scheitert die Prüfung und der Aufruf liefert einen Rechtefehler. Das ist die Mechanik hinter der Einstellung, und sie funktioniert.

Sie funktioniert für Apps. Sockets von Systemkomponenten liegen unterhalb einer Schwelle namens FIRST_APPLICATION_UID und gelten als System, dürfen also jedes Netz erreichen, egal was ein VPN im Nutzerraum gerade tut. Das System muss unter allen Umständen mit dem Netz sprechen können, für sich genommen ist die Ausnahme also vernünftig. Zum Problem wird sie in dem Moment, in dem eine gewöhnliche App einen Systemprozess überreden kann, ein Paket an ihrer Stelle zu senden.

Leck eins: der höfliche Abschied

Android 16 bekam eine Funktion für das saubere Beenden von QUIC-Verbindungen. Stirbt der Socket einer App unerwartet, bleibt der Server am anderen Ende bis zum Timeout auf einer halboffenen Verbindung sitzen, also lässt das System jetzt ein Abschiedspaket vorab registrieren, das es stellvertretend zustellt. Der Forscher, der die Lücke fand und unter dem Namen lowlevel publiziert, taufte das Ergebnis die kleine UDP-Kanone.

1. Die App ruft eine Methode des Netzwerkdienstes auf und übergibt ihr einen UDP-Socket samt beliebigem Byte-Block. Eine Rechteprüfung gibt es an dieser Stelle nicht, weder in der Methode noch in der Schnittstellenbeschreibung noch in der Sicherheitsrichtlinie.
2. Das System merkt sich den Aufrufer, das Netz sowie Quell- und Zieladresse des Sockets.
3. Die App beendet sich. Der Kernel meldet den Socket als zerstört.
4. Der Systemprozess öffnet einen frischen Socket im physischen WLAN, verbindet ihn mit dem gemerkten Ziel und sendet die gemerkten Bytes. Das VPN sieht das Paket nie, das Ziel sieht die echte Adresse des Geräts.

Der Forscher meldete den Fund über Androids Bug-Bounty-Programm. Die Meldung wurde als Won't Fix (Infeasible) geschlossen, mit der Begründung, das liege außerhalb des Bedrohungsmodells. Mullvad, das sonst nicht über fremde Fehler schreibt, warnte im Mai und reichte den Fall erneut über den öffentlichen Tracker ein; der Eintrag wurde daraufhin ohne Erklärung als nicht zugänglich markiert. GrapheneOS lieferte einen Fix, der die Optimierung abschaltet.

Leck zwei: das Keepalive sendet der WLAN-Chip für Sie

Der zweite Fund, am 29. Juli von Armin Šupuk veröffentlicht und am 10. September von Mullvad aufbereitet, nimmt eine andere Tür in denselben Raum. Android bietet eine öffentliche Schnittstelle, um eine NAT-Zuordnung am Leben zu halten: Eine App bittet das System, ein kleines UDP-Paket periodisch zu senden, damit eine Verbindung über den Heimrouter nicht abreißt. Aus Effizienzgründen wandert die Aufgabe hinunter zum WLAN- oder Mobilfunkchip, der die Pakete selbst abfeuert.

Das Framework nimmt die Anfrage an, ohne zu prüfen, ob der Aufrufer die referenzierte Ressource überhaupt besitzt, und ohne zu fragen, ob für ihn die VPN-Sperre gilt. Anschließend entsteht das Keepalive in der Netzwerkhardware, unterhalb der Ebene, auf der die VPN-Regeln greifen. Pakete festen Formats auf UDP-Port 4500 landen bei der Adresse, die die App gewählt hat, und tragen die echte IP.

Die Arbeit führt den Fehler auf ein Vertrauensmodell zurück, das über die Jahre auseinanderfiel. Der Aufruf begann als privilegierte Schnittstelle mit rohem Dateideskriptor, bekam einen öffentlichen Einstiegspunkt, dann eine Ressourcenprüfung, und verlor diese bei einem Revert wieder. Was blieb, lässt die Anfrage durch, ohne einen Besitznachweis zu verlangen.

Die eigene Notiz des Melders im GrapheneOS-Tracker fällt schmaler aus als die Überschrift der Arbeit: Auf Pixel-Geräten funktioniert es über WLAN und größtenteils nicht über IPv6. Dafür ist es hartnäckig. Das Leck läuft im Hintergrund weiter, im Sperrbildschirm, im Doze-Modus, im Energiesparmodus und unter dem Prozess-Freezer, und es übersteht das erzwungene Beenden der App.

Was tatsächlich nach draußen geht

Nicht Ihre Nachrichten. Beide Lecks sind schmale Kanäle: Die App bestimmt, wohin das Paket geht, und im QUIC-Fall zusätzlich, was in ein paar Bytes davon steht. Die Gegenseite erfährt, dass ein bestimmtes Gerät mit einer bestimmten öffentlichen IP-Adresse existiert und gerade online ist. Für eine App, die ohnehin weiß, wer Sie sind, ist das das fehlende Glied zwischen Konto und Aufenthaltsort, und genau das sollte das VPN verhindern.

Warum sich das wiederholt

Beide Lecks stammen aus derselben Entwurfsentscheidung: Komfortfunktionen, die einen Systemprozess im Auftrag einer App handeln lassen, geschrieben ohne die Frage, ob diese App in diesem Moment überhaupt direkt ins Netz darf. Die Sperrprüfung filtert App-Identitäten, alles unter einer Systemidentität liegt außerhalb ihrer Reichweite.

Und es bleibt nicht bei zweien. In der Diskussion bei GrapheneOS merkte ein Betreuer an, das Projekt habe mindestens zehn weitere Lecks selbst gefunden und behoben, und Lecks, die ohne bösen Willen einer App auftreten, hätten Vorrang vor diesen beiden. Derselbe Betreuer wurde bei den Anreizen deutlich: Google zahlt für VPN-Lecks nicht, und Meldungen lohnen sich fürs Protokoll, nicht in Erwartung eines Patches.

Was Sie tun können

Was das für die VPN-Wahl bedeutet

Hier lohnt Genauigkeit bei der Schuldfrage, denn die Werbung dazu wird nicht genau sein. Kein VPN-Dienst kann eines der beiden Lecks beheben, und keiner hat sie verursacht: Die Pakete erreichen die Anwendungsebene, auf der ein VPN-Client arbeitet, nie. Woran sich ein Anbieter hier fair messen lässt, ist die Frage, ob er seine Nutzer überhaupt informiert hat. Wenn Sie eine App fürs Telefon aussuchen, behandelt unser Überblick zu VPNs für Android das, was die App selbst steuert, also alles oberhalb dieser Ebene.