Salesforce Guest User Log Analysis

Introduction

In early October 2020, Security Researcher Aaron Costello, now offensive security engineer at AppOmni, published an influential blog detailing how to leverage Aura (aka Lightning) Controllers as an anonymous guest user to extract and manipulate data within a misconfigured Salesforce Community, Portal, or Site.

This article summarizes Aaron’s original post and highlights the challenges around detecting this activity and what you can do about it. A link to the full original post is below. 

Salesforce Event Monitoring

Salesforce has two primary avenues for obtaining event data from a Salesforce org: Event Monitoring and Real-Time Event Monitoring. Discussing the specific differences between these two offerings is outside the scope of this article; however, the essential highlights are as follows:

Both options are made available via Salesforce Shield or an Event Monitoring Add-On License.Real-Time Event Monitoring is mostly a subset of the “Standard” Event Monitoring.

• “Standard” Event Monitoring is only made available on an hourly or daily basis, depending on the event type. Consequently, this is forcing a detection delay of at least that long.
• Real-Time Event Monitoring is, as the name suggests, Real-Time.

Based on our analysis, we believe neither one of these options provides the requisite visibility into detecting any exploitation of misconfigured guest user access on a Salesforce Community or Site due to the lack of events that are made available related to Aura Controller access.

Obtaining Visibility

There is a third avenue of approach to obtaining event data for a Salesforce instance: engaging Salesforce support directly to provide additional event data for a specified time. Salesforce calls this the “Historical Event Logs Process,” and it applies whether or not the org in question has Salesforce Shield/Event Monitoring Add-On. This process is what needs to be followed in order to obtain the necessary data to investigate the issue highlighted in the above mentioned research article. AppOmni recommends contacting Salesforce support directly to understand what options for obtaining visibility are available to you based on your usage and license type.

There are several challenges to this approach:

• Salesforce typically provides event data up-to 30 days in the past
• There may be a charge associated with requesting and retrieving these logs
• By default, this process’s output is roughly equivalent to the event data available in Real-Time Event Monitoring
• There are often wait times associated with requesting these logs, and there may be additional delays with customers obtaining this event data after it has been requested
• The process often applies to one guest user at a time but each Community, Portal, and Site has a unique guest user context that applies to the anonymous user when requesting data or resources from that particular external interface. That is to say that data may not be exposed through one Community, Portal, or Site interface but a slight change to the URL to point requests at a different interface can expose a totally different set of data and resources

As noted above, this process’s default output is to provide data that is roughly equivalent to the output of Real-Time Event Monitoring. However, it is possible to request additional event data from Salesforce in the instance of a documented need. In this instance, you will require visibility into Aura Controller access, which requires access to the augen event type. As such, it is necessary to tailor your support request for historical event logs to note that you are investigating Aura Controller access and need augen events in your output.

When contacting Salesforce support, keep in mind that the person responding to your request may not be a security expert. Additional requests or escalation may be needed to obtain the necessary log files. Don’t be afraid to involve your Salesforce Account Executive to help move the process along. These events are critical to the investigation, and without them, you cannot properly investigate this issue.

Detecting Exploitation Attempts of Salesforce Communities or Sites

Salesforce provides the event data in CSV format with numerous columns dictating the various fields available in the event data, and each row is one event. As such, you can leverage your favorite spreadsheet program to conduct the analysis. The logs will likely provide far more event data than is necessary to perform the analysis; thus, you can start by filtering for events where the logRecordType field is augen or ‘U’, where the logName field is /sfsites/aura, the userType field is Guest, and the requestMethod is POST. You should focus your analysis on the following columns, which will allow you to hide/delete any other columns:

• timestamp
• organizationId
• userId
• logRecordType
• remoteAddr
• logName
• actionMessage
• userType
• httpReferer
• requestMethod

Additionally, the logs may not be sorted by timestamp, so it’s always a good idea to sort on the timestamp field.

Before you start diving into event analysis, it’s worth noting that `U` events are paired with augen events to provide context on the request; primarily in terms of the httpReferer field as augen events do not contain this data. This pairing of events can be done by timestamp, as both events should have identical (or near identical, sometimes microseconds apart) timestamps.

Another point worth noting is that while augen events provide the requisite visibility into seeing if somebody accessed an Aura controller, these events do not offer any context into what parameters were utilized in the request or if the request returned any data. Unfortunately, this means you cannot tell from the event data if somebody successfully accessed a resource or what resource they attempted to access. Only that somebody attempted to access an unspecified resource. You can, however, directly analyze your Salesforce instance(s) to see which records are currently exposed to the anonymous external guest users and would likely have been exposed by any attempts. This analysis can be complex and time consuming to perform manually and requires a deep understanding of the Salesforce platform. AppOmni can perform this assessment for you as part of our 1 hour risk assessment.

The below section will provide the manual steps you would take to identify indicators of the technique outlined in the referenced article in the CSV logs provided by Salesforce support. As these logs can be extensive, we recommend using our free log analysis service to analyze and extract logs entries relevant to this technique for further investigation. This service will also determine if you’ve received the correct log streams from Salesforce support.

If manually analyzing this event data appears overwhelming or daunting, take advantage of our free log analysis service to isolate those events that most warrant investigation.

Manual Analysis

To detect suspicious behavior, you should focus on the actionMessage field; The pattern you are looking for here is an augen event where the actionMessage is:

1$serviceComponent://ui.force.components. controllers.hostConfig. HostConfigController/ ACTION$getConfigData={}

followed by a sequence of one or more augen events where the actionMessage is:

1$serviceComponent://ui.force.components. controllers.lists. selectableListDataProvider.Selectable ListDataProvider

Controller/ACTION$getItems={}

The first event (HostConfigController) reflects an attempt by a user to get a list of accessible custom Salesforce objects.

The second event (SelectableListDataProviderController) reflects an attempt by a user to extract data from an object. A request made to the SelectableListDataProvider Controller will return all accessible data for the user.

The fidelity of this sequence of events is varied as they theoretically can occur during regular expected activity in a Salesforce Org. Still, generally speaking, a singular or small handful of calls to `HostConfigController` followed by many calls to SelectableListDataProviderController is indicative of someone identifying accessible objects and then enumerating those objects to extract data; as you would not expect many calls to SelectableListDataProviderController to occur in such short period of time.

Conclusion

As noted above, this log analysis can only identify if someone attempted to access resources in your Salesforce organization. It cannot determine if those attempts were successful and what resources were accessed. To determine this, you need to analyze your Salesforce org configuration to identify what resources are exposed to the guest user. Read the complete tutorial, “Salesforce Lightning – An In-Depth Look at Exploitation Vectors for the Everyday Community,” for all the details.

---

Related Resources