Voici une info qui va vous faire voir les VPN sous un autre angle. Bah oui, parce que si vous pensiez que votre petit tunnel chiffré préféré vous mettait à l’abri des regards indiscrets quand vous surfez depuis un réseau public, désolé de casser vos rêves, mais c’est loin d’être le cas !

Une équipe de chercheurs de Leviathan Security a découvert une faille qu’ils ont baptisée TunnelVision qui permet de court-circuiter la protection des VPN à l’aiiise, grâce à une fonctionnalité bien pratique du protocole DHCP, ce bon vieux serviteur qui distribue des adresses IP à tout va.

En gros, quand vous vous connectez à un réseau, votre machine demande gentiment une adresse IP au serveur DHCP local. Jusque là, tout va bien. Sauf que ce protocole a plus d’un tour dans son sac. Il peut notamment pousser des règles de routage sur votre bécane, via une option peu connue appelée « Classless Static Route » ou option 121.

Concrètement, un attaquant qui contrôle le serveur DHCP peut installer des routes par défaut sur votre machine, ce qui lui permet de rediriger tout votre trafic vers sa propre passerelle, même si vous êtes connecté via un VPN ! Et là, c’est le drame, car il peut intercepter toutes vos données en clair. 😱

Bon, rassurez-vous, il y a quand même quelques conditions pour que cette attaque fonctionne :

• 1. L’attaquant doit avoir un accès physique au réseau local ou être en mesure de compromettre un équipement sur ce réseau.
• 2. Le client VPN ne doit pas bloquer les sorties de trafic vers les interfaces réseau locales.

Mais quand même, ça fait froid dans le dos, d’autant que cette faille touche potentiellement tous les réseaux, des petits réseaux domestiques aux gros réseaux d’entreprise. Les chercheurs ont d’ailleurs réussi à l’exploiter sur Windows, macOS, iOS, Android, et même sur des distributions Linux.

Heureusement, il existe des parades pour se prémunir contre TunnelVision :

• Activer les fonctions de DHCP snooping et d’ARP protection sur les commutateurs réseau pour empêcher l’installation de serveurs DHCP non autorisés.
• Configurer des règles de pare-feu strictes pour bloquer le trafic non autorisé.
• Utiliser des protocoles de chiffrement comme HTTPS pour sécuriser les ressources internes.
• Implémenter une isolation réseau robuste via des fonctionnalités comme les espaces de noms réseau (network namespaces) sous Linux.

Les fournisseurs de VPN ont évidemment aussi un rôle à jouer en documentant publiquement les mesures d’atténuation contre TunnelVision et en avertissant leurs utilisateurs des risques.

Bref, en attendant un éventuel correctif, la prudence reste de mise. Mais en appliquant les bonnes pratiques et en restant vigilants, on peut quand même limiter les dégâts ! Si le sujet vous intéresse et que vous voulez aller plus loin, je vous invite à consulter le papier de recherche complet qui détaille le fonctionnement technique de TunnelVision. C’est un peu ardu, mais ça vaut le coup d’œil pour les plus motivés d’entre vous.

Source

Y’a un nouveau soft qui vient de sortir et qui va vous permettre de créer des tunnels réseau virtuellement inarrêtables, où que vous soyez dans le monde. Ça s’appelle onionpipe et ça utilise les adresses Onion de Tor pour faire transiter vos données de manière sécurisée et privée.

Imaginez un peu le truc : vous avez un service perso que vous voulez héberger chez vous mais votre FAI bloque les connexions entrantes ? Ou alors vous avez des clients qui sont derrière des pare-feu restrictifs type WiFi public ? Pas de souci, avec onionpipe votre service n’a pas besoin d’une IP publique pour être accessible ! Vous pouvez publier votre service avec une adresse onion unique et persistante, et donner l’accès de manière sécurisée seulement aux personnes de votre choix.

Le plus cool c’est que vous n’avez pas besoin de faire confiance et de filer vos données persos à des services payants type Tailscale ou ZeroTier. Avec onionpipe, vous gardez le contrôle total !

Concrètement, onionpipe c’est un peu comme socat mais pour les réseaux Tor. Ça met en place des tunnels de transfert de paquets pour faire des redirections de ports. Par exemple vous pouvez exposer le port local 8000 vers une adresse onion temporaire :

onionpipe 8000

Ou alors vers le port 80 d’une adresse onion temporaire en utilisant ~ comme raccourci :

onionpipe 8000~80

Vous pouvez même créer une adresse onion persistante avec un petit nom pour vous y retrouver :

onionpipe 8000~80@my-app

Et réutiliser ce nom dans plusieurs redirections pour faire référence à la même adresse onion. Tiens par exemple on pourrait monter un petit forum web pour un serveur Minecraft :

onionpipe 8000~80@minecraft 25565@minecraft

Toutes les redirections sans nom utilisent la même adresse onion temporaire :

onionpipe 192.168.1.100:8000~80,8080,9000 9090

Vous pouvez aussi exposer un socket Unix vers une adresse onion :

onionpipe /run/server.sock~80

Ou sacrifier un peu la confidentialité réseau contre une latence réduite en publiant un service onion non-anonyme :

onionpipe --anonymous=false 8000

Dans l’autre sens, vous pouvez rediriger le port 80 d’une adresse onion distante vers le port local 80 :

onionpipe xxx.onion:80

Ou vers le port 80 en écoute sur toutes les interfaces, pour exposer publiquement l’accès au service onion :

onionpipe xxx.onion:80~0.0.0.0:80

Pour aller plus loin dans la sécurisation de vos services persos, onionpipe gère aussi l’authentification client. En gros ça permet de n’autoriser l’accès qu’à une liste de clés publiques de votre choix.

Voilà comment ça marche :

Alice génère une nouvelle paire de clés d’authentification client

onionpipe client new alice

Puis Alice partage cette clé publique avec Bob, qui transmet un service en oignon qu’elle seule peut utiliser.

onionpipe --require-auth CLEPUBLIQUEALICE 8000~80@test

Alice utilise alors sa clé privée pour se connecter au service onion de Bob et le rediriger en local

onionpipe --auth alice ADRESSEONIONBOB:80~7000

Et voilà, un canal de communication privé et sécurisé entre Alice et Bob, sans passer par un serveur central 😉

Cerise sur le gâteau, ça s’intègre super facilement avec Docker ! Seule subtilité, comme c’est le conteneur qui fait la redirection, faut ajuster les adresses locales en conséquence. Pour rediriger le port 80 de l’hôte Docker :

docker run --rm ghcr.io/cmars/onionpipe:main host.docker.internal:80

Avec Podman vous pouvez carrément exposer le réseau de l’hôte local :

podman run --network=host --rm ghcr.io/cmars/onionpipe:main 8000

Et comme les adresses de redirection locales sont résolues par DNS, c’est ultra simple de publier des services onion depuis Docker Compose ou Kubernetes. Jetez un œil à cet exemple avec Nextcloud, c’est assez génial !

Merci à Lorenper

C’est l’heure de vous parler d’un nouveau truc pour contourner la censure sur Internet ! 🕶️

WebTunnel, ça vous dit quelque chose ?

C’est le nouveau joujou de l’équipe anti-censure de Tor Project. Ils l’ont sorti en grande pompe hier (le 12 mars), la journée mondiale contre la cyber-censure. Et devinez quoi ? C’est dispo direct dans la dernière version stable de Tor Browser ! 🥳

WebTunnel, c’est un nouveau type de bridge Tor conçu pour aider les internautes des pays où c’est la misère niveau liberté sur le web. Le principe est simple: ça imite du trafic web chiffré (HTTPS) pour se fondre dans la masse. Comme ça, pour les censeurs, ça ressemble juste à un internaute lambda qui surfe sur le web. Malin ! 😎

En gros, WebTunnel emballe la connexion dans une couche qui ressemble à du WebSocket over HTTPS. Du coup, ça passe crème. C’est inspiré d’un truc qui s’appelle HTTPT. Le plus fort, c’est que WebTunnel peut même cohabiter avec un vrai site web sur la même IP et le même port. Comme ça, si quelqu’un visite le site, il ne se doute de rien… Le bridge secret est bien planqué ! 😏

Concrètement, c’est une alternative aux bridges obfs4. L’avantage de WebTunnel, c’est qu’en imitant du trafic web classique et autorisé, il passe mieux dans les pays où il y a des listes blanches de protocoles (et tout le reste bloqué par défaut). C’est comme une pièce de monnaie qui rentre parfaitement dans la fente de la machine. Alors qu’un truc comme obfs4 qui ne ressemble à rien de connu, c’est direct dégagé ! ❌

Bon, et si vous voulez tester WebTunnel, comment on fait ?

Facile, il suffit de chopper un bridge sur le site dédié de Tor Project. Dans « Advanced Options », sélectionnez « webtunnel » dans le menu déroulant, et cliquez sur « Get Bridges », puis résolvez le captcha et copiez le bridge.

Ensuite, vous l’entrez dans les paramètres de Tor Browser (version desktop ou Android), en allant dans la fenêtre des préférences de connexion (ou cliquez sur « Configurer la connexion »). Il suffit de cliquez sur « Ajouter un bridge manuellement » et d’ajoutez le bridge copié précédemment.

Fermez la fenêtre et cliquez sur « Connecter » ! Et voilà !

Bref, WebTunnel c’est un nouvel outil dans l’arsenal de Tor pour contrer la censure et plus on en a, mieux c’est pour s’adapter et garder une longueur d’avance. À l’heure actuelle, il y a 60 bridges WebTunnel qui tournent un peu partout dans le monde, et plus de 700 utilisateurs quotidiens sur différentes plateformes. Ça marche bien en Chine et en Russie, par contre en Iran c’est plus compliqué pour le moment. 🌍

L’objectif, c’est que Tor soit accessible à tous, partout. Parce qu’avec tous les conflits géopolitiques actuels, Internet est devenu crucial pour communiquer, témoigner, s’organiser ou défendre les droits humains. C’est pour ça que la contribution des volontaires est essentielle.

Vous voulez aider ?

Il y a plein de façons de s’impliquer : faire tourner des bridges, des Snowflake proxies ou des relais Tor. C’est toujours ça de pris contre la censure et pour un Internet libre et sans entraves ! ✊