Posible fuga de tráfico DNS fuera del túnel VPN en Android

 (mullvad.net)
2 puntos por GN⁺ 2024-05-04 | 1 comentarios | Compartir por WhatsApp
  • En algunas combinaciones de apps y estados en Android, las consultas DNS pueden salir fuera del túnel VPN, y Mullvad considera que la causa es un bug del sistema operativo Android más que de la app de VPN
  • La fuga puede ocurrir incluso con la VPN activada durante breves transiciones, como cuando no hay servidores DNS configurados, durante la reconfiguración del túnel, o si la app de VPN es forzada a cerrarse o se bloquea
  • El impacto se concentra en apps que llaman directamente a getaddrinfo, y no se detectó fuga en apps que solo usan la API de Android DnsResolver
  • El problema no se bloquea por completo incluso con Always-on VPN y “Block connections without VPN” activados, y se ha confirmado en varias versiones, incluida Android 14
  • Mullvad planea mitigar temporalmente algunos casos configurando un servidor DNS falso, pero las fugas durante la reconexión son difíciles de bloquear por completo sin una corrección del sistema operativo

Condiciones de la fuga DNS observada en Android

  • Mullvad confirmó el 22 de abril, a partir del reporte de un usuario en Reddit, que puede producirse una fuga DNS al apagar y volver a encender la VPN con “Block connections without VPN” activado
  • En la investigación interna surgieron más escenarios en los que Android OS puede enviar tráfico DNS fuera de la VPN
    • Cuando la VPN está activa pero no hay un servidor DNS configurado
    • Mientras la app de VPN reconfigura el túnel
    • Durante el breve lapso en que la app de VPN es forzada a cerrarse o falla
  • Este comportamiento no coincide con el funcionamiento esperado de Android OS y debe corregirse en un nivel superior del sistema operativo

Apps afectadas y ruta de resolución de nombres

  • La fuga parece ocurrir en apps que llaman directamente a la función C getaddrinfo para resolver nombres de dominio
  • Mullvad no detectó fugas en apps que solo usan la API de Android DnsResolver
  • El navegador Chrome es un ejemplo de app que puede usar getaddrinfo directamente
  • Usar getaddrinfo no es en sí mismo algo incorrecto, y para proteger a todos los usuarios de Android hace falta una solución a nivel del sistema operativo

Límites de Always-on VPN y del bloqueo de conexiones

  • Las fugas confirmadas ocurren independientemente de que Always-on VPN y “Block connections without VPN” estén activados o no
  • Si “Block connections without VPN” está activado, no debería salir del dispositivo nada excepto tráfico WireGuard cifrado, pero durante la reproducción del problema se observó DNS en texto plano en el router
  • Mullvad considera que esta configuración no cumple con lo que su nombre o su comportamiento documentado prometen y que presenta varios defectos
    • El tráfico DNS puede filtrarse en las condiciones anteriores
    • Como ya habían reportado antes, el tráfico de verificación de conectividad también sigue filtrándose

Mitigación temporal en la app de Mullvad y problemas pendientes

  • La app de Mullvad actualmente no configura un servidor DNS cuando entra en estado de bloqueo
    • Si la configuración del túnel falla de una manera no recuperable, la app entra en estado de bloqueo
    • En ese estado evita que el tráfico salga del dispositivo, pero al dejar vacío el DNS puede darse la condición que provoca la fuga
  • Mullvad planea responder por ahora configurando un servidor DNS falso para rodear el bug del sistema operativo, y prevé publicar pronto una versión con esa corrección
  • Las fugas que ocurren durante la reconexión del túnel son más difíciles de mitigar desde la app
    • Mullvad está buscando una solución
    • Puede que reduzca la cantidad de reconfiguraciones del túnel, pero por ahora no considera posible bloquear por completo esta fuga
  • Mullvad reportó a Google el problema y una propuesta de mejora

Observaciones al reproducirlo con WireGuard y Chrome

  • El segundo escenario, la fuga durante cambios en la configuración del túnel VPN, puede reproducirse con la app de WireGuard y Chrome
    • WireGuard se usa como caso de referencia para la implementación de VPN en Android
    • Mullvad cree que también podría reproducirse en otras apps VPN para Android
    • Chrome se usa para activar la fuga porque está confirmado que utiliza getaddrinfo
  • El procedimiento de reproducción incluye estos elementos
    • Descargar spam_get_requests.html
    • Instalar la app de WireGuard y Chrome
    • Importar wg1.conf y wg2.conf en WireGuard
    • Activar el túnel wg1 en WireGuard y conceder permisos de VPN
    • Activar Always-on VPN y “Block connections without VPN” para WireGuard en la configuración VPN de Android
    • Iniciar la captura en el router con tcpdump -i <INTERFACE> host <IP of android device>
    • Abrir WireGuard y Chrome en pantalla dividida, ejecutar spam_get_requests.html en Chrome y alternar entre wg1 y wg2 desde WireGuard
  • En el router se observaron consultas de registros A y respuestas NXDomain dirigidas al puerto 53 del router OpenWrt desde el dispositivo Android
  • La fuga DNS puede usarse para inferir la ubicación aproximada del usuario o los sitios web y servicios que visita, por lo que el impacto en la privacidad puede ser importante
  • Según el modelo de amenaza, en usos sensibles podría ser necesario evitar Android o aplicar otras mitigaciones para prevenir esta fuga
  • Los usuarios de la app de Mullvad deberían mantenerla actualizada, ya que puede incluir una mitigación parcial

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-05-04
Opiniones en Hacker News

  • No uso Mullvad, pero de verdad me ganaron el respeto. La descripción del problema, la solución temporal a corto plazo, posibles soluciones alternativas que otros pueden usar y hasta lo que Android debería corregir están muy bien organizados y con mucha densidad de información.

    • Elegí Mullvad como servicio de VPN justamente porque publican este tipo de artículos de blog, en vez de hacer patrocinios interminables en YouTube como la competencia.
    • Aunque no uses VPN, Mullvad tiene un servicio de DNS gratuito. El aumento de tráfico/uso también puede ser una forma de apoyarlos, y desde el punto de vista de las solicitudes DNS, probablemente ayude a que los usuarios de Mullvad VPN llamen menos la atención.
      La desventaja es que, en mi caso, el ping es bastante más alto que con quad9 o cloudflare.
      En este hilo dejé un método para bloquear anuncios a nivel DNS e información relacionada con cloudflare: https://news.ycombinator.com/item?id=40056162
    • Por sus valores, su forma de pensar, la lealtad a sus creencias centrales y la evidencia constante de haber mantenido su lema durante décadas, me parece la mejor VPN.
    • Como usuario de Mullvad, estoy muy satisfecho. Una vez escribí al equipo de soporte por una consulta de pago y de paso agregué una pequeña pregunta sobre iptables relacionada con un problema que estaba teniendo.
      Me resolvieron rápido el problema de pago y, sobre iptables, recibí una respuesta detallada con los pros y contras de varias soluciones. En una palabra: excelente.
    • Si usas VPN, me da curiosidad cuál usas.

  • Soy desarrollador de rethinkdns.
    Sobre la frase “estos problemas deben resolverse en el SO para proteger a todos los usuarios de Android, sin importar qué app usen”, el networking paranoico de Android siempre ha tenido excepciones para apps del sistema y apps de OEM, incluidas las apps de Google.
    Es probable que la mayoría de estas correcciones de bugs tampoco cambien esa suposición central. Código relacionado: https://github.com/celzero/rethink-app/issues/224
    Sobre la parte de “las fugas durante la reconexión del túnel son más difíciles de mitigar desde la app; aún estamos buscando una solución”, Android admite una transición sin interrupciones entre dos dispositivos TUN durante la reconfiguración. Implementarlo correctamente es complicado, pero posible.

    • Ni siquiera te dejan quitarle el permiso de Internet a una app de linterna, lo cual tiene sentido si consideramos que el SO lo opera una empresa de publicidad en Internet.

  • Es un problema que existe en Android desde hace mucho. Aunque quieras usar solo servidores DNS internos, Android cambia a la red celular y usa ese DNS si decide que lo necesita o quiere.
    Hace poco estuve observando la depuración con adb para ver por qué/cuándo se corta la conexión inalámbrica, y al final, si no puede ver o interpretar algo durante la verificación de conectividad, activa los datos celulares e intenta por ahí.
    Es especialmente frustrante cuando usas registros DNS que solo existen internamente y el teléfono se comporta de forma arbitraria. El dispositivo está conectado a una Wi‑Fi que provee el servidor DNS interno donde existen esos registros, pero por alguna razón Android los está resolviendo desde afuera.
    No sé cómo será Apple, pero viendo que básicamente intentan proxificar hasta el DNS con DoH a través de su VPN de “privacy”, me cuesta imaginar que sea mejor cuando usas algo que pueda considerarse un producto competidor, y ya sabemos cómo trata Apple a esos productos.

    • Habría que revisar si eso de “cambia a la red celular y la usa cuando lo necesita o quiere” no es porque está activada la Asistencia para Wi‑Fi. Esa función está diseñada explícitamente para cambiar a datos celulares cuando la señal Wi‑Fi es mala.
    • Apple o iOS tienen una forma integrada bastante sólida de filtrar y bloquear tráfico usando perfiles de configuración. No estoy seguro de si se puede configurar por app, pero definitivamente se pueden definir listas de permitidos/bloqueados por nombre de host.
      Como ejemplo real, mira este bloqueador de anuncios para todo el sistema: https://myxxdev.github.io/depictions/MYbloXXforiOS/MYbloXXfo...
    • iOS nunca usa Private Relay de forma predeterminada. Aunque esté incluido en tu suscripción, tienes que activarlo tú mismo explícitamente.
    • Me pregunto si probaste desactivar “Datos móviles siempre activos” en las opciones de desarrollador.
    • He compilado AOSP desde el código fuente. Es algo que no debería tener requisitos exclusivos de Google, y bloqueé en el archivo hosts tantos servidores de Google como pude para evitar que se conectara a Google a escondidas.
      El único problema que tuve fue que el dispositivo mostraba que no tenía Internet aunque estaba conectado a un AP inalámbrico que funcionaba correctamente. En realidad sí funcionaba, pero para el ícono de la barra de estado y otros propósitos del código interno del sistema parecía verificar contra servidores de Google si Internet estaba funcionando.
      Si te importa la privacidad, conviene mantenerse lejos de Android, y probablemente ser cuidadoso con la tecnología en general.

  • Hace unos años, cuando probaba varias configuraciones de VPN para un proyecto, solía poner un equipo firewall MikroTik entre la computadora y el router principal. El objetivo era simplemente bloquear todo tráfico cuyo destino no fuera la dirección IP del servidor VPN al que la PC intentaba conectarse.
    Este enfoque funcionó muy bien para garantizar que no se filtrara tráfico fuera de la ruta de la PC hacia el servidor VPN. Las direcciones IP de los servidores VPN que uso casi nunca cambian y, si cambian, es fácil actualizarlas en el firewall MikroTik.
    Si no conoces la IP del servidor o cambia, otra opción es bloquear todo tráfico que no corresponda al par puerto/protocolo que usa el servidor VPN. Por ejemplo, según el tipo de VPN, descartar el tráfico cuyo destino no sea UDP 1194.
    Los routers MikroTik también tienen una pequeña herramienta llamada torch para ver el tráfico rápida y fácilmente, y admiten captura de paquetes. Sus precios van de 30 a 3000 dólares, no tienen licencias de software y, si sabes manejarlos, son muy potentes y capaces.

    • A este tipo de equipo se le llama network slug, y es una idea excelente.
      Estrictamente hablando, un slug real es un firewall transparente de capa 2 sin dirección IP definida, pero no hace falta ponernos tan detallistas aquí.
      https://john.kozubik.com/pub/NetworkSlug/tip.html

  • El filtrado de salida basado en direcciones y puertos de origen/destino es un concepto básico de los firewalls y una configuración estándar en todas las plataformas de firewall-enrutamiento. El enrutamiento basado en políticas que filtra según el gateway va en la misma línea: https://en.wikipedia.org/wiki/Policy-based_routing
    En general, solo los productos de consumo o semiprofesionales permiten por defecto todo el tráfico saliente. Me da curiosidad saber qué era ese “router principal” en esta configuración. ¿Era un equipo provisto por el ISP?

    • Ya que estamos recomendando, me pregunto si también hay routers con firewall de capa 7 que sean baratos y decentes.
      También estaría bueno poder poner un firewall entre las apps del teléfono y el módem.

  • El problema de DNS en Android es que en esta plataforma no se puede configurar un servidor DNS IPv6 propio. Cada vez que algo cambia en el Wi-Fi, se modifica.
    Incluso en un Android rooteado no hay apps que impidan que el sistema operativo lo cambie.
    Si usas un router que siempre distribuye direcciones IPv6 y no permite desactivarlo, básicamente estás bloqueado.
    Ni siquiera sé si se puede instalar un equipo firewall detrás de ese router para quitar el servidor DNS IPv6 que anuncia.

    • Se me ocurre que, en lugar de configurar la dirección IP del servidor DNS, podría usarse el soporte de DNS-over-TLS a nivel del sistema. Es una configuración global, así que debería aplicarse sin importar en qué red estés ni qué ocurra en esa red.
      Si te preocupan las fugas de solicitudes DNS, de todos modos deberías usar DoT o DoH.
    • ¿No se puede cambiar el DNS IPv6 con rethink?
    • Parece que se refiere a que eso pasa cuando el teléfono es la interfaz principal.
      Me pregunto si también ocurre con tethering por Wi-Fi. Si uso una VPN en una laptop conectada por el Wi-Fi del teléfono, ¿se filtra de la misma manera?

  • La configuración más segura parece ser apagar los datos móviles del teléfono y llevar un hotspot con OpenWRT que gestione la VPN por encima del teléfono.

    • Exacto. En iOS es una pesadilla aún peor.
      La “VPN siempre activa” solo puede configurarse en dispositivos en estado “supervised” mediante una solución MDM de una organización aprobada por Apple. Requiere una solicitud documentada y una llamada telefónica con un empleado actual.
      O, si no, solo con la app Apple Configurator en una Mac se puede crear un perfil de configuración que incluya la clave “always-on VPN”.
    • Hace tiempo probé esto durante meses con un GL.inet E750 y un iPhone sin SIM, y las operadoras GSM de EE. UU. solían restringir mucho el tráfico UDP en puertos raros. A veces caía a 64-128 kbps, es decir, alrededor de 0.1 Mbps.
      Las notificaciones también se retrasaban con frecuencia.
    • Si usas Wi-Fi público o red móvil, esa es la mejor solución. Si alguien opera directamente una estación base, el teléfono puede conectarse a ella.
      Si no es mi red, es mejor no conectarse directamente sin un router móvil.
    • Como otros dicen que Android vuelve a activar silenciosamente los datos celulares en varias condiciones, este método tampoco es una solución garantizada.
      The Grugq creó una herramienta para este propósito hace 10 años. Lamentablemente, hoy ya no recibe mantenimiento: https://github.com/grugq/portal
      Formaba parte de una charla sobre seguridad operativa para hackers, y vale la pena verla si te interesan casos de varios hackers famosos —o infames— que creían estar seguros, pero terminaron atrapados: https://www.youtube.com/watch?v=9XaYdCdwiWU

  • Un sistema sin acceso root es, por definición, inseguro. Android e iOS son ridículos.

    • También se podría decir que un sistema que tiene el concepto de acceso root es, por definición, inseguro. Cualquiera puede hacer afirmaciones tajantes de ese estilo.
    • Si los teléfonos no hubieran reemplazado a las desktops/laptops para la mayoría de la gente, podríamos reírnos y dejarlo pasar.
      Me dan pena los niños que crecieron, o crecerán, teniendo como “computadora” principalmente un dispositivo diseñado para consumir medios y recolectar datos privados.
    • Los desarrolladores de GrapheneOS están muy en contra del root. Me pregunto qué opinan de esto.
    • El punto es claro y también viene al caso. Por eso no queda otra que sigan aumentando los proyectos de dispositivos móviles con software y hardware de código abierto.
      https://en.wikipedia.org/wiki/PinePhone_Pro
    • Según esa definición, muchos de mis sistemas más importantes serían “inseguros”.
      Si puedes obtener una copia de mi clave privada SSH desde esos dispositivos, te doy 100,000 dólares en efectivo sin hacer preguntas.
      Esa definición no significa nada y no sirve para razonar ni para comunicarse.

  • “Bloquear conexiones sin VPN” está resultando tan poco confiable como mi autocontrol en un buffet. Si no me equivoco, estas fugas de DNS pueden revelar bastante sobre los sitios visitados e incluso la ubicación, lo que destruye el propósito mismo de la VPN.
    Android puede filtrar información DNS aunque la VPN esté activada, así que si la privacidad te importa de verdad, conviene pensar más allá de usar Android o sacar las tareas sensibles del teléfono.

  • A veces sospecho que estos “bugs” no estarán colocados intencionalmente en lugares muy convenientes. Más aún considerando que las grandes tecnológicas han cooperado con varias agencias de inteligencia.
    No es la primera vez que oigo de este tipo de bugs en Android, así que ya me cuesta creer que tantos bugs de este calibre hayan entrado “sin querer”.

    • “Una vez es casualidad, dos veces es coincidence, tres veces es acción enemiga”. —Ian Fleming, Goldfinger

  • Desde hace tiempo sospechaba en cierta medida que pasaba algo así. Aunque actives una VPN en Android, MMS y Visual Voicemail siguen funcionando.
    Ambas cosas a veces requieren acceso móvil directo o son rechazadas. Pueden estar disponibles solo en la red móvil, o rechazarse si la solicitud no viene desde dentro de la red móvil. Sospecho que con VoLTE pasa lo mismo. Con una VPN, estas funciones pueden complicarse.
    En Mobile Linux te das cuenta porque, al activar una VPN, todas estas funciones se rompen.
    No parece haber una forma clara de arreglar esto en Android sin romper muchas funciones esperadas.

    • Irónicamente, SMS/MMS y VVS son de las pocas tareas/funciones para las que podría justificarse que estén hardcodeadas a la conexión de la operadora. Tal vez las actualizaciones del sistema también.

Como ya tuve que lidiar con el equipo de soporte avanzado de AT&T por problemas de VVS en iOS con la VPN activada, puedo confirmar que este problema no se limita únicamente a Android

  • VoLTE usa un bearer dedicado en el stack LTE, es decir, una interfaz de red separada. No es la interfaz para datos
    Distintos bearers pueden tener diferentes prioridades/QCI, es decir, calidad de servicio. En una red LTE congestionada, VoLTE debería ofrecer una mejor experiencia que VOIP sobre un bearer de menor prioridad