Les VPN garantissent-ils la confidentialité des données à 100% ? Selon des chercheurs en sécurité de Leviathan Security Group la réponse est clairement non. Ils ont récemment identifié un procédé capable de contourner l'encapsulation VPN. "Un attaquant peut utiliser cette technique pour forcer le trafic d'un utilisateur cible à quitter son tunnel VPN en utilisant les fonctions intégrées du protocole DHCP", explique la société de conseil dans un rapport. "Le résultat est que l'utilisateur transmet des paquets qui ne sont jamais cryptés par un VPN et qu'un pirate peut espionner son trafic". Le principal problème est que cette découverte pourrait en fait être utilisée à des fins malveillantes depuis 22 ans... Il semble donc plus que temps de trouver une parade à la faille CVE-2024-3661 baptisée TunnelVision. Dans le cadre de son étude, Leviathan a constaté que les VPN qui s'appuient uniquement sur des règles de routage pour sécuriser le trafic de l'hôte sont vulnérables. Toute personne hébergeant ses VPN ou les administrateurs système qui ne renforcent pas leur configuration sont probablement exposés. "La force de l'algorithme de chiffrement utilisé par un VPN ne fait aucune différence. L'effet de TunnelVision est indépendant du protocole VPN sous-jacent par exemple, WireGuard, OpenVPN ou IPsec, car il reconfigure la pile réseau de l'OS sur laquelle repose le VPN", prévient la société.

Un PoC d'exploit pour "décloquer" les VPN a été mis au point, consistant à faire fonctionner un serveur DHCP sur le même réseau que l'utilisateur VPN ciblé et à reparamétrer la configuration DHCP pour qu'elle s'utilise elle-même comme passerelle. "Nous nous servons de l'option 121 du DHCP pour définir une route dans la table de routage de l'utilisateur du VPN. La route que nous définissons est arbitraire et nous pouvons également définir plusieurs routes si nécessaire.", poursuit Leviathan. En imposant des routes plus spécifiques que la plage CIDR /0 utilisée par la plupart des VPN, la société est parvenue à établir des règles de routage davantage prioritaires que les routes créée par le VPN. "Nous pouvons définir plusieurs routes /1 pour recréer la règle 0.0.0.0/0 pour tout le trafic défini par la plupart des VPN. Pousser une route signifie également que le trafic réseau sera envoyé sur la même interface que le serveur DHCP au lieu de l'interface réseau virtuelle. Il s'agit d'une fonctionnalité prévue qui n'est pas clairement indiquée dans le RFC. Par conséquent, pour les routes que nous poussons, le trafic n'est jamais chiffré par le VPN, mais transmis par l'interface réseau qui parle au serveur DHCP", poursuit l'entreprise.

Le scénario de renouvellement de bail DHCP dans le viseur

Dans la peau d'un attaquant, Leviathan a pu sélectionner les adresses IP qui passent par le tunnel et par l'interface réseau communiquant avec son serveur DHCP pour transmettre le trafic en dehors du tunnel crypté du VPN. "Nous pouvons créer artificiellement ce scénario en fixant une courte durée de bail dans le bail DHCP, de sorte que l'utilisateur mette à jour sa table de routage plus fréquemment. De plus, le canal de contrôle du VPN reste intact car il utilise déjà l'interface physique pour sa communication. Lors de nos tests, le VPN a toujours continué à signaler qu'il était connecté, et le kill switch n'a jamais été enclenché pour interrompre notre connexion VPN", prévient la société de conseil.

Cette dernière indique qu'elle a eu connaissance d'une mesure d'atténuation et même d'un correctif pour les systèmes basés sur Linux mais que le remède pourrait s'avérer moyennement efficace : "cette solution apporte un canal latéral qui pourrait être utilisé pour du déni de service ou pour désanonymiser la destination du trafic", prévient elle. "Ce canal latéral pourrait à lui seul entrainer l'emprisonnement ou la mort de ceux qui comptent sur les VPN pour assurer leur sécurité". Cette découverte intervient après un coup dur aux utilisateurs de systèmes Windows dont la dernière mise à jour de sécurité casse les VPN. Pour résoudre ce problème (qui ne consiste pas juste à supprimer le support de la fonction DHCP risquant de rompre la connexion Internet), Leviathan Security Group propose plusieurs approches. Tout d'abord une résolution, réalisée sur la base de la documentation de WireGuard, en suggérant aux fournisseurs VPN d'implémenter des namespaces réseau au niveau des distributions Linux afin de segmenter les interfaces et les tables de routage en dehors du réseau local. L'utilisation d'espaces de noms de réseau sous Linux peut complètement corriger ce comportement d'après la société. Cependant, cette fonction semble être spécifique à Linux et il n'est pas dit qu'une telle mesure ayant un même niveau de robustesse puisse être appliquée aux environnements Windows, MacOS ou autres. Et reste à savoir dans quelle mesure les fournisseurs VPN seront ou non réceptifs à l'invocation de Leviathan Security Group.

Des mesures d'atténuation à tester

La société propose aussi plusieurs techniques d'atténuation parmi lesquelles le réglage des pare-feux. "Nous avons observé des fournisseurs de VPN qui refusaient tout le trafic entrant et sortant vers et depuis l'interface physique via des règles de pare-feu. Une exception était nécessaire pour les IP des serveurs DHCP et VPN, car elles sont indispensables pour rester connecté au réseau local et au serveur VPN", fait savoir Leviatan. L'inspection approfondie des paquets pourrait également être effectuée pour n'autoriser que les protocoles DHCP et VPN mais dans ce cas un impact sur les performances serait à prévoir.

Autre solution possible : ignorer l'option 121 lorsque le VPN est activé. Principal inconvénient ? Rompre la connectivité du réseau. "Si cette mesure d'atténuation est mise en œuvre, elle doit être obligatoire, car les attaquants pourraient simplement refuser l'accès au réseau jusqu'à ce que le VPN ou l'utilisateur réactive l'option 121", prévient Leviatan. Utiliser un hotspot ou une VM peut aussi être envisagé pour créer un réseau local verrouillé par mot de passe avec traduction automatique de l'adresse réseau, tout comme ne pas recourir à des réseaux non fiables si vous avez besoin d'une confidentialité absolue de votre trafic.