Good afternoon.
Welcome to the security bedroom.
Let me introduce Jan Lucas.
We talked about the invisible key.
Securing the new attack vector of OA.
O, O, O, O, O.
Tokens, O, O, O, O, O, O, O.
Okay.
So, not an easy task after lunch. So, I'll try to make this funny and louder. Okay, good,
sorry for that. Can you hear me? Good, perfect. So, good afternoon, everyone. Where am I very
quickly? I've been involved in cyber for the last 20 years. I've been doing both the blue
team and right team work for the past 20 years across multiple companies and also public
sector. Today, what I want you to discuss is that fundamentally, we need to shift a bit
the paradigm of hackers and how hackers are not even actually breaking in anymore, but just
log in. You might laugh at this, but there's actually nothing to laugh because fundamentally
today we will see how easy it's becoming to actually abuse and exploit some spots and
some areas of our industry and all the things we work on on a daily basis that I'm not
actually really having an oversight from security teams. Now, we just have 25 minutes. So, I'll
need to go fast on the on the basics, fundamentally, but if we want you to summarize a bit
what's of is, is that fundamentally, it's an authorization framework. And they asked you
actually to recall authorization in non-authentication because it will come and in the next
slides. Fundamentally, we use of for delegating actually the user authentication to third
parties. Everything started back in the days with signing with Google, signing with Facebook,
signing with whatever across the platform of the web services out there. And what we ended
up with was an interesting journey into UX and UI where fundamentally that architecture
we are all familiar with. I know in the room there are people that are very skeptical about
doing social, against and likes and they only do individual emails, individual password,
good job guys. But the rest of the word out there, the normal human and so out there,
as side of us, is actually using a lot of signing for people around me that I can become friend
with, am I gonna become reach? Can I sign into that? Can you give me the word for that? Can
you give me the solution for that? So there are a lot of stupid applications that we use to
sign in all around that. And the interesting things about here, if we look at all permissions
and roles, is that fundamentally, we have a resource owner, yourself, a third party applications,
is actually quite generic. We don't know what's behind that, third party application,
as we will see today. And then there's the most interesting things that is the scopes.
What permissions are we granting to those applications? Who, every time signing into something,
look at the scopes and lift them before accessing and granting those permission to tools? And
pretty cool. Who's gonna do that in the room? Okay, that's very good, but that's actually
a technical conference, I had some fair. Good, so, and what's relevant for today's talk is also
the flows that people and systems that we're talking here about user authentication and
machine authentication can perform in order to get access to all of us. A certain code flow
actually, please flow with single page applications. There is an interesting one about
resource owner, password flow that we will see today. And my preferred one is also client credentials
flow for machine to machine authentication. Now, each of these flows have flows. And they might be
exploited if we don't actually pay attention to them. Now, if you're curious about how can a
complement that layer of authentication that is missing with oath, you might have seen open
AD connect around, quite evident in the last years, actually quite a few years. And fundamentally,
it's complementary to support the development of that authentication layer that we're going to be working
on and also provides us with message flows based on a variety of protocols in there. Now,
why are those tokens interesting? Because with being teaching everybody to use strong passwords,
use MFA, whatever possible. And then we ended up using tokens that don't have a MFA,
don't have strong passwords in a way. And also, are pretty invisible or harder to spot
into logs. And you can actually not secure what you cannot see. Because fundamentally,
if you have a token in there, it's pretty generic as we said before. It's a pretty
opaque string that without introspection, without knowing where to look for tokens. It's pretty
hard to know where to come from. We've been teaching ourselves also to use a lot of traditional
tooling, whilst firewall and the likes to spot for just things. And also be looking at API calls.
But, again, in here, when we don't have the context, we don't know whether the API call is a
GTM or not. So, what about identity of the token? What about permission of the token? We just see
actually the string we don't know who belongs to. And most importantly, also, we have this
improvisation here. We have a variety of services, but just one issue, oftentimes, like your
SSL, opt-up, Google, and the likes, it is actually fundamentally consumed by a path for our
applications that are third parties. And as we said before in there, we've been teaching ourselves
lately to use conditional access. If you come from the zero-trust ward, the intro ward,
you've been actually applying a lot of conditional access policies, but the reality is that
you cannot apply conditional access in a very easy way to your tokens. And so, they don't actually
really apply cleanly to those tokens. And so, they bypass all the mitigation and context
definitions that you might put in your gotories. And, I'm sorry, shortens here, also, did you provide
actually API access? And again, in here, you might have this ability that is very different when
you do a user authentication through a UX, like a login form, compared to that API access. And
in that token, also, might be made in a way that you issue a token, as we will see today,
and you never actually refresh that token. And so, you can actually do a lot of styles of
pivoting here where you can try to jump in, actually move with that token without actually being seen.
Now, if we look at the start of the show that I love to say is on a side, you have a single
ticket for one movie that is actually the access token. Usually, it's a short leave token that needs
to be refreshed. And then you have a refreshed token in here that is actually the whole subscription
passed to the whole cinema. So, you have a ticket that actually is long-lived and never expires
into here. And the crucial point for attackers in here is that they're interested in their fresh
token specifically. Now, as we said in here, there are like five major concerns when we look into
the token topic that is, the longevity of the token, do we know how long it's going to last,
and did we forget or not to disable that token? Do we know who has what and for our long?
The scopes, I mean, we're all lazy as fuck. And so, we ended up broadening a bit, the list of
permissions we usually grant our applications. And it's really hard to do this privilege as an approach
to applications and privileges in general. To communicate, my preferred, get up, get lab,
beat bucket, and all the likes love to host your tokens. So, don't forget, when you push those
tokens to clean up them from being active, because we will see how token leakage is also still
one of the actors for our threat actors to abuse them. And then, fundamentally, it's really hard
to revoke those and do a proper of board. Of boarding a user doesn't mean actually this boarding
a token. And then, indeed, the supply chain risk. That token might have access to another third
party with supply chain attacks because of that third party having access to another third party.
And then, you have it like a domino aspect that might be very risky in there. The seamless things
clean up my inbox, type of applications that we've seen over the last 10 years, sign an email
take over. You actually allow this application to clean up your inbox in order to clean up your
inbox, then you need to have access to your inbox. And you know what it can happen.
Mass data excitation would have given token with the right permission over an inbox,
for instance, or over a drive, or SharePoint, and the likes, you can fundamentally actually do
a mass data excitation. And the third party in the years that a single token that we believe
was stupid, simple, and actually limited in terms of scope might be something that we use for
actually, uh, privileges creation and shadow admins. Now, tokens installing in a variety of ways.
I need to go a bit faster here because the device we're stuck in here and I want to show you something
around. But there are several ways how people still tokens. Uh, renting yourself, you're
granting yourself access to a given application. You might have seen all type of tickover, um,
fishing being one, of course, of the main vectoring here used to still tokens, um, source code
as we said, pushing tokens that can be abused and impersonated in here. Infoscedors became a big issue
over the last five to seven years as well, because if it's not fishing, it's malware and or infoscedors.
And fundamentally, yeah, having infoscedors actually do, they do have still tokens that they can take over.
Um, lucky to be for us, um, cookie binding and other binding technologies are coming from
browsers. So, uh, a token he should from a given device might be confined to the device that
got generated from. So, we're kind of mitigating that, uh, nowadays for windows, for mac and
for Linux over the last, over the next, actually, couple of months and years probably. And then
there are other type of attacks where if we have access to the identity provider, that's our golden
mind. We can of course forge additional tokens. And I mean, you can mean new tokens without actually being
spotted. Now, all types of attacks that we might have seen span towards the typical fishing email
where whatever something security alert is asking you to login, signing with that application.
And you can see on the right side, it all looks like legitimate. There's a github logo. There is a green
check. It should be legitimate. There are a lot of scopes in here. But that was the profile behind that.
So, that was the profile that as you might see in zero followers, one following was not really
github security in here. Another one that was pretty famous over the last couple of years was,
how do we take over as many browser extension like the Chrome Web Store and the likes,
let's send an update to all developers saying, you need to login. Now, you need to login to
something and you see a privacy policy extension application asking your access to the Google
account. Now, if you look at the UX UI, you have edit, update, or publish to the Web Store,
that meant fundamentally granting yourself access to the threat actor to your Chrome Web Store
and allowing them to push a malicious extension. So, when you see the news, a lot of malicious
extensions, browser extension, getting stolen and compromised in the likes, that's actually one of
the good vector in there. And that ends here over the last couple of weeks. We have seen a lot of
ramping up in terms of attacks from consent fix that was fundamentally yourself,
actually consenting access to a row application from a very silly if you asked me slow,
but as you can see here, fundamentally the threat actor was asking you the full URL
containing the token in it so that you just actually pass the token and leverage on that for further
authentication. Now, there are too many threat actors in here that we've seen very active.
You might have heard in the news, Salesforce, Salesforce, Salesforce, Trist. There were a lot of
companies out there about 700 companies plus over summer when everybody was at the beach. A lot of
companies out there were getting compromised and data from them was getting access threaded from Salesforce
specifically. And scattered spider and shiny hunters are actually two of the games that are
more interested into this type of attack vectors. Social engineering, stating actually third-party
tokens, and then as we said, actually moving into this company, asking for ransom and doing several
nasty things that potentially can be done when you have access to that type of assets. Now,
how did work? It all started actually with the social engineering. Social engineering and
fishing is still very active. Somebody was requesting user credentials. Somebody was asking you
to approve a given code. The third-party data loader was actually added, so the data loader was added
to that and the data export was fundamentally granted to your tenant from the Salesforce environment.
Now, why did it happen? Because if you look at this, many people do have a device flow
for that given application enabled as a old brand. Why is that? The device is actually something
used on boards, TVs, screens where you don't want to actually type in 60-wars, character, 60
characters passwords in your remote, so you just go for a silly pin and then you need to enable
the device flow. And once you have the device flow, actually the attacker flow is pretty similar.
You're granting yourself and that application and malicious applications without reading
the standing, what you're doing there. Now, let's look at it from the blue team word and from
the response word, what can you do to spot this? If you have some visibility in there and then we're
going to be talking about deception, you will see that we might have had the identity provided
logs, the API and application logs and a lot of the signals you could actually have inferred
for understanding that coming from a lot of token being rented and issued, refresh tokens being
actually accessed from malicious IPs, botnids or actually a non-APS and then a lot of API operations
API calls that you, if you might have actually an API gateway in front of them, you might have
spotted as such. SaveSloft was another one, a third-party component used by many companies
using Salesforce in there, that fundamentally worked the same way. The developer lost given token
on a GitHub repo. That was about April to May last year and that token was abused to must query
a lot of Salesforce accounts and Salesforce objects, not just accounts but tastes, user, opportunity,
tickets and everything you can think of. Those tickets were containing a lot of, that's another
problem for another talk, but a lot of secrets, AWS keys, snowflake tokens, VPN URLs and the likes.
And then from that given token, the threat actor was able to pivot across the extension for Gmail
that was fundamentally granting read and write access to inbox itself. Now, that was a problem.
Now, the problem with this application is that for something that fundamentally needs to read
and at some point needs to write, we end up with that simple list that you can see in a year of
permissions. So from something that had to be not very critical, not very risky, we ended up
granting, I mean, giving them the keys of the castle without really understanding what we were doing.
Now, that's fundamentally a security program in a slide and that's going to be a security
program for the next five years of anybody not having a lot of resources, but if you look at
all applications, try to audit them into your own environment, start centralizing logs,
the problem in here is that if you have logs all around, it's really odd not to ingest them
and analyze them without ingesting them in a single place and then try to build a lot of detection rules.
Now, the walks do where and the detecting here is pretty interesting because
I don't know if you have a familiar with canary tokens, but they're like,
very effective tokens that you can deploy anywhere in your environment.
A lot of EVRs, a lot of actually MDR services as well on the security space are starting to
deploy tokens because fundamentally those are going to be granting you all their capabilities when
threat actors, chorus people and everybody is going to be clicking on things like issuing an AWS
account or anything you can think of in here. Fake credit cards, you can just put them anywhere in your
environment because you know that threat actors will try to exploit those.
And then in here, of course, another pillar of that deception space, it's fundamentally to
look at those detection signals. You need to better understand how those
headers are eventually handled and whether you can use canary tokens, whether you can use, of course,
getting a better understanding and introspection on the lots of their self.
And on the stock side of the story, you need automation playbooks to understand what can
you do when a token gets exposed and compromised. Because a token, as we said, it's funny,
but a lot of SaaS, when you deactivate a user, don't kill sessions, don't deactivate tokens.
So, it's a spending a user in a given SaaS, like it could be Slack or anything,
doesn't actually validate end-token until the expiry date of the refresh token. So, when you see
every time you see like, close all the sessions, kill all the sessions and the likes, that's why
fundamentally isn't there. But of course, the reality of the problem, the core issue of the problem,
is stop actually granting over-privileged permissions to applications that shouldn't have them,
like mail, read, write, all. If you look into your intros and Google workspace, I'm sure you
will see applications with read and write access to your inbox that shouldn't be the case like that.
All the AI companion, all the help me writing that email, so I don't understand my customer.
This kind of things try to write them, try to better understand what kind of extension are you using
in there. And then, of course, there's a lot of things you can do about refresh tokens, try to refresh
them more often, and set rotation of those tokens, session lengths, whenever you can, on services.
Where are we going? Conditional access, like we said in here, it's pretty interesting because
if you're coming from Antrop, for instance, you have a token protection here, where you can,
for instance, forging tokens assigned to a given device. You might have seen a disclaimer in there.
It's not really stable for a bunch of operating systems. It's still being tested by it's very
promising in here, and those sub-rowser are adding that support on the browser side for that.
And finally, on the Microsoft Word, I'm doing a lot of examples on Antrop, because let's be honest,
it's quite a huge footprint out there. You can start actually using a linkable token identity,
where you can finally link token identity to applications and users, because fundamentally,
third party applications are pushing out signals that you can use in your ingestion and telemetry
and alerting for understanding who does what and from where. Now, we're quite out of time, so there
are a lot of things that are being implemented. I give you the slides, I give you that. I do
also find that he isn't here. There's a lot of standards being implemented from mostly
SSO providers, spending towards actually encrypting actually the token itself, encrypting the
session into here, doing a lot of logic around MTRS and the likes, shared signals, having applications,
for instance, and third party apps that communicate the charter, and fundamentally sending each other
signals, so that if a user is getting compromised like on Google, you might also want another
service to be completely informed. And I leave you with this, time is over, so revoking actually
access whenever and whenever rings, try to have a play look for that, try to be ready for
terminating sessions, investigating where those sessions are originated from, and what APIs were
cold and how they were abused, and then fundamentally tried to remedy them. I need to go.
So thanks a lot for your time.
Thank you again.