La société de sécurité Perfect Privacy a averti hier dans un billet de blog que bon nombre de solutions VPN étaient vulnérables à des attaques par redirection de port. De fait, une bonne partie des utilisateurs pourraient voir leurs adresses IP réelles être dévoilées par des pirates utilisant les mêmes réseaux.
Les VPN, ou réseaux privés virtuels, sont conçus pour permettre l'accès à des ordinateurs distants. Ils sont également souvent utilisés pour masquer les adresses IP d'origine. Mais il n’est finalement pas très compliqué d’obtenir quand même cette information, surtout quand les solutions existantes autorisent la redirection de port et qu’elles ne sont protégées contre des attaques utilisant cette fonctionnalité.
La faille « VPN Fail »
Hier, la société Perfect Privacy a averti qu’un grand nombre de solutions VPN pouvaient révéler ces adresses IP si un pirate savait où chercher. Pour que l’attaque fonctionne, il doit se trouver sur le même réseau virtuel que sa victime et connaître son adresse IP de sortie. Comme l’indique The Hacker News, cette étape est assez simple puisqu’il suffit d’attirer l’utilisateur sur un site évidemment contrôlé par le pirate. Si la redirection de port est activée, le pirate pourra obtenir l’adresse IP réelle de la victime en l’amenant à ouvrir par exemple une image. À partir de là, il devient possible de rediriger le trafic vers un port là encore contrôlé par le pirate, d’où le nom de l’attaque.
Cette faille de sécurité, nommée « VPN Fail » par Perfect Privacy, a donné lieu à un avertissement lancé à de nombreux éditeurs. La plupart sont donc informés et le tir a été corrigé pour des solutions comme Private Internet Access, Ovpn.to et nVPN. Ce dernier est pour le moment le seul à avoir confirmé officiellement que c'était le cas, comme en atteste le tweet ci-dessous. Perfect Privacy indique cependant que toutes les solutions n’ont pas été testées et que le nombre de produits vulnérables est donc sans doute important.
Clients VPN, systèmes d'exploitation, BitTorrent
La faille pose évidemment un vrai problème de sécurité et de vie privée. Les VPN sont très utilisés dans les pays par exemple où la censure est importante, notamment parce qu’ils bloquent le repérage de la géolocalisation. En conséquence, une faille qui laisserait apparaître la véritable adresse IP ne peut que briser tout l’intérêt de ces solutions et on peut espérer que des correctifs seront rapidement déployés.
La dangerosité de la faille est grande selon Perfect Privacy, puisqu’à cause de la nature même de la faille, on risque de la retrouver dans un très grand nombre de produits, dont les systèmes d’exploitation. Elle peut également être utilisée pour piéger des internautes qui se serviraient de BitTorrent. La technique s’exploite d’ailleurs plus rapidement puisque le pirate n’a pas besoin d’amener l’utilisateur sur un site. Il doit simplement se trouver sur le même VPN et avoir activé la redirection de port.
Fixed a possibility to exploit a VPNs PF feature revealing a user's real IP https://t.co/1XJ7zqj70m Thanks for early notice @perfectprivacy
— nVpn.net (@nVpnNet) 27 Novembre 2015
Rien à faire pour l'instant du côté de l'utilisateur
Dans tous les cas, la victime n’a pas besoin d’avoir l’option activée, et il n’y a donc rien qu’elle puisse faire de son côté. Tous les protocoles liés au VPN, comme OpenVPN et IPSec, sont également concernés. La seule solution est actuellement d’attendre, jusqu’à recevoir une notification de son fournisseur de solution VPN, si bien entendu ce dernier prend la peine de communiquer.
On notera enfin que, dans le cadre de son programme de primes de sécurité, la société Private Internet Access a récompensé la découverte de Perfect Privacy par 5 000 dollars.
Commentaires (40)
Les VPN, ou réseaux privés virtuels, sont conçus pour masquer l’adresse IP d’origine.
Ce n’est pas vraiment vrai, c’est juste une utilisation détournée de son but original, qui est pour rappel : “Virtual Private Network, est un système permettant de créer un lien direct entre des ordinateurs distants” (Wikipedia). En résumé le but original d’un VPN était de relier par exemple 2 réseaux d’entreprise…
Je suis allé un peu vite en besogne et ai remanié la phrase, merci 
" />
lapin compris.
" />
Normalement la connexion VPN force tout les connections à passer par elle (sauf si on s’est explicitement linké à une interface).
Le mec ouvre un port qui est commun aux utilisateurs utilisant le même serveur. Donc OpenVPN devient con est se connecte à ce port via l’interface qui a établi la connexion VPN ?!?!
Donc c’est un peu comme la faille IPV6 ou de n’importe quel client torrent qui se lie à chaque interface (qBittorrent donne la possibilité de se lié à une seule interface).
Pour ceux qui ont un cerveau et qui ont toujours filtré les connexions via le VPN only il y a aucune raison pour que ça “fuite”.
Ou alors j’ai vraiment rien compris
perso j’appelle pas ça une faille
" />
Le VPN n’ayant pas été conçu pour masquer une adresse IP ( comme expliqué par Benjarobin ) je vois pas pourquoi on parle de faille
Mais bon … c’est sûr que pour l’utilisateur qui ne s’en servait que pour ça , c’est assez génant
Ce que je comprends :
Certains providers vpn permettent aux utilisateurs de définir un port forwarding (via une interface web) sur leur ip de sortie (1.2.3.4), qui va rediriger de manière statique par exemple le port 12345 vers leur machine (10.0.0.18 sur leur interface vitrtuelle). Ca permet à certains softs de mieux fonctionner (voire fonctionner tout court).
L’attaquant met en place une redirection du port 12345 vers sa machine. Ainsi toutes les connexions sur le port 12345 de l’ip 1.2.3.4 vont chez lui (10.0.0.18).
Si un autre utilisateur du même côté du VPN (10.0.0.42) que lui essaye d’y accéder, il ne va pas sortir par l’ip de sortie mais rester sur la partie privée du VPN, et la machine cible voit donc 10.0.0.42 en source.
Ce que je ne comprends pas :
L’attaquant devrait voir l’ip de l’interface virtuelle du client vpn, pas l’ip de l’interface publique.
Tous les softs de VPN que je connais permettent d’interdire aux machines du VPN de communiquer entre elles. Ce n’est pas activé par défaut (normal, un VPN sert à faire communiquer des machines entre elles à la base), et ils sont juste en train de dire qu’une partie des providers ne sont pas foutus de lire une doc (finalement ce point là je pense le comprendre).
Tu n’as que le début de bon, mais cela m’a permit de comprendre la chose. Je ne connaissais pas cette fonctionnalité de port forwarding des services VPN, c’est assez pratique, cela permet de fournir un accès à des services de sa machine (par exemple BT :-) )
Bref, sauf que les clients ne se voient pas, c’est là ton erreur. Il ne peuvent pas communiquer entre eux.
La personne qui se fait attaquer et qui va essayer d’accéder à 1.2.3.4:12345 va sortir via son IP de connexion normale et non l’IP du VPN (ce qui est normal, c’est la règle de routage nécessaire pour faire fonctionner le VPN).
En résumé lors de l’accès à 1.2.3.4:12345 le VPN n’est absolument pas utilisé, ce qui est normal. Le correctif doit être fait coté serveur
Par contre je ne comprend pas comment une simple règle de parfeu peut régler le problème sans créer d’effet de bord. Si tu as 2 PC derrière un NAT, un avec le VPN de configuré et l’autre sans, je ne vois pas comment ils arrivent à bloquer la connexion (à 1.2.3.4:12345) du premier PC et l’autoriser pour le second…
Évidemment, c’est pas con en fait.
Pour empêcher ça, suffit d’avoir une IP d’entrée dans le VPN différente de l’IP de sortie.
Apparemment Mullvad et Torguard auraient patché la faille depuis déjà plusieurs années, mais j’ai pas vérifié.
Hum, si tu as une IP d’entrée dans le VPN différente de l’IP de sortie, en effet tu pourras fournir l’accès à un serveur Web tournant sur ta machine, et il n’y aura plus de faille.
Mais je crains que certains services nécessitent d’avoir l’IP de sortie (vue publiquement) et l’IP d’entrée (le forwarding) identiques, par exemple BT (qui je pense est l’utilisation la plus courante du port forwarding)
Sur perfect-privacy, ils indiquent des solutions
On Client connect set server side firewall rule to block access from Client real ip to portforwardings that are not his own.
Sauf que s’ils font cela, cela à des effets de bord, comme expliqué au dessus…
La grosse bouse c’est qu’un VPN public autorise le “port forwarding” en réalité !..
Quelqu’un le dit à Free d’ailleurs ? Qu’ils analysent si ça leur semble une faille ou pas. A mon sens non, puisque ceux qui font ça maîtrisent l’intégralité de leur réseau.
Et du reste, ne pas faire ça sur un serveur public est évidemment de l’inconscience.
En gros, ces deux règles disent :
-(règle 1) j’autorise l’udp sur 1194 vers 1.2.3.4 (c’est à dire OpenVPN en UDP sur 1194 vers mon fournisseur VPN)
-(règle 2) tout autre trafic vers ce fournisseur est interdit.
Et du coup le petit malin qui veut vous faire afficher une image qui réside à 1.2.3.4:12345 (en TCP donc), eh bien vos règles l’interdisent, il n’aura donc rien…. et vous ne verrez bien sûr pas d’image !
Bien sûr, cela vous interdit aussi de faire du BT avec un “voisin de VPN” qui aurait ouvert ses ports pour être en “HighID”… mais vous faites encore du BT ?
Bref… dire “il n’y a rien à faire” est visiblement faux.
Après, que certain O.S. grand public ne soient pas capables de gérer des règles de filtrage de la sorte, je veux bien le croire… mais dans ce cas il faut utiliser un O.S. sérieux.
Je ne vois pas pourquoi, c’est le fonctionnement classique d’un NAT :p
Et aussi pour être complet… il faut aussi mettre un règle pour bloquer tous les INPUTs depuis votre fournisseur VPN qui ne soit pas de l’UDP provenant du 1194.
Ainsi, si le fournisseur tente de pénétrer sur votre machine, de façon mal-intentionné, ou parce qu’il a été “hacké”… eh bien cela l’empêchera.
Par contre, dans ce cas, si vous utilisez vous même des port-forward, il faut évidemment ouvrir les INPUTs correspondants !
Je n’ai rien contre BT, c’était une partie à lire au second degré !..
" />
" />
Et bien évidemment, c’est très certainement LA fonctionnalité recherchée qui pousse au port-forward. Parce que héberger son serveur Web derrière un VPN pour le “cacher”, c’est juste une grosse blague. Si les “autorités” veulent savoir, elle n’ont qu’à aller demander au fournisseur VPN… et en ce moment elles n’ont même pas besoin de juge : il suffit d’entrer en défonçant la porte et piquer les infos.
… mais bon, il y en a encore qui croient qu’un fournisseur de VPN les cache !..
En réalité ça déplace juste la “confiance” depuis votre FAI vers votre fournisseur VPN. Et ça complique juste un petit peu si le VPN est à l’étranger.
BT est par exemple utilisé très “officiellement” par le client de mise à jour Blizzard pour WoW, et aussi pour télécharger toutes vos ISO de Linux n’est-ce pas.
réponse intéressante de airvpn
 https://airvpn.org/topic/16129-ip-leak-affecting-vpn-providers-with-port-forward… (le post #4)
5 000 dollars 
" />
Est-ce qu’il ne suffirait pas côté client de n’avoir la route vers le serveur VPN que pour le processus gérant le VPN (processus openvpn par ex).
Ainsi toute connexion provenant d’un autre programme utilisera forcément le VPN, quelle que soit l’adresse de destination (sauf vers le LAN bien sûr).
Sous Linux il y a plusieurs façons de faire ça :
Tu as raison, effectivement, l’O.S. le plus grand public, car le plus utilisé au monde : [Android], comprend bien iptables (depuis le kernel Linux 2.6.29 et au delà), mais dans sa version courante non-rootée, l’utilisateur ne peut pas le faire tourner puisque ça réclame des privilèges root.
Pas nécessairement toutes les connexions, non.
Ex : je peux me connecter au réseau de ma boîte via un VPN; Toutes la plage d’adresses de l’entreprise passe par le VPN, le reste (notamment le web, mon client web) passe par ma connexion en direct.
Ah ok, je n’avais pas compris le but de la suggestion, désolé !
… mais ça reste un bon exercice de jouer avec le marques iptables et les tables de routage, on comprend plein de trucs pas faciles… et ce n’est pas aisé à mettre en place également !
Si je comprend bien, des fournisseurs de VPN mettent tous leurs clients sur le même VPN, du coup les clients peuvent voir leurs adresses IP entre eux. Au lieu de faire un VPN par client.
" />
C’est ça ou j’ai rien compris ?
Ca existe encore les iso ???? C’est pas install by cloud only ?
Ce n’est pas exactement ça : tu peux tout à fait te parler entre clients du VPN en utilisant l’IP interne au VPN fournie par le serveur, ça ne révèle rien !
En fait il faut en plus la “redirection”, et que le client qui parle n’ait pas les règles firewall (iptables ou selon) indiquées plus haut. Sinon, sur OpenVPN par exemple, le mode client to client utilise bien les IP allouées par le VPN.
Je conçois la vulgarisation, c’est parfait pour expliquer !
Mais comme le disait un internaute plus haut en réponse à un de mes commentaires au second degré, ne nous voilons pas la face, la plupart des ventes de VPN sont pour des gens qui veulent faire du BT. Par conséquent, ils ont besoin de rediriger les ports pour être en “High ID”. Si tu es fournisseur de VPN et que tu ne proposes pas ça, en gros tu es “hors marché” vu l’usage commun de la chose.
Donc on ne peut pas vraiment dire “mauvais usage” en réalité, puisque c’est ce que les clients veulent.
Maintenant, en dehors de toute protection de base des clients (que je suggère), il y a des mesures à prendre côté serveur pour parer la faille.
Certaines de ces mesures sont indiquées dans le lien sur l’article. J’opérerais un VPN, j’imaginerais par exemple une règle à la connexion des clients pour exclure leurs IP des redirections chez les autres. C’est pas trop dur à faire sur un OpenVPN par exemple puisqu’il te permet de lancer des scripts à plusieurs moments clé, dont connexion/déconnexion d’un client.
Ainsi, si tu exclus les IP de tes clients de la redirection programmée par un autre, même si le “piège” décrit est mis en place, les iptables sur le serveur bloqueront le flux et tu n’as plus de “faille”.
Ne nous voilons pas la face ? Non mais le VPN est une technologie largement exploitée par les entreprises depuis des années
" />
Il y a surement bien d’utilisation de VPN “légal” que tu ne sembles le croire… Accès à distance sécurisé, interconnexion de site distants, cloud… bref.
Le VPN c’est “virtual private network” , l’exploitation de VPN pour ce cacher c’est une dérive. Et oui le VPN peut servir à çà.
Totalement d’accord avec toi !
" />
Du reste j’ai mon propre VPN, le serveur est ma Synology, plus les postes que j’ai enrôlés moi même sur ma PKI. Sur ce VPN je ne fais que des échanges comme ceux que tu cites.
Quant aux VPN business, en général c’est ton entreprise qui héberge le serveur… et oui, c’est utilisé pour tout ce qui est télétravail, ou simplement quand ton entreprise te confie un PC pour que tu puisses par exemple consulter tes mails professionnels tout en étant branché sur ta ligne privée.
Mais on ne parle pas de la même chose là je pense… (enfin je n’affirme rien n’étant pas client moi-même !)