Si eres de los que activan VPN siempre encendida en el celular, con la opción de bloquear conexiones sin VPN, probablemente confías en que nada se escapa por fuera del túnel. Pues malas noticias: un investigador independiente (Armin Šupuk) publicó un análisis donde demuestra que casi cualquier app normal en Android 12 o superior puede enviar paquetes por fuera de la VPN, incluso con el modo lockdown activado.
¿Cómo funciona la wea?
El detalle está en la API de keepalive NAT-T de Android (IpSecManager.UdpEncapsulationSocket combinado con ConnectivityManager.createSocketKeepalive()). Esa API es pública y está pensada para que las apps de VPN mantengan vivos los mapeos NAT del túnel. Pero el framework acepta la petición sin verificar si el proceso que llama realmente tiene una política de VPN activa, y delega el envío del paquete al hardware Wi-Fi (keepalive offload). Resultado: paquetes UDP/4500 con formato fijo salen por la interfaz física, directo al router, sin pasar por el túnel.
Šupuk lo comprobó capturando tráfico en su propio access point con un Pixel 8 Pro con Android 16, con VPN siempre activa y lockdown. Los paquetes aparecieron claritos en la red física. Y no es un bug de un fabricante: replicó la observación en un Samsung Galaxy Fold y en un Nothing, y la ruta del framework es la misma para la mayoría de los dispositivos con Android 12+, o sea, exposición de clase de dispositivo, no un caso aislado.
Lo que se filtra (y lo que no)
Seamos honestos con el alcance: no es que tu app de banca esté mandando todo tu tráfico en claro. Lo que se escapa son paquetes de keepalive de formato fijo hacia destinos que la app elige. Pero eso igual filtra información: que el dispositivo existe, que está en esa red, y con quién se comunica, en un momento en que el usuario cree estar 100% dentro del túnel. Para un atacante en la misma red (wifi de hotel, aeropuerto, oficina), es metadata valiosa. Mullvad e IVPN ya han documentado fugas similares, así que esto no viene de la nada.
Mi lectura
Lo que más me llama es la historia del código: la API empezó como privilegiada, con validación de recursos, y en algún punto esa validación se agregó y después se revirtió. El modelo de confianza se derrumbó sin que nadie lo notara hasta que alguien capturó paquetes en su router. Es el patrón clásico de seguridad de plataformas: una API pensada para un actor de confianza se hace pública y nadie re-audita las garantías originales.
¿Qué hacer mientras Google arregla? Nada dramático: si tu nivel de paranoia es normal, sigue usando tu VPN tranquilo. Si trabajas en entornos hostiles, la única mitigación real hoy es controlar el gateway (firewall que solo permita tráfico hacia el servidor VPN), tal como recomiendan en GrapheneOS para estos casos. Y si eres desarrollador de apps de seguridad, revisa si tu app toca estas APIs, porque el detalle de que el framework no autentica el par fd/recurso es oro para entender el problema.
El paper completo con las capturas y la matriz de dispositivos está en el sitio del investigador; vale la pena leerlo, es de esos hallazgos que muestran cuánto falta para que «VPN activa» signifique realmente «nada sale por fuera».
Fuente de inspiración: Android NAT-T Keepalive Offload Bypasses VPN Lockdown: Device-Class Exposure Across Most Android 12+ Devices
