In early October, Security Researcher Aaron Costello published a 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 highlights the challenges around detecting this activity and what you can do about it.
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.
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.
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
userType field is
Guest, and the
POST. You should focus your analysis on the following columns, which will allow you to hide/delete any other columns:
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.
To detect suspicious behavior, you should focus on the
actionMessage field; The pattern you are looking for here is an
augen event where the
followed by a sequence of one or more
augen events where the
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.
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.