Unha técnica de ataque (CVE-2019-14899) que permite que os paquetes sexan falsificados, modificados ou inseridos en conexións TCP enrutadas a través de túneles VPN. O problema afecta a Linux, FreeBSD, OpenBSD, Android, macOS, iOS e outros sistemas tipo Unix. Linux admite o mecanismo rp_filter (filtrado de ruta inversa) para IPv4, que, cando está activado no modo "Estrito", neutraliza este problema.
O método permite a substitución de paquetes a nivel de conexións TCP que pasan dentro dun túnel cifrado, pero non permite a cuña en conexións que usan capas de cifrado adicionais (por exemplo, TLS, HTTPS, SSH). Os algoritmos de cifrado utilizados na VPN non importan, xa que os paquetes falsificados proveñen da interface externa e son procesados polo núcleo como paquetes da interface VPN. O obxectivo máis probable do ataque é interferir con conexións HTTP sen cifrar, pero e usar un ataque para manipular as respostas de DNS.
Demostrouse a suplantación de paquetes con éxito para túneles creados usando OpenVPN, WireGuard IKEv2/IPSec.Tor non é susceptible a este problema, xa que usa SOCKS para o reenvío do tráfico e a vinculación á interface de bucle. Para IPv4, o ataque é posible se rp_filter está configurado no modo "Loose" (sysctl net.ipv4.conf.all.rp_filter = 2). Inicialmente, a maioría dos sistemas usaban o modo "Strict", pero comezando con , lanzado o pasado decembro, o modo predeterminado cambiou a "Loose" e este cambio reflectiuse na configuración predeterminada de moitas distribucións. Linux.
mecanismo rp_filter para verificar adicionalmente as rutas de paquetes para evitar a suplantación de enderezos de orixe. Cando se establece en 0, non se realiza ningunha comprobación de enderezos de orixe e calquera paquete pódese reenviar entre interfaces de rede sen restricións. O modo 1 "Estrito" inclúe a comprobación de cada paquete procedente de fóra para comprobar o cumprimento da táboa de enrutamento e se a interface de rede a través da que se recibiu o paquete non está asociada coa ruta de entrega de resposta óptima, entón o paquete descartarase. O modo 2 "Folto" relaxa a comprobación para permitir que os equilibradores de carga ou o enrutamento asimétrico funcionen cando
A ruta de resposta pode pasar por unha interface de rede distinta a aquela pola que chegou o paquete entrante.
No modo solto, un paquete entrante compróbase na táboa de enrutamento, pero considérase válido se o enderezo de orixe é accesible a través de calquera interface de rede dispoñible. O ataque proposto baséase no feito de que o atacante pode enviar un paquete cun enderezo de orixe falsificado correspondente á interface VPN e, a pesar de que este paquete entrará no sistema a través da interface de rede externa e non a través da VPN, no rp_filter O modo "solto" tal paquete non se descartará.
Para levar a cabo un ataque, o atacante debe controlar a pasarela a través da cal o usuario accede á rede (por exemplo, a través dunha organización MITM, cando a vítima se conecta a un punto de acceso sen fíos controlado polo atacante ou a través de ). Ao controlar a pasarela a través da cal un usuario está conectado á rede, un atacante pode enviar paquetes falsos que se percibirán no contexto da interface de rede VPN, pero as respostas serán encamiñadas a través do túnel.
Ao xerar un fluxo de paquetes ficticios nos que se substitúe o enderezo IP da interface VPN, inténtase influír na conexión establecida polo cliente, pero a influencia destes paquetes só se pode observar mediante a análise pasiva do fluxo de tráfico cifrado asociado. coa explotación do túnel. Para levar a cabo un ataque, cómpre descubrir o enderezo IP da interface de rede do túnel asignado polo servidor VPN e tamén determinar que unha conexión a un host específico está actualmente activa a través do túnel.
Para determinar o enderezo IP da interface de rede virtual da VPN, envíanse paquetes SYN-ACK ao sistema vítima, percorrendo secuencialmente todo o rango de enderezos virtuais (en primeiro lugar, búscanse os enderezos usados na VPN por defecto, por exemplo en OpenVPN Úsase a subrede 10.8.0.0/24). A existencia do enderezo pódese xulgar en función da recepción dunha resposta co indicador RST.
De xeito similar, determínase a presenza dunha conexión a un sitio determinado e o número de porto no lado do cliente; ao clasificar os números de porto, envíase ao usuario un paquete SYN, como enderezo de orixe, no que a IP. do sitio substitúese e o enderezo de destino é unha VPN IP virtual. Pódese predicir o porto do servidor (80 para HTTP) e o número de porto no lado do cliente pódese calcular mediante forza bruta, analizando para diferentes números o cambio na intensidade das respostas ACK en combinación coa ausencia dun paquete co RST. Bandeira.
Nesta fase, o atacante coñece os catro elementos da conexión (enderezos IP de orixe/porto e enderezo IP/porto de destino), pero para xerar un paquete ficticio que o sistema vítima aceptará, o atacante debe determinar a secuencia TCP e números de recoñecemento (seq e ack) - conexións. Para determinar estes parámetros, o atacante envía continuamente paquetes RST falsos, probando con diferentes números de secuencia, ata que detecta un paquete de resposta ACK, cuxa chegada indica que o número cae dentro da xanela TCP.
O atacante verifica entón a corrección da detección enviando paquetes co mesmo número e observando as respostas ACK entrantes, tras o cal determina o número de secuencia exacto da secuencia actual. A tarefa complícase polo feito de que as respostas se envían dentro dun túnel cifrado e a súa presenza no fluxo de tráfico interceptado só se pode analizar indirectamente. Se o cliente enviou un paquete ACK dirixido ao servidor VPN determínase en función do tamaño e a latencia das respostas cifradas, que se correlacionan co envío de paquetes falsificados. Por exemplo, para OpenVPN Un paquete cifrado cun tamaño de 79 permítenos xulgar con precisión que contén unha confirmación ACK.
Ata que se engade a protección contra ataques ao núcleo do sistema operativo como método temporal para bloquear o problema utilizando un filtro de paquetes na cadea "preroute", bloquea o paso de paquetes nos que se especifica o enderezo IP virtual do túnel como enderezo de destino.
iptables -t raw -I PRERUTING ! -i wg0 -d 10.182.12.8 -m tipo de enderezo ! --src-type LOCAL -j DROP
ou para nftables
nft engadir táboa ip raw
nft add chain ip raw prerouting '{ tipo 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 protexerse cando use túneles con enderezos IPv4, simplemente configure rp_filter no modo "Estrito" ("sysctl net.ipv4.conf.all.rp_filter = 1"). No lado da VPN, o método de detección de números de secuencia pódese bloquear engadindo un recheo adicional aos paquetes cifrados, facendo que todos os paquetes teñan o mesmo tamaño.
Fonte: opennet.ru
