Bypass sensitivity label restrictions with mobile Edge and conditional access policies

Vulnerability assesment by MSRC

Scope of the security vulnerability

This article describes a security vulnerability that allowed an authenticated Microsoft 365 user to bypass additional protective measures based on sensitivity labels to download content to an unmanaged device. The user could not access files that she otherwise would not have access to.

If you don’t want a recap on what sensitivity labels are or how to setup the environment you can skip ahead to the test result or to the findings.

Background information

The intended audience for this blog are experienced Microsoft 365 administrators, but I still want to enable as many interested in the topic. The next few paragraphs explain the technologies used in the environment.

What are sensitivity labels

Microsoft Information Protection in Microsoft 365 uses sensitivity labels to classify files or container and apply different protection settings to those entities.

On a file level those protections can be any of the following

• Apply encryption to the data
• Mark content with a watermark (e.g. confidential)

It is also possible to protect files within a container with additional settings. A container refers to a Microsoft Teams, Microsoft 365 groups or a SharePoint sites.

• Privacy (public or private) of teams sites and Microsoft 365 groups
• Control external user access
• Restrict external sharing from SharePoint sites
• Access from unmanaged devices

A label has to be created and published to all the users that should be able to use it. After that it can be assign to files and containers.

What is an unmanaged device

Microsoft defines unmanaged devices either as

or

depending where you look. But the difference is negligible and not important for the vulnerability. Becaus in both cases the device has to be enrolled to Intune or has to be hybrid Entra ID (Azure AD) joined.

Enrollment in Intune

Intune is Microsofts Mobile Device Management solution and can manage a wide range of operating systems and platforms.

Device enrollment is the process of onboarding a given device to this platform and gain the ability to enforce certain policies. Those can range from enabling encryption, to setting password policies or pre-installing certain company apps.

After a device is enrolled the device compliance policy assigned to the device checks every defined settings and reports the device as either compliant or noncompliant to Intune.

Because the IT department has control of the device and the data on the device, those devices are more trusted than an unmanaged device, e.g. a personal smartphone.

Through enrollment restrictions the IT department can further lock down who is able to enroll which kind of device. This locks down who is able to create a more trusted device.

Hybrid Azure AD joined

A hybrid Entra ID (Azure AD) joined device has to be both of the following

• Joined to the on-premises Active Directory
• Joined to Azure Active Directory

By definition a hybrid Entra ID (Azure AD) joined device can only be a Windows device. Officially supported are the following operating systems

• Windows 7
• Windows 8.1
• Windows 10
• Windows Server 2008 + R2
• Windows Server 2012 + R2
• Windows Server 2016
• Windows Server 2019

Mobile devices like smartphones are, by any of the mentioned definitions, never hybrid AAD joined.

Conditional Access

Conditional Access is a feature of Azure Active Directory and enables the IT department to define fine grained rules that are applied when a user signs in. Those rules can be different based on the user, device type and other factors like location.

Every Entra ID (Azure AD) sign-in is verified by Conditional Access and besides of having the option to require multi factor authentication when accessing a specific service, it is also possible to require the use of approved apps or enforce session settings like application enforced restrictions.

This feature is a key component of Microsofts Zero Trust vision.

Environment setup

The vulnerable environment has quite a few configuration requirements. Let’s get to work.

Licenses

• Office 365 license to use SharePoint
• Azure Active Directory Premium P1 to apply sensitivity labels

Test user

Create a user and assign the necessary licenses to the user. Do not forget to set the usage location before you assign the licenses.

SharePoint

You have to enable MicrosoftAzure Information Protection in your SharePoint tenant. In addition you can disable legacy authentication to make sure that only modern authentication protocols are used.

# Install module
Install-Module -Name Microsoft.Online.SharePoint.PowerShell
# Login
Connect-SPOService https://TENANTNAME-admin.sharepoint.com/
# Enable Microsoft/Azure Information Protection (AIP)
Set-SPOTenant -EnableAIPIntegration $true
# Optional: Disable legacy authentication
Set-SPOTenant -LegacyAuthProtocolsEnabled $false
#View results
Get-SPOTenant | Select EnableAIPIntegration, LegacyAuthProtocolsEnabled

Azure AD

In your Entra ID (Azure AD) configuration you must set EnableMIPLabels to true to enable Microsoft Information Protection (MIP) for Unified Groups.

#Install module
Install-Module AzureADPreview
# Login
Connect-AzureAD
# Get template configuration for Unified Groups
$TemplateId = (Get-AzureADDirectorySettingTemplate | where { $_.DisplayName -eq "Group.Unified" }).Id
$Template = Get-AzureADDirectorySettingTemplate | where -Property Id -Value $TemplateId -EQ
# Generate default settings
$Setting = $Template.CreateDirectorySetting()
# Enable MIP Labels
$Setting["EnableMIPLabels"] = "True"
New-AzureADDirectorySetting -DirectorySetting $Setting

Sensitivity Label

Access the Microsoft 365 compliance center to create a new sensitivity label.

You can freely choose a name and description.

For the scope of this label you select “Groups & sites”.

External sharing and Conditional Access settings is the only relevant protections setting for this demo.

Chose “Block access” for unmanaged devices and safe the label.

Label policy

The next step is to publish the policy to your test user. To do this you have to create a label policy.

Choose your newly created label to be included in your label policy.

Apply this policy to a test user.

Do not configure any other settings since they are not needed.

Think of a nice name for the label policy and save it.

You newly created label is now published but initially it needs to be synced to Entra ID (Azure AD).

Sync sensitivity labels to Entra ID (Azure AD)

# Install module
Install-Module ExchangeOnlineManagement
# Login
Connect-IPPSSession
# Sync Labels with Azure AD
Execute-AzureAdLabelSync

Microsoft Teams / Unified Group

To save the sensitive company data we utilize a Microsoft Teams (Unified Group) and apply the sensitivity label to it.

You can check if this was successful using the Teams Admin Center, the Entra ID (Azure AD) portal or the Exchange Online PowerShell module.

Conditional Access policies

Now the only configurations left are the conditional access policies.

Enforce app restriction

The first one is to enforce app restrictions when using SharePoint, which is a requirement that the block unmanaged devices configuration works.

Create a new Conditional Access Policy and apply it only to your test user.

Also make sure to only select Office 365, Office 365 Exchange Online, and Office 365 SharePoint as cloud apps.

And last but not least select “Use app enforced restrictions” in the session section, enable the policy and save it.

Require approved client app

The second policy should apply to all cloud apps, but only when used on a mobile device.

If this condition is true it must make sure only approved client apps can be used.

Approved apps also support the Intune App protection policies, but this feature is optional and requires additional licensing.

Recap and expected behavior

Let’s pause for a second and break down the configuration and clarify the expectations.

• There is a sensitivity label that restricts access to Unified Groups from unmanaged devices
• A Teams Unified Group is created and has this sensitivity label applied to it.
• All the necessary steps and configurations, including the conditional access policy for “app enforced restrictions” are in place
• Also we safeguard our data on mobile devices because we only allow approved client apps

The image above outlines two ways to access a document, that both should not be possible.

The first client is a mobile user, in our tests a Android 10 device, with Microsoft Edge installed. It is not managed through Intune.

The second client is a Windows 10 desktop with Chromium based Edge, also unmanaged and not Entra ID (Azure AD) hybrid-joined.

Observed behavior

When I tried to access the data using the Windows 10 client and Microsoft Edge the following error was displayed.

But when I tried to access the protected file on my mobile device, there was no error message. I could access the file.

So instead of blocking the access to the document, I could read, edit, and download it on a completely unmanaged device.

Testing

To find the root cause of this error, I defined each configuration variable a different letter and then created test cases with the different configurations put together.

While testing I deleted all data from the apps, removed the account from the Android device and unregistered it from Entra ID (Azure AD) after each test case to make sure there is no false positive through cached credentials or temporary files.

Installed apps

Configuration variables

*CAP = Conditional Access Policy

Test cases and results

The following lists all test configurations I set up, as well as the tested apps and the result for each tested app and configuration. Not all apps where tested in every configuration.

Test case	Configuration	Mobile Edge	Mobile Chrome	Mobile Word	Mobile Office	Mobile Teams	Windows 10 Edge
#1	A	⛔	⛔	⛔	❔	❔	⛔
#2	A+B	⛔	n/a	❔	❔	❔	n/a
#3	A+B+C	☠️*	n/a	⛔	⛔	⛔	n/a
#4	A+B+C+D	⛔	n/a	❔	❔	❔	n/a
#5	A+B+C+D+E	☠️	⛔	☠️	☠️	☠️	n/a
#6	A+C+D	Sign-In required	Redirect to Edge	❔	❔	❔	n/a
#7	A+B+E		n/a	n/a	n/a	n/a	n/a
#8	A+B+C+E	☠️	n/a	☠️	☠️	☠️	n/a
#9	A+C	n/a	⛔	⛔	⛔	⛔	n/a
#10	A+E	n/a	Redirect to Edge				n/a
#11	A+C+E	n/a	Redirect to Edge	☠️	☠️	☠️	n/a

Symbol	Explanation
⛔	Access denied (good)
☠️	Access granted (bad)
	Enforce AAD device register
❔	Not tested
n/a	Not applicable

Test Case #1 - Baseline

Expected behavior: Access denied
Observed behavior: Access denied

Configuration Test :

• Sensitivity label applied to O365 Group & CAP “Enforce app restriction”

The user can’t access the document and is presented with the following error message

Test Case #2

Expected behavior: Access denied
Observed behavior: Access denied

Configuration Test :

• Sensitivity label applied to O365 Group & CAP “Enforce app restriction”
• User is signed-in to Edge with the work account

The user can’t access the document and is presented with the following error message

Test Case #3

Expected behavior: Access denied
Observed behavior: Access granted partially

Configuration:

• Sensitivity label applied to O365 Group & CAP “Enforce app restriction”
• User is signed-in to Edge with the work account
• The mobile device is AAD registered

The user can access a document within the protected Unified group when using Microsoft mobile Edge and is not restricted by any other mechanism to download the file.

The other Microsoft mobile apps like Word, Teams and Office where prevented from accessing the file.

Test Case #4

Expected behavior: Access denied
Observed behavior: Access denied

Configuration:

• Sensitivity label applied to O365 Group & CAP “Enforce app restriction”
• User is signed-in to Edge with the work account
• The mobile device is AAD registered
• Intune Application Protection policy applied to Edge Browser

The user can’t access the document and is presented with the following error message

Test Case #5

Expected behavior: Access denied
Observed behavior: Access granted

Configuration:

• Sensitivity label applied to O365 Group & CAP “Enforce app restriction”
• User is signed-in to Edge with the work account
• The mobile device is AAD registered
• Intune Application Protection policy applied to Edge Browser
• CAP: Enforce approved app on mobile devices

The user can access the document within the protected Unified group and but is restricted by the applied Intune App protection policy. Should this policy deny any local storage, the data cannot be downloaded to the device.

Test Case #6

Expected behavior: Access denied
Observed behavior: Access denied

Configuration:

• Sensitivity label applied to O365 Group & CAP “Enforce app restriction”
• The mobile device is AAD registered
• Intune Application Protection policy applied to Edge Browser

The user is presented with an message that she has to sign-in to Microsoft Edge browser with her work account to access the data.

Chrome redirects the user to Microsoft Edge.

Test Case #7

Expected behavior: Access denied
Observed behavior: Access denied

Tested Apps	Results
Mobile Edge

Configuration:

• Sensitivity label applied to O365 Group & CAP “Enforce app restriction”
• User is signed-in to Edge with the work account
• CAP: Enforce approved app on mobile devices

The user is presented with an message that she has register her device to access the data.

Test Case #8

Expected behavior: Access denied
Observed behavior: Access granted

Configuration:

• Sensitivity label applied to O365 Group & CAP “Enforce app restriction”
• User is signed-in to Edge with the work account
• The mobile device is AAD registered
• CAP: Enforce approved app on mobile devices

The user can access the document within the protected Unified group and is not restricted by any other mechanism to download the file.

This works with all tested mobile apps.

Test Case #9

Expected behavior: Access denied
Observed behavior: Access denied

Configuration:

• Sensitivity label applied to O365 Group & CAP “Enforce app restriction”
• The mobile device is AAD registered

The user can’t access the document and is presented with the following error message

Test Case #10

Expected behavior: Access denied
Observed behavior: Access denied

Configuration:

• Sensitivity label applied to O365 Group & CAP “Enforce app restriction”
• CAP: Enforce approved app on mobile devices

Tested Apps	Results
Mobile Chrome
Mobile Word
Mobile Office
Mobile Teams

The user is presented with a message that she has register her device to access the data.

Test Case #11

Expected behavior: Access denied
Observed behavior: Access granted

Configuration:

• Sensitivity label applied to O365 Group & CAP “Enforce app restriction”
• The mobile device is AAD registered
• CAP: Enforce approved app on mobile devices

The user can access the document within the protected Unified group and is not restricted by any other mechanism to download the file.

Findings

There was one two configuration option where the Microsoft Information Protection restrictions, applied through Sensitivity labels, are ignored and could by bypassed

1. The user uses mobile Edge browser, has the device Entra ID (Azure AD) registered and is signed into Edge
   Test case #3
2. The user has the device Entra ID (Azure AD) registered and the the conditional access policy enforces approved apps
   Test cases #5, #8 and #11

It is not enough to just Entra ID (Azure AD) register the device as test case #9 shows. The Conditional Access Policy has to enforce approved apps #11 to allow to bypass.

The documented definition of a unmanaged device as devices …

that aren’t hybrid Entra ID (Azure AD) joined or enrolled in Intune

…still holds and this is not poor documentation.

Test cases #1, #3, and #9 also demonstrates that the use of an approved app alone is also not enough to access the protected data.

The exact root cause cannot be determined without deeper access to the underlying code.

Implications, countermeasures and detection

After applying the configuration outlined above to the Microsoft 365 environment, the data is not as protected as the admin and end user might think. An attacker with foothold and access could exfiltrate data that otherwise would be protected.

To counter this vulnerability you have few options:

Disable Azure AD device registration

Because Entra ID (Azure AD) device registration is used in many BYOD scenarios, it is not uncommon that this setting is not restricted. For certain features like passwordless Phone sign-in to work it is a perequipment to be enabled. Also if the company uses Intune it is not possible to restrict this setting.

This makes it almost impossible to disable this setting in most environments.

Also since you are using sensitivity labels to protect certain sensitiv data, you only want to be restrictive on some information. You still want to enable the user to access other non sensitive data. Otherwise block non-managed devices with conditional access.

Use Intune App Protection policies

Intune App Protection policies are a great use case for unmanaged devices. The defined protection policy is applied to supported apps when the users signs in the first time.

In those policies you can define e.g. where the user can store data, if she can take screenshots or protect the apps with an additional PIN that has to be entered after the app is not used for some time.

This solution comes at a cost, since you will need additional licenses for every mobile user.

Conditional Access authentication context

Use Conditional Access authentication context (preview) instead of “Enforce app restriction”. This feature is based on conditional access and you are able to more granularly select the grant conditions.

• Require multi-factor authentication
• Require device to be marked as compliant
• Require Hybrid Entra ID (Azure AD) joined device
• Require approved client app
• Require app protection policy

The conditions marked would represent the same level of protection as the “Block unmanaged devices” feature.

I had not evaluated this in more depth, so you should test the your scenarios before relying on this as a fix.

Also be aware that this feature requires a Microsoft 365 E5 or Microsoft 365 E5 Compliance license for each user accessing a labeled site. So this option gets quite expensive fast.

Detection

The device is reported as “Entra ID (Azure AD) registered” in the Entra ID (Azure AD) sign-in logs, but is also reported as not managed and therefore not compliant.

Both conditional access policies are evaluated successfully.

Since there is no information about which site the users has accessed in the sign-in logs, you would have to correlate Office 365 audit logs with the device id and the management state of the device.

Using Microsoft Sentinel and advanced hunting queries it might be possible to create a custom alert.

let SensitivDataIsAccessed = OfficeActivity
| where  Operation in ('FileAccessed', 'FilePreviewed', 'FileDownloaded')
| where Site_Url startswith "https://YOURTENANT.sharepoint.com/PROTECTED-SITE/"
| project UserAgent, UserId, ClientIP, OfficeObjectId;
SigninLogs
| join (SensitivDataIsAccessed) on $left.UserPrincipalName == $right.UserId, $left.IPAddress == $right.ClientIP
| project UserPrincipalName, DeviceId = DeviceDetail.deviceId , DevicetrustType = DeviceDetail.trustType, operatingSystem = DeviceDetail.operatingSystem,displayName = DeviceDetail.displayName, countryOrRegion = LocationDetails.countryOrRegion, OfficeObjectId

The query above lists every access to a manually defined sensitiv SharePoint site and correlates those with the sign-in data. It only presents data related to the user, the device, sign-in location and accessed data. This may help in identifying questionable access patterns.

Final thoughts

This vulnerability is a good example of how complex and interdependent features can themselves become a security problem.

Even if the manufacturer promises a certain level of security, it is important to challenge these claims before using the feature in production.

Disclosure timeline

2021-03-29 - The first time I encounter this behavior
2021-06-01 - Findings are send to Microsoft Security Response Center (MSRC)
2021-06-03 - MSRC case is created
2021-06-08 - Provided additional testing results
2021-06-09 - Case is closed because “this is by design”
2021-06-10 - Requested additional information on this decision
2021-06-16 - MSRC requests a fiddler trace
2021-06-17 - Provided requested information and received confirmation that this is not “by design”
2021-08-02 - Fix is applied, the exact date was not disclosed to me. This is the date I received the information after requesting an update
2021-08-03 - Out-of-Scope notification from the Microsoft Bounty Program
2021-08-30 - Public disclosure of the findings

Acknowledgements

This research was conducted in close collaboration with Fielmann. A big thanks to Ingo Bente ([T] [L]) and Gerald Lasch ([T] [L]) for their support.

Links

• Microsoft Information Protection in Microsoft 365
• Learn about sensitivity labels
• Enable sensitivity labels for Office files in SharePoint and OneDrive
• Assign sensitivity labels to Microsoft 365 groups in Azure Active Directory
• Use sensitivity labels to protect content in Microsoft Teams, Microsoft 365 groups, and SharePoint sites
• Control access from unmanaged devices
• What is device enrollment in Intune?
• Use compliance policies to set rules for devices you manage with Intune
• Set enrollment restrictions
• Hybrid Entra ID (Azure AD) joined devices
• What is Conditional Access?
• How to: Require approved client apps for cloud app access with Conditional Access
• Zero Trust Deployment Guide for Microsoft Azure Active Directory
• Microsoft 365 compliance center
• Microsoft Teams admin center
• Azure Active Directory admin center
• Control device access across Microsoft 365
• Require approved client app
• Register your personal device on your organization’s network
• Conditional Access authentication context (preview)
• Manage site access based on sensitivity label