La page d'hameçonnage était la vraie page
Un kit nommé Bluekit ne construit plus un faux écran de connexion. Il vous diffuse le véritable, depuis un navigateur que l'attaquant contrôle, capture votre session à l'instant où vous vous connectez, et passe outre le MFA. Une passkey l'arrête là où un œil plus aiguisé pour les faux ne le peut pas — c'est pourquoi Bromure permet à un profil de ne partager que les passkeys de votre Mac.
Pendant vingt ans, vaincre l'hameçonnage signifiait apprendre à repérer le faux. Le browser-in-the-middle ne vous donne rien à repérer. Il vous montre la vraie page de connexion et vole votre session en direct pendant que vous regardez. Ce qui l'arrête, c'est un identifiant que vous ne pouvez pas recopier.
Vous recevez un message au sujet d'un document partagé, d'une connexion signalée, d'une facture. Vous cliquez. Une page de connexion Microsoft s'ouvre, et c'est la vraie : les bonnes polices, le bon logo, la petite animation quand vous passez d'un champ à l'autre, la véritable demande d'authentification multifacteur qui fait vibrer votre téléphone. Vous l'approuvez. Vous êtes connecté. Rien n'a semblé anormal, parce que presque rien ne l'était. La page sur laquelle vous avez tapé était la page de connexion de Microsoft. Ce n'est pas vous qui lui parliez.
Fin juin, Harry Everett de Netcraft a documenté un kit d'hameçonnage nommé Bluekit franchissant ce pas, et BleepingComputer en a parlé la même semaine. Bluekit se vend en tant que service : un kit d'hameçonnage hébergé avec des modèles pour Outlook, Gmail, iCloud, GitHub, et un portefeuille crypto ou deux, plus un assistant intégré pour rédiger l'e-mail d'appât. Sa nouvelle astuce porte un nom qui circule depuis qu'un chercheur connu sous le pseudonyme mr.d0x l'a décrite en 2022 : browser-in-the-middle.
La vraie page, diffusée jusqu'à vous.
L'hameçonnage à l'ancienne fabrique une contrefaçon. Quelqu'un clone la page de connexion, l'héberge sur un domaine sosie, et espère que vous ignorerez la barre d'adresse. La défense s'est construite autour de ça : repérer le faux, attraper la faute de frappe dans l'URL.
Un kit à proxy inverse comme Evilginx est venu ensuite. Il ne clone pas la page. Il se place au milieu de la connexion, un « adversary in the middle », et fait transiter votre trafic vers le vrai site, raclant le cookie de session au passage. (Ce cookie est le petit jeton qu'un site remet à votre navigateur après la connexion, pour cesser de vous réclamer votre mot de passe à chaque clic.) Le voler met en échec la plupart des connexions multifacteur, car l'attaquant s'empare de la preuve d'une connexion aboutie plutôt que du mot de passe.
Le browser-in-the-middle est plus étrange, et d'une certaine façon plus simple. L'attaquant fait tourner un véritable navigateur sur son propre serveur et le pointe vers la véritable page de connexion. Une bibliothèque open source nommée rrweb, conçue pour rejouer des sessions utilisateur, sérialise cette page en direct et vous la diffuse via un WebSocket, un canal bidirectionnel persistant entre votre navigateur et le sien. Votre navigateur restitue la structure de la vraie page comme si vous l'aviez chargée vous-même. Vous ne regardez pas une capture d'écran ni une vidéo. Vous télécommandez un navigateur qui se trouve dans la vraie boutique, et vos frappes, votre souris et votre approbation multifacteur lui sont relayées en retour. Quand la connexion aboutit, elle aboutit dans leur navigateur, et leur serveur frappe le jeton de session. Ils possédaient votre session dès la première seconde.
Pourquoi se donner cette peine ? Parce que cela convainc d'une manière qu'un clone n'atteint jamais. Il n'y a pas de fausse page à rater. Et parce que l'attaquant utilise un seul navigateur cohérent pour parler au vrai site, la connexion ne déclenche pas les alarmes de discordance d'empreinte (les petites incohérences entre votre appareil et un proxy) qui trahissent parfois un kit à proxy inverse. Netcraft a compté environ soixante-dix nouveaux noms d'hôte Bluekit en une seule semaine. C'est la production d'un produit.
Ce qui ne l'arrête pas.
Commençons par la mauvaise nouvelle, car il y en a beaucoup.
L'authentification multifacteur, dans ses formes courantes, n'arrête pas ceci. Un code à usage unique et une approbation push prouvent la même chose, qu'une connexion est en train de se produire en ce moment, et l'attaque a besoin que cette connexion se produise, car c'est l'attaquant qui se connecte. C'est vous qui faites la preuve. C'est lui qui garde la session.
Le renforcement de session plus récent aide moins qu'on ne l'espérerait. Netcraft note que les Device Bound Session Credentials, un mécanisme qui lie un cookie de session à l'appareil sur lequel il a été émis, « ne peuvent pas protéger contre le Browser-in-the-Middle, alors qu'ils offrent une certaine protection contre l'Adversary-in-the-Middle ». La session voit le jour sur l'appareil de l'attaquant, donc la lier à cet appareil protège l'attaquant, pas vous. Tout ce qui se greffe après la connexion arrive trop tard, car à ce moment-là l'attaquant détient la session de plein droit.
L'isolation ne l'arrête pas non plus, et cela vaut la peine de le dire clairement. Un navigateur qui exécute chaque onglet dans une machine virtuelle jetable, comme le fait le nôtre, contient ce qu'une page peut faire à votre ordinateur. Le browser-in-the-middle ne fait rien à votre ordinateur. Il emprunte vos mains le temps d'une connexion et garde le résultat sur un serveur que vous ne verrez jamais. Vous pouvez jeter votre propre session à l'instant où vous fermez l'onglet. La copie qui compte n'a jamais été de votre côté pour être jetée. La jetabilité défend contre une longue liste d'attaques, et le browser-in-the-middle n'est pas sur la liste.
Ce qui l'arrête.
Aucun meilleur détecteur de fausse page n'aide ici, car il n'y a pas de fausse page. La parade, c'est un identifiant que l'attaquant ne peut pas recopier.
Les mots de passe et les codes à usage unique partagent une propriété fatale : ce sont des chaînes de caractères. Vous tapez une chaîne dans une page diffusée, le fil la transporte, et le navigateur à l'autre bout la rejoue. C'est tout le modèle économique.
Une passkey est une clé privée qui réside sur votre appareil et ne le quitte jamais. Se connecter signifie que votre Mac signe un défi à usage unique après que vous l'avez approuvé avec Touch ID, et la signature qu'il renvoie est liée au site web exact pour lequel vous avez créé la passkey. Deux conséquences en découlent, et toutes deux brisent le browser-in-the-middle.
D'abord, il n'y a rien à taper, donc rien à relayer. Le secret n'apparaît jamais dans la page, ne traverse jamais le WebSocket, et ne se trouve jamais dans un champ de formulaire que rrweb pourrait rediffuser. Le navigateur de l'attaquant peut bien demander tant qu'il veut ; la signature se fait sur une puce dans votre Mac que le serveur de l'attaquant ne peut pas atteindre.
Ensuite, la passkey de votre vraie banque est enregistrée pour le domaine de votre vraie banque. Quand l'hôte de l'attaquant sert la page devant vous, votre Mac cherche une passkey qui n'existe pas là et n'en propose aucune. La connexion qui devrait prendre une seule pression n'arrive pas. Ce silence, l'auto-remplissage qui ne se déclenche jamais et la passkey qui n'est pas dans la liste, c'est l'avertissement que la fausse barre d'adresse vous donnait jadis et ne peut plus donner.
Deux façons de prêter les identifiants de votre Mac.
La conception du navigateur compte ici, car une passkey ne vous défend que si elle atteint l'endroit où vous vous connectez.
Bromure exécute chaque session de navigation dans une machine virtuelle Linux jetable sur votre Mac, un petit ordinateur séparé qu'il efface quand vous fermez la fenêtre. Cela contient bien les pages hostiles, mais soulève une question évidente : si le navigateur vit dans une machine jetable, d'où viennent vos identifiants enregistrés ? Bromure vous fait choisir, profil par profil, et scinde le choix en deux interrupteurs à dessein.
Utiliser les mots de passe macOS
L'option de commodité, large. La session remplit automatiquement les noms d'utilisateur et les mots de passe depuis les mots de passe enregistrés de votre Mac et le trousseau iCloud, et le propre coffre de mots de passe de Chromium s'éteint. Cela reste lié au domaine, donc il ne remplira pas automatiquement sur l'hôte de l'attaquant. Mais un mot de passe est une chaîne, et une personne déterminée peut en taper un à la main. De la commodité, avec un bord tendre.
Utiliser les passkeys macOS
L'option étroite, résistante à l'hameçonnage. La session se connecte avec les passkeys détenues sur votre Mac, et Touch ID ou votre mot de passe verrouille chaque requête. Vous pouvez activer ceci tout en laissant le partage complet des mots de passe désactivé : les passkeys seulement. Rien à taper, rien à relayer, rien à proposer sur le mauvais domaine. Cet interrupteur retire le browser-in-the-middle de la table.
Les scinder est tout l'intérêt. Partager tout votre trousseau dans une session est la valeur par défaut, commode ; ne partager que les passkeys est l'option immunisée contre l'attaque de cet article. Le mode passkeys-seulement a son propre interrupteur, de sorte que le choix résistant à l'hameçonnage vous coûte une bascule plutôt qu'un projet de sécurité. Vous pouvez faire tourner un profil avec exactement une seule façon de vous authentifier, celle qui ne peut pas être diffusée depuis votre écran.
Ce que ceci ne résout pas.
Une bascule n'est pas un champ de force, et les limites comptent.
La principale mérite d'être répétée. Si vous vous connectez avec un mot de passe via une page browser-in-the-middle, même avec un code à usage unique ou un push derrière, l'attaquant obtient une session fonctionnelle, et ni une VM jetable ni un navigateur astucieux ne la récupèrent. Le partage passkeys-seulement protège les connexions où vous utilisez une passkey, et aucune autre. Bien des sites n'en proposent toujours pas, et pour ceux-là le vieux conseil est le seul conseil : ne suivez pas les liens de connexion contenus dans les messages, ouvrez le site vous-même.
La détection aide, et Bromure l'utilise : un DNS filtré qui bloque les domaines malveillants connus, et un contrôle anti-hameçonnage par IA qui note l'URL et la structure des formulaires d'une page avant que vous n'agissiez. Les deux réduisent les probabilités. Aucun n'est une garantie, et le browser-in-the-middle est conçu pour rendre la détection plus difficile. Soixante-dix nouveaux noms d'hôte par semaine devancent la plupart des listes de blocage, et un analyseur de contenu ne trouve aucune fausse page à signaler. La détection attrape l'attaquant négligent. Les identifiants résistants à l'hameçonnage attrapent celui qui est soigneux.
Et la plus ordinaire des limites : on peut convaincre une personne de bien des choses. Si un message persuasif vous conduit vers un site sans passkey et que vous tapez un mot de passe réutilisé ailleurs, aucun réglage de navigateur n'a jamais été dans cette boucle. Le partage passkeys-seulement ne vous rend pas invincible. Pour les connexions qui comptent le plus, votre messagerie, votre hébergeur de code, votre fournisseur d'identité, il retire la chaîne que l'attaquant venait chercher et laisse une clé qu'il ne peut pas atteindre.
La fausse barre d'adresse part à la retraite.
Le conseil que nous avons répété pendant deux décennies (vérifiez l'URL, cherchez le cadenas, doutez de la page) supposait que l'attaquant devait forger quelque chose. Le browser-in-the-middle ne forge rien. Il vous tend l'article authentique et se tient derrière, le sac ouvert.
Le constat honnête : un navigateur axé sur la sécurité ne vous rend pas immunisé contre ceci, et nous préférons le dire plutôt que faire semblant. La réponse a migré de vos yeux vers vos identifiants. Face à une page que vous ne pouvez pas distinguer de la vraie, la défense durable est de se connecter avec quelque chose que vous ne pouvez pas recopier : une passkey, signée sur votre Mac, liée au vrai domaine, jamais proposée à celui de l'attaquant. Le rôle de Bromure est petit et précis. Il en fait la valeur par défaut facile en permettant à un profil de partager des passkeys et rien d'autre. Installez-le, activez le mode passkeys-seulement pour les comptes que vous ne pouvez pas vous permettre de perdre, et laissez la prochaine page de connexion d'allure parfaite vous réclamer un secret que vous n'avez plus à lui donner.