Présentation
/login/callback qui détermine l’utilisateur. Ce jeton contient une référence à l’, un locataire Auth0, auquel il est destiné. Le service Auth0 ne validait pas correctement cette audience, et permettait donc à des jetons destinés à un locataire d’être utilisés chez un autre. De plus, la fonctionnalité de base de données personnalisée proposée à tous les locataires Auth0 permet de générer des jetons d’authentification avec n’importe quel identifiant. Par conséquent, si un pirate apprenait l’identifiant de l’utilisateur d’une victime prévue chez un locataire cible, ce qui est généralement considéré comme une information publique, il pouvait générer un jeton avec cet identifiant. L’audience n’étant pas bien vérifiée, le locataire cible pouvait l’accepter et établir une séance de connexion en considérant l’attaquant comme la victime. Cela permettait une escalade des privilèges, parmi d’autres vecteurs d’attaque possibles.
Le risque d’utilisation de cette attaque sur le service de gestion Auth0 constituait une préoccupation particulière. Les locataires Auth0 sont gérés par des administrateurs de locataires, qui disposent de comptes sur un « locataire d’autorité » avec les autorisations nécessaires. Si un attaquant apprenait l’identifiant de l’utilisateur d’un administrateur de locataire sur l’autorité du locataire (par exemple par ingénierie sociale), cela permettait à l’attaquant de se connecter en tant qu’administrateur par la méthode d’attaque décrite. L’attaquant pouvait alors exécuter des actions administratives et consulter toutes les informations du locataire.
L’attaque ne fonctionnait jamais si l’utilisateur avait activé l’authentification multifacteur, ce qui est recommandé.