Microsoft admits “insecure pattern” in Azure AD exposed customers to risk of data loss, account takeover
"The risk is mainly with multi-tenant applications where this misconfiguration could result [in] account and privilege escalation" -- here's what you need to do.
Microsoft says it has “developed mitigations” for an Azure Active Directory vulnerability dubbed n0auth that under certain circumstances let an attacker gain full target account takeover by simply replacing an email address – in their own attacker-owned Azure AD admin account.
The “insecure pattern” exposed Azure AD customers to data leakage and escalation of privileges risk, Microsoft admitted in a June 20, 2023 post, adding that “the risk is mainly with multi-tenant applications where this misconfiguration could result [in] account and privilege escalation.”
How n0auth works
Microsoft describes the Azure AD authentication bug as follows: "AAD users without a provisioned mailbox can have any email address set for their Mail (Primary SMTP) attribute. This attribute is not guaranteed to come from a verified email address. An AAD user can be created or modified by a privileged user with an email which impersonates another AAD user. When an application uses an unverified email claim for authorization, a bad actor has the potential to gain unauthorized access by issuing a token to impersonate a valid AAD user."
Descope added that to exploit the issue: "The attacker accesses their Azure AD account as admin.
- The attacker changes the “Email” attribute to the victim’s email address
- Since Microsoft does not require the email change to be validated on Azure AD, this is all the preparation the attacker needs.
The Azure AD authentication design flaw, n0auth, was identified and reported by security researchers at Descope, a California-based authentication and user management platform startup.
Their testing found no shortage of vulnerable organisations. The configurations that left customers exposed were against best practice and came despite Microsoft documentation having urged customers not to “use the ‘email’ claim as a unique identifier in the access token."
Exposed organisations included a “leading multi-cloud consulting provider” and a “publicly traded customer experience company” Descope said, with Microsoft adding that it had also identified “several multi-tenant applications” that were exposed to risk and notified their owners.
What does Microsoft recommend?
Microsoft recommends reviewing application source code and determining whether the following patterns are present:
- A mutable claim, such as
email, is used for the purposes of uniquely identifying a user - A mutable claim, such as
emailis used for the purposes of authorizing a user's access to resources
These patterns are considered insecure, as users without a provisioned mailbox can have any email address set for their Mail (Primary SMTP) attribute. This attribute is not guaranteed to come from a verified email address. When an email claim with an unverified domain owner is used for authorization, any user without a provisioned mailbox has the potential to gain unauthorized access by changing their Mail attribute to impersonate another user. Learn more.
The Azure AD authentication design flaw comes just 12 weeks after security researchers at cloud security company Wiz demonstrated how Microsoft itself had fallen prey to AAD’s configuration challenges, and “inadvertently exposed internal applications to external attackers” – letting them manipulate search results on Bing.com and perform XSS attacks on Bing users, “potentially exposing customers’ Office 365 data.”
Descope added that as a result of its disclosure of the Azure AD authentication issue on April 11, "Microsoft is introducing two new claims to mitigate cases when nOAuth is used for cross-tenant spoofing.
"These features will enable apps to verify whether an email claim contains a domain-verified email address and redact email claims when the email domain is unverified," the company added on June 20.
Microsoft said it "has identified several multi-tenant applications with users that use an email address with an unverified domain owner. Although unverified email addresses do not pose a risk to applications that do not utilize email claims for authorization purposes, these application owners have been notified and were provided with guidance on how to modify their applications, if applicable. If you did not receive a notification, your application has not consumed email claims with unverified domain owners. To protect customers and applications that may be vulnerable to privilege escalation, Microsoft has deployed mitigations to omit token claims from unverified domain owners for most applications."
