Cómo secuestrar la sesión del túnel VPN en Linux, FreeBSD, OpenBSD, MacOS, iOS y Android

Un grupo de especialistas en análisis de vulnerabilidades de la Universidad de Nuevo México, integrado por William J. Tolley, Beau Kujath y Jedidiah R. Crandall, acaba de reportar una vulnerabilidad presente en la mayoría de las distribuciones de Linux y otros sistemas operativos que, de ser explotada, permitiría a los actores de amenazas descubrir si otro usuario está conectado a una VPN, la dirección virtual que le asigna el servidor y si existen conexiones activas a sitios web en específico. Este ataque permitiría la inyección de datos en el flujo TCP y el secuestro de conexiones.

La mayoría de las distribuciones vulnerables a esta falla usan la versión de systemd corregida después del 28 de noviembre de 2018, que inhabilitó el filtrado de ruta inversa; no obstante, el ataque también funciona contra IPv6. Como protección, agregar una regla de enrutamiento previo para descartar paquetes destinados a la dirección IP virtual del cliente es efectivo en algunos sistemas, pero esto solo fue probado en las máquinas de los investigadores.

La vulnerabilidad funciona contra OpenVPN, WireGuard e IKEv2-IPSec y, aunque no ha sido probada contra tor, se cree que no es vulnerable debido a que incluye autenticación y cifrado en el espacio de usuario. Los hackers pueden recurrir al tamaño y cantidad de paquetes enviados para inferir qué tipo de paquetes se envían a través del túnel VPN, sin importar la tecnología VPN.

En su informe, los expertos en análisis de vulnerabilidades dividen el ataque en tres etapas:

  • Determinar la dirección IP virtual del cliente VPN
  • Usar la dirección IP virtual para hacer inferencias sobre las conexiones activas
  • Usar las respuestas cifradas a paquetes no solicitados para determinar la secuencia y los números de reconocimiento de la conexión activa para secuestrar la sesión TCP

Por otra parte, hay 4 componentes para la reproducción del ataque:

  • El dispositivo de la víctima (conectado a AP, 192.168.12.x, 10.8.0.8)
  • Punto de acceso (controlado por el atacante, 192.168.12.1)
  • Servidor VPN (no controlado por el atacante, 10.8.0.1)
  • Un servidor web (no controlado por el atacante, IP pública en un escenario real)

El dispositivo objetivo debe conectarse al punto de acceso (durante las pruebas se empleó una computadora portátil con create_ap). Posteriormente, el dispositivo debe establecer la conexión con su proveedor de VPN.

Lista de sistemas operativos afectados

La vulnerabilidad fue analizada con éxito en los siguientes sistemas operativos:

  • Ubuntu 19.10 (systemd)
  • Fedora (systemd)
  • Debian 10.2 (systemd)
  • Arco 2019.05 (systemd)
  • Manjaro 18.1.1 (systemd)
  • Devuan (sysV init)
  • MX Linux 19 (Mepis + antiX)
  • Linux vacío (runit)
  • Slackware 14.2 (rc.d)
  • Deepin (rc.d)
  • FreeBSD (rc.d)
  • OpenBSD (rc.d)

Esta lista sólo está compuesta por los sistemas operativos analizados durante la investigación, por lo que los expertos en análisis de vulnerabilidades mencionan que es necesario probar otras distribuciones.

Potenciales soluciones

Activar el filtrado de ruta inversa

Posible problema al implementar esta solución: el enrutamiento asincrónico no es confiable en dispositivos móviles, etc. No está claro que esto sea realmente una solución, ya que parece funcionar en otros sistemas operativos con diferentes pilas de redes. Además, incluso con el filtrado de ruta inversa en modo estricto, se pueden completar las dos primeras partes del ataque, lo que permite al atacante hacer inferencias sobre conexiones activas, por lo que aún es posible concretar el ataque.

Filtrado de direcciones IP falsas

Problema potencial al implementar esta solución: las direcciones de red locales utilizadas para VPN y redes locales, y algunas naciones, como Irán, utilizan el espacio de IP privado reservado como parte del espacio público.

Tamaño de paquete cifrado y timing

Dado que el tamaño y la cantidad de paquetes permiten al atacante eludir el cifrado provisto por el servicio de VPN, quizás se podría agregar algún tipo de relleno a los paquetes cifrados para que tengan el mismo tamaño. Además, dado que el ACK de desafío por límite de proceso nos permite determinar si los paquetes cifrados son ACK de desafío, permitir que el host responda con paquetes de tamaño equivalente después de agotar este límite podría evitar que el atacante haga esta inferencia, aseguran los expertos en análisis de vulnerabilidades del Instituto Internacional de Seguridad Cibernética (IICS).

Ya está listo para su publicación un informe completo sobre esta vulnerabilidad, sus alcances y las potenciales consecuencias de su explotación, no obstante, será revelado hasta que las distribuciones de Linux comprometidas lancen una solución apropiada. Otros servicios afectados que ya han sido notificados incluyen a Systemd, Google, Apple, OpenVPN y WireGuard, además de otras distribuciones de los sistemas operativos afectados.