TunnelCrack fronte a TunnelVision: que rompe realmente cada un

Dous nomes de investigación úsanse indistintamente para calquera tráfico VPN que sae do túnel, pero os mecanismos que hai detrás non son os mesmos. TunnelCrack describe dúas familias de excepcións de enrutamento; TunnelVision describe unha ruta proporcionada por DHCP no equipo final. Ningún rompe o cifrado, e ningún lle di que fai hoxe unha compilación concreta do cliente. Cinco comprobacións separan os mecanismos do titular.

Primeiro paso: nomee o mecanismo que revisa

A divulgación de TunnelCrack de agosto de 2023 describe dúas familias de ataques. No caso da rede local, o tráfico que o cliente considera da rede local toma unha excepción de acceso local e sae do túnel. No caso do enderezo do servidor, a ruta que o cliente necesita para chegar ao propio servidor VPN está fóra do túnel, e un adversario que controla ese enderezo pode explotar a excepción.

TunnelVision é un informe aparte sobre rutas estáticas sen clase entregadas por DHCP. Un servidor DHCP malicioso pode dar ao equipo final rutas que cambian por que camiño vai o tráfico, incluído o camiño cara ao servidor VPN. O informe recoñece traballos anteriores sobre efectos de enrutamento relacionados, o que recorda que o mecanismo subxacente é máis antigo que o nome.

Manteña os nomes atados aos seus mecanismos. Aplicar unha corrección para un porque o outro está nas noticias é a forma en que unha revisión produce movemento sen cobertura.

Segundo paso: mire a excepción de acceso local

A maioría dos clientes eximen o tráfico da rede local para que impresoras, transmisión e compartición de ficheiros sigan funcionando mentres o túnel está activo. Esa excepción é unha decisión de política cun custo de seguridade: un adversario na mesma rede pode presentarse como anfitrión local, e o tráfico que chega a el nunca entrou no túnel.

Pregunte se o perfil despregado necesita a excepción. Unha plantilla remota que nunca usa o descubrimento local a miúdo pode desactivala, e os servizos locais restantes poden acadarse por un camiño documentado. Onde a excepción é necesaria, diga que destinos cobre en lugar de describila como tráfico local.

A comprobación é unha pregunta de configuración, non unha captura de paquetes. Lea o axuste do perfil e a documentación do cliente para a compilación que despregue, porque o valor por defecto difire entre produtos e entre versións do mesmo produto. Escriba a resposta xunto ao perfil, para que o seguinte revisor non teña que deducila do comportamento. Unha excepción que ninguén documentou é unha excepción que ninguén revisa.

Terceiro paso: mire como se aprende o enderezo do servidor

O cliente ten que chegar ao servidor VPN antes de que exista ningún túnel, así que ese destino se enruta fóra do túnel por deseño. Se o enderezo se aprende dun nome, o paso de resolución forma parte do camiño de confianza, e un adversario que pode responder a esa consulta pode dirixir o cliente a un anfitrión que controla.

Fixar o enderezo, usar un certificado verificado co nome correcto e negarse a caer nun servidor non verificado reducen todos a exposición. Ningún deles elimina a necesidade de chegar ao servidor fóra do túnel; cambian quen pode responder por ese enderezo.

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

A consulta de ruta mostra a interface que o cliente usaría para o enderezo do servidor, que é a excepción en forma concreta. Se esa consulta devolve a interface do túnel, o cliente non pode nin establecer o túnel, así que se espera unha ruta externa e a pregunta é só como se escolle o seu destino.

Cuarto paso: mire as rutas que proporciona DHCP

As rutas estáticas sen clase permiten que un servidor DHCP reparta entradas da táboa de enrutamento, e o equipo final normalmente acéptaas sen preguntar. Nunha rede onde un adversario pode responder DHCP máis rápido que o servidor lexítimo, esas entradas poden redirixir tráfico que o usuario cre dentro do túnel.

Compare as rutas do equipo final coas rutas que espera. Unha ruta por defecto ou un prefixo amplo que apunta á pasarela local mentres o túnel está activo é a sinatura que merece investigación, e é visible sen 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"

O último axuste é o control do lado do equipo final que moitos clientes e plataformas expoñen dalgunha forma: ignorar as rutas que proporciona a rede. Desactivar a aceptación automática de rutas é un compromiso, porque tamén desactiva o enrutamento dividido lexítimo dun servidor DHCP corporativo, así que decídao por clase de rede e non globalmente.

Quinto paso: separe o aviso da compilación actual

Un ataque publicado describe comportamento observado en versións concretas do cliente nun momento concreto. Non establece que o portátil que ten diante estea afectado, nin establece que estea corrixido. Ambas as afirmacións necesitan o número de compilación real e o aviso actual do fabricante.

Anote a versión do cliente, a plataforma, os axustes do perfil que gobernan as excepcións anteriores e a data en que o comprobou. Ese rexistro envellece con honestidade, mentres que unha nota que diga que a VPN se parcheou por TunnelCrack non o fai. Vólvao ler cada vez que o cliente se actualice, porque un valor por defecto do perfil pode cambiar baixo unha versión que vostede non tocou.

Cando valide de verdade, use un plan aprobado contra o seu propio equipo final e un destino inocuo. Reproducir o ataque contra outros usuarios nunha rede compartida non é unha proba, e desactivar a verificación de pares ou o cifrado da aplicación para facilitar unha observación elimina a protección que intentaba medir.

Por último, manteña a protección de nivel de aplicación na imaxe. Unha excepción de enrutamento pode expor tráfico que o túnel tería levado, e o TLS da aplicación segue protexendo ese tráfico de extremo a extremo. As dúas capas fallan de forma independente, e por iso unha canle de control conectada non é proba de que cada fluxo tomase o camiño previsto.