Zenity Researchers Discover Over-Permissions in Salesforce Copilot Topics

The discoveries can lead to data leakage, exfiltration, phishing, and more.

The Zenity Labs team has discovered that non-administrator users can modify existing flows that were connected to Einstein by an administrator, influencing Einstein without having the necessary permissions to edit it directly. In doing so, bad actors can easily insert malicious actions into flows that are triggered by business users throughout the enterprise, including phishing attacks, data exfiltration, and more. 

The results from this setting are very challenging for security teams to detect as there are so many audit logs to sift through, that without a proper alerting system, will be like searching for a needle in a haystack. This finding from the Zenity Labs team can impact any organization using the powerful enterprise copilot in their organization. 

By leveraging this vulnerability, bad actors can exfiltrate data and impact business operations throughout Salesforce. There has never been a more important time for security teams to place proper guardrails and alerting systems in place than right now, as enterprise copilot adoption is still early, but certainly taking strong hold in many, many enterprises. Now is the time to lay foundational security and governance controls. 

Understanding how bad actors will look to exploit them is a necessary first step, and in this blog we will untangle our findings and conclude with some actions that your security team can take to bolster its defenses. 

Understanding Copilot

For Salesforce Einstein, it is important to understand a couple of key terms as relates to copilots. First, a ‘copilot topic’ is a specific Salesforce term that means ‘a category of actions related to a particular job to be done by agents and Copilot. Topics contain actions, which are the tools available for the job, and instructions, which tell the agent how to make decisions. Collectively, topics define the range of capabilities your agent can handle. Salesforce provides a library of standard topics for common use cases, and you can create custom topics to meet your users’ specific business needs.’ 

Salesforce documentation, pictured below, shows that admins and devs can create custom actions that can give Einstein Copilot more capabilities. 

Only an admin can create a new topic and connect it to a flow action. However, while non-administrators are not allowed to edit Einstein Copilot directly, they likely have access to edit flows. This permission to edit flows gives them an easy bypass which can impact the entire Copilot. And when in the wrong hands, this bypass can be used in very malicious ways, which we will show below.

Copilot Flows 

Flows run on the user’s behalf, i.e. whoever the user that is talking to Einstein. Using this vulnerability, bad actors can pretend to be the user by editing the flow, basically doing any action they want on his behalf (send emails, edit records, delete records, and lots more). 

Anyone who has flow permissions can change the functionality of a legitimate flow using completely customizable actions. In many organizations, Copilot is used by end users of all technical backgrounds and functions; brushing up against critical data housed in Salesforce in the process. If a flow is changed, it can have monumental damages if it is designed maliciously. 

The way audit logs are constructed in Salesforce is that within a flow, someone can insert any kind of malicious activity into the flow while keeping the input and output exactly the same; which essentially hides the activity. This will look completely legitimate for anyone who invokes the flow from Einstein while actually doing other things on the user’s behalf in the background. Let’s dive in to a real scenario undertaken by the Zenity Labs team. 

Inserting Malicious Flows in Salesforce Copilot

In the scenario we’re about to unpack, we are going to add a step to a legitimate flow which was connected to Einstein by an admin. Using this step we will be able to send phishing emails to customers directly from the inbox of the user running the flow, i.e. the user using Einstein Copilot

First, let’s see this from an admins perspective. Here we are, where we can see the flow. 

Next we’re able to see the different agent actions that we have access to edit and create. 

We’re going to open up a specific action where Einstein can ‘get the most recent accounts’ and relay that information to someone who’s asking about the latest data to be entered into Salesforce. 

And we can also see how the flow is decomposed and the way that Einstein reads the prompt and answers accordingly. 

Now that our flow is connected to Einstein, let’s see how the flow interacts today to someone that is using this copilot and how the ensuing flow plays out.

Looks good! We’re ready to use this and get it into the hands of our Salesforce users. 

Where It Goes Wrong

But… now, let’s see where this can go wrong. We’re going to log in now as ‘Elad’, a non-admin user who does not have the ability to edit Einstein.  

However, he can still edit flows and the actions that are in that flow. 

Now, let’s add in a new action within that flow. 

Here, we’re going to add an email, and we have control over the: 

• Label
• Subject
• Description
• Who’s sending it
• And who can receive it as part of this flow

But, how does this play out? Well, at first glance, it looks the same. 

However, if we dive in further, and look into the email inbox of one of the contacts John (our victim) is in touch with, for example “Tamir Holland” as seen below. 

We’ll see a new email from John has been received. This is the email that our bad actor inserted as part of this flow. And, of course, it contains a phishing link.

Wait, what just happened? 

This malicious user was able to leverage this flow to send a phishing email to a customer directly from the email address of the person who’s running the flow. This phishing email will be sent on behalf of any user who accidently invokes the flow through Einstein Copilot 

The origin of the email address is the address of the user that activated the flow; in this case it is the unsuspecting John Smith. 

From Einstein Access, this user is blocked and should not be able to influence the Copilot’s functionality in any way. However, the bad actor can access the flow, edit it and even delete the malicious versions after they are used, further masquerading themselves.

From the target’s perspective, it is hard to notice anything is afoot as the email is sent behind the scenes and the flow returns the expected response as we showed.

We have now sent off a phishing email, where all we need is one click in order to succeed in our mission. 

What did we learn? 

Salesforce Einstein is a powerful enterprise copilot that is being used by a huge variety and number of organizations. However, without proper guardrails, bad actors can edit existing flows to do whatever they want with them on behalf of the unsuspecting users who are using Einstein. This is increasingly challenging to decipher, even in Salesforce audit logs. 
It is recommended that organizations that are leveraging Salesforce Einstein implement strong detection mechanisms to discover when flows are edited, especially ones which were connected to Einstein. If you’d like to see it for yourself, click here!