Android filtra su IP real pese a la VPN, y Google no lo va a arreglar

Android tiene un interruptor llamado «Bloquear conexiones sin VPN». Actívelo junto con la VPN permanente y el sistema promete que nada sale del dispositivo fuera del túnel. Dos hallazgos independientes de este año demuestran que cualquier aplicación corriente pasa de largo ese interruptor y entrega su dirección IP real al servidor que ella elija. Google cerró los dos avisos sin arreglar nada.

Qué debería garantizar ese interruptor

Cuando se levanta una VPN en Android, el sistema reescribe sus reglas de enrutado para que las aplicaciones cubiertas solo alcancen la red a través de ella. Cada socket lleva una marca que le dice al núcleo a qué red pertenece, y si una aplicación intenta enlazar un socket directamente a la interfaz física de Wi-Fi, la comprobación falla y la llamada devuelve un error de permisos. Esa es la mecánica del ajuste, y funciona.

Funciona para las aplicaciones. Los sockets de los componentes del sistema quedan por debajo de un umbral llamado FIRST_APPLICATION_UID y se etiquetan como de sistema, lo que les permite llegar a cualquier red haga lo que haga una VPN en el espacio de usuario. El sistema tiene que poder hablar con la red pase lo que pase, así que la excepción por sí sola es razonable. Se convierte en problema en cuanto una aplicación corriente puede convencer a un proceso del sistema de que envíe un paquete en su nombre.

Fuga uno: la despedida cortés

Android 16 incorporó una función para cerrar limpiamente las conexiones QUIC. Si el socket de una aplicación muere de golpe, el servidor del otro extremo se queda con una conexión a medio abrir hasta que expire, así que ahora el sistema permite registrar por adelantado un paquete de despedida que él mismo entregará. El investigador que la encontró, que publica como lowlevel, bautizó el resultado como el pequeño cañón UDP.

1. La aplicación llama a un método del servicio de red y le entrega un socket UDP y un bloque de bytes arbitrario. En esa llamada no hay comprobación de permisos: ni en el método, ni en la descripción de la interfaz, ni en la política de seguridad.
2. El sistema anota quién llama, la red y las direcciones y puertos de origen y destino del socket.
3. La aplicación termina. El núcleo informa de que el socket ha sido destruido.
4. El proceso del sistema abre un socket nuevo en la red Wi-Fi física, lo conecta al destino anotado y envía los bytes anotados. La VPN nunca ve ese paquete y el destino ve la dirección real del dispositivo.

El investigador lo comunicó por el programa de recompensas de Android. El aviso se cerró como Won't Fix (Infeasible), razonando que queda fuera del modelo de amenazas. Mullvad, que no suele escribir sobre fallos ajenos, publicó una advertencia en mayo y volvió a presentar el caso en el rastreador público; el registro quedó luego marcado como inaccesible sin explicación. GrapheneOS publicó un parche que apaga la optimización.

Fuga dos: el keepalive lo manda el propio chip de Wi-Fi

El segundo hallazgo, publicado el 29 de julio por Armin Šupuk y analizado por Mullvad el 10 de septiembre, entra a la misma sala por otra puerta. Android expone una interfaz pública para mantener viva una traducción NAT: la aplicación pide al sistema que emita cada cierto tiempo un pequeño paquete UDP para que la conexión a través del router doméstico no se caiga. Por eficiencia, la tarea baja al chip de Wi-Fi o al de datos móviles, que emite los paquetes él mismo.

El framework acepta la petición sin comprobar que quien llama posee de verdad el recurso al que apunta y sin preguntarse si le afecta el bloqueo de la VPN. A partir de ahí el keepalive nace en el hardware de red, por debajo de la capa donde viven las reglas del túnel. Paquetes de formato fijo al puerto UDP 4500 llegan a la dirección que eligió la aplicación, cargando la IP real.

El estudio rastrea un modelo de confianza que se fue deshaciendo. La llamada nació como una interfaz privilegiada que recibía un descriptor de archivo en crudo, ganó un punto de entrada público, después una validación del recurso, y volvió a perderla en una reversión. Lo que queda admite la petición sin exigir prueba alguna de propiedad.

La nota del propio autor en el rastreador de GrapheneOS es más estrecha que el titular del estudio: en dispositivos Pixel funciona por Wi-Fi y casi nunca por IPv6. Eso sí, es tozuda. La fuga sigue con la aplicación en segundo plano, con la pantalla bloqueada, en modo Doze, en ahorro de energía y bajo el congelador de procesos, y sobrevive a forzar la detención de la aplicación.

Qué se escapa en realidad

Sus mensajes no. Ambas fugas son canales estrechos: la aplicación controla adónde va el paquete y, en el caso de QUIC, qué contienen unos pocos bytes. Lo que aprende el otro extremo es que un dispositivo concreto con una IP pública concreta existe y está conectado ahora mismo. Para una aplicación que ya sabe quién es usted, ese es el eslabón que faltaba entre una cuenta y una ubicación, justo lo que la VPN debía impedir.

Por qué se repite

Las dos fugas nacen de la misma decisión de diseño: funciones de comodidad que dejan a un proceso del sistema actuar en nombre de una aplicación, escritas sin preguntarse si esa aplicación puede en ese momento salir a la red por su cuenta. La comprobación de bloqueo filtra identidades de aplicaciones, así que todo lo que se ejecuta con identidad de sistema queda fuera de su alcance.

Y la lista no se queda en dos. En la discusión de GrapheneOS un mantenedor señaló que el proyecto ha encontrado y corregido por su cuenta al menos diez fugas más, y que las que ocurren sin que una aplicación intente escaparse a propósito van antes que estas dos. El mismo mantenedor fue claro con los incentivos: Google no paga por fugas de VPN, y comunicarlas sirve para dejar constancia, no para esperar un parche.

Qué puede hacer usted

Qué cambia esto al elegir VPN

Conviene ser preciso con la culpa, porque la publicidad alrededor de esto no lo será. Ningún servicio de VPN puede arreglar estas fugas y ninguno las provocó: los paquetes nunca llegan a la capa de aplicación donde trabaja un cliente VPN. Lo que sí se le puede exigir a un proveedor es si avisó a sus usuarios. Si está eligiendo una aplicación para el móvil, nuestra guía de VPN para Android trata lo que la aplicación sí controla, es decir, todo lo que queda por encima de esta capa.