une technique d'attaque (CVE-2019-14899) qui permet d'usurper, de modifier ou de remplacer des paquets dans les connexions TCP transmises via des tunnels VPN. Le problème affecte 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, son activation en mode « Strict » neutralise ce problème.
La méthode permet la substitution de paquets au niveau des connexions TCP passant à l'intérieur d'un tunnel chiffré, mais ne permet pas de se coincer dans des connexions utilisant des couches de chiffrement supplémentaires (par exemple, TLS, HTTPS, SSH). Les algorithmes de chiffrement utilisés dans le VPN n'ont pas d'importance, puisque les paquets usurpés proviennent de l'interface externe et sont traités par le noyau comme des paquets provenant de l'interface VPN. La cible la plus probable de l'attaque est d'interférer avec les connexions HTTP non chiffrées, mais et utiliser une attaque pour manipuler les réponses DNS.
Une usurpation de paquets réussie a été démontrée pour les tunnels créés à l'aide d'OpenVPN, WireGuard et IKEv2/IPSec. Tor n'est pas sensible à ce problème, car il utilise SOCKS pour transférer le trafic et est lié à une interface de bouclage. Pour IPv4, une attaque est possible si rp_filter est réglé 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 dernier, le mode de fonctionnement par défaut a été modifié en "Loose" et ce changement s'est reflété dans les paramètres par défaut de nombreuses distributions Linux.
mécanisme rp_filter pour une vérification supplémentaire des chemins de paquets afin d’empêcher l’usurpation d’adresse source. Lorsqu'il est défini sur 0, aucune vérification de l'adresse source n'est effectuée et tout paquet peut être transmis entre les interfaces réseau sans restrictions. Le mode 1 « Strict » inclut la vérification de la conformité de chaque paquet provenant de l'extérieur avec la table de routage, et si l'interface réseau via laquelle le paquet a été reçu n'est pas associée à la route de livraison de réponse optimale, alors le paquet est rejeté. Le mode 2 « Loose » assouplit la vérification pour permettre aux équilibreurs de charge ou au routage asymétrique de fonctionner lorsque
La route de réponse peut passer par une interface réseau autre que celle par laquelle le paquet entrant est arrivé.
En mode Loose, un paquet entrant est vérifié par rapport à la table de routage, mais est considéré comme valide si l'adresse source est accessible via n'importe quelle interface réseau disponible. L'attaque proposée est basée sur le fait que l'attaquant peut envoyer un paquet avec une adresse source usurpée correspondant à l'interface VPN, et malgré le fait que ce paquet entrera dans le système via l'interface réseau externe et non via le VPN, dans le rp_filter En mode « loose », un tel paquet ne sera pas rejeté.
Pour mener une 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 sans fil contrôlé par l'attaquant, ou via ). En contrôlant la passerelle par laquelle un utilisateur est connecté au réseau, un attaquant peut envoyer de faux paquets qui seront perçus dans le contexte de l'interface réseau VPN, mais les réponses seront acheminées via le tunnel.
En générant un flux de paquets fictifs dans lequel est substituée l'adresse IP de l'interface VPN, on tente d'influencer la connexion établie par le client, mais l'influence de ces paquets ne peut être observée qu'à travers une analyse passive du flux de trafic chiffré associé. avec l'exploitation du tunnel. Pour mener une attaque, vous devez connaître l'adresse IP de l'interface réseau du tunnel attribuée par le serveur VPN, et également déterminer qu'une connexion à un hôte spécifique est actuellement active via le tunnel.
Pour déterminer l'IP de l'interface réseau virtuelle VPN, des paquets SYN-ACK sont envoyés au système victime, énumérant séquentiellement toute la plage d'adresses virtuelles (tout d'abord, les adresses utilisées dans le VPN sont énumérées par défaut, par exemple, OpenVPN utilise le sous-réseau 10.8.0.0/24). L'existence d'une adresse peut être jugée sur la base de la réception d'une réponse avec l'indicateur RST.
De la même manière, la présence d'une connexion à un certain site et le numéro de port côté client sont déterminés - en triant les numéros de port, un paquet SYN est envoyé à l'utilisateur, comme adresse source, dans laquelle le site L'IP est remplacé et l'adresse de destination est un VPN IP virtuel. Le port du serveur peut être prédit (80 pour HTTP) et le numéro de port côté client peut être calculé par force brute, en analysant pour différents nombres le changement de l'intensité des réponses ACK en combinaison avec l'absence de paquet avec le RST. drapeau.
À ce stade, l'attaquant connaît les quatre éléments de la connexion (adresses IP/port source et adresse IP/port de destination), mais afin de générer un paquet fictif que le système victime acceptera, l'attaquant doit déterminer la séquence TCP et numéros d'accusé de réception (seq et ack) - connexions. Pour déterminer ces paramètres, l'attaquant envoie en continu de faux paquets RST, en essayant différents numéros de séquence, jusqu'à ce qu'il détecte un paquet de réponse ACK dont l'arrivée indique que le numéro se situe dans la fenêtre TCP.
Ensuite, l'attaquant clarifie l'exactitude de la définition en envoyant des paquets avec le même numéro et en observant l'arrivée des réponses ACK, après quoi il sélectionne le numéro exact 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 crypté et que leur présence dans le flux de trafic intercepté ne peut être analysée qu'à l'aide de méthodes indirectes. Le fait qu'un client envoie un paquet ACK adressé au serveur VPN est déterminé en fonction de la taille et de la latence des réponses chiffrées, qui sont en corrélation avec l'envoi de paquets usurpés. Par exemple, pour OpenVPN, une taille de paquet chiffré de 79 vous permet de juger avec précision qu'il y a un ACK à l'intérieur.
Jusqu'à ce qu'une protection contre les attaques soit ajoutée au noyau du système d'exploitation comme méthode temporaire pour bloquer le problème à l'aide d'un filtre de paquets dans la chaîne « préroute », bloquer le passage des paquets dans lesquels l'adresse IP virtuelle du tunnel est spécifiée comme adresse de destination.
iptables -t raw -I PREROUTING ! -i wg0 -d 10.182.12.8 -m type d'adresse ! --src-type LOCAL -j DROP
ou pour les nftables
nft ajouter une table ip brute
nft ajouter une chaîne ip préroutage brut '{ type filtre hook préroutage priorité 0 ; }'
nft ajouter une règle ip raw prerouting 'iifname != "wg0" ip daddr 10.182.12.8 fib saddr type != local drop'
Pour vous protéger lors de l'utilisation de tunnels avec des adresses IPv4, définissez simplement rp_filter sur le mode « Strict » (« sysctl net.ipv4.conf.all.rp_filter = 1 »). Du côté VPN, la méthode de détection du numéro de séquence peut être bloquée en ajoutant un remplissage supplémentaire aux paquets chiffrés, ce qui donne à tous les paquets la même taille.
Source: opennet.ru