Une nouvelle faille d’Android permet à une application de révéler l’adresse IP réelle d’un appareil malgré un VPN actif, y compris lorsque le système bloque normalement toute connexion qui ne passe pas par le tunnel.
Le problème ne résulte pas du VPN lui-même, mais d’une fonction d’Android qui entretient périodiquement l’activité d’une connexion réseau pour éviter qu’elle ne soit interrompue. Le chercheur indépendant Armin Šupuk, dont les travaux ont été relayés par Mullvad, a établi qu’une application pouvait détourner ce dispositif pour émettre des paquets en dehors du tunnel VPN, sans permission sensible ni accès root. Un serveur contrôlé par l’attaquant peut alors récupérer l’adresse IP réelle du smartphone, même lorsque le VPN permanent et l’option « Bloquer les connexions sans VPN » sont activés au niveau du système.
Des paquets envoyés hors tunnel par la puce Wi-Fi
En temps normal, Android contrôle le trafic émis par les applications avant de l’acheminer dans le tunnel VPN ou de le bloquer si le tunnel n’est pas disponible. Le système embarque aussi une fonction liée au NAT-T, qui permet de préserver l’association établie par le routeur lorsqu’un appareil communique avec Internet derrière une adresse IP publique partagée. Pour cela, Android envoie à intervalles réguliers un petit paquet UDP sur le port 4500, appelé keep-alive, et peut déléguer cette tâche à la puce Wi-Fi afin d’économiser les ressources du système.
Or, une application peut demander à Android d’envoyer ces paquets vers un serveur qu’elle contrôle. Si le système en confie l’émission à la puce Wi-Fi, ils ne repassent plus par les contrôles logiciels qui imposent normalement le VPN ou interrompent la connexion en son absence. Ils quittent alors le smartphone hors du tunnel et révèlent au serveur distant son adresse IP réelle.
Armin Šupuk a confirmé la fuite sur un Pixel 8 Pro sur Android 16, connecté en Wi-Fi. Malgré le VPN permanent et l’activation du kill switch au niveau du système, il a pu capturer sur le réseau les paquets émis toutes les dix secondes depuis l’adresse réelle du smartphone. Des essais menés sur des appareils Samsung et Nothing ont également confirmé que la même fonction pouvait emprunter le chemin matériel en cause, ce qui tend à écarter un défaut propre à un modèle ou constructeur, et pointe plutôt vers Android.
Une parade imparfaite en attendant un correctif Android
C’est aussi le constat dressé par Mullvad qui, à défaut d’une solution pérenne, évoque une parade théorique. La puce Wi-Fi ne peut gérer qu’un nombre limité de connexions keep-alive en parallèle. Il faudrait donc que le client VPN puisse les monopoliser toutes à l’avance afin d’empêcher une application malveillante d’en réserver une et d’exploiter la fuite. Le fournisseur devrait alors volontairement envoyer des paquets hors tunnel, chose contre-intuitive pour un VPN, sans garantie qu’un emplacement n’ait déjà été réservé avant son activation.
D’où l’importance d’un patch au niveau du système, que Google ne semble pas pressée de publier. Šupuk a en effet signalé la faille au programme de récompenses des vulnérabilités Android en mai dernier, mais son rapport a été classé comme doublon d’un problème déjà connu, pour lequel aucun correctif n’a été annoncé depuis.
Mullvad a finalement renoncé à sa solution de fortune. GrapheneOS, système dérivé d’Android et renforcé pour la sécurité et la confidentialité, a, en revanche, confirmé avoir identifié le bug et prévoit de le corriger prochainement.
