Power Platform Privilege Escalation

Summary

In early 2023, Secureworks® Counter Threat Unit™ (CTU) researchers discovered an Azure Active Directory (Azure AD)[1] application with an abandoned reply URL address. This application is related to Microsoft Power Platform (a low-code platform). An attacker could leverage this abandoned URL to redirect authorization codes to themselves, exchanging the ill-gotten authorization codes for access tokens. The threat actor could then call Power Platform API via a middle-tier service and obtain elevated privileges.

CTU researchers reported the issue to Microsoft at the beginning of April 2023. Microsoft quickly confirmed privilege escalation was possible and assigned a critical severity rating. Within 24 hours of the CTU notification, Microsoft addressed the issue by removing the identified abandoned reply URL from the Azure AD application.

Update: On August 28, CTU analysis revealed additional details about limitations that would impact customers' ability to mitigate this issue directly.

Discovery

CTU researchers developed a scanner that searches for abandoned reply URL values in Azure AD applications. The scanner then confirms if those URLs are available for registration in the impacted Azure services (see Figure 1).

Figure 1. Code snippet from the scanner tool. (Source: Secureworks)

An identified abandoned Dynamics Data Integration app reply URL was associated with the Azure Traffic Manager profile (dataintegratorui . trafficmanager . net). As with many first-party Microsoft applications, this application was pre-consented. As a result, no additional consent was required to stage the attack. The legitimate use for the app is to facilitate data integration inside Power Platform between various Power Platform apps and Dataverse. Dataverse provides a secure way to store and manage Power Platform-related data.

We observed how the legitimate version of the client-side app (https: //dataintegrator . trafficmanager . net/dualWrite) uses the getExternalData API endpoint on the middle-tier service (see Figure 2). This method defines what is essentially a proxied request to a limited set of downstream APIs.

Figure 2. Legitimate traffic pattern, omitting the Azure AD steps. (Source: Secureworks)

As shown in Figure 3, requests are made against the middle-tier service (https: //<middletierservice>/api/GetExternalData) via client-side calls based on the client-side code loaded from the traffic manager front end.

Figure 3. POST request against the middle-tier service. (Source: Secureworks)

The request pattern consists of a body payload of 'url', 'requestData', and 'requestType' (see Figure 4), and a requested token 'audience' (see Figure 5).

Figure 4. Body payload defined in Azure Traffic Manager client-side call. (Source: Secureworks)

Figure 5. Requested token audience in Azure Traffic Manager client-side call. (Source: Secureworks)

This access token was likely then exchanged using on-behalf-of flow in the middle-tier service. The middle-tier service only receives the access token in the authorization header, so it does not have a refresh token to request new access tokens. We discovered that the Power Platform downstream API (https: //api . bap . microsoft . com) (see Figure 6) and the Azure AD Graph API (https ://graph . windows . net) were accessible from the middle-tier service.

Figure 6. Request from the client to the middle-tier service identifying which intended API to call. (Source: Secureworks)

Power Platform API

Power Platform API lets users manage environments, change environment settings, and query capacity consumption. As a result, it is a prime target for threat actors seeking privileged access.

We demonstrated privileged access on the Power Platform API by elevating the privileges of an existing service principal. The goal was not to further abuse this privileged access but to demonstrate that privileged actions such as elevating applications and deleting environments are possible due to the access gained via the middle-tier service. An attacker with malicious intent and adequate knowledge of the Power Platform admin API operations could likely develop additional scenarios.

Create application user

We first requested the system administrator role for an existing service principal (see Figure 7) using the downstream API (see Figure 8).

Figure 7. Code to acquire the system administrator role for an existing service principal. (Source: Secureworks)

Figure 8. Power Platform API confirming addition of existing service principal to system administrator role. (Source: Secureworks)

Delete environment

We then used the downstream API to send an HTTP 'delete' request referencing the environment to be destroyed (see Figure 9).

Figure 9. Request to delete an environment. (Source: Secureworks)

This request deleted the environment (see Figure 10). Deletion can be confirmed from the Power Platform admin portal.

Figure 10. Log showing deleted environment. (Source: Secureworks)

Azure AD Graph API

Delegated permissions granted to Azure AD Graph API for the middle-tier service seem to be limited to a subset of read-only permissions (User.Read). This configuration provides some protection when the tokens compromised via the application belong to a highly privileged user because the attacker would still not have write access.

Regardless of the limited scope, the attacker can use Azure AD Graph API access to gather information about the environment to stage additional attacks.

Read Azure AD

In this scenario, we used the request in Figure 11 to gather information from the Azure AD Graph API (see Figure 12).

Figure 11. Request for information from the Azure AD Graph API. (Source: Secureworks)

Figure 12. Response from the Azure AD Graph API. (Source: Secureworks)

Flow of the attack

Figure 13 outlines the attack, highlighting the significant steps.

Figure 13. Attack flow. (Source: Secureworks)

1. A victim accesses a malicious link. Azure AD redirects the victim's system to the reply URL claimed by the attacker and includes the authorization code in the URL parameter.
2. The malicious server exchanges the authorization code for the access token.
3. The malicious server calls the middle-tier service using the access token and intended API.

We focused our investigation on the middle-tier service calling the downstream API but later discovered that it was also possible to directly exchange the authorization codes for access tokens without relaying these tokens to the middle-tier service. The original focus was the most beneficial approach for research purposes because it allowed us to understand why and how the APIs are used.

Communication with Microsoft

CTU researchers reported this privilege escalation vulnerability to the Microsoft Security Response Center (MSRC) on April 5, 2023. The MSRC immediately investigated the issue and released an update to address it on April 6.

Conclusion

Keeping track of Azure AD applications' reply URLs is important to avoid the attack described in this analysis. CTU researchers have no evidence that this issue has been abused as of this publication. Because the identified application is managed by the vendor, organizations cannot mitigate this issue directly. The only option would be deleting the service principal, which would nullify any legitimate use of the app. We recommend monitoring for abandoned reply URLs.

August 28 update

We conducted additional research after publishing this analysis and determined that even deleting the first-party app would not address this issue because the app is pre-consented for all tenants. Organizations typically do not modify issuance settings directly from first-party apps. However, disabling users’ sign-in ability (see Figure 14) would block the app from issuing a token. This change would also nullify any legitimate use of the app.

Figure 14. Option to disable sign-in ability. (Source: Secureworks)

[1] In July 2023, Microsoft announced that Azure AD would be renamed Microsoft Entra ID.