IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Mars 2013
    Messages
    8 522
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Mars 2013
    Messages : 8 522
    Points : 199 060
    Points
    199 060
    Par défaut Sécurité en ligne compromise : une attaque inédite menace la sécurité de presque toutes les applications VPN
    Sécurité en ligne compromise : une attaque inédite menace la sécurité de presque toutes les applications VPN
    et remet en question leur utilité fondamentale

    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 ».

    Nom : vpn.png
Affichages : 170996
Taille : 37,5 Ko

    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 ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre habitué
    Profil pro
    Inscrit en
    Août 2006
    Messages
    80
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2006
    Messages : 80
    Points : 127
    Points
    127
    Par défaut
    a part le DNS (et encore)... il y a quoi comme protocole qui ne soit pas chiffré de nos jours ?
    c'est bien tu as enlevé la couche VPN et donc ?
    il te reste la couche HTTPS (TLS ou SSL).

    Ceux qui pensent qu'un VPN rendent le adresse IP anonyme se foutent le doigt dans l'oeil jusqu'au coude...

  3. #3
    Expert éminent Avatar de kain_tn
    Homme Profil pro
    Inscrit en
    Mars 2005
    Messages
    1 578
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations forums :
    Inscription : Mars 2005
    Messages : 1 578
    Points : 7 355
    Points
    7 355
    Par défaut
    Citation Envoyé par foxzoolm Voir le message
    a part le DNS (et encore)... il y a quoi comme protocole qui ne soit pas chiffré de nos jours ?
    c'est bien tu as enlevé la couche VPN et donc ?
    il te reste la couche HTTPS (TLS ou SSL).

    Ceux qui pensent qu'un VPN rendent le adresse IP anonyme se foutent le doigt dans l'oeil jusqu'au coude...
    Tu devrais lire l'article original: il est très bien expliqué.
    Le principal souci est que tu routes des paquets des couches OSI inférieures, et donc que tu rends la machine attaquable, depuis cette liaison VPN non chiffrée.
    Copier c'est copier; voler c'est vendre un CD une vingtaine d'euros!


    Code C : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    #include <stdio.h>
     
    int main(int argc, char **argv) {
     
        printf("So long, and thanks for the fish, Dennis...\n");
        return 0;
    }

Discussions similaires

  1. [XL-2010] Maintenir une userbox au-dessus de toutes les applications actives
    Par Reaverman dans le forum Macros et VBA Excel
    Réponses: 6
    Dernier message: 18/08/2018, 09h42
  2. .NET Standard : une couche de base unique pour toutes les applications .NET
    Par Hinault Romaric dans le forum Général Dotnet
    Réponses: 22
    Dernier message: 21/10/2016, 13h37
  3. Réponses: 2
    Dernier message: 14/05/2012, 17h35
  4. Réponses: 11
    Dernier message: 05/04/2010, 22h10
  5. Réponses: 7
    Dernier message: 26/06/2007, 20h00

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo