Ghost Sites: Stealing Data From Deactivated Salesforce Communities

Varonis Threat Labs discovered improperly deactivated Salesforce 'ghost' Sites that are easily found, accessible, and exploitable by attackers.
Nitay Bachrach
2 min read
Last updated May 31, 2023

Varonis Threat Labs discovered that improperly deactivated and unmaintained Salesforce "ghost sites” remain accessible and vulnerable to risk. By manipulating the host header, threat actors can gain access to sensitive PII and business data.

Salesforce Sites allow you to create customized communities, enabling partners and customers to collaborate within a company’s Salesforce environment.

When these communities are no longer needed, though, they are often set aside but not deactivated. Because these unused sites are not maintained, they aren’t tested against vulnerabilities, and admins fail to update the site’s security measures according to newer guidelines.

Varonis Threat Labs discovered that many of these improperly deactivated Salesforce Sites are still pulling fresh data and are easily found, accessible, and exploitable by attackers. We dubbed these abandoned, unprotected, and unmonitored Salesforce Communities “ghost sites.”

In this blog, we’ll show you how these ghost sites manifest, how to locate them, and how an attacker can use a simple exploit to access them.

Where do ghost sites come from?

The creation of a ghost site starts with custom domain names.

Instead of using unappealing internal URLs like “acmeorg.my.site.com/partners,” companies create custom domains so partners can browse "partners.acme.org” instead. This is accomplished by configuring the DNS record so that “partners.acme.org” points to the lovely, curated Salesforce Community Site at “partners.acme.org. 00d400.live.siteforce.com.

Note that the new DNS record should have a CNAME entry that points to your FQDN, followed by the organization ID, followed by.live.siteforce.com. With the DNS record changed, partners visiting “partners.acme.org” will be able to browse Acme’s Salesforce site.

The trouble begins when Acme decides to choose a new Community Site vendor.

Birth of a ghost site

Like any other technology, companies might replace a Salesforce Experience Site with an alternative.

Subsequently, Acme modifies the DNS record of “partners.acme.org” to point toward a new site that might run in their AWS environment, for example, instead of “partners.acme.org.00d400.live.siteforce.com.”

From the users’ viewpoint, the Salesforce Site is gone, and a new community page is available. The new page might be completely disconnected from Salesforce, not running in the environment, and no obvious integrations are detectable.

Varonis Threat Labs researchers discovered that many companies stop at just modifying DNS records. They do not remove the custom domain in Salesforce, nor do they deactivate the site. Instead, the site continues to exist, pulling data and becoming a ghost site.

Speaking with ghost sites

Now that Acme’s domain no longer points toward Salesforce, simply calling in endpoints such as Aura will not work.aura-not-working-1

aura-working-2

But because ghost sites are still active in Salesforce, the siteforce domain still resolves, meaning it’s available under the right circumstances. A straightforward GET request results in an error — but there is another way to gain access.

Attackers can exploit these sites by simply changing the host header. This would trick Salesforce into believing that the site was accessed as https://partners.acme.org/ and that Salesforce would serve the site to the attacker.

regular-site-3

While it’s true that these sites are also accessible using the full internal URLs, these URLs are difficult for an external attacker to identify. However, using tools that index and archive DNS records — such as SecurityTrails and similar tools — make identifying ghost sites much easier.

Adding to the risk is the fact that old, obsolete sites are less maintained and, therefore, less secure, increasing the ease of an attack.

Ghost site secrets

Our research found many such sites with confidential data, including PII and sensitive business data that were not otherwise accessible. The exposed data is not restricted to only old data from when the site was in use; it also includes new records that were shared with the guest user due to the sharing configuration in their Salesforce environment.

Exorcising ghost sites

To solve the problem of ghost sites — and to mitigate other threats — sites that are no longer in use should be deactivated. It’s important to keep track of all Salesforce sites and their respective users’ permissions — including both community and guest users. Varonis Threat Labs created a guide for protecting your active Salesforce Communities against recon and data theft, and you can read more about keeping sensitive Salesforce data safe here.

What should I do now?

Below are three ways you can continue your journey to reduce data risk at your company:

1

Schedule a demo with us to see Varonis in action. We'll personalize the session to your org's data security needs and answer any questions.

2

See a sample of our Data Risk Assessment and learn the risks that could be lingering in your environment. Varonis' DRA is completely free and offers a clear path to automated remediation.

3

Follow us on LinkedIn, YouTube, and X (Twitter) for bite-sized insights on all things data security, including DSPM, threat detection, AI security, and more.

Try Varonis free.

Get a detailed data risk report based on your company’s data.
Deploys in minutes.

Keep reading

Varonis tackles hundreds of use cases, making it the ultimate platform to stop data breaches and ensure compliance.

security-vulnerabilities-in-apex-code-could-leak-salesforce-data
Security Vulnerabilities in Apex Code Could Leak Salesforce Data
Varonis' threat researchers identified high- and critical-severity vulnerabilities in Apex, a programming language for customizing Salesforce instances.
data-theft-in-salesforce:-manipulating-public-links
Data Theft in Salesforce: Manipulating Public Links
Varonis Threat Labs uncovered a vulnerability in Salesforce's public link feature that threat actors could exploit to retrieve sensitive data.
no-time-to-rest:-check-your-jira-permissions-for-leaks
No Time to REST: Check Your Jira Permissions for Leaks
Varonis researchers enumerated a list of 812 subdomains and found 689 accessible Jira instances. We found 3,774 public dashboards, 244 projects, and 75,629 issues containing email addresses, URLs, and IP...
varonis-delivers-market-leading-salesforce-security
Varonis Delivers Market-leading Salesforce Security
Varonis delivers market-leading Salesforce security