Android NAT-T keepalive offload bypasses VPN lockdown
Une application Android ordinaire peut, via IpSecManager.UdpEncapsulationSocket et ConnectivityManager.createSocketKeepalive, déclencher l'émission répétée de paquets UDP/4500 NAT‑T sur l'interface réseau physique alors que l'option Toujours actif et « Bloquer les connexions sans VPN » est activée. Une capture contrôlée sur un Pixel 8 Pro a enregistré des paquets toutes les 10 secondes, et des observations indépendantes sur un Samsung SM‑F966B et un Nothing A059 ont confirmé des créneaux actifs via la même voie publique, établissant une exposition trans‑OEM et, selon le recensement, sur une large part des appareils Android 12+ (environ 91 % des expéditions estimées). La cause profonde est un modèle de confiance effondré : la méthode fd‑based startNattKeepaliveWithFd(...) accepte des descripteurs et des resourceId non authentifiés après l'annulation des contrôles d'ownership et de verrouillage en 2019, et n'applique pas la politique VPN effective de l'UID appelant avant l'offload matériel. L'impact est une divulgation répétée de l'adresse IP source réelle et de la cadence temporelle vers un point de terminaison choisi par l'attaquant, pouvant être provoquée par une application normale sans privilèges, ADB, root ou permission dangereuse. Le correctif recommandé exige d'authentifier le couple fd/resource et la propriété du socket, de vérifier et révoquer l'autorisation en fonction de la politique VPN effective avant toute admission matérielle, d'assurer le verrouillage de durée et l'interdiction des usages concurrents, et de faire échouer à fermée les offloads non privilégiés, voire de déprécier l'accès IPsec public aux applications normales.