In light of recent compromises of third-party applications, this information is intended for use by Security practitioners and Salesforce technical staff to better address the current concerns and suggest future controls to prevent similar issues. This details the attack vectors used by Scattered Spider, ShinyHunters, and UNC6395, and more importantly, how to protect against such attacks in the future.
Upon determining the existence of the compromise, Salesforce revoked the Drift App OAuth tokens, rendering them useless. However, it is still important for every customer, whether they have been breached or not, to ensure that they take the necessary steps by blocking and uninstalling the Drift apps. While teams may be focused on Production, it is also important to do the same in lower environments such as Full or Partial Sandboxes, Test, and Dev. This will ensure that you defend against all attack vectors.
Action:
It was observed that even non-customers and former customers were affected by the Drift App OAuth tokens compromise. While this highlights some obvious issues, such as the Drift App’s failure to remove or purge tokens for non-customers, it is also your responsibility to review and remove any unused Connected Apps. Customers should take this step across all of their environments (Production, Sandbox, Dev, and Test).
Moreover, it’s possible that the OAuth tokens were not encrypted by the Drift app, leading to a direct compromise. It is your responsibility to ensure that you do not have residual risk from unused, often abandoned, Connected Apps.
Action:
Salesforce removed OAuth 2.0 Device Flow access in the Data Loader to protect against Phishing attacks. This is a great step in the right direction as it prevents abuse of the device flow connection, which is conducive to Voice Phishing (Vishing) or Phishing attacks. Moreover, Device Flows pose a significant risk to privileged user accounts. Salesforce also introduced a new setting (Approve Uninstalled Connected Apps), which is designed to mitigate the risk of users installing Connected Apps. While this is a great improvement, it still creates a single point of failure: users with these permissions are still targets of Phishing or Vishing attacks. We recommend a more robust approach where security teams are involved in vetting whether an app should be allowed or not.
Action:
During this Salesforce data breach, threat actors leveraged compromised OAuth tokens to search Salesforce data for exposed credentials and secrets.
Scattered Spider, ShinyHunters, and UNC6395 used the compromised OAuth tokens to gain access to Salesforce data and then searched the data for credentials to other cloud services, like AWS, Snowflake, to expand the blast radius and move laterally to other valuable targets in an environment. In some cases, they were successful in gaining access to such secrets because they were exposed in the Salesforce environment. This is why the full impact of this breach is still to be determined. There may be follow-up breaches resulting from this original breach.
Action:
The impact of a compromised OAuth token can be further restricted using IP whitelists. Ask your Connected App vendor to provide egress IP ranges, which you can whitelist so that OAuth token access can be restricted to approved source IPs. This does not mitigate the instance where a host from a vendor is compromised, in which case IP whitelisting is ineffective, but it significantly reduces the attack surface.
Action:
While we recommend reviewing your current Connected Apps, it is also important to note that an app not breached today can also be an attack vector tomorrow. DigitSec will install all your Connected Apps in a sandbox environment and monitor them for indicators of compromise (IOC). This will ensure that you closely monitor Connected App connections for compromise.
Action:
It is necessary to address the risk with Connected Apps, but 3rd-party risk doesn’t start or stop with them. In a Salesforce org, several 3rd-party entry points must be protected. For example, there may be external services, remote sites, CORS policies, CSP domains, remotely loaded scripts (remember Polyfill?), which pose a risk. Moreover, custom code is a major attack vector.
Action:
The question you must ask yourself is whether it is worth investing in Salesforce security using tooling that is specifically designed for Salesforce. If your answer is yes, then we are aligned, and we should talk about how we can help you achieve your goals and keep your Salesforce environments secure.
