Des chercheurs ont mis au point une attaque contre presque toutes les applications de réseau privé virtuel (VPN), qui les oblige à envoyer et à recevoir une partie ou la totalité du trafic en dehors du tunnel chiffré conçu pour le protéger contre l’espionnage ou la manipulation. L’attaque, baptisée TunnelVision, remet largement en question l’objectif et l’argument de vente principal des VPN, qui est d’encapsuler le trafic Internet entrant et sortant dans un tunnel chiffré et de masquer l’adresse IP de l’utilisateur. Les chercheurs estiment qu’elle affecte toutes les applications VPN lorsqu’elles sont connectées à un réseau hostile et qu’il n’existe aucun moyen de prévenir de telles attaques, sauf lorsque le VPN de l’utilisateur fonctionne sous Linux ou Android. Ils ont également déclaré que leur technique d'attaque était possible depuis 2002 et qu'elle avait peut-être déjà été découverte et utilisée depuis lors :
« Récemment, nous avons identifié une nouvelle technique de réseau 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 intégrées du protocole DHCP (Dynamic Host Configuration Protocol). Le résultat est que l'utilisateur transmet des paquets qui ne sont jamais chiffrés par un VPN, et qu'un hacker peut espionner son trafic. Nous utilisons le terme "decloaking" pour désigner cet effet. Il est important de noter que le canal de contrôle du VPN est maintenu, de sorte que les fonctions telles que les interrupteurs d'arrêt ne sont jamais déclenchées, et que les utilisateurs continuent d'apparaître comme connectés à un VPN dans tous les cas que nous avons observés.
« Nous avons passé beaucoup de temps à étudier cette possibilité et à essayer d'informer le plus grand nombre possible de parties concernées. Nous savons également qu'il est de notre responsabilité, en tant que chercheurs en sécurité, d'informer la communauté de la sécurité et de la protection de la vie privée, ainsi que le grand public, de cette menace. Nous pensons également que cette technique pourrait avoir été possible dès 2002 et qu'elle pourrait avoir déjà été découverte (nous avons été informés que des références à ce comportement de "decloaking" ont été faites sur les médias 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 utilisée 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 système d'exploitation, chaque administrateur de VPN auto-hébergé et chaque utilisateur de VPN dépasse de loin les capacités de notre petite équipe de recherche ».
Le fonctionnement de TunnelVision est expliqué dans une démonstration vidéo
« Le trafic de la victime est maintenant démasqué et acheminé directement par l’attaquant. L’attaquant 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 réseau local. Un paramètre connu sous le nom d'option 121 permet au serveur DHCP d'outrepasser les règles de routage par défaut 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 détourne les données vers le serveur DHCP lui-même. Les chercheurs de Leviathan Security ont expliqué :
« Notre technique consiste à exécuter un serveur DHCP sur le même réseau que l'utilisateur VPN ciblé et à configurer notre configuration DHCP pour qu'elle s'utilise elle-même comme passerelle. Lorsque le trafic atteint notre passerelle, nous utilisons des règles de transfert de trafic sur le serveur DHCP pour faire passer le trafic vers une passerelle légitime pendant que nous l'espionnons.
« Nous utilisons 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. En imposant des routes plus spécifiques que la plage CIDR /0 utilisée par la plupart des VPN, nous pouvons établir des règles de routage plus prioritaires que les routes de l'interface virtuelle 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éfinie 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 l'interface virtuelle du VPN, mais transmis par l'interface réseau qui parle au serveur DHCP. En tant qu'attaquant, nous pouvons sélectionner les adresses IP qui passent par le tunnel et celles qui passent par l'interface réseau qui communique avec notre serveur DHCP.
« Le trafic est maintenant transmis en dehors du tunnel chiffré du VPN. Cette technique peut également être utilisée contre une connexion VPN déjà établie lorsque l'hôte de l'utilisateur VPN doit renouveler un bail auprès de notre serveur DHCP. 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. En outre, 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 ».
L'attaque peut être menée de la manière la plus efficace par une personne qui dispose d'un contrôle administratif sur le réseau auquel la cible se connecte. Dans ce scénario, 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 réseau en tant qu'utilisateur non privilégié d'effectuer l'attaque en configurant leur propre serveur DHCP malveillant.
Atténuations
Règles 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 règles de pare-feu. Une exception a été nécessaire pour les IP des serveurs DHCP et VPN, car elles sont nécessaires pour rester connecté au réseau 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 affectées.
Problèmes liés à l'atténuation des règles de pare-feu
Les mesures d'atténuation des pare-feux créent un déni de service sélectif pour le trafic utilisant la route DHCP et introduisent un canal latéral. Un attaquant peut utiliser ce canal latéral pour déterminer la destination du trafic. Pour déterminer 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 référence 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 différence 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'inconvénient est que l'option 121 existe pour une raison, et ignorer ces routes peut rompre la connectivité du réseau (ce qui est souvent évoqué comme une raison de l'implémenter sur Android). 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.
Utiliser un hot spot ou une VM
Les hot spots sont des réseaux Wi-Fi temporaires contrôlés par un appareil cellulaire. Ils créent un réseau local verrouillé par mot de passe avec traduction automatique de l'adresse réseau. Étant donné que ce réseau est entièrement contrôlé par l'appareil cellulaire et qu'il nécessite un mot de passe, un pirate ne devrait pas avoir accès au réseau local. Une machine virtuelle fonctionnerait également de la même manière tant que l'adaptateur réseau de la machine virtuelle n'est pas en mode ponté.
N'utilisez pas de réseaux non fiables si vous avez besoin d'une confidentialité absolue de votre trafic
Source : résultats des chercheurs
Et vous ?
Quelle est votre réaction initiale à la découverte de l’attaque TunnelVision contre les VPN ? Comment cette vulnérabilité affecte-t-elle votre confiance dans l’utilisation des VPN pour la sécurité en ligne ? Quelles mesures pensez-vous que les développeurs de VPN devraient prendre pour protéger leurs utilisateurs contre de telles attaques ? Est-ce que l’immunité d’Android contre cette attaque vous inciterait à changer de système d’exploitation pour vos activités en ligne ? Comment les entreprises peuvent-elles se prémunir contre les failles de sécurité qui existent depuis longtemps mais qui sont seulement récemment exploitées ? Quel rôle les utilisateurs doivent-ils jouer dans la protection de leur propre sécurité en ligne face à de telles vulnérabilités ? 
Envoyé par foxzoolm
