Good afternoon, welcome to the security bedroom.
Let me introduce Jan Lukabud, his talk about the invisible key securing the new attack
of OA, OA, OA, OA, OA, OA, OA, OA, OA, OA, OA, OA.
Ok, good.
So, not an easy task after lunch, so I'll try to make this funny and louder.
Ok, good, sorry for that.
Can you hear me?
Good.
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 writing 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 is 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 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 and none of the indication
because it will come and in the next slides, fundamentally we use of for delegating actually
the user's indication 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 logins and likes and they only do individual
emails, individual passwords, good job guys, but the rest of the word out there, the normal
human and so out there, side of us, is actually using a lot of sign mean 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'm fair, good, 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 kinds, a solution code flow actually
implicit flow with single page applications, there's 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
they 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 we've been 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
inspection, without knowing where to look for tokens, it's pretty hard to know where they come from.
We've been teaching ourselves also to use a lot of traditional tooling, was 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 G2M 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 visualization here. We have a variety of services, but just
one isher, oftentimes, like your SSL, opta, Google, and the likes, it is actually fundamentally
consumed by a plaster of 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
Award, the Entra Award, 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 gotters. And, I'm sorry, shorting 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 their API access. And, and 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
lecturally 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 pass 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 the refreshed 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 how long? The scopes?
For, 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. Token leakage might refer to GitHub, GitHub, GitHub,
GitHub, BitBocket, and all the likes love to host your tokens. So, don't forget when you push
those tokens to clean up them from, yeah, 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 have seen over the last 10
years signing email takeover. 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 here is 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,
fishing being one, of course, of the main vector in here used to steal tokens.
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, uh,
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 mine, we can of course,
forge additional tokens. And I mean, you can mean new tokens without actually being spotted.
Now, all type 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, a row application from a very silly, if you asked me, flow, but as it can
seem to your 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, Trust. 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 accepted 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, that's really 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 prove
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 grant. 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 we 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, botnets, 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 much. Since last was another one, a third-party component
used by many companies using Salesforce in there, that fundamentally worked the same way.
A developer lost a given token on a GitHub repo. That was about April to May last year.
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
the security program in this 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 hard 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 what's doing where
and the detecting here is pretty interesting because, um, I do not know if you have familiar with
canary tokens, but they're like very active tokens that you can deploy anywhere in your environment.
A lot of EDRs, 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 key invisibility
when, threat actors, chorus people, and everybody is going to be clicking on things like Ishing
and 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 that in here, of course, in other, uh, pillar of that deception space, it's fundamentally
to look at those detection signals. You need to better understand how, um, those
hadders are eventually handled and whether you can use canary tokens, whether you can use, of course,
getting a better understanding and introspection on the, 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 it's open, get exposed and compromised? Because the 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, suspending a user in a given SaaS, like it could be Slack or anything,
doesn't actually validate any token until the expiry date of the refresh token. So, when you see
every time you see like, close all the session, kill all the sessions and the likes, that's why
Fondimentary 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 in-try 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 an intra, 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
an intra because let's be honest, it's quite a huge footprint out there. You can start actually
using a linkable token identities, where you can finally link token identities to applications
and users, because fundamental 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 leave you the slides, I leave you to that. I leave you also something he isn't here.
There's a lot of standards being implemented from mostly SSO providers, spanning towards
actually encrypting actually the token itself, encrypting the session into here, doing a lot
of logic around MTS 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 other
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 called 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.