Ghost Sites: Stealing Data From Deactivated Salesforce Communities

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.

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.

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.