The human factor in Salesforce security: From permission creep to social engineering

In this article:

The relentless expansion of Salesforce across the business world has created a parallel digital universe, one in which administrators and developers are trained differently from their IT counterparts, apps run on a SaaS/cloud platform with a confusing shared-responsibility model, and security and AppSec best practices may not be followed or even understood.

The results are over-permissioning, configuration drift, security blind spots, abandoned profiles and poorly administered security within many Salesforce environments. Some of these factors contributed to the waves of Salesforce breaches earlier this year, which may serve as a wake-up call about the vulnerabilities within.

More security managers, CISOs and CIOs need to be aware of the Salesforce-based shadow ecosystem that may be growing within their own organizations. Salesforce admins and developers will ultimately have to be cross-trained in best practices. Until then, it's best to take advantage of the tools and practices that can help secure your Salesforce environment.

How Salesforce became its own universe

Today's Salesforce is a long way from the customer-relationship-management tool that debuted in 1999. Over time, its users have found that they can adapt the basic Salesforce tools to manage suppliers, keep track of inventory, manage invoices and billing, build up libraries of patient data, store and track changes in contracts and legal documents, and much more.

"When you think about Salesforce originally, it was a CRM, and it was mainly used for just sales and leads and gens and ops and updating leadership and everything else that's going on," says Justin Hazard, Principal Security Architect, AutoRABIT. "It does a lot more than that today."

After it moved its operations to the cloud, Salesforce rapidly expanded its capabilities to meet user demand. It is now an independent cloud-based platform with its own application ecosystem, app store, programming languages, developer lexicon, and administrator and developer certification programs.

"It is a programmable platform which has its own permissions, which has its own data model, which has automation that works every day," says Prasanth Samudrala, VP of Products at AutoRABIT. "It's not a CRM. It's company-management software."

Many organizations may not realize how important and powerful their own Salesforce deployments are and the attack surface that they present. Salesforce developers and administrators may be part of the marketing teams, isolated from IT, development and security teams and unable to learn from them.

"Most Salesforce development teams are not connected to that enterprise risk team," observes Hazard.

How developing for Salesforce is different

Developing for Salesforce is not like developing for other platforms. It's much faster, and it skips many of the checks and balances that have been built into regular application development.

"You're basically just bringing value to your business users within a very short period of time," says Samudrala, "compared to the traditional [approach], where if somebody wants an app, you write a spec, it goes to a bunch of engineers, they code the app, it goes to QA, it goes to external internal UAT [user acceptance testing], external UAT, then comes to production. All of those [steps] are simply skipped."

In a way, that's more democratic. Samudrala refers to it as "empowering the last mile user ... to simply go and create software and automation with clicks."

But to get enough people trained on Salesforce, the company has run aggressive recruitment campaigns, Samudrala argues.

"The more the number of developers that you have on your platform, your platform wins," he says. "How do you get the local developers? Well, you create campaigns. Hey, are you a nurse? Tired of working 22 hours a day? Here, learn this platform."

"They're not calling them your typical software engineers," Samudrala adds. "They call them Salesforce developers. It's a completely different term. It's a marketing term."

This has created millions of certified Salesforce developers and administrators. But they may not be as well trained as regular software engineers and system admins in best security practices.

"You have a group of people who are not trained in those security principles who are making decisions and making changes," says Lindsay Duran, Chief Marketing Officer, AutoRABIT. "This market of Salesforce developers has historically not had the level of sophisticated tooling to help them make fewer mistakes and to catch those mistakes as they happen."

An alternate set of terms

Salesforce — which Samudrala says "is not just a technology company, it's a marketing giant" — has created an entire alternative vocabulary to refer to common security and development terms.

"The verbiage that the industry uses to talk between two people from the same industry, Salesforce goes outside of that," he adds. "Instead of just calling it a 'table,' they will call it 'objects.' Instead of just calling it 'role-based access controls,' they will call it 'permission sets.'"

That may lead to communication problems between Salesforce developers and admins and their counterparts in the regular IT world.

"There are the Salesforce devs and admins that know Salesforce really well, and then you have the traditional security folks that know security really well and understand application security," explains Hazard. "After a decade of doing this stuff, we're trying to bridge that gap between the two because they don't talk the same, the vernacular's different."

Salesforce has leaned heavily into low-code/no-code development, which as Hazard points out, is not a problem if it's done right. But there's a tremendous amount of customer, supplier, account and patient data in many Salesforce instances, and this raises the stakes.

"From a risk perspective, with the data that's available in a lot of these Salesforce instances, it goes through the roof very, very quickly," Hazard says.

More recently, Samudrala says, Salesforce has been leaning into vibe coding using its Agentforce AI-development platform, which only magnifies the risks that come with bad coding.

"You can literally talk to build now in Salesforce, thanks to Agentforce Vibes," says Samudrala. "By bringing that into the Salesforce environment to the last-mile admin, you basically again multiplied the threat."

Misunderstandings and drift

Let's get one thing out of the way: Salesforce itself does not have poor security. It locks down its cloud-based instances very well. But almost all Salesforce clients customize their own deployments to suit their own business needs, and any changes made to a default Salesforce package is the client's responsibility, not Salesforce's.

"When you get a Salesforce environment, you get it in a prepackaged way," explains Samudrala. "Any new configuration that you start adding, that starts creating a drift from the baseline."

"That is your responsibility as the buyer of Salesforce, and I think people have significantly misunderstood or underestimated their responsibility in that instance," adds Duran.

Because of this, many Salesforce admins may not realize how far away from the standard Salesforce configurations they've drifted, or how some common practices may accelerate that drift.

For example, Duran and Hazard say, Salesforce encourages admins to clone existing user profiles when creating new user profiles. All the old user's permissions will be grafted onto the new user, even if the new user doesn't need them — a serious violation of the principle of least privilege.

"Maybe you've then copied that same profile 500 to 1,000 times more," says Duran. "It's not uncommon for us to see that you might have copied a profile and now 2,000 people have API enabled access into your org, or you have given large groups of people the ability to just download all of the records in Salesforce without knowing it."

Hazard says there is a better way to clone profiles.

"What we're seeing in that configuration drift is people just using things that weren't necessarily the intended use for," he says. "What you should have is a template of a bare-bones user that then you add permissions to, instead of a super-high admin user that you remove permissions from."

AutoRABIT's developers have come up with a tool called Guard to keep an eye on excessive permissions, Hazard says.

"They look at all the users, they look at all the different permissions, they look at all of the different groups and whatnot, and they then map those things out so that you can go in and clearly define what you're looking for," he says.

Likewise, Samudrala says there are ways to enforce least privilege in a Salesforce environment, such as by removing dangerous privileges and segregating duties in permission-set groupings, as well as just-in-time access for admin privileges.

"You have to verify how much data is getting exported," he adds. "That would have prevented Scattered Spider, by the way."

Keeping an eye on tokens and data exfiltration

Samudrala is referring to two different waves of attacks on Salesforce implementations earlier this year by allied attacker groups, ShinyHunters and Scattered Spider.

The first wave involved voice-phishing, or vishing, social-engineering attacks on companies such as Google, Chanel and Quantas. Callers convinced employees of those companies to add malicious third-party apps to their Salesforce instances. Data was stolen from the Salesforce instances and the companies were extorted, although many refused to pay the ransoms.

The second wave used OAuth tokens stolen from a company called Salesloft to break into Drift chatbot interfaces in the Salesforce instances of yet more companies to steal yet more data.

"The attackers got into the Salesloft environment and then the OAuth tokens for all of those customers were available to them because of some bad practices" involving the tokens, Hazard says

He adds that AutoRABIT tools such as the permissions-monitoring tool Guard would have spotted the incursion, although they would not have been able to stop it due to the legitimate permissions already granted to the stolen tokens.

"Because of where the OAuth token sat and what happened in that particular situation, the big thing is you would have been aware of what was going on," he says.

"What it would have done is if you had Guard in place and you looked at the OAuth token and you were like, 'Why does this have permission to everything? Let's scale that back to what it's actually needed,' it would have limited the damage."

A wake-up call

Duran, Hazard and Samudrala all hope that the media exposure given to the recent Salesforce breaches force the mainstream information-security industry to pay attention to the vulnerabilities and misconfigurations in custom Salesforce instances.

"We're already seeing Salesforce take action," says Hazard. "They're limiting very specific things and they're now enforcing different things that they didn't necessarily have enforced beforehand, which is great."

"Scattered Spider is like a future that we predicted about four or five years ago, because even then there were these minor breaches that would happen," Samudrala adds.

But he says there needs to be more awareness among information-security managers of just how big a threat Salesforce vulnerabilities can pose.

"We're trying to call out to the CIOs and CSOs of the world that [Salesforce] is an attack surface," Samudrala says. "You need to have security around this attack surface, so you need to understand what's your baseline configuration when somebody is making, the last mile user is making changes."

That's especially important, Hazard adds, when Salesforce attackers are now using the proven technique of poisoning online software repositories with malicious code — as may have happened in the initial Salesloft Drift attacks.

"They're creating malicious applications, hosting them over on like GitHub or open Bitbucket or GitLab or something along those lines," he says, "and then running SEO to get it at the top of the charts and saying, 'Hey, come download this, you can connect to Salesloft and you do all the things that you need to do.'"

Samudrala emphasizes that although he wants Salesforce developers and admins to learn and use best security practices and terminology, he's not trying to be exclusionary or say that Salesforce devs are inferior to traditional ones.

"We want more people to do, run software," he says. "We want more people to create software, to build great products, to build great things. But these tools and interfaces that are being provided to build software, they have to take the responsible way of keeping the user safe."