Inactive, unmaintained Salesforce sites vulnerable to threat actors

Improperly deactivated and unmaintained Salesforce sites are vulnerable to threat actors who can gain access to sensitive business data and personally identifiable information (PII) by simply changing the host header. That’s according to new research from Varonis Threat Labs, which explores the threats posed by Salesforce “ghost sites” that are no longer needed, set aside, but not deactivated. These sites are typically not maintained or tested against vulnerabilities, while admins fail to update security measures according to newer guidelines. However, they can still pull fresh data and are easily exploitable by malicious actors, the researchers said.

The research follows a recent report from Okta, which warned that inactive and non-maintained accounts pose significant account takeover security risks with cybercriminals adept at using information stolen from forgotten or otherwise non-upheld accounts to exploit active accounts. Meanwhile, Google announced that it is updating its inactivity policy for Google Accounts to two years on security grounds, meaning that if a personal account has not been used or signed into for at least two years, it may delete the account and its contents. Google stated that abandoned accounts are at least ten-times less likely than active accounts to have multifactor authentication set up and typically rely on password reuse, making them particularly vulnerable to compromise.

What are Salesforce ghost sites?

Salesforce ghost sites are typically created when companies use custom domain names instead of unappealing internal URLs so partners can browse them, Varonis Threat Labs wrote. “This is accomplished by configuring the DNS record so that “partners.acme.org” [for example] points to the lovely, curated Salesforce Community Site at “partners.acme.org. 00d400.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, the researchers said.

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,” Varonis Threat Labs added. 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.

However, the 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.”

Attackers can exploit Salesforce ghost sites by changing the host header

As a ghost site remains active in Salesforce, the siteforce domain still resolves, meaning it’s available under the right circumstances, the researchers said. “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 tricks Salesforce into believing that the site was accessed correctly, and Salesforce would serve the site to the attacker, they added.

Although these sites are also accessible using the full internal URLs, these URLs are difficult for an external attacker to identify, the researchers pointed out. “However, using tools that index and archive DNS records — such as SecurityTrails and other similar tools — makes 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.

Salesforce ghost sites found to host sensitive business data, PII

The Varonis researchers said they found many inactive sites with confidential data, including sensitive business data and PII, that was 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.”

Sites that are no longer in use should be deactivated, the researchers advised, along with highlighting the importance of tracking all Salesforce sites and their respective users’ permissions — including both community and guest users. Varonis Threat Labs has also created a guide for protecting active Salesforce Communities against recon and data theft.