Downgrade FIDO : contournement d’authentification sur Microsoft Entra ID

Une faille permet de forcer l’abandon des passkeys FIDO sur Entra ID, rendant possible le vol de session via une attaque Adversary-in-the-Middle.

L’adoption croissante des passkeys renforce la sécurité, mais une recherche récente met en évidence un angle mort d’implémentation côté clients et parcours de connexion. Dans cette attaque, un proxy malveillant relaie le formulaire Entra ID et modifie l’agent utilisateur pour faire croire au service que le navigateur ne prend pas en charge FIDO. Lorsque le service désactive FIDO et renvoie une erreur, l’utilisateur est invité à choisir une méthode de secours. Si cette méthode est utilisée, l’attaquant peut intercepter les éléments d’authentification et détourner la session.

Comment l’attaque de déclassement contourne FIDO sur Entra ID

Selon les chercheurs, le vecteur repose sur un « phishlet » personnalisé au sein d’un cadre AiTM de type Evilginx, capable d’usurper un agent utilisateur dépourvu de prise en charge FIDO. Le cas cité est Safari sous Windows, qui n’est pas compatible avec FIDO pour Microsoft Entra ID. En conséquence, la plateforme d’authentification désactive FIDO et affiche une erreur qui détourne l’utilisateur vers une méthode alternative.

Dans ce flot de repli, l’utilisateur peut se voir proposer l’application Microsoft Authenticator, un code SMS ou un OTP. L’architecture AiTM, qui proxifie le véritable formulaire Entra ID, intercepte alors les identifiants, le jeton MFA ou le cookie de session. L’attaquant importe ensuite le cookie valide dans son propre navigateur et obtient l’accès au compte qui était pourtant protégé par une authentification réputée résistante au phishing. Ces points sont détaillés dans l’analyse de BleepingComputer.

Les chercheurs précisent ne pas avoir observé cette méthode à grande échelle pour l’instant, les acteurs malveillants ciblant encore prioritairement des comptes sans MFA. Ils soulignent cependant que le risque est significatif pour des attaques limitées et très ciblées. Ils recommandent de désactiver les méthodes de secours lorsqu’un compte est protégé par FIDO, ou d’ajouter des contrôles additionnels lorsqu’un repli est déclenché.

Détails techniques et mesures de mitigation côté entreprise

Le succès de cette technique tient à un « trou » fonctionnel : toutes les combinaisons navigateur/système ne prennent pas en charge FIDO. En spoofant un agent utilisateur non pris en charge, l’attaquant déclenche le scénario d’erreur côté service et force l’utilisateur à se rabattre sur une méthode moins robuste. Dans un cadre AiTM, ces méthodes sont interceptables en transit, d’où la possibilité de détournement de session par récupération du cookie.

Pour réduire le risque, les recommandations discutées insistent sur la gestion stricte des chemins de repli. Sur les comptes sensibles, la désactivation des alternatives (SMS, OTP, prompts OAuth) ou l’application de vérifications supplémentaires lors d’un déclenchement de repli limite l’exploitabilité. La synthèse publiée par TechRadar reprend ces mesures et souligne l’importance d’anticiper le recours aux méthodes de secours, courantes pour la récupération de compte.

Un autre travail de recherche cité évoque « PoisonSeed », une tentative différente de déclassement où un site de phishing initie un flux d’authentification inter‑appareil, avec QR code à scanner sur la page légitime. Bien que conceptuellement intéressant, ce procédé s’est avéré impraticable en raison d’exigences de proximité rendant les demandes frauduleuses inopérantes. Cet élément est rapporté dans la même analyse décrivant l’attaque AiTM.

Comprendre FIDO (explication pour non‑initiés)

FIDO (Fast Identity Online) regroupe des standards – dont FIDO2 et WebAuthn – qui visent à supprimer les faiblesses des mots de passe et des codes envoyés par SMS. Concrètement, lors de l’enregistrement d’une « passkey », l’appareil de l’utilisateur génère une paire de clés cryptographiques : une clé privée et une clé publique. La clé privée reste sur l’appareil et n’est jamais transmise au service ; la clé publique est associée au compte.

Lors de la connexion, le service envoie un défi unique que l’appareil signe localement avec la clé privée. La signature est vérifiée à l’aide de la clé publique ; si elle est valide, l’accès est accordé. Comme la clé privée ne circule pas, un site de phishing ne peut pas la « voler ». Cette propriété rend FIDO très résistant au phishing et aux interceptions de données. L’attaque de déclassement ne brise pas FIDO lui‑même : elle contourne FIDO en forçant un repli vers une méthode plus faible, ce qui rouvre la porte aux attaques AiTM et au vol de cookies de session. Une présentation claire de ces principes figure dans l’article source de BleepingComputer.

Quel est l’état de la menace aujourd’hui?

À ce stade, les chercheurs n’ont pas observé d’exploitation active de cette méthode à grande échelle. Ils estiment toutefois que, avec la généralisation des passkeys dans des environnements critiques, des acteurs déterminés pourraient intégrer ce type de déclassement dans leurs chaînes d’attaque. L’article de synthèse de Cyber Security News / CyberPress rappelle que ces attaques exigent l’existence de méthodes alternatives actives et des « phishlets » spécifiquement conçus pour les scénarios de déclassement.

En somme, la sécurité offerte par FIDO reste robuste tant que le parcours utilisateur ne permet pas de bascule vers des méthodes plus faibles. La montée en puissance de l’authentification résistante au phishing doit donc s’accompagner d’une surveillance des déclenchements anormaux et d’une sensibilisation claire : si un service demande soudainement de changer de méthode de connexion au lieu d’une passkey attendue, il faut interrompre la procédure et vérifier par les canaux officiels.