
Dans cet article (5)
Analyse des risques UX du phishing par code d’appareil OAuth
Points clés
- Traitez les invites de consentement OAuth et d’autorisation d’appareil comme une surface d’attaque, et non comme une simple plomberie d’arrière-plan.
- Utilisez l’accès conditionnel et la conformité des appareils pour bloquer les tentatives d’autorisation risquées avant que les utilisateurs n’aient à les évaluer.
- Réécrivez les invites d’approbation afin que les utilisateurs puissent voir l’application, le contexte et le risque avant d’accorder l’accès.
Analyse d’une faille qui n’en est pas une : quand le véritable flux d’autorisation fait le travail de déguisement du site d’hameçonnage.
La ruse de phishing la plus cruelle n’est pas toujours la fausse page de connexion avec un nom de domaine déguisé en masque d’Halloween bon marché. Parfois, c’est la vraie page d’autorisation, qui sourit poliment en demandant à l’utilisateur de valider la mauvaise chose. Le phishing par code d’appareil est le genre de problème d’identité qui pousse les défenseurs à regarder une fonctionnalité parfaitement légitime et à murmurer : évidemment, c’est devenu un outil de base pour les attaquants. La leçon n’est pas qu’OAuth est cassé. La leçon, c’est que l’expérience de connexion, l’accès conditionnel et les invites de consentement font désormais partie de la surface d’attaque, et qu’ils méritent la même méfiance que celle que nous réservons d’habitude aux bases de données exposées et aux communiqués de presse affirmant prendre la sécurité au sérieux.
Ce qui s’est passé, selon Proofpoint et Rubrik
Proofpoint décrit le phishing par code d’appareil comme une évolution de la prise de contrôle d’identité, et non comme un nouveau sort mystérieux trouvé dans un grimoire de cave. Ses recherches sur les menaces indiquent que le phishing d’identifiants continue de permettre la prise de contrôle de comptes, la fraude, les rançongiciels et l’espionnage, tandis que les acteurs malveillants se sont étendus au phishing par code d’appareil et au phishing OAuth à mesure que les organisations renforcent leurs défenses contre le phishing MFA courant. Voilà l’évolution de l’intrigue : quand les défenseurs rendent l’ancienne astuce moins rentable, l’adversaire ne prend pas sa retraite ; il cherche un processus auquel les utilisateurs font déjà confiance. L’échange de Rubrik avec Selena Larson, chercheuse chez Proofpoint, présente le problème comme un abus du flux d’authentification, où les adversaires exploitent des structures de communication légitimes pour capter des accès administratifs et d’entreprise. Cette formulation compte, car le camouflage n’est pas seulement une marque usurpée ou un domaine ressemblant. Le camouflage, c’est la cérémonie normale de connexion elle-même, ce qui signifie que les équipes de sécurité doivent examiner la cérémonie, pas seulement les identifiants saisis pendant celle-ci.
Comment le vrai flux devient l’appât, selon Proofpoint
Proofpoint explique qu’entre 2020 et environ 2022, des équipes rouges, ainsi que parfois des criminels et des acteurs d’espionnage, ont utilisé le phishing par code d’appareil pour pousser quelqu’un à autoriser une requête malveillante. C’est le point important pour les concepteurs : la victime ne saisit pas forcément un mot de passe sur une page contrefaite. Elle peut être en train de suivre un véritable flux d’autorisation et d’accorder un accès dans un contexte qu’elle ne comprend pas. Cela déplace la question de défense : au lieu de se demander si l’utilisateur a repéré la fausse page, il faut se demander si le système a rendu le choix risqué lisible avant le consentement. Une invite qui dit d’approuver ce code peut être techniquement exacte et pourtant inutile pour une personne qui essaie de terminer une invitation à une réunion, une conversation avec le support ou un autre rituel de travail accompagné d’une légère panique. L’exactitude n’est pas la même chose que la compréhension, et les attaquants prospèrent dans cet écart comme de la moisissure dans un vieux frigo de bureau oublié.
Ce qui a été exposé, selon Krebs et BleepingComputer
Krebs on Security a documenté l’ancienne version de cette histoire d’identité en 2022, lorsque du phishing par SMS ciblait des employés d’entreprises de recrutement commercial et les dirigeait vers des pages imitant les écrans d’authentification Okta. Krebs a rapporté que les personnes qui soumettaient leurs identifiants étaient ensuite invitées à fournir des codes d’accès à usage unique pour la MFA. La technique diffère, mais la morale est tristement familière : si l’étape d’authentification peut être relayée ou manipulée socialement, la présence de la MFA ne signifie pas automatiquement que la décision était sûre. La couverture par BleepingComputer du phishing OAuth par code d’appareil sur Azure et Google met en évidence une autre complication pratique : les défenses d’identité vivent à l’intérieur d’implémentations propres à chaque plateforme. Cela ne veut pas dire que chaque équipe doit devenir un groupe de passionnés des comités de normalisation OAuth, même si félicitations aux trois personnes qui le sont déjà. Cela signifie que les défenseurs doivent inventorier où l’autorisation par appareil est activée, quelles applications peuvent la demander, et comment chaque plateforme explique la demande à la personne qui tient le clavier.
Comment le contenir, selon Rubrik et Krebs La conversation de
Rubrik oriente les défenseurs vers des contrôles architecturaux, notamment des politiques d’accès conditionnel et des cadres stricts de conformité des appareils. C’est exactement là que ce sujet doit se trouver. Former les utilisateurs à reconnaître les invites suspectes est utile, mais demander à chaque employé de déboguer personnellement OAuth sous la pression d’une échéance n’est pas une stratégie ; c’est un test de stress professionnel avec des jetons cloud. Krebs a également rapporté en 2022 qu’Apple, Google et Microsoft avaient annoncé la prise en charge d’approches de connexion sans mot de passe reposant sur le déverrouillage d’un smartphone, des experts affirmant que ces changements devraient aider à vaincre de nombreux types de phishing, tout en avertissant qu’un véritable avenir sans mot de passe pourrait encore être éloigné de plusieurs années pour la plupart des sites web. Le sans mot de passe peut réduire le vol de mots de passe, mais le phishing par code d’appareil rappelle que le prochain combat porte sur la clarté de l’autorisation. Si un utilisateur approuve un accès, le produit doit montrer ce qui est approuvé, pour quelle application, depuis quel contexte, et pourquoi la demande est inhabituelle.
Ce que cela signifie vraiment pour vous, selon Proofpoint et Krebs
Pour les équipes chargées de l’identité, le message à retenir est assez simple pour tenir sur un post-it et assez déprimant pour gâcher le déjeuner : examinez les flux de connexion comme des surfaces produit, pas seulement comme de la tuyauterie de sécurité. Le cadrage de Proofpoint sur la prise de contrôle de comptes et l’historique de Krebs sur le phishing de codes d’accès pointent tous deux vers le même mode d’échec, où une étape d’authentification techniquement valide devient une scène d’ingénierie sociale. Auditez la disponibilité du code d’appareil, renforcez l’accès conditionnel, exigez des appareils conformes lorsque c’est approprié, et réécrivez les invites pour que les utilisateurs comprennent le risque avant de consentir. Pour tous les autres, ne considérez pas une vraie page de connexion comme une preuve que la demande est légitime. Ralentissez lorsqu’une invite vous demande de saisir un code, d’approuver un appareil ou d’autoriser une application que vous n’avez pas volontairement commencé à utiliser. La prochaine défense d’identité vraiment utile ne sera peut-être pas une case de plus dans le panneau des paramètres MFA. Ce sera peut-être une phrase plus claire exactement au moment où quelqu’un est sur le point de remettre les clés au mauvais personnage.