Bug in the Azure AD Access Panel allows guest users to view groups and their membership

In the IT world, there is a constant struggle between security and usability. Admins often have to weigh in on user impact before they enable some feature designed to improve the security stance of a given product. This of course holds true for the cloud applications as well. Take Guest users and the Azure B2B collaboration features as an example. While the benefits of being able to collaborate directly with your clients and partners are immeasurable, if the wrong document or piece of information gets in the hands of the wrong person, this can inadvertently have some very negative consequences. This includes even trivial things such as a name of a group or its members – imagine a partner seeing the names of some of his competitor’s employees in a group called “Preferred buyers” or similar.

Thus, at least for some companies, the subject of exposing user and group information from your directory to external parties is a very sensitive one. For the most part, Microsoft has made sure to ease the minds of such companies, by restricting the type of data exposed to Guest users. Take Teams for example, a Guest user can only see details about and participate in conversations with people that are members of the Teams he’s added in. He cannot perform searches for other users in the company, initiate chats and calls with them or view the organizational chart.

A detailed description of what a Guest user can and cannot do in the directory can be found here. Some additional controls for the level of access granted to Guest users exists, for example the “Guest users permissions are limited” toggle under the Azure AD blade -> User settings -> External collaboration settings. Citing the detailed description of this option:

It turns out however that the Azure AD Access Panel did not honor this setting. By default, Guest users get access to the panel, and can use it to get an overview of all the groups they own or are member of by navigating to the panel and selecting the Groups app. This functionality will work regardless of the value of the Guest users permissions are limited  setting described above. What the toggle should prevent is the ability for Guest users to browse all the other groups in the tenant, the ones they are not member of.

Let’s take a look at few screenshots to illustrate the issue. First, as a Guest user, I can verify that access to the Group app is enabled and working as expected:

(Yes, I’m actually listed as an owner of one group, and that’s perfectly acceptable for Guest users but is not the subject of the current article.)

For any of the groups listed on the page, I can click the individual group entry and get additional details, including the list of members and owners, their names and UserPrincipalName attribute. But that’s all the information I can get, and it matches the experience I would get in other endpoints, such as the Teams client. However, I can also click the Join group button, which then lists all the groups in the tenant:

That Tenant_admins group certainly looks like an interesting one, but since it’s a security group I cannot just join it. What I can do however is click on the Show more details link and get presented with its membership list:

In effect, now I’m looking at the details and membership of a group I’m not a part of. This is not the behavior you would expect when the Guest users permissions are limited setting is configured, so after reporting the issue to Microsoft, they managed to reproduce it and provide a quick fix. As with most quick fixes, the current experience is a bit “unoptimized”, but the important thing is that it does address the issue. If the option is toggled in the tenant, clicking the Join group button will now result in the following error message: “This functionality is not enabled or not available.“. As you can see from the below video however, there’s a brief moment where the list of groups is actually flashed on the screen before you get the error message:

This however does not result in the full list of groups being exposed, as confirmed by a network trace, and is only a visual glitch. What’s more worrying is that a “deep link” to the settings dialog for a given group continues to work. In other words, I can still get access to the list of group members as long as I know the objectID of the group, by constructing a link that looks like this: https://account.activedirectory.windowsazure.com/r#/manageMembership?objectType=Group&objectId=85e5fda0-92a0-4089-bdd0-147278dd4cfe

Of course, me being the tenant owner makes it very easy for me to get the objectID of the group. It’s highly unrealistic to expect that anyone would be able to guess the GUID corresponding to a given group in a tenant he has limited access to, so the potential to exploit this is very limited. Regardless, I’ve reported this behavior and I have no doubts that it will be addressed soon. I’ll make sure to update the article once this happens. In the meantime, if you are worried that some of your Guest users might be snooping around the directory, go and toggle the Guest users permissions are limited setting.