Un nuevo ataque contra prácticamente todas las aplicaciones VPN neutraliza todo su propósito

Los investigadores han ideado un ataque contra casi todas las aplicaciones de redes privadas virtuales que las obliga a enviar y recibir parte o todo el tráfico fuera del túnel cifrado diseñado para protegerlo de espionaje o manipulación.

TunnelVision, como llamaron los investigadores a su ataque, niega en gran medida el propósito y el punto de venta de las VPN, que es encapsular el tráfico de Internet entrante y saliente en un túnel cifrado y ocultar la dirección IP del usuario. Los investigadores creen que afecta a todas las aplicaciones VPN cuando están conectadas a una red hostil y que no hay forma de prevenir tales ataques excepto cuando la VPN del usuario se ejecuta en Linux o Android. También dijeron que su técnica de ataque puede haber sido posible desde 2002 y es posible que ya haya sido descubierta y utilizada en la naturaleza desde entonces.

Leer, eliminar o modificar el tráfico VPN

El efecto de TunnelVision es que “el tráfico de la víctima ahora queda oculto y se dirige directamente a través del atacante”, un demostración en vídeo explicado. “El atacante puede leer, descartar o modificar el tráfico filtrado y la víctima mantiene su conexión tanto a la VPN como a Internet”.

El ataque funciona manipulando el Servidor DHCP que asigna direcciones IP a dispositivos que intentan conectarse a la red local. Un escenario conocido como opción 121 permite que el servidor DHCP anule las reglas de enrutamiento predeterminadas que envían el tráfico VPN a través de una dirección IP local que inicia el túnel cifrado. Al utilizar la opción 121 para enrutar el tráfico VPN a través del servidor DHCP, el ataque desvía los datos al propio servidor DHCP. Los investigadores de Leviathan Security explicaron:

Nuestra técnica consiste en ejecutar un servidor DHCP en la misma red que un usuario VPN objetivo y también configurar nuestra configuración DHCP para que se utilice como puerta de enlace. Cuando el tráfico llega a nuestra puerta de enlace, utilizamos reglas de reenvío de tráfico en el servidor DHCP para pasar el tráfico a una puerta de enlace legítima mientras la espiamos.

Usamos la opción 121 de DHCP para establecer una ruta en la tabla de enrutamiento del usuario de VPN. La ruta que configuramos es arbitraria y también podemos configurar múltiples rutas si es necesario. Al impulsar rutas que son más específicas que un rango CIDR /0 que utilizan la mayoría de las VPN, podemos crear reglas de enrutamiento que tengan una prioridad más alta que las rutas para la interfaz virtual que crea la VPN. Podemos configurar múltiples rutas /1 para recrear la regla de todo el tráfico 0.0.0.0/0 establecida por la mayoría de las VPN.

Enviar una ruta también significa que el tráfico de la red se enviará a través de la misma interfaz que el servidor DHCP en lugar de la interfaz de red virtual. Esta es una funcionalidad prevista que no está claramente establecida en el RFC. Por lo tanto, para las rutas que enviamos, la interfaz virtual de la VPN nunca las cifra, sino que las transmite la interfaz de red que se comunica con el servidor DHCP. Como atacante, podemos seleccionar qué direcciones IP pasan por el túnel y qué direcciones pasan por la interfaz de red hablando con nuestro servidor DHCP.

Ahora tenemos tráfico transmitiéndose fuera del túnel cifrado de la VPN. Esta técnica también se puede utilizar contra una conexión VPN ya establecida una vez que el host del usuario de VPN necesite renovar un contrato de arrendamiento de nuestro servidor DHCP. Podemos crear ese escenario artificialmente estableciendo un tiempo de concesión corto en la concesión de DHCP, para que el usuario actualice su tabla de enrutamiento con más frecuencia. Además, el canal de control VPN sigue intacto porque ya utiliza la interfaz física para su comunicación. En nuestras pruebas, la VPN siempre continuó informándose como conectada y el interruptor de apagado nunca estuvo activado para interrumpir nuestra conexión VPN.

El ataque puede ser llevado a cabo de manera más efectiva por una persona que tenga control administrativo sobre la red a la que se conecta el objetivo. En ese escenario, el atacante configura el servidor DHCP para usar la opción 121. También es posible que las personas que pueden conectarse a la red como usuarios sin privilegios realicen el ataque configurando su propio servidor DHCP no autorizado.

El ataque permite que parte o todo el tráfico se enrute a través del túnel no cifrado. En cualquier caso, la aplicación VPN informará que todos los datos se envían a través de la conexión protegida. La VPN no cifrará el tráfico que se desvíe de este túnel y la dirección IP de Internet visible para el usuario remoto pertenecerá a la red a la que está conectado el usuario de la VPN, en lugar de una designada por la aplicación VPN.

Curiosamente, Android es el único sistema operativo que inmuniza completamente a las aplicaciones VPN contra el ataque porque no implementa la opción 121. Para todos los demás sistemas operativos, no existen soluciones completas. Cuando las aplicaciones se ejecutan en Linux, hay una configuración que minimiza los efectos, pero incluso entonces TunnelVision se puede utilizar para explotar un canal lateral que se puede utilizar para anonimizar el tráfico de destino y realizar ataques dirigidos de denegación de servicio. Los firewalls de red también se pueden configurar para denegar el tráfico entrante y saliente hacia y desde la interfaz física. Esta solución es problemática por dos razones: (1) un usuario de VPN que se conecta a una red que no es de confianza no tiene capacidad para controlar el firewall y (2) abre el mismo canal lateral presente con la mitigación de Linux.

Las soluciones más efectivas son ejecutar la VPN dentro de una máquina virtual cuyo adaptador de red no esté en modo puente o conectar la VPN a Internet a través de la red Wi-Fi de un dispositivo celular. La investigación, de los investigadores de Leviathan Security Lizzie Moratti y Dani Cronce, está disponible aquí.