Los atacantes podrían exponer VPN basadas en enrutamiento

• Una VPN es una tecnología que crea un túnel para el tráfico de red entre el dispositivo del usuario y un servidor en otra red. La red virtual creada de esta manera funciona igual que una red física, sin estar limitada por la ubicación geográfica.
• El cliente VPN crea una interfaz de red virtual, cifra/descifra el tráfico y luego lo envía a la interfaz de red física.
• Las VPN están diseñadas para ser lo más fáciles de usar posible para el usuario y no suelen requerir mucho más que iniciar sesión y hacer clic en un botón.
• Como las VPN transmiten tráfico de red de bajo nivel a través de Internet, en realidad aumentan la superficie de ataque del host. Una VPN encapsula el tráfico de la LAN en Internet, creando una red de área local (LAN) sobre Internet.
• Las VPN mitigan la superficie de ataque ampliada de la LAN mediante controles compensatorios como el cifrado de paquetes. Sin embargo, no protegen a los usuarios contra ataques de red local en la LAN física.

DHCP y la opción 121 de DHCP

• DHCP es un protocolo que asigna direcciones IP dinámicamente y ofrece opciones para ajustar remotamente la configuración de los dispositivos.
• La opción 121 de DHCP permite a los administradores agregar rutas estáticas a la tabla de enrutamiento del cliente.
• Una característica interesante de la opción 121 es que el servidor DHCP no puede especificar en qué dispositivo de interfaz de red se instalará la ruta. En su lugar, el cliente DHCP selecciona implícitamente la interfaz de red que se comunica con el servidor DHCP al instalar las reglas de enrutamiento para esa opción.

Requisitos y proceso del ataque Decloaking

• El host objetivo debe aceptar un arrendamiento DHCP de un servidor DHCP controlado por el atacante.
• El cliente DHCP del host objetivo debe implementar la opción 121 de DHCP.
• El atacante ejecuta un servidor DHCP en la misma red que el usuario de la VPN y se configura a sí mismo como gateway en la configuración DHCP.
• Usa la opción 121 de DHCP para establecer rutas en la tabla de enrutamiento del usuario de la VPN.
• Con esas rutas, el tráfico de red se envía por la interfaz de red que se comunica con el servidor DHCP, y no por la interfaz virtual de la VPN.
• El tráfico se transmite fuera del túnel cifrado de la VPN, pero el canal de control de la VPN permanece activo, por lo que la VPN sigue apareciendo como conectada.

Sistemas afectados

• La mayoría de los sistemas operativos que implementan clientes DHCP según la especificación RFC y soportan rutas mediante la opción 121 —como Windows, Linux, iOS y macOS— se ven afectados. (Android no se ve afectado porque no soporta la opción 121 de DHCP).
• Son vulnerables las VPN que dependen únicamente de reglas de enrutamiento para proteger el tráfico del host.
• Si alojas tu propio servidor VPN, podrías ser vulnerable si no refuerzas la configuración del cliente VPN.
• Se ven afectadas independientemente del protocolo VPN subyacente (WireGuard, OpenVPN, IPsec, etc.), porque el ataque reconfigura la pila de red del sistema operativo de la que depende la VPN.

Mitigaciones y limitaciones

• El uso de network namespaces en Linux puede resolver completamente este problema, pero por lo general no está bien implementado.
• Se ha observado que algunos proveedores de VPN bloquean el tráfico entrante/saliente en la interfaz física mediante reglas de firewall, pero esto solo es una mitigación parcial.
• Ignorar la opción 121 de DHCP también es una mitigación posible, aunque podría romper la conectividad de red.
• Usar un hot spot o una VM puede ayudar, ya que dificulta que un atacante obtenga acceso a la red local.
• Si se requiere confidencialidad absoluta del tráfico, la mejor defensa es evitar el uso de redes no confiables.

Opinión de GN⁺

• Como las VPN no están diseñadas para mitigar ataques LAN en la red física, las afirmaciones de marketing de algunos proveedores sobre que una VPN protege a los clientes en redes no confiables pueden ser riesgosas. Los proveedores de VPN deberían documentar públicamente las mitigaciones o correcciones para TunnelVision y comunicarlas a los usuarios.
• Las VPN corporativas se usan con frecuencia en cafés, hoteles y aeropuertos, por lo que los administradores de red deberían informar a los empleados sobre los riesgos de trabajar en esos lugares y recomendar evitarlos siempre que sea posible. Además, deberían implementar protocolos cifrados como HTTPS para los recursos internos, a fin de evitar filtraciones de datos por parte de usuarios de VPN que se conectan desde redes no confiables.
• Como la mayor parte del tráfico de Internet ya está protegida con HTTPS, incluso si la VPN queda anulada, la mayoría de los datos de los usuarios no quedarán expuestos a atacantes en la red local. Aun así, el tráfico sensible requiere advertencias adicionales.
• Los responsables del mantenimiento de sistemas operativos, excepto Linux, deberían revisar si es posible agregar o mejorar funciones relacionadas con network namespaces.
• Aunque esto no viola las propiedades de seguridad de la tecnología VPN en sí, sí contradice las garantías ofrecidas por los proveedores, por lo que puede considerarse una vulnerabilidad. Los investigadores estiman que esta técnica podría haber sido posible desde 2002 y decidieron publicar sus hallazgos para informar ampliamente a las partes afectadas.

[GN⁺]

Opinión de Hacker News

Resumen:

• Este ataque es similar al ataque "Poison Tap" de Samy Kamkar de 2016. Usando un adaptador de red USB/Thunderbolt, se pueden anunciar dos rutas más específicas e interceptar todo el tráfico con prioridad sobre las demás interfaces del sistema.
• El titular afirma que afecta a todos los clientes VPN, pero muchos clientes configuran reglas de firewall para bloquear el tráfico con interfaces físicas. Habría sido útil documentar qué proporción de las principales soluciones VPN personales/comerciales y empresariales tienen esta función activada por defecto.
• Con la opción 121 de DHCP, el servidor DHCP puede establecer reglas de enrutamiento para rangos CIDR específicos. Estas tienen mayor prioridad que la regla predeterminada 0.0.0.0/0 debido a su prefijo más largo.
• Este "ataque" hace un uso ingenioso de la opción 121 de DHCP. Para aislarlo correctamente, se debe usar un enrutamiento basado en políticas adecuado (por ejemplo, Linux network namespaces, FreeBSD vnet, OpenBSD rdomains).
• En Linux, esto se puede mitigar colocando la interfaz VPN en un VRF. systemd-networkd lo soporta de forma nativa.
• El modelo de amenaza en el que un atacante puede convertirse en el servidor DHCP de la LAN es poco probable, pero no imposible.
• Una arquitectura basada en máquinas virtuales también puede resolver este problema. QubesOS permite configurar algo muy parecido con mucha facilidad.
• Una alternativa interesante a los espacios de nombres de red es omitir por completo el networking del kernel y usar una pila de red en espacio de usuario.
• Me preocupa más usar un servicio VPN solo para IPv4 mientras IPv6 sigue habilitado en el sistema. Eso puede causar problemas graves.