Hello everyone! I’m Yuval Adler, Customer Success Director at Zenity.

I’m inviting you to read my blog series where I will share new Microsoft Power Platform DLP Bypass findings we uncovered.

Finding #2 – HTTP Calls

Low-code and no-code technologies are being embraced across the world, but there’s one LCNC platform that stands out, with significant growth and enterprise adoption – and that’s Microsoft’s Power Platform.

In order to protect the organization’s sensitive data and prevent users from potentially exposing organizational data, Microsoft came up with Power Platform data loss prevention (DLP) policies that define the consumer connectors that specific business data can be shared with. Some connectors can also be blocked for usage, similar to an allow and block list. I’ve written before about vulnerabilities in these DLP policies (Check out this blog post to learn more).

In today’s article, we want to share another DLP bypass uncovered by the Zenity security research team. Power Platform DLP aims to set boundaries between connectors that should have access to the organization’s business data and connectors that shouldn’t. As we continue to discover, administrators have partial ways to create security guidelines for the organization’s access to sensitive data in Power Platform DLP.

The finding presented in this blog is related to the usage of the HTTP connector and its limitations. It turns out that, when using this connector, the maker can reach out to blocked services and connectors in the DLP by simply accessing their API and reaching out with HTTP requests. This means a direct way to bypass any DLP policy configured in the organization today with almost no way for the administrators to be aware of it. 

Power Platform offers a variety of connectors that creators can choose from, within the platform. The list of options isn’t infinite and can’t cover everything you might need in order to build every conceivable workflow. There are instances where you’ll want to integrate or trigger a flow using an application or service that’s not currently available in Power Platform.

One of the most popular (and risky) ways to go around the connector limitation is by using the HTTP connector. In fact, even the Microsoft Center of Excellence (CoE) Starter Kit asks you to enable HTTP as a business connector (Docs). It allows you to type in any URL you would like for your app or flow to reach. The trouble is, it allows you to reach even a service or connector that your organization has blocked. 

For example, if your organization were to have blocked direct connections to Gmail, then using the HTTP connector, an app or flow creator can bypass this block and reach out to Gmail. From the outside it will look like a regular HTTP request. It’s not obvious to the system that the app or flow is actually connected to Gmail, which the organization has attempted to block.

In the following screenshots, you can see a demonstration of an admin trying to block the use of the Gmail connector in the organization’s DLP policy “Blocked Gmail DLP” (Screenshot 1).

Screenshot 1

The DLP policy is set to run on all environments (Screenshot 2).

Screenshot 2

As a user trying to bypass this limitation, I’ve created the flow “DLP_Gmail_Bypass” to create a POST HTTP call to Gmail and send an email to my personal Gmail account. The flow includes the following steps:

• Manual trigger
• Variable that includes the email message 
• HTTP request to the Gmail API

Screenshot 3

In the following screenshots you can see that the flow has run successfully and I got the email to my personal Gmail account (screenshots 4 & 5).

Screenshot 4

Screenshot 5

This is the easiest way to bypass any blocked connector the DLP policy has and this means that admins have no actual power to block or restrict the use of risky connectors (I will cover the endpoint filtering feature soon), even when they are making full use of the Power Platform DLP policies.

In order to try to address this risky connector, Microsoft Power Platform came up with the Configure Endpoints capability, through which administrators can enable specific endpoints to be allowed or to be blocked. As an administrator, you can select the relevant DLP policy and then click on Prebuilt connectors → choose HTTP connector → 3 dots → Configure connector → Connector endpoints (Screenshot 6).

Screenshot 6

You can establish rules for the HTTP connector, and there are 2 different actions that can be set – Allow and Deny. By pasting the URL, the DLP should suspend any flow using a HTTP step trying to access that endpoint.

To demonstrate it, in screenshot 7 you can see that we’ve configured the address accessing the Gmail API to be set as “Deny” and in screenshot 8 you can see that when trying to edit the flow it was updated to “Suspended” status:

Screenshot 7

Screenshot 8

However, configured endpoints can be easily bypassed too. As presented in the previous blog, Finding #1 – DLP Enforcement Failure on existing resources, we uncovered an issue with the Microsoft DLP enforcement method where you might still see existing resources which are running blocked connectors or accessing blocked endpoints. In other words, blocking is not always retroactive.

Another way to bypass this is by using environment variables which are not supported by Microsoft DLP endpoint filtering. This is a known limitation published by Microsoft: “endpoint filtering rules are not enforced on environment variables, custom inputs and dynamically bound endpoints during runtime. Only static endpoints known and selected when building an app, flow, or chatbot during design time are enforced.”

In the following screenshots (9-11) you can see that when using an environment variable set as the Gmail API URI, instead of accessing the URI directly – the flow can be turned on and is now running and bypassing the DLP.

Screenshot 9

Screenshot 10

Screenshot 11

We can see that although we’ve configured in our DLP policy that the URI be part of the “Deny” list – the flow is still actively running because when using the environment variable we can bypass that configuration and access the desired request.

The HTTP connector exposes companies to another security risk, as well. The way this connector works is that the authentication credentials are saved and presented as plain text (see screenshot 3 & 9). The risk is that when trying to connect to services which require authentication, a maker might store secrets within the step parameters which are visible to everyone who has access to the flow.

If you’re not using Azure key vault or environment variable there is a high risk that your organization’s flows with HTTP steps are currently exposing sensitive data in your environment. And once again, there’s no trigger to alert security or IT teams that this is the case.

As presented here, the HTTP connector is a very powerful connector that might expose your organization to several security risks and should be monitored carefully to make sure it is being used the right way.
Our recommendations in order to reduce risk in those scenarios are:

• Make sure to remove the HTTP connector from the business data group in the environment DLP policy and add it to the blocked connectors list 
• Consider replacing the HTTP step with an official Power Platform connector that has the same functionality
  • If such a connector does not exist, consider creating a custom connector  
• Make sure you’re using Azure key vault or environment variables to avoid exposing hard-coded secrets 

It is important to know that even when following those recommendations, as presented today, there is still potential risk which can not be mitigated. Moreover, you may struggle to find and fix existing instances of these vulnerabilities.   

In order to address these security risks and provide our customers with more visibility, at Zenity we’ve added dedicated rules to our security rules set to monitor these specific scenarios, alert our customers about them, and provide them with the ability to resolve this issue immediately. 

To learn more about the security risks mentioned, feel free to reach out over email to yuvala@zenity.io. I’m always happy to talk about research and recommendations! To continue reading on this series, please check out finding #3; Custom Connectors.