Es posible que el tráfico DNS se filtre fuera del túnel VPN en Android

Es posible que el tráfico DNS se filtre fuera del túnel VPN en Android

Confirmación de fugas múltiples de DNS

• Recientemente se descubrió una posible fuga de DNS múltiple en Android
• Proviene de un error nativo de Android y solo afecta a ciertas apps
• El 22 de abril, lunes, se confirmó la fuga de DNS a partir de un reporte de un usuario de Reddit
  • El usuario encontró que, con la configuración "Bloquear conexiones sin VPN" habilitada, al desactivar y activar el VPN se escapaban consultas DNS
• Se inició de inmediato una investigación interna y se pudo verificar el problema
• La investigación reveló más escenarios en los que Android puede provocar fugas de DNS

Hallazgos

Se identificaron los escenarios en los que el tráfico DNS puede filtrarse en Android:

• Cuando el VPN está activo sin que haya un servidor DNS configurado
• Durante un corto intervalo cuando la app VPN está reconfigurando el túnel o se fuerza su cierre/fallo

La fuga parece limitarse a llamadas directas a la función C getaddrinfo:

• En los escenarios listados, las apps que usan este método para resolver nombres de dominio provocan fugas
• En apps que solo usan APIs de Android como DnsResolver no se detectaron fugas
• Un ejemplo de app que puede usar getaddrinfo directamente es el navegador Chrome

Esto aplica independientemente de que estén habilitados Always-on VPN y Block connections without VPN:

• No es un comportamiento esperado del sistema operativo, por lo que debe corregirse en el upstream del OS

Se pudo confirmar esta fuga en varias versiones de Android (incluyendo la más reciente, Android 14)

Mejoras

Actualmente la app no configura el servidor DNS cuando está en estado bloqueado:

• Si la app no logra configurar el túnel de forma recuperable, pasa a estado bloqueado
• En ese estado, el tráfico deja de salir del dispositivo
• Sin embargo, como no se configura un servidor DNS en ese estado, puede ocurrir la fuga DNS descrita
• Temporalmente se planea establecer un servidor DNS falso para eludir el bug del OS
• Se espera un release pronto que incluya esta corrección

Mitigar la fuga durante la reconexión del túnel desde la app es más difícil:

• Aún se sigue buscando una solución
• Es posible minimizar la cantidad de reconfiguraciones del túnel, pero de momento no creemos posible prevenir completamente esta fuga

Debe dejarse claro que ningún app VPN debería requerir estas mitigaciones:

• No está mal que una app use getaddrinfo para resolver nombres de dominio
• En cambio, para proteger a todos los usuarios de Android independientemente de la app usada, este problema debe resolverse en el OS

Se reportó el problema a Google y se propusieron mejoras, esperando que se resuelva lo antes posible

Pasos para reproducir

Estos pasos reproducen el segundo escenario anterior, donde el usuario VPN cambia la configuración del túnel (por ejemplo, cambiar a otro servidor o modificar el DNS):

• Se usa la app WireGuard, porque es la implementación de referencia de VPN en Android
• Hay que considerar que la fuga probablemente también pueda reproducirse con otras apps VPN de Android
• Se usa Chrome para disparar la fuga, ya que es una de las apps confirmadas como usuaria de getaddrinfo

1. Descargar spam_get_requests.html

2. Instalar las apps WireGuard y Chrome

3. Importar wg1.conf y wg2.conf en WireGuard

4. Activar el túnel wg1 en la app WireGuard y conceder permisos VPN

5. En la configuración VPN de Android, habilitar "Always-on VPN" y "Block connections without VPN" para WireGuard

6. Iniciar captura de datos en el router usando tcpdump $ tcpdump -i <INTERFACE> host <IP of android device>

7. Dividir la pantalla para mostrar WireGuard y Chrome en paralelo

8. Abrir spam_get_requests.html en Chrome y pulsar "Start"

9. En la app WireGuard, alternar entre wg1 y wg2 repetidamente hasta que la fuga se muestre en el siguiente paso

10. Observar en el router tráfico DNS como el siguiente:

    11:50:27.816359 IP Pixel-Tablet.lan.53353 > OpenWrt.lan.53: 11200+ A? 307lf5rgn6-19282-11-50-27-519z.mullvad.test.lan. (65)
    11:50:27.816359 IP Pixel-Tablet.lan.48267 > OpenWrt.lan.53: 44347+ A? 307lf5rgn6-19284-11-50-27-579z.mullvad.test.lan. (65) 
    11:50:27.816396 IP Pixel-Tablet.lan.16747 > OpenWrt.lan.53: 44584+ A? 307lf5rgn6-19289-11-50-27-729z.mullvad.test. (61)
    11:50:27.816458 IP OpenWrt.lan.53 > Pixel-Tablet.lan.53353: 11200 NXDomain 0/0/0 (65)
    11:50:27.816476 IP Pixel-Tablet.lan.45727 > OpenWrt.lan.53: 40503+ A? 307lf5rgn6-19290-11-50-27-759z.mullvad.test. (61)
    11:50:27.816542 IP OpenWrt.lan.53 > Pixel-Tablet.lan.48267: 44347 NXDomain 0/0/0 (65) 
    11:50:27.816588 IP Pixel-Tablet.lan.43821 > OpenWrt.lan.53: 36295+ A? 307lf5rgn6-19291-11-50-27-789z.mullvad.test. (61)
    11:50:27.816625 IP OpenWrt.lan.53 > Pixel-Tablet.lan.16747: 44584 NXDomain 0/0/0 (61)
    

Aunque "Block connections without VPN" estaba habilitado, y nada debería salir del dispositivo salvo el tráfico cifrado de WireGuard, aquí puede verse cómo sale DNS en texto plano desde el dispositivo

Conclusión y recomendaciones

La fuga de DNS puede tener un impacto grave en la privacidad del usuario, y puede usarse para determinar su ubicación aproximada o averiguar qué sitios y servicios utiliza

Estos hallazgos muestran nuevamente que "Block connections without VPN" no concuerda con su nombre (o documentación) y que presenta varias fallas:

• Bajo las condiciones mencionadas arriba, una app aún puede filtrar tráfico DNS
• Al igual que se había reportado antes, aún se está filtrando tráfico de verificación de conexión

Según el modelo de amenaza, puede ser necesario dejar de usar Android para tareas sensibles o aplicar otras medidas de mitigación para prevenir fugas:

• Como el objetivo es mitigar este problema parcialmente desde la app, conviene mantener la app actualizada

Opinión de GN⁺

• Este problema es, en esencia, un bug del OS Android y debería corregirse pronto por Google; no es deseable que todos los desarrolladores de apps con capacidad VPN tengan que trabajar para resolverlo por su cuenta
• Que la opción "Block connections without VPN" no se comporte como indica la documentación y que exista fuga de DNS es un problema importante para los usuarios. Uno de los motivos principales para usar VPN es la protección de la privacidad, y esto puede exponer detalles como el historial de navegación del usuario
• La seguridad de la tecnología de túnel VPN en sí sigue siendo alta, pero quizá convenga considerar usar también soluciones de seguridad/privacidad adicionales además de VPN para prevenir fugas no intencionales del OS
• Desde el punto de vista del desarrollo de apps, aunque éstas estén implementando parches para saltarse el bug del OS, a largo plazo parece necesaria una mejora del sistema operativo para resolver el problema de fondo
• A medida que la tecnología VPN se vuelve más avanzada y masiva, este tipo de problemas de seguridad vuelve a cobrar protagonismo. En adelante, seguramente hará falta una mayor auditoría de seguridad y mejora continua de la red y las funciones VPN del OS móvil

[GN⁺]

Opinión en Hacker News

• Se elogió que Mullvad explicó muy bien su abundante información, así como la descripción del problema, una solución temporal, una posible solución y los cambios que deberían hacerse en Android.
• El "paranoid networking" de Android tiene excepciones para apps del sistema y de OEM, y el desarrollador de rethinkdns dijo que la mayoría de los parches de errores no cambiarán esa suposición central.
• Android soporta un "handover" fluido entre dos dispositivos TUN, pero su implementación es compleja.
• Android ha tenido desde hace tiempo el problema de cambiar a datos celulares y usar DNS externos incluso al intentar usar solo servidores DNS internos.
• En Apple, dado que por defecto la VPN de "privacidad" intenta enrutar todo por proxy, se espera que con productos competidores la situación no sea mejor.
• En Android no se pueden establecer servidores DNS IPv6 directamente y este valor cambia cada vez que cambia la red Wi-Fi.
• Es posible prevenir fugas de tráfico bloqueando con un firewall de MikroTik todo el tráfico que no vaya a la dirección IP del servidor VPN.
• Todos los sistemas sin acceso root son intrínsecamente inseguros, y Android e iOS son ridículos.
• La configuración más segura es apagar los datos móviles del teléfono y usar un hotspot OpenWRT para hacer VPN en la salida.
• La fuga de DNS puede exponer la ubicación de navegación e incluso la ubicación real del usuario, lo que anula el propósito del VPN.
• En iOS también hay fugas de tráfico APNS fuera del túnel VPN (excepto para el VPN soportado por el sistema operativo instalado con un perfil de aprovisionamiento).
• Se plantea la duda de si estos "errores" fueron intencionalmente introducidos, dado que es difícil creer que tantos fallos en Android existan por accidente si consideramos que las grandes empresas tecnológicas trabajan con agencias de inteligencia.