Mapping the SaaS Attack Surface

Wow, so many people want to know how to map SAS attack surface. So, uh please give a round of applause for our next speaker. Hi, MT who is a CTO and co-founder of N Security. Please uh if you have any questions, go to besidescf.org/q&A and leave your questions in Slido. We're going to answer them at the at the end of the session if we have some time. Awesome. Thank you. Well, thank you for joining me today for the session map uh mapping the SAS attack surface. My name is Hime Blasco. I'm a co-founder and CTO of a company called Nat Security. We help companies actually mapping your attack surface and helping you protect all your SAS applications and working

with your employees to to actually do that the proper way. Uh before that I was at a company called Alien Bowl. uh we got acquired by AT&T and I spent a few years there but most of my career it's been focused on thread detection and thread intelligence and some of the ideas that I'm going to present today are actually based on the work that I used to do to map you know uh adversary infrastructure and you know things like that and how you can apply that to map supply chains from uh you know any company that you want. So what is uh you know a lot of you are probably familiar with ASM or attack surface management right that's

uh you know the process of mapping any external facing asset from a company that can be IP IP addresses domain names subdomains you know applications etc and the main goal is understanding from an attacker's perspective what are some of the potential entry points that you have into a company now this traditionally has been very very focused on onre infrastructure and in cloud you know espec especially cloud uh applications but there hasn't been a lot of focus on SAS what happens you know in the world that we live today where you know hey some companies we work with 90% of their applications are actually SAS based so they are not really owned by them right so some of the techniques I'm

I'm going to share today and hopefully by the end of the talk you're going to have a lot of ideas and tools to actually uh you know map that attack surface for any given company. So let's start with the super simple ones and most of you are probably familiar with this right when when you acquire certain SAS tools they force you to validate your domain name uh sorry the the ownership of the domain so you know they ask you to uh you know do things like add um you know DNS uh records uh more simplistic you can use uh you know MX records and as as a reminder MX record just tells you how the email address for a certain domain

is routed and you can use that very in a very basic way to understand whether the company's using Google or Microsoft and in some cases understand whether they use any email security like you know proof point uh you know proof point mcast etc. In addition to that, you can expand that to sender the sender policy framework where you know that basically indicates who which services are allowed to send emails with that domain and you know the way you can you uh use that to to find things like marketing tools, development tools that usually need to send emails and you know you usually find things like hotspots, send etc. If you look at uh TXT records um in a

more you know a a broader way uh you can see some of those domain ownership verifications where you know at some example you know with OpenAI it will ask you to you know put a DNS TXT record in order to validate ownership. Obviously a lot of people don't remove those. So you can very easily use that information to understand some of the applications they are using. Some vendors do that a little bit better which is they will ask you to use a subdomain or a prefix like PCEL is an example but that's not great either because you can just build um um a list of you know specific vendors and prefixes in order to brute force that

and understand you know what applications are being used and then finally is an example of how you do this uh in a proper way which is send layer for instance generates a random you know string that you can use to validate your domain and any vendor should be using that because otherwise you are just telling the world what application you're using. Um more simple things you can do uh once you have discovered all the you know facing applications and internal applications you can just look at JavaScript imports and usually you're going to find things like develop development tools analytic tools some examples of those are like segment full story you know sentry you can also uh

traditionally find security tools as well or authentication like outer etc. Similarly, you can use content security policies to find find as many content security policies as you can in the you know exposed um you know externally you know domains and look for uh you know content security policies. As a reminder, obviously most of you know what a CSP is, but that indicates uh you know uh the web server indicates to the browser which resources can be loaded and from which sources. And the way to do this, the reason to do this is to avoid you know code injection attacks, you know, especially cross scripting. So what you're going to find is an overlap with some of those

JavaScript sources that you obviously need in CSP. But in addition to that, sometimes you're gonna find things like where the the website can be embedded and you're gonna find internet, you're gonna find uh you know things like Jira, things like sneak uh that need to be embedded in in the websites. So a lot of security tools as well. Uh let's move on to something a little bit more uh you know more interesting. uh let's say you know the next thing we want to do is like discover as many subdomains as we can and look at for look for CNAME records those are usually things uh you know records that you are going to use when

you configure subdomains for your company that point to a SAS provider and in this case you know there are some examples with you know safe base Salesforce skill jar etc but sometimes that's going to be things more internal like in this case like jamf that is a MDM tool uh you know you can see that was supposed to probably be uh to some extent some internal DNS but somehow it might have been leaked as well. Um so how you can do this? The first thing is doing just brute forcing and you can use tools like sapfinder from project discovery to do this. You can do passive DNS. Uh for you those of you that don't

know pass pass pass pass pass pass pass pass pass pass pass pass pass pass pass pass pass pass pass pass passive DNS. I mean if you do thread intelligence or you work work in a sock it's something that you do every day but basically it's a it's a database of historical DNS information uh that you know teams use to like map uh adversary infrastructure. But you can use that same database to actually find all the subdomains for a specific company. Uh there are different vendors like I built something like this in my previous life and alien OTX which is free and then there are other vendors like domain tools, silent push, security trails etc that you can use for that. Uh

the next one is certificate transparency logs. uh this is a log that they've created for uh you know anytime a new certificate SSL certificate is issued the CA will write a log of that uh certificate and if it's not a wildcard SSL certificate that contains subdomains you will actually find those subdomains for the company as well. So combining all of these you can basically find all the subdomains then uh try to resolve the CNAME and see if there are any uh say you know SAS providers that point there and you know one of the tools that we will will be releasing has a a large database of like those you know domains that that belong to certain SAS

providers that you can use. Okay then moving on to looking at specific SAS providers. In this case we are looking at a SAS provider called 8fold.ai. AI and you know this is pretty common. There's a lot of SAS providers that haven't been learned the lesson and basically create a unique tenant subdomain for each customer that they have and obviously that's not ideal because you are broadcasting to the to the world uh who are your customers and you know again using the techniques I described before either brute forcing passive DNS or certificate transparency locks you can basically have a list of uh SAS providers and list all all their customers. In addition to that, some vendors uh and some customers themselves

will use uh a specific prefix prefixes or suffixes. So you want to have in your brute force a word list a way to like you know doing generic uh prefixes and suffixes because sometimes you even find uh you know UAT or you know development uh tenants that actually you can exploit in different ways. Something else you can do is look at uh public source code repos. And you know you can do d do this directly with GitHub or you can use a tool like source graph that allows you to search in a more meaningful way. And you can again once you have a specific tenants that you are interested on you can search for those or you can you search for a

specific domain names that belong to SAS providers in order to find those tenants as well. And there's a lot of fun you can a lot of fun you can do find here and a lot of dams from things that shouldn't be in GitHub repos. But I'll invite you to test that with your company and see what you find. Uh something very interesting you can do as well is look at just uh Darw data in particular infos steeler dumps and even if those credentials are not valid uh you can still derive the fact that you can find the tenant information from from those uh dumps right so there are some companies like hats and rock constell intelligence spite cloud that

provide this service in this case I'm giving you an example for Nike where you know at some point I imagine they have some compromised credential credials for a service now uh tenant. Uh even if those as I said even if those credentials are not valid anymore you can still find those tenants which is what what we are trying to do today. Now let's talk about uh SSO and you know just as a super quick refresher you have in SSO you have two modes right? One is the service uh it um one is the identity provider initiated SSO where your employee is going to go to uh you know octa or enter ID or one login

whatever IDP you have is going to login into the IDP is going to select the application that they want to access uh and then the IDP is going to send the assertion uh to the uh to the uh service provider and the service provider is going to see it's going to say sure login or you know this user doesn't belong Here on the other hand you have the service provider initiated single sign on that is the opposite where the user goes to the service provider let's say asana.com uh it tries to login into the application uh the application redirects to the IDP um the user logs in in the IDP or just if it's logging just uh the

IDP sends the assertion to the service provider and if the user is valid the service provider says great you can authenticate so this is going to be very handy for cases where the SAS uh vendor is truly multi-tenant like they don't have subdomains uh for instance and it's just like one domain share across every customer but also even if you brute force uh subdomains in some cases you cannot be completely sure that domain bel that subdomain belongs to the customer someone else could have created that so let's see how we can use SSO for this um again like the examples I'm going to use today and don't want to pick on any company and maybe some of

you are here but this is just uh you know widespread across the industry I you know I'm not I'm not picking any enemies here it's just some examples so in this case let's say that we want to know if octa uh is an asana customer right uh you will say well how can we do this it's actually extremely simple you can go to asana.com you can introduce an arbitrary uh email address from octa like test octa.com and if they have configured SSO the Asana will say great I'm going to redirect you to your IDP and guess what octa's internal IDP is is octa.octa.com octa.com. So not very uh creative but you know you see how you

can exploit that right like basically anytime you configure SS. So as long as that redirect exist you can basically check for you know any uh company out there and see if for a particular uh such provider they're actually a customer. Uh another example that is even worse is like in this case uh there's an example with Palo Alto Prisma and for those of you that are soccer fans like you know this is an example with FIFA uh some of these providers will use uh I imagine they're trying to offiscate the fact that there's a Palo Alto domain gpcccloudservice.com but obviously it's it's pretty easy to guess uh but in this case you don't even need to put an email

address if you go to that URL it will automatically redirect you to the IDP and you see how that becomes a problem. I will uh this is going to be very important in a little bit when we see how we can do this at at scale. Uh also take uh into account that in octa the tenants is defined by the subdomain or the domain uh in this is an example where enter ID uh with Microsoft enter ID and the tenant ID there's that guju ID and that's going to be very important when we go after some of the techniques later. Uh another example of what not to do, uh Miro for example has a API you can call

and ask the question does you know Nike uh is is Nike your customer and they will just say great here I'll redirect you to your IDP which makes things even easier to automate because you don't have to even automate the browser you can just use an API. Um, cool. Now once you have found the IDP for a specific customer that you are trying to uh map their infrastructure now this becomes super easy to expand uh the number of applications that you can find because you can use tools like census shan uran to actually find uh search for the tenant ID in the case of enter ID or search for the you know octa.octa.com octa.com as an IDP uh as

the tenant and you will find tons of applications because of the techniques that we have shown right like some of those applications automatically redirect you to the tenant so you can find that and some of them your people just randomly submit URLs and redirect x and you can find that information on the internet so using this you can usually find you know dozens if not hundreds and sometimes of like applications that redirects to those IDPs so instead of having to broad brute force every SAS application out there. You have a very uh specific list of things that you know are redirecting to that IDP. Cool. Uh some uh some vendors probably know about this and and some you know

some IDPs kind of know about this. So for for instance I believe whis uses cognto and cognto tries to be like well if the user doesn't exist I'm not going to redirect you which actually makes things a little bit worse because now you can enumerate users that exist in the application right so you you need to you need to peel to pick your your your peel it's like do you want to let them know which user exist or automatically redirect them so you'll say well damn it now I can't know if whis is sorry if full story is using whis well uh the problem is like you know you can easily go to whis uh you know you customer

stories and be like wait a minute a full story actually uses whis so let's find the name of the person that I'm protecting because it's you know I mean again this could be me right it's not uh it's it's nothing bad but you can find the person that you know uh is doing the customer story you can use a tool like Apollo.io O, which is a tool that my sales team uses to know annoy the hell out of like everybody on the internet that basically allows you to search for any random name and it will give you the email address. Uh sometimes you can even find the their personal email addresses which is kind of funny. Uh but anyway,

you graph the email address from the person that you believe uh is a user of whis in this case and uh you put the email address instead of a random email address and sure enough is redirecting you to the IDP right? So you can see how you can automate this at scale. uh and my marketing team is going to hate me, but you know uh I truly don't recommend people to do customer uh stories because of this because it's really easy to find the fact that you're a customer specific technology and that's part of the of your attack surface, right? So again, this is something that you can uh automate very quickly. So why are we

talking about this? Why is this important? A lot of you probably responded to this uh snowflake bridge last year where you know attackers uh you know a thread actor found a lot of compromised credentials for a snowflake tenants uh on the dark web or bought access to them uh and then you know compromised a lot of those tenants because you know a lot a lot of those snowflake tenants didn't have MFA enforcement right in addition to that uh we are seeing so many uh thread actors targeting SAS uh applications and supply chains uh in it. You know, as an example, Lasseros group, which maybe some of you are dealing with, targeted targets mainly cryptocurrency companies, one of

the things they like doing is actually trying like hacking the SAS providers in their supply chain to actually access uh information about those companies. And then Mandant in their mand reports a couple of days ago, they just said that, you know, the engagements that they have had last year that include SAS and cloud are just like the norm. is not something that is um you know once in a while now. So other things why this is important and some of the scenarios you can exploit once you have all the supply chain is uh you know as long as you have access to one email address of of of an employee or you know uh a rock employee

could just like brute force all these u SAS applications and try to automatically log uh to those and the problem is a lot of these applications if they are not in SSO uh will allow anyone from the organization to access that application so uh it's very easy to do that then I recommend you check uh those two links one of the talks about a vulnerability in send where you could actually uh you know exploit the fact that senders will uh forward emails from you know the ticketing system to val verify any uh account in any s service and then you could exploit that for the same purpose that that we are seeing today and the second one talks about

this particular it's not a vulnerability it's a feature of Google where you can create uh uh any an a Google account with any domain and as long as you have access uh as an employee, you can create an alias that gets associated with a Google account and then if you leave the organization that account is still valid like your employee can remove access to that. So basically exploiting that you could access any SAS application that doesn't enforce SSO or you know a a guest invitation. Um you could also look at uh bridge passwords and brute force using those passwords uh to uh brute force shadow tenants. Uh so again like using the fact that you can find all those tenants and

try to use the same credentials or you can use targeted fishing campaigns. Now now that you see that now that you know all the SAS applications that the company uses you can very easily make it look like any of those services at scale and even for particular people that you know are using that application. We have seen this last year where attackers were using docuign uh to you know features to actually launch fishing campaigns. Um something else you can do is create a fake tenant as an attacker of an existing SAS application in a company. So let's say instead of Nvidia, you can call it Nvidia Corp and try to lure uh employees to access your tenant and

exploit certain things or you could create uh you know a completely new SAS application that they are not using with the corporate tenant uh naming that they have and try to trick employees. You can also exploit that SP initiated SSO to try to emulate that with employees and exploit that for fishing SSO providers because if you remember in those octa in those octa screenshots that I share you can actually uh by accessing the octa tenant you you can know whether they have fishing resistant MFA or not. So you can choose the victims that don't have fishing resistant MFA for fishing purposes. Uh so what are some of the things you can do to reduce the attack

surface? Uh as an organization, first thing is as as soon as you uh validate a domain, please delete all the DNS records. That's that's super easy to do. Please use random tenants. Don't be octa. Don't use octa.octa.com for everything. Like you can do something else that is not as obvious, right? And again, that's not ideal, but at least it's a little bit easier. I the the thing that works I seen some of the most sophisticated security organizations out there just register registering completely different domain names that have nothing to do with the company and use that for SSO and for production infrastructure that is critical. So that way you know instead of octa you can

call yourself like snake onion and no one knows that you are octa right. um monitor the gra the the graation of on any unmanaged tenant in in your organization uh and any unknown SAS application uh and uh you know that's something that that we do and keep a real time uh inventory of all those SAS applications are the on the supply chain the supply chain is really important for those you know examples that I get with Lazerus where if you are a specific uh ind in a specific industry they're going to go after your your supply chain and actually this uh these techniques is something we have used internally to map sub uh supply chains at scale for a few years now.

Um if you're an organization make sure that you implement SSO as broadly as possible. I know this is not always possible but try to do as as much as you can if the SAS provider supports it. Uh you know don't allow that SP initiated SSO and I know that's not the case even in 1% of them. So it's a problem. uh always if you have SSO the option again is better than OL and better than user and password and you know enforce SSO across every SAS provider as you can and if SSO is not uh is not supported at least try to enforce MFA as much as you can always disable the uh uh the invite

only uh sorry the the invitations like in some SAS applications users can just invite random users instead of like you know using um you know using uh something that that the organization provides and in many cases those SAS applications also allow any email address from the company to join the organization. So you always need to disable that for for this purpose. uh monitor uh corporate credentials uh obviously in the dark web monitor for password reuse because once you have uh employees you reusing passwords you are in trouble as we have seen uh and you know do this as part of your incident response plan where you have a plan for what happens when you know someone

compromised one of our SAS tenants or someone is trying to target one of those tenants. Uh and this is something really cool that Canary tokens added recently where you can have a SL IDP token as a canary. So basically you can use that uh SL token. So if anyone tries to log into your fake application, it will trigger the canary. So you can know that someone is trying to exploit some of these things. Um now if you're a SAS provider, avoid using subdomains for tenency please. This is not ideal for for anyone. uh if using some sub subdomains at least randomize the tenant like this is something for example duo and a snowflake do well to some extent where

it's a random you know tenant name is not like octa right uh if it's multi-tenant always enforce the tenant ID or some sort of validation for the SP initiated flow because otherwise that redirect is going to always tell me that that you're a customer evaluate the riskreward of using wild cars certificates because again as we have seen if you don't use a wild card one, you're broadcasting to the world every time you uh issue one of those SSL certificates and always offer other ways than just txt records to validate those domains. Uh again if using SP initiated do not redirect support IDP initiated SSO always give me the ability to have a policy that uh prevents creation of new

tenants from the same domain because usually you only want to have one domain or you want to be the one created those domains internally and then use that security by default settings. Some of the dark part patterns that we see is like not enforcing MFA by default. Uh not offering a setting to always enforce MF SSO or if you enable SSO not disabling other authentication methods that go off uh user and password. Uh you know prevent auto login and disable user invites. And then uh the most important one is do not charge for SSO please. We do hate everybody hates that. And you know, I have some of those stickers. If anyone wants those SSO tax uh stickers,

please find me later. And yeah, we are going to be releasing some of these tools. Uh so stay tuned in that URL. And I have a quick demo that hopefully I have three minutes to run. And so uh I'm going to run one of these tools that we created with nvidia.com. And you know we were able to find you know north of 100 different SAS applications with these techniques. So Nvidia uses uh uh Office 365 or Microsoft Office 365. With the tenant ID you can list all the domains associated with Nvidia and then you can use all the techniques that we described today like you know TXT records uh brute forcing uh using the SSO redirect to

find additional um additional applications etc. I can't see the screen so it's hard to describe but you get the point. Uh you know again we we are able to find usually hundreds of different SAS applications and tenants if you combine all these techniques that I have described before uh today and that's it. If anyone has any

[Applause] questions, okay, so one question is uh octa.octa.com does seem bad, but if the name is totally random, how do we teach users to recognize it as the correct link when they check the URL? I think the the trick is really enforcing that uh IDP initiated SSO where you have a list of applications in octa for example and you force them to go to octa first and login versus going to the app because you know and again it's not always supported but that's the um can you say more about the value of using s IDP can the value is really understanding whether an attacker is trying to map your infrastructure and you know reacting to that maybe you know

you can keep an eye on those IP the addresses that are mapping the infrastructure and trying to monitor if they're actually, you know, doing uh something else further like brute forcing or or gaining access. So, you can use those scanneries to actually further monitor for uh for that infrastructure. Uh and I think those are all the all the questions.