All right.
Hi, everyone.
Thanks for coming to my talk today.
We're going to be talking about Salesforce and the different security misconfigurations and vulnerabilities that can come up in a Salesforce environment.
Just a little bit about me.
My name is Jessa.
I'm a red teamer and penetration tester in a healthcare software company.
I've been in this role for three years.
Prior to that, I was in college.
I studied computer science.
But by the time my senior year came around, I kind of learned that I was better at breaking code than actually doing it.
So, I became a pen tester.
I'm a badge life enthusiast.
So, if you see me at DEF CON, I'll be having all the different electronic badges.
I really like doing that.
And in my free time, I'm a yoga instructor and runner.
And I'm also a dog parent.
I didn't want to not include a picture of my dog.
So, this is my dog, Atlas.
He's a three-year-old Cavapoo.
He's not a cybersecurity professional, but he is my best friend.
Also, this is my first time speaking at CypherCon.
So, I'm really happy to be here.
And if you like my talk today, feel free to give me a follow on LinkedIn.
So, the agenda and what we're going to be talking about today.
I'm going to go over a little bit of background of what Salesforce actually is and what makes it special compared to other CRM tools.
Specifically, the idea of point-and-click programming versus manual coding.
Salesforce is pretty big, but I'm going to focus on Flow Builder, Page Layouts, Widgets and Chatter, and Digital Experiences.
Then I'm going to kind of go into what are the specific security concerns.
Specifically, misconfigurations that cause different issues when you're dealing with a Salesforce test or environment.
Then I'm going to talk about different attacks.
Specifically, widgets that can reveal different insecurities.
Kind of similar to broken access control or insecure direct object references.
And then kind of a closing of different remediation detection and prevention techniques that you can use in your Salesforce environment or if you're doing a Salesforce penetration test.
And then going into a closing of a QA and future work.
Really, the big idea of this talk today is sometimes when something is easy, that creates risk in the security realm of things.
So kind of keep that in mind as we progress through this talk together.
Now, a little advisory.
I'm a pen tester.
I'm not a Salesforce engineer.
So a lot of the topics I'm going to be talking about today are things I've just found and discovered and tests I've done in the real world.
And this is not a sales pitch for Salesforce.
My main motivation here is to talk about the different application vulnerabilities I've seen in the past and not try to sell or promote anything.
So don't worry.
Another thing I'd like to say is Salesforce can be very, very complicated and it's a really hard thing to talk about in like a 30-minute talk.
So a lot of the features and ideas I'm going to be talking about today are very high level and a little bit beginner friendly.
But that said, again, I'm not a Salesforce engineer.
I'm a hacker.
I do not fully understand the ins and outs of Salesforce and every day I learn more about the project.
But I do know how to attack it.
So I hope you enjoy these different attack factors I talk about today.
Kind of before we dive in, who here works with Salesforce at their role, their company?
Cool.
A couple of you.
So I guess you'll know it's very complicated.
What do you think are the primary security concerns that come with Salesforce?
Would anyone have a good guess or no?
Yeah?
Yes?
Yeah, definitely.
So that kind of falls into like misconfigurations and how you configure an environment.
And that's kind of what I want to talk about.
So the thing about Salesforce is it's a leading CRM that companies use to store, organize, and manage their various customer data.
Companies usually have a lot of customer data, so Salesforce is basically a tool that lets them organize and do that.
It's very popular among customer care teams for its tools and features to automate regular tasks, optimize customer communications, and increase services.
This platform is very flexible and customizable, which makes it very preferred with different companies and across different industries.
The talk I'm going to... the features of Salesforce I'm going to talk about today are Flow Builder, which kind of modifies the different Salesforce objects, page layouts, which determine the visibility of what objects are seen on an environment or a page,
a chatter widget, which is a small, I guess, another feature that displays different customer information, and then Digital Experience Sites, which basically kind of renders this all together for a customer UI platform.
Kind of a TLDR, but companies tend to have a lot of data, so Salesforce just helps these support teams to manage this data.
So can anyone guess what, like, the main issues that can come up again?
I kind of asked this earlier, but...
All right.
So I think I said this before, but really just default configurations.
So what's kind of interesting here is when you start to test Salesforce applications, you don't really think of it as, like, the OWASP top 10.
It's more of these specific misconfigurations that you want to find throughout the environment that cause, like, data leakage or broken access control, and this is kind of what I'm going to talk about today.
So what are objects?
Objects in Salesforce often represent different business data, like customer contacts, site users, groups, case records, and files.
Within these objects, there's something called records, which is just the different information for each object.
So say you have a customer object, a record would be, like, a cell phone number or address or name.
And oftentimes, the permissions can be very lax by default, and you'll kind of see this before or see this later.
But you'll kind of want to start to think, what happens when you start to enable features in a Salesforce environment where things are very lax by default?
And you kind of want to keep this in your head, and this is really interesting, because oftentimes now, since Salesforce is kind of migrating to this point and click approach, these support teams don't really have to hire out, like, a Salesforce engineer or someone else to kind of develop the environment for them.
They can do it very easily themselves.
And if these support teams don't really have any security knowledge or security forward, this can create a lot of issues when they're starting to build and automate these processes, and you'll kind of see this a little bit later.
And our first feature that I want to talk about, which is Flow Builder, and this kind of emphasizes just how Salesforce is beginning to migrate to this point and click programming approach and not, like, manual coding.
But what you see here is Flow Builder, and this is basically something that allows these customer support teams to automate different processes.
So you can kind of think about it as, like, say if they want to create a process for a customer to, like, report an issue, they can use Flow Builder to do that fairly easily.
Kind of the red flag here is Flow Builder oftentimes manipulates a lot of Salesforce objects, and again, if you're having someone to go in and automate these processes who isn't security forward, you could create a lot of different, like, read and write permission issues.
And you can kind of see to the left here, this is what the back end looks like.
So if you're trying to create a process with Flow Builder, this is really simple, but this, again, just kind of shows that drag and drop programming.
And then to the right is what that would look like in the user interface.
And I don't know, something random that I've learned pretty recently that causes a lot of confusion is in the security space, we often think of roles as something that gives someone authentication or permission to view something, but in Salesforce, that's not what that is.
A role in Salesforce is basically, like, a business purpose, and it's not security-related at all.
So you could imagine the kind of confusion that comes up when people think about that.
But in Salesforce, those kind of permissions are managed by something called profiles, which determine the authentication permission for different objects and actions and so forth.
This is the second feature I want to talk about, which is page layout.
Page layout is something that determines the visibility for different objects or things that you want to see on a page.
And right here, you can kind of see, like, think about the different issues.
Like, if there's some misconfigurations, what kind of data can I see or not?
But basically, what these do is determine what record information users can see, edit, view, delete, or create.
And they're also object-specific and control what a user sees on a digital experience site, which we'll kind of talk about later.
But this is what it would look like in the environment that you're in.
So, if you're, like, a customer or whatever viewing a page.
And then this is kind of how you'll configure it.
And this will go into our first vulnerability that I want to talk about.
So, this is the backend, how you would configure that page layout page.
In Salesforce, there's two different, I guess, versions.
There's Salesforce Classic Publisher, which is kind of like the older UI version of Salesforce.
And then there's Lightning Experience Actions.
And when you go to configure these in your Salesforce environment, it's really interesting because, say, if you're someone who's only really wanting that Lightning Experience Actions, you toggle it and, I guess, build it up on the same page as Salesforce Classic.
So, if you see in this screenshot, the Salesforce Classic has a lot more, I guess, objects and things you can see compared to the Lightning Experience Actions.
So, if you're someone on a customer development team and you're only focusing on Lightning Experience Actions, you're not really thinking of what you could potentially be toggling in your Salesforce Classic because, in your head, you're like, oh, I'm not really using this.
So, we can kind of see the issues that causes in the next slide.
So, right here is just an example application I created that kind of shows what that Lightning UI would look like.
And you see it's very clean.
It makes a lot of sense.
But in a lot of the tests I've done, there's something you can do where you just input a value in the URL and it will actually break you into the Classic version.
So, that's what I'm doing here.
I just added that payload into the URL and now I'm in that Classic version.
What's something you see here?
It's in a red box that you didn't see in the modern version.
Yes, exactly.
So, in the Classic version, there's actually this recycle bin, which wasn't available in the modern version.
But now you have this whole other area that you can see and maybe try to potentially collect other data, which is really interesting.
Again, I feel like maybe like 75% of the Salesforce pen tests I do, this is always an issue.
Well, this is a very common finding for me.
So, keeping that in mind too.
Kind of the next feature I want to talk about is Chatter.
Chatter is a commonly used feature in Salesforce that allows users and their customers to connect, engage, collaborate across an organization in real time.
You can kind of think about it like Microsoft Teams or Slack.
People can just talk back and forth to one another.
A big note here is that Chatter is enabled by default for Salesforce customers.
And some common use cases for Chatter are posting status updates or questions, using feed to post industry relevant articles, or to send and receive files directly for easy access to edit and review.
Another interesting thing about Salesforce is it doesn't really check the file type when you upload something.
So, you can kind of upload whatever you want and put it in the environment.
There's really nothing to stop you, as I've seen.
So, again, in these tests that I've done, there's not really that, like, upload check that you would want to see.
But specifically, what I want to talk about here is the log a call, which is basically just a commonly used widget that comes with the Salesforce Chatter.
And it allows you to, like, track tasks or different records where you, like, communicated with someone.
And in this instance, I'm just a public guest user accessing the Salesforce environment.
And you'll see in the next slide what kind of issues can come up when things are misconfigured.
So, in this case, I'm just a public user going into that log a call feature, and I'm just typing in any random name.
And from that, since these contact objects are very... there's no permissions to hold them back from, like, public users, I can actually see all of them within a Salesforce environment.
Which is very problematic, because you don't really want your customer data being leaked to random people.
And that's kind of just an example of how bad things can happen if you're not configuring these objects properly or safely for other people to see.
Now, finally, the last feature I want to talk about today is digital experience sites.
Which can kind of be thought of as the thing that wraps everything together like a bow on top for your customers.
And basically what it is, it's a... it allows businesses to create cloud-based platforms that deliver and connect digital interactions to their customers.
So, kind of how you can think about this is you want your customers to see some of your Salesforce data.
And digital experience sites make that possible.
And once you enable this, you're basically saying, like, yeah, I'm okay with these customers seeing my data.
And it can be very, very problematic, as you're about to see.
Because setting up digital experience sites is easy and can be done purely through point and click measures.
So, you don't really have to code anything or know any programming or security knowledge.
You can just go in and click it.
Again, you'll kind of see how that happens in the next few slides.
But right here is just a digital experience site I created.
I'm accessing it through, like, a public or guest user.
But because of this account, these account objects are viewable to anyone.
I can actually go in and see, like, the different companies that are in my Salesforce environment.
Names, numbers, even addresses.
All because these objects aren't locked down properly.
And I just want to say, none of this data is actually real.
This was created in kind of a research test environment that I used to kind of show, like, this is what happens when an object isn't configured properly.
But obviously, this is pretty bad.
And again, I've seen this before in real world tests.
So, it does happen.
And now I'm going to kind of talk about how does that happen.
So, right here, you can kind of see in the top screenshot, I'm enabling guest users to access my digital experience site.
This just means that you're making your site public to the internet.
And then on the bottom screenshot, I'm giving that account, those account objects read access to guest users.
And then in the next slide here, I'm creating a share setting rule that allows these guests to view those objects.
I do want to say, Salesforce does make it a little bit complicated to do this.
So, good for them.
And again, I kind of just want to emphasize that this was a research environment.
So, I didn't really have, like, all the data or all the rules or whatever that I wanted.
But this is just kind of an example of how it can happen.
All right.
In the next slide, I kind of have a here.
So, Salesforce objects, they're given this character string that kind of can serve as an identifier.
I just want to say it looks random, but it's actually not.
I haven't really figured it out yet what, like, how Salesforce designs these character strings.
But if you are someone who knows, I would be very interested, because I feel like that could be a whole other talk.
And you'll see in the next few slides how knowing that, how it works would be very helpful for, like , enumeration kind of stuff.
But, yeah, in this case, when you access, like, a Salesforce object, it's usually at the end of the URL.
So, if it's something that looks like this, that's when you kind of know, like, oh, I'm working with an object here.
Because it kind of makes it pretty obvious.
Now we're going to kind of get into, like, the attack and how you can enumerate and attack these different objects.
So, right here, I'm just using something called Burp, which is a web proxy.
It's a very common pen testing tool for application security.
And right here, I'm just taking that get request to that object URL and throwing it into something called Intruder.
Intruder and Burp is basically just something that allows you to send a bunch of payloads to a request to see what you can find.
And that's kind of what I'm doing in the next slide here.
Another interesting thing about a lot of Salesforce applications is they don't implement something called rate limiting, which basically means you can send as many requests as you want and it's not going to block you out.
Which is really important if you want to do what I'm doing here, which is object enumeration.
So, in this case, you can kind of start to tell what objects are real or not.
Obviously, this isn't the best example, because I haven't figured out how to iterate over the objects in the best way yet.
But you can kind of see, like, objects that don't exist return that 2,294 number, but ones that have content have, like, a much longer length.
And when you're kind of scrolling through your results, you can start to see this.
And right here, I actually found a real object, and I was able to pull the contact object for Josh Ortiz and take all of that information.
And again, this is possible because that contact object was made permissible or viewable to all guest users.
Now, we're going into just some remediation, prevention, and detection techniques.
So, always try to lock down your objects in Salesforce, implementing the idea of least privilege, which is basically just giving an object as least amount of privilege as it really needs to function.
Making sure you inspect all user rules, including your guest users, with the knowledge that they can often be insecure by default.
Be very cautious about what you enable, kind of what I said before, that digital experience site.
Once you enable it, it is making your Salesforce data public.
And it can even make it public to the internet.
So, be very aware of what you're doing.
Knowing that Salesforce apps can sometimes override one another.
So, when you saw that Salesforce classic versus publisher, that was kind of what was going on there.
Detection-wise, honestly, it's pretty hard to find misconfigurations in Salesforce.
In a free way.
I haven't really found any tools or resources that can say, like, scan your environment and find all the misconfigurations for you.
But that's why it's important to know, like, you do need to test your Salesforce apps.
I feel like there can be this kind of misconception where people believe, like, oh, I built this app with Salesforce.
It's a very commonly used tool.
There's not going to be any insecurities or vulnerabilities.
That is not true.
And that's why it's very important to be working with these different customer support or marketing teams so that they know that.
And that you can test their apps and find any potential issues.
Also, just be sure to inspect the different test widgets or elements because they can leak data in ways that you may not think about.
And then kind of just remediation.
Not much for now, unfortunately.
But just making sure that you're testing your apps and, again, just locking down those objects and making sure your user roles are appropriate for what you're trying to do.
And then kind of just future work in QA.
I know a lot of these vulnerabilities seem very, very obvious.
But they still do happen.
And I still see them in a lot of the tests I do today.
So I kind of see this as a cautionary tale that even though this seems like common sense, it still happens.
But for my future work and kind of what I want to do going forward, because I'm still fairly new to this space, is kind of think about what kind of default configurations can show up in flows so that, like, automating feature to automate processes.
So digital experience site shenanigans, what I would really love to do is find a way to scan, like , the public internet and see what digital experience sites are or were accidentally made public to see what kind of data I can take.
And then also asking myself, can we automate finding these security misconfigurations?
Because as of now, I haven't really found anything that can do that for you.
So kind of with that being said, I know a lot of these findings seem straightforward, but this is a cautionary tale, because I do still find a lot of these vulnerabilities in the wild.
So with that being said, I'll be happy to take any questions.
Thank you.
Yes?
Yeah, good question.
So in this case, I needed to add that because it was a research environment.
But in tests I've done before, I'll have, like, different user accounts that were made within Salesforce, and then there's, like, those misconfigurations that make them viewable or seen.
Yes?
Not yet.
I don't know how much detail I can go into that.
I'm just saying not yet.
Any other?
Yeah.
Sorry, can you repeat that?
Yeah, in this case, I'm trying to think of how to answer that question in a confidential way.
There's been some where they just give me the app, like the digital experience apps, for example, they just kind of give it to me.
They don't do any source code analysis.
But for others, where there might be a little bit more of manual code, there could be, but maybe not as thoroughly.
Like, they're not looking at the code.
They might be using something, like, another, like, tool or so.
But yeah.
Yes, in the back?
No, I haven't.
But I would be very interested to see how that works.
Any other questions?
Yes?
Yeah.
Kind of going, I guess, going back to mine that I created.
Probably in, I would say, if you start to, like, click around at the different accounts or objects, you can kind of see in that, like, URL, that, like, character string that I kind of showed you.
Let me get to it.
Yeah.
If you kind of start to click around and see, like, that, I would say that's a really good sign that you're working with a Salesforce app.
It's blocked out here.
But sometimes in the domain, it will say Salesforce, which is very obvious.
But I would say those are two very big, I guess, very big things.
Something I would suggest, if you want to try to get into all of this stuff, you can actually create a free Salesforce developer account, and you can kind of poke around and make your own digital experience site and kind of see what can happen or how it looks like and how it kind of functions,
too, if that's something you're interested in.
Anything else?
Cool.
Well, thank you.
Thanks for listening.
Have a good one.