Des chercheurs ont mis au point une attaque contre presque toutes les applications de rseau priv virtuel (VPN), qui les oblige envoyer et recevoir une partie ou la totalit du trafic en dehors du tunnel chiffr conu pour le protger contre lespionnage ou la manipulation. Lattaque, baptise TunnelVision, remet largement en question lobjectif et largument de vente principal des VPN, qui est dencapsuler le trafic Internet entrant et sortant dans un tunnel chiffr et de masquer ladresse IP de lutilisateur.
Les chercheurs estiment quelle affecte toutes les applications VPN lorsquelles sont connectes un rseau hostile et quil nexiste aucun moyen de prvenir de telles attaques, sauf lorsque le VPN de lutilisateur fonctionne sous Linux ou Android. Ils ont galement dclar que leur technique d’attaque tait possible depuis 2002 et qu’elle avait peut-tre dj t dcouverte et utilise depuis lors :
Rcemment, nous avons identifi une nouvelle technique de rseau qui contourne l’encapsulation VPN. Un hacker peut utiliser cette technique pour forcer le trafic d’un utilisateur cible quitter son tunnel VPN en utilisant les fonctions intgres du protocole DHCP (Dynamic Host Configuration Protocol). Le rsultat est que l’utilisateur transmet des paquets qui ne sont jamais chiffrs par un VPN, et qu’un hacker peut espionner son trafic. Nous utilisons le terme « decloaking » pour dsigner cet effet. Il est important de noter que le canal de contrle du VPN est maintenu, de sorte que les fonctions telles que les interrupteurs d’arrt ne sont jamais dclenches, et que les utilisateurs continuent d’apparatre comme connects un VPN dans tous les cas que nous avons observs.
Nous avons pass beaucoup de temps tudier cette possibilit et essayer d’informer le plus grand nombre possible de parties concernes. Nous savons galement qu’il est de notre responsabilit, en tant que chercheurs en scurit, d’informer la communaut de la scurit et de la protection de la vie prive, ainsi que le grand public, de cette menace. Nous pensons galement que cette technique pourrait avoir t possible ds 2002 et qu’elle pourrait avoir dj t dcouverte (nous avons t informs que des rfrences ce comportement de « decloaking » ont t faites sur les mdias sociaux. Cela montre une fois de plus qu’il est important d’informer le public en dehors du secteur technologique de l’existence de notre technique) et potentiellement utilise dans la nature. C’est pourquoi nous pensons qu’il est essentiel pour nous de la divulguer publiquement, car notifier chaque fournisseur de VPN, chaque responsable de systme d’exploitation, chaque administrateur de VPN auto-hberg et chaque utilisateur de VPN dpasse de loin les capacits de notre petite quipe de recherche .
Le fonctionnement de TunnelVision est expliqu dans une dmonstration vido
Le trafic de la victime est maintenant dmasqu et achemin directement par lattaquant. Lattaquant peut lire, supprimer ou modifier le trafic qui fuite, et la victime maintient sa connexion la fois au VPN et Internet , expliquent les chercheurs.
L’attaque fonctionne en manipulant le serveur DHCP qui attribue les adresses IP aux appareils qui tentent de se connecter au rseau local. Un paramtre connu sous le nom d’option 121 permet au serveur DHCP d’outrepasser les rgles de routage par dfaut qui envoient le trafic VPN via une adresse IP locale qui initie le tunnel chiffr. En utilisant l’option 121 pour acheminer le trafic VPN via le serveur DHCP, l’attaque dtourne les donnes vers le serveur DHCP lui-mme. Les chercheurs de Leviathan Security ont expliqu :
Notre technique consiste excuter un serveur DHCP sur le mme rseau que l’utilisateur VPN cibl et configurer notre configuration DHCP pour qu’elle s’utilise elle-mme comme passerelle. Lorsque le trafic atteint notre passerelle, nous utilisons des rgles de transfert de trafic sur le serveur DHCP pour faire passer le trafic vers une passerelle lgitime pendant que nous l’espionnons.
Nous utilisons l’option 121 du DHCP pour dfinir une route dans la table de routage de l’utilisateur du VPN. La route que nous dfinissons est arbitraire et nous pouvons galement dfinir plusieurs routes si ncessaire. En imposant des routes plus spcifiques que la plage CIDR /0 utilise par la plupart des VPN, nous pouvons tablir des rgles de routage plus prioritaires que les routes de l’interface virtuelle cre par le VPN. Nous pouvons dfinir plusieurs routes /1 pour recrer la rgle 0.0.0.0/0 pour tout le trafic dfinie par la plupart des VPN.
Pousser une route signifie galement que le trafic rseau sera envoy sur la mme interface que le serveur DHCP au lieu de l’interface rseau virtuelle. Il s’agit d’une fonctionnalit prvue qui n’est pas clairement indique dans le RFC. Par consquent, pour les routes que nous poussons, le trafic n’est jamais chiffr par l’interface virtuelle du VPN, mais transmis par l’interface rseau qui parle au serveur DHCP. En tant qu’attaquant, nous pouvons slectionner les adresses IP qui passent par le tunnel et celles qui passent par l’interface rseau qui communique avec notre serveur DHCP.
Le trafic est maintenant transmis en dehors du tunnel chiffr du VPN. Cette technique peut galement tre utilise contre une connexion VPN dj tablie lorsque l’hte de l’utilisateur VPN doit renouveler un bail auprs de notre serveur DHCP. Nous pouvons crer artificiellement ce scnario en fixant une courte dure de bail dans le bail DHCP, de sorte que l’utilisateur mette jour sa table de routage plus frquemment. En outre, le canal de contrle du VPN reste intact car il utilise dj 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 .
L’attaque peut tre mene de la manire la plus efficace par une personne qui dispose d’un contrle administratif sur le rseau auquel la cible se connecte. Dans ce scnario, l’attaquant configure le serveur DHCP pour qu’il utilise l’option 121. Il est galement possible pour les personnes qui peuvent se connecter au rseau en tant qu’utilisateur non privilgi d’effectuer l’attaque en configurant leur propre serveur DHCP malveillant.
Attnuations
Rgles de pare-feu
Nous avons observ des fournisseurs de VPN qui refusaient tout trafic entrant et sortant vers et depuis l’interface physique via des rgles de pare-feu. Une exception a t ncessaire pour les IP des serveurs DHCP et VPN, car elles sont ncessaires pour rester connect au rseau local et au serveur VPN. L’inspection approfondie des paquets pourrait galement n’autoriser que les protocoles DHCP et VPN, mais les performances en seraient probablement affectes.
Problmes lis l’attnuation des rgles de pare-feu
Les mesures d’attnuation des pare-feux crent un dni de service slectif pour le trafic utilisant la route DHCP et introduisent un canal latral. Un attaquant peut utiliser ce canal latral pour dterminer la destination du trafic. Pour dterminer la destination du trafic, un pirate pourrait effectuer une analyse du volume de trafic crypt VPN envoy par un utilisateur. L’attaquant aurait besoin d’un volume de trafic de rfrence o aucun logiciel malveillant n’est install. Ensuite, il devra modifier la configuration du bail pour installer des routes qui refusent le trafic et observer la diffrence de volume.
Ignorer l’option 121
Une autre solution possible consiste ignorer l’option 121 lorsque le VPN est activ. Nous avons not qu’Android ne prenant pas en charge l’option 121 du DHCP, il n’tait pas affect. L’inconvnient est que l’option 121 existe pour une raison, et ignorer ces routes peut rompre la connectivit du rseau (ce qui est souvent voqu comme une raison de l’implmenter sur Android). Si cette mesure d’attnuation est mise en uvre, elle doit tre obligatoire, car les attaquants pourraient simplement refuser l’accs au rseau jusqu’ ce que le VPN ou l’utilisateur ractive l’option 121.
Utiliser un hot spot ou une VM
Les hot spots sont des rseaux Wi-Fi temporaires contrls par un appareil cellulaire. Ils crent un rseau local verrouill par mot de passe avec traduction automatique de l’adresse rseau. tant donn que ce rseau est entirement contrl par l’appareil cellulaire et qu’il ncessite un mot de passe, un pirate ne devrait pas avoir accs au rseau local. Une machine virtuelle fonctionnerait galement de la mme manire tant que l’adaptateur rseau de la machine virtuelle n’est pas en mode pont.
N’utilisez pas de rseaux non fiables si vous avez besoin d’une confidentialit absolue de votre trafic
Source : rsultats des chercheurs
Et vous ?
Quelle est votre raction initiale la dcouverte de lattaque TunnelVision contre les VPN ?
Comment cette vulnrabilit affecte-t-elle votre confiance dans lutilisation des VPN pour la scurit en ligne ?
Quelles mesures pensez-vous que les dveloppeurs de VPN devraient prendre pour protger leurs utilisateurs contre de telles attaques ?
Est-ce que limmunit dAndroid contre cette attaque vous inciterait changer de systme dexploitation pour vos activits en ligne ?
Comment les entreprises peuvent-elles se prmunir contre les failles de scurit qui existent depuis longtemps mais qui sont seulement rcemment exploites ?
Quel rle les utilisateurs doivent-ils jouer dans la protection de leur propre scurit en ligne face de telles vulnrabilits ?