The Long and Winding Road of DLP Patches in Power Platform

Connections are a big part of Power Platform. Huge part, even. They are, in a way, credentials to the different data sources we work with as makers, and which users are permitted to use (albeit via API calls,, but still - these are effectively credentials). Although we have some security guardrails to protect us from exploitable security misconfigurations, the very nature of these security mechanisms is sometimes itself vulnerable to misconfigurations or is incomplete by design.

Power Platform's Data Loss Prevention Policies component (also referred to as DLP) is one such security mechanism. However, It’s not really a DLP in the traditional sense - for a long time, it was more or less an on-off toggle mechanism for blocking connectors from being used by other different Power Platform resources.

Thankfully, its functionality, granularity, and robustness have been upgraded over time. That being said, it’s also had its share of bypasses discovered in the past. We recently revisited some of those bypasses, focusing on the notable ones from the last 2 years, and were happy to find some interesting new results.

(Very) Rough Timeline

In last year’s Black Hat, we discussed the possible risks introduced by Azure AD guest accounts in Power Platform, and how they can leverage undocumented APIs and other misconfigurations in Power Platform for gaining unauthorized access to sensitive business data and more.

Here are some of the methods we discovered to bypass the Power Platform DLP restrictions, which were also discussed in the Black Hat briefing mentioned above.

DLP Bypass #1 - Why Access The App When You Can Access The Connection Directly?

One of the issues we uncovered was a vulnerability that allowed users to bypass the Power Platform DLP entirely. In a nutshell, this bypass allowed users to access connections used by Power Apps despite any DLP restrictions, as these policies only blocked the connectors from being used within Power Apps—not from being accessed directly. If you would have accessed the connection directly, no DLP restriction would have been enforced.

DLP Bypass #2 - You Cannot Block That Which Already Exists

Bypass #1 was disclosed to Microsoft and resolved. However, the fix still allowed Bypass #2 to persist: the DLP could restrict users from creating connections that used blocked connectors, but it wouldn’t block existing connections in any way (even if they were using blocked connectors).

While the DLP now successfully prevented direct access to connections (not just their use within Power Apps), these restrictions were only enforced on new connections, not existing ones. This posed a significant problem, as it was impractical for many organizations to review thousands of connections, apps, and flows to determine whether they were compatible with the new DLP policy.

This is also discussed here in further detail:

Microsoft Power Platform DLP Bypass Uncovered- Finding #1 | Zenity | Security for Low-Code, No-Code, & GenAI Development

One (Fixed) DLP To Block Them All

We tested this last bypass again in the last few weeks and were happy to find some new behavior:

1. When blocking a certain connector, relevant connections that use it will have their status changed in real-time to connection is disabled so it cannot be used.

2. Creating a new application via Power Apps and adding this connection

shows an error regarding The connection is disabled so it cannot be used.

3. Accessing a Power Apps application that uses a blocked connection shows an error for not being compliant with latest data loss prevention policies.

4. Trying to create a new connection returns an error that the connection has been blocked by Data Loss Prevention (DLP) policy.

5. Observing the API call from the Power Apps when trying to add a blocked connector’s connection shows that it returns a 400 status in the invoke request now.

Official documentation for the Microsoft Data Loss Prevention Policies supported these findings - Microsoft seems to have addressed this in a distinction called design-time versus runtime:

In short, it seems that 'design-time' refers to limitations during resource creation that affect the makers, while 'runtime' prevents users from utilizing existing resources.

This update appears to be one of several recent changes aimed at making the DLP more robust and granular, moving it beyond the simple allow-and-deny list it once was. You can find more information on the current status in the official documentation:

Data Loss Prevention (DLP) policies - Power Platform

Ahem ahem

All this is great from the security perspective, however, there are a few missing pieces we should note:

• First, no clear timeline or explicit explanation from Microsoft was provided regarding this fix, as far as we could tell. Another vague aspect is when exactly this fix was updated, what problems it aimed to resolve, and what it specifically included.
  
  Regarding the timing of the update, we can unofficially say that, according to the GitHub changes in the documentation pages, the design-time versus runtime distinction seems to have been added around May 2024.

Update wp-data-loss-prevention.md · MicrosoftDocs/power-platform@766a782

• Second, unfortunately, once again, no acknowledgment was given to our work in raising awareness of the DLP bypasses that led to these fixes and their resolution.

Conclusion

While this may no longer be considered a DLP bypass, the core issue remains unresolved. The real concern has always been the widespread sharing of credentials in Power Platform, and that inherent challenge persists.

This is a fundamental issue embedded in the platform—it’s both the source of significant risks in business development and the reason it is so valuable and empowering to users. While it's possible to create additional restrictions on the platform to limit certain connectors and edge cases, doing so risks undermining its essential value.

Additional Details

You can find more DLP bypasses we’ve uncovered in the past here:

Research Archives | Zenity | Security for Low-Code, No-Code, & GenAI Development

Want to test your own organization and see what connections and resources a guest user can access? Check out powerpwn, our open-source red-teaming tool (now with GenAi features for Microsoft Copilot and Copilot Studio):

GitHub - mbrg/power-pwn: An offensive security toolset for Microsoft 365 focused on Microsoft Copilot, Copilot Studio and Power Platform