Les attaquants peuvent exposer les VPN basés sur le routage
(leviathansecurity.com)- TunnelVision (CVE-2024-3661) abuse d’une fonction existante de DHCP pour détourner le trafic des utilisateurs hors du tunnel VPN, où les paquets ne sont alors pas chiffrés par le VPN
- Les attaquants peuvent injecter des routes plus spécifiques via l’option DHCP 121 afin de créer des chemins prioritaires par rapport à l’interface virtuelle du VPN, et ainsi envoyer le trafic vers l’interface physique
- L’attaque est possible si la cible accepte un bail DHCP contrôlé par l’attaquant et si le client implémente l’option 121 ; lors des tests, Windows, Linux, iOS et macOS ont été affectés, contrairement à Android
- Le canal de contrôle du VPN reste actif, de sorte que l’utilisateur voit toujours le VPN comme connecté ; dans les cas observés, même le kill switch n’a pas empêché les fuites de trafic
- Les espaces de noms réseau de Linux peuvent constituer une solution solide, mais les atténuations basées sur le pare-feu peuvent créer un déni de service sélectif et un canal auxiliaire d’inférence des destinations du trafic
Le décloaking de VPN provoqué par TunnelVision
- TunnelVision est une technique réseau qui contourne l’encapsulation VPN pour forcer le trafic d’un utilisateur à sortir du tunnel
- Un attaquant peut utiliser DHCP (Dynamic Host Configuration Protocol) pour faire en sorte que les paquets ciblés soient transmis sans être chiffrés par le VPN
- Comme le canal de contrôle du VPN reste maintenu, l’utilisateur a toujours l’impression d’être connecté au VPN ; cet effet est appelé decloaking
- Cette technique pourrait être possible depuis 2002, et après sa publication, il a été confirmé qu’il existait des travaux antérieurs sur l’option DHCP 121 et son impact sur les VPN au moins depuis 2015
- 2015 : Hardening OpenVPN for Def Con
- 2016 : Samy Kamkar's
- 2017 : Jomo's Mastodon
- 2023 : Lowend talk thread
Pourquoi le routage VPN devient une surface d’attaque
- Un VPN crée un tunnel pour le trafic entre l’appareil hôte et un serveur situé sur un autre réseau, et le client VPN chiffre et déchiffre le trafic sur une interface réseau virtuelle
- Une configuration qui envoie tout le trafic via le VPN est appelée full-tunnel VPN, tandis qu’une configuration avec des exceptions, comme le réseau local, est appelée split-tunnel VPN
- Comme le VPN doit maintenir la connexion avec le serveur, une route d’exception est nécessaire pour envoyer via l’interface physique le trafic destiné à l’adresse IP du serveur VPN
- La table de routage détermine le chemin du trafic selon la destination, et dans la plupart des piles réseau, un préfixe CIDR plus spécifique a une priorité plus élevée
- Une route
/32est prioritaire sur/24ou/0 - Beaucoup de VPN full-tunnel envoient le trafic vers l’interface VPN avec
0.0.0.0/0ou deux routes/1
- Une route
Injection de routes avec l’option DHCP 121
- DHCP fournit dynamiquement des baux d’adresses IP aux appareils du réseau local et transmet aussi, via des options, des paramètres comme la passerelle par défaut et les serveurs DNS
- Le flux habituel consiste à ce que le client diffuse
DHCPDISCOVER, puis que le serveur propose un bail à durée limitée viaDHCPOFFER - Introduite dans la RFC 3442, l’option DHCP 121 fournit la fonction classless static routes, qui permet à un serveur DHCP d’ajouter des routes statiques à la table de routage du client
- L’option 121 ne permet pas au serveur DHCP de spécifier directement quel périphérique d’interface réseau doit être utilisé pour les routes installées
- Le serveur DHCP indique une plage CIDR et un routeur
- Le client choisit implicitement comme interface de cette route celle par laquelle il communique avec le serveur DHCP
- À cause de ce comportement, le trafic correspondant aux routes injectées peut sortir par l’interface réseau physique utilisée pour parler au serveur DHCP, et non par l’interface virtuelle du VPN
Conditions et déroulement de l’attaque
- L’attaque TunnelVision nécessite deux conditions
- L’hôte ciblé doit accepter un bail provenant d’un serveur DHCP contrôlé par l’attaquant
- Le client DHCP de l’hôte ciblé doit implémenter l’option DHCP 121
- Un attaquant présent sur le même réseau peut devenir le serveur DHCP de la cible de plusieurs façons
- En lançant une attaque de famine DHCP contre le vrai serveur DHCP, puis en répondant aux nouveaux clients
- En répondant en premier aux diffusions
DHCPDISCOVERpour exploiter le comportement de sélection de la première offre du client DHCP - En interceptant le trafic entre le vrai serveur DHCP et le client via ARP spoofing, puis en attendant le renouvellement du bail
- L’attaquant exécute un serveur DHCP sur le même réseau que l’utilisateur du VPN ciblé et se définit comme passerelle
- Il ajoute ensuite des routes arbitraires dans la table de routage de l’utilisateur VPN via l’option DHCP 121, avec des routes plus spécifiques que le
/0du VPN afin qu’elles soient prioritaires sur l’interface virtuelle du VPN- Il est possible de définir plusieurs routes
/1pour reproduire la règle de trafic global0.0.0.0/0utilisée par la plupart des VPN - L’attaquant peut choisir quelles adresses IP passeront dans le tunnel VPN et lesquelles passeront par l’interface qui communique avec le serveur DHCP malveillant
- Il est possible de définir plusieurs routes
- Cela peut aussi s’appliquer à une connexion VPN déjà établie, et un temps de bail DHCP court peut provoquer des mises à jour plus fréquentes de la table de routage
PoC et scénarios expérimentaux
- Les ressources publiées sont les suivantes
- Video proof of concept : https://www.youtube.com/watch?v=ajsLmZia6UU
- Lab Setup Code : https://github.com/leviathansecurity/TunnelVision
- DHCP Server image : https://drive.google.com/file/d/1WLJGs3ZUypf6hLh5WL4AJmsKdUOZo5yZ
- L’environnement de test a été conçu pour représenter plusieurs scénarios d’attaque
- Cas où l’attaquant a compromis le serveur DHCP ou le point d’accès
- Cas où un administrateur malveillant possède et configure directement l’infrastructure
- Cas où l’attaquant installe un point d’accès Wi‑Fi evil twin dans un lieu physique comme un café ou un bureau
- Après la publication future d’ArcaneTrickster, il sera aussi possible de simuler un attaquant sur le même LAN, hôte voisin mais sans position réseau privilégiée
Systèmes d’exploitation et VPN affectés
- Lors des tests, les systèmes d’exploitation qui implémentent un client DHCP conforme à la RFC et prennent en charge les routes de l’option DHCP 121 ont été affectés
- Impact observé : Windows, Linux, iOS, macOS
- Exception : Android n’est pas affecté car il ne prend pas en charge l’option DHCP 121
- Les VPN qui reposent uniquement sur des règles de routage pour protéger le trafic de l’hôte sont vulnérables
- Les administrateurs système qui exploitent leur propre serveur VPN peuvent également être vulnérables s’ils n’ont pas durci la configuration du client VPN
- La robustesse des algorithmes de chiffrement n’a aucun effet
- TunnelVision ne casse pas les protocoles VPN eux-mêmes, comme WireGuard, OpenVPN ou IPsec
- Il modifie la configuration de routage de la pile réseau du système d’exploitation pour faire en sorte que l’utilisateur n’emprunte plus le tunnel VPN
Correctifs et mesures d’atténuation
- Les espaces de noms réseau de Linux peuvent corriger complètement ce comportement
- La documentation WireGuard montre comment traiter dans un espace de noms distinct le trafic des applications devant utiliser le VPN, puis l’envoyer vers un autre espace de noms contenant l’interface physique
- On ne sait pas clairement s’il existe une solution aussi robuste sous Windows, macOS et les autres systèmes d’exploitation
- Certains fournisseurs de VPN utilisent une atténuation qui bloque, via des règles de pare-feu, tout le trafic entrant et sortant sur l’interface physique
- Des exceptions sont nécessaires pour DHCP et pour l’adresse IP du serveur VPN, afin de maintenir le LAN et la connexion au serveur VPN
- Il est aussi possible de n’autoriser que DHCP et le protocole VPN via une inspection approfondie des paquets, mais cela peut entraîner un coût en performances
- Les atténuations par pare-feu peuvent créer un déni de service sélectif pour le trafic utilisant les routes DHCP et ajouter un canal auxiliaire
- Un attaquant peut analyser les variations du volume de trafic VPN chiffré afin de démontrer statistiquement si l’utilisateur ciblé envoie du trafic vers une destination spécifique
- Il peut comparer avec une liste prédéfinie, effectuer un blocage sélectif comme mécanisme de censure, ou utiliser le blocage de l’espace IP comme une recherche binaire pour retrouver une connexion en temps logarithmique
- Il est aussi possible d’ignorer l’option 121 lors de l’utilisation d’un VPN, mais cette fonction peut être nécessaire pour une connectivité réseau légitime et provoquer des problèmes de connexion
- Si cette atténuation est optionnelle, un attaquant peut refuser l’accès au réseau pour pousser le VPN ou l’utilisateur à réactiver l’option 121
- Les hotspots ou les VM peuvent aussi aider à l’atténuation
- Un LAN protégé par mot de passe et contrôlé par un appareil cellulaire peut aider à empêcher l’accès de l’attaquant au réseau local
- Une VM se comporte de manière similaire tant que son adaptateur réseau n’est pas en mode bridged
Mesures à prendre pour les utilisateurs et les opérateurs
- Pour le trafic sensible, il faut éviter les réseaux non fiables et, si cela est inévitable, utiliser un fournisseur VPN disposant de mesures d’atténuation efficaces contre TunnelVision
- Même en cas de decloak VPN, si l’utilisateur accède à des sites web en HTTPS, la plupart de ses données restent invisibles pour un attaquant sur le réseau local, mais la destination et le protocole peuvent être exposés
- Si un VPN d’entreprise est utilisé dans des cafés, hôtels ou aéroports, les administrateurs réseau doivent signaler le risque et recommander d’éviter ces situations autant que possible
- Si ce n’est pas réaliste, ils doivent recommander un VPN intégrant une atténuation ou un correctif
- Il est aussi possible d’utiliser d’abord un hotspot de confiance avant de se connecter au VPN, ou d’exécuter le VPN dans une VM recevant son bail d’un serveur DHCP virtuel
- Les entreprises qui exploitent leur propre réseau ou des VPN site-to-site doivent vérifier leurs commutateurs et activer des protections de couche 2 comme DHCP snooping et la protection ARP
- Ces protections aident à réduire les serveurs DHCP rogue, mais elles n’éliminent pas le scénario d’un administrateur malveillant
- L’application de HTTPS ou d’autres protocoles chiffrés aux ressources internes aide à prévenir les fuites de données pour les utilisateurs VPN se connectant depuis des réseaux non fiables
- Les fournisseurs VPN peuvent ajouter au client une fonction de pare-feu qui bloque les paquets sortants destinés à l’interface réseau, mais les utilisateurs ne pourront alors plus interagir avec les ressources du réseau local
- Les clients VPN full-tunnel pour Linux devraient envisager une isolation basée sur les espaces de noms réseau
- Les mainteneurs de systèmes d’exploitation devraient envisager l’ajout ou le renforcement de fonctions liées aux espaces de noms réseau sur les systèmes autres que Linux
- Une bibliothèque d’infrastructure adverse nommée ArcaneTrickster, destinée à la recherche sur la sécurité des LAN et aux démonstrations d’attaques réelles, est en cours de développement et sera publiée plus tard
1 commentaires
Avis sur Hacker News
C’est une légère variante de l’attaque PoisonTap de Samy Kamkar, en 2016. Elle fait la même chose avec un adaptateur réseau USB/Thunderbolt : on le branche sur la machine de la victime et, en annonçant deux routes plus spécifiques comme 0.0.0.0/1 et 128.0.0.0/1, on peut capter tout le trafic en prenant le pas sur les autres interfaces système, quel que soit l’ordre des interfaces : https://github.com/samyk/poisontap
Il existe probablement d’autres antécédents, mais celui-ci est très connu. Le titre de l’article dit que tous les clients VPN sont affectés, mais, comme le texte l’admet aussi, beaucoup de clients VPN mettent en place des règles de pare-feu qui bloquent le trafic entrant et sortant par les interfaces physiques.
Les VPN qui mettent en avant l’anonymat, ou pour lesquels cet anonymat est important, ont généralement tendance à implémenter cela. Beaucoup de réglages ne sont sans doute pas activés par défaut, mais il aurait été plus utile de documenter quel pourcentage des principales solutions VPN personnelles/commerciales/d’entreprise l’activent par défaut.
L’explication pour le grand public est bonne, mais comme beaucoup de clients empêchent la majeure partie des fuites de données avec ce type de règles de pare-feu, et que l’article ne reconnaît pas les travaux antérieurs dans ce domaine, le titre paraît un peu exagéré.
J’ai failli recracher ma boisson en voyant l’expression « attaque par canal auxiliaire ».
Édition : à ce que je vois, NordVPN n’a pas ce genre de règle de pare-feu par défaut, au moins sur Mac, et semble donc vulnérable à cette attaque.
Je ne comprends pas pourquoi cet article est aussi long.
DHCP Option 121 permet à un serveur DHCP de définir des règles de routage pour des plages CIDR précises ; comme le préfixe est plus long, elles ont une priorité plus élevée que la règle par défaut 0.0.0.0/0.
La moitié des informations sur les VPN disponibles sur Internet sont écrites par des fournisseurs de VPN, et elles sont inexactes ou pas assez techniques pour expliquer comment cela fonctionne réellement.
Nous voulions mettre dans l’introduction une phrase du type « si vous connaissez déjà tout cela, passez à la section POC », avec un lien ; je vais la mettre à jour pour qu’elle soit plus visible.
C’est une supposition basée uniquement sur le commentaire ci-dessus, je n’ai pas lu l’article.
Il me semblait avoir déjà lu cette attaque chez d’autres auteurs, alors j’ai cherché et, après avoir traversé le spam des fournisseurs de VPN qui inonde les résultats, j’ai retrouvé des travaux antérieurs [1].
Cet article-ci va plus loin dans la manière d’exploiter la faille et contient aussi du code utile pour une preuve de concept.
1 : https://www.usenix.org/conference/usenixsecurity23/presentat...
Cela dit, aucune des deux techniques présentées dans l’article d’août 2023 ne poussait des routes via DHCP option 121. Le fait de pousser des routes via DHCP augmente beaucoup l’impact depuis la même position d’attaquant. Par exemple, si l’on est en mesure de distribuer des baux IP hors des plages RFC1918 ou de falsifier des réponses DNS.
Le modèle de menace suppose qu’un attaquant quelconque puisse, d’une manière ou d’une autre, devenir serveur DHCP sur mon LAN ; c’est peu probable, mais pas impossible.
En revanche, si vous utilisez la passerelle fournie par votre FAI, l’histoire est différente.
C’est l’argument de vente numéro 1 de la grande majorité des offres VPN.
Dans ce cas, la bonne réponse est d’utiliser une connexion 4G/5G et de ne pas se connecter à des réseaux douteux et non fiables.
Le fait que, dans un foyer classique, le DHCP soit fourni par le routeur et réponde donc généralement en premier est secondaire. N’importe quel appareil malveillant sur le réseau peut exploiter cette vulnérabilité.
Sous Linux, on peut aussi atténuer le problème en plaçant l’interface VPN dans une VRF. Par exemple, systemd-networkd le prend en charge nativement.
Attention : quand on active une VRF, l’entrée ip rule pour l3mdev est réglée à 1000, tandis que la règle du trafic local est réglée à 0. Il faut déplacer la règle locale à 1000 ou plus.
Cette « attaque » n’est qu’une utilisation astucieuse de DHCP option 121. C’est une attaque valable contre des configurations client gravement cassées.
Changer la route par défaut, ou l’écraser avec deux routes en /1 puis ajouter une route d’hôte vers le point de terminaison VPN, n’est pas sûr. Pour isoler correctement le trafic encapsulé du réseau sous-jacent, il faut utiliser du routage fondé sur des politiques, par exemple les namespaces réseau Linux, vnet sur FreeBSD ou rdomains sur OpenBSD.
Les bricolages qui tentent de combiner de force filtres de paquets et « kill switch » en espace utilisateur sont cassés dès la conception, et montrent à quel point les hébergeurs VPN courants ne comprennent pas, ou ne se soucient pas, de ce qui devrait pourtant être leur compétence centrale. C’est encore le vieux problème consistant à « énumérer les mauvaises choses ».
Rien de vraiment nouveau.
Je m’inquiète davantage pour les gens dont le système a IPv6 activé mais qui utilisent un service VPN uniquement IPv4.
Là, les choses peuvent vraiment très mal tourner.
Il existe énormément de façons de contourner un VPN depuis l’appareil client. C’est pourquoi, quand j’ai besoin d’un VPN, je préfère placer entre le client et Internet un routeur qui termine le tunnel VPN et qui n’a pas d’autre route
Ces routeurs de voyage sont très faciles à configurer et à emporter partout, et c’est d’ailleurs ce que je fais
Par exemple, j’ai un routeur Wi-Fi « work » qui maintient en permanence une connexion VPN vers l’intranet de mon entreprise, un Wi-Fi « Australia » qui se connecte en VPN à un serveur australien chaque fois que je veux regarder la télévision australienne, et enfin le Wi-Fi domestique classique
C’est très facile à faire avec quelques vieux routeurs Wi-Fi, et les routeurs domestiques bon marché actuels semblent aussi offrir un certain niveau de prise en charge des VPN. Au-delà de la centralisation de la configuration du VPN, qui réduit les risques d’erreur, le gros avantage est que n’importe quel appareil peut utiliser le VPN simplement en se connectant au Wi-Fi correspondant
J’utilise ainsi plusieurs vieux routeurs, mais il me semble qu’il y aurait aussi un marché pour un routeur domestique unique capable d’établir des VPN vers plusieurs endroits dans le monde et de proposer un réseau Wi-Fi différent pour chaque localisation. L’idée serait de faire croire facilement qu’une TV, un Roku ou un iPad se connecte depuis une autre région
En revanche, si le LAN contient un appareil non fiable et utilise DHCP, cet appareil peut employer cette technique pour espionner le trafic non chiffré*. Même ainsi, il ne trouvera pas l’adresse IP réelle, car la passerelle la masque
Le scénario le plus réaliste pour cette attaque est un Wi-Fi de café, par exemple. Dans ce genre d’endroit, il est peu probable que l’on apporte son propre routeur
Ici, « trafic non chiffré » désigne le trafic qui n’est pas encapsulé pour être envoyé au fournisseur VPN. De nos jours, la plupart du trafic est en HTTPS, donc son contenu lui-même restera probablement chiffré
Pour une personne technique, cela aurait dû être assez évident, mais c’est une bonne introduction au réseau et aux VPN. J’ai configuré plusieurs fois des VM Linux servant de passerelle VPN, et une architecture qui repose uniquement sur la table de routage m’a toujours semblé fragile, surtout quand elle s’exécute sur la même machine que celle qui utilise cette connexion
En plus des namespaces réseau et des routeurs passerelles VPN physiques, une architecture basée sur des VM peut aussi résoudre ce problème. Dans mon homelab, le pare-feu bloque le trafic inattendu provenant de la VM passerelle VPN. Les appareils du VLAN VPN ne peuvent pas se connecter directement à l’extérieur, et la VM passerelle dispose d’un VLAN séparé pour les connexions externes
Comme solution personnelle, QubesOS permet de mettre en place une configuration similaire avec assez peu de friction, mais cela demande tout de même plus de connaissances techniques qu’un OS généraliste
Le passage disant qu’« Android est le seul à ne pas être affecté, car il n’a pas implémenté la prise en charge de l’option DHCP 121 » est intéressant
Je me demande si Google connaissait ce problème et a pris cette décision délibérément, ou si c’était entièrement un hasard
Si je devais spéculer, l’équipe réseau d’Android est très favorable à IPv6. Elle ne semble pas très intéressée par les fonctionnalités de niche manquantes d’IPv4. Elle a aussi une vision assez précise de la façon dont IPv6 doit être utilisé, ce qui conduit à ne pas prendre en charge volontairement certaines fonctions comme DHCPv6 avec état
Cette option DHCP n’étant pas couramment utilisée, une telle stratégie aurait très probablement conduit à ne pas la prendre en charge, indépendamment des considérations de sécurité
Ce n’est donc pas vraiment surprenant