Pen-Testing Salesforce Apps: Part 1 (Concepts)
By: Praveen Kanniah
Tags: In Simple Words, Penetration Testing, Salesforce Security, Salesforce, Application Security

in simple words: For Pen-Testers and Security Researchers

This is a two-part blog on pen-testing Salesforce SAAS applications. Part-1 focusses on understanding the Salesforce basics and Part-2 focusses on the actual Pen-Test steps. Let’s begin.

Introduction to Salesforce SAAS Applications

SAAS or Software as a Service, is a software delivery model where a software is made accessible via web. To an extent, it is like a web application. Also, using SAAS is like a privilege, the infrastructure and platform of the SAAS application is completely managed by the vendor.

CRM or Customer Relationship Management, helps a business organisation to maintain their relationship with its customers. Software has been built to manage CRM efficiently. Now, don’t get confused with the word customers here, for example, let’s consider an e-commerce application, the e-commerce company would use CRM to maintain relationship with their suppliers (not customers who buy), check their activity, provide analytics on how they do and enable support.

Salesforce offers SAAS applications for CRM. These SAAS application can be entirely managed and customised via an admin panel, which means you can make the SAAS app live in no time using the admin panel itself. The coding effort required is minimal and it involves one of Salesforce programming technologies.

Lightning Component Framework : A UI development framework similar to AngularJS or React. This includes Aura components too.

: A UI development framework similar to AngularJS or React. This includes components too. Apex : Salesforce’s proprietary programming language with Java-like syntax.

: Salesforce’s proprietary programming language with Java-like syntax. Visualforce: A markup language that lets you create custom Salesforce pages with code that looks a lot like HTML, and optionally can use a powerful combination of Apex and JavaScript

Customisation via other programming languages are allowed too, but the former is the most preferred.

How is this different from the traditional web app Pen-Testing ?

Remember, Salesforce SAAS application is a software that is made accessible like a web application. For the web application part, you will still apply all your traditional web app pen-testing skills, but the software part is where it gets a little different. The software offers separate access controls for managing its data and users. These security controls are accessible primarily via the admin panel and messing up with these security controls can result in Improper Authorisation vulnerability leading to sensitive data leakage.

To exploit these misconfigured security controls, a pen-tester needs to understand the Salesforce format in the HTTP request params. The surface of attack would still be over web, but its really the way we exploit these vulnerabilities that makes this different from the traditional approach

Salesforce specific Vulnerability Exploitations

There are a couple of vulnerabilities that have unique exploitation methods when it comes to Salesforce.

Improper Authorisation - Salesforce offers security controls to manage its data and users. Misconfiguring them can result in Improper Authorisation vulnerability leading to sensitive data leakage. However, to exploit this, you will need to understand the format of the Salesforce HTTP request params.

Note - This might not be applicable if any other programming language apart from the Salesforce programming technologies are used.

SOQL Injection - SOQL is the SQL query language of Salesforce, but its range is limited only to SELECT statements. If a user input is injected directly into SOQL queries, one can modify the query to pull more data than what a user is allowed to see. Again, to exploit this, you will need to understand the query format of SOQL and apply payloads accordingly.

Salesforce Terminologies

Lets take a quick look at the terminologies that are required to carry out the pen-test.

Objects are like tables for storing data. There are two types.

are like tables for storing data. There are two types. Standard Objects , pre-formatted tables that are provided by Salesforce. This will be available to all organisations using Salesforce SAAS applications.

, pre-formatted tables that are provided by Salesforce. This will be available to all organisations using Salesforce SAAS applications. Custom Objects, the objects or tables that are created by an organisation. This will be available only to the organisation that created it.

the objects or tables that are created by an organisation. This will be available only to the organisation that created it. Fields are like columns

are like columns Records are like rows

are like rows Controllers contain Actions , these are functions that retrieve data from Objects (or tables). Params are passed to these functions. There are two types

contain , these are functions that retrieve data from Objects (or tables). are passed to these functions. There are two types Standard Controllers , pre-formatted functions to access Salesforce objects. These controllers will be available to all organisations using Salesforce SAAS applications

, pre-formatted functions to access Salesforce objects. These controllers will be available to all organisations using Salesforce SAAS applications Custom Controllers, new functions developed to access Salesforce objects. This will be available only to the organisation that created it.

new functions developed to access Salesforce objects. This will be available only to the organisation that created it. An unauthenticated user is called a Guest User in Salesforce

Understanding the Salesforce format in the HTTP request

Now that we have a good context about Salesforce SAAS applications, let’s take a look at the HTTP request params and understand the Salesforce format within.

Salesforce HTTP Request (encoded)

A quick url decode on the POST params shows us this:

Salesforce HTTP Request (decoded)

There are four parameters in the POST body.

message

aura.context

aura.pageURI

aura.token

Our topic of interest is really the message parameter and very specifically the “descriptor” and “params” key-value pairs that are within. The other ones are of no interest. But in case, you find anything interesting let me know.

Now, let’s try to relate this to our terminologies.

Salesforce HTTP Request — Controller, Action and params

Forget the names for now, all you have to understand is ComponentController contains getComponentDef function that takes name as a parameter, or its a function with params that interacts with an Object(or table) and fetches data, that sometimes can be records.

So, the function that pulls data from an object (table) is directly exposed in an HTTP request? Yes, thats true.

Now this is where, if the permissions are misconfigured, things can go haywire.

Mapping Misconfigurations to Pen-Test

Let’s take a look at how permissions are assigned, if you want to understand this in detail, you can read my blog here.

In short, permissions are set for objects, fields and records separately. Out of the three, we as pen-testers really care about the record permissions because they are the real data. Two scenarios that can lead to permissions misconfiguration.

Providing over-permissive record permissions to users via admin panel

2. Remember Apex (one of proprietary programming language with Java-like syntax), when certain methods like @Remote Action or @AuraEnabled are used and if proper checks are not performed, it can override the UI permissions and open up wider permissions for records

But what these really mean from a pen-tester’s perspective is, if we identify both objects, controllers and fuzz them with the right params, we should be able to retrieve records that has misconfigured permissions

If we are able to retrieve these records as an unauthenticated user or what is called as Guest User in Salesforce, it’s considered to be CRITICAL. However, there has been a number of upgrades that Salesforce has pushed with regards to Guest User Security.

I hope you enjoyed reading the blog :) You are now set to read Part -2 , fuzz and exploit Salesforce applications. Good Day !

References

https://trailhead.salesforce.com/en/content/learn/modules/platform_dev_basics/platform_dev_basics_code#:~:text=Apex%3A%20Salesforce's%20proprietary%20programming%20language,combination%20of%20Apex%20and%20JavaScript.