Utiliser MITM pour contourner la protection anti-hameçonnage FIDO2

FIDO2 est un terme de groupe d'authentification moderne pour l'authentification sans mot de passe. L'alliance Fast Identity Online (FIDO) l'a développé pour remplacer l'utilisation d'anciens mots de passe connus et fournir une méthode sécurisée d'authentification à l'aide d'une clé physique ou intégrée.  

FIDO2 est surtout connu pour protéger les utilisateurs contre les attaques de type man-in-the-middle (MITM), de phishing et de détournement de session.  

Dans cet article, je vais vous présenter mes recherches pour découvrir comment utiliser les attaques MITM pour contourner FIDO2. Tout d’abord, je vais décrire un flux d’authentification WebAuthn complet, puis passer en revue les protections de FIDO2. Ensuite, j'aborderai des techniques d'attaque célèbres et proposerai des cas d'utilisation réels. Enfin, je discuterai des mesures d'atténuation et de ce que vous pouvez faire pour protéger votre entreprise.   

Mais d'abord, un peu de contexte

Le flux d'authentification FIDO2 comprend la spécification de l'API WebAuthn pour une partie de confiance client (RP) – qui est la communication de l'application cloud – et le protocole Client to Authenticator (CTAP) pour la communication matérielle. L'ensemble du processus est géré par le navigateur et comprend deux étapes d'authentification : l'enregistrement de l'appareil et l'authentification.  

Il est construit de cette façon car FIDO2 est basé sur un mécanisme de cryptographie à clé publique. C'est ici que le client génère une clé privée et publique et renvoie cette dernière au RP pour vérification de la signature lors de la connexion. FIDO peut être appliqué comme méthode d'authentification pour une application unique ou dans une fédération. Pour ceux qui ne le savent pas, une fédération fait référence à une authentification unique (SSO) pour plusieurs applications indépendantes gérées par un seul fournisseur d'identité (IdP).  

Fonctionnalités de sécurité FIDO2 

FIDO2 est célèbre pour ses fonctionnalités de sécurité, principalement pour empêcher les attaques de phishing, d'interception et de détournement de session.  

Dans le cadre de mes recherches, je voulais voir si FIDO2 était immunisé contre ces attaques – et j’ai été surpris par les résultats. J'ai commencé par le détournement de session, une technique d'attaque dans laquelle l'adversaire vole la session d'un navigateur pour accéder à l'application et aux données privées de l'utilisateur. La deuxième attaque sur laquelle j'ai enquêté était une attaque de l'homme du milieu (MITM) contre l'IdP, où un adversaire écoute, modifie et relaie les communications entre deux appareils croyant qu'ils se transmettent directement l'un à l'autre.  

Aujourd’hui, MITM est plus difficile à réaliser grâce à la protection TLS. Néanmoins, il existe de nombreuses méthodes pour obtenir un MITM, notamment l'usurpation d'identité DNS/DHCP, l'empoisonnement ARP et le SLAAC. En outre, il est connu que des acteurs étatiques parviennent à contourner et à déchiffrer TLS en volant le certificat d'une organisation. Un exemple est en attaquant Active Directory Services de certification. 

FIDO a été conçu pour empêcher ces attaques. Cependant, lors de la mise en œuvre de cette méthode d'authentification moderne, la plupart des applications ne protègent pas les jetons de session créés une fois l'authentification réussie. J'ai découvert que de nombreux fournisseurs d'identité sont toujours vulnérables aux types d'attaques MITM et de détournement de session.  

Pour comprendre comment cela fonctionne, il faut revenir à l’essentiel. 

Au fil du temps, les bases de la communication web n’ont pratiquement pas changé. Le protocole HTTP et ses fonctionnalités sont largement utilisés sur le World Wide Web, notamment l'utilisation de GET et POST pour transférer des attributs entre les points de terminaison et les cookies afin de conserver un état de session pour un client. Les applications Web et les protocoles SSO tels que OIDC et SAML s'appuient sur le protocole HTTP et doivent suivre ses directives pour conserver un état client. Au fil des années, la sécurité des sessions utilisateur s'est améliorée en termes de manière dont elle est conservée localement par le navigateur et comment l'application la calcule. Toutefois, ces changements ne suffisent pas.  

Comment FIDO2 vous protège-t-il exactement ? 

Pour une authentification FIDO2 réussie, l'utilisateur doit soit enregistrer le périphérique FIDO auprès de la partie utilisatrice, soit ordonner au navigateur d'exécuter une fonction navigator.credentials.create(). Cela demande au périphérique FIDO de générer une clé privée et publique pour un utilisateur spécifique et de la lier à une origine de domaine. Le navigateur peut ensuite valider l'origine du domaine de la partie utilisatrice pendant le processus d'authentification.  

Vient ensuite l'étape d'authentification, où la partie utilisatrice appelle la méthode navigator.credentials.get() du navigateur pour chaque demande d'authentification. Une fois déclenché par le RP, le navigateur communique avec la clé de sécurité FIDO via CTAP. Si l'authentification est approuvée par l'utilisateur final, la clé de sécurité génère une signature à l'aide de la clé privée stockée. Cette signature est ensuite vérifiée par le RP à l'aide de sa clé publique. 

Lors d'une attaque de phishing sur un site Web avec une URL différente, l'origine du domaine du site Web validé empêchera un vol potentiel d'informations d'identification, car l'URL ne correspond pas à l'origine enregistrée. Cependant, le mécanisme d'attaque MITM est différent. La condition préalable à une attaque MITM est d’avoir un certificat approuvé par la victime cible. La plupart des navigateurs modernes alerteront et forceront une authentification sécurisée via TLS sur un site Web distant. Une attaque MITM réussie expose l’intégralité du contenu des requêtes et des réponses du processus d’authentification. À la fin, l'adversaire peut acquérir le cookie d'état généré et détourner la session de la victime. En termes simples, il n'y a aucune validation par l'application une fois l'authentification terminée.  

Tester les cas d'utilisation 

J'ai décidé de prendre Entra IdP, PingFederate et Yubico comme cas d'utilisation pour la recherche. Chacun fonctionne différemment et a ses propres avantages et inconvénients.  

Cas d'utilisation 1 : aire de jeux Yubico 

Le Yubico Playground a été créé pour démontrer et tester les fonctionnalités et clés de sécurité FIDO. Dans cet exemple, FIDO authentifie l'utilisateur directement via HTTP auprès d'une base de données d'utilisateurs locale. Une fois l'authentification réussie, un cookie nommé « session » est généré. Il n'y a aucune validation sur l'appareil qui a demandé cette session, et n'importe quel appareil peut utiliser ce cookie jusqu'à son expiration. L'acquisition de ce cookie pourrait permettre à l'adversaire de contourner l'étape d'authentification, d'accéder à l'espace privé de l'utilisateur et, dans ce cas, de supprimer la clé de sécurité du profil de l'utilisateur. Ceci est un exemple simple de détournement de session ; au fur et à mesure que nous passerons à des scénarios plus compliqués, nous verrons comment cette méthode évolue.  

Cas d'utilisation 2 : Entra ID SSO 

Le deuxième cas d'utilisation est Entra ID SSO, qui dispose de capacités de sécurité pour s'authentifier via divers protocoles SSO et d'autres méthodes d'authentification modernes. C'est Accès conditionnel – force d’authentification la fonctionnalité limite les mécanismes sans mot de passe – en particulier FIDO2. Notre test a validé des applications Microsoft natives telles qu'Office 365 et le portail de gestion Azure sur le protocole OpenID Connect (OIDC) et un exemple d'application tierce sur le protocole SAML. Dans les deux protocoles de fédération, l'IdP fournit un jeton d'accès signé avec un délai d'expiration d'une heure qui est transmis en tant qu'attribut POST à ​​la partie utilisatrice. Dans le mécanisme de fédération, l'adversaire n'a même pas besoin de relayer le processus d'authentification. L'attaquant a juste besoin d'un jeton signé, et il peut être réutilisé dans le bon délai et générer des cookies d'état dans un délai plus long. OIDC prend en charge les jetons d'actualisation qui peuvent générer des jetons de session pour une période prolongée. 

Nous pouvons voir dans l'exemple suivant que l'application native du portail Azure Management ne valide pas le token accordé par le SSO. 

Cas d'utilisation 3 : PingFederate 

Le troisième cas d'utilisation est PingFederate. Cette application globale fournit une fédération SSO pour une grande variété d’applications d’entreprise. Contrairement à Entra, Ping utilise des adaptateurs tiers pour effectuer l'authentification. Ces adaptateurs peuvent être enchaînés dans un flux de stratégie d’authentification. Chaque adaptateur a son propre contexte et est séparé des autres. Une authentification réussie est le moment où un utilisateur répond aux exigences de tous les adaptateurs de la stratégie. Les capacités FIDO2 peuvent être utilisées avec l'adaptateur PingOne. Étonnamment, notre équipe a découvert que si le développeur de la partie utilisatrice ne valide pas le jeton OIDC (ou la réponse SAML), l'attaque MITM décrite réussira.  

Lien le plus faible de l'authentification 

Les cas d’utilisation du SSO sont plus sévères par rapport à l’approche directe. À mesure que davantage d’acteurs sont impliqués dans le processus d’authentification, la partie utilisatrice a moins de contrôle sur la validation de l’intégrité du périphérique source. Même si FIDO protège contre les attaques MITM, toute la chaîne repose sur ses maillons les plus faibles, à savoir les protocoles SSO dont les jetons d'attribution peuvent être réutilisés par un autre appareil. 

Atténuations et prochaines réflexions 

Et s'il existait un moyen de vérifier que la session authentifiée est utilisée uniquement par le client authentifié ? Présentation Liaison de jeton, une proposition de norme demandée en 2018. 

La liaison de jetons permet aux applications et aux services de lier cryptographiquement leurs jetons de sécurité à la couche TLS pour atténuer le vol de jetons et les attaques MITM. Token Binding v1.0 liera l’intégralité de la session à sa poignée de main TLS sous-jacente. La cryptographie à clé publique s'étend au-delà du contexte d'authentification et WebAuthn fournira en toute sécurité la signature de liaison du jeton.  

Mais comment fonctionne la liaison de jetons ? 

• Lors de Client-Server Hello, une extension Token Binding est disponible. 
• Les deux points de terminaison s'accordent sur les champs TLS que le client signera.  
• Exactement comme dans WebAuthn, le navigateur crée une paire de clés privée/publique de longue durée.  
• Le client envoie la clé publique au RP pour vérification de la signature ; puis la signature est envoyée sur la couche application.  
• Le serveur vérifie la signature et la lie au jeton de session. 

J'ai initialement mené cette recherche à la mi-2023 et soumis les résultats à Microsoft. En réponse à la divulgation initiale, Microsoft a affirmé qu'il ne s'agissait pas d'une vulnérabilité. C'est quand même un surface d'attaque cela pourrait causer des dommages à une organisation exposée. Quatre mois plus tard, Microsoft a présenté un aperçu d'accès conditionnel de Protection des jetons, qui est une variante de liaison de jeton spécifiquement pour Trusted Platform Module (TPM). Dans sa documentation, Microsoft explique que le vol de tokens est rare, mais que les dégâts peuvent être importants. Dans le cas des applications Web, le TPM peut agir de manière similaire au FIDO en utilisant une méthode de communication différente de celle de la puce de sécurité. Cependant, le protocole WebAuthn reste le même pour la communication entre le navigateur et le RP. L'aperçu actuel est limité à des applications Web spécifiques et à des versions client Windows. La configuration actuelle est lourde et, à l'avenir, Microsoft étendra la fonctionnalité aux clés de sécurité FIDO génériques. 

À ce jour, Microsoft EDGE est le seul navigateur proposant la liaison de jetons. Chrome proposait la liaison de jetons, mais l'a supprimé en raison d'une faible adoption.  

La proposition de Token Binding aborde deux types de liaison de périphérique. L’une pour l’authentification directe est appelée Provided Token Binding. Ce type est courant dans les applications simples comme le terrain de jeu Yubico. Le deuxième type, Liaison de jeton référencé traite de la protection du fournisseur d’identité et de la partie utilisatrice. Dans tous les cas, WebAuthn peut passer la signature Token Binding en toute sécurité lors de la phase d’authentification.  

Il est recommandé aux gestionnaires d'applications d'exiger la liaison de jeton sur une authentification FIDO2, si disponible.  

Lors de la conception d’un mécanisme d’authentification, vous devez comprendre l’attribution de votre menace et construire votre authentification en conséquence. Dans les cas sensibles, l'approche directe est recommandée car l'application peut avoir plus de contrôle sur le jeton de session. 

Pour les développeurs d'applications, nous recommandons d'ajouter si possible une liaison de jeton au processus d'authentification FIDO2, ou au moins de limiter l'utilisation du jeton OIDC ou de la réponse SAML de chaque authentification réussie à utiliser une seule fois.  

Il est préoccupant que les excellentes fonctionnalités de sécurité de FIDO2 ne protègent pas l’intégralité de la session utilisateur. Il est important de comprendre que les méthodes d’authentification modernes ne constituent pas un charme magique en matière de sécurité et qu’il ne suffit pas de les acheter et de les mettre en œuvre : vous devez en comprendre en profondeur les avantages et les inconvénients. 

Pour en apprendre plus sur Silverfort, obtenez une démo ici.