A shocking number of organizations — including banks and healthcare providers — are leaking private and sensitive information from their public Salesforce Community websites, KrebsOnSecurity has learned. The data exposures all stem from a misconfiguration in Salesforce Community that allows an unauthenticated user to access records that should only be available after logging in.
A researcher found DC Health had five Salesforce Community sites exposing data.
Salesforce Community is a widely-used cloud-based software product that makes it easy for organizations to quickly create websites. Customers can access a Salesforce Community website in two ways: Authenticated access (requiring login), and guest user access (no login required). The guest access feature allows unauthenticated users to view specific content and resources without needing to log in.
However, sometimes Salesforce administrators mistakenly grant guest users access to internal resources, which can cause unauthorized users to access an organization’s private information and lead to potential data leaks.
Until being contacted by this reporter on Monday, the state of Vermont had at least five separate Salesforce Community sites that allowed guest access to sensitive data, including a Pandemic Unemployment Assistance program that exposed the applicant’s full name, Social Security number, address, phone number, email, and bank account number.
This misconfigured Salesforce Community site from the state of Vermont was leaking pandemic assistance loan application data, including names, SSNs, email address and bank account information.
Vermont’s Chief Information Security Officer Scott Carbee said his security teams have been conducting a full review of their Salesforce Community sites, and already found one additional Salesforce site operated by the state that was also misconfigured to allow guest access to sensitive information.
“My team is frustrated by the permissive nature of the platform,” Carbee said.
Carbee said the vulnerable sites were all created rapidly in response to the Coronavirus pandemic, and were not subjected to their normal security review process.
“During the pandemic, we were largely standing up tons of applications, and let’s just say a lot of them didn’t have the full benefit of our dev/ops process,” Carbee said. “In our case, we didn’t have any native Salesforce developers when we had to suddenly stand up all these sites.”
Earlier this week, KrebsOnSecurity notified Columbus, Ohio-based Huntington Bank that its recently acquired TCF Bank had a Salesforce Community website that was leaking documents related to commercial loans. The data fields in those loan applications included name, address, full Social Security number, title, federal ID, IP address, average monthly payroll, and loan amount.
Huntington Bank has disabled the leaky TCF Bank Salesforce website. Matthew Jennings, deputy chief information security officer at Huntington, said the company was still investigating how the misconfiguration occurred, how long it lasted, and how many records may have been exposed.
KrebsOnSecurity learned of the leaks from security researcher Charan Akiri, who said he wrote a program that identified hundreds of other organizations running misconfigured Salesforce pages. But Akiri said he’s been wary of probing too far, and has had difficulty getting responses from most of the organizations he has notified to date.
“In January and February 2023, I contacted government organizations and several companies, but I did not receive any response from these organizations,” Akiri said. “To address the issue further, I reached out to several CISOs on LinkedIn and Twitter. As a result, five companies eventually fixed the problem. Unfortunately, I did not receive any responses from government organizations.”
The problem Akiri has been trying to raise awareness about came to the fore in August 2021, when security researcher Aaron Costello published a blog post explaining how misconfigurations in Salesforce Community sites could be exploited to reveal sensitive data (Costello subsequently published a follow-up post detailing how to lock down Salesforce Community sites).
On Monday, KrebsOnSecurity used Akiri’s findings to notify Washington D.C. city administrators that at least five different public DC Health websites were leaking sensitive information. One DC Health Salesforce Community website designed for health professionals seeking to renew licenses with the city leaked documents that included the applicant’s full name, address, Social Security number, date of birth, license number and expiration, and more.
Akiri said he notified the Washington D.C. government in February about his findings, but received no response. Reached by KrebsOnSecurity, interim Chief Information Security Officer Mike Rupert initially said the District had hired a third party to investigate, and that the third party confirmed the District’s IT systems were not vulnerable to data loss from the reported Salesforce configuration issue.
But after being presented with a document including the Social Security number of a health professional in D.C. that was downloaded in real-time from the DC Health public Salesforce website, Rupert acknowledged his team had overlooked some configuration settings.
Washington, D.C. health administrators are still smarting from a data breach earlier this year at the health insurance exchange DC Health Link, which exposed personal information for more than 56,000 users, including many members of Congress.
That data later wound up for sale on a top cybercrime forum. The Associated Press reports that the DC Health Link breach was likewise the result of human error, and said an investigation revealed the cause was a DC Health Link server that was “misconfigured to allow access to the reports on the server without proper authentication.”
Salesforce says the data exposures are not the result of a vulnerability inherent to the Salesforce platform, but they can occur when customers’ access control permissions are misconfigured.
“As previously communicated to all Experience Site and Sites customers, we recommend utilizing the Guest User Access Report Package to assist in reviewing access control permissions for unauthenticated users,” reads a Salesforce advisory from Sept. 2022. “Additionally, we suggest reviewing the following Help article, Best Practices and Considerations When Configuring the Guest User Profile.”
In a written statement, Salesforce said it is actively focused on data security for organizations with guest users, and that it continues to release “robust tools and guidance for our customers,” including:
Control Which Users Experience Cloud Site Users Can See
Best Practices and Considerations When Configuring the Guest User Profile
“We’ve also continued to update our Guest User security policies, beginning with our Spring ‘21 release with more to come in Summer ‘23,” the statement reads. “Lastly, we continue to proactively communicate with customers to help them understand the capabilities available to them, and how they can best secure their instance of Salesforce to meet their security, contractual, and regulatory obligations.”
Sounds like Salesforce has the same security strategy as AWS. Market their products claiming that they’ll handle (and be responsible for) security issues that don’t result from user misconfiguration, then define “configuration” such that it covers basically the entire attack surface and make correct configuration so unlikely when performed by mere mortals that only an idiot would ever bother to hit the parts the company is legally responsible for. What a business model.
I don’t know how familiair you are with Salesforce but wouldn’t you consider it misconfiguration if someone grants access to objects to the Guest User profile?
That is exactly the question; whose responsibility are these misconfigurations.
It varies I’m sure – yet they have a fair defense by putting out literature on the
“correct configuration” and having their (enterprise?) clients ignore that…
Are they any more responsible than Linus for hack webadmins blowing it?
It’s called a Shared Responsibility Model and, I believe, all Cloud vendors have one. Yes, it does amount to CYA but, like it or not, customers do have to configure things correctly in order for them to work as expected. There’s no “one size fits all” config that’ll work for every single customer so the customer must bear some responsibility.
And sure, not every company using this stuff has people that are incredibly skilled in this area. There are many other options, however, including paying a third party to do your config, pen testing after it’s set up, etc, etc. I think these issues stem mostly from a lack of education in regard to how these products work and who takes care of what. People make assumptions about AWS or Azure just taking care of it when the reality isn’t that at all. If the company documents what they are responsible for (and the two mentioned prior do exactly that) and the customer makes an assumption, it’s kind of hard to pin it on the company, IMO.
I think the correct thing to do is to hire people who at least have passed one Salesforce certification and lean or weight your questions towards the security end of things. You’d be surprised how many companies have ‘accidental’ admins who started managing without studying or getting a developer org to learn something. Because the system doesn’t crash, these people then think they’re ok and that they know what they’re doing, when nothing could be farther from the truth. That’s analogous to a person who’s a terrible driver, but who hasn’t had a fatal accident yet, and because of that, they think they’re a good driver (“Well, I haven’t killed anyone”)
TBH, you complaint reads more like, “I can’t be bothered to take the time to understand how all of this works that I’m putting my business critical data and information in, so give me an easy button and you be responsible “. Where as, you shouldn’t approach cloud any differently than data center IMO. It’s the same thing, just different hosting, by different companies, in different locations. If SalesForce and Amazon’s platform makes the mistake, then that is one thing. But if you make the mistake and your reason is “I didn’t understand how it works due to not doing my due diligence” then why should the host be responsible? It’s not different than if you provision in a traditional DC and make the same mistake. Now I do agree that marketing from these companies makes it sound like it’s easier to bypass traditional security steps, but a security mind should know better and raise the alarm to anyone who is thinking that way.
Salesforce admins needs to stop the sharing of unwanted data to guest users. I am sure that they have clear security model and not admins or developer who have well trained on that.
Salesforce aura objects misconfigs, not surprising. And the incompetency of these government and private organizations to address and rectify these misconfigurations isn’t alarming either.
Ten years ago, I worked for a healthcare company managing Medicaid accounts and it uploaded sensitive client data to a state reporting system. The data was uploaded to the front facing website instead of the secure site. Withing 5 minutes there were hits from China and Eastern European countries. I can guarantee that any information on Sales Force Community sites open by guest access has already been gleaned by the China and Korea. They are monitoring all of our systems.
:Facepalm: is all I can say.
PS. Also why would a database need a guest access?
Guest access is for public knowledgebases or the ability to request a quote without having to authenticate.
I run my own Salesforce Security consultancy. At the same time I was drafting a blog about Salesforce Community Security issues, this article was published. My blog covers authenticated access and has a solution to the issue as well. Please have a look at https://www.platinum7.com.au/salesforce-communities-security-issue
This is very interesting considering that the RSA Conference is in San Francisco this week.
I didn’t see any security related marketing content on this salesforce.com landing page that I clicked on after typing “Salesforce” in Google and clicking on the first sponsored result.
https://www.salesforce.com/form/demo/salesforce-products/
However, I have not visited their home page.
interim Chief Information Security Officer Mike Rupert.
On the basis of this report, perhaps this guy should only be interim interim CISO and briefly?
Somebody should file a FOIA request to see if the 3rd party report exists and if so, whether it caught the vulnerability and recommended mitigations, or whether the 3rd party is ineffective.
Something seems fishy here.
So the si didn’t configure the data model correctly and then an untrained admin got loose.
“Carbee said the vulnerable sites were all created rapidly in response to the Coronavirus pandemic, and were not subjected to their normal security review process.”
I was a security analyst for a large municipal health department when novel coronavirus reached the U.S. I was already frustrated before that by cases of established IT security procedures being bypassed in the name of questionable operational expediency, so toward the end of 2019 I started documenting these to review with management later.
Come February 2020, I had to throw this notion out the window. Emergency became the new normal very rapidly, and if a stakeholder could link the word “CoViD” to their project by any tortured twist of logic, then no questions could be asked.
I don’t work there now. I can only hope that three years later the situation has stabilized enough that my old IT department has been able to return to more deliberate and comprehensive practices. In any case, the techs and managers implicated in this report have my sympathy, and I hope they’ve also been able to regain their sanity. I also hope they are grateful to the researchers that help them find the issues they’ve missed, more than annoyed.
I just email DC’s Department of Health to ask them to confirm that their vulnerability has been fixed…. Very not good given the fees for being licensed in DC…
Maybe getting fixed? DC’s licensing Salesforce site now shows:
“Sorry, We are down for Scheduled maintenance”
Hmmm, yeah, “scheduled”. Uh-huh, yeah.
No worries. I’m sure ChatGPT will solve it all!
Could all this leaking be on purpose or are these “experts” really this dumb?
While I follow security issues the best I can, I thought I wasn’t smart enough to be a “pro”. Maybe I’m not as dumb as I thought.
what does cgpt have to do with any of this?
In that it also doesn’t yet faithfully detect and understand sarcasm. Meta joke.
https://www.varonis.com/blog/salesforce-misconfiguration-causes-sensitive-data-leaks
Well, the DC one looks to be a no-brainer. After all, the site snapshot there says it is copyrighted in the year “203”. Who thought about cybersecurity back then, when the major issue of the day was your lost goat in the forest?
Saw that, solid attention to detail there. “What could go wrong?”
Salesforce has consistently recommended to admins that these sorts of holes are plugged. Their security audit tool calls this out as a high-priority, critical issue. The biggest problems (not in any particular order) are:
1. Packages made by ISV partners that leave these holes open for “some purpose” that if an admin tries to close them, it breaks the necessary access.
2. Admins who just don’t know any better (this is getting more and more common, as the focus is that admins pass the exam rather than gain the requisite knowledge before getting their first admin gig).
3. Specialization in Experience Cloud (this is NOT called Communities anymore, and hasn’t been for two years) is often the role of a consultant, so admins who are building them are often not aware of the issues involved.
How do we fix these issues? As they have different causes, we have to approach them individually. I say shame on these ISV’s who create the problems that admins can’t fix. And we really need to rethink the attitude of “everyone can be an admin” and “passing the test is all that matters.” We do ourselves and the public a disservice when people don’t know how to address these things.
Totally agree RC. And apologies for using the term Communities… The product has changed names a few times and sometimes the old one sticks. It is tough for admins though – Salesforce is a huge product and it is basically impossible for one person to know all the minute details about every feature. The consultants on the other hand should know, in detail, their speciality and if they’re bought in to assist in getting an Experience Cloud site set up, they should be making sure it is secure…
Definitely agree on all counts here. That said, there are basics of “what to share and what to close down” that an admin should know about Experience Cloud. But Salesforce, in their infinite wisdom, took everything EC off the Admin exam a couple years ago. Consultants are important, absolutely. But a lot of organizations don’t have the budget in addition to admins, and more and more, admins don’t have the basic knowledge they need to keep an org safe.
Why aren’t State DAs going after this shoddy workmanship on critical infrastructure? Salesforce needs to be sued into oblivion. A configuration that permits this level of insecurity crosses the line into malicious neglect.
You’re also getting more and more ‘accidental admins’ who don’t quite know what they’re doing but since everyone else in the company knows a whole lot less, including their boss, these folks think everything is hunky dorry!
The whole concept is horrendously risky.
1 – build a central business platform for your core business.
2 – create a public website for your customers to interact directly with that core platform.
3 – hope that no admin, consultant or over permissions person in marketing ops makes no mistake.
4 – hope no app developer makes a mistake
…
Why not segment public and private platforms and neatly integrate them securely.
“Just make it a protocol, all problems solved.” -Dorsey
I think it is worrisome that Salesforce is marketing their product for use by the non-profit sector, which does not have the resources nor the expertise to appropriately manage these types of configurations. Non-profits are using sfdc to track the most sensitive information imaginable about vulnerable populations.
Access decisions must be tied to an active decision by an administrator with warnings designed in by Salesforce before allowing the administrator to click allow.
Any other design at this point is a actionable Salesforce failure.
So this misconfiguration was caused by “human error”. No AI occupies this market, yet,I guess.
After that, we will still have human error to blame breaches on.
The AI will be smart enough to blame the error on a human anyway.
hakcer hire m ail hackerspytech on googlemail
This problem has been on OWASP Top 10 since OWASP Top 10 was first published! LMAO
People will continue to people, no matter how fancy the technology.
Akiri’s methodology should be standard practice, and employed by the vendors of their technologies. Call it a “bonus service” to ensure their customers’ implementations are proper and ‘safe’.