Une erreur dans la configuration d’Azure Active Directory permettait à n’importe quel utilisateur ayant un compte Microsoft entreprise de se connecter à des applications auxquelles ils ne devraient pas avoir accès.
La faille, découverte par l’entreprise Wiz Research spécialisée dans la cybersécurité des systèmes hébergés dans le cloud, impacte environ 25% des applications utilisant Azure AD pour authentifier leurs utilisateurs.
Parmi les applications vulnérables, on retrouve par exemple le Content Management System (CMS) de Bing. Les chercheurs de Wiz ont pu s’y connecter avec des comptes non autorisés et configurer les résultats de recherche des internautes. Par ce biais, il peuvent changer par exemple le résultat de la recherche “best soundtracks” mais aussi et surtout injecter du contenu malicieux dans ces résultats et ainsi récupérer des données personnelles des utilisateurs, comme le contenu de leurs mails Outlook ou les documents partagés avec eux via Sharepoint.
Le résultat de la recherche “best soundtracks” avant et après l’attaque
🧑💻 La feature vulnérable
Azure AD est ce qu’on appelle un identity provider. Son rôle est d’authentifier les utilisateurs avant de leur donner un token, qu’ils pourront ensuite utiliser pour accéder à l’application.
Lorsqu’on se connecte à ChatGPT par exemple, on peut le faire en s’authentifiant avec un compte google. Dans ce cas, google sert d’identity provider, authentifie l’utilisateur et lui donne un token que l’application d’openAI utilise ensuite pour afficher et customiser la page.
Les identity providers permettent aux développeurs de ne pas avoir à implémenter les fonctionnalités d’authentification, mais leur complexité facilite souvent les mauvaises configurations.
Une des features très pratique de Azure AD est de permettre à l’application d’authentifier des utilisateurs venant de plusieurs organisations. Ces utilisateurs sont regroupés en groupes appelés “tenants”. Par exemple, Microsoft Teams utilise l’architecture multi-tenant : tous les utilisateurs s’authentifient sur le même portail, puis accèdent à une ressource configurée en fonction de l’entreprise (le tenant, donc) à laquelle ils appartiennent.
Dans le cas des applications multi-tenant, l’identity provider a pour rôle d’authentifier les utilisateurs, de leur fournir un token spécifiant leur organisation, puis de les rediriger vers une instance de l’application.
Dans une application multi-tenant, Azure AD authentifie les utilisateurs venant de tous les tenants, puis les redirige vers une version de l’application
💥 La faille :
Grâce à Azure AD, implémenter l’authentification dans une application est extrêmement simple - trop simple même. Tellement simple que le partage de la responsabilité entre Azure AD et l’application n’est pas toujours clair.
Panneau de configuration d’Azure AD - une simple checkbox permet de choisir entre autoriser les utilisateurs d’un tenant ou de plusieurs tenants.
Dans la configuration “Current tenant - Single tenant”, Azure AD fournira un token à l’utilisateur uniquement si son compte appartient au bon tenant. L’application peut ensuite utiliser ce token en toute tranquillité en sachant que l’utilisateur est censé accéder à l’application.
Cependant, dans les configurations “Any Azure AD directory - Multi-tenant” et “Any Azure AD directory & personal Microsoft accounts”, Azure AD fournira un token à n’importe quel compte tant qu’il appartient à un tenant, peu importe celui auquel il appartient. Dans cette configuration, la responsabilité de vérifier l’origine du token incombe à l’application.
Le problème apparaît lorsque la fonction multi-tenant est activée par erreur sur une application censée être single-tenant. Dans ce cas, l’erreur est invisible au premier regard car les utilisateurs de l’application cible sont authentifiés comme attendu. Mais cette configuration permet bel et bien aux utilisateurs provenant d’autres tenants Azure AD d’accéder à la ressource.
🛠️ Les contres-mesures de Microsoft :
Microsoft a désactivé la fonctionnalité multi-tenant pour les applications qui n’en avaient pas l’usage, soit 99% des applications qui l’utilisaient.
Pour les applications qui nécessitent vraiment d’authentifier des utilisateurs provenant de plusieurs tenants, Microsoft a implémenté une feature qui permet de ne plus émettre de tokens pour les utilisateurs des tenants non spécifiés dans les ressources. Cela permet essentiellement de forcer les développeurs à spécifier les tenants auxquels ils font confiance à travers une whitelist, et donc de bloquer par défaut les utilisateurs venant de tenants inconnus.
🛡️ Comment s’en protéger ?
Une erreur de configuration peut arriver à tout développeur, peu importe son expérience. En cas de doute, il est préférable d’utiliser l’option la plus restrictive et de revenir changer la configuration plus tard pour satisfaire le besoin métier.
Pour s’assurer de la sécurité de son application, il est primordial d’être extrêmement clair sur la répartition des responsabilités lors de l’authentification. Un token utilisateur doit être vu comme un badge que l’utilisateur présente à chaque fois qu’il veut faire une action : ce système n’est sécurisé que si l’organisation qui délivre le badge a vérifié les droits de l’utilisateur correctement.
En tant que responsable métier, c’est une bonne pratique de lister les vérifications à effectuer avant d’autoriser les utilisateurs à accéder à l’application, puis de demander à l’équipe technique qui effectue chacune des vérifications.
Enfin, dans la majorité des cas, un utilisateur d’origine inconnue ne doit pas avoir accès aux parties protégées de l’application. Une bonne pratique est donc de privilégier les whitelist aux blacklist quand on veut restreindre l’accès à une ressource.
Liens utiles :
Article sur le Blog de Wiz, qui a découvert la faille
Communiqué de Microsoft suite au fix de la faille
Nous avons pour ambition de sécuriser le web, et pour atteindre cet objectif, nous avons besoin de vous ! Si vous avez des questions, des suggestions ou le moindre doute, n'hésitez pas à contacter notre équipe sécurité par mail security@theodo.fr.
