Se presenta al público un método de ataque TunnelVision que permite, al tener acceso a una red local o control sobre una red inalámbrica, redirigir el tráfico de la víctima a su propio host, eludiendo la VPN (en lugar de enviarse a través de la VPN, el tráfico se enviará en texto claro, sin túnel hacia el sistema del atacante). Este problema afecta a cualquier cliente VPN que no utilice espacios de nombres de red aislados al dirigir el tráfico al túnel o que no aplique reglas de filtrado de paquetes que prohíban la ruta del tráfico VPN a través de interfaces de red físicas existentes.
La esencia del ataque es que el atacante puede lanzar su propio servidor DHCP y usarlo para transmitir información al cliente para cambiar la ruta. En particular, el atacante puede aprovechar la opción 121 proporcionada en el protocolo DHCP (RFC-3442, adoptada en 2002), diseñada para transmitir información sobre rutas estáticas, para realizar cambios en la tabla de rutas en la máquina de la víctima y redirigir el tráfico. VPNLa redirección se lleva a cabo mediante el establecimiento de una serie de rutas para subredes con prefijo /1, que tienen una prioridad más alta que la ruta predeterminada con prefijo /0 (0.0.0.0/0); por lo tanto, el tráfico en lugar de ser dirigido a la interfaz de red virtual asignada para la VPN se redirigirá a través de la interfaz de red física al host del atacante en la red local.
El ataque puede llevarse a cabo en cualquier sistema operativo que soporte la opción 121 de DHCP, incluyendo Linux, Windows, iOS y macOS, independientemente del protocolo VPN utilizado (Wireguard, OpenVPN, IPsec) y el conjunto de cifrados. La plataforma Android no es susceptible al ataque, ya que no procesa la opción 121 en DHCP. Sin embargo, el ataque permite acceder al tráfico, pero no proporciona la capacidad de interceptar conexiones y determinar el contenido transmitido utilizando protocolos de aplicación seguros, como TLS y SSH; por ejemplo, el atacante no puede determinar el contenido de las solicitudes HTTPS, pero puede entender a qué servidores se están enviando.
Para protegerse de un ataque, se puede prohibir a nivel de filtrado de paquetes el envío de paquetes dirigidos a la interfaz VPN a través de otras interfaces de red; bloquear paquetes DHCP con la opción 121; utilizar VPN dentro de una máquina virtual (o contenedor) aislada de la red externa, o aplicar modos de configuración de túneles específicos que utilizan espacios de nombres en Linux (network namespace). Se ha publicado un conjunto de scripts para experimentar con la realización de ataques.
Se puede notar que la idea de modificar la ruta localmente no es nueva y anteriormente se utilizaba comúnmente en ataques dirigidos a la suplantación de servidores DNS. En un ataque similar, TunnelCrack, donde el redireccionamiento del tráfico se realizaba a través del reemplazo de la puerta de enlace predeterminada, el problema afectó a todos los clientes VPN probados para iOS, al 87.5% de los clientes VPN para macOS, al 66.7% para Windows, al 35.7% para Linux y al 21.4% para Android. En el contexto de VPN y DHCP, este método también se mencionó anteriormente, por ejemplo, en uno de los informes de la conferencia USENIX 2023 del año pasado (el estudio mostró que el 64.6% de los 195 clientes VPN probados eran vulnerables al ataque).
Para la sustitución de rutas, anteriormente se propuso utilizar una memoria USB diseñada especialmente que simula el funcionamiento de un adaptador de red, el cual al ser conectado a la computadora se declara a sí mismo como la puerta de enlace a través de DHCP. Además, con control sobre la puerta de enlace (por ejemplo, al conectar a la víctima a una red inalámbrica controlada por el atacante), se desarrolló una técnica de inyección de paquetes en el túnel, percibidos en el contexto de la interfaz de red VPN.
Flujos de datos al usar VPN:
Flujos de datos después de realizar el ataque:
Fuente: opennet.ru
