Administrators can use teams policies for controlling what users can do in Microsoft Teams.

In this blog, I’ll show that these policies are applied only in client and thus can be easily bypassed.

What are Teams policies?

Policies are used in Microsoft Office 365 and Azure AD for securing access to services and data. Besides the common identity and device access policies, Microsoft has provided a set of Teams specific policies:

• Teams and channel policies
• Messaging policies
• Meeting policies
• App permission policies

For example, administrators can configure Teams so that external users are not able to edit or delete any messages they’ve sent. Or, an owner of a Teams site can disable message editing for members of a certain channel.

Bypassing Teams policies

Initial discovery

While I was working with the previous version (v0.4.4) of AADInternals Teams functions I noticed an interesting thing: I was able to edit and delete chat messages using AADInternals as a guest even when it was not allowed.

This led to a question that what if the policies are applied only at the client end? In practice this would mean that the Teams service tells to your Teams client that “Though shall not edit messages!” but the client could still do so.

Observing Teams client behaviour

I started by watching what was going on between the client and cloud when the Teams client started. The first observation was that the client made about 120 http requests to the cloud. While browsing through those requests, I spotted one that caught my interest (headers stripped):

POST https://teams.microsoft.com/api/mt/part/emea-02/beta/users/useraggregatesettings HTTP/1.1

{
    "tenantSettingsV2": true,
    "userResourcesSettings": true,
    "messagingPolicy": true,
    "clientSettings": true,
    "targetingPolicy": true,
    "tenantSiteUrl": true,
    "userPropertiesSettings": true,
    "callingPolicy": true,
    "meetingPolicy": true,
    "educationAssignmentsAppPolicy": true
}

The response contained all the settings and policies the Teams client is allowed to do as the logged in user. Below can be seen the messagingPolicy section:

"messagingPolicy": {
	"value": {
		"allowUserEditMessage": true,
		"allowUserDeleteMessage": true,
		"allowUserChat": true,
		"allowGiphy": true,
		"giphyRatingType": "Moderate",
		"allowGiphyDisplay": true,
		"allowPasteInternetImage": true,
		"allowMemes": true,
		"allowStickers": true,
		"allowUserTranslation": true,
		"allowUrlPreviews": true,
		"readReceiptsEnabledType": "UserPreference",
		"allowImmersiveReader": true,
		"allowPriorityMessages": true,
		"audioMessageEnabledType": "ChatsAndChannels",
		"channelsInChatListEnabledType": "DisabledUserOverride",
		"allowRemoveUser": true,
		"allowSmartReply": true
	}
}

What we can learn here is that the Teams client asks from the cloud what the current user is allowed to do, which was the expected behaviour.

Testing in action

Next I decided to try whether I could lie to Teams client:

1. I saved the response from above to be used as a baseline.

2. I created a new Messaging policy to disable editing and deleting of sent messages.
   
   I applied the policy to a single demo user:
   
   
   
   Now I had two policies, the default organisation wide and the restricted one for demo user:
   
   

3. I restarted the Teams client and noticed that the editing and deleting were correctly disabled (didn’t exists).

4. I compared the returned policies from the useraggregatesettings requests
   and as we can see, the request was missing two lines:
   
   

5. I closed the client and configured Fiddler to do an autoresponse using the saved http response from above:
   
   
   
   Now, when the client is requesting the settings file, it will be served the one that allows editing and deleting.

6. I started the Teams client and the editing and deleting were again allowed and I was able to edit and delete (my own) messages!

What we can lean here is that we can lie to Teams client and change its behaviour :joy:
Moreover, we learnt that Teams policies are applied only on the client :man_facepalming:

Here is the video demonstrating this with AADInternals and Fiddler (sorry for the bad audio after 03:20):

Below is a video that shows in action that this works also with cloud file storage restrictions:

Note: Although not seen on the video, I was able to add my Google Drive account to Teams so this is not just a UI thing.

Detecting and protecting

As far as I know, the “uncompliant” Teams client behaviour can not be detected.

Same verdict with protecting. Well, one could try to use Conditional Access (CA) with device ownership and compliance restrictions, but that doesn’t cover all scenarios.

Summary

Our little test here proves that Teams policies are applied ONLY on the client!.

If the user (or guest) is utilising Teams APIs directly, using for instance AADInternals Teams functionality, he or she can bypass the restrictions set by the policies. However, this is not a bug or vulnerability as such, but a (very very bad) design choice by Microsoft.

Users can do at least the following:

• Bypass messaging policies
• Bypass cloud file storage restrictions
• Bypass meetings policies

:warning: Teams policies are NOT a security measure and organisations should not rely on them! :warning:

References:

• Microsoft: Common identity and device access policies
• Microsoft: Policy recommendations for securing Teams chats, groups, and files