Summary
In August 2022, Secureworks® Counter Threat Unit™ (CTU) researchers discovered a vulnerability in Azure Active Directory (Azure AD) that allowed a user to retain access to a targeted Security Assertion Markup Language (SAML) application after the user assignment was removed. Using a backdoor application that was given consent to access the SAML application, a malicious user could request SAML tokens despite the user assignment removal. By exploiting this vulnerability, a malicious user could establish persistence and elevate privileges on targeted SAML applications.
CTU™ researchers reported these findings to Microsoft on August 4. Microsoft addressed the issue with mitigations initially deployed on October 25.
Attack overview
Azure AD offers the option to configure SAML-based single sign-on (SSO) for multiple pre-integrated and customer-developed services (i.e., applications). When user assignment is required, users and groups must first be assigned to the application before they can access it.
When exploiting this vulnerability, the most lucrative target for a malicious user would be a SAML application that relies solely on Azure AD’s user assignment setting. In this scenario, the absence of user assignment enforcement in the SAML application could be exploited to provision a new user for the malicious user in the target service.
The flaw was triggered when chaining sign-in with additional application and certain parameters in the token request (see Figure 1). This use case was originally intended so that backend SAML APIs could be called from an OAuth 2.0 application.
Figure 1. Attack process. (Source: Secureworks)
-
The malicious user requests an Azure AD access token for the additional application.
- The additional application requests a token for the SAML application using on-behalf-of flow. The request payload includes the parameters listed in Figure 2.
Figure 2. Parameters included in request payload. (Source: Secureworks)Chaining steps 1 and 2 bypasses the user assignment setting. The token generated in step 1 is used in the ‘assertion’ parameter.
- The request response emits the SAML token.
Proof of concept
In the proof-of-concept (PoC) scenario, a malicious user leverages a backdoor application to access any existing SAML applications that the malicious user was assigned when the backdoor application was configured. The malicious user retains access via the backdoor to any SAML application after their access is removed.
- The malicious user creates a new Azure AD application to use as the backdoor. They then consent it to any existing SAML application for which they want to receive tokens after the user assignment is removed. In the example shown in Figure 3, the malicious user uses a backdoor application named “UnPrivilegedUserSAMLattack2” to access a generic application called “SAML app” for which the malicious user had an existing user assignment.
Figure 3. Using a backdoor to compromise a SAML application. (Source: Secureworks) - The application administrator removes the malicious user from the user assignment in the existing SAML application (see Figure 4).
Figure 4. Removing the malicious user from the SAML application user assignment. (Source: Secureworks) - The malicious user requests tokens for the SAML application using the application configured in step 1.
The backdoor application used in this PoC requests tokens by leveraging an unrelated app retrofitted with malicious code added to its getCode.js file. The lines referencing the requested token contain the following vulnerable parameter combination that bypasses the user assignment verification:
"requested_token_type":"urn:ietf:params:oauth:token-type:saml2",
"requested_token_use":"on_behalf_of"
Evaluation of SAML tokens
The objective of the attack is to acquire a SAML token with a valid signature, issuer, audience, and claims (see Figure 5). The malicious user receives a SAML token comparable to one that is emitted using a legitimate access pattern, despite the lack of user assignment for the application. Testing concluded that additional claims configured for the SAML application, such as groups, were included in the maliciously obtained SAML token.
Figure 5. Attributes of a maliciously acquired SAML token. (Source: Secureworks)
Exploitation requirements
While the vulnerability was trivially exploitable, the malicious user needed a deep understanding of Azure AD applications and their configurations. The malicious user had to backdoor applications while they possessed a valid user assignment. The following knowledge is required to exploit this issue:
- Understanding on-behalf-of flows in Azure AD.
- Understanding the use of non-standard flows to request a SAML token with a JWT.
- Understanding Azure AD application consents and application permissions.
- Understanding the use of SAML tokens outside the normal use pattern. The PoC code abuses a CLI application with device code flow to gain a JWT, and later exchanges it for a SAML token using the on-behalf-of pattern “<->”. This technique differs from the typical use case of having a web browser receive the SAML token via interfacing directly the browser application.
Communication with Microsoft
CTU researchers reported their initial findings about this vulnerability to Microsoft on August 4, 2022 and provided additional details on October 7. Microsoft confirmed the attack pattern on October 10 and categorized it as an “important” elevation of privilege issue. Microsoft addressed the issue in mitigations initially deployed on October 25 and provided the following response:
Microsoft has fixed an issue in the Azure Active Directory (Azure AD) OAuth2.0 protocol access token request when those requests are made by middle-tier applications who in turn use Security Assertion Markup Language (SAML) based authorization to access back-end APIs. Under certain circumstances, this issue would allow users within a tenant inappropriate access to back-end application functionality.
Microsoft has fixed the issue. Only correctly configured users will have access to the functionality of the back-end application.
Conclusion
This flaw allowed a previously assigned user within the tenant boundary to retain access to an application via a backdoor application, even after the user assignment was removed. This behavior was only possible if the user had valid access when the backdoor application was configured.
The following mitigating factors applied to this vulnerability:
- Applications that support IdP-initiated SSO were affected. Applications that only support SP-initiated SSO were not affected because SP-initiated SSO requires the “inResponseTo” attribute in the SAML response.
- Applications that perform additional checks for user permissions or roles when receiving the token could prevent access even if the malicious user was able to bypass the user assignment on Azure AD.
To reduce risk to similar threats, CTU researchers recommend that organizations prevent users from registering their own applications in the Azure AD tenant.