técnica de ataque (CVE-2019-14899), que permite substituir, alterar ou inserir pacotes em conexões TCP, transmitidas através de túneis VPN. O problema afeta sistemas Linux, FreeBSD, OpenBSD, Android, macOS, iOS e outros sistemas semelhantes ao Unix. O Linux suporta o mecanismo rp_filter (filtragem de caminho reverso) para IPv4, cuja ativação no modo 'Strict' neutraliza este problema.
O método permite a inserção de pacotes no nível das conexões TCP que passam por um túnel criptografado, mas não permite a intercepção de conexões que utilizam camadas adicionais de criptografia (por exemplo, TLS, HTTPS, SSH). Os algoritmos de criptografia utilizados em VPNs não têm importância, uma vez que pacotes falsificados chegam da interface externa e são processados pelo núcleo como pacotes da interface VPN. O alvo mais provável do ataque é a interferência em conexões HTTP não criptografadas, mas e o uso do ataque para manipular respostas DNS.
A substituição bem-sucedida de pacotes foi demonstrada para túneis criados com OpenVPN, WireGuard e IKEv2/IPSec. O Tor não está sujeito ao problema, pois utiliza SOCKS para encaminhar o tráfego e vinculação à interface de loopback. Para IPv4, o ataque é possível se o rp_filter for configurado no modo 'Loose' (sysctl net.ipv4.conf.all.rp_filter = 2). Inicialmente, a maioria dos sistemas usava o modo 'Strict', mas a partir de , lançado em dezembro do ano passado, o modo de operação padrão foi alterado para 'Loose' e essa mudança se refletiu nas configurações padrão de muitas distribuições Linux.
O mecanismo rp_filter para verificação adicional de caminhos de passagem de pacotes para prevenir spoofing de endereço de origem. Quando configurado como 0, não há verificação do endereço de origem e qualquer pacote pode ser redirecionado entre interfaces de rede sem restrições. O modo 1 'Strict' habilita a verificação de cada pacote externo em relação à tabela de roteamento, e se a interface de rede pela qual o pacote foi recebido não estiver ligada à rota ideal de entrega da resposta, o pacote é descartado. O modo 2 'Loose' relaxa a verificação para permitir operação ao usar balanceadores de carga ou roteamento assimétrico, onde
a rota de resposta pode passar por uma interface de rede diferente daquela pela qual o pacote de entrada chegou.
No modo 'Loose', o pacote de entrada é verificado quanto à conformidade com a tabela de roteamento, mas é considerado válido se o endereço de origem for acessível através de qualquer interface de rede disponível. O ataque proposto baseia-se no fato de que o invasor pode enviar um pacote com o endereço de origem falsificado, correspondente à interface VPN, e apesar desse pacote entrar no sistema através de uma interface de rede externa, e não pela VPN, no modo rp_filter 'Loose', tal pacote não será descartado.
Para realizar o ataque, o criminoso deve controlar o gateway pelo qual o usuário se conecta à rede (por exemplo, através de uma organização MITM, ao conectar a vítima a um ponto de acesso sem fio controlado pelo atacante ou através de ). Controlando o gateway pelo qual o usuário está conectado à rede, o atacante pode enviar pacotes falsos que serão interpretados no contexto da interface de rede VPN, mas as respostas serão enviadas através do túnel.
Ao gerar um fluxo de pacotes falsos, nos quais é inserido o endereço IP da interface VPN, tentam-se influenciar a conexão estabelecida pelo cliente, mas a observação dos efeitos desses pacotes só pode ser feita através da análise passiva do fluxo de tráfego criptografado relacionado à operação do túnel. Para conduzir o ataque, é necessário descobrir o endereço IP da interface do túnel designado pelo servidor VPN, bem como determinar que atualmente há uma conexão ativa através do túnel para um determinado host.
Para determinar o IP da interface de rede virtual VPN, é enviado ao sistema da vítima pacotes SYN-ACK, percorrendo sequencialmente todo o intervalo de endereços virtuais (primeiramente, são testados os endereços padrão utilizados na VPN, por exemplo, no OpenVPN usa-se a sub-rede 10.8.0.0/24). A existência do endereço pode ser inferida pela chegada de uma resposta com a flag RST.
Da mesma forma, é determinado se há conexão com um site específico e o número da porta no lado do cliente — percorrendo os números de portas em direção ao usuário, é enviado um pacote SYN, onde o IP do site é colocado como endereço de origem, e o endereço de destino é o IP virtual da VPN. A porta do servidor pode ser prevista (80 para HTTP), enquanto o número da porta no lado do cliente pode ser calculado através de tentativa e erro, analisando para diferentes números a variação da intensidade das respostas ACK em conjunto com a ausência de um pacote com o flag RST.
Neste estágio, o atacante conhece todos os quatro elementos da conexão (endereço/porta IP de origem e endereço/porta IP de destino), mas para gerar um pacote falso que será reconhecido pelo sistema da vítima, o atacante deve determinar os números de sequência e confirmação (seq e ack) da conexão TCP. Para determinar esses parâmetros, o atacante continuamente envia pacotes RST falsos, testando diferentes números de sequência, até que receba um pacote ACK em resposta, cuja chegada indica que o número está dentro da janela TCP.
Em seguida, o atacante verifica a precisão da identificação enviando pacotes com o mesmo número e observando a recepção das respostas ACK, após o que ele identifica o número exato da sequência atual. A tarefa é dificultada pelo fato de que as respostas são enviadas dentro de um túnel criptografado, e sua presença no fluxo de tráfego interceptado só pode ser analisada indiretamente. O fato de um pacote ACK endereçado ao servidor VPN ser enviado pelo cliente é determinado com base no tamanho e na latência das respostas criptografadas, correlacionadas com o envio de pacotes falsos. Por exemplo, para o OpenVPN, um pacote criptografado com tamanho 79 permite concluir com precisão que contém uma confirmação ACK.
Antes que a proteção contra ataques seja adicionada ao kernel do sistema operacional, um método temporário de bloqueio do problema é bloquear a passagem de pacotes via um filtro de pacotes na cadeia "preroute", onde o endereço de destino é o endereço IP virtual do túnel.
iptables -t raw -I PREROUTING ! -i wg0 -d 10.182.12.8 -m addrtype ! --src-type LOCAL -j DROP
ou 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 proteger o uso de túneis com endereços IPv4, é suficiente configurar o rp_filter para o modo "Strict" ("sysctl net.ipv4.conf.all.rp_filter = 1"). Do lado da VPN, o método de identificação do número de sequência pode ser bloqueado adicionando preenchimento aos pacotes criptografados, tornando o tamanho de todos os pacotes uniforme.
Fonte: opennet.ru
