TunnelCrack frente a TunnelVision: qué rompe realmente cada uno

Dos nombres de investigación se usan indistintamente para cualquier tráfico VPN que sale del túnel, pero los mecanismos que hay detrás no son los mismos. TunnelCrack describe dos familias de excepciones de enrutamiento; TunnelVision describe una ruta proporcionada por DHCP en el equipo final. Ninguno rompe el cifrado, y ninguno le dice qué hace hoy una compilación concreta del cliente. Cinco comprobaciones separan los mecanismos del titular.

Primer paso: nombre el mecanismo que revisa

La divulgación de TunnelCrack de agosto de 2023 describe dos familias de ataques. En el caso de la red local, el tráfico que el cliente considera de la red local toma una excepción de acceso local y sale del túnel. En el caso de la dirección del servidor, la ruta que el cliente necesita para llegar al propio servidor VPN está fuera del túnel, y un adversario que controla esa dirección puede explotar la excepción.

TunnelVision es un informe aparte sobre rutas estáticas sin clase entregadas por DHCP. Un servidor DHCP malicioso puede dar al equipo final rutas que cambian por qué camino va el tráfico, incluido el camino hacia el servidor VPN. El informe reconoce trabajos anteriores sobre efectos de enrutamiento relacionados, lo que recuerda que el mecanismo subyacente es más antiguo que el nombre.

Mantenga los nombres atados a sus mecanismos. Aplicar una corrección para uno porque el otro está en las noticias es la forma en que una revisión produce movimiento sin cobertura.

Segundo paso: mire la excepción de acceso local

La mayoría de los clientes eximen el tráfico de la red local para que impresoras, transmisión y compartición de archivos sigan funcionando mientras el túnel está activo. Esa excepción es una decisión de política con un coste de seguridad: un adversario en la misma red puede presentarse como anfitrión local, y el tráfico que llega a él nunca entró en el túnel.

Pregunte si el perfil desplegado necesita la excepción. Una plantilla remota que nunca usa el descubrimiento local a menudo puede desactivarla, y los servicios locales restantes pueden alcanzarse por una ruta documentada. Donde la excepción es necesaria, diga qué destinos cubre en lugar de describirla como tráfico local.

La comprobación es una pregunta de configuración, no una captura de paquetes. Lea el ajuste del perfil y la documentación del cliente para la compilación que despliega, porque el valor por defecto difiere entre productos y entre versiones del mismo producto. Escriba la respuesta junto al perfil, para que el siguiente revisor no tenga que deducirla del comportamiento. Una excepción que nadie documentó es una excepción que nadie revisa.

Tercer paso: mire cómo se aprende la dirección del servidor

El cliente tiene que llegar al servidor VPN antes de que exista ningún túnel, así que ese destino se enruta fuera del túnel por diseño. Si la dirección se aprende de un nombre, el paso de resolución forma parte del camino de confianza, y un adversario que puede responder a esa consulta puede dirigir al cliente a un anfitrión que controla.

Fijar la dirección, usar un certificado verificado con el nombre correcto y negarse a caer a un servidor no verificado reducen todos la exposición. Ninguno de ellos elimina la necesidad de llegar al servidor fuera del túnel; cambian quién puede responder de esa dirección.

resolvectl query vpn.lab.example
ip route get 198.51.100.24
ip rule show

La consulta de ruta muestra la interfaz que el cliente usaría para la dirección del servidor, que es la excepción en forma concreta. Si esa consulta devuelve la interfaz del túnel, el cliente no puede ni establecer el túnel, así que se espera una ruta externa y la pregunta es solo cómo se elige su destino.

Cuarto paso: mire las rutas que proporciona DHCP

Las rutas estáticas sin clase permiten que un servidor DHCP reparta entradas de la tabla de enrutamiento, y el equipo final normalmente las acepta sin preguntar. En una red donde un adversario puede responder DHCP más rápido que el servidor legítimo, esas entradas pueden redirigir tráfico que el usuario cree dentro del túnel.

Compare las rutas del equipo final con las rutas que espera. Una ruta por defecto o un prefijo amplio que apunta a la puerta de enlace local mientras el túnel está activo es la firma que merece investigación, y es visible sin ningún tráfico de ataque.

ip route show table all
ip route get 203.0.113.55
nmcli -g ipv4.ignore-auto-routes con show "Wired connection 1"

El último ajuste es el control del lado del equipo final que muchos clientes y plataformas exponen de alguna forma: ignorar las rutas que proporciona la red. Desactivar la aceptación automática de rutas es un compromiso, porque también desactiva el enrutamiento dividido legítimo de un servidor DHCP corporativo, así que decídalo por clase de red y no de forma global.

Quinto paso: separe el aviso de la compilación actual

Un ataque publicado describe comportamiento observado en versiones concretas del cliente en un momento concreto. No establece que el portátil que tiene delante esté afectado, ni establece que esté corregido. Ambas afirmaciones necesitan el número de compilación real y el aviso actual del fabricante.

Anote la versión del cliente, la plataforma, los ajustes del perfil que gobiernan las excepciones anteriores y la fecha en que lo comprobó. Ese registro envejece con honestidad, mientras que una nota que diga que la VPN se parcheó por TunnelCrack no lo hace. Vuelva a leerlo cada vez que el cliente se actualice, porque un valor por defecto del perfil puede cambiar bajo una versión que usted no tocó.

Cuando valide de verdad, use un plan aprobado contra su propio equipo final y un destino inocuo. Reproducir el ataque contra otros usuarios en una red compartida no es una prueba, y desactivar la verificación de iguales o el cifrado de la aplicación para facilitar una observación elimina la protección que intentaba medir.

Por último, mantenga la protección de nivel de aplicación en la imagen. Una excepción de enrutamiento puede exponer tráfico que el túnel habría llevado, y el TLS de la aplicación sigue protegiendo ese tráfico de extremo a extremo. Las dos capas fallan de forma independiente, y por eso un canal de control conectado no es prueba de que cada flujo tomara el camino previsto.