Le piège d'OAuth : lorsqu'une redirection légitime devient hameçonnage, malware et vol d'identité

Microsoft a publié cette semaine une alerte qui devrait mettre les administrateurs du secteur public et les utilisateurs en garde : les agresseurs profitent des mécanismes légitimes de redirection de flux OAuth pour amener les victimes à une infrastructure contrôlée par des criminels, évitant ainsi beaucoup des protections habituelles du courrier et du navigateur. Il ne s'agit pas tant de violer un service que d'exploiter le comportement prévu par la norme d'autorisation de sorte qu'une URL apparemment inoculée se retrouve dans un piège.

OAuth est la pièce technique qui permet aux applications de demander la permission d'agir au nom d'un utilisateur sans exiger votre mot de passe, et est la base de la connexion "Connexion avec Google" ou "Connexion avec Microsoft." La spécification prévoit que, dans certains scénarios (par exemple, erreurs ou flux spécifiques), le fournisseur d'identité redirige l'utilisateur vers une URL donnée. Les attaquants ont conçu des applications malveillantes et des liens qui abusent de cette redirection pour diriger l'utilisateur vers des pages hébergées par les criminels eux-mêmes. Si vous voulez examiner le fonctionnement du protocole, l'explication de base est oauth.net et la documentation spécifique des fournisseurs tels que Google et Microsoft détaille comment redirection URI sont gérés sur leurs plateformes ( Google OAuth, Microsoft Entrée / Identité).

Le mode de fonctionnement décrit par Microsoft combine l'ingénierie sociale et l'abus du flux OAuth: les attaquants créent une application dans un locataire qu'ils contrôlent et mettent comme URI de redirection un domaine malveillant. Ensuite, ils envoient des liens de phishing dans la post - avec des leurres soigneusement développés tels que les demandes de signature électronique, les enregistrements Teams ou les problèmes financiers et administratifs - qui demandent à l'utilisateur d'authentifier avec l'application malveillante, souvent en utilisant un "scope" intentionnellement invalide pour forcer la route d'erreur / de redirection souhaitée. Le résultat n'est pas toujours le vol direct de jetons; dans plusieurs campagnes, le but était de forcer les téléchargements qui ont infecté la propre équipe de l'utilisateur.

Dans les cas analysés, le fichier qui finit par arriver à l'appareil est généralement un ZIP qui contient un accès direct à Windows (LNK). Lorsque vous ouvrez cet accès direct, une commande PowerShell est immédiatement exécutée pour inspecter l'équipement et supprimer un installateur MSI. Cet installateur laisse un document de leurre en vue tandis que, dans l'arrière-plan, il sideloadea une bibliothèque malveillante (un nom DLL comme "crashhandler.dll") en profitant d'un binaire légitime pour le charger, défigurer un fichier supplémentaire et libérer la charge finale en mémoire. De là, le malware établit la communication avec un serveur de commande et de contrôle pour continuer l'intrusion, qui peut se retrouver dans l'activité pré-ransom ou les actions manuelles par les opérateurs humains.

En plus des campagnes qui livrent des logiciels malveillants, la même technique de redirection a été utilisée pour les pages qui implémentent des kits de phishing de type adverse-in-the-middle (AitM). Ces cadres vous permettent de capturer des identifiants, des cookies de session ou même d'échanger des codes OAuth en temps réel ; des cadres connus dans la communauté de sécurité ont démontré l'efficacité de ces approches lorsque l'utilisateur fait confiance au flux et que le fournisseur d'identité ne bloque jamais la redirection.

Un autre détail pertinent détecté par Microsoft est l'utilisation créative du paramètre "état" : conçu à l'origine pour corréler demandes et réponses et protéger contre CSRF, dans ces chaînes les attaquants encodent l'adresse email de la cible pour apparaître automatiquement sur la page phishing, augmentant leur crédibilité. C'est un rappel qu'une pièce conçue pour la sécurité peut être réutilisée perverse si son contenu n'est pas vérifié.

Microsoft a déjà supprimé plusieurs applications malveillantes identifiées, mais la conclusion pour l'équipement de sécurité et l'informatique responsable est claire: les contrôles techniques doivent être combinés avec de bonnes pratiques administratives. Limiter le consentement que les utilisateurs peuvent donner aux applications tierces, vérifier régulièrement les permis accordés et révoquer les applications inutiles ou surprivilégiés Ce sont des étapes critiques. Microsoft offre des outils de gestion d'application et des politiques de consentement sur sa plateforme; examiner ces options peut réduire la surface d'attaque ( gestion des applications en Azure AD / Entre).

Pour compléter ces mesures, il convient de renforcer les protections dans les terminaux et le courrier : empêcher l'ouverture automatique des pièces jointes dangereuses, bloquer les domaines et fichiers connus malveillants sur la porte de liaison et de courrier, et maintenir des solutions de détection capables d'identifier des techniques telles que l'exécution PowerShell de LNK ou DLL. Il est également important d'enseigner aux utilisateurs et aux équipements à soupçonner des liens même lorsqu'ils semblent provenir d'un fournisseur légitime; l'Agence américaine de sécurité. Les États-Unis et d'autres entités formulent des recommandations pratiques contre l'hameçonnage qui peuvent être intégrées dans les programmes de sensibilisation ( CISA - Guide d'hameçonnage).

De plus, les organisations ayant une identité centrale devraient évaluer des politiques plus strictes : empêcher le consentement des utilisateurs non gestionnaires pour certaines applications, exiger des examens administratifs pour les permis particulièrement sensibles et activer des contrôles conditionnels qui nécessitent une vérification supplémentaire ou bloquer l'accès à des environnements peu fiables. Les outils natifs des fournisseurs permettent la création de listes de demandes autorisées ou refusées et le suivi des tentatives inhabituelles de consentement.

Cet épisode rappelle que la sécurité à l'ère de l'identité comme périmètre est multidimensionnelle : il ne suffit pas de protéger l'infrastructure du périmètre si le modèle d'autorisation lui-même peut être manipulé socialement. La prévention nécessite la coordination des politiques d'identité, le contrôle du courrier et des paramètres, et la formation continue des personnes. Ce n'est donc pas le maillon le plus faible.

Si vous voulez examiner le rapport technique de Microsoft avec tous les indicateurs et exemples montrés par l'équipe de défense, il est disponible sur votre blog de sécurité: Microsoft Blog Sécurité - Abus de redirection OAuth. Pour approfondir la gestion des redirections et des URis dans différents fournisseurs, la documentation officielle Google et Microsoft sur OAuth / Identité est un bon point de départ ( Google, Microsoft Entrez.), et pour comprendre la conception du protocole lui-même, la référence dans oauth.net C'est utile.

Bref, ce n'est pas seulement une question technique, mais une question de gouvernance et de culture. Tenir un inventaire des applications, limiter ce que les utilisateurs peuvent autoriser activement et examiner les permis sont des mesures qui, combinées à des contrôles techniques, rendent difficile pour des attaques comme celle-ci d'atteindre un bon port.