What a Vulnerability in Salesforce Apex Code Means for You

What Happened? 

Varonis researchers have recently disclosed that several government agencies and private-sector companies had customized or added features to their Salesforce Apex code that leaked data, allowed data corruption, or allowed an attacker to disrupt business functions. 

Impacted data included the usual suspects like phone numbers, addresses, social security numbers, and username/password combinations. 

Why is This a Big Deal?

Because of the obfuscated nature of custom Apex code that is used in internal Salesforce instances and apps (i.e. Lightning, Lightning Communities) is at the root of the problem. As people are building their own apps and automations, there are also a variety of settings, steps, and configurations that need to happen that are often missed due to the lack of a software development lifecycle that takes place across Salesforce, and other low-code platforms like it. 

Unfortunately, there are a couple of issues that make it very easy for Salesforce devs (consisting of both professional and citizen developers) to make mistakes that can lead to data leakage. The key issue in this case, however, can be distilled down to whether a developer designates an Apex class as ‘with sharing’ or ‘without sharing.’ 

What’s interesting with how Salesforce has set up their platform, is the ‘without sharing’ designation is actually the security nightmare, as it allows Apex code to ignore users’ permissions and change and commit changes to any record. As this happens, bad actors can gain access to more things than they need, and are essentially granted super-admin powers to be able to change any record with very little in the way of governance. 

Why Will This Continue to Happen?  

As with most things, it is not so simple as to just tell users to not select ‘without sharing’ when designating Apex classes. For one, this classification is a ‘powerful and important capability often required for proper functionality,’ and is always going to be needed; the real questions are, ‘when is this needed’ and ‘how do I prevent unnecessary designations to occur?’

The Varonis recommendations are to avoid this ‘without sharing’ configuration when possible, to check user-supplied inputs, and be extra vigilant when allowing guest users to access and use Apex classes. The underlying recommendation is to better educate business users that are developing their own resources inside of Salesforce. 

The problems are threefold:

1. This is easier said than done as low-code development spans tens, if not hundreds of thousands of individual resources, and so going back and monitoring all apps is incredibly time consuming
2. Then, once you’ve found and accounted for all of them, identifying each resource that has been misconfigured and mitigating the risk is even more time consuming
3. Business users will always take the path of least resistance when building productivity tools for themselves (particularly without a software development lifecycle to implement checks and balances) 

What Can Be Done? 

While many tools are available to assist with ‘security for Salesforce’ the way these tools work are often to persist on an access control level; that is to limit the very use of Salesforce (or other SaaS development platforms) to only the people that need it to do their jobs; often associated with SSPMs. There are other data-security tools (i.e. DSPMs) that aim to classify data that exists within the SaaS platform and approach security that way. 

However, the problem still exists that there are huge numbers of people that need access to these SaaS tools, and the data that need to be integrated and connected to the offshoots coming from these SaaS tools; namely apps, automations, dataflows, and even copilots. Further, because these tools all exist at the surface level and are not able to properly distinguish between apps where it makes sense to have this ‘without sharing’ label make sense, and where it does not. 

What can be done to prevent and mitigate the risk from this specific incident (and likely many more to come as more and more people adopt AI and low-code development platforms) is as follows:

• Establish a rolling inventory of all apps, automations, dataflows, and more that are created across various development platforms and understanding the business-level logic behind each app. This can include Salesforce, ServiceNow, Microsoft, OpenAI, and more. 
• Assess each individual resource for risk and vulnerabilities. This would include detecting which apps are over-provisioned (as was the case here), expose sensitive data in plaintext, or are otherwise misconfigured so as to increase the risk of data leakage
• Implement guardrails for secure development so that even if your devs do not 100% process ongoing security training, security can act in real-time to correct the issues to prevent data leakage

If you’d like to see this in action, Zenity offers full security and governance support for Salesforce, including the ability to flag any Apex code that has been designated as ‘without sharing,’ and providing automated remediation steps. Check out our solution page, or get in touch with us at hello@zenity.io to learn more!