Vue d’ensemble
/login/callback pour identifier l’utilisateur. Ce jeton contient une référence à l’ — un locataire Auth0 — à laquelle il est destiné. Une faille dans le service Auth0 ne validait pas correctement cette audience et permettait donc qu’un jeton destiné à un locataire soit utilisé dans un autre. De plus, la fonctionnalité de base de données personnalisée offerte à tous les locataires Auth0 permet de générer des jetons authentifiés avec n’importe quel identifiant. Ainsi, si un attaquant parvenait à obtenir l’ID utilisateur d’une victime ciblée dans un locataire donné — ce qui est généralement considéré comme de l’information publique — il pouvait créer un jeton avec cet identifiant. En raison de la validation inadéquate de l’audience, le locataire cible l’acceptait et établissait une session de connexion en reconnaissant l’attaquant comme la victime. Cela permettait notamment une élévation de privilèges.
Une préoccupation particulière concernait l’utilisation potentielle de cette attaque contre le service de gestion d’Auth0. Les locataires Auth0 sont gérés par des administrateurs de locataire, qui ont des comptes sur un « locataire d’autorité » avec les autorisations pertinentes. Si un attaquant pouvait découvrir l’identifiant utilisateur d’un administrateur de locataire sur le locataire d’autorité (par exemple au moyen de l’ingénierie sociale), cela lui permettait d’ouvrir une session en tant qu’administrateur à l’aide de la méthode d’attaque décrite. L’attaquant pouvait alors effectuer des actions administratives et consulter toute l’information du locataire.
L’attaque n’était jamais efficace si l’utilisateur avait l’ activée, ce qui est recommandé.