Summary
Microsoft has addressed an authorization misconfiguration for multi-tenant applications that use Azure AD, initially discovered by Wiz, and reported to Microsoft, that impacted a small number of our internal applications. The misconfiguration allowed external parties read and write access to the impacted applications.
-
Microsoft immediately corrected the misconfiguration and added additional authorization checks to address the issue and confirmed that no unintended access had occurred.
-
Microsoft has confirmed that all the actions outlined by the researchers are no longer possible because of these fixes.
-
Microsoft made additional changes to reduce the risk of future misconfigurations.
Customers with multi-tenant applications should follow the security guidance outlined in this article to protect their applications from unauthorized access. As always, Microsoft additionally encourages all customers follow these security best practices.
Technical Details
Microsoft Azure Active Directory applications can be configured as single-tenant or multi-tenant. Multi-tenant applications enable developers to make their apps available across organizational boundaries, enabling a variety of business-to-business, business-to-consumer, and complex organization scenarios. Applications configured as multi-tenant require additional authorization (AuthZ) checks to ensure that only those entities that should be allowed access are permitted. This need for additional authorization checks is also true of applications that are utilizing features such as Azure App Service Authentication to handle their Azure AD authentication.
In this specific case some apps were incorrectly configured as multi-tenant applications and other multi-tenant applications did not correctly handle authorization checks and may have incorrectly authorized access to a resource in a tenant from a client that was not explicitly registered in that tenant. Part of implementing correct authorization checks is for an application to check for a service principal in the access token provided by the client.
Please see the guidance below to protect your multi-tenant applications from unauthorized access.
Security Enhancements
Azure AD has been updated to stop issuing access tokens to clients that are not registered in the resource tenants. This prevents this issue from happening even if an application does not correctly handle the authorization check.
- This functionality has been disabled for more than 99% of customer applications. For the remainder of multi-tenant resource applications that rely on access from clients without a service principal, we have provided instructions in an Azure Service Health Security Advisory to Global Admins (Azure Portal and email) and in the Microsoft 365 Message Center. All customers with multi-tenant applications still need to follow the security guidance below.
Azure App Service Authentication has introduced new configuration options to add checks for the presence of a client registration (Service Principal) and for the tenant ID matching an allow-list. These can be used for additional security for multi-tenant applications.
Guidance on securing your multi-tenant applications that use Azure AD
Below are some steps you can take, based on your role, to protect your applications from unauthorized access.
If you are an admin:
-
Inventory all applications in your tenant registered as multi-tenant. Review whether each needs to be used outside the tenant where it is registered. If not, update the audience to restrict to the application’s tenant. This will eliminate accidental access from outside the tenant.
-
Continue to follow security best practices. Review and monitor sign-in logs for your tenant. Use the “Assignment required” feature to restrict access to only entities that are explicitly assigned to a resource app. To manage external access to resources in your tenant, implement conditional access policies.
If you are an application developer:
-
Review your Azure AD multi-tenant application’s authorization logic and make sure you implement recommended authorization checks.
-
For applications using the App Service Authentication feature, which by default only provides authentication, take explicit steps to include authorization logic. App Service Authentication allows some additional checks to be configured as part of the authorization logic for the app. Your application can also perform authorization checks by working with the claims from code.
-
Ensure that you have authorization logic based on object ID (‘oid’) or other security identifiers.
-
Update customer deployment procedures to include steps to create a Service Principal for each client app to allow access to the resource application.
-
Ensure your application uses Microsoft Authentication Library (MSAL) for authentication and token management.
Acknowledgments
We appreciate Wiz responsibly disclosing this finding which gave us the opportunity to investigate and address the issues raised. We encourage all researchers to work with vendors under Coordinated Vulnerability Disclosure (CVD) and abide by the rules of engagement for penetration testing to avoid impacting customer data while conducting security research.
References
Questions? Open a support case through the Azure Portal at aka.ms/azsupt.
Wiz’s Blog Site: https://www.wiz.io/blog/azure-active-directory-bing-misconfiguration