e-Xpert Solutions Lausanne
Auteur : Michael Molho
Date de publication : 21 septembre 2018 - Dernière mise à jour : 24 septembre 2018
Dans l’écosystème Microsoft Cloud, une des briques principales est l’ Azure Active Directory, aussi appelée Azure AD. Fondamentalement, il s’agit du même composant que le traditionnel Active Directory local mais dans le Cloud. De la même manière que l’AD local, l’Azure AD contient la liste de tous les utilisateurs et groupes de sécurité d’une entreprise avec tous leurs attributs respectifs tels que :
L’administration de l’Azure AD se fait directement via la console Web centralisée Azure sur https://portal.azure.com/:
Une fonctionnalité « étonnante » de la solution est que n’importe quel utilisateur disposant d’une adresse email sur le domaine peut accéder à la console d’administration depuis Internet et consulter toutes les informations liées aux utilisateurs du domaine. Il peut « dumper » l’ensemble du domaine.
Il est par exemple possible de :
Tout cela représente une fuite d’information conséquente. Si un seul compte de l’entreprise est compromis, un attaquant pourrait alors accéder à toutes ces données sur les utilisateurs, les groupes et les appareils de l’entreprise.
C’est très simple :
Il est tout de même intéressant de mettre cela en perspective par rapport à un Active Directory local. En effet, par défaut, sur un Active Directory interne, n’importe quel utilisateur possède les permissions pour « dumper » de la même manière toutes les informations sur les utilisateurs et les groupes de l’entreprise. Quel est donc le risque dans le cas de l’Azure AD Cloud de Microsoft ?
La grande différence entre l’Azure AD et un AD interne, c’est que dans le cas de l’Azure AD Microsoft, toutes ces informations sont accessibles directement depuis Internet. Dans le cas d’un AD local, il faut être physiquement présent dans le réseau pour accéder aux données. Pour l’Azure AD, tout se passe « online » depuis Internet. Le risque est donc beaucoup plus important.
Il suffit qu’un seul compte (login/mot de passe) d’un utilisateur soit compromis, pour que l’ensemble de l’annuaire de l’entreprise soit directement exposé.
Cela peut permettre à un attaquant de cibler ses actions vers les utilisateurs ayant des droits élevés, par exemple dans des groupes de type « Admin … » ou « VPN … ». Ces informations peuvent également être utilisées pour mener une campagne de phishing massive sur tous les utilisateurs de l’entreprise. Pire que cela, en utilisant la connaissance des groupes de sécurité, il serait possible de cibler uniquement la population des ressources humaines, de la comptabilité de l’entreprise ou directement du board.
Après quelques recherches, il semble que la réponse à cette question ne soit pas si simple. Dans le portail d’administration Azure, il y a une option qui semble parfaitement adaptée :
En effet, après avoir positionné cette option à « Yes », il n’est plus possible pour un utilisateur lambda d’accéder au portail Web Azure … MAIS ! Il est toujours possible d’obtenir toutes les informations sur les utilisateurs via PowerShell pour Azure ou un programme .NET avec le framework Azure …
En utilisant par exemple Azure CLI ( https://docs.microsoft.com/en-us/cli/azure/install-azure-cli?view=azure-cli-latest), il est toujours possible d’obtenir la liste des utilisateurs, bien que l’option de blocage soit activée :
Toutes les actions décrites précédemment sont en fait toujours faisables techniquement avec un compte lambda via PowerShell ou .NET. Seul l’accès à la console Web est en fait bloqué.
En creusant encore un peu plus, il semble que deux autres pistes soient envisageables :
Aucune solution ne semble vraiment idéale. C’est la raison pour laquelle nous sommes actuellement en contact avec Microsoft pour avoir leur retour. Si nous obtenons de nouvelles informations intéressantes, nous ne manquerons pas de mettre à jour cet article.
Events
Archives