informa
News

Misconfigured Salesforce Communities Place Orgs at Risk of Data Theft, Adversary Recon

Organizations often inadvertently let unauthenticated guests have access to a lot more data within these communities than they should, security vendor says.

Many organizations that allow customers and partners to interact with their Salesforce instance via Salesforce Communities are at heightened risk of data theft and adversary reconnaissance activity because of improperly configured settings.

Researchers from Varonis say they recently discovered numerous publicly accessible Salesforce Communities with a configuration that allows attackers to search for information such as customer lists, support issues, and employee email addresses.

At minimum, the misconfiguration offers attackers a way to gather information for a future spear-phishing campaign, while in a worst-case scenario they can exploit weak configuration settings to steal sensitive data about the business and its operations. In some instances, the configuration error can even allow attackers to move laterally and access data from other services that are tied to the Salesforce account, Varonis said. The issue impacts organizations that allow even a limited amount of anonymous — or unauthenticated — guests to access their Salesforce community.

Salesforce Community Cloud is a platform that allows organizations to quickly set up branded Web pages and websites that customers, partners, employees, and others can use to connect and collaborate. Use cases for a Salesforce Community include customer support, marketing, and subscription management. Salesforce Communities are Internet-facing because they are designed to be accessed from outside the organization. They are indexed by Google, which makes it easy not just for customers and partners to find them, but also attackers looking for vulnerable sites.

"A single organization can have dozens of communities," says Rob Sobers, vice president of marketing at Varonis. "We've seen big customers with hundreds of them that serve different purposes for their organization."

Security issues can result when organizations give anonymous guest users on these communities — those that don't need a password or other authentication measure — overly permissive access to data that they should not be allowed to access. Often administrators do this without even realizing the problem because of how complicated Salesforce's configuration settings can be, Sobers says.

Salesforce Communities run on a rapid, component-oriented development framework called Lightning. The components, which are called "aura components," are objects that developers can use to quickly assemble custom Web pages, Varonis said in a report this week. Multiple application programming interfaces (APIs) are present in the environment that allow for action to be taken against these objects, such as viewing and updating records. Some of the components or objects that users can query with aura APIs include those pertaining to the account, users, support cases, employees, and leads.

An unauthenticated user with malicious intent and access to these APIs can query objects to collect information about the site and about the Salesforce account, or to view default and custom objects and search for, list, and retrieve data and records. In its report, Varonis listed multiple APIs and how they could be used to pull down data from a vulnerable Salesforce Community site.

Finding a Salesforce Community site to attack is often little more than a Google search away for adversaries because of the easily identifiable URL fingerprints associated with these communities. Numerous avenues are then available for an attacker to gather information about the site and to determine the access an unauthenticated guest user might have. 

"It would only take an attacker a few minutes before they could start pulling down data via the APIs we documented," Sobers says.

Many admins are not aware of the potential security implications, he says. The aura APIs that Varonis exploited are not intended for public use and are undocumented.

"Most Salesforce admins have no clue they exist and have no idea that the security settings they've configured would have this downstream effect," Sobers notes. "The issue is that the Salesforce configuration is so complex and there are so many chain reactions that can happen."

Previous Warning
This is not the first time a security vendor has sounded the alarm on the potential attack vectors available for adversaries within Salesforce's Lightning framework. Last October, security researcher Aaron Costello, now with SaaS security firm AppOmni, published research showing how the way in which security is implemented within the framework allows attacker to carry out a variety of malicious actions. These include pulling custom object names, retrieving records from objects, and crawling applications for other avenues for attack.

"There are hundreds of configuration settings in Salesforce and hundreds of additional permissions, entitlements, access rights, and profile settings that can be applied to users and applications," says Brendan O’Connor, CEO and co-founder at AppOmni. "Modern SaaS platforms are closer to operating systems in their power, flexibility, and configuration options than the simple Web applications they were 10 years ago."

Salesforce is already taking many steps to prevent users from making serious configuration mistakes, Sobers says. They have, for instance, been removing the ability for guest users to access excessive data and have made a few changes to ensure that some crucial settings are secure by default.

Organizations, too, can do a lot to shore up security around their Salesforce Communities, starting with implementing the principle of least privilege, Varonis says. Each organization must also decide whether to make their community completely open to the world, require registration, or a mix. 

"This is what makes it easy to misconfigure — most organizations run in a hybrid mode where they want to expose some things and hide others," Sobers says. 

Decisions about access rights needs to be made at the organizational level, the object level, and down to the individual field level. 

"For example, user role X can view a customer record, but they can't see the attached contract," he says.

Turning off guest access would mitigate risk significantly, but that's not an option for many organizations due to business requirements, he notes. 

"Salesforce and many other SaaS vendors preach a 'shared-responsibility' model," Sobers says. "It's Salesforce's responsibility to make it hard for customers to make critical mistakes, but at the end of the day, it is up to each customer to understand these settings and configure them appropriately."

Recommended Reading: