Atacantes pueden exponer VPN basadas en enrutamiento
(leviathansecurity.com)- TunnelVision (CVE-2024-3661) explota una función existente de DHCP para desviar el tráfico del usuario fuera del túnel VPN, de modo que los paquetes no se cifran con la VPN
- Un atacante puede inyectar rutas más específicas con DHCP option 121 para crear rutas con prioridad sobre la interfaz virtual de la VPN y enviar el tráfico por la interfaz física
- El ataque es posible si el objetivo acepta un arrendamiento DHCP controlado por el atacante y el cliente implementa option 121; en las pruebas, Windows, Linux, iOS y macOS resultaron afectados, mientras que Android quedó fuera
- El canal de control de la VPN sigue activo, por lo que el usuario ve la conexión como si siguiera establecida; en los casos observados, incluso el kill switch no evitó la fuga de tráfico
- Los network namespaces de Linux pueden ser una solución sólida, pero las mitigaciones basadas en firewall pueden crear denegación selectiva de servicio y canales laterales para inferir destinos del tráfico
TunnelVision y el decloaking de VPN
- TunnelVision es una técnica de red que evade la encapsulación de la VPN y fuerza el tráfico del usuario a salir fuera del túnel
- Un atacante puede usar DHCP (Dynamic Host Configuration Protocol) para hacer que los paquetes del objetivo se transmitan sin cifrado de la VPN
- Como el canal de control de la VPN se mantiene, el usuario sigue viendo que está conectado a la VPN; a este efecto se le llama decloaking
- Esta técnica podría haber sido posible desde 2002, y tras su divulgación se confirmó que ya existían investigaciones previas sobre DHCP option 121 y su impacto en VPN al menos desde 2015
- 2015: Hardening OpenVPN for Def Con
- 2016: Samy Kamkar's
- 2017: Jomo's Mastodon
- 2023: Lowend talk thread
Por qué el enrutamiento de la VPN se convierte en superficie de ataque
- Una VPN crea un túnel para el tráfico entre el dispositivo host y un servidor en otra red, y el cliente VPN cifra y descifra el tráfico en una interfaz de red virtual
- Una configuración que envía todo el tráfico por la VPN se llama full-tunnel VPN, mientras que una configuración con excepciones como la red local se llama split-tunnel VPN
- Como la VPN debe mantener la conexión con el servidor, necesita una ruta de excepción que envíe por la interfaz física el tráfico dirigido a la IP del servidor VPN
- La tabla de enrutamiento determina la ruta del tráfico según el destino, y en la mayoría de los stacks de red tiene prioridad el CIDR prefix length más específico
- Una ruta
/32tiene prioridad sobre/24o/0 - Muchas VPN full-tunnel envían el tráfico a la interfaz VPN con
0.0.0.0/0o con dos rutas/1
- Una ruta
Inyección de rutas con DHCP option 121
- DHCP proporciona dinámicamente arrendamientos de direcciones IP a dispositivos de la red local y, mediante options, también entrega configuraciones como gateway predeterminado y servidores DNS
- El flujo típico es que el cliente difunda
DHCPDISCOVERpor broadcast y el servidor responda conDHCPOFFERproponiendo un arrendamiento con tiempo limitado - DHCP option 121, introducida en RFC 3442, es la función de classless static routes que permite al servidor DHCP agregar rutas estáticas a la tabla de enrutamiento del cliente
- option 121 no permite que el servidor DHCP indique directamente qué dispositivo de interfaz de red debe usar la ruta instalada
- El servidor DHCP especifica el rango CIDR y el router
- El cliente elige implícitamente como interfaz de esa ruta la interfaz por la que se comunica con el servidor DHCP
- Debido a este comportamiento, el tráfico de las rutas inyectadas puede salir por la interfaz física de red que se comunica con el servidor DHCP, y no por la interfaz virtual de la VPN
Condiciones y ejecución del ataque
- El ataque TunnelVision requiere dos condiciones
- Que el host objetivo acepte un arrendamiento del servidor DHCP controlado por el atacante
- Que el cliente DHCP del host objetivo implemente DHCP option 121
- Un atacante en la misma red puede convertirse en el servidor DHCP del objetivo de varias formas
- Lanzando un ataque de DHCP starvation contra el servidor DHCP real y luego respondiendo a nuevos clientes
- Respondiendo antes al broadcast
DHCPDISCOVERpara aprovechar el comportamiento del cliente DHCP que elige la primera oferta - Interceptando con ARP spoofing el tráfico entre el servidor DHCP real y el cliente, y esperando la renovación del arrendamiento
- El atacante ejecuta un servidor DHCP en la misma red que el usuario de la VPN objetivo y se configura a sí mismo como gateway
- Luego agrega rutas arbitrarias a la tabla de enrutamiento del usuario VPN con DHCP option 121, insertando rutas más específicas que
/0para que tengan prioridad sobre la interfaz virtual de la VPN- Puede configurar varias rutas
/1para reproducir la regla de tráfico total0.0.0.0/0que usan la mayoría de las VPN - El atacante puede elegir qué direcciones IP irán por el túnel VPN y cuáles saldrán por la interfaz que se comunica con el servidor DHCP del atacante
- Puede configurar varias rutas
- También puede aplicarse a conexiones VPN ya establecidas, y si se configura un tiempo de arrendamiento DHCP corto se puede forzar una actualización más frecuente de la tabla de enrutamiento
PoC y escenarios de prueba
- El material publicado incluye lo siguiente
- Video proof of concept: https://www.youtube.com/watch?v=ajsLmZia6UU
- Lab Setup Code: https://github.com/leviathansecurity/TunnelVision
- DHCP Server image: https://drive.google.com/file/d/1WLJGs3ZUypf6hLh5WL4AJmsKdUOZo5yZ
- El entorno de pruebas fue diseñado para representar varios escenarios de ataque
- Cuando el atacante compromete el servidor DHCP o el punto de acceso
- Cuando un administrador malicioso posee y configura directamente la infraestructura
- Cuando el atacante instala un AP inalámbrico evil twin en un lugar físico como una cafetería u oficina
- En el futuro, tras la publicación de ArcaneTrickster, también se podrá simular a un atacante host adyacente en la misma LAN pero sin una posición privilegiada en la red
Sistemas operativos y VPN afectados
- En las pruebas, los sistemas operativos que implementan clientes DHCP conforme a la especificación RFC y soportan rutas DHCP option 121 resultaron afectados
- Afectados observados: Windows, Linux, iOS, macOS
- Excepción: Android no se ve afectado porque no soporta DHCP option 121
- Son vulnerables las VPN que dependen solo de reglas de enrutamiento para proteger el tráfico del host
- Incluso los administradores que operan su propio servidor VPN pueden ser vulnerables si no reforzaron la configuración del cliente VPN
- La fortaleza del algoritmo de cifrado no influye
- TunnelVision no rompe los propios protocolos VPN como WireGuard, OpenVPN o IPsec
- Su método consiste en cambiar la configuración de enrutamiento del stack de red del sistema operativo para que el usuario deje de usar el túnel VPN
Correcciones y mitigaciones
- Los network namespaces de Linux pueden corregir completamente este comportamiento
- La documentación de WireGuard muestra cómo manejar el tráfico de aplicaciones que deben usar la VPN en un namespace separado y luego enviarlo a otro namespace que tiene la interfaz física
- No está claro si existe una solución igual de robusta en Windows, macOS u otros sistemas operativos
- Algunos proveedores de VPN usan como mitigación reglas de firewall que bloquean todo el tráfico entrante y saliente de la interfaz física
- Para mantener la conectividad con la LAN y el servidor VPN se necesitan excepciones para DHCP y para la IP del servidor VPN
- También podría permitirse solo DHCP y el protocolo VPN mediante inspección profunda de paquetes, aunque esto probablemente implique una penalización de rendimiento
- Las mitigaciones con firewall crean denegación selectiva de servicio para el tráfico que usa rutas DHCP y añaden canales laterales
- El atacante puede analizar cambios en el volumen del tráfico cifrado de la VPN para demostrar estadísticamente si el usuario objetivo está enviando tráfico a un destino específico
- Puede contrastarlo con una lista predefinida, aplicar bloqueo selectivo como mecanismo de censura o usar bloqueo del espacio IP como una búsqueda binaria para encontrar conexiones actuales en tiempo logarítmico
- También existe la opción de ignorar option 121 mientras se usa la VPN, pero esa función puede ser necesaria para conectividad legítima de red y causar fallas de conexión
- Si esa mitigación es opcional, un atacante puede negar el acceso a la red para inducir a la VPN o al usuario a volver a habilitar option 121
- Los hotspots o las VM también pueden ayudar como mitigación
- Una LAN protegida con contraseña controlada por un dispositivo celular puede ayudar a impedir el acceso del atacante a la red local
- Una VM se comporta de forma similar mientras el adaptador de red no esté en modo bridged
Medidas necesarias para usuarios y operadores
- Para tráfico sensible se debe evitar usar redes no confiables y, si es inevitable, usar un proveedor de VPN con mitigaciones efectivas contra TunnelVision
- Incluso si ocurre un decloak de la VPN, cuando se accede a sitios HTTPS la mayoría de los datos del usuario no serán visibles para un atacante de la red local, pero sí pueden quedar expuestos el destino y el protocolo
- Si se usa una VPN corporativa en cafeterías, hoteles, aeropuertos u otros lugares similares, los administradores de red deben informar del riesgo y recomendar evitarlo en la medida de lo posible
- Si eso no es práctico, deben recomendar el uso de VPN con mitigaciones o correcciones aplicadas
- También es posible usar un hotspot confiable antes de conectarse a la VPN, o ejecutar la VPN dentro de una VM que obtenga su arrendamiento desde un servidor DHCP virtual
- Las empresas que operan su propia red o una VPN site-to-site deben revisar sus switches y habilitar funciones de protección de Layer 2 como DHCP snooping y protección ARP
- Estas protecciones ayudan a reducir servidores DHCP rogue, pero no eliminan el escenario de un administrador malicioso
- Aplicar HTTPS u otros protocolos cifrados a los recursos internos ayuda a evitar la filtración de datos de usuarios VPN que acceden desde redes no confiables
- Los proveedores de VPN pueden agregar al cliente una función de firewall que bloquee los paquetes salientes por la interfaz de red, pero eso impediría que el usuario interactúe con recursos de la red local
- Los clientes VPN full-tunnel para Linux deben considerar el aislamiento mediante network namespaces
- Los mantenedores de sistemas operativos deberían evaluar agregar o reforzar funciones relacionadas con network namespaces en sistemas distintos de Linux
- Se está desarrollando una biblioteca de infraestructura adversarial llamada ArcaneTrickster para investigación de seguridad LAN y demostraciones reales de ataque, y se planea publicarla más adelante
1 comentarios
Opiniones de Hacker News
Esto es una ligera variación del ataque PoisonTap de Samy Kamkar de 2016. Hace lo mismo con un adaptador de red USB/Thunderbolt: si lo conectas al dispositivo de la víctima y anuncias dos rutas más específicas, como 0.0.0.0/1 y 128.0.0.0/1, puedes capturar todo el tráfico con prioridad sobre otras interfaces del sistema, sin importar el orden de las interfaces: https://github.com/samyk/poisontap
Probablemente haya otros antecedentes, pero este es un caso muy conocido. El título del artículo dice que todos los clientes VPN están afectados, pero, como el propio texto reconoce, muchos clientes VPN configuran reglas de firewall que bloquean el tráfico que entra y sale por interfaces físicas.
Las VPN que prometen anonimato, o para las que ese anonimato es importante, suelen implementar esto. Seguramente muchas tienen configuraciones que no vienen activadas por defecto, pero habría sido más productivo documentar qué porcentaje de las principales soluciones VPN personales/comerciales/empresariales lo activan de forma predeterminada.
La explicación para el público general está bien, pero dado que muchos clientes evitan la mayor parte de la fuga de datos con esas reglas de firewall y que no se reconocen los antecedentes en esta área, el título parece un poco exagerado.
Casi escupo la bebida cuando vi la expresión “ataque de canal lateral”.
Edición: por lo que veo, NordVPN al menos en Mac no tiene esas reglas de firewall por defecto, así que parece vulnerable a este ataque.
No entiendo por qué este artículo es tan largo.
DHCP Option 121 permite que un servidor DHCP configure reglas de enrutamiento para rangos CIDR específicos, y al tener un prefijo más largo tienen mayor prioridad que la regla predeterminada 0.0.0.0/0.
La mitad de la información sobre VPN en internet está escrita por proveedores de VPN, y no es precisa o no es lo bastante técnica para explicar cómo funcionan realmente.
Pensaba agregar al inicio una frase con enlace del tipo “si ya conoces esto, salta a la sección del POC”, pero la actualizaré para que se vea mejor.
Es una suposición basada solo en el comentario anterior; no leí el artículo.
Me pareció haber leído sobre este ataque de otro autor antes, así que busqué y, después de abrirme paso entre el spam de empresas de VPN que aparece en los resultados, encontré trabajo previo [1].
Este artículo entra más a fondo en cómo explotar la falla y también incluye código útil para una prueba de concepto.
1: https://www.usenix.org/conference/usenixsecurity23/presentat...
Sin embargo, ninguna de las dos técnicas del paper de agosto de 2023 empujaba rutas mediante DHCP option 121. Si empujas rutas por DHCP, el impacto es mucho mayor desde la misma posición del atacante. Por ejemplo, desde una posición capaz de entregar concesiones de IP fuera de rangos RFC1918 o falsificar respuestas DNS.
El modelo de amenaza es que un atacante cualquiera de algún modo pueda convertirse en servidor DHCP dentro de mi LAN; es poco probable, pero no imposible.
En cambio, si estás usando el gateway que te dio el ISP, la historia cambia.
Ese es el principal punto de venta de la gran mayoría de los productos VPN.
En ese caso, la respuesta correcta es usar una conexión 4G/5G y no conectarse a redes sospechosas en las que no confías.
En una casa común, que el DHCP lo provea el router y por eso normalmente responda primero es algo secundario. Cualquier dispositivo malicioso dentro de la red puede usar esta vulnerabilidad.
En Linux también se puede mitigar poniendo la interfaz VPN en una VRF. Por ejemplo, systemd-networkd lo soporta de forma nativa.
Hay que tener en cuenta que al activar VRF, la entrada de ip rule para l3mdev queda en 1000, pero la regla de tráfico local queda en 0. Hay que mover la regla local a 1000 o más.
Este “ataque” no es más que un uso ingenioso de DHCP option 121. Es un ataque válido contra configuraciones de cliente gravemente rotas.
Cambiar la ruta predeterminada, o sobrescribirla con dos rutas /1 y agregar una ruta de host hacia el endpoint de la VPN, no es seguro. Para aislar correctamente el tráfico encapsulado de la red inferior hay que usar enrutamiento basado en políticas. Por ejemplo, espacios de nombres de red en Linux, vnet en FreeBSD o rdomains en OpenBSD.
Intentar armar esto a la fuerza con filtros de paquetes y “kill switches” en espacio de usuario está roto desde el diseño, y muestra lo poco que entienden —o les importa— a los proveedores comunes de hosting VPN algo que supuestamente es su competencia central. Es otra aparición del viejo problema de “enumerar cosas malas”.
No es nada nuevo.
Me preocupan más las personas que tienen IPv6 activado en el sistema pero usan un servicio VPN solo IPv4.
Eso sí puede salir realmente mal.
Hay muchísimas formas de eludir una VPN desde un dispositivo cliente. Por eso, cuando necesito una VPN, prefiero poner entre el cliente e internet un router que termine el túnel VPN y no tenga otra ruta.
Estos routers de viaje se pueden configurar muy fácilmente y llevar a cualquier parte; de hecho, eso es lo que hago.
Por ejemplo, tengo un router Wi‑Fi “work” que mantiene siempre una conexión VPN a la intranet del trabajo, una Wi‑Fi “Australia” que conecta la VPN a un servidor en Australia cada vez que quiero ver TV australiana y, por último, la Wi‑Fi normal de internet de casa.
Con unos cuantos routers Wi‑Fi viejos es muy fácil hacerlo, y parece que incluso los routers domésticos baratos de hoy ofrecen cierto soporte para VPN. Además de centralizar la configuración de la VPN y reducir la posibilidad de errores, tiene la gran ventaja de que cualquier dispositivo puede usar la VPN con solo conectarse a esa Wi‑Fi.
Uso esto con varios routers viejos, pero en realidad creo que también podría haber mercado para un producto en el que un solo router doméstico establezca VPN hacia varias ubicaciones del mundo y ofrezca distintas redes Wi‑Fi según la ubicación. La idea sería que una TV/Roku/iPad parezca conectarse fácilmente desde otra región.
Dicho eso, si hay un dispositivo no confiable en la LAN y usas DHCP, ese dispositivo puede espiar con esta técnica el tráfico no cifrado*. Aun así, no puede averiguar la IP real porque la puerta de enlace la oculta.
Donde este ataque resulta más realista es en situaciones como el Wi‑Fi de un café. En lugares así es poco probable que lleves tu propio router.
Aquí, “tráfico no cifrado” significa tráfico que no está encapsulado para enviarse al proveedor de la VPN. Hoy en día casi todo es HTTPS, así que el contenido de ese tráfico probablemente seguirá estando cifrado.
Para una persona técnica, esto debería haber sido bastante obvio, pero como introducción a redes y VPN está bien. He configurado algunas veces VMs Linux como gateways VPN, y una arquitectura que depende solo de la tabla de ruteo siempre me pareció frágil, sobre todo cuando corre en la misma máquina que usa esa conexión.
Además de los namespaces de red y los routers físicos como gateways VPN, una arquitectura basada en VMs también puede resolver este problema. En mi homelab, el firewall bloquea el tráfico inesperado que sale de la VM gateway de VPN. Los dispositivos de la VLAN de VPN no pueden conectarse directamente al exterior, y la VM gateway tiene una VLAN separada para la conexión externa.
Como solución personal, QubesOS permite configurar algo parecido con bastante poca fricción, aunque igualmente requiere más conocimientos técnicos que un sistema operativo común.
Es interesante la parte que dice que “Android fue el único no afectado porque no implementó soporte para DHCP option 121”.
Me pregunto si Google conocía este problema y tomó esa decisión intencionalmente, o si fue pura casualidad.
Si tuviera que especular, diría que el equipo de networking de Android es muy favorable a IPv6. No parece interesarle demasiado cubrir funciones de nicho faltantes de IPv4. Incluso para IPv6 tienen una visión específica de cómo debería usarse, lo que termina en decisiones como no dar soporte deliberadamente a funciones como DHCPv6 con estado.
Esta opción de DHCP no se usa mucho, así que con esa estrategia probablemente no habría sido soportada independientemente de las preocupaciones de seguridad.
Así que no es tan sorprendente.