técnica de ataque (CVE-2019-14899) que permite reemplazar, modificar o inyectar paquetes en conexiones TCP que se transmiten a través de túneles VPN. El problema afecta a Linux, FreeBSD, OpenBSD, Android, macOS, iOS y otros sistemas similares a Unix. Linux soporta el mecanismo rp_filter (filtrado de ruta inversa) para IPv4, cuya activación en modo 'Estricto' neutraliza este problema.
El método permite la inyección de paquetes a nivel de conexiones TCP que pasan a través del túnel cifrado, pero no permite interferir en conexiones que aplican capas adicionales de cifrado (por ejemplo, TLS, HTTPS, SSH). Los algoritmos de cifrado utilizados en VPN no son relevantes, ya que los paquetes falsificados provienen de la interfaz externa, pero son tratados por el núcleo como paquetes de la interfaz VPN. La víctima más probable de este ataque es la intervención en conexiones HTTP no cifradas, pero y el uso del ataque para manipular las respuestas DNS.
La suplantación de paquetes ha sido demostrada para túneles creados con OpenVPN, WireGuard e IKEv2/IPSec. Tor no está afectado, ya que utiliza SOCKS para enrutar el tráfico y se vincula a la interfaz loopback. Para IPv4, el ataque es posible si se cambia rp_filter a modo 'Suelto' (sysctl net.ipv4.conf.all.rp_filter = 2). Originalmente, la mayoría de los sistemas utilizaban el modo 'Estricto', pero desde , lanzado en diciembre del año pasado, el modo por defecto fue cambiado a 'Suelto', y este cambio se reflejó en la configuración predeterminada de muchas distribuciones de Linux.
El mecanismo rp_filter se utiliza para verificar adicionalmente las rutas de los paquetes con el fin de prevenir la suplantación de dirección de origen. Al establecerlo en 0, no se realiza la verificación de la dirección de origen y cualquier paquete puede ser redirigido sin restricciones entre las interfaces de red. El modo 1 'Estricto' activa la verificación de cada paquete entrante desde el exterior de acuerdo con la tabla de enrutamiento, y si la interfaz de red a través de la cual se recibió el paquete no está asociada con la ruta óptima para entregar la respuesta, entonces el paquete es descartado. El modo 2 'Suelto' flexibiliza la verificación para permitir el funcionamiento con balanceadores de carga o enrutamiento asimétrico, en el cual
la ruta de respuesta puede no pasar por la interfaz de red a través de la cual llegó el paquete entrante.
En el modo «Loose», el paquete entrante se verifica en relación con la tabla de enrutamiento, pero se considera válido si la dirección de origen es alcanzable a través de cualquier interfaz de red disponible. El ataque propuesto se basa en que un atacante puede enviar un paquete con una dirección de origen falsificada, correspondiente a la interfaz VPN, y a pesar de que este paquete llegue al sistema a través de una interfaz de red externa, y no a través de la VPN, en el modo rp_filter «Loose», dicho paquete no será descartado.
Para llevar a cabo el ataque, el atacante debe controlar la puerta de enlace a través de la cual el usuario accede a la red (por ejemplo, a través de una organización MITM, cuando la víctima se conecta a un punto de acceso inalámbrico controlado por el atacante o a través de ). Controlando la puerta de enlace a la que está conectado el usuario en la red, el atacante puede enviar paquetes falsos que serán percibidos en el contexto de la interfaz de red VPN, pero las respuestas se enviarán a través del túnel.
Al generar un flujo de paquetes falsos en los que se inserta la dirección IP de la interfaz VPN, se intentan influir en la conexión establecida por el cliente, pero la influencia de estos paquetes solo se puede observar a través de un análisis pasivo del flujo de tráfico cifrado relacionado con la operación del túnel. Para llevar a cabo el ataque, es necesario conocer la dirección IP de la interfaz de red del túnel asignada por el servidor VPN, así como determinar que en ese momento hay una conexión activa a un determinado host a través del túnel.
Para determinar la IP de la interfaz de red virtual VPN, se envían paquetes SYN-ACK al sistema de la víctima, revisando secuencialmente todo el rango de direcciones virtuales (primero se revisan las direcciones utilizadas por defecto en la VPN, como en OpenVPN, donde se usa la subred 10.8.0.0/24). La existencia de la dirección se puede inferir en base a la recepción de una respuesta con la bandera RST.
De manera similar, se determina la conexión a un sitio específico y el número de puerto en el lado del cliente: al iterar sobre los números de puerto, se envía un paquete SYN como dirección de origen, en el que se sustituye la IP del sitio y la dirección de destino es una IP virtual de VPN. El puerto del servidor se puede prever (80 para HTTP), y el número de puerto en el lado del cliente se puede calcular iterando, analizando para diferentes números el cambio en la intensidad de las respuestas ACK junto con la ausencia de un paquete con la bandera RST.
En esta etapa, el atacante conoce los cuatro elementos de la conexión (direcciones/puertos IP de origen y dirección/puerto IP de destino), pero para generar un paquete falso que el sistema de la víctima acepte, el atacante debe determinar los números de secuencia y confirmación (seq y ack) de la conexión TCP. Para determinar estos parámetros, el atacante envía continuamente paquetes RST falsos, iterando sobre diferentes números de secuencia, hasta que capta un paquete ACK de respuesta, cuya recepción indica que el número cae dentro de la ventana TCP.
A continuación, el atacante verifica la exactitud de la identificación enviando paquetes con el mismo número y observando la llegada de respuestas ACK, después de lo cual encuentra el número exacto de la secuencia actual. La tarea se complica porque las respuestas se envían dentro de un túnel cifrado, y su análisis en el flujo de tráfico interceptado solo se puede hacer de manera indirecta. El hecho de que el cliente envíe un paquete ACK dirigido al servidor VPN se determina en función del tamaño y la latencia de las respuestas cifradas, correlacionando con el envío de paquetes falsos. Por ejemplo, para OpenVPN, un paquete cifrado de tamaño 79 permite inferir con precisión que contiene una confirmación ACK.
Antes de que la protección contra ataques se agregue al núcleo del sistema operativo, como un método temporal para bloquear el problema utilizando un filtro de paquetes en la cadena «preroute», para bloquear la transmisión de paquetes con la dirección de destino especificada como la dirección IP virtual del túnel.
iptables -t raw -I PREROUTING ! -i wg0 -d 10.182.12.8 -m addrtype ! —src-type LOCAL -j DROP
o para nftables
nft add table ip raw
nft add chain ip raw prerouting ‘{ type filter hook prerouting priority 0; }’
nft add rule ip raw prerouting ‘iifname != «wg0» ip daddr 10.182.12.8 fib saddr type != local drop’
Para protegerse al utilizar túneles con direcciones IPv4, es suficiente configurar rp_filter en modo 'Strict' ('sysctl net.ipv4.conf.all.rp_filter = 1'). Desde el lado de VPN, el método para determinar el número de secuencia puede ser bloqueado agregando relleno a los paquetes cifrados, haciendo que el tamaño de todos los paquetes sea igual.
Fuente: opennet.ru
