Posted by The Microsoft Teams Client for Linux authenticates to Azure AD using the Application ID 5e3ce6c0-2b1f-4285-8d4b-75ee78787346 of the Microsoft Teams Web Client, thus being seen as a browser by Conditional Access. With an architecture using Conditional Access App Control for browsers, the Microsoft Teams Client for Linux sessions are redirected to Microsoft Cloud App Security (MCAS); however, MCAS recognizes the Microsoft Teams Client for Linux as a desktop application, not as a browser. The effect is that any custom MCAS session policy is bypassed. This is by design, built into MCAS. Credits go to a group of colleagues, who independently found out about this effect.
MCAS uses the Linux Teams Client User Agent string to take the decision that this traffic is coming from a desktop application. The string is “Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) MicrosoftTeams-Preview/1.2.00.32451 Chrome/69.0.3497.128 Electron/4.2.12 Safari/537.36” as can be seen, for example, in the Azure AD Sign-ins.
The immediate question one can ask is “Can this be used for spoofing in a browser to bypass the MCAS session policies?” And clearly yes, it can. Of course, user agent spoofing in a browser is very simple; the following video shows the described effect on Conditional Access App Control and MCAS session policies.
When contacted with this, the Microsoft Security Response Center (MSRC) replied “Our team investigated this issue, and this is by design. To mitigate, customer can create an access policy scoped to client apps with an action of “block”. This way, if a browser is spoofed as a client app, it will be blocked, and if it isn’t, session policy will apply as expected.” With this being the official position by Microsoft, here is a brief discussion what such an access policy could look like. Note that any access policy that produces the desired effect of preventing the spoofed browser session will always also prevent the Microsoft Teams Client for Linux.
Essentially, the MCAS access policy has action “Block” with the crucial part being the filter for matching the activities. Ideally, the filter would consist only of the Linux Teams Client User Agent string, but this just does not work: it does not match the spoofed browser sessions.
The filter must include the “Client app equals Mobile and desktop” expression (the information notification mentions that this filter works for apps with session control). Whenever “Client app” is specified in the filter, then also “App” needs to be specified in the filter, otherwise the access policy cannot be saved. Using “Microsoft Online Services” as App, the resulting filter looks like this:
If your overall architecture is to use Conditional Access App Control only for browsers and never for Mobile and desktop apps, this filter is a good choice. It simply blocks all Mobile and desktop apps including anything that uses the Microsoft Teams Client for Linux User Agent string. Note that you must create additional access policies with “Block” action if you want to prevent the session policy bypass also for other apps that are not included in the “Microsoft Online Services” list.
If you have an architecture that does use Conditional Access App Control for Mobile and desktop apps as well, the filter needs to include the User agent string so as not to block those Mobile and desktop apps you want to allow. One possibility is to simply paste the whole string into the “User agent string” filter expression:
This will prevent the Microsoft Teams Client for Linux, it will prevent the User agent spoofed browser sessions, but leave all other Mobile and desktop apps unaffected. The downside is: it will no longer work once Microsoft changes only one character in the Teams Client for Linux User agent string. Unfortunately, putting a regular expression like Linux.*MicrosoftTeams.*Electron into the field is not possible, neither is it possible to specify a filter like User Agent string contains Linux AND User Agent string contains MicrosoftTeams AND User Agent string contains Electron because there can be only one User Agent string contains expression in the filter. Putting MicrosoftTeams or MicrosoftTeams-Preview into the field is an option because these strings do not occur in the User agent string for the Windows or MacOS Teams client.
In any case, whatever value you specify for the User Agent string filter expression, the matching of the access policy needs to be monitored closely as Microsoft might change the User Agent string for its Teams Clients anytime.
Once an access policy with the above filter is in place, the Microsoft Teams Client for Linux is blocked:
A spoofed browser session is also blocked:
The MCAS activity log shows the blocked access for the Microsoft Teams Client for Linux and for the spoofed browser session and also shows the allowed access for the non-spoofed browser session:
Azure AD Stuff 