By Nitay Bachrach, Senior Security Researcher, Polyrize

This article describes in detail a Salesforce privilege escalation scenario whereby a malicious insider exploits Author Apex permission to take over an organization’s Salesforce account and all data within it. The user abuses the fact that some APEX code can be executed in System Mode context, which bypasses their standard limited permissions and enables them to grant themselves admin-level or privileged access without being an admin or privileged user.

Privilege escalation techniques for IaaS (like AWS or GCP) have been well-known for a while (like this one, this one, and these ones). However, SaaS privilege escalation constitutes a new class of exploit that has emerged and is often overlooked by security teams. However, since the potential damage to a company’s business continuity, finances, and reputation is so substantial, preventing privilege escalation then, is critical to securing cloud environments and the business critical data stored and shared within them.

What is Privilege Escalation?

Privilege escalation is the process of exploiting a programming flaw or configuration error in an application to gain elevated access to resources that should normally be unavailable to the exploiting user. By exploiting their existing permissions to obtain more powerful ones, malicious users can then abuse their newly acquired admin privileges to hijack the account, exfiltrate data or encrypt it for ransom.

Preventing privilege escalation then, is critical to securing cloud environments and the business critical data stored and shared within them. Both user-to-super and privileged-to-super escalations pose a significant threat since they significantly increase the number of potential super-admins, and the higher the number of super-admins, the wider the attack surface.

Salesforce Permissions 101

Salesforce has a complex multi-layered security model. The first layer consists of permission sets and profiles. On top of this layer come other kinds of access control mechanisms, such as organization-wide defaults, roles, and shares, that can control the user’s access in a more granular manner. The privilege escalation described in this article abuses the permission set mechanism.

Profiles and permissions sets determine many capabilities, including:

• Reading, modifying, and deleting Salesforce objects, such as Accounts
• Accessing and running reports
• Customizing the Salesforce environment
• Administering different aspects of Salesforce
• Bypassing sharing rules, such as “view all” permissions or even modifying all data.
• Authoring APEX

What is APEX?

APEX is a powerful tool that lets Salesforce users customize and adjust their Salesforce environment. It’s a Java-like proprietary programming language that can interact with almost anything in Salesforce.

APEX can be used in order to customize pages, create APIs (using APEXREST), and different data controls. Just like in most modern SQL databases, one can register APEX functions to be executed after or before commits, or in Salesforce’s case, sObjects. These APEX functions are known as APEX Triggers.

It’s possible to register triggers on many actions for most objects, this includes accounts, cases, opportunities, leads, users, profiles, and so on. The code can be set to trigger before and/or after ‘create’, ‘update’, and ‘delete’ actions.

Another important aspect of APEX is execution context. APEX code can be executed in either system mode or user mode:

• User mode - The execution is limited by the user’s permissions.
• System mode - The execution is not limited by the user’s permissions.

Triggers, like many other APEX pieces, run in System Mode. This can be used among other things to create different constraints that are not affected by the active user’s permissions or to enforce default values that the user cannot otherwise control. This behavior can be exploited by attackers in order to escalate privileges.

APEX Privilege Escalation Walkthrough

Any user in Salesforce can update some details about themselves. This means any user can invoke a user update trigger, a fact that makes it the perfect trigger for privilege escalation.

The execution flow goes as follow:

1. Registering the trigger
2. Executing the trigger
3. Granting admin privileges
4. Abusing admin rights

1. Registering the trigger

1.1.Creating a new Trigger

First thing first, the threat actor needs to add the trigger. Registering the trigger using Lightning (the modern Salesforce layout) is not trivial:

This explains that a trigger could be added in the desired object's management page. Unfortunately for the attacker, this cannot be done in Lightning, as can be seen in this comparison of the lightning view of the User’s management page, between the attacker and an actual admin:

Triggers” is missing in the attacker’s menu within the Lightning UI but not in the Classic UI:

1.2. The Trigger Code

The attacker can add a new trigger as follows:

The header “trigger SFDCUserEditPolicyVerification on User (before update)” means that the trigger listens for update events on users, and executes before the update takes place, a trigger that can be activated by any user.

The purpose of a trigger is to grant the malicious actor a permission set and the privilege to modify it as they desire.

A line by line explanation of the trigger:

2. Executing the trigger

The trigger executes before any user update. This can easily be done by an “empty update”:

Go to “my profile”

And click on “Edit Profile”

Then, without changing anything, click “Save All”.

This activates the trigger and adds the Permission Set to the user.

3. Adding privileges

By itself the permission set does not let the attacker do much. Most actions, such as editing a user, will fail:

But it does grant the attacker one significant privilege: it lets them modify permission sets. So the actor can grant themselves any permission they desire, by modifying the permission set the trigger granted them.

This can be done by browsing to setup->Users->Permission Sets and clicking the newly assigned permission set. In this example it’s “'HRConsultentDefaultSet'”:

Then the permissions can be modified by clicking System Permissions and then edit.

The actor can grant themselves any permission, but in order to obtain super-admin rights, “Manage Users”, “Customize Application”, and “Modify All Data” suffice. Note that these privileges automatically grant some other privileges as well.

After adding said permissions, the attacker becomes a super admin.

The Consequences

After obtaining super admin privileges by exploiting the user’s Author Apex permission to escalate privileges and adding the three mentioned permissions, there are several scenarios that can happen. Among them:

1. The malicious actor may export every account, opportunity, contact, or lead in Salesforce
2. The malicious actor may steal any information stored in Salesforce.
3. The malicious actor may delete or corrupt stored data, demanding a ransom in order to restore it.
4. The malicious actor might set up a backdoor.

Example Scenario - Exporting all Accounts

The threat actor can export all stored accounts by going to reports, adding a new report, and choosing Accounts:

In “filters” the value “Show me” should be changed from “My Accounts” to “All Accounts” and the value of “Created Date” should be changed to “All Time” by changing the range from “Custom” to “All Time”:

This creates a new report that can be executed by hitting “Run”. After the execution, the report can be exported.

Thus the attacker has exported every account in Salesforce, including any desired associated data, such as annual revenue, priority, or personal information.

Mitigation Steps You Can Take

1. Treat “Author Apex” as a super-admin right, and keep the number of such users at a minimum. Revoke the privilege from users once it’s no longer needed. You can use this Polyrize utility to find users who are capable of privilege escalation using APEX. GET UTILITY HERE
2. Make sure to keep track of all users' permissions and privileges.
3. Keep track of APEX classes and triggers in your organization.
4. Review the code and make sure that developers inform the security team of updates.

About the Author

Nitay Bachrach is a security researcher who works as a Cloud Security Expert at Polyrize. Nitay is also highly experienced in Linux, IoT, and reverse engineering.