Vous pensez que les méthodes d’authentification modernes comme FIDO2 vous protègent efficacement contre le vol de cookies et les attaques de l’homme du milieu (MITM) ? Détrompez-vous ! Une équipe de chercheurs vient de démontrer qu’il est possible de contourner ces protections en s’emparant des précieux sésames que sont les jetons de session.

Vous vous connectez tranquillement à votre appli préférée, en scannant votre empreinte digitale ou en insérant votre clé de sécurité dernier cri, vous vous sentez en sécurité, comme un petit bébé dans les bras de sa maman ou de son papa, protégé par la magie de FIDO2 (et de son absence de mots de passe).

Sauf que dans l’ombre, un vilain pirate que nous appellerons Vladimitch, a réussi à s’immiscer entre vous et le serveur, tel un cyber-ninja. Et là, c’est le drame : il intercepte le fameux jeton de session qui vous permet de rester connecté sans avoir à retaper vos identifiants à chaque clic. Ni vu ni connu, il peut alors se faire passer pour vous et accéder à votre compte !

Mais comment est-ce possible avec une authentification si robuste ? Eh bien figurez-vous que le problème ne vient pas de FIDO2 en lui-même, mais plutôt de la façon dont les applications gèrent les sessions après la phase d’authentification. Une fois que vous êtes connecté, c’est open bar, et votre jeton se balade joyeusement sur le réseau, sans trop de protection.

Les chercheurs ont mis en lumière cette faille en testant plusieurs implémentations de FIDO2, comme le bac à sable Yubico Playground, le système d’authentification unique (SSO) Entra ID de Microsoft ou encore l’adaptateur PingFederate. Et dans chaque cas, ils ont pu démontrer qu’un attaquant pouvait intercepter et réutiliser un jeton de session valide sans posséder la clé d’authentification FIDO2 associée.

Mais rassurez-vous, tout n’est pas perdu. Il existe une parade pour éviter de se faire dérober son précieux jeton : la « liaison de jeton » (ou token binding pour les anglophones). Concrètement, ça consiste à créer un lien indéfectible entre votre jeton de session et la connexion sécurisée (TLS) que vous utilisez. Comme ça, il devient impossible pour l’attaquant d’utiliser votre jeton sur une autre connexion. Malin !

Le hic, c’est que cette protection est encore peu répandue. Et à part Microsoft qui l’a intégrée sur Edge, les autres navigateurs et applications web traînent des pieds. Google a même fini par jeter l’éponge sur Chrome, faute d’adoption. Pourtant, cela pourrait éviter bien des déboires aux utilisateurs et des migraines aux administrateurs système mais que voulez-vous, entre la sécurité et la facilité, le cœur des développeurs balance !

Bref, restez vigilant car même une sécurisation FIDO2 n’est pas infaillible face à une attaque MITM bien pensée. Microsoft a réagi de son côté en introduisant une fonctionnalité de protection des jetons basée sur les modules de plateforme sécurisée (TPM) dans Windows, une variante de la « liaison de jeton ». Mais pour une adoption massive, il faudra que tous les acteurs jouent le jeu.

En attendant, les experts recommandent aux développeurs d’applications d’exiger la « liaison de jeton » sur les authentifications FIDO2 lorsque c’est possible, de limiter l’usage des jetons OIDC et SAML à une seule fois par authentification réussie, et surtout de bien comprendre les menaces pour concevoir des mécanismes d’authentification adaptés.

Et vous, en tant qu’utilisateur, c’est toujours la même chanson, à savoir, évitez de vous connecter à des hotspots Wi-Fi publics douteux, ne cliquez pas sur les liens louches, et méfiez-vous des plugins de navigateur exotiques.

Bref, un peu de jugeotte, comme toujours… Sur ce, bon développement à tous et may the force (4th) be with you ! (On l’a passé, c’était le 4 mai…)

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