L'escroquerie de redirection OAuth qui vole les identifiants

Microsoft chercheurs de sécurité a récemment alerté sur une technique qui profite d'une fonction légitime de l'écosystème d'identité pour colliger des pages malveillantes sans recourir à la tromperie classique de supplantation directe. Au lieu de falsifier ou masquer des domaines, les attaquants exploitent le mécanisme de redirection d'OAuth pour « forcer » le navigateur ou le client de messagerie à emmener l'utilisateur vers une ressource contrôlée par l'attaquant. Le résultat est une arnaque d'hameçonnage beaucoup plus difficile à détecter par des filtres automatiques et par simple inspection visuelle.

Le vecteur décrit par les analystes combine des messages urgents - demandes de signature électronique, avis d'assurance sociale, invitations aux réunions ou réinitialisations de mot de passe - avec des liens qui semblent être des demandes d'autorisation légitimes. Parfois, ces URLs malveillantes sont cachées dans les fichiers PDF pour éviter les contrôles de courrier. Lorsque la victime clique, la chaîne d'événements profite de la façon dont les fournisseurs d'identité traitent les erreurs d'autorisation pour rediriger l'utilisateur vers un URI que les attaquants ont enregistré dans les applications OAuth sous leur contrôle. Le rapport technique peut être lu dans la note publiée par Microsoft: Microsoft Security Blog.

Pour comprendre pourquoi cette astuce fonctionne, il faut se rappeler que OAuth est une norme conçue pour déléguer les autorisations entre les services. Un fournisseur d'identité - comme Microsoft Enter ID - permet aux applications enregistrées de demander l'accès pour le compte des utilisateurs selon des règles très spécifiques ( RFC 6749). Lorsque quelque chose ne va pas pendant la négociation - par exemple, les paramètres qui appellent une authentification "silente" (prompt = aucun) ou une portée invalide - la spécification prévoit que le service d'identité génère une erreur et, dans de nombreux cas, répond par une redirection vers l'URI enregistrée par l'application. Les attaquants ont appris à provoquer délibérément ce comportement pour transformer une réponse d'erreur en route vers leur propre infrastructure.

Dans la pratique, les agresseurs créent des applications OAuth chez un locataire qui contrôle et enregistre une redirection qui pointe vers leur serveur. Ils établissent ensuite des liens d'autorisation qui semblent légitimes et les distribuent dans des campagnes ciblées, en particulier contre les organismes publics et les entités gouvernementales. Lorsque le fournisseur d'identité détecte l'"erreur" intentionnelle, il envoie l'utilisateur exactement à l'adresse de l'attaquant configuré. Dans certains cas, cette page est un site d'hameçonnage qui reproduit l'interface de connexion; dans d'autres, la redirection pointe vers une ressource qui délivre automatiquement un ZIP avec des raccourcis (.LNK) et des techniques de contrebande HTML pour supprimer les détections et exécuter le code sur l'équipe de la victime.

Les chercheurs décrivent également des variantes dans lesquelles les criminels utilisent des cadres d'attaques humaines dans des moyens spécialisés pour intercepter des lettres de créances ou des jetons de session et ainsi éviter des obstacles tels que l'authentification multifactorielle. Des outils de ce type - par exemple, des projets open source connus qui facilitent les attaques par procuration sur des sessions Web - permettent à un attaquant de capturer des cookies ou des jetons valides et de les réutiliser avant que la victime ne remarque quelque chose d'étrange; une référence technique de projets similaires est disponible dans le dépôt Evilginx2: Evilginx2 (GitHub).

Un détail particulièrement efficace de ces campagnes est l'abus du paramètre « état » d'OAuth. Il est habituellement utilisé pour maintenir le contexte entre la demande et la réponse d'autorisation; les agresseurs l'utilisent pour insérer l'adresse postale de la victime sur la page d'hameçonnage, ce qui augmente le sentiment d'authenticité et réduit les soupçons en voyant leur propre courrier déjà rempli. Dans d'autres variantes, l'ouverture du raccourci . LNK exécute la puissance Shell qui effectue la reconnaissance locale et déclenche une chaîne de charge latérale de DLL: un binaire légitime charge une DLL malveillante qui découple et exécute la charge utile finale en mémoire, un modèle connu et documenté par la communauté de détection de menace (voir techniques connexes dans MITRE: PowerShell, DLL Stree-Loading).

La clé de cette campagne n'est pas une vulnérabilité chez OAuth, mais l'utilisation d'un comportement standard : les fournisseurs d'identité répondent exactement comme ils devraient à certaines erreurs, et les attaquants manipulent ces erreurs en leur faveur. C'est pourquoi les défenses fondées uniquement sur des listes d'URL ou des heuristiques de courrier peuvent échouer si une demande d'autorisation légitime - apparemment - sert de couverture.

Que peuvent faire les organisations pour réduire ce risque? Les recommandations de Microsoft mettent en évidence plusieurs orientations complémentaires : limiter qui peut enregistrer les demandes auprès du locataire, exiger le consentement administratif pour les permissions sensibles, appliquer des politiques d'identité saines et l'accès conditionnel, et coordonner la détection entre le courrier, les services d'identité et les paramètres pour identifier les schémas transversaux. La documentation officielle sur les permis et le consentement et sur les politiques d'accès conditionnel aide à comprendre comment appliquer ces contrôles dans les environnements d'azur : Autorisations et consentement en Azure AD et Guide d'accès conditionnel. Il est également bon de limiter l'enregistrement des demandes par le biais de politiques et de vérifier régulièrement les demandes avec des permis délégués.

Au niveau de l'utilisateur final, la prudence devrait être accrue avec des liens inattendus, même lorsqu'ils proviennent de services légitimes ou lorsque le message semble être dirigé : les fichiers joints contenant des URL, comme les PDF, sont une technique d'évitement régulière. La combinaison de l'éducation, des filtres de courrier avancés, l'analyse du comportement des paramètres et la configuration rigoureuse de l'identité est la meilleure défense. Pour ceux qui veulent approfondir le fonctionnement des autorisations OAuth et comment éviter les abus, le processus d'enregistrement des demandes sur la plateforme d'identité de Microsoft fournit une base technique utile: Enregistrer des applications dans la plateforme d'identité Microsoft.

Bref, nous sommes confrontés à des attaques qui ne brisent pas la cryptographie ou exploitent les échecs traditionnels, mais qui profitent de comportements standard et de chaînes de confiance humaines. La solution consiste à reconnaître que la zone d'attaque comprend désormais l'infrastructure d'autorisation elle-même et à appliquer des contrôles de gouvernance de l'identité avec le même soin que le réseau et le terminal sont protégés. Comme toujours, la sécurité est une coordination entre la technologie, les processus et la sensibilisation.