Technique d'attaque (CVE-2019-14899) permettant de modifier ou de substituer des paquets dans des connexions TCP, transmises via des tunnels VPN. Le problème concerne Linux, FreeBSD, OpenBSD, Android, macOS, iOS et d'autres systèmes de type Unix. Linux prend en charge le mécanisme rp_filter (filtrage de chemin inverse) pour IPv4, dont l'activation en mode "Strict" neutralise ce problème.
Cette méthode permet de substituer des paquets au niveau des connexions TCP à l'intérieur d'un tunnel chiffré, mais ne permet pas de s'immiscer dans des connexions utilisant des couches de chiffrement supplémentaires (par exemple, TLS, HTTPS, SSH). Les algorithmes de chiffrement utilisés dans les VPN n'ont pas d'importance, car les paquets falsifiés proviennent de l'interface externe et sont traités par le noyau comme des paquets de l'interface VPN. La cible la plus probable de l'attaque est l'interférence avec les connexions HTTP non chiffrées, mais l'utilisation de l'attaque pour manipuler les réponses DNS.
La substitution de paquets réussie a été démontrée pour les tunnels créés à l'aide de OpenVPN, WireGuard et IKEv2/IPSec. Tor est protégé contre ce problème, car il utilise SOCKS pour transmettre le trafic et se lie à l'interface loopback. Pour IPv4, l'attaque est possible si rp_filter est mis en mode "Loose" (sysctl net.ipv4.conf.all.rp_filter = 2). Initialement, la plupart des systèmes utilisaient le mode "Strict", mais à partir de , sorti en décembre de l'année dernière, le mode de fonctionnement par défaut a été changé en "Loose" et ce changement est reflété dans les paramètres par défaut de nombreux distributions Linux.
Le mécanisme rp_filter pour une vérification supplémentaire des chemins de passage des paquets afin d'éviter le spoofing de l'adresse source. Lorsqu'il est réglé à 0, la vérification de l'adresse source n'est pas effectuée et tout paquet peut être redirigé sans restrictions entre les interfaces réseau. Le mode 1 "Strict" active la vérification de chaque paquet entrant pour s'assurer qu'il correspond à la table de routage, et si l'interface réseau par laquelle le paquet a été reçu n'est pas liée à la route optimale de livraison de la réponse, alors le paquet est rejeté. Le mode 2 "Loose" assouplit la vérification, permettant de fonctionner lors de l'utilisation de répartiteurs de charge ou de routage asymétrique, où
la route de réponse peut passer par une interface réseau différente de celle par laquelle le paquet entrant est arrivé.
En mode « Loose », le paquet entrant est vérifié par rapport à la table de routage, mais est jugé valide si l'adresse source est accessible par n'importe quelle interface réseau existante. L'attaque propose que l'attaquant puisse envoyer un paquet avec une adresse source falsifiée correspondant à l'interface VPN, et bien que ce paquet arrive dans le système via une interface réseau externe plutôt que par VPN, en mode rp_filter « Loose », ce paquet ne sera pas rejeté.
Pour mener à bien l'attaque, l'attaquant doit contrôler la passerelle par laquelle l'utilisateur accède au réseau (par exemple, via une organisation MITM, lorsque la victime se connecte à un point d'accès Wi-Fi contrôlé par l'attaquant ou à travers ). En contrôlant la passerelle à laquelle l'utilisateur est connecté au réseau, l'attaquant peut envoyer des paquets factices, qui seront perçus dans le contexte de l'interface réseau VPN, mais les réponses seront envoyées via le tunnel.
En générant un flux de paquets factices, dans lequel l'adresse IP de l'interface VPN est insérée, des tentatives sont faites pour influencer la connexion établie par le client, mais l'observation de l'impact de ces paquets ne peut se faire que par une analyse passive du flux de trafic chiffré associé au fonctionnement du tunnel. Pour mener l'attaque, il est nécessaire de connaître l'adresse IP du tunnel attribuée par le serveur VPN, ainsi que de déterminer qu'à ce moment, une connexion active à un certain hôte passe par le tunnel.
Pour déterminer l'adresse IP de l'interface réseau virtuelle VPN, des paquets SYN-ACK sont envoyés au système victime, en itérant progressivement sur toute la plage d'adresses virtuelles (en priorité, les adresses utilisées par défaut dans le VPN, par exemple, dans OpenVPN, le sous-réseau 10.8.0.0/24 est utilisé). L'existence d'une adresse peut être jugée sur la base de la réception d'une réponse avec le drapeau RST.
De la même manière, la présence d'une connexion avec un site donné et le numéro de port du côté client sont déterminés - en parcourant les numéros de ports vers l'utilisateur, un paquet SYN est envoyé avec l'adresse source définie comme l'IP du site et l'adresse de destination comme l'IP virtuelle du VPN. Le port du serveur peut être prédit (80 pour HTTP), tandis que le numéro de port côté client peut être calculé par essai et erreur, en analysant les réponses ACK pour différents numéros, en combinaison avec l'absence de paquet avec le drapeau RST.
À ce stade, l'attaquant connaît les quatre éléments de la connexion (adresses/port IP source et adresse/port IP destination), mais pour générer un paquet fictif, que le système de la victime interprétera, l'attaquant doit déterminer les numéros de séquence et d'accusé de réception (seq et ack) de la connexion TCP. Pour définir ces paramètres, l'attaquant envoie continuellement de faux paquets RST, en essayant différents numéros de séquence, jusqu'à ce qu'il capture un paquet ACK de réponse, dont la réception indique que le numéro se trouve dans la fenêtre TCP.
Ensuite, l'attaquant vérifie la précision de son identification en envoyant des paquets avec le même numéro et en observant les ACK- réponses reçues, après quoi il ajuste le numéro de la séquence actuelle. La tâche est compliquée par le fait que les réponses sont envoyées à l'intérieur d'un tunnel chiffré et qu'il n'est possible de les analyser dans le flux de trafic intercepté que par des méthodes indirectes. La réalité de l'envoi d'un paquet ACK à destination du serveur VPN par le client est déterminée sur la base de la taille et du délai des réponses chiffrées, corrélées à l'envoi de paquets falsifiés. Par exemple, pour OpenVPN, un paquet chiffré de taille 79 permet de conclure avec certitude qu'il contient une confirmation ACK.
Avant que la protection contre l'attaque ne soit ajoutée au noyau du système d'exploitation, comme méthode temporaire pour bloquer le problème en utilisant un filtre de paquets dans la chaîne «preroute» pour bloquer le passage des paquets dont l'adresse de destination est l'adresse IP virtuelle du tunnel.
iptables -t raw -I PREROUTING ! -i wg0 -d 10.182.12.8 -m addrtype ! --src-type LOCAL -j DROP
ou pour 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'
Pour se protéger lors de l'utilisation de tunnels avec des adresses IPv4, il suffit de passer le rp_filter en mode « Strict » (« sysctl net.ipv4.conf.all.rp_filter = 1 »). Du côté VPN, la méthode de détermination du numéro de séquence peut être bloquée en ajoutant un remplissage aux paquets chiffrés, rendant la taille de tous les paquets identique.
Source : opennet.ru
