Apex Code Vulnerabilities Let Hackers Steal Salesforce Data

Hackers target Apex code vulnerabilities in Salesforce to exploit security weaknesses, gain unauthorized access to sensitive data, or manipulate the system.

Apex is a powerful language that enables the customization of Salesforce with Java-like syntax. It executes logic, controls transactions, and responds to system events. 

This is primarily used for business logic and is triggered by web services and object events.

Cybersecurity researchers at Varonis Threat Labs recently discovered serious Apex vulnerabilities in multiple Fortune 500 companies and government agencies.

While researchers promptly reported and alerted the affected companies, the vulnerabilities were marked with high and critical severity tags.

Document

Live Account Takeover Attack Simulation

Live attack simulation Webinar demonstrates various ways in which account takeover can happen and practices to protect your websites and APIs against ATO attacks.

Apex Code Vulnerabilities

The Apex code can be run in two different modes:-

‘Without sharing’ in Apex disregards user permissions, which grants unrestricted access and modification. 

‘With sharing’ respects record-level permissions while overlooking object and field-level restrictions.

Running Apex classes ‘without sharing’ grants powerful capabilities but raises risks. It can lead to insecure data access (IDOR) and vulnerabilities like SOQL injection, Varonis said.

Besides this, the misuse by external users or guests poses data integrity threats. VTL demonstrates exploiting Apex vulnerabilities to access user data without permission. 

Using a Salesforce environment with real code issues, the instance shows how attackers can abuse aura methods for reconnaissance.

This enables the extraction of sensitive data like phone or social security numbers.

Using the aura method (Source - Varonis)
Using the aura method (Source – Varonis)

Despite a custom field ‘VerySecretFlag__c,’ users can’t access others’ data. Even ‘CreatedBy.VerySecretFlag__c’ fails, and guests also lack access. 

To bypass this, researchers exploited the ‘apex://CaseCreationController/ACTION$createCaseR’ via a custom Apex class, which is callable with Aura, specifying desired field returns.

The case retrieved solely via Apex is inaccessible by other means that hint at ‘without sharing’ mode. To access ‘VerySecretFlag,’ an attacker exploits this by specifying desired fields, like ‘CreatedBy.VerySecretFlag__c,’ via an over-permissive class by accessing data from other objects.

Apex is essential in Salesforce, but reviewing classes, especially ‘without sharing,’ boosts security as manual checks are time-consuming. 

Both the Profiles and Permission Sets need to be examined to determine access. Access setup through Salesforce setup and then navigate to the Profiles. 

Besides this, review each profile’s ‘Enabled Apex Class Access’ section.

Enabled Apex Class Access (Source - Varonis) 
Enabled Apex Class Access (Source – Varonis) 

To verify the access, check Permissions Sets for each entry. Review users assigned to Profiles and Permission Sets. Examine class source code for the ‘without sharing’ declaration. 

With Event Monitoring, track user calls and adjust permissions. Ensure safe coding practices, like using ‘:queryName’ syntax in SOQL to prevent injection.

Moreover, consider adding “WITH SHARING_ENFORCED” to your queries to enforce object- and field-level permissions. Adding “WITH SHARING_ENFORCED” only affects SELECT clauses and not WHERE clauses.

You can block malware, including Trojans, ransomware, spyware, rootkits, worms, and zero-day exploits, with Perimeter81 malware protection. All are extremely harmful, can wreak havoc, and damage your network.

Stay updated on Cybersecurity news, Whitepapers, and Infographics. Follow us on LinkedIn & Twitter.

Leave a Reply

Your email address will not be published. Required fields are marked *