Salesforce customers are abandoning their sites without deactivating them, leaving sensitive corporate, vendor, and user data behind.
The problem occurs within what the service calls “Communities,” busy sites that allow partners, vendors, and customers to collaborate within a company’s Salesforce environment. By their nature, Communities contain lots of potentially high-value business and personal information, which can be exposed when administrators aren’t diligent enough.
Sometimes, for example, companies will move from Salesforce to other providers, taking their domains with them. When they do that, though, many forget to erase what they’ve left behind. Researchers from Varonis are calling these forgotten Communities “ghost sites,” in a report published May 31.
Ghost sites may be forgotten, but they’re not without their hidden treasures. “It’s the same website, the same Community,” emphasizes Nitay Bachrach, security researcher for Varonis, “but now that things have changed, it’s more problematic. All of [the unerased data] is available for anyone.”
How Ghost Sites are Created
Every company wants a good, clean URL. For instance, a Salesforce customer called “Acme” might choose the custom domain “partners.acme.org” to point to its Community site at “partners.acme.org/00d400.live.siteforce.com.”
If Acme one day decides to leave Salesforce for another provider, it might choose to take “partners.acme.org” with them, modifying the DNS record to point to a new site hosted by, say, AWS. In this process, the researchers found, “many companies stop at just modifying DNS records. They do not remove the custom domain in Salesforce, nor do they deactivate the site.”
Put simply: While the URL has moved on, the site continues to exist, with all of the potentially sensitive communications, business records, and other business and personal information therein.
And it gets worse: Salesforce enables companies to automate the uploading of certain data streams that they may wish to share with partners and customers, using sharing rules.
“Basically, you set up a rule — you set up conditions — and any data that meets these conditions are shared,” explains Or Emanuel, Varonis’ director of research. “And this still applies for ghost sites because, again, Salesforce doesn’t know the difference. So the data, as long as it still meets the requirements, keeps [being sent out].”
The Risks Ghost Sites Pose
So what’s the problem with this situation? No malicious actor could easily know the precise internal domain associated with a company’s extant Salesforce site, after all. However, these sites can nonetheless be exploited.
The researchers pointed out that “tools that index and archive DNS records — such as SecurityTrails and other similar tools — makes identifying ghost sites much easier.”
Also, “because ghost sites are still active in Salesforce, the siteforce domain still resolves, meaning it’s available under the right circumstances,” according to the Varonis analysis. “A straightforward GET request results in an error — but there is another way to gain access.”
Specifically, attackers can simply change the host header: “This would trick Salesforce into believing that the site was accessed as “https://partners.acme.org/” and Salesforce would serve the site to the attacker.”
Adding to the risk is the fact that old, obsolete sites are less maintained and therefore less secure, increasing the ease of an attack.
Bottom line? When a Salesforce site is no longer active or needed, companies should always deactivate.
If they don’t, they leave not only their own data exposed, but also the data of the partners and users who have connected to their Community. And of course, partners and users don’t have the same ability to account for and deactivate sites they’ve merely connected to.
“So it’s [also] a risk management sense,” Bachrach says of the third-parties caught up in any potential mess.