Faille concernant tous les VPN.

[Mackguil]

By design, the DHCP protocol does not authenticate messages, including for example the classless static route option (121). An attacker with the ability to send DHCP messages can manipulate routes to redirect VPN traffic, allowing the attacker to read, disrupt, or possibly modify network traffic that was expected to be protected by the VPN. Many, if not most VPN systems based on IP routing are susceptible to such attacks.

Source: https://nvd.nist.gov/vuln/detail/CVE-2024-3661

[solar10]

C'est pas neuf. Si!? Ou c'est DNS qui a le même genre de faille ?

[Unix-Linux]

C'est pas neuf. Si!?

This vulnerability is currently awaiting analysis.
Many, if not most VPN systems based on IP routing are susceptible to such attacks.


Détails :

Recently, we identified a novel network technique that bypasses VPN encapsulation. An attacker can use this technique to force a target user’s traffic off their VPN tunnel using built-in features of DHCP (Dynamic Host Configuration Protocol). The result of this is the user transmits packets that are never encrypted by a VPN, and an attacker can snoop their traffic. We are using the term decloaking to refer to this effect.

TunnelVision (CVE-2024-3661): How Attackers Can Decloak Routing-Based VPNs For a Total VPN Leak

Enfin, ici, c'est pas grave car le VPN du forum est pas cher et en plus il est pas à notre nom

[eric]

Toujours éviter les réseaux publics, même avec un VPN.
Les volumes data des abonnements mobiles permettent largement d'utiliser le partage de connexion à la place, tant qu'il s'agit d'un usage ponctuel.
Plus problématique en voyage hors UE, faute de roaming inclus, dans des pays moins démocratiques...

[Mackguil]

Toujours éviter les réseaux publics, même avec un VPN.

Why ?

[solar10]

Le DPI ça existe toujours.

[Mackguil]

Le DPI ça existe toujours.

J'ai loupé un truc ?

[solar10]

Tu ne sais jamais ce qui tourne derrière un réseau public. Surtout dans les hotels et aéroports.
Quand on a un représentant qui part dans un pays moins démocratique, on lui fourni un laptop clean et un phone clean aussi. Techniquement, il part en slip. On lui fourni même des sacs "Faraday". Et à son retour, c'est reformatage complet de la machine.

[grumeur]

OUI...mais
A priori si je me connecte à un VPN, sauf l'envoi de ma clé "publique" tout le trafic est raisonnablement protégé.

Celui qui copie ma clé publique, ne peut pas l'utiliser (en captant le trafic) car il lui faut ma clé privée pour lire le retour.
Si ma communication est détournée par une usurpation d'adresse (dns), je peux me retrouver sur un site pirate.
Encore faut-il que ce site simule parfaitement celui que je voulais atteindre initialement.
A moins de me RE-demander mes mots de passe et de se faire passer pour "moi" ensuite, je ne vois pas ce qui est possible.

Si je me trompe....merci de m'expliquer ce qui pourrait se passer avec ce type d'attaque

[Unix-Linux]

Il s'agit d'une nouvelle technique réseau qui contourne l’encapsulation VPN. Un attaquant peut utiliser cette technique pour forcer le trafic d'un utilisateur cible à quitter son tunnel VPN à l'aide des fonctionnalités intégrées de DHCP
Le résultat est que l’utilisateur transmet des paquets qui ne sont jamais cryptés par un VPN et qu’un attaquant peut espionner leur trafic.
Une route DHCP option 121 malveillante qui empêche le chiffrement du trafic par le processus VPN et le trafic transmis est en dehors du tunnel crypté du VPN

[grumeur]

je te lis et te remercie.
Ai-je bien compris la méthode:
Si l'utilisateur "A" veut aller sur le site "C" mais est dérouté (via son DNS) sur un site malveillant "B" (qui sait où A voudrait aller), le site "B" va créer une liaison criptée A<>B, la voir en clair et, à son tour, faire suivre par une liaison criptée B<>C .
Pour un VPN "classique" les clés sont fixes et connues à l'avance, par l'utilisateur et le VPN et donc "non interceptables" car non-échangées.
Le piratage doit donc se faire en aval du VPN qui lui devrait être en DHCP... ce qui doit être rare.

[Unix-Linux]

Non grumeur, ça n'a rien à voir avec le DNS, mai bien à propos du DHCP option 121

La technique, baptisée TunnelVision (CVE-2024-3661), a été découverte par le Leviathan Security Group. Cela revient en fait à dire qu’un utilisateur connecté à un réseau contrôlé par un agresseur court le risque que sa connexion soit espionnée via un VPN, alors qu’il lui semble être connecté en toute sécurité.

Quasiment tous les VPN sujets à une mise sous surveillance depuis des années déjà

[grumeur]

pour ceux qui s'intéressent
un complément d'explication par korben !

https://korben.info/tunnelvision-faille ... nnees.html

[knots]

Ouais, en fait le problème est lié au server DHCP sur lequel on se connecte, et pas directement au VPN.

Ce n'est pas juste pour une connexion internet par câble ou wifi dans les lieux publics, on aurait le même problème en 4G/5G si l'opérateur était malveillant ou qu'il y avait une cellule relais pirate.

Cela démontre encore une fois le côté bon enfant des premières technologies IP que nous utilisons toujours. Le réseau n'était pas pourri par les acteurs malveillants comme maintenant. Il faudrait probablement déterrer le DHCPSEC (de 1997...) et ré-évaluer les étapes de connexion au réseau pour les sécuriser (DHCPSEC, DNSSEC, MACSEC, IPSEC, etc). Que du xSEC quoi.
(pour le SECx, c'est sur un autre site :) )