una técnica de ataque (CVE-2019-14899) que permite falsificar, modificar o sustituir paquetes en conexiones TCP reenviadas a través de túneles VPN. El problema afecta a Linux, FreeBSD, OpenBSD, Android, macOS, iOS y otros sistemas similares a Unix. Linux admite el mecanismo rp_filter (filtrado de ruta inversa) para IPv4; activarlo en modo "Estricto" neutraliza este problema.
El método permite la sustitución de paquetes a nivel de conexiones TCP que pasan dentro de un túnel cifrado, pero no permite la integración en conexiones que utilizan capas de cifrado adicionales (por ejemplo, TLS, HTTPS, SSH). Los algoritmos de cifrado utilizados en la VPN no importan, ya que los paquetes falsificados provienen de la interfaz externa y el núcleo los procesa como paquetes de la interfaz VPN. El objetivo más probable del ataque es interferir con conexiones HTTP no cifradas, pero y utilizar un ataque para manipular las respuestas DNS.
Se ha demostrado que la suplantación de paquetes es exitosa para túneles creados usando OpenVPN, WireGuard e IKEv2/IPSec. Tor no es susceptible al problema, ya que usa SOCKS para reenviar el tráfico y está vinculado a una interfaz loopback. Para IPv4, un ataque es posible si rp_filter está configurado en modo "Suelto" (sysctl net.ipv4.conf.all.rp_filter = 2). Inicialmente, la mayoría de los sistemas utilizaban el modo "Estricto", pero a partir de , lanzado en diciembre pasado, el modo operativo predeterminado se cambió a "Suelto" y este cambio se reflejó en la configuración predeterminada de muchas distribuciones de Linux.
mecanismo rp_filter para una verificación adicional de las rutas de los paquetes para evitar la suplantación de direcciones de origen. Cuando se establece en 0, no se realiza ninguna verificación de la dirección de origen y cualquier paquete se puede reenviar entre interfaces de red sin restricciones. El modo 1 "Estricto" incluye verificar que cada paquete proveniente del exterior cumpla 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 de entrega de respuesta óptima, entonces el paquete se descarta. El Modo 2 "Suelto" relaja la verificación para permitir que los balanceadores de carga o el enrutamiento asimétrico funcionen cuando
La ruta de respuesta puede pasar a través de una interfaz de red distinta de aquella por la que llegó el paquete entrante.
En el modo suelto, un paquete entrante se compara con la tabla de enrutamiento, pero se considera válido si se puede acceder a la dirección de origen a través de cualquier interfaz de red disponible. El ataque propuesto se basa en que el atacante puede enviar un paquete con una dirección de origen falsificada correspondiente a la interfaz VPN, y a pesar de que este paquete ingresará al sistema a través de la interfaz de red externa y no a través de la VPN, en el rp_filter Modo “suelto”, dicho paquete no será descartado.
Para llevar a cabo un 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 mediante ). Al controlar la puerta de enlace a través de la cual un usuario está conectado a la red, un atacante puede enviar paquetes falsos que serán percibidos en el contexto de la interfaz de red VPN, pero las respuestas se enrutarán a través del túnel.
Al generar un flujo de paquetes ficticios en los que se sustituye la dirección IP de la interfaz VPN, se intenta influir en la conexión establecida por el cliente, pero la influencia de estos paquetes sólo puede observarse mediante un análisis pasivo del flujo de tráfico cifrado asociado. con la explotación del túnel. Para llevar a cabo un ataque, debe averiguar la dirección IP de la interfaz de red del túnel asignada por el servidor VPN y también determinar que actualmente hay activa una conexión a un host específico a través del túnel.
Para determinar la IP de la interfaz de red virtual VPN, los paquetes SYN-ACK se envían al sistema víctima, enumerando secuencialmente todo el rango de direcciones virtuales (en primer lugar, las direcciones utilizadas en la VPN se enumeran de forma predeterminada, por ejemplo, OpenVPN utiliza la subred 10.8.0.0/24). La existencia de una dirección se puede juzgar en función de la recepción de una respuesta con el indicador RST.
De manera similar, se determina la presencia de una conexión a un sitio determinado y el número de puerto en el lado del cliente: al clasificar los números de puerto, se envía al usuario un paquete SYN, como la dirección de origen, en la que se encuentra la IP. del sitio se sustituye y la dirección de destino es una VPN IP virtual. El puerto del servidor se puede predecir (80 para HTTP) y el número de puerto en el lado del cliente se puede calcular mediante fuerza bruta, analizando para diferentes números el cambio en la intensidad de las respuestas ACK en combinación con la ausencia de un paquete con el RST. bandera.
En esta etapa, el atacante conoce los cuatro elementos de la conexión (direcciones IP/puerto de origen y dirección IP/puerto de destino), pero para generar un paquete ficticio que el sistema víctima acepte, el atacante debe determinar la secuencia TCP y números de reconocimiento (seq y ack) - conexiones. Para determinar estos parámetros, el atacante envía continuamente paquetes RST falsos, probando diferentes números de secuencia, hasta que detecta un paquete de respuesta ACK, cuya llegada indica que el número se encuentra dentro de la ventana TCP.
A continuación, el atacante aclara la exactitud de la definición enviando paquetes con el mismo número y observando la llegada de respuestas ACK, después de lo cual selecciona el número exacto de la secuencia actual. La tarea se complica por el hecho de que las respuestas se envían dentro de un túnel cifrado y su presencia en el flujo de tráfico interceptado sólo puede analizarse mediante métodos indirectos. Si un cliente envía un paquete ACK dirigido al servidor VPN se determina en función del tamaño y la latencia de las respuestas cifradas, que se correlacionan con el envío de paquetes falsificados. Por ejemplo, para OpenVPN, un tamaño de paquete cifrado de 79 le permite juzgar con precisión si hay un ACK en su interior.
Hasta que se agregue protección contra ataques al kernel del sistema operativo como método temporal para bloquear el problema utilizando un filtro de paquetes en la cadena “preroute”, bloquear el paso de paquetes en los que se especifica la dirección IP virtual del túnel como dirección de destino.
iptables -t raw -I ¡PRERUTAMIENTO! -i wg0 -d 10.182.12.8 -m tipo de dirección! --src-tipo LOCAL -j DROP
o para nftables
nft agregar tabla ip raw
nft agregar cadena ip raw prerouting '{tipo filtro gancho prerouting prioridad 0; }'
nft agregar regla 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, simplemente configure rp_filter en modo "Estricto" ("sysctl net.ipv4.conf.all.rp_filter = 1"). En el lado de la VPN, el método de detección del número de secuencia se puede bloquear agregando relleno a los paquetes cifrados, haciendo que todos los paquetes tengan el mismo tamaño.
Fuente: opennet.ru