7 ms·

Many public Salesforce sites are leaking private data

206 points by impish9208 4y ago

gazelle21 4y ago
This is a known issue. I was doing some bug bounty work on a target, found a salesforce domain leaking data. Reported it responsibly, and they basically told me to kick rocks. I have hear of similar issues from other security researchers.
paxys 4y ago
Salesforce is impossible to set up by design. The mistake here was that these small businesses and government agencies didn't contract with a Salesforce-preferred ISV charging $250+/hr per consultant to correctly configure it for them.
- tomrod 4y ago
  LOL. I wholeheartedly disagree where you place the blame. Broken-by-design means blame lies with Salesforce entirely. What _other_ major sources of data leaks should we expect from such past performance?
  - aliasxneo 4y ago
    I think there's an inferred /s at the end of the comment you're responding to :)
    - tomrod 4y ago
      I reckon I am the obligatory whoosh of the day :) -- thanks for recontextualizing
    - the_duke 4y ago
      I don't think so. Considering my experience with Saleforce, I'm quite sure the comment is entirely earnest.
    - Paul-Craft 4y ago
      FYI, I think you mean "implied," rather than "inferred." Remember the difference this way: when someone implies something, that means you may infer that they want you to believe it.
  - evilspammer 4y ago
    Cloudflare and AWS?
- bombcar 4y ago
  Those ISVs charging $250 an hour are the source of lots of the insecurity, because "that makes it work" finally.
- mym1990 4y ago
  Well its clearly not impossible since there is a whole industry of professionals doing it successfully for the past 2 decades. Salesforce is difficult to implement because it is extremely customizable and Salesforce is effectively completely hands off. It is not a small business product, and government contracts tend to be a race to the bottom for price, which results in poor quality of development.
layman51 4y ago
I still need to dig into the details, but does this exploit work primarily by changing stuff that appears in a URL?
- npace12 4y ago
  yeah for a public site thats exposed you just go to /003 and it would have a list of all the contacts lol
  - bombcar 4y ago
    When they went to longer IDs they REALLY MISSED OUT on the ability to make them cryptographically secure. https://help.salesforce.com/s/articleView?id=000385008&type=1 https://help.salesforce.com/s/articleView?id=000385008&type=... There was no need to make those human readable; 64 character UUIDs would have been just fine; as it is they're sequential and so if you know yours you can guess some more.
    - npace12 4y ago
      yeah that would have helped, but the issue was really that either the default RBAC for contacts when using "salesforce sites" was either Public from what I remember or it was one of those things that required a lot more proper setup and people usually would "get back to it later" and never did. So now, you have all your contacts available for unauthorized users to read, and since they provide automatic "list" pages as /<first 3 chars of record> you automatically get a nice table interface for anyone to scrape.
    - cdcarter 4y ago
      FWIW, the 18-character "longer ID" is just a checksum of the first 15 characters. The ID storage format did not change when 18-char IDs were released. So, in some ways, that opportunity hasn't been missed yet ;)
- chasd00 4y ago
  yeah URL but you can also manipulate browser async requests. Salesforce portals and plain old Salesforce make a lot of async calls back to the server which is the style these days. You watch these in your browser dev tools and sort of deduce what's happening. Then you can play around and see if you can replay these requests but pointed at different objects or records and see what happens. It's not any different than what you can do with any other site. It's just that Salesforce is an incredibly wide and deep platform. You need to understand a lot about general web app security and then you need to know the Salesforce way of doing it across the whole platform to cover your bases. It's just a very complicated beast.
satrday 4y ago
> “My team is frustrated by the permissive nature of the platform,” Carbee said. As someone who implements Salesforce projects for companies like this, I place the blame solely on whoever setup that Vermont org. Salesforce's permissions are very, very powerful and flexible, which also makes them complex. Salesforce recommends and works best with a "least privilege" security model. It is frustrating to me how often I see colleagues (and some clients) push for a "wide open" permissions structure, where every internal user can see everything unless otherwise specified. It's just laziness towards doing it the right way. During a brand-new Salesforce implementation for a multi-thousand user company, the stakeholders pushed me hard for an open policy. "We trust our employees". Ugh.
- bramblerose 4y ago
  > It's just laziness towards doing it the right way. Just because "least privilege" is "the right way" from a (some?) technical perspective, doesn't mean that it's the right way from a business perspective. There is a real, and significant, business cost to needing to wait for access and not being able to discover data (and thus not even knowing that you need to ask for access).
  - satrday 4y ago
    Definitely worth keeping in mind the business needs. I'm not going after "well designed security that meets the business needs". I'm calling out lazy security that cuts corners because doing it well takes time and effort. That being said, there is also a real, significant business cost to leaking sensitive information. If users are frequently waiting for access or unable to discover data, that's a failure in understanding the users needs and/or failing to test those needs in UAT during implementation. Convenience should never trump security, in this context.
    - martincmartin 4y ago
      I'm calling out lazy security that cuts corners because doing it well takes time and effort. Time and effort cost money. It's possible that the value gained is less than the cost, and so therefore isn't worth it. Of course, it's also possible they don't understand the value gained until there's a scandal.
webel0 4y ago
So many of these pages displayed tables that included a column for SSNs. Once they lock down the authorization permissions they ought to reconsider whether they really need to be displaying that data all over the place.
- chasd00 4y ago
  it's just bad config, it's a checkbox to censor fields like ssns on the UI. They need to check that box and click save.
  - carlmr 4y ago
    What's right should be easy. SSNs should be censored by default and it should be really hard to disable that.
    - chasd00 4y ago
      Well how would salesforce, or any system, know you’re storing social security numbers? A custom field (a user created table column in SF jargon) is defined using a handful of data types. It’s up to the person doing the configuration to take the extra steps given what kind of dat is going in these fields.
testplzignore 4y ago
> 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. Does FOIA apply here? Can we find out who the third party was?
chasd00 4y ago
i do a lot of Salesforce stuff, all of these issues are on Experience Cloud ( the Salesforce portal portfolio ). No one ever looks closely at the "guest user" this is basically used for unauthenticated portal pages, even though there isn't a user per-se there's still a session and it maps back to a user and profile ( profile = what controls security for a group of users in Salesforce ). What happens is the guest user ends up with read access on an Object ( SF term for a table ) somehow but it's never surfaced on the portal as a page and therefore never tested/known by the testing/qa team. Then, as an end user curious enough, through some browser request manipulation or address bar manipulation you can access the records for that Object (table). Guest user problems go far deeper than what the article describes and over the years Salesforce has been slowly dialing down what the guest user can have access to. It's an intricate exercise to properly lock down that profile in Experience Cloud (the portal feature portfolio). Guest user aside, privilege escalation attacks are very easy to introduce when writing custom APEX and front-end code. APEX is Salesforce's backend language similar to Java but runs in a system context not entirely constrained by the security settings of the running user. It's very simple for a naive developer to introduce a privilege escalation attack when writing an APEX method that is called from the front-end javascript framework ( LWC or Aura ). This is especially the case when the underlying record access model (think row-level access control in PostGres) is left to defaults or even opened further and not properly locked down. At my firm we have an entire practice dedicated to Salesforce security and require security scans, reviews, and remediation performed by this practice for all implementation projects because of things like this.
- Jach 4y ago
  Yeah, it's a sad mess. I used to work at sfdc in the experience cloud, my team didn't own the guest user stuff directly but it and other permissions-related issues were always ongoing problems we'd have to work around anyway, or try to find better solutions for given our limited ability to change things (long history from the Sitemasher acquisition and integration), or help various owning teams fix their own broken stuff (articles were always "fun" and special especially when it came to sitemaps). Even collaborated with dedicated security folks to put together better info on securing a community (now 'digital experience' or whatever). I've thought if I needed some cash I could perhaps join a firm like yours and contribute some value quickly knowing how the sausage is made, but to be honest I'd rather forget about it all...
b33j0r 4y ago
This is a direct consequence of integrations as a service. Analogy. I don’t like the apple app store being so choosy about what I can install, nor the play store telling me what to do. However. I haven’t gotten any malware from a third-party in my dang life. If you make a platform that doesn’t do anything without plugins, you can’t control what people do with it. Looking at you, Eclipse. SF is the second-worst offender I’ve worked with.
doubled112 4y ago
I've lumped Salesforce into a certain group of platforms everybody loves to hate on, like Jira and Wordpress, but they all have a similarity. In my brief exposure to it, I found that Salesforce's main strength is that it will let you do whatever you want. Its main weakness is also that it will let you do whatever you want.
- tmpz22 4y ago
  There are legitimate grievances across the vast array of features Salesforce offers but if you find yourself blaming your tools you might be a poor craftsperson - or at least your organization is. And thats a hard truth many won't face and fewer would openly acknowledge.
RadixDLT 4y ago
why cant these companies hire a real web developer instead of buying a cheap DIY service, they are only destroying their business by being greedy

206 points by impish9208 4y ago

This is a known issue. I was doing some bug bounty work on a target, found a salesforce domain leaking data. Reported it responsibly, and they basically told me to kick rocks. I have hear of similar issues from other security researchers.

paxys 4y ago

Salesforce is impossible to set up by design. The mistake here was that these small businesses and government agencies didn't contract with a Salesforce-preferred ISV charging $250+/hr per consultant to correctly configure it for them.

tomrod 4y ago
LOL. I wholeheartedly disagree where you place the blame. Broken-by-design means blame lies with Salesforce entirely. What _other_ major sources of data leaks should we expect from such past performance?
- aliasxneo 4y ago
  I think there's an inferred /s at the end of the comment you're responding to :)
  - tomrod 4y ago
    I reckon I am the obligatory whoosh of the day :) -- thanks for recontextualizing
  - the_duke 4y ago
    I don't think so. Considering my experience with Saleforce, I'm quite sure the comment is entirely earnest.
  - Paul-Craft 4y ago
    FYI, I think you mean "implied," rather than "inferred." Remember the difference this way: when someone implies something, that means you may infer that they want you to believe it.
- evilspammer 4y ago
  Cloudflare and AWS?
bombcar 4y ago
Those ISVs charging $250 an hour are the source of lots of the insecurity, because "that makes it work" finally.
mym1990 4y ago
Well its clearly not impossible since there is a whole industry of professionals doing it successfully for the past 2 decades. Salesforce is difficult to implement because it is extremely customizable and Salesforce is effectively completely hands off. It is not a small business product, and government contracts tend to be a race to the bottom for price, which results in poor quality of development.

layman51 4y ago

I still need to dig into the details, but does this exploit work primarily by changing stuff that appears in a URL?

npace12 4y ago
yeah for a public site thats exposed you just go to /003 and it would have a list of all the contacts lol
- bombcar 4y ago
  When they went to longer IDs they REALLY MISSED OUT on the ability to make them cryptographically secure. https://help.salesforce.com/s/articleView?id=000385008&type=1 https://help.salesforce.com/s/articleView?id=000385008&type=... There was no need to make those human readable; 64 character UUIDs would have been just fine; as it is they're sequential and so if you know yours you can guess some more.
  - npace12 4y ago
    yeah that would have helped, but the issue was really that either the default RBAC for contacts when using "salesforce sites" was either Public from what I remember or it was one of those things that required a lot more proper setup and people usually would "get back to it later" and never did. So now, you have all your contacts available for unauthorized users to read, and since they provide automatic "list" pages as /<first 3 chars of record> you automatically get a nice table interface for anyone to scrape.
  - cdcarter 4y ago
    FWIW, the 18-character "longer ID" is just a checksum of the first 15 characters. The ID storage format did not change when 18-char IDs were released. So, in some ways, that opportunity hasn't been missed yet ;)
chasd00 4y ago
yeah URL but you can also manipulate browser async requests. Salesforce portals and plain old Salesforce make a lot of async calls back to the server which is the style these days. You watch these in your browser dev tools and sort of deduce what's happening. Then you can play around and see if you can replay these requests but pointed at different objects or records and see what happens. It's not any different than what you can do with any other site. It's just that Salesforce is an incredibly wide and deep platform. You need to understand a lot about general web app security and then you need to know the Salesforce way of doing it across the whole platform to cover your bases. It's just a very complicated beast.

satrday 4y ago

> “My team is frustrated by the permissive nature of the platform,” Carbee said. As someone who implements Salesforce projects for companies like this, I place the blame solely on whoever setup that Vermont org. Salesforce's permissions are very, very powerful and flexible, which also makes them complex. Salesforce recommends and works best with a "least privilege" security model. It is frustrating to me how often I see colleagues (and some clients) push for a "wide open" permissions structure, where every internal user can see everything unless otherwise specified. It's just laziness towards doing it the right way. During a brand-new Salesforce implementation for a multi-thousand user company, the stakeholders pushed me hard for an open policy. "We trust our employees". Ugh.

bramblerose 4y ago
> It's just laziness towards doing it the right way. Just because "least privilege" is "the right way" from a (some?) technical perspective, doesn't mean that it's the right way from a business perspective. There is a real, and significant, business cost to needing to wait for access and not being able to discover data (and thus not even knowing that you need to ask for access).
- satrday 4y ago
  Definitely worth keeping in mind the business needs. I'm not going after "well designed security that meets the business needs". I'm calling out lazy security that cuts corners because doing it well takes time and effort. That being said, there is also a real, significant business cost to leaking sensitive information. If users are frequently waiting for access or unable to discover data, that's a failure in understanding the users needs and/or failing to test those needs in UAT during implementation. Convenience should never trump security, in this context.
  - martincmartin 4y ago
    I'm calling out lazy security that cuts corners because doing it well takes time and effort. Time and effort cost money. It's possible that the value gained is less than the cost, and so therefore isn't worth it. Of course, it's also possible they don't understand the value gained until there's a scandal.

webel0 4y ago

So many of these pages displayed tables that included a column for SSNs. Once they lock down the authorization permissions they ought to reconsider whether they really need to be displaying that data all over the place.

chasd00 4y ago
it's just bad config, it's a checkbox to censor fields like ssns on the UI. They need to check that box and click save.
- carlmr 4y ago
  What's right should be easy. SSNs should be censored by default and it should be really hard to disable that.
  - chasd00 4y ago
    Well how would salesforce, or any system, know you’re storing social security numbers? A custom field (a user created table column in SF jargon) is defined using a handful of data types. It’s up to the person doing the configuration to take the extra steps given what kind of dat is going in these fields.

testplzignore 4y ago

> 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. Does FOIA apply here? Can we find out who the third party was?

chasd00 4y ago

i do a lot of Salesforce stuff, all of these issues are on Experience Cloud ( the Salesforce portal portfolio ). No one ever looks closely at the "guest user" this is basically used for unauthenticated portal pages, even though there isn't a user per-se there's still a session and it maps back to a user and profile ( profile = what controls security for a group of users in Salesforce ). What happens is the guest user ends up with read access on an Object ( SF term for a table ) somehow but it's never surfaced on the portal as a page and therefore never tested/known by the testing/qa team. Then, as an end user curious enough, through some browser request manipulation or address bar manipulation you can access the records for that Object (table). Guest user problems go far deeper than what the article describes and over the years Salesforce has been slowly dialing down what the guest user can have access to. It's an intricate exercise to properly lock down that profile in Experience Cloud (the portal feature portfolio). Guest user aside, privilege escalation attacks are very easy to introduce when writing custom APEX and front-end code. APEX is Salesforce's backend language similar to Java but runs in a system context not entirely constrained by the security settings of the running user. It's very simple for a naive developer to introduce a privilege escalation attack when writing an APEX method that is called from the front-end javascript framework ( LWC or Aura ). This is especially the case when the underlying record access model (think row-level access control in PostGres) is left to defaults or even opened further and not properly locked down. At my firm we have an entire practice dedicated to Salesforce security and require security scans, reviews, and remediation performed by this practice for all implementation projects because of things like this.

Jach 4y ago
Yeah, it's a sad mess. I used to work at sfdc in the experience cloud, my team didn't own the guest user stuff directly but it and other permissions-related issues were always ongoing problems we'd have to work around anyway, or try to find better solutions for given our limited ability to change things (long history from the Sitemasher acquisition and integration), or help various owning teams fix their own broken stuff (articles were always "fun" and special especially when it came to sitemaps). Even collaborated with dedicated security folks to put together better info on securing a community (now 'digital experience' or whatever). I've thought if I needed some cash I could perhaps join a firm like yours and contribute some value quickly knowing how the sausage is made, but to be honest I'd rather forget about it all...

b33j0r 4y ago

This is a direct consequence of integrations as a service. Analogy. I don’t like the apple app store being so choosy about what I can install, nor the play store telling me what to do. However. I haven’t gotten any malware from a third-party in my dang life. If you make a platform that doesn’t do anything without plugins, you can’t control what people do with it. Looking at you, Eclipse. SF is the second-worst offender I’ve worked with.

doubled112 4y ago

I've lumped Salesforce into a certain group of platforms everybody loves to hate on, like Jira and Wordpress, but they all have a similarity. In my brief exposure to it, I found that Salesforce's main strength is that it will let you do whatever you want. Its main weakness is also that it will let you do whatever you want.

tmpz22 4y ago
There are legitimate grievances across the vast array of features Salesforce offers but if you find yourself blaming your tools you might be a poor craftsperson - or at least your organization is. And thats a hard truth many won't face and fewer would openly acknowledge.

RadixDLT 4y ago

why cant these companies hire a real web developer instead of buying a cheap DIY service, they are only destroying their business by being greedy