Le public est informé d'une méthode d'attaque appelée TunnelVision, qui permet, en ayant accès à un réseau local ou un contrôle sur un réseau sans fil, de rediriger le trafic de la victime vers son propre hôte, contournant ainsi le VPN (au lieu d'être envoyé via le VPN, le trafic sera transmis en clair, sans tunneling vers le système de l'attaquant). Tous les clients VPN qui n'utilisent pas des espaces de noms réseau isolés lors de la direction du trafic dans le tunnel ou qui ne mettent pas en place des règles de filtrage de paquets interdisant la routage du trafic VPN par les interfaces réseau physiques existantes sont vulnérables.
Le principe de l'attaque est que l'attaquant peut lancer son propre serveur DHCP et l'utiliser pour transmettre au client des informations pour modifier la routage. En particulier, l'attaquant peut profiter de l'option 121 fournie par le protocole DHCP (RFC-3442, adoptée en 2002), destinée à transmettre des informations sur les routes statiques, pour apporter des modifications à la table de routage sur la machine de la victime et diriger le trafic en contournant. VPNLa redirection s'effectue en établissant une série de routes pour des sous-réseaux avec le préfixe /1, qui ont une priorité plus élevée que la route par défaut avec le préfixe /0 (0.0.0.0/0), de sorte que le trafic, au lieu d'être dirigé vers l'interface réseau virtuelle du VPN, sera envoyé via l'interface réseau physique vers l'hôte de l'attaquant sur le réseau local.
L'attaque peut être réalisée sur tous les systèmes d'exploitation supportant l'option 121 de DHCP, y compris Linux, Windows, iOS et macOS, indépendamment du protocole VPN utilisé (Wireguard, OpenVPN, IPsec) et de l'ensemble de chiffrement. La plateforme Android n'est pas vulnérable à l'attaque, car elle ne traite pas l'option 121 dans DHCP. Cependant, l'attaque permet d'accéder au trafic, mais ne permet pas de s'immiscer dans les connexions ni de déterminer le contenu transmis en utilisant des protocoles niveau application sécurisés tels que TLS et SSH ; par exemple, l'attaquant ne peut pas déterminer le contenu des requêtes HTTPS, mais peut comprendre à quels serveurs elles sont envoyées.
Pour se protéger contre une attaque, il est possible d'interdire au niveau du filtrage des paquets l'envoi de paquets destinés à l'interface VPN par d'autres interfaces réseau ; de bloquer les paquets DHCP avec l'option 121 ; d'utiliser un VPN à l'intérieur d'une machine virtuelle séparée (ou d'un conteneur) isolée du réseau externe, ou d'appliquer des modes spéciaux de configuration de tunnels utilisant des espaces de noms dans Linux (network namespace). Un ensemble de scripts a été publié pour expérimenter la conduite d'une attaque.
Il est à noter que l'idée de modification locale de la routage n'est pas nouvelle et était auparavant généralement utilisée dans des attaques visant à remplacer le serveur DNS. Dans une attaque similaire, TunnelCrack, où le trafic était redirigé en remplaçant la passerelle par défaut, le problème touchait tous les clients VPN vérifiés pour iOS, 87,5 % des clients VPN pour macOS, 66,7 % pour Windows, 35,7 % pour Linux et 21,4 % pour Android. Dans le contexte des VPN et du DHCP, la méthode a également été mentionnée précédemment, par exemple, un des rapports de la conférence USENIX 2023 lui était consacré (l'étude a montré que 64,6 % des 195 clients VPN testés étaient vulnérables à l'attaque).
Pour l'injection de routes, il a également été proposé d'utiliser une clé USB spécialement formatée, simulant le fonctionnement d'un adaptateur réseau, qui en se connectant à un ordinateur via DHCP se déclare comme passerelle. De plus, lorsqu'il y a contrôle sur la passerelle (par exemple, en connectant la victime à un réseau sans fil contrôlé par l'attaquant), une technique d'injection de paquets dans le tunnel a été développée, perçue dans le contexte de l'interface réseau VPN.
Flux de données lors de l'utilisation d'un VPN :
Flux de données après une attaque :
Source : opennet.ru
