Microsoft Power Platform DLP Bypass Uncovered – Finding #5 – Parent and Child Flow Execution

Analysis of Microsoft Power Platform’s security features revealed limitations that could expose organizations to security risks, such as difficulty enforcing DLP policies for pre-existing resources and issues with HTTP calls or custom connectors. In an effort to address these concerns, Microsoft has implemented Data Loss Prevention (DLP) policies that allow defining business connectors that are permitted to access specific business data, while blocking the usage of others in a manner similar to an allow and block list. 

In our latest findings, we’ve discovered that a parent flow running a child flow can combine business and non-business connectors which will bypass any DLP configuration. The result we expect to see in this scenario is that the DLP will block this operation since the main purpose of the DLP policy is to not allow a combination of business and non-business connectors. However, as discovered throughout this blog series, there are many ways to bypass that. That the DLP will not be triggered and the flows will be able to run successfully while bypassing that configuration, is a major vulnerability that administrators need to be aware of. 

With Microsoft tools, you can create a flow that calls another flow using the “Run a child flow” step. In order to demonstrate our findings I will present to you how a user, whether inadvertently or with malicious intent, can combine a business connector, such as SharePoint, and a non-business connector, such as Outlook, to create data leakage of the organizational sensitive information.

In the below two screenshots, I’ve created a dedicated DLP policy and configured the Outlook connector to be under the non-business connectors group and the SharePoint connector under the business connectors group. 

Below, you will see that I have created the following SharePoint list which includes the columns: Title, Amount, Date and Category, and will contain customer information.

Next, I created the following child flow that uses the non-business Outlook connector to send an email to my account with information that I set in the first step, which includes the SharePoint list objects.

Then, I created the parent flow which will be triggered by a new item that was created in my SharePoint list and will run the child flow we’ve created previously with the relevant information from the list.

To trigger the parent flow, I’ve added an item with customer information to the list.

Both flows ran successfully and I got an email with the item information, that was added to the SharePoint list.

The use of Power Platform has introduced a built-in bypass of data loss prevention policies. Our recent research and demonstration above has shown another easy way to bypass DLP configurations that are meant to prevent a combination of business and non-business connectors. With this bypass, data can be exposed to unauthorized personnel or external entities, putting the organization at risk of data breaches and other security incidents.

This discovery again highlights the lack of visibility that administrators have in monitoring any DLP bypass operations. It also puts the lack of trust that administrators might have towards the DLP policy being able to control and block these operations, as the DLP configurations alone may not be sufficient to prevent data leakage of sensitive information. 

It’s important to be aware that while HTTP connectors can be added to the DLP policy blocked connectors list, the “run a child flow” action cannot be blocked by DLP policies which limits administrators’ options to control the use of this strong capability. 

Another important point is that both SharePoint and Office 365 outlook connectors are part of the unblockable connectors in the DLP configuration which means you can not block users from using them (to read more about unblockable connectors and they can be used to bypass DLP click here).

In order to address these security risks and provide our customers with more visibility, Zenity is continuously adding dedicated rules that are set to monitor scenarios exactly like this one. From there, prioritized alerts can be triggered to alert of potential data leakages and playbooks to automatically remediate any issues that arise. 

To learn more about the security risks mentioned in this article or in the earlier articles in this series, feel free to reach out over email to yuvala@zenity.io and I’ll be happy to help! You can also contact us here!