WEBVTT 00:00.000 --> 00:06.000 Good afternoon. 00:06.000 --> 00:09.000 Welcome to the security bedroom. 00:09.000 --> 00:12.000 Let me introduce Jan Lucas. 00:12.000 --> 00:15.000 We talked about the invisible key. 00:15.000 --> 00:18.000 Securing the new attack vector of OA. 00:18.000 --> 00:21.000 O, O, O, O, O. 00:21.000 --> 00:25.000 Tokens, O, O, O, O, O, O, O. 00:25.000 --> 00:26.000 Okay. 00:26.000 --> 00:38.440 So, not an easy task after lunch. So, I'll try to make this funny and louder. Okay, good, 00:38.440 --> 00:44.480 sorry for that. Can you hear me? Good, perfect. So, good afternoon, everyone. Where am I very 00:44.480 --> 00:50.920 quickly? I've been involved in cyber for the last 20 years. I've been doing both the blue 00:50.920 --> 00:57.000 team and right team work for the past 20 years across multiple companies and also public 00:57.000 --> 01:02.880 sector. Today, what I want you to discuss is that fundamentally, we need to shift a bit 01:02.880 --> 01:10.440 the paradigm of hackers and how hackers are not even actually breaking in anymore, but just 01:10.440 --> 01:15.960 log in. You might laugh at this, but there's actually nothing to laugh because fundamentally 01:15.960 --> 01:24.480 today we will see how easy it's becoming to actually abuse and exploit some spots and 01:24.480 --> 01:29.760 some areas of our industry and all the things we work on on a daily basis that I'm not 01:29.760 --> 01:36.320 actually really having an oversight from security teams. Now, we just have 25 minutes. So, I'll 01:36.320 --> 01:43.200 need to go fast on the on the basics, fundamentally, but if we want you to summarize a bit 01:43.200 --> 01:48.160 what's of is, is that fundamentally, it's an authorization framework. And they asked you 01:48.160 --> 01:53.040 actually to recall authorization in non-authentication because it will come and in the next 01:53.040 --> 01:59.520 slides. Fundamentally, we use of for delegating actually the user authentication to third 01:59.520 --> 02:05.960 parties. Everything started back in the days with signing with Google, signing with Facebook, 02:05.960 --> 02:12.160 signing with whatever across the platform of the web services out there. And what we ended 02:12.240 --> 02:18.480 up with was an interesting journey into UX and UI where fundamentally that architecture 02:18.480 --> 02:23.600 we are all familiar with. I know in the room there are people that are very skeptical about 02:23.600 --> 02:27.840 doing social, against and likes and they only do individual emails, individual password, 02:27.840 --> 02:34.080 good job guys. But the rest of the word out there, the normal human and so out there, 02:34.080 --> 02:41.280 as side of us, is actually using a lot of signing for people around me that I can become friend 02:41.360 --> 02:48.720 with, am I gonna become reach? Can I sign into that? Can you give me the word for that? Can 02:48.720 --> 02:52.400 you give me the solution for that? So there are a lot of stupid applications that we use to 02:52.400 --> 02:58.160 sign in all around that. And the interesting things about here, if we look at all permissions 02:58.160 --> 03:03.840 and roles, is that fundamentally, we have a resource owner, yourself, a third party applications, 03:03.920 --> 03:10.240 is actually quite generic. We don't know what's behind that, third party application, 03:10.240 --> 03:15.520 as we will see today. And then there's the most interesting things that is the scopes. 03:15.520 --> 03:22.160 What permissions are we granting to those applications? Who, every time signing into something, 03:22.160 --> 03:27.040 look at the scopes and lift them before accessing and granting those permission to tools? And 03:27.040 --> 03:32.480 pretty cool. Who's gonna do that in the room? Okay, that's very good, but that's actually 03:32.480 --> 03:39.920 a technical conference, I had some fair. Good, so, and what's relevant for today's talk is also 03:39.920 --> 03:46.160 the flows that people and systems that we're talking here about user authentication and 03:46.160 --> 03:53.040 machine authentication can perform in order to get access to all of us. A certain code flow 03:53.040 --> 03:58.560 actually, please flow with single page applications. There is an interesting one about 03:58.560 --> 04:03.920 resource owner, password flow that we will see today. And my preferred one is also client credentials 04:03.920 --> 04:11.520 flow for machine to machine authentication. Now, each of these flows have flows. And they might be 04:11.520 --> 04:18.480 exploited if we don't actually pay attention to them. Now, if you're curious about how can a 04:18.480 --> 04:25.520 complement that layer of authentication that is missing with oath, you might have seen open 04:25.520 --> 04:30.800 AD connect around, quite evident in the last years, actually quite a few years. And fundamentally, 04:30.800 --> 04:36.800 it's complementary to support the development of that authentication layer that we're going to be working 04:36.800 --> 04:43.360 on and also provides us with message flows based on a variety of protocols in there. Now, 04:44.320 --> 04:52.320 why are those tokens interesting? Because with being teaching everybody to use strong passwords, 04:52.320 --> 04:58.400 use MFA, whatever possible. And then we ended up using tokens that don't have a MFA, 04:58.400 --> 05:05.600 don't have strong passwords in a way. And also, are pretty invisible or harder to spot 05:05.600 --> 05:11.680 into logs. And you can actually not secure what you cannot see. Because fundamentally, 05:13.120 --> 05:18.800 if you have a token in there, it's pretty generic as we said before. It's a pretty 05:18.800 --> 05:24.240 opaque string that without introspection, without knowing where to look for tokens. It's pretty 05:24.240 --> 05:30.400 hard to know where to come from. We've been teaching ourselves also to use a lot of traditional 05:30.400 --> 05:37.360 tooling, whilst firewall and the likes to spot for just things. And also be looking at API calls. 05:37.360 --> 05:43.520 But, again, in here, when we don't have the context, we don't know whether the API call is a 05:43.520 --> 05:49.120 GTM or not. So, what about identity of the token? What about permission of the token? We just see 05:49.120 --> 05:54.400 actually the string we don't know who belongs to. And most importantly, also, we have this 05:54.400 --> 06:00.160 improvisation here. We have a variety of services, but just one issue, oftentimes, like your 06:00.160 --> 06:07.040 SSL, opt-up, Google, and the likes, it is actually fundamentally consumed by a path for our 06:07.040 --> 06:13.040 applications that are third parties. And as we said before in there, we've been teaching ourselves 06:13.040 --> 06:18.960 lately to use conditional access. If you come from the zero-trust ward, the intro ward, 06:18.960 --> 06:23.280 you've been actually applying a lot of conditional access policies, but the reality is that 06:24.000 --> 06:29.920 you cannot apply conditional access in a very easy way to your tokens. And so, they don't actually 06:29.920 --> 06:35.120 really apply cleanly to those tokens. And so, they bypass all the mitigation and context 06:35.120 --> 06:41.520 definitions that you might put in your gotories. And, I'm sorry, shortens here, also, did you provide 06:41.520 --> 06:47.200 actually API access? And again, in here, you might have this ability that is very different when 06:47.200 --> 06:54.240 you do a user authentication through a UX, like a login form, compared to that API access. And 06:55.200 --> 07:01.840 in that token, also, might be made in a way that you issue a token, as we will see today, 07:01.840 --> 07:06.800 and you never actually refresh that token. And so, you can actually do a lot of styles of 07:06.800 --> 07:14.400 pivoting here where you can try to jump in, actually move with that token without actually being seen. 07:15.920 --> 07:21.360 Now, if we look at the start of the show that I love to say is on a side, you have a single 07:21.360 --> 07:27.600 ticket for one movie that is actually the access token. Usually, it's a short leave token that needs 07:27.600 --> 07:32.800 to be refreshed. And then you have a refreshed token in here that is actually the whole subscription 07:32.880 --> 07:39.760 passed to the whole cinema. So, you have a ticket that actually is long-lived and never expires 07:39.760 --> 07:44.960 into here. And the crucial point for attackers in here is that they're interested in their fresh 07:44.960 --> 07:53.520 token specifically. Now, as we said in here, there are like five major concerns when we look into 07:53.520 --> 07:58.640 the token topic that is, the longevity of the token, do we know how long it's going to last, 07:58.720 --> 08:04.720 and did we forget or not to disable that token? Do we know who has what and for our long? 08:05.120 --> 08:12.720 The scopes, I mean, we're all lazy as fuck. And so, we ended up broadening a bit, the list of 08:12.720 --> 08:18.400 permissions we usually grant our applications. And it's really hard to do this privilege as an approach 08:18.400 --> 08:25.520 to applications and privileges in general. To communicate, my preferred, get up, get lab, 08:25.520 --> 08:30.400 beat bucket, and all the likes love to host your tokens. So, don't forget, when you push those 08:30.400 --> 08:38.080 tokens to clean up them from being active, because we will see how token leakage is also still 08:38.080 --> 08:43.360 one of the actors for our threat actors to abuse them. And then, fundamentally, it's really hard 08:43.360 --> 08:48.800 to revoke those and do a proper of board. Of boarding a user doesn't mean actually this boarding 08:48.800 --> 08:54.240 a token. And then, indeed, the supply chain risk. That token might have access to another third 08:54.240 --> 09:00.480 party with supply chain attacks because of that third party having access to another third party. 09:00.480 --> 09:06.480 And then, you have it like a domino aspect that might be very risky in there. The seamless things 09:07.200 --> 09:12.400 clean up my inbox, type of applications that we've seen over the last 10 years, sign an email 09:12.400 --> 09:17.120 take over. You actually allow this application to clean up your inbox in order to clean up your 09:17.120 --> 09:20.080 inbox, then you need to have access to your inbox. And you know what it can happen. 09:21.040 --> 09:25.520 Mass data excitation would have given token with the right permission over an inbox, 09:25.520 --> 09:30.960 for instance, or over a drive, or SharePoint, and the likes, you can fundamentally actually do 09:30.960 --> 09:36.640 a mass data excitation. And the third party in the years that a single token that we believe 09:36.640 --> 09:44.080 was stupid, simple, and actually limited in terms of scope might be something that we use for 09:44.080 --> 09:50.160 actually, uh, privileges creation and shadow admins. Now, tokens installing in a variety of ways. 09:50.160 --> 09:54.160 I need to go a bit faster here because the device we're stuck in here and I want to show you something 09:54.160 --> 10:00.640 around. But there are several ways how people still tokens. Uh, renting yourself, you're 10:00.640 --> 10:06.320 granting yourself access to a given application. You might have seen all type of tickover, um, 10:06.320 --> 10:13.520 fishing being one, of course, of the main vectoring here used to still tokens, um, source code 10:13.520 --> 10:20.560 as we said, pushing tokens that can be abused and impersonated in here. Infoscedors became a big issue 10:20.560 --> 10:27.200 over the last five to seven years as well, because if it's not fishing, it's malware and or infoscedors. 10:27.200 --> 10:32.880 And fundamentally, yeah, having infoscedors actually do, they do have still tokens that they can take over. 10:34.080 --> 10:39.440 Um, lucky to be for us, um, cookie binding and other binding technologies are coming from 10:39.440 --> 10:45.680 browsers. So, uh, a token he should from a given device might be confined to the device that 10:45.680 --> 10:51.440 got generated from. So, we're kind of mitigating that, uh, nowadays for windows, for mac and 10:51.440 --> 10:56.480 for Linux over the last, over the next, actually, couple of months and years probably. And then 10:56.480 --> 11:01.840 there are other type of attacks where if we have access to the identity provider, that's our golden 11:01.840 --> 11:08.560 mind. We can of course forge additional tokens. And I mean, you can mean new tokens without actually being 11:09.040 --> 11:15.200 spotted. Now, all types of attacks that we might have seen span towards the typical fishing email 11:15.200 --> 11:21.760 where whatever something security alert is asking you to login, signing with that application. 11:21.760 --> 11:27.200 And you can see on the right side, it all looks like legitimate. There's a github logo. There is a green 11:27.200 --> 11:33.920 check. It should be legitimate. There are a lot of scopes in here. But that was the profile behind that. 11:34.000 --> 11:38.480 So, that was the profile that as you might see in zero followers, one following was not really 11:38.480 --> 11:44.960 github security in here. Another one that was pretty famous over the last couple of years was, 11:44.960 --> 11:49.920 how do we take over as many browser extension like the Chrome Web Store and the likes, 11:49.920 --> 11:56.400 let's send an update to all developers saying, you need to login. Now, you need to login to 11:56.400 --> 12:01.840 something and you see a privacy policy extension application asking your access to the Google 12:01.840 --> 12:08.240 account. Now, if you look at the UX UI, you have edit, update, or publish to the Web Store, 12:08.240 --> 12:13.520 that meant fundamentally granting yourself access to the threat actor to your Chrome Web Store 12:13.520 --> 12:18.560 and allowing them to push a malicious extension. So, when you see the news, a lot of malicious 12:18.560 --> 12:23.760 extensions, browser extension, getting stolen and compromised in the likes, that's actually one of 12:23.760 --> 12:29.360 the good vector in there. And that ends here over the last couple of weeks. We have seen a lot of 12:29.440 --> 12:34.560 ramping up in terms of attacks from consent fix that was fundamentally yourself, 12:34.560 --> 12:43.360 actually consenting access to a row application from a very silly if you asked me slow, 12:43.360 --> 12:48.080 but as you can see here, fundamentally the threat actor was asking you the full URL 12:48.080 --> 12:53.280 containing the token in it so that you just actually pass the token and leverage on that for further 12:53.280 --> 12:59.360 authentication. Now, there are too many threat actors in here that we've seen very active. 12:59.360 --> 13:04.640 You might have heard in the news, Salesforce, Salesforce, Salesforce, Trist. There were a lot of 13:04.640 --> 13:11.600 companies out there about 700 companies plus over summer when everybody was at the beach. A lot of 13:11.600 --> 13:17.840 companies out there were getting compromised and data from them was getting access threaded from Salesforce 13:17.920 --> 13:24.080 specifically. And scattered spider and shiny hunters are actually two of the games that are 13:24.080 --> 13:31.200 more interested into this type of attack vectors. Social engineering, stating actually third-party 13:31.200 --> 13:39.440 tokens, and then as we said, actually moving into this company, asking for ransom and doing several 13:39.440 --> 13:45.280 nasty things that potentially can be done when you have access to that type of assets. Now, 13:45.360 --> 13:49.440 how did work? It all started actually with the social engineering. Social engineering and 13:49.440 --> 13:55.200 fishing is still very active. Somebody was requesting user credentials. Somebody was asking you 13:55.200 --> 14:03.120 to approve a given code. The third-party data loader was actually added, so the data loader was added 14:03.120 --> 14:09.920 to that and the data export was fundamentally granted to your tenant from the Salesforce environment. 14:10.880 --> 14:17.280 Now, why did it happen? Because if you look at this, many people do have a device flow 14:17.280 --> 14:25.440 for that given application enabled as a old brand. Why is that? The device is actually something 14:25.440 --> 14:32.880 used on boards, TVs, screens where you don't want to actually type in 60-wars, character, 60 14:32.880 --> 14:40.400 characters passwords in your remote, so you just go for a silly pin and then you need to enable 14:40.400 --> 14:46.320 the device flow. And once you have the device flow, actually the attacker flow is pretty similar. 14:46.320 --> 14:50.960 You're granting yourself and that application and malicious applications without reading 14:50.960 --> 14:56.400 the standing, what you're doing there. Now, let's look at it from the blue team word and from 14:56.400 --> 15:02.160 the response word, what can you do to spot this? If you have some visibility in there and then we're 15:02.240 --> 15:06.800 going to be talking about deception, you will see that we might have had the identity provided 15:06.800 --> 15:12.880 logs, the API and application logs and a lot of the signals you could actually have inferred 15:12.880 --> 15:20.160 for understanding that coming from a lot of token being rented and issued, refresh tokens being 15:20.160 --> 15:28.240 actually accessed from malicious IPs, botnids or actually a non-APS and then a lot of API operations 15:28.240 --> 15:33.440 API calls that you, if you might have actually an API gateway in front of them, you might have 15:33.440 --> 15:40.880 spotted as such. SaveSloft was another one, a third-party component used by many companies 15:40.880 --> 15:48.000 using Salesforce in there, that fundamentally worked the same way. The developer lost given token 15:48.000 --> 15:56.800 on a GitHub repo. That was about April to May last year and that token was abused to must query 15:56.800 --> 16:03.120 a lot of Salesforce accounts and Salesforce objects, not just accounts but tastes, user, opportunity, 16:03.120 --> 16:09.520 tickets and everything you can think of. Those tickets were containing a lot of, that's another 16:09.520 --> 16:16.480 problem for another talk, but a lot of secrets, AWS keys, snowflake tokens, VPN URLs and the likes. 16:16.480 --> 16:22.960 And then from that given token, the threat actor was able to pivot across the extension for Gmail 16:22.960 --> 16:31.440 that was fundamentally granting read and write access to inbox itself. Now, that was a problem. 16:31.440 --> 16:37.840 Now, the problem with this application is that for something that fundamentally needs to read 16:38.560 --> 16:44.400 and at some point needs to write, we end up with that simple list that you can see in a year of 16:44.400 --> 16:51.280 permissions. So from something that had to be not very critical, not very risky, we ended up 16:51.280 --> 16:57.360 granting, I mean, giving them the keys of the castle without really understanding what we were doing. 16:57.920 --> 17:03.840 Now, that's fundamentally a security program in a slide and that's going to be a security 17:03.840 --> 17:11.280 program for the next five years of anybody not having a lot of resources, but if you look at 17:11.280 --> 17:18.480 all applications, try to audit them into your own environment, start centralizing logs, 17:18.480 --> 17:23.920 the problem in here is that if you have logs all around, it's really odd not to ingest them 17:23.920 --> 17:28.880 and analyze them without ingesting them in a single place and then try to build a lot of detection rules. 17:29.680 --> 17:34.720 Now, the walks do where and the detecting here is pretty interesting because 17:37.600 --> 17:40.800 I don't know if you have a familiar with canary tokens, but they're like, 17:40.800 --> 17:44.960 very effective tokens that you can deploy anywhere in your environment. 17:45.040 --> 17:50.480 A lot of EVRs, a lot of actually MDR services as well on the security space are starting to 17:50.480 --> 17:55.920 deploy tokens because fundamentally those are going to be granting you all their capabilities when 17:55.920 --> 18:02.640 threat actors, chorus people and everybody is going to be clicking on things like issuing an AWS 18:02.640 --> 18:08.720 account or anything you can think of in here. Fake credit cards, you can just put them anywhere in your 18:08.720 --> 18:12.400 environment because you know that threat actors will try to exploit those. 18:13.840 --> 18:20.080 And then in here, of course, another pillar of that deception space, it's fundamentally to 18:20.080 --> 18:25.920 look at those detection signals. You need to better understand how those 18:27.440 --> 18:33.840 headers are eventually handled and whether you can use canary tokens, whether you can use, of course, 18:34.000 --> 18:39.280 getting a better understanding and introspection on the lots of their self. 18:39.920 --> 18:44.240 And on the stock side of the story, you need automation playbooks to understand what can 18:44.240 --> 18:49.120 you do when a token gets exposed and compromised. Because a token, as we said, it's funny, 18:49.120 --> 18:54.480 but a lot of SaaS, when you deactivate a user, don't kill sessions, don't deactivate tokens. 18:54.480 --> 18:58.880 So, it's a spending a user in a given SaaS, like it could be Slack or anything, 18:58.960 --> 19:04.960 doesn't actually validate end-token until the expiry date of the refresh token. So, when you see 19:04.960 --> 19:10.160 every time you see like, close all the sessions, kill all the sessions and the likes, that's why 19:10.160 --> 19:17.040 fundamentally isn't there. But of course, the reality of the problem, the core issue of the problem, 19:17.040 --> 19:25.440 is stop actually granting over-privileged permissions to applications that shouldn't have them, 19:25.440 --> 19:30.080 like mail, read, write, all. If you look into your intros and Google workspace, I'm sure you 19:30.080 --> 19:35.760 will see applications with read and write access to your inbox that shouldn't be the case like that. 19:35.760 --> 19:41.840 All the AI companion, all the help me writing that email, so I don't understand my customer. 19:41.840 --> 19:46.560 This kind of things try to write them, try to better understand what kind of extension are you using 19:46.560 --> 19:51.520 in there. And then, of course, there's a lot of things you can do about refresh tokens, try to refresh 19:51.680 --> 19:58.240 them more often, and set rotation of those tokens, session lengths, whenever you can, on services. 19:59.680 --> 20:04.880 Where are we going? Conditional access, like we said in here, it's pretty interesting because 20:04.880 --> 20:10.400 if you're coming from Antrop, for instance, you have a token protection here, where you can, 20:10.400 --> 20:16.400 for instance, forging tokens assigned to a given device. You might have seen a disclaimer in there. 20:16.400 --> 20:21.600 It's not really stable for a bunch of operating systems. It's still being tested by it's very 20:21.600 --> 20:26.880 promising in here, and those sub-rowser are adding that support on the browser side for that. 20:28.320 --> 20:34.400 And finally, on the Microsoft Word, I'm doing a lot of examples on Antrop, because let's be honest, 20:34.400 --> 20:40.720 it's quite a huge footprint out there. You can start actually using a linkable token identity, 20:40.880 --> 20:47.600 where you can finally link token identity to applications and users, because fundamentally, 20:47.600 --> 20:53.600 third party applications are pushing out signals that you can use in your ingestion and telemetry 20:53.600 --> 21:00.640 and alerting for understanding who does what and from where. Now, we're quite out of time, so there 21:00.640 --> 21:06.480 are a lot of things that are being implemented. I give you the slides, I give you that. I do 21:06.480 --> 21:11.360 also find that he isn't here. There's a lot of standards being implemented from mostly 21:11.360 --> 21:19.760 SSO providers, spending towards actually encrypting actually the token itself, encrypting the 21:19.760 --> 21:27.120 session into here, doing a lot of logic around MTRS and the likes, shared signals, having applications, 21:27.120 --> 21:34.240 for instance, and third party apps that communicate the charter, and fundamentally sending each other 21:34.240 --> 21:40.400 signals, so that if a user is getting compromised like on Google, you might also want another 21:40.400 --> 21:48.880 service to be completely informed. And I leave you with this, time is over, so revoking actually 21:48.880 --> 21:53.360 access whenever and whenever rings, try to have a play look for that, try to be ready for 21:53.360 --> 22:00.560 terminating sessions, investigating where those sessions are originated from, and what APIs were 22:00.640 --> 22:06.160 cold and how they were abused, and then fundamentally tried to remedy them. I need to go. 22:06.160 --> 22:11.920 So thanks a lot for your time. 22:11.920 --> 22:13.920 Thank you again.