TunnelVision : la faille qui fait sauter le VPN et détourne le trafic des données

[Violence]

Voici une info qui va vous faire voir les VPN sous un autre angle. Bah oui, parce que si vous pensiez que votre petit tunnel chiffré préféré vous mettait à l’abri des regards indiscrets quand vous surfez depuis un réseau public, désolé de casser vos rêves, mais c’est loin d’être le cas !

Une équipe de chercheurs de Leviathan Security a découvert une faille qu’ils ont baptisée TunnelVision qui permet de court-circuiter la protection des VPN à l’aiiise, grâce à une fonctionnalité bien pratique du protocole DHCP, ce bon vieux serviteur qui distribue des adresses IP à tout va.

En gros, quand vous vous connectez à un réseau, votre machine demande gentiment une adresse IP au serveur DHCP local. Jusque là, tout va bien. Sauf que ce protocole a plus d’un tour dans son sac. Il peut notamment pousser des règles de routage sur votre bécane, via une option peu connue appelée « Classless Static Route » ou option 121.

Concrètement, un attaquant qui contrôle le serveur DHCP peut installer des routes par défaut sur votre machine, ce qui lui permet de rediriger tout votre trafic vers sa propre passerelle, même si vous êtes connecté via un VPN ! Et là, c’est le drame, car il peut intercepter toutes vos données en clair.

Bon, rassurez-vous, il y a quand même quelques conditions pour que cette attaque fonctionne :

1. L’attaquant doit avoir un accès physique au réseau local ou être en mesure de compromettre un équipement sur ce réseau.
2. Le client VPN ne doit pas bloquer les sorties de trafic vers les interfaces réseau locales.

Mais quand même, ça fait froid dans le dos, d’autant que cette faille touche potentiellement tous les réseaux, des petits réseaux domestiques aux gros réseaux d’entreprise. Les chercheurs ont d’ailleurs réussi à l’exploiter sur Windows, macOS, iOS, Android, et même sur des distributions Linux.

Heureusement, il existe des parades pour se prémunir contre TunnelVision :

• Activer les fonctions de DHCP snooping et d’ARP protection sur les commutateurs réseau pour empêcher l’installation de serveurs DHCP non autorisés.
• Configurer des règles de pare-feu strictes pour bloquer le trafic non autorisé.
• Utiliser des protocoles de chiffrement comme HTTPS pour sécuriser les ressources internes.
• Implémenter une isolation réseau robuste via des fonctionnalités comme les espaces de noms réseau (network namespaces) sous Linux.

Les fournisseurs de VPN ont évidemment aussi un rôle à jouer en documentant publiquement les mesures d’atténuation contre TunnelVision et en avertissant leurs utilisateurs des risques.

Bref, en attendant un éventuel correctif, la prudence reste de mise. Mais en appliquant les bonnes pratiques et en restant vigilants, on peut quand même limiter les dégâts ! Si le sujet vous intéresse et que vous voulez aller plus loin, je vous invite à consulter le papier de recherche complet qui détaille le fonctionnement technique de TunnelVision. C’est un peu ardu, mais ça vaut le coup d’œil pour les plus motivés d’entre vous.

– Sources :

https://krebsonsecurity.com/2024/05/why-your-vpn-may-not-be-as-secure-as-it-claims/

https://korben.info/tunnelvision-faille-vpn-fuites-donnees.html

https://www.it-connect.fr/la-vulnerabilite-tunnelvision-affecte-tous-les-vpn-et-permet-de-detourner-le-trafic/

–> TunnelVision affecte tout les VPN, et tout les OS sauf Android. Pourquoi ? Et bien parce que l’option 121 du DHCP n’est pas prise en charge ! TunnelVision ne dépend pas du protocole VPN utilisé, donc il n’y a pas un protocole à prioriser plus qu’un autre (OpenVPN, IPsec, WireGuard, etc.)

[kemkem]

Il me semble que cet exploit est connu depuis très très longtemps. Leviathan Security vient surtout de découvrir pourquoi les killswitch existent. Pas mal pour une société de pentesting… lol Autant pour moi, ce ne sont pas les killswitch qui empèchent cet exploit mais les network namespaces (netns).

[Un Ancien Utilisateur]

Ouf android n’est pas touché c’est déjà ça

Vite les fournisseurs un patch

[7cf148fd]

Android est touché comme tout le monde.
Cela dit ça ne compromet aucun VPN qui sont imperméables à ce genre d’attaque MitM.

[Un Ancien Utilisateur]

@7cf148fd ça dit Que non En fin de post

[Un Ancien Utilisateur]

Bonjour !

Nos ingénieurs ont effectué une analyse approfondie de cette menace, l’ont reconstituée expérimentalement et l’ont testée sur Proton VPN.

Nous avons conclu que :

1. l’attaque ne peut être réalisée que si le réseau local lui-même est compromis
2. nos applications Windows et Android sont entièrement protégées contre cette attaque
3. pour les applications iOS et macOS, vous êtes complètement protégé contre cette attaque tant que vous utilisez un Kill Switch et un protocole basé sur WireGuard (nos applications utilisent WireGuard par défaut, et si un utilisateur veut utiliser autre chose que des dérivés de WireGuard, il devra le configurer manuellement). Notez que Stealth, WireGuard TCP, et notre protocole Smart sur iOS/macOS sont tous basés sur WireGuard.
4. pour notre application Linux, nous travaillons sur un correctif qui fournirait une protection complète contre ce problème.

En gros on risque pas grand chose, pour ce qui est des vpn low cost c’est peut être pas la même

[Violence]

Le lien stp @Ashura

[Un Ancien Utilisateur]

@Violence réponse sur reddit, je trouve plus le post

Edit ; https://www.reddit.com/r/ProtonVPN/s/QmOlwAD9os

[Magissia]

dhclient permet d’ignorer des options fournies par le serveur DHCP.
Sous Windows, il faut des règles de pare-feu drastiques pour refuser les paquets DHCP venant d’ip ne terminant pas en 1 ou 254 et espérer ne pas avoir de faux positifs sur des réseaux curieux.

Pour les administrateurs réseaux, à eux de filtrer les réponses DHCP qui ne proviennent pas de la bonne machine/port physique.

Enfin, le problème n’est pas nouveau.

[Magissia]

@7cf148fd Android ignore l’option 121, donc non affecté.