Inhalt

Bypass sensitivity label restrictions with mobile Edge and conditional access policies

Vulnerability assesment by MSRC

Severity Important
Security Impact Security Feature Bypass

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.

Fixed
The issue has now been fixed by Microsoft and it is no longer possible to reproduce this behavior.

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

Microsoft Docs
[…]those not hybrid AD joined or compliant in Intune[…]

/bypass-sensitivity-label-restrictions/images/unmanagedDevices.png

or

Microsoft 365 compliance center
[…]that aren’t hybrid Azure AD joined or enrolled in Intune[…]

/bypass-sensitivity-label-restrictions/images/unmanagedDevices2.png

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 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 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 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 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.

/bypass-sensitivity-label-restrictions/images/UsageLocation.PNG

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
Notiz
Blocking legacy authentication is recommended when you limit access from unmanaged devices.

Azure AD

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

Warnung

The following code assumes you do not have any configuration in you Azure AD and creates a new configuration from the default template.

Do not do this in your production tenant, otherwise the current configuration is overwritten.

#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.

/bypass-sensitivity-label-restrictions/images/SensitivityLabelTooltip.png

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

/bypass-sensitivity-label-restrictions/images/SensitivityLabelScope.png

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

/bypass-sensitivity-label-restrictions/images/SensitivityLabelExternalSharingAndConditionalAccess.png

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

/bypass-sensitivity-label-restrictions/images/SensitivityLabelBlockAccess.png

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.

/bypass-sensitivity-label-restrictions/images/LabelPolicyLabels.png

Apply this policy to a test user.

/bypass-sensitivity-label-restrictions/images/LabelPolicyAffectedUsers.png

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

/bypass-sensitivity-label-restrictions/images/LabelPolicySettings.png

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

/bypass-sensitivity-label-restrictions/images/LabelPolicyName.png

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

Sync sensitivity labels to 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.

/bypass-sensitivity-label-restrictions/images/CreateTeam.png

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

/bypass-sensitivity-label-restrictions/images/CheckLabelPortals.png

/bypass-sensitivity-label-restrictions/images/CheckLabelPowerShell.png

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.

/bypass-sensitivity-label-restrictions/images/CAPAppEnforcedRestrictions.png

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.

/bypass-sensitivity-label-restrictions/images/CAPRequireApprovedClientApp.png

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

/bypass-sensitivity-label-restrictions/images/Expectation.png

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 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.

/bypass-sensitivity-label-restrictions/images/AccessDeniedWindows10.png

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

/bypass-sensitivity-label-restrictions/images/Bypass.png

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

/bypass-sensitivity-label-restrictions/images/ObservedBehavior.png

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.

Notiz
I also added the usage of Intune App Protection policies to the test case, since this was part of the original use case. I did not include it in the environment setup above, because it’s not needed to provoke the error, as you will see in the test results.

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

Installed apps

App Version
Company portal v5.0.5155.0
Microsoft Authenticator v6.2105.3263
Microsoft Edge v46.04.4.5157
Microsoft Teams v1416/1.0.0.2021055001
Microsoft Word v16.0.14026.20172
Microsoft Office v16.0.14026.20172
Google Chrome v90.0.4430.82
Outlook v4.2119.3

Configuration variables

Identifier Configuration
A Sensitivity label applied to O365 Group & CAP* “Enforce app restriction”
B User is signed-in to Edge with the work account
C The mobile device is AAD registered
D Intune Application Protection policy applied to Edge Browser
E Conditional Access Policy: Enforce approved app on mobile devices

*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.

Notiz
Configuration variable A is always part of the test cases, because it’s the minimum configuration requirement set by Microsoft to block unmanaged devices.
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 /bypass-sensitivity-label-restrictions/images/DeviceRegistration.png 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 /bypass-sensitivity-label-restrictions/images/DeviceRegistration.png /bypass-sensitivity-label-restrictions/images/DeviceRegistration.png /bypass-sensitivity-label-restrictions/images/DeviceRegistration.png n/a
#11 A+C+E n/a Redirect to Edge ☠️ ☠️ ☠️ n/a
Symbol Explanation
Access denied (good)
☠️ Access granted (bad)
/bypass-sensitivity-label-restrictions/images/DeviceRegistration.png 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”
Tested Apps Results
Mobile Edge
Mobile Chrome
Windows Chrome
Mobile Word

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

Warnung
Due to organizational policies, you can’t access this resource from this untrusted device.

/bypass-sensitivity-label-restrictions/images/TestCase_1.png

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
Tested Apps Results
Mobile Edge

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

Warnung
Due to organizational policies, you can’t access this resource from this untrusted device.

/bypass-sensitivity-label-restrictions/images/TestCase_2.png

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
Tested Apps Results
Mobile Edge ☠️
Mobile Word
Mobile Office
Mobile Teams
Info
After 2021-06-10 it was no longer possible to bypass Microsoft Information Protection with Edge in this test case.

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.

/bypass-sensitivity-label-restrictions/images/TestCase_3.png

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
Tested Apps Results
Mobile Edge

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

Warnung
Due to organizational policies, you can’t access this resource from this untrusted device.

/bypass-sensitivity-label-restrictions/images/TestCase_4.png

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
Tested Apps Results
Mobile Edge ☠️
Mobile Chrome
Mobile Word ☠️
Mobile Office ☠️
Mobile Teams ☠️

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.

/bypass-sensitivity-label-restrictions/images/TestCase_5.png

Test Case #6

Expected behavior: Access denied
Observed behavior: Access denied

Tested Apps Results
Mobile Edge
Mobile Chrome Redirect to Microsoft Edge

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.

/bypass-sensitivity-label-restrictions/images/ChromeRedirectToEdge.png

/bypass-sensitivity-label-restrictions/images/TestCase_6.png

Test Case #7

Expected behavior: Access denied
Observed behavior: Access denied

Tested Apps Results
Mobile Edge /bypass-sensitivity-label-restrictions/images/DeviceRegistration.png

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.

/bypass-sensitivity-label-restrictions/images/TestCase_7.png

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
Tested Apps Results
Mobile Edge ☠️
Mobile Word ☠️
Mobile Office ☠️
Mobile Teams ☠️

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.

/bypass-sensitivity-label-restrictions/images/TestCase_8.png

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
Tested Apps Results
Mobile Chrome
Mobile Word
Mobile Office
Mobile Teams

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

Can't open file
Document.docx maybe locked, in use, or you don’t have sufficient permissions.

/bypass-sensitivity-label-restrictions/images/TestCase_9.png

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 /bypass-sensitivity-label-restrictions/images/DeviceRegistration.png
Mobile Office /bypass-sensitivity-label-restrictions/images/DeviceRegistration.png
Mobile Teams /bypass-sensitivity-label-restrictions/images/DeviceRegistration.png

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

/bypass-sensitivity-label-restrictions/images/TestCase_10.png

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
Tested Apps Results
Mobile Chrome Redirect to Edge
Mobile Word ☠️
Mobile Office ☠️
Mobile Teams ☠️

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

/bypass-sensitivity-label-restrictions/images/TestCase_11.png

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 Azure AD registered and is signed into Edge
    Test case #3
  2. The user has the device Azure AD registered and the the conditional access policy enforces approved apps
    Test cases #5, #8 and #11

It is not enough to just 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 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.

Notiz

As requested from the Microsoft Security Response Center team I tested if this only applied to SharePoint Teams sites.

It did not. SharePoint communication sites where affected as well.

Implications, countermeasures and detection

Erfolg

As of the time of publishing this article the vulnerability is fixed and you don’t have to do anything. I verified all scenarios above and could no longer reproduce the vulnerability.

Still check out why it was nearly impossible to protect your data while the vulnerability was active.

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 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.

Zitat
Allow users to register their devices with Azure AD (Workplace Join). Enrollment with Microsoft Intune or Mobile Device Management for Office 365 requires Device Registration.If you have configured either of these services, ALL will be selected and the button will be disabled.

/bypass-sensitivity-label-restrictions/images/AzureADRegisterDevices.png

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.

/bypass-sensitivity-label-restrictions/images/AppProtectionPolicy.png

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 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.

/bypass-sensitivity-label-restrictions/images/CAAuthContext.png

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 “Azure AD registered” in the Azure AD sign-in logs, but is also reported as not managed and therefore not compliant.

/bypass-sensitivity-label-restrictions/images/SignInLogsDeviceInfo.png

Both conditional access policies are evaluated successfully.

/bypass-sensitivity-label-restrictions/images/SignInLogsDeviceCA.png

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 Azure 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.