BsidesLV 2025 - PasswordsCon - Monday

Heat. [Music] Heat. [Music] Heat. [Music]

Heat. [Music] Heat. Heat.

Heat. Heat. N.

[Music]

Heat. Hey, heat. Hey, heat. Heat. Heat. [Music] Heat. Heat.

Heat.

[Music] Heat. [Music] Yeah, [Music]

down. [Music] Hey hey hey. [Music]

down. [Music] Down. [Music]

Black.

[Music] I'm [Music] Heat. Heat. [Music] by [Music] Hey, hey, hey.

[Music]

Hello.

[Music] Heat. Heat. [Music]

Heat. [Music] Heat. [Music] Heat. Heat.

[Music] Heat. Heat.

[Music] Heat. Hey, Heat. Heat. Heat. [Music] Heat. Heat. N.

Heat. Heat. Heat. [Applause] [Music] Heat. Heat.

Heat. Heat. [Music]

Heat.

Heat. Heat. Heat. N. [Music]

permission of those in the frame. So just keep that in mind that that that that includes the presenter. Um so no pictures unless the presenter doesn't mind or says that they don't mind and that applies to the audience as well in particular and anyone else outside. Yeah. So with that in mind, we are ready to begin with our first uh presentation this morning. I'm a machine and you should trust me. The future of nonhuman identity. Dwayne McDaniel is handling that for us. Is Dwayne here or is he stepped out? >> I'm right here. >> Is he there? Oh, there he is. Thanks. >> Thanks. >> Yay. Let's hand over to Dwayne. Thanks. Give it up for Demetri, everybody. Awesome.

Thank you all for being here. And wow, I can't believe it's already here. I can't believe that besides Las Vegas has already snuck up on us. It feels like it was just a couple months ago that I was so exhausted after the best week of Hacker Summer Camp I've ever spent in my life. And here we are again. And I'm so honored and privileged to be here. Um, I'm also speaking tomorrow and I'm just profoundly profoundly grateful to be here. I just kind of want to say that upfront. If you want these slides, I highly recommend it because I talk fast. I have 87 of them and I have 45 minutes. I don't know how to pair down. Not to be

ironic, but don't know how to pair down things. I miss pair. I wish he was here this year. Um, so the the tiny URL, that's where you can get them. I don't QR code things. So, just tiny URL preview if you want. That's why I like their service. You can preview things with that. Let's get going. I need a volunteer who's willing to do a stupid little thought experiment with me. Just raise your hand. You You don't have to get up. Just somebody audience. Anybody right there front row sens to raise your hand first. All right. Ring ring. You pick up your phone. >> Hi. >> Hi. Uh this is your power company and it's summer. If you stop using as much

electricity, we're going to give you a discount on your phone bill. Here's 1 800 number. You can check it on the website. Uh, give us a call back if you got any questions. Would you trust that phone call? I would because I get that phone call all the time. I called them back one time. It's like, "Hey, is this for real?" Like, "Yeah, we give discounts for using less less uh less power in the summer." Makes sense. It's like, but there's like it's plausible, right? There's a plausibility to that overall versus ring ring. Hello. >> Congratulations. You've won an all expenses paid trip to the island dream of your choice. All we need to get

started is your credit card to hold your reservation sir. >> Uh, no thank you. >> Yeah, you wouldn't trust. Your gut instincts are dead right. And thank you for being brave. Here is a home copy of a game I made called Spot the Secrets. It's an exercise. We can talk about it later. >> See, that's what you get for being brave, people. I also have prizes later, so be be aware. So, that's a human. Humans have this fundamental built-in BS detector that says, "Wait a minute, something don't sound right." Or, "Wait a minute, you gave me something that sounds a little too good to be true, but I can verify that. There's a number. It matches what

I can find online. I can call it back. Huh. Okay, I will trust that based on I can verify it." Computers don't work that way. If I am a person that writes a API request that says give me all the users and the bearer token checks out, guess what? That resource is going to give me all the users because the bearer token checked out. There's no MFA. There's no gut check. And that's the fundamental difference between a human and a non-human. Humans aren't just a series of running processes. And for our intents and purposes, nonhumans are. Why am I giving a talk about nonhumans? Well, because in 2022, Cyber Arc said, "Hey, we're outnumbered in the identity

factor uh by nonhumans by about 45 to one. For every human you need to authenticate, there are 45 nonhumans that have some kind of authentication mechanism going on that gets to a resource or something." Here's 2025. We think it's closer to 100, but we don't really know. Research says it's somewhere between 70 and 150, uh, depending on which report you read. There's a bunch floating out there because a lot of people are obsessed with this right now. But we live in the world of Agentic AI now. And I don't know about you, but I have never seen us deploy this much stuff this fast in my entire life. But again, I come from a old school days of like Drupal and FTP

where you you rolled out once every three weeks. That was considered really fast. I remember 6 months was like, "Hey, that's pretty normal to release rate." Now it's like, you're not releasing every 3 seconds. Like, what's wrong with you? But what are we releasing? We're releasing more of these. So, that's why I'm giving this talk is to can we get a handle on this? Can we get ahead of this? And I think the answer is probably, but we got to act and we got to act quick and we got to figure out how to talk to each other about this. So, briefly, I'm Dwayne. I came here from Chicago. This is my, like I said, my third one of these. um

probably my 150th talk in the security space over the last couple three four years of my life. Um I help people figure stuff out. That's my entire mission in life. If I can help you today, I'll be doing my job. Check out my repo podcast, the security repo podcast. Uh we handle everything you can think about in security from red teaming to blue teaming to people just getting started to 20-year veterans, Jason Haddex to Tonnie Jen to, you know, people you've never heard of who I met in my local community and I thought they had a really cool story. Um, hit me up on Instagram or not Instagram, sorry. Uh, LinkedIn or um, just email me. Blue

Sky also works. I'm on the socials. Mo Mastadon, not X anymore for obvious reasons. Let's move on. Oh, I also work at GitGuardian. That will come up later, but it's not really talk about. Um, if you didn't get a sticker earlier, by the way, with the GitG Guardian thing, I do have more stickers with that owl on it. Hit me up afterward. Happy to give you some. All right, so let's get back to why I think this is important. Uh so last year Cyber Arc came out this report and I promise I do not work for Cyber Arc. I promise I just like their research. Um they said 93% of organizations had one or more identity

related breaches in the past year. So what what does that mean identity related? This actually threw me for a loop and I had to go do some thinking and research and actually talk to some people I know over at Cyber. I won't name drop but they help me figure it out like it's anytime someone assumes the identity of someone else to do something. That's it. If you're assuming a human identity, that means you're taking over their account and you're acting on their behalf. Here's a fun one from back in May when I first first first uh was putting these slides together uh for a different version of this talk. This just happened to happen. So, a paid WordPress theme just let

anybody reset passwords, including on admin accounts, which means you could then act as the admin and do whatever you wanted on the account. So, that's that's a classic, you know, human takeover. Fishing is another one where we got your account and we got into your uh 360 um mailbox or whatever you call it. Um we got in your Gmail. We're acting as you. But again, 45 to1 in 2022 and 100 to1 right now we think estimate and this is much far more likely. I am assuming the identity of this non-human entity to do something. While this entity was supposed to be set up to go and pull images or go and, you know, check things

into GitHub, um, now I can use it to delete repos or clone those repos and send them anywhere I want or xfill data or do things like this. Just a couple examples that uh, if you got the slides in the speaker notes, there's links to these actual articles, but we'll steal an API key and get in and do whatever we want. As an attacker, I love this because I don't have to know anything about exploiting vulnerabilities. I don't have to know zero days. I barely have to be functionally literate to put an API key in the right place on an CLI call. I just do. We got to remember that we're not dealing with humans

for the most part anymore when it comes to identity. So all the conversations we have about IM, PAM, pass keys, phto, all awesome stuff. I am for pass keys a zillion percent. I can convince someone to put their thumb on a screen and unlock a stupid long number that they'll never see that gets rotated on the regular behind the the scenes way more often than I can convince someone to download Authenticator. I personally don't like Authenticator even though I know it's like mandatory. I need to use it. It's just like, man, I got to use authentic. Ah, god dang it. Pull out my phone. So when we say non-human, the fundamental problem with that is

it's like saying there's only two things in the whole world, a potato and not a potato. It's not really that helpful. So there's humans and non-humans. What do we really mean by that? Well, it could mean the floor. It could mean the Wi-Fi network. It could mean a car. It could mean a IoT device. It could mean a lot of things. I I work in the world of application security. I just do. I'm an OASP fanboy. Uh I'll get to them in a second, but I really really really like the IETF's uh the Internet Engineering Task Force definition. I'll talk about Whimsy a little bit later. Uh just briefly, not going to get into the depths of it, but

they have a really succinct concept of workload. It is a running instance of software executing a per something for a purpose. That's it. Can run for seconds, can run for years, part of a larger system normally, but it needs to communicate those other parts of the system. OASP on the other hand came out with this definition back in January or December and said what we mean is part of a larger application something that needs to be identified. It's not a human. They go on to say well this is often associated with secrets. It needs to have an authentication mechanism to go from I can't do work to now I got the data and I can do the work. Makes sense.

We got to authenticate to do stuff. And before I go any further, I just need to make a caveat. I've been talking about this stuff for so long and so much that the words token, credential, secret, API key, password, database connection URL all mean the exact same thing in my head. And I know there are semantic differences and I apologize upfront, but I'm going to say secret and credential interchangeably for the rest of this. And I don't know I'm doing it. So what I mean by that is this and yes we can get to a world of PKI and shortlived JTOS and hopefully I'll get to that a little bit later uh and get away from this but by and large

when I'm talking about secrets I'm talking about that that problem of we hardcoded a thing a string and said yep that's how we're going to connect. The obvious implication is if anybody finds this code, then they can use that exact same string to do whatever the hell they want. This comes from uh about two months ago now when I asked chat GPD like give me an example API call like that in a Python script. And here's what it told me to do. Notice how it didn't say call environment variable. Notice how it didn't say call into the vault. No, it's like your access token here. Now, I have been doing development. I'm I got a gray beard. I've been around for

a while and know like, okay, that's silly. But it's telling me, okay, generally this is how it's sculpted. Do most people know that? Do most people know that's this is a dumb idea? >> Not based on what I'm seeing. >> Yeah, not based on what I'm seeing either. Um, now I'm not against AI. I am totally love AI. I use Cad GBT almost daily um for various things, but I kind of use like I use Wikipedia for reference for noncritical stuff. Like sure, it got a little wrong, but that's cool. I'll just playing around with an idea anyways, bouncing ideas off. But if I'm going to put something in production, it better pass all my other

tests and it better meet the standards that I'm going to put in production. And my worry with all of these assist bots, co-pilots, and whatnot are that we're not having that human conversation. But that's a whole other talk I give and I'm going to get off that horse. We know that this problem of people hard- coding credentials is getting way worse because well we can just look in public to see this which is a self-feeding system because guess where all of these co-pilots and whatnot are being trained on this and on here my company uh puts out this report every year. This isn't a sales pitch. Please go download this report. You can do it

over tour. You can. I promise we are not going to ask for anything from you. Just we just want this information out there. It's a free PDF. Just go click the button. We don't ask for nothing. Um again, do it through an honest window if you want. Um so here's game time for a fabulous prize. We're going to play a Price is Right kind of game. How many secrets do you think we found added to get and you already know that answer? Uh how many secrets do you think we found added to GitHub public just in the year 2024? From the beginning of the year 2024 to the end of the year 2024, how many secrets do you think we found in

public? And I need hands. Otherwise, this isn't going to work. And it's price straight style. >> 50 million. >> 50 million. >> 500,000. >> 500,000. >> 100 million. >> 100 million. >> 1 million. >> 1 million. >> 60 million. >> 60 million.$1. >> $1. Bob. >> 1 million. >> 1 million. Four. >> Infinity plus more. >> Infinity plus. Wow, that'd be a cool number. Um, well, the good news is it's not as high as some of you were guessing. Um, but it is 23.77 million. Uh, so who who who got the closest? You're gonna have to be honest with me because I don't remember. >> No, 50 is over. >> You said was it one million?

>> You said 1 million. >> 1 million >> all the way in the back. I can't throw it that far, but you want a stuffed octop. It's not stuffed. Crocheted octopus. That's red team plus blue team put together materials. I crochet on the plane. Come up later and we'll get it. I do that for that specific purpose of wow that's kind of a fun way to break terrible news because this is not good and uh it is like 4.6% of all repos. So you can do this too. You can play this game too. You can just go to api github.com/events and look at the feed. It's public. It's in the name of the product. You can just read the feed. Go

look at every commit. Scan it for a secret. Uh or anything that becomes public that was private. Scan it for a secret. 25% growth year over year. And we have changed methodologies, but even accounting for the old methodologies, it still grew 25%. Um, and the report goes into great detail of how we did the methodologies on it. The most horrifying part of this to me, oh, so also just to finish the thought, um, we do send an email immediately upon seeing a secret to the committer. So, please sign your your commits with actual emails you check. Please, because there are good people in the world that are trying to say, "Hey, you might have done this by accident. Please don't do

that." Uh we're one of those people. The horrifying part to me was we do validation checks on all these secrets. That's not the horrifying part. Um if we can validate, we validate and say, "Hey, does this work or not?" Non- intrusive call into the system. Say, "Hey, does this work or not?" And if it does, we say, "Well, that's a valid secret." Um we went back to 2022, the all the data we've had then from those findings and said, "Okay, all the ones we found valid, let's take a subset." So we found 11,000. We just took a random 11,000 that were valid in 2022. retested them in January 2025 and 70% came back as still valid.

Yeah. Which kind of makes the data from Verizon's DBR make a little more sense. Um I don't know who has not read the VR DBR this year. You can be honest. It's free. It's an awesome report. It's written by humans for humans. It's the best like two-hour read you'll have this year. >> Press release. >> The press release's good, but there's jokes all throughout. all throughout. Uh my favorite one I think is on page 14 or 18. It's like and just like in the land of Fay. Names have meaning here. Um yeah. Uh it's footnote 13 is a call back to footnote 11 from the previous year. Yeah. Fun. Uh anyway, um I like I like

talking about the fun parts because yeah, 22% of all initial um access vectors for breaches is credential abuse. people finding these keys and just getting in. Exploitation of vulnerabilities is close second. Fishing's falling down. Yeah. Well, wait a minute. Fishing is how you get human access. This is definitely riding on the backs of web infrastructure. People are attacking the non-humans because there's just so many more of them and we've secured them so poorly and there's no MFA and there's overcoped and they live forever by default. And we see the numbers for how fast rotation happens. Here's Verizon's independent thing. They say 94 is the number of average days after the breach is known. So we put out this other report. Again,

Cyber Arc, don't work for them. Um, but they keep popping up. Uh, we did a report with them back in 2024 and we asked uh a thou well, I'll put that back up for a second if you want. Voice of practitioner we call it. Um, we asked over a thousand uh IT professionals a bunch of questions and 75% said, "Hey, we got strong confidence in our secret manager capability and then we said, "How long to take your remediate secret?" And they're like, "Uh, we think about 27 days." Nope. Nope. We're pretty sure that's not right. We're pretty sure that's not right. Um, yeah. And then same exact people said only 40% of developers reported follow

security best practices. So what? How? I don't know. This is survey data. You can trust it only so far. So what do we do? What do we do? That's the horrifying first half of the talk. Apologies for making people uncomfortable or scaring people. That's why I do it with a little bit of levity. What do we do? Well, I can't overstress this part enough. Be like this little bird. Breathe. Eat. Remember, you are human. You are a person first and foremost. If we lose sight of the fact that all of security is about human beings, including you, including your health and mental health, we've lost the game. We We can fight zero days till we we're dead. We're

never going to win security. All we can do is keep supporting each other. Bides is really important for that. Getting together and seeing each other face to face. You're no longer just a screen name here. You're no longer just an anonymous person out there fighting the good fight as well. We're here together. And that means something. God damn it. So you take care of you first. Put your oxygen mask on first. Breathe. Realize like look, we can do our best effort. We can fight this fight together and we can make the world a better secure place so developers can go home to their kids and not have to get worry about this at 3 in

the morning. That we can have jobs tomorrow because we did it right enough that the attackers got to us and said, "Wow, all the easy paths are hard now here are here. All the easy paths are blocked. I'm gonna have to do some back flips to get in here. I can move somewhere else or breathe first. And then look to OASP. I'm OASP fanboy, so forgive me. Uh, but they put out this back again December uh January this came out. The OASP nonhuman identity top 10 risk something. Um, let's look it up. That's a lot of stuff and I'm not going to laundry list it to you. I have a talk tomorrow where we're going to go through

this a little more in depth about how to talk to developers about all this stuff. Um, but I think it basically falls into these three broad categories that we really have to get a handle on. One of them is really hard and it's going to be the challenge I going to challenge everyone to walk out of this room and think about how to go about the rest of your job and the rest of your career. The second one's pretty straightforward and that's the one I'm going to spend the most time on because that one's the easiest one to talk about and well, I like talking about things that are easy. Um, the last one is only going to get

more complex, but good news, there are tools on the way, and tools aren't the solution for everything, but tools can help. Tools are part of the solution. So, I say three pillars of NHI governance on this screen. I'll say something else later, but I firmly believe this is how all good programs work. I've always believed this and I always will believe this. It's a virtuous cycle where you raise awareness with the right people, make a plan, put processes in place to say, "This is how we're going to do this." Then, and only then, go out and acquire the tools you need to get the job done. And once you have the tools, train the people on how to use those

tools properly using the processes you set forth, and then refine the whole thing in a virtuous cycle, a feedback loop, if you will, a DevOps, an agile loop to say, "This is how we're going to solve this." and keep refining and keep refining and keep refining. But if you don't start with raising awareness, getting people on the same page of what we need to get done, it ain't gonna get done. And that comes down to ownership. You ever want to scare an IT team walk in and say, "Who owns Active Directory?" The answer should be somebody. The answer should be a very specific point person in the company. Who owns PAM? Who owns Octa? go to your HR teams like who

owns onboarding and like what do you mean? Maybe they have an answer. Hopefully they have an answer. But if we go through this list, it's like all right, devs introduce these NHIs a lot. They put the calls to the APIs. They have to authenticate to things. DevOps builds the infrastructure that's all the pieces talking to each other. Do they own it? Well, they created it. Devs have a pretty high turnover rate. So, you hope they're still around. DevOps hopefully hopefully operations does have a plan for contingency on this stuff, right? Well, guess who goes to jail if you get a breach because of something they did? Not these guys. Uh maybe it's the exec team. The exec

team ultimately is responsible for everything in your company. Firmly believe that. It's their job. But their job is also to manage risk. And security in their opinion is just one more risk and a whole litany of sea of risk. Maybe it's your IM owner. Maybe you have this person. Maybe you're big enough to the group that studies executive pay. Uh I forget what this stands for, but INS um said from stage a couple years ago that it's not until companies hit about the five billion revenue mark that they're big enough to justify having somebody that owns AM outright that reports to a C level. So it be CISO or the CIO or the CTO or

maybe CEO or maybe board. But this person should exist. Somebody should be responsible to drive the conversation forward. So they don't maybe outright own everything. But unfortunately it means everybody owns it, which means nobody owns it right now. And this is the conversation that's hard. All right. How do we rally this? How do we get budget for this? How do we improve this across the team? because this is how they're getting in. We can spend all the money on all the EDX, EDR, all the endpoint solutions, all the lock down of everything, all the technical solutions in the world, but if we're just throwing out the password for all of these NHIs we're creating at a

rapid rate because the AI keeps telling us to do it, why why do we even bother? If I can log in, I don't need I don't care about your firewall. So, how do we have that conversation drive it forward? Oh, I think it does boil down to having the conversation of like what even is ownership here. I like Ann Landers version of it. She stole it from somebody else, but that's where I read it first, so I'll credit Ann Landers here. I won't read the whole list to you, but open it, close it, turn it on, turn it off. What's her sunset policy on this API? How long does this secret live? Who wrote down those questions?

Where is that policy? Where's the governance model around it? That's the challenge I want everybody to go out here thinking like, all right, technically we can do this, but who drives it? How do I have that conversation with the rest of my team? That's all I'm going to harp on today. Come back to my talk tomorrow. We talk way more in detail about how to have that conversation with developers and drive them. Let's talk about the easier one, the one with a very straightforward set of technical solutions that I'll speed up now. How do we get dev ops and dev people to stop doing this? Because if you just send them a ticket, say, "All right, you

leaked a secret, put it, rotate it." Guess what's going in the code? The exact same thing they just did because there's no other meth better methodology. So, I'm going to talk short. I'm going to talk long term and I'm talk short term. In the long term, we have solutions. We are going to move things to the world of identity uh federated identities and ephemeral secrets. And we're already doing it. We've been doing it for a decade. Google's been doing this for a decade. It's called Spiffy. Secure production identity framework for everyone. They don't call Spiffy internally. Google has something else that they call it internally. Uh but this K idea came out about seven, eight

years ago from a meetup uh happened at Netflix. And Spire is the open source actual implementation you can go download right now. And if you're handling your own workloads right now and your own internal systems, this is what you're going to want to do. Way too much to spiffy to cover in this short time time, but I'm going to give you resources. I'm going to give you the quick overview. We can cryptographically prove a bunch of stuff at the time a workload is created. We can do secure boot. We can do trusted boot. We can know all the facts we need to know that this thing we spun up is the thing we spun up and it's provably true. If

that's true, we can then inject with an API a credential that says you are you this is your identification and we can use that for authoriz uh for authentication throughout distributed systems. That's kind of it. If I go to a trust uh if I go to a gateway and say here's my credential, you can say yep that's your credential. I trust that certificate authority. Cool. Or I say let me go double check that real quick. And now we let it in. And then we wor about authorization as a separate mechanism because those are two separate things and I'm not going to get into authorization today. You can federate the certificate authorities. You can do really cool

stuff with this, but it's the idea of namespacing and allow listing with PKI. There's a whole book about this. It's one of the best technical books I read in the last few years of my life. spiffy.iobook. It's free. It's 198 pages. If you're like, I ain't got time for a book. Sorry, that should have taken another slide out. Uh you like I got time for a book. Well, go watch this talk from uh cloud native security con last year. Uh the story of crush. It's really really good and everything you need to know about this with some working and implementation details uh much deeper than I get into today. You're like well that's cool but that's

cloud native. What about the rest of us? Well that's where the ITF comes in. So you might not know what the IETF is because I honestly didn't before a couple years ago. ITF, Internet Engineering Task Force takes care of things like, you know, TCP, IP, HTTP, HTML, like the actual standards body that says this is what this means. Well, they're working on something called whimsy, wearable identity in multi system environments, which is basically the ideas of spiffy applied globally at a better scale. We're in draft four right now and there's a real large conversation going on in the email group and it's like sped up in the last few weeks uh as we march toward one of their

big events. Uh you can go read the drafts. It's awesome. That's where this workload thing comes from. And it's basically what I explained with Spiffy but applied to pretty much everything. There's going to be a whimsy namespace instead of a spiffy namespace but there conversations ongoing and what that actually looks like and if you want to get involved in that now's the time. like okay well how far off in the future is this stuff this is like how we're going to do this in a few years great uh well we can do it right since May in Kubernetes um as of Kubernetes uh.33 this is how we can do image pulls now you can set up service count token for

credential providers that's shortlived automatically rotated tokens for service counts if the credential communicates and opt in receiving service count the whole thing uh this is for image pools so basically you say here's my token that says I am me. Cool. I'll swap that for a very short-lived thing to do the image pull. Everybody wins. This is already popping up. This is how we're going to do things in the future. So the idea of a longived credential that says I am allowed to do these things is going to be separated out from here is a rotated short-lived thing that says you are you that's provable through a specific authority and that's how you're going to authenticate in. And

then we're going to about authorization as a separate piece and that's what you're going to trade for once you're past the token uh once you're past a zone. I'm oversimplifying a few things here. Go read the standards. Go read the docs. That's how we're going to do that in the long term. And developers are just going to think about name spacing, certificate authorities. I promise you in the next three to four years that's where we're going with it. But in the short term, how do we stop this? Well, there's this magic trick you can kind of pull off if we think we have all these non-human identities, all these these things we need to account for and right

now we need a way to identify them. We need to am identity access management all of these things and in the meantime we have given them all a unique identifier in the form of a secret that exists just to do let it do the thing. What if we said these are equal? If we can just map out all of the secrets, then we have therefore mapped out all of our NHIS. Now, it's a little bit of kabuki theater. Is that exactly 100% true? No. Is it a practical approach to how do we get out of this hell in the short term? Yes. Because I've seen a lot of people do this. The plan then becomes very

simple with just these steps. Find all your secrets, properly store them, get better developer tooling, continually secret scan, and then automatically rotate all the secrets once they're properly stored. It starts with finding everything because that's the first rule of all threat models. If you don't know what it is, you can't protect it. And everybody's kept track of all these NHIS they've created and all the secrets. Right. Right. They they they definitely didn't like put a giant list out there on plain text. We would hope, right? No, of course not. But we do know where all of these secrets live because we keep finding them in code and in Jira and config files and Slack and Confluence

and secrets.ext and many, many, many, many, many other places in the world. And we know where those are because they're on our network. And hopefully we can scan our own networks, right? Well, that one I actually do hope I'm right on. We know where these things are. And there are a bunch of tools to do this. Now, I have a personal favorite of this list, but eventually you just want to be able to find all of the secrets. A lot of them match pre-existing patterns with prefixes. A lot of them don't, and you need contextual analysis to figure out how to do that. There's a lot of ways to go about this. Again, I have a

personal favorite on this list, but I'm not here to sell you anything specifically other than the idea of scan for secrets continually. So, okay, we found all of our secrets and we got this giant list of like here's our inventory of all the secrets where they're not supposed to be. What do we do next? Well, we put them where they're supposed to be. And here's a very highly accurate art um art uh what do you call architecture diagram of how secret managers work. Basically, a secret manager can in store uh can store credentials secrets whatever even config at rest, encrypt it, and then deliver it over the wire when needed, being pulled in just in time to be used.

Thank you. And yeah, hopefully have some centralized reporting on that. Hopefully, it's easy enough for developers to use. Good news, if you're all in on one cloud provider, you already won the day. They already have this. This is built in. It's baked in. Is it free? I don't know. Maybe. hope should be isn't but it should be. Um AWS actually is trying to get out secrets everywhere so you can do like AWS secret manager for everything. It's still a work in progress. I've heard mixed results but still you can do this if you're on multicloud the uh hybrid legacy. Well guess what they sell that it's called a service that does that. Enterprise Secret Manager is generally the the class, but

vault is the general term you hear, even though Hash Corpse actually is called vault. And they all work the general same way. You stuff the secret in there and you give it a path. And then don't worry about the rest of this. This is just an example to like prove that you pulled the secret out. But then the developer instead of hard- coding the secret, instead of hard coding the secret, the developer says, "All right, here's the thing I am calling and here's the path inside of the thing I'm calling to give me back the secret." Now, there are a few ins and outs and architectural trade-offs you're going to have to make when you do this. And one

of the best talks I've ever seen about how to do this green uh blue green rotation of secrets using a secret manager happened on this stage last year. Um Kenton um brilliant talk. The link to the the talk is um in the show notes or in the speaker notes. Go look at it. But basically rotate as often as you can and do it in a way that doesn't break. He's doing this against satellites. So if they mess up there's no going back. So they have to very securely do this in a very very scalable way or a very robust way. So then you just got your list of like all right so we do this for new systems

green field obviously then we do mission critical systems and then you find all these legacy secrets like what does this even go to? And a subset of that's going to be zombies. How many people think they know all the API endpoints that are still running across your organization? Never had a hand go up. Actually, one guy did. He's like, "Yeah, we have one API. It has two endpoints." Like, okay, okay, you you're going to you get a pass. Uh, but everybody else got you got something running. Guess what? If I'm fuzzing, I don't care. I don't care if it still works or not. I'm just going to fuzz until it does. All right. So, how

do we get developers to use that stupid long string and then put things in there with a path? That's a hard question because you're trying to slow them down now and their brain anything security-wise you're asking them to do slows them down and guess what their boss is yelling them to go faster and they're saying we're going to replace you with AI if you can't produce fast enough again tomorrow I'm going to dig into that a lot more but in the short term we got to say hey how would you like to go a lot faster and we give you tools that do that and that's where security engineers are the greatest heroes in the

entire universe and this is another challenge if you are a person that has access to developers and you are a person that wants to actually help developers, go sit down and talk to them about their workflows and the thing that's going to pop up in every conversation is Git. Guaranteed 97.8% of all developers on Earth use Git daily in their workflows. Why don't we meet them where they are? Because Git has this awesome ability to do scripting. It's called the hooks. everywhere in the life cycle when git does a thing is a chance to hook in a tool. So why not give them a tool locally that says all right paste your hard-coded credential try and that's catch it and

say all right you can't do that that exists out of the box right now a lot of people do that but then why don't you further the script and say well why don't we just go check and see if this already exists in the vault oh it does cool here's the path oh this doesn't exist in the vault that's stuff it in and make up a path for you that exists sort of out of the box that takes a little bit of scripting and a little bit of how does the path work but I've seen that script in action and then you said a whatever I don't know PowerShell tools um to actually swap out the line where they

hardcoded the secret with the vault call again that's just pretty simple scripting and then once everything's committed if I commit and this is on the other side if a commit contains a new call to the vault rotate that secret automatically I've seen this script I've seen the script work takes a little work, but possible. But dev's going to be devs. They're going to get around your tools. So, why don't you do this at the PR level? Why aren't we doing this at the PR level? This is possible. Now, the technology has caught up. Maybe you don't know it has, but it has. And I'm here to tell you this. You want to see open source how we built

this a year and a half ago. We called it Brimstone. They called it Cyber called it something else, but it's a reference implementation. Would you run this in production? Maybe. Your your risks are your risks. Um a little bit brittle in my opinion, but we've worked on it a lot since then. And um again, it's this jumping off point. All of this is just scripting. All of this is just how do you communicate to a vault? And guess what? All of the players are willing to talk to you right now and say this is how we want to do it. Thank you. So final secrets, put them in there. Containably scan for secrets. people going you can inject

secrets everywhere through the software development life cycle and people going to get around things constantly so constantly so this rotation at scale though this is actually pretty straightforward again if you're already all in on one provider these scripts exist they wrote a lambda for you already on AWS for every conceivable thing they built ever and if it doesn't exist write them and they will write it for you because they want you to do this and that all the script does is just make a new one test swap in the new one test cleanup that's All it that's all these scripts do. There's tons of blogs. There's tons of resources on this. If your team doesn't

already have a plan in place to make this happen, this should go way higher in your priority list because if I find a hard-coded secret and it expired, it's useless to me. Sure, I can help map your network and whatnot, but I don't really care about that. Doesn't let me immediately in. I'm going to move on to something else. If you're on one of those other systems, then the question is, can I make a call into that system to let me rotate a secret? The answer should be yes. It's 2025. The answer should be yes. Uh if the answer is no, start asking yourself why you're using that service because it's 2025 and you should be able to make

an API call to rotate a secret. And then all the other players like Cyber Arc Vault, Doppler, all those guys all have scripts to help you out with this stuff. They all do. If you can't find what you're looking for, call the rep, call whoever, and say, "Look, this is what I need." Go to the communities pages. It's out there. People have been working on this. You're not alone. Just to reiterate, there's a lot of stuff on here. I'm not going to go through them all one by one. No time anymore. But it boils down to ownership. And that's the hardest piece. And that's the conversation you're going to have to need to have. Long live secrets.

Hopefully I've spelled out that it's doable, straightforward. Easy. No, nothing's easy. But there are straightforward paths here for technical complexity. I'm going to point it at CSPMs. I'm just going to cheap out and say, look, there are tools that can help you do this and training and awareness around all of these things. Like, but we're only making our it harder and more difficult on ourselves. Just go pick a tool, go talk to them how to do it. And there is a whole another class of things around AM that stretch beyond humans. I was at Identiverse earlier this year and this is like a happening conversation and there's a bunch of players that say how do we stretch our

IM platforms not just to handle humans but for non-humans and then these guys popped up non-human identity management group I'm affiliated with them um full disclosure but their entire mission is like how do we tool for this how do we deal with non-human identity at scale in a governance way in a security way and they put out lists and a bunch of reviews of all of these players There's a lot and this is the fastest growing segment of security I've seen in the last couple years of my life. It's just kind of amazing how fast this is exploding. We're in there, too. Just full disclosure. But that's where I'm going to leave you. Go look at what's out there and what

they can provide for non-human identity governance. But I ain't worried so much about the governance as much as I am worried about we keep leaking secrets. I am worried that NHIS are outpacing humans by so much. But the fact that we can abuse their access so easily because we keep getting secrets wrong terrifies me when I think about this is happening right now. I don't have no idea how many robots are on that screen. I've never counted. I just know it's a lot. And I know the Gen AI is pushing this forward really hard. Raise that awareness. Get the right people having the right conversation. Get that conversation of ownership going. And then you can start building

the processes. Then you can pick the tools. Then you can train the people and then the visual a virtuous cycle can complete. I'm out of time. Then I'm Dwayne. I came from Chicago. Help people figure stuff out. Hit me up. I am happy to give you anything you need slide-wise or whatnot. That just goes to our blog. And thanks very much. Slides are again at that tiny URL. Thanks very much everybody.

And with that, thank you very much. Waitri. [Music] was [Music] Heat. Heat. [Music]

[Music] [Music] Heat. Heat. N. [Music] Are you

home? [Music] Down. [Music] Hey. Hey. [Music]

[Music] Heat. Heat. [Music] Heat. Heat. Heat. Heat. [Music] Heat. Heat. N.

Heat. Heat. Heat. [Applause] [Music] Heat. Heat.

Heat. Heat. [Music]

Heat. Heat. N.

[Music] Heat. Heat. N.

Heat. Heat. Heat. [Music] Heat. Heat.

Heat. Heat.

[Music]

[Music]

[Music] Heat. Heat. [Music] Heat. [Music] Heat. [Music] Wow.

[Music] [Music] Yeah. Heat. Heat. [Music]

[Music] Heat. Heat.

[Music] Heat. [Music] Heat. [Music] Heat. [Music]

Heat.

Heat. Heat.

[Music] Heat. [Music]

Heat. Heat. Heat. Heat. N. [Music] Heat. Heat. N.

Heat.

[Music] Heat. [Music] Yeah, [Music]

down. [Music] Hey, hey hey. [Music] Okay, we are ready for our next uh talk. So, we'd like to welcome everybody again to Passwords Con. If you're still here from the previous session, great. If you're new, um, welcome to Passwords Con. Our next talk is entitled The Rise of Synthetic Passwords in Botnet and Attack Operations by Travis Moore. A quick thank to our sponsors, our diamond sponsors, Adobe and Aikido, the gold sponsors, Drop Zone AI and Profit. Reminder about cell phones. Please keep them on silent so that it doesn't disrupt anyone anyone around. There's no need to record or stream. Uh the talks are recorded and they are being streamed. Also a reminder that uh the Bides Las

Vegas photo policy prohibits taking photos of anybody without their prior consent including speakers and their content. So just please keep that in mind. Um obtain con consent before taking a picture of anybody not just here or in the audience but the whole conference as well. Right. So, we're going to get started with the rise of synthetic passwords and botnet attack operations by welcoming Travis Moore to the platform. [Applause] >> Yeah. >> Yeah. >> Yeah. I'm I'm okay. >> All right. Uh good morning everybody. Um very very cool to be here. First time in uh Las Vegas. Can everybody hear me? >> Yeah. All good. Okay, cool. Um so yeah uh Riser synthetic passwords in botnet

and attack operations. Um so just a quick little who am I? uh so I'm a security rearch researcher at Bitrack Cyber Security based in South Africa with all the lions and tigers running on the loose and then uh yeah I'm focusing on uh credential abuse and detection evasion um also interested in password systems and attacker behavior so um it was mentioned earlier that it's also passwords con isn't just about passwords it's about you know kind of human behavior and I think I think that's a very important note to to remember. I also really enjoy hardware hacking and low-level exploration. So yeah, that's just a little bit about me. Um but without further ado, let's get to the talk. Okay, so

uh I just want to fix this thing. There we go. Okay, so the credential landscape has shifted. Um so as defenders continue to strengthen protections around password reuse and breach correlation and behavior behavioral analytics attackers are shifting tactics. So one such evolution is is the increasing use of synthetic passwords. So these are algorithmically generated never before used credentials designed to overwhelm and evade. So they're not sourced from leaks or created through guessing strategies. Instead, they are crafted at scale using scripts or AI to mimic humanlike formats or generate high entropy randomness. So their purpose, sorry I was meant to go to the next one. So their purpose is actually to flood login systems. So, I

mean, the reality of you getting a uh getting into an account with a synthetic password is very low, but that's not their point. Their point is not to log in to the system. It's not a brute force in a traditional sense. Instead, it's meant to flood the sock and obiscate credential stuffing attempts and poison the uh the visibility of security tools that rely on known patterns or breach history. So, let's just uh let's just take a step back. So, synthetic passwords are they've never they've never been used before. Um and they evade detection. So, the detection that I'm talking about in this sense is uh many bigger platforms they use breach correlation. I mentioned that

earlier. So breach correlation is basically um if your password or the password you're trying to create or login with was previously found in a breach, they're not going to let you use that password again. They're using um you know API calls and stuff like that from other kind of password um what's the word? Yeah, that that's it. Thank you. So, password repositories, they're trying to look through that and trying to see, okay, like obviously if the passwords in a leaked database, they're not going to let you use it again. That's like the worst security practice. So, that's just a little bit about what you know what what we're trying to avoid here is we're trying we're trying to get

rid of that uh alleviate that that kind of stress that we've got there as brute forcing and stuff like that goes. So, terms of making a synthetic passwords, it's actually really, really easy. Uh, this is just a random Python script that I just uh whipped up with the good old uh chat GPT. And it's just obviously the the working part of it. But what you can do with this script is you can literally just put in um words and numbers. I believe it's numbers and digits. Yeah, digits and it will just randomize it completely. So I think I did about 10 billion passwords with this. Uh I changed the how many it makes in total and not one

single one was uh you know they were all unique basically not one was repeated. So it worked pretty well for that. Again it was just more of a proof of concept. Um, I definitely think with with enough time and like actual effort put into to making this a real thing, I definitely could have made a better script than a whole lot of if state statements. But here's some examples of the synthetic passwords that that um that that script makes. So, I passed it in a whole lot of names and a whole lot of numbers and then it obviously does special characters. Uh, but but it's so versatile. You can do whatever you want with the script really. Um, you don't

have to put names. You can put pets or uh literally drinks. Uh, really it doesn't matter what you put in here, but they they look they look real enough, which is which is kind of the problem here is they look real enough. the entropy level is pretty good. Um, you know, nothing nothing out of the ordinary when we're looking at stuff like that. And again, that no one's ever well I say I think no one's ever typed these passwords into anything. At least they weren't in any of the breaches that we found. So, they're pretty unique, which is which is good. And they're not like, you know, password managers 25 character thing that looks like I don't

even know what it looks like. It looks like a bomb hit the alphabet. So that that's pretty interesting. They look real enough. Okay. So why why do we use them? So I just want to change my notes here. So, we use them because uh give me a second.

All right, I found where I was. Okay. So, uh why should we use them or why why why are they being used? So, defenders often assume that no match in have I been poned should equals a low threat. So, this assumption is now exploitable. We all know what assump what assume means. So, if there's no match, there shouldn't be any attack. That's basically what they're saying. And I'm also on the wrong slide here. There we go. Okay. So, just because it's not in the breached repositories doesn't mean that it's not um that it it's not a brute force trying to get in because what ends up happening is the socks drowned or your system operation s uh sensors drown in junk. I

mean it's like uh it's noise. So you're left analyzing high volumes of high entropy inputs that kind of go nowhere, you know, they're like uh rabbit holes. Then breach mashing, breach matching like have I been pawned and uh dehashed I believe it is and spy cloud. Um it just zero match means to them at least if if they're using those kind of repos means that it's clean and it means that it's perfectly okay to just you know let all the um the login attempts go through. And then honeywords also break down. So, if all attempts are unique and high entropy, even Honey accounts become harder to trigger because it it looks like somebody maybe just typed the email

address in wrong and then they're using their real password because they look so they look so real. And then the behavioral signal kind of gets lost in translation as well. So, if every attempt comes from a different session or an RP, what do you focus on? Uh there's nothing concrete that you can focus on. You can't focus on the IP. You can't focus on the um the type of passwords they are because they synthetic but real looking. Um so it's it it's kind of like a a difficult one, you know. Um so I have this graph here. As you can see, I'm not very good at making graphs. Um because that's the strangest graph I've ever seen in my life.

So what I did was for this for this graph I have 10 million synthetic passwords and I have stolen passwords from stealer logs that were fairly recent and I compared them as my breach corpus. I compared them to the NAS API breach. Okay. And of this stolen passwords from the stealer logs 98.66% 66% were found in the NAS API stuff, which is kind of kind of a given. I thought it was a bit high though, but I suppose people aren't really changing their passwords. And then the synthetic generated passwords wasn't found in anything. So, I probably could have just put this into words, but I thought the graph looked kind of funny. So, I I hope you enjoy my

my lopsided graph. Uh so it's kind of the invisible attack surface, right? So synthetic passwords are no longer on the fringe. Botnets are using them. Attack scripts are generating them. They are cheap, scalable, and invisible to traditional controls. The attacker doesn't care if the password works. As I said before, in fact, many times they don't even want it to. The goal is to learn to mask and to distract and they're succeeding at these. So, detection must in evolve. Um, so to detect them, we stop relying solely on breach correlation, incorporate entropy scoring and login pattern anomalies. All pretty standard stuff. and session fingerprinting. And by standard stuff, I mean we think it's standard, but some

people are just I don't know. I don't know. They're not they're not implementing them, which is strange. Um, credential attempts that fail too cleanly. So, we we could monitor things like credential attempts that follow fail too cleanly. And what I mean by that is, you know, if if as a as a human if the password is wrong, we kind of try something maybe slightly different. We put put a little bit uh like I know for me when I before I used a password manager, if the password wasn't password, it was password one or password two. And that that's kind of how it went. But if they fail too cleanly and people are just like kind of

trying something completely different, you know, that that kind of could could mean that we're getting brute force basically. And then the seam logs with sudden surges in high format variance inputs. So what I mean is again it they they're varying all over the show whereas usually a normal person a user a human uh would would try something not not all over the show it would be like closer to the actual word that you're trying to that you're trying to guess or whatever if you forgot your password. Um and then I have a final call to action here which is just shift the detection from uh ident from identity to int intentbased. So what what is the user's intent with

trying to log in? Um and I think that that could definitely be something that we can push forward with AI. Um, I know AI is not perfect, but we could definitely train train some sort of model just to figure out the intent rather than the identity. And then we could also flag sessions with non-human patterns, kind of like a recapture. But um yeah, you know, all of the stuff, all of the stuff that I've mentioned honestly seems pretty straightforward and pretty normal to everybody in this room, but a lot of the companies and uh login pages and stuff, they're kind of just using one method. It's like a one one method fits all type of thing. So, this is more

just to raise awareness um and just trying to trying to get the word out there. But I think I spoke too fast. So questions. >> Yeah, >> sorry. I want to back up a little bit. So we've observed this phenomenon where high volumes of synthetic passwords are being submitted as >> from botn nets or for the purposes of creating accounts for botnet activity. >> Yes. Yes. So this is this is brute forcing current accounts. Okay. So that that's kind of where we saw the you know the sock and the seams kind of get overloaded with these passwords that looked like the whole world was trying to log in. >> Okay. >> Human human activity and that's that's

kind of where we started. >> So they're generating passwords that they think a human might use. Yes. Very. Okay. So the ultimate goal here is to brute force their way into the ultimate goal here is to brute force their way into existing accounts by trying to generate passwords that would look like what a human would. Yes. But the sock might not notice because they look so much like I'm following now. Okay. >> Exactly. If you weren't following, I'm sorry. >> I thought you were saying they were just trying to flood >> I thought what you were saying was that they were just trying to flood the zone with with basically useless data in order to mask actual credential

stuffing. >> Yeah. So it's it's basically a a um a mix of those two. It's credential stuffing and kind of just you know basically dossing the login site with >> so in a way it is brute forcing. Okay. Yeah. I do have another question. You said you generated 10 million or 10 billion. >> Yes. >> Uh using your your uh your chat GPT Python script and yet none of those showed up in any breach logs. >> Isn't that kind of statistically impossible? I mean there's only so many variations you can get upon like eight or 10 characters. So surprisingly um I can I'll I'll show you the after the talk I'll show you the the stuff but

surprisingly I got nothing >> really >> and I was also like that's a bit strange because now my graph's kind of going to look lobsided and I was like these people are going to think that I don't know how to use PowerPoint or >> whatever clearly not working right they're clearly not guessing things. >> Yes. Yes. Yes. So yeah, but I I'll I can definitely show you. >> I believe I trust you. >> No worries. No worries. >> Any more questions?

>> Travis. >> Yes. Yes. >> This will be our last one. Thanks. What's your opinion on really like have I been pawned in those larger pod stores? How much value do they have really? Because the control is rate limiting people from attacking with scripts like this, right? And having policies around that because now we're telling in the defense of the end user, hey, all these words in in the alpha in the dictionary are can no longer be used because they were once used in a compromise. But they're not there. Some most of the time those are tied to specific accounts. So you only have one half of the equation from your for your attacking. So literally we're just

basically creating large dictionary attacks that we're saying you can't use all the words in the alphabet words in the dictionary user. >> Yeah. Yeah. No 100%. So it's kind of like we're making a big rainbow table if you want to call it. And I think that is that is something um you know we we need to I think communication when it comes to trying to tell people oh this password this password sucks this password's good you know that that type of thing we need to try and convey the message a little bit clearer like you said it's only half one of the equation so um have I been ped and all of that stuff uh I think it's

good uh I don't think I think you should take it with a grain of salt personally Um I don't think it's like oh my password's here you know. Um but I think that's why they brought out that uh what do you call it the the email address part of things as well like you put your email address and then you put the password kind of like a login like they're just taking your login for your email address but you know it kind of gives you that that two-sided picture. So I don't know does that answer your question? Is that is that okay? Yeah, you're helpful, but it's not. >> Yeah. Yeah. No, 100% 100%. >> You can leave it there.

>> Okay. Okay. Cool. >> Thanks everyone. That was uh that was also Travis's first talk at a conference this size. So, thanks very much for listening. If you had any questions for him, uh he's available afterwards as well. The next talk will be at uh 2 p.m. extending password insecurity to the browser. How malicious extensions are used to steal user password. So we've been talking about stealers in the previous talk. So we're going to also break that open a bit more now as well. So that's 2 p.m. from here. We look forward to everyone attending that as well. Thank you. Have a good break. [Music] Heat. Heat. [Music] Heat. Heat. [Music]

[Music] [Music] Baby, [Music] hey. [Music] There you go. [Music]

Hey,

hey, hey. [Music] Hey, hey, hey. [Music] Down. [Music] Heat. Heat. [Music] Heat. Hey. Hey. Hey. Heat. Heat. [Music] Heat. Heat. [Music] [Applause] Heat. Heat. Heat. [Music] Heat. Heat. Heat. [Music]

Heat. Heat. N.

[Music] Heat.

Hey Heat. Heat. Heat. N. [Music] Hey,

hey hey.

[Music]

[Music] Hey. [Music]

[Music] Heat. Heat.

[Music]

Woo! Wow! [Music] Heat. Hey, heat. Hey, heat. [Music]

[Music] Heat. Heat. [Music] Heat. Heat. [Music] Heat. Heat. [Music]

Heat. Heat. [Music] Heat. Heat. [Music] Heat. Heat. Heat. Heat. [Music] Heat. Heat. N. [Music] Yeah, [Music]

[Music]

down. [Music] Hey hey hey hey hey hey hey hey hey hey hey hey. [Music] Yeah, [Music] down down. [Music] Down

down down down down down.

[Music] I'm [Music]

[Music] Dirty. Bye-bye. [Music] Here [Music] you go. [Music] Heat. Heat. N. [Music] down. [Music]

Heat. Heat. [Music] Heat. Hey. Hey. Hey.

[Music]

Heat. Heat. Heat. [Music] Heat.

Heat. [Music] Heat. [Music]

Heat. Heat. Heat.

[Music] Heat. Heat.

Heat. Heat. Heat. [Music]

Heat. Heat. [Music] Heat.

[Music] Heat. [Music]

[Music] Hey, [Music] Heat. [Music] Heat. [Music] Wow. [Music] Heat. [Music]

Heat. Heat.

Heat.

[Music] Heat. [Music] Heat. Hey, heat. Hey, heat. [Music]

Heat. Heat. N.

Heat. Heat.

[Music] Heat.

[Music] Heat. Heat. Heat. [Music] Heat. Heat. [Music] Yeah, [Music]

[Music]

down. [Music] Hey, [Music] hey hey. [Music] Yeah, [Music] down down.

Down down down down down.

[Music]

[Music] by [Music] Heat. Heat. N. [Music] D hey. [Music]

Heat. Heat. [Music] Heat. Heat.

[Music] Heat. Heat. [Music] Heat. Hey, heat. Hey, heat. [Music] [Applause] Heat. Heat. [Music] Heat. Heat. Heat. [Music]

Heat. Heat. N.

[Music] Heat.

Heat. Heat. Heat. Heat. [Music] Hey,

hey hey.

[Music] Hey. [Music] Heat. Heat. N. [Music] Hey, [Music] hey hey. Heat. [Music] Heat. [Music] Wow. [Music] Heat. [Music]

Heat. Heat.

Heat.

[Music] Heat. [Music] Heat. Heat.

[Music] Heat. Heat. [Music] Heat. Heat.

[Music] Heat. [Music] Heat.

Heat. Heat. [Music] Heat. Heat. [Music] Heat. Heat. N. [Music]

Yeah,

[Music] down. [Music] Black [Music] hey yeah hey yeah hey yeah hey yeah hey yeah hey yeah hey yeah hey yeah hey yeah hey yeah hey [Music] Yeah, [Music] down. [Music]

Hey hey hey.

[Music]

[Music] [Music] Heat. Heat. N. [Music] Hey, hey hey. [Music] Down. [Music] Heat. [Music] Heat.

Heat. Heat. [Music]

Heat. Heat.

[Music] Heat. Heat. [Music] Heat. [Music] Hey Heat.

Heat. Heat. N.

[Music] Heat.

[Music]

Heat.

Heat. Heat. N. [Music] Hey,

hey, hey.

[Music]

[Music] Hey. [Music] Heat. Heat. N. [Music] Hey, [Music] hey hey. Heat. [Music] Heat. [Music]

Wow. [Music] Heat. [Music]

Heat. Heat. [Music] Heat. Heat. [Music] Heat. Heat.

Heat. Heat. [Music] Heat. Heat. [Music] Heat. Heat.

Heat. [Music] Heat.

Feel

[Music] down. [Music] Yeah, [Music]

down. [Music] Hey, hey hey. [Music] Yeah,

[Music] down down. [Music] Down

[Music] Hey hey hey. [Music]

[Music] [Music] Heat. Heat. N. [Music] D hey. [Music] Down. [Music] Heat. Heat. [Music]

Heat. Heat.

[Music]

Heat. Heat. Heat. [Music] Heat. [Music] Heat. Heat. [Music] Heat.

Heat. [Music] Heat. [Music] Heat.

Heat. Heat. Heat. [Music]

Heat. Heat. N. [Music] Hey,

[Music]

[Music] hey hey. [Music] Heat. Heat.

[Music] Heat. Heat. [Music]

Wow. [Music] Yeah. [Music] Heat. Heat. N. [Music]

Heat. [Music] Heat. [Music] Heat. Heat. [Music] Heat. Heat.

[Music] Heat. Heat.

[Music] Heat. [Music] Heat. Heat. Heat. [Music]

Heat. Heat. [Music] Yeah, [Music]

[Music]

down. [Music] Hey, [Music] hey hey. [Music] Yeah, [Music] down down. [Music] Down

[Music] Hey hey hey. [Music] Heat. Heat. [Music] Heat. Heat. [Music]

[Music] down. [Music] Baby, [Music] doo. [Music] Here [Music] you go. [Music] Hey, hey hey. [Music] Heat.

[Music] Heat.

[Music] Heat. Hey. Hey. Hey. Heat. Heat. [Music] Heat. Heat. [Music] [Applause] [Music] Heat. Heat.

Heat. Heat. Heat. [Music] Heat. Heat. N.

[Music] Yeah.

Heat. [Music] Heat. Heat. N. [Music] Heat. [Music]

Heat. [Music]

[Music] That's [Music] true.

[Music] Hello. [Music] Heat. [Music] Heat. [Music]

Wow. [Music] Heat. Heat. Heat. [Music]

[Music] Heat. Heat.

[Music] Heat. Hey, heat. Hey, heat.

[Music] Heat. Heat. N.

Heat. Heat. N.

Heat. Heat.

[Music] Heat. Heat. Heat. Heat. [Music] Heat. Heat. N. [Music] Heat. Heat. N. [Music]

Yeah,

[Music] down. [Music] Hey, hey hey. [Music] down

down [Music]

down down down down down up.

[Music] Woohoo! [Music] Bye. [Music] down. [Music] Heat. [Music] There you [Music] Hey. Hey. Hey. [Music]

Heat.

Heat.

[Music] Heat.

[Music] Heat. [Music] Heat. Hey. Hey. Hey. Heat. [Music]

Heat.

[Music] Heat.

Heat.

Heat. [Music] Heat. [Music]

Heat. Heat. Heat.

[Music] Heat. Heat. [Music] Heat. Heat. [Music] Heat. Heat. N. [Music]

Heat. Heat. [Music]

[Music] Heat. Heat.

[Music] Heat. Heat. [Music]

Wow. [Music] Yeah. [Music] Heat. Heat. N. [Music]

Heat. Heat. [Music] Heat. Heat. [Music] Heat.

[Music]

Heat.

Heat.

[Music]

Heat. [Music] Heat. Heat. [Music] Heat. Heat.

[Music] Heat. Heat.

[Music] Hey feel down. [Music] Yeah, [Music]

[Music] down. [Music] Black [Music] hey yeah hey yeah hey yeah hey yeah hey yeah hey yeah hey yeah hey yeah hey yeah hey yeah hey [Music] Yeah, [Music] down. [Music]

Yeah,

[Music] Heat. Heat. [Music]

[Music] During

[Music] Baby [Music] doo doo. Here [Music] you go. [Music]

Hey,

hey, hey. [Music] Hey hey hey hey hey hey hey hey hey hey [Music] hey. [Music] Down. [Music] Heat.

Heat. [Music]

Heat. Heat. [Music]

Heat. Heat. Heat. Heat. [Music] [Applause] Heat. Heat. [Music] Heat. Heat. [Music]

Heat. Heat.

[Music] Heat. [Music] Heat.

Heat. Heat. N. [Music]

Heat. Heat. N. [Music] Heat. Heat. N.

Heat.

[Music] Heat. [Music]

[Music]

Hey, [Music] Heat. [Music] Heat. [Music]

Wow. [Music] Heat. [Music]

Heat. Heat.

Heat.

[Music] Heat. [Music] Heat. [Music] Hey, heat. Hey, heat. Heat. Heat.

[Music] Heat. Heat. [Music] Heat.

[Music] Heat. [Music] Heat. Heat.

Heat. Heat.

[Music] Yeah, [Music]

down. [Music] Hey, hey hey. Yeah, [Music] down. [Music] down.

Hey hey hey. [Music] Heat. Heat. [Music]

[Music] by far. [Music] down. [Music] Baby, baby. [Music] There you go. [Music] Hey, hey, hey. [Music] Heat. Heat.

[Music]

Heat. Heat. [Music]

Heat. Heat.

[Music] Heat. Heat. [Music] [Applause] [Music] Heat. Heat. Heat. Heat. N. [Music] Heat. Heat. N.

[Music] Heat. Heat.

Heat. Heat. N. [Music]

Heat. Heat. [Music] Heat. Heat. N.

Heat.

[Music] Heat. [Music]

[Music] Heat. Heat. [Music] Wow. [Music] Heat. [Music]

Heat. [Music] Heat. [Music] Heat. Heat. [Music] Heat. Heat.

[Music] Heat. Heat.

Heat. Heat.

[Music] Heat. Heat. Heat. Heat. [Music] Heat. [Music] Heat.

Heat.

[Music] Heat. [Music] Yeah, [Music]

[Music] down. [Music] Hey hey hey yeah hey yeah hey yeah hey yeah hey yeah hey yeah hey yeah hey yeah hey yeah hey yeah hey [Music] Down [Music] down down down down [Music] down down down down down down down down down down down down down down down down down down down down Yeah,

[Music]

Hey, [Music] hey hey. [Music]

[Music] [Music] Baby, [Music] baby, baby. [Music] Here [Music] you go. [Music] Hey. Hey. Hey. [Music] Heat. Heat.

[Music]

Heat. Heat. [Music]

Heat. Heat. Heat. [Music] Heat.

[Music] Heat. Heat. Heat. Heat. N. [Music] Heat. Heat. N.

[Music] Heat. Heat.

Heat. Heat. Heat. [Music]

Heat. Heat. [Music] Heat. Heat. N.

Heat. Heat.

[Music]

[Music]

[Music] Hey, [Music] hey hey. Heat. Heat. [Music]

Wow. [Music] Heat. Heat. Heat. [Music]

[Music] Heat. Heat.

[Music] Heat

up [Music] here. Heat.

Heat.

Heat. Heat.

[Music] Heat. Heat. Heat. Heat. [Music] Heat. Heat. N. [Music]

[Music]

[Music] Those of us who are joining, we're going to be enjoying the talk extending password and security to to the browser how malicious browser extensions are used to steal user passwords. Before we hand over to our speaker or issue just some reminders um we like to of course thanks our bside sponsors the diamond sponsors Prisma cloud inventor and gold sponsors Adobe and project circuit breaker along with all the other sponsors and volunteers of course that make this conference possible. Cell phones. Please put your cell phones on silent so it does not disturb anybody else. And then also please note that the Bside's Las Vegas policy on taking photos is that you may not take photos of anybody

without their prior consent, including speakers and those who are attending. So if the speaker when he starts gives you permission to do so, you're welcome to or his content. If he doesn't, please refrain from taking any pictures. Um the talk is streamed live on uh YouTube and there will be recording so there's no need to record with our devices either. So we're going to resume uh passwordscon with extending password insecurity to to the browser. How malicious browser extensions are used to steal user passwords and I'll hand over now to orchest

[Applause] uh first of all can you all hear me including the folks in the back or you can take pictures but I'm not accountable if they go bad. That's I can't I can't help it. Um I want to start with a simple question. How many of you by raising your hands remember the cyber haven breach in Christmas of last year? Okay. So relatively low. So during this session we'll talk a little bit about how malicious extensions can be used to steal credentials, identity data, passwords and then we'll actually go back to that bridge and analyze it a little bit if we have time. A bit about myself. My name is Ores. Yes or is my

name and no my mom never thought that this will happen this conversation so people will ask me is that a real name it is a real name uh in the last 15 years I'm doing web security from every possible angle uh including offensive defensive projects for uh end companies honestly at any company that I've been to eventually it goes to something stupid employees do online so passwords and web are always a part of it regardless of how much identity security is progressing Uh during my career uh I was running uh the takedown of a large browser hijacker called fireball in 2016 and 2017 and uh for a couple of years I was doing a IR that led to the catch of

a couple of bad guys that had a really bad network security architecture on their on their behalf. So if you do bad stuff which is criminal, make sure not to deploy that on your own device because people can find you that. In today's session, we'll cover three parts. The first one is understanding a little bit about security threats about of browser extensions. So, we move from assuming you're all uh basics amateurs in extension security to understanding how it works. Then specifying that to identity security and password security. Eventually, we'll talk a little bit of what can you do with that regard. I'm an open book. Eventually, we'll have a Q&A. I'm open to any kind of question and

I'll try to put a little bit of examples from day-to-day life. So, that's what we'll do. And the benefits of that will be that we'll understand the risks posed by malicious extensions. Understand exactly uh the the specifications of attacks using malicious extensions. So in the context of passwords, which permissions, how do they get infected, how do they get in, etc., etc. as well with examples and talk a little bit about how can that be used to uh how can you use this knowledge to improve security within your organizations or if you guys are bad guys, how can you develop your malicious extensions better. So we will all improve today. Uh as introduction let's talk a little

bit about browsers and identities. Now I'm not good at design. So the presentation assume that what I should have done is upload it to chat and ask for improvements of visuals. So you'll forgive me. So we've seen some sort of an evolution in the last about 20 years a bit more than that from at the beginning avocado structure of organization where you had uh an outer shell a soft interior really juicy where all the data is in inside organizations had all access done inside a network. This is the fine days of NDR companies that I think within a couple of years will go extinct like dinosaurs. At that time access was limited to physical line

or virtual line. to a VPN or some sort of an IP range. Then more and more things moved outside of the organization to some sort of a basic uh authentication process without federation primarily based on host name. So a firewall or proxy would be able to recognize which destination is based on the site and there was no identity security. Those are the fine days of anti-ishing solutions and awareness training. In last couple of years, improvements to using 2FA, then MFA, then federation with ITDR, all kinds of identity governance, etc., etc. So, organizations today have all of their data pretty much outside. Authentication is done on multiple apps, multiple identities. A hostnip cannot specify a specific identity in a specific tenant

because on the same application, I can have multiple tenants. Me personally, I I can go to cetchup.com. I have a million accounts over there and all of them are communicating to the same address and many of them are using a personal identity. Some of them are federated, some of them are not. All very, very different than one another. So, the world has pretty much changed in regard to how we use identities at work. Now, with that regard, things affected also on the way that run in the browser. Now, this is a very simplistic process. When I sign into an application and I'm happy that you all see it because that will amaze you. I'm kidding. It's uh

basic I authenticate once and then in order to avoid being exhausted by authenticating again and again and again and again a cookie is being created in my browser. Uh now a cookie is a mechanism which is older than some of the folks in this room and the only thing in it that didn't change whatsoever. There is typically like a 32 characters or 16 characters token over there that says hey he is who he's claiming to be. Basically that's what it is. And then in order to avoid reauthenticating again and again that's the website is able to check that on my browser. Uh and then the assumption is that considering this for the validity of the cookie that sometimes

organizations manage and sometimes they don't. So you'll find some cookies existent for a couple of years like a store-bought candies and sometimes are existent for like a week homemade candies and then there is some sort of a security enhancement around that that includes encryption. Now this diagram is very simplistic because I'm lazy but basically the cookie is stored on the device but it is secure and encrypted from the device standpoint uh using the browser encryption mechanisms. That means, in other words, that other tools on my device are not supposed to see my cookies and their content on the device unless they find some sort of a key that the browser is managing or hiding somewhere. Then again, the traffic from

the browser to the application is also encrypted with some sort of a TLS key in the future, postquantum encryption, sci-fi, alien proof encryption. Regardless of that, in between inside the browser itself, it's all in clear text. Wild wild west. Everything over there is visible to anyone sitting inside the browser. So it can be a website but the website only sees its own cookies. So there is no cross site uh visibility and any other instrument that has access to the session. That means users and extensions because extensions see everything in real time. Um so pretty much you know organizations that not really know don't don't really know what's happening within the session have no idea. Now uh now in this month

in the upcoming versions of Chrome, Edge and Firefox, all of them will have an embedded AI. It took me about 8 minutes to say I for the first time. So uh so they all have some sort of an AI embedded inside of them with its own API. There will be something that can see that as well. So we'll see changes in what has access to those cookies and those credentials. We know also that Google is trying to make changes to this mechanism, but it's really hard because it's impacting user experience. Now that leads us to some sort of an insight that zero trust is dead in the browser because there is no real zero trust.

Whoever has my cookie can get in my behalf. No real validation, no real authentication. You don't always suspect or whatever they say about zero trust. And that there are a lot of like loose ends to that mechanism. For example, password managers in the browser. Not all malicious not all bad extensions are malicious. Some of them are just doing something unintentional. Profile syncs. uh profile sync can extract passwords. A nice example that I found over Reddit, a great place to find cases for security is a sock analyst reporting that they found a key logger extension on one of their browsers fetching credentials. Apparently, they had an employee who was suspected by her husband to be cheating.

So, he deployed on her home device a key logger to collect all her data including all her passwords so he can sign in into her uh apps and see what is she's doing. And apparently that uh password manager got synced to a work device fetching all the credentials from the work applications. So this functionality is a functionality. It's not evil by design. It's just there. And then you have by as well that may affect that as well. In any case, we have a problem. Okay. So on the background authentication, access all of that is really improving. But all the improvements we're making are pretty much a still going to the same uh bottleneck because all those factors of

authentications we add all happen within a web session and once they're being approved there is a cookie in the browser. So we're pretty much putting more and more and more and more and more power on the same failed mechanism inside the process between the user and app. Are we good so far? Are we scared? Perfect. Okay. Okay, so now let's talk about the other side of it, extensions and how can they be the really awesome weapon to uh to do really powerful things. So first of all, what is an extension? An extension is a piece that's being added to an application or a browser in our case that's running in the browser in an agentless manner. What

does that mean? It means technically that if I open my uh dev tools and look for an extension, it will be non-existent in in the eyes of the device or the edr. So my craft strike will not see cookie stealer uh stealing cookies. It will see Chrome touching a cookie on its own cookie repository which seems really really really benign. Uh it means that whenever the browser is on all the extensions are always on and when the browser is off it's also off because of the fact that the extension is only there to fetch data from the browser. We are fine with the fact that it's aless. Now it has both an agent and a network

functionality. What does that mean? that there is one memory unit that it has which is persistent as long as the browser is on. Uh in the last couple of years across I say like hundreds of customer environments only once I got asked by customer what happens when the browser is off. Out of all of those organizations we met only one organization had the exotic scenario in which a browser is off internally. Actually we were so surprised by the question that we went opened up a lab to check what happens when the browser is being launched because we just assumed that the browser is always on. So also in that case whenever the browser goes on the agent piece immediately starts.

The browser extension also got a network functionality which is a fancy word for able to inject code into any website. Then it has a visibility to unencrypted traffic and data of the browser. So it means that whatever improvements existing or happening in browser security or networking whether that's postquantum encryption, enhanced encryption, an enterprise browser with with its own fancy encryption mechanism, it doesn't really matter inside the browser. It's a really uh it's a really you know crazy party where all the data is visible to everyone. Uh it can use or abuse browser access and visibility. We won't talk about that today but all kinds of permissions for the browser extension. for example, uh it's very very elementary for a browser

extension to get access to the download folder of the browser. In many cases, that's where all data is being stored and there is even a permission that some extensions have to enumerate the file system of the device. So in theory, some malicious extensions can actually run over the device itself, steal data, can listen to traffic fields. Uh we just released a research about the ability to sniff traffic from prompts. So they can s do anything that uh a power user can do in the browser and over time that's very important. So I come from malware analysis with malware analysis we check hashes or fuzzy hashes and all kinds of rules. So we are assuming that something is

similar within different versions of the same payload that doesn't exist in extensions. Extensions got only two things which are definitive in their existence. One is the ID. The second one is who has it installed. What does that mean? Jared here from Larex is a great guy and if he develops some sort of a productivity extension um that is behind it will have an ID. It will have you know hundreds of thousands of installations. Let's say that I buy his extension on the dark web and I can change the content, I can change the name, I can change the code, I can change anything. It wouldn't matter. It will still be running on the same devices with the same ID. So once

someone for example approved it once, it will stay approved forever. This is what attackers are doing. With that regard, we talked about the cyber driven breach. When attackers are taking over the admin account of a Chrome developer that has some sort of an extension, they can replace the entire code with malware and you know, nothing will trigger any kind of alert. It will just push all the code into the browser and no one will pay attention into it and nothing will trigger some sort of a a an alert because it's the same ID on the same browser and no security tool really cares. And that's the last piece of it which is a bit abstract. But when you look at the

permissions that browser extensions have, they're actually really really excessive. And some people ask, "Holy [ __ ] why is Google allowing all this data for extensions that are deployed in a consumer environment like on the Chrome store? Why aren't they changing them? For example, cookie permission to raise a cookie permission. Why is that possible? Like who really needs that? It doesn't make sense to allow the consumer tool." This is really something which is not trivial. uh Chrome, Edge, Firefox, all the rest. They use extensions, but you don't see them. They use extensions that are embedded into the browser to do some things. Why? Because let's say that you run an operating system. You won't write all the code into the kernel that

will break things and people will cry. You'll probably write an executable or a DL. So that's exactly the equivalent. So even though you don't see extensions in the browser, there are some extensions over there that are made by Chrome to run on Chrome and they will come at the form of for example the sidebar of Copilot within uh Edge or some sort of functionality within Chrome and now with all the AI browsers will see that as well. So it means that Google, Microsoft, Firefox and others are dependent on the same permissions and this is why over time we actually see an increase of the amount of data being visible to extensions rather than a decrease. For example, now we have a new

permission prompt API. Prompt API will allow any extension to ask questions about an embedded AI running in the browser about who knows what like the devil knows what. Uh how is the user typically behaving? Uh is this password the real password of the user or not. Now I got an R&D team re researching what can we do with that. I'm pretty confident now in not as a nice hotel but somewhere else. There are bad guys asking themselves what can we do to improve ourselves using the same permission. So you get the point. The same way EDRs and malware typically run similarly. We won't talk about all those other crazy stuff. If you're interested, I'll leave this QR code for 5 seconds. You

can also find this online. You can take pictures whatever about all kinds of attack patterns with malicious extensions. Uh today we'll only talk about that in the context of passwords. So I'll be invited again to Bside for not creating false advertisement about this talk. All right. So extensions in environments um pretty much everywhere and there are a couple of reasons to why extensions are existent everywhere. Uh so the stats here show about the the frequency of having extensions in enterprises. Very few organizations don't allow extensions at all. And we're talking about organizations like Bank of America very very archaic even though it's a great organization. Why can't organizations prevent users from deploying extensions? One, political or

culture. Some users are expecting to have that. B uh password managers, productivity tools. Uh C, AI extensions. Four, sorry, number D, and that's the most significant ones. Web developers love extensions and they use them to test everything and they download them from GitHub and they don't even check what it is. It's pretty much like eating trash from the floor. They don't ask themselves, what is that really doing? They deployed it on their own browsers to test and emulate web applications they develop. And no one no one no one will ever tell a web developer not to try an application because before it's being released to the public. Now any kind of approach that's possible with

tools on the endpoint like an MDM edr etc etc don't know how to digest this. It's basically something that was downloaded from GitHub without any ID no reputation no data about this code constantly changing doing all kinds of shady stuff. Uh and even if you do a a find an ability to scan them or sandbox them, it's really hard to apply a policy that says allow these extensions only for developers. You need to have some sort of a very robust mechanism that don't exist in all organizations because those web developers will have four, five different browsers. In three weeks, they will have like eight different browsers with all those fancy AI browsers as well. And that means that

for IT security teams, it will be some sort of a cat-and- mouse game that they already give up on from day one. So they don't do anything about that. We know some organizations do but it's not really happening. All right. So we're scared about the fact it's there. Let's be scared about what kind of data they have access to. Uh 53% of all enterprise users have an extension with a high or critical level ever permission. Increase a dead compromise in which attackers took over the admin account of Cyber Haven, the best DLP vendor in the world, but don't have a very robust Chrome Enterprise uh admin consoles. They replaced several extensions about 40 with malware. We checked our

customers about 90% had one of them. It's really really easy to get extensions to the general audience. And then it doesn't really matter if you have, you know, one, three, four, five. A single extension can dump at once all your cookies. Uh jackpot. It doesn't really matter. You don't have to have some sort of a user involvement. 11% of users have an extension with cookie permission. So that means that one of nine users is vulnerable to complete identity theft and 15% of enterprise extensions of Chrome web store extensions have a scripting permission. That means that really easily they can get to passwords. Now there are all kinds of ways to get to passwords. With scripting you can do

things such as if you have a password manager you go to a password field. It says do you want me to pick up a password for you? Like it's really really excited. basically is just listening and waiting for you to do something on that field of a password. The same very very basic logic can happen with the malicious extension except it doesn't let you know it's there. Now who develops these extensions? Putting aside all extensions that are not coming from the Chrome web store that's web developers huge problem assuming that users download those extensions from a trustworthy uh source such as the Chrome web store. we assume that someone checked that uh we know that those checks are not very very

robust. A part of that is that it doesn't necessarily means that the extension is malicious per se. It can also be something you just don't want to have in your environment. A supply chain something that could be compromised or abused or being neglected and there are all kinds of extensions in the Chrome store that no one is using for a couple of years. In theory, I can write I can buy a domain uh that is associated with this extension. it's already expired and then just create the email address that's being granted to the admin account. I can do all kinds of things. It's really easy. Now, at some point in time, I instructed one of my analysts. I

told her, "Open a proton mail." In that proton mail, reach out to extension owners with 100,000 installs and above and say that you would like to buy anonymous leader extension and ask for a price listing. And basically what I instructed her to do is like behave like a drug lord when you communicating with them to see what are the ethical barriers that they have. And apparently like you know out of 30 a good side like a handful of them said I'm open to negotiate like they didn't have any problem and extensions with hundreds of thousands of downloads are not that common. So something with thousands or you know 10 thousands is easy to find. Uh from an attacker standpoint, by the

way, it's really easy to find out if they're deployed in enterprise environments or not because they get some sort of a flag coming from the extension about the device in which it's being installed. So if I buy an extension off the shelf that already got installed, I can create a report that says where is that existent you know uh and then probably you know 60% is individuals and then 40, you know, 30% is mom and pop shops and then 10% will be enterprise users and that's where the real money is. So over half of extensions are identified with a free Gmail account which is also a big security problem. For example, some security vendors uh associate their

extension with a a Gmail account that is not behind any security. Um 89% of extensions have fewer than thousand installs. So they're really hard to evaluate in terms of permission and 79% of extensions have a single extension for per publisher. So just imagine what it takes to apply some sort of a reputation service on that. So why are they such an effective attack factor? They're everywhere. They're harmless, like allegedly harmless. They never say what they do, but they get access to data that you don't want them to get access to, and it's really hard to control that. And they are invisible to existing toolings because existing solutions only see the ID. And as we said, the idea is not very

effective. Now comes the question, how do I get to have a malicious extension? I need to uh to get a compromised extension. So I can a develop one from the bottom up. Just create a malicious extension, sneak it into the chrome store, some sort of like a shashank redemption. I add a little bit of malicious code a day. Eventually it will become malicious and some guy a poor guy in Bangladesh that checks the code will not be able to, you know, to understand what I'm doing over time because it's so dynamic and it's really hard like it's happening all the time. I can just, you know, compromise a legit extension like happened to Cyber Haven, which what I

consider to be the prettiest attack of 2024, or just buy something uh on the dark web. Lastly, I can also silo an extension by malware. So, that's kind of like a disappearing attack vector, but there are all kinds of ways for uh malware to deploy extensions. We see some sort of a shift from extensions being used to compromise the device. Now things on the device are useless. Not entirely useless, but the email is more valuable. So you'll see an ext a malware being deployed locally to elevate permissions into the browser. And eventually this is why we see extensions all over the news. And like most people don't don't understand how powerful it is. Actually, it has better data access

than a malware. Well, enough talking about extensions. Now we'll talk a little bit about how extensions can get access to passwords. So we talked about different kinds of permissions. We won't cover all of them but extensions have all kinds of permissions that can be used in all kinds of ways to get access to passwords. Now in my imagination there is the attacker and there is the defender. The attacker wants to simplify his life. The defender wants to simplify his life and then every time they try to pick like less and less obvious permissions to try and do the same work in a different way exactly like malware. So on the most basic stuff, cookie permission, which is

pretty much game over because then I can with one line of code dump all the of the user cookies and uh get access to an application. You can fetch data about identities of the browser itself, password storage, client certificates. We can see all kinds of things. It can have full access to text inputs, clipboard data, a browser metadata would will catch u o ooth and sample c certificates. So everything that goes in the URI will be will be visible to an extension and all the content of a web page. Now I want to give you an example. We've done a research uh a year and a half ago about cookie theft for entra. So how to use an

malicious extension to uh compromise entra identities. And basically our PC was an extension that steals the cookie of Entra including the browser uh user agent and you know screen resolution which typically is enough to get in and then two days before the conference uh it stopped working and added some sort of a security mechanism. I'll let you guess what was the security mechanism. It was adding another factor something they hide in they hide somewhere in order to check if that's the real browser. Now at at that point in time there is some sort of a logical paradox. They want to hide another factor because they don't trust the cookie. Where can they hide something inside the browser? So they hide they

hidden another factor inside the browser cache. The cache is also something that's visible to the extension. So our researcher all that he had to do is to reauthenticate with Azure uh with Entra on one browser see exactly what's being generated. added one line of code to his malicious extension on the PC and then eventually being able to still get in. So it it took us five minutes to fix that. And every time they try to improve something, they just uh hidden another factor inside the browser. So it's it's a it's a fundamental problem that they can't avoid placing secrets where the extension has visibility to to them. There is nowhere they can they can go

and hide that we won't find them. And that's a big problem that existing controls do not provide. It's a fundamental problem. By the way, there is a solution not using SAS. It's a possible solution, but it's not people here are not here to talk about how to go backwards in time. Um, and here you have a list of, you know, key permissions that can be used in what way, but eventually if you if you'll go and search for extensions out there. It can be something like, you know, uh, dark mode for Grammarly or whatever, it can be something that sounds like, you know, really really simple coupon code for Amazon and you check their permissions. It's kind of

like, you know, reading the ingredients of a of, you know, Advil or some sort of a medicine that you're taking or reading the, you know, the back page. It's horrific. So, those permissions are everywhere because they use them for kinds of, you know, all kinds of things that they do. By the way, sometimes the developers just say, "Let's pick all the all the permissions now." Uh, so if we need them, we won't have to reapply on the Chrome store for new permissions. So, they'll ask for everything and if they get approved, they'll just keep on using that. So, that's very very significant. uh so they can get access to cookies, but there are all kinds of

other permissions. By the way, all the changes that Google made on manifest 33, it's a part of Google's strategy to fight uh ad blockers did not change whatsoever the ability to steal passwords. You can relax. Now, when we map that to TTPs, uh it really aligns perfectly well. So, let's talk about, you know, cookie theft. Most organizations assume that cookie theft is being done on the device using malware. That's a really really like that's a that's not the path of least resistance. That's really really hard. You need to deploy malware and that malware needs to find something on the device. Chrome is like running away from that. But an extension like you one of every nine extensions can get there. Uh

so that will be very simple just you know stealing the cookie. The beautiful thing is that the same extension can also uh replicate everything else. For example, it can detect if a user is now on the application. So someone may apply some sort of an impossible travel. It can check uh browser configurations. So, if you ever seen uh a cookie a cookie sale uh like uh like on the dark web when they advertise advertisement for a cookie on the dark web, they typically put the cookie together with screen resolution and a few other things. All of them come as a package like it's a bundle. It's like the fries and drinks together with a hamburger. All of those are very useful.

But now let's use uh now a survey. What is the average price of a malicious attacker's extension on the dark web? What would be the cost on average of a stolen cookie on the dark web? Let's, you know, who wants to guess? Let's take five people. Who wants to guess? What's the average price? >> 10 cents. >> 10 cents. Okay. No, it's not that free. That's a Come on. Say >> 50 USD. Okay. Five bucks. 50 USD. Who else? So, it's $10 in descending. So that's the only asset in the US which is inflation resistant and the price is going down over time because it's becoming easier and easier to get them. And what I learned in economy class is

that if it's becoming cheaper it means that the supply is becoming more uh prevalent. Then you have also other things that are a bit more complex about browser session hijacking which like there are million ways to do that but the best ways to do that would be from the browser. So when you think about it, the extension is there actually you can open up the same session in another tab but minimize it on the side of the screen. Like there are a million things you can do whether that's compromising uh you know mimicking the sample data on the URI or just man in the middle in the traffic. You can do you can do like a

million things. It's like really easy. I think the main difference between cookie theft and browser session hijacked that with cookie theft you don't have to wait for the user to do stupid. you can just do it in one line of code once and with uh a web session hijack you need sorry you need to wait for some sort of a user interaction uh and that's the the big difference okay let's continue

I have here another resource which is a mapping extension threat to MITER attack framework if that's interesting you're welcome to uh take a a or scan a QR code. Eventually, it's mapping all kinds of attack factors from the browser to that. I'd say that it's trivial for frameworks about extension security to already be aware of that because at the moment the number one payload of malicious extensions is stealing identities. In the future, maybe something else. Okay, so now the question is what can we do about that and how can we be more secure? So we have a couple of possible strategies and we'll evaluate them one by one. The first one which is the number one

existing strategy is an allow list and that means prevent installation if the ID of an extension is not in the allow list. So you remember we only know if there is an ID or not nothing else uh besides the ID nothing else is like nothing else matters. It means that there should be some sort of a manual or automated review. So a user needs to ask uh for approval to install an extension that needs to get to security somehow. Typically this problem scales at the size of organization because the distance between security and the end user is becoming more significant and then they can still be hit by a compromise or weaponized extension. Uh so the case of the cyber raven breach

that's a great example. It's a security tool that already has the best permissions in the world being entirely abused to steal all the cookies of the user. So that's the best possible strategy but it's really really labor intensive and still not very secure. Then the next one is a block list. um scan periodically and add ids to a block list requires robust scanning routine of all approved browsers and great way to waste time and still be compromised. So basically running a block list on extensions is pretty much like boiling the ocean um or emptying the ocean like the amount of work is unfeasible and eventually it's still very temporary because an extension can change and

mutate. It's really happening all the time even for us as a security vendor that we install extensions for all kinds of demos. we had you know malicious extensions arriving to our environment. It's really really really common to happen in all kinds of ways. Then uh the third one is no extensions at all. Um and there are some organizations that can do that and for them the problem does not exist whatsoever. What we see in real life that that doesn't really apply to all organizations. But you know uh I also met once a CISO that said that they are not allowing users to consume internet. And by the way these guys don't need any kind of tool. It's always correct that

if you avoid using some sort of a technology, you avoid the problem entirely. I think a couple of years ago before AI, it was easier to do that in the US market. Nowadays, I don't meet so many organizations that do that and many of them actually prefer to uh spend a lot of time uh to to deal with that in a manual process rather than filing users. Then the the last piece of it is risk based security. What does that mean? um you need to first of all audit all the all the extensions on all the browsers periodically because every new version of each extension uh may introduce a new kind of code. So it

means that you need to find all the browsers. It's kind of like a really uh it's a you know some sort of a mixture between you know uh Squid Game to Pokemon. You need to catch them all but like three times all the browsers then all the extensions on all the browsers and then all the versions of all the extensions on all the browsers and have some sort of a mapping of those. Then you need to be able to classify them based on risk. Also understand context because context really really matters. No extension will say I'm malicious. Most of them will say at best I'm really poorly written. I am full of CVAs. Uh I'm like eating something from the

ground. None of them really shouts to the world I am malicious. Many of them are just a real supply chain risk. Not all of them are malicious but most of them are just bad uh by nature. And then having some sort of a risk adaptive security rules. Now the levels in which you can get go are really outstanding. For example, if you have a lot of time, you can actually edit the browser configuration file and shut down specific extensions, access to specific sites. If you really have a lot of time for free, you can take care of the take care of this problem by restricting specific extensions on specific sites. You can uh identify specific host names

and prevent them from running on specific browser. You can shut down syncing. You can do all kinds of things. But the levels of enforcement you can get uh manually are outstanding. And then you get to all kinds of mechanisms such as you know uh the pitfalls, how do you get all the browsers, how do you make sure that all of them provide the same level of visibility. For example, Chrome and Edge have a free enterprise version. If it's free and it's fully SAS, it's good thing to use. Uh but Firefox doesn't have that. Brave doesn't have that. Opera for example, Opera prevents uh anyone from viewing its registries. So not all browsers are born equal and we'll see

the same habit also now with AI browsers. Some browsers try to hide themselves from the IT. So Duck Go, uh tour browser, Opera, some of them are just nasty. Um then you don't have like the same coverage. Some of them are coming from a third party store. All kinds of pitfalls. Then the risk classification I talked about that the pol polymorphism of extensions is a real problem. And then the enforcement is where both organizations claim to fail. And the reason is that it's really really really hard to combine a routine periodic scanning for each update of the browser with the MDM. In many cases, organizations claim that the reason is that they can't do whatever they want on

the MDM uh to run this scanning all the time. Erh, how do we help the the community? At Lex, we've uh released a resource called Extension Pedia. Extension Pedia is a a free resource for extension assessment. Where do we get the data? We have announced uh last week on a tech alliance with Google. So, Google is streamlining to us hundreds of thousands of extensions from the Chrome web store. And I intentionally say that because about half of malicious extensions are coming from outside of the store because it's easier to build it outside of the store. It's harder to get it to the destination, but it's easier to build it over there. So, we have a vast majority of the Chrome store

already scanned. You can submit ID and get some sort of a report about risk also with different kinds of criteria about the risk. And in summary, we talked today about browser extensions are everywhere. The threat service is everyone. Uh I think the prettiest piece of it from an attacker standpoint, I don't have to wait for a user to do stupid. Uh it can affect everyone. The fact that developers install extensions more than anyone is is an outstanding thing because I actually got a powerful uh population inside the organization that has access to very valuable systems running extensions more than anyone else. Actually, it allows an attacker to get exactly to the target demographics that typically is the most uh elusive

and that really really it's really really appealing to attackers that you don't have to wait for them to make a mistake. they're already looking for these extensions on the on GitHub and they use it for all kinds of sources which makes this an awesome killer uh functionality. Uh excessive permissions are everywhere. Uh most of them have excessive permissions and uh and in a way human identity is browser security as long as the browser is the vessel of choice for applications to store all the credentials and all the cookies. By the way, when you sign into Slack or Teams or whatever, uh, still they store their cookies and passwords inside the browser even though they're not in the browser.

So, the tiny window they open for authentication is actually inheriting from either Chrome or Edge depending on what's your uh default browser. Um, and there are all kinds of tools you already have that can be effective. It's really about balancing cost and manual work inside your organization. There are like a million ways to solve every kind of problem. Not all of them are right for your kind of organization. And that's it for now. I hope it was not too exhaustive, too, you know, boring. I hope you did learn something new today. And I I'll be happy to take questions if you have any. [Applause] >> Do you want to pick who to ask? >> Um, you can be random. I don't want to

be biasing anyone. Let's >> start over here. Hi, thanks for the talk. Um, a couple times you mentioned screen resolution uh in conjunction with a browser session cookie. So I was curious if um the SAS application is using that as like a second factor of authentication to identify the user or is it just an additional data point and why is that important for the authentication process? >> So under UBA effectively there is you know it's it says I use what I have. So sorry for a bad analogy. When I'm hungry at night, I open the fridge. I'm using whatever is there. And if I have leftovers of something, I'll use leftovers of something. What is the SAS

application got? Because it's not an IDP problem. It's an application problem. Uh once the provisioning is ended, uh and the cookies being generated, you know, co octa is off. It's not a part of the process. So the application asks itself, okay, what do I what have I got? I got the screen resolution, user agent, IP range is super, you know, false positive. uh you know it's uh it's horrible usage to use that some cases you can use a geoloccation but it's only if the user is approving that so they're trying to think what have I got always screen resolution um OS version and browser ID are the things that they have so from an attacker standpoint not to

mimicking that which is typically you know 24 in and the most up-to-date chrome of Firefox it's like the very basics of you know uh saying I care about my job I'm trying to do like a decent job it's not hard and that's a part of the complexity around that. So I'm using that you know it's any kind of data you can you have access to as a SAS developer. Now if you are PayPal for example as a sample vendor you look at you know anomalies of you know mouse movement and key you know key stro strokes most applications don't do that can they probably I don't know how easy or expensive or cheap it is for them to

do that effectively they don't

Uh thanks for the talk. That was great. Um you mentioned uh finding developers uh lol. So um developers that need access to uh extensions to do to do development work. What what kind of um best practices that actually work in organizations? Do you see like is it segregating uh like enterprise activity from development or is it uh doing like you said doing like very manual kind of allow listing per site like what have you seen that actually works when it comes to this? So the answer is yes, yes and yes. And Google is now releasing a new framework. Now is I'm not responsible. I don't really know when is now. It's like near real time. It can be

any any time. But they're about to release a framework which is an ability to deploy browsers for testing specifically some sort of a puppeteer or selenium uh that you can load extensions a very specific way that's supposed by design not to have a GUI. So the chances of you know you you know uh making mistakes. You know they're trying to make that the you know kitchen drawer will be very uncomfortable to store you know I don't know uh weapons or whatever. So you don't mix you know your work stuff with your personal stuff. Uh they're trying to make some sort of a UIX distin distinction. So you developers will not do it on their own

browsers. It will minimize the problem but not solve it entirely. Okay we've got time for one more.

You may have mentioned it. I came in a little late so I apologize. How do you see manifest v3 versus v2 impacting the security of these extensions and the problems that you have seen? >> Um the changes are not that significant uh for a for an attacker. changes mostly affect the ability to control the user experience within the session. So, it's not a big deal. I would say that if you find some sort of an MV2 extension in your in your environment, those extensions cannot update anymore. Extensions do inherit third uh library third party libraries and actually all those CVS are being inherited by sites that are affected. So in a way it's kind of like you know opening another door to

the browser that you know browser exploits are something that people really are scared about. So it's just you know bad bad habits in terms of development to use that. That's what I'd say. Aside from that from an attacker standpoint there is no much of a difference because the some permissions were left and some were added. So all in all as an attacker I feel like my conditions are pretty much the same. But any other kind of attack vector has become more you know more complicated. So you know fishing is really hard harder, malware is harder. So I'm going always to the path of least resistance. And this is why I think we see more and

more attacks coming in the browser itself because not because it's became uh easier just because the alternatives became significantly harder. >> Okay, thank you very much. >> Thank you very much everyone. >> Unfortunately that's all we have time for now. But um if you have any further questions I'm sure or will be hang hanging around here. You're welcome to come and see him. And then the next password con talk will be at 5, the HMAC trap security or illusion. Thanks everyone. [Music]

Heat. Heat. [Music]

[Music] By far down. [Music] Baby, [Music] baby. [Music] There you go. [Music] D. [Music]

Doo.

[Music]

[Music] Heat. Heat.

[Music] Heat. [Music] Hey. Hey. Hey. Heat. Heat. N.

Heat. Heat. Heat. [Applause] [Music] Heat. Heat.

Heat. Heat. [Music]

Heat.

Hey, heat. Hey, heat. Heat. Heat. [Music] Heat. Heat. N. [Music]

[Music] Heat. Heat. [Music] Ooh.

Hey. Hey. Heat. Heat. [Music] Heat. Heat. [Music] Wow.

[Music] Heat. Heat. Heat. [Music]

[Music] Heat. Heat.

[Music] Heat. Heat.

[Music] Heat.

Heat.

Heat.

[Music] Heat. [Music] Heat. Heat.

[Music] Heat. Heat. [Music] Heat. Heat. N.

[Music] Down. [Music]

[Music] Hey. Hey. [Music] Okay, so we are back. Um, the next Passwords con track is ready to start. So, we'd like to welcome everybody to this track. Uh a reminder about our sponsors, uh Diamond sponsors, Prisma Cloud and Vant, and our gold sponsors, Drop Zone AI and Simgrip, and them along with all the other sponsors and volunteers. Again, thanking for uh all the uh sponsorship and the work and the effort that goes into producing this conference um and passwords con being possible as well. Just a reminder about cell phones. Please put them on silent so that we can uh pay full attention to what'll be presented this afternoon. And then also uh when it comes to photos, so

the the B sounds Las Vegas photo policies, no photographs of any presenters or uh uh content or attendees unless the presenters give permission. So these presenters don't mind if you take photos of them or their content. So you can but please no photos of any of the attendees uh in this room or anywhere else and there's no need to record it is being recorded for us already. So hazard analysis of military AI systems using STPAC a systems theoretic approach to secure and assured autonomy by Dr. Josh Hargus and Chris Ward. They're now up. Let's see what it's about. >> Thank you. [Applause] Thanks everyone. Um, so my name is Josh Hargus. Uh, so myself and Chris Ward run

a small consultancy called Fire Mountain Labs. Uh, we do AI and AI security consulting. Uh, something that we've been working on is trying to to uh, kind of adapt some of the frameworks that are out there for other purposes to use for AI security and AI safety. Uh, my background, we just started this back in April. Um, I was the chief of AI security at Cranium, an AI security company. Uh before that, MITER, before that, Navy research, been doing AI for almost do like two decades. I'll let Chris do it. >> Hey, Chris Ward. Welcome. Um I'm a Navy veteran. That's where I got my start in security. I was like a radar guy, but

you can't be in the military and not learn some security. Uh so got out of the Navy, got a degree in electrical engineering. That's where I started thinking about like processes and and system analysis. Uh met up with Josh at a lab called Spaywar, which is now defunct and called Naval Information Warfare Center. Uh, but that's where we started looking into AI security and how to apply this kind of stuff to AI systems. >> Cool. >> All right. So, if you haven't noticed yet, this is has nothing to do with passwords. Um, so hopefully that's uh clear to everyone right off the beginning. >> If we get to the end, you're like, I know how this connects to passwords.

Let's talk about it. >> We would love to know. >> So, bluff, so AI systems can fail without actually breaking in kind of traditional ways. Um so what we're looking at is is uh you know ways that are that are a little bit non-traditional. So traditional failing analysis is not sufficient for AI because of this. So STPA sec we'll get into that identifies hidden and systemic AI risks. Um and then it also uh proactively applies controls uh for safe AI. So quick outline. So we're going to get into the overview uh of of STPA some of that background. um STPA sec so the security kind of extension of that uh we'll go through a case study look at

identifying hazards for for these case studies applying controls and then we'll we'll leave you with some uh takeaways and a little bit of time I I hope at the end for Q&A if you have any questions while we're going though please feel free to uh interrupt so STPA is uh system theoretic process analysis uh so software's role in this complex uh kind kind of systems is definitely growing. So, STPA is is really uh kind of uh before software. So, it's been around for a very long time. Uh these traditional safety methods are kind of outdated for these modern systems. This isn't even including AI. So, that's that's kind of why this the SEC one exists. Um and then STPA offers kind of

a unique system level safety analysis that can be applied to systems extended to AI systems, which is what we're looking at here. Um, and then the other key part of this is that it can identify hazards beyond component failures. So, we'll get into what those hazards are and how to how to define those. So, software uh safety challenges. So, accidents can stem from very complex interactions as as I'm sure you know if you're from the software world. Um, software flare flaws are systematic, not random. uh traditional methods lack that ability to to you know make software safely uh and and analyze it. So and then formal verification is not really enough uh to to take us to where we need

to go for this. Um and so STPA is what really helps us link uh system and software safety. So stamp is another uh uh kind of process out there. Uh so it's system theoretic accident model and processes. So that's stamp. Um so stamp itself views safety as a system control problem. So if you're from a controls background, some of this uh might look familiar. Uh accidents result from inadequate controls um and interactions. Whereas STPA a little different uh it's hazard analysis from MIT identifies causal factors behind component failures. Uh and then really the goal is to prevent hazards. That's really the whole purpose of STPA. So some of the key concepts. So it's a hierarchical approach uh for system

analysis. Uh we'll get into some of these terms, but some of the key terms are loss hazard, unsafe control action. Very important part of this that we'll get to later. Um these unsafe control actions can lead to hazards. And so they're very important to identify and try to uh mitigate. Um, and then there's four types of these unsafe control actions that we've identified uh within STPA, and that's these four here. So, control action required for safety is not provided. So, they just didn't put it in. Uh, an unsafe uh control action is provided. So, it is it is there. It's it's known. Um, safe control action provided too early or too late. Uh, and then the last one is safe control action

is stopped too soon. So it's it falls into one of these categories when you when you build your kind of unsafe control actions for these hazards. Um and so you you figure out how to kind of c categorize that. Okay. So kind of wrapping up this section. So benefits and applications. So uh you know really focuses on the interactions among the components. Uh identifies missing feedback or decisions. Uh proactive risk development or risk uh management in development. So that's one of the key aspects of this is proactive versus uh you know after the fact um versatile across uh diverse software intensive systems including AI. So obviously it has to kind of be extended to AI but the whole point of

this is to capture very complex uh a software systems. Um if you know some camps out there that just say AI is software there's there's some truth to that. So we're extending some of this uh work for for capturing that. Uh and then there is an open source handbook and tool support available out there. There's a there's a ton of literature kind of on this topic. So moving into overview of STPA sec. So this is this is that extension from STPA into uh security. So again, you know, we're we're noticing the software is increasing role into new safety challenges. Uh kind of a repeat of some of the things, but traditional safety analysis is is, you know, often uh

insufficient for this new complex, you know, software uh system. Um cyber cyber security risks are also rising in complex systems. Uh and then finally, STPA sec integrates security into safety analysis. So it's trying to bridge those two things together. So some of the key concepts we mentioned these earlier. So loss is anything of value to stakeholders. So we'll get into specific ones but you can imagine this is where you really want to focus your energy uh if there's something that you are are you know viable to lose uh that is very important to you. Uh SBA also expands losses uh to include security uh concerns. So not just things of value but actual uh you know just purely

security items. And then a hazard which we'll talk about some examples is a system condition leading to a loss. So there's a connection there between hazard and loss. Um and then finally the the framing the problem framing defines analysis purpose and context. So these are kind of the the main concepts. Um, now we'll get into some of the scenarios and talk about a little bit more specifically how this applies to kind of AI systems. So there's the UCAs and scenarios. So So again, this is that um I already lost my place. So UCAs are are the controllers actions that are that are leading to these uh hazards. So four types. We already we already covered those types. Um focuses on

unsecured control actions. And really what we're trying to get at is these scenarios drive how these UCAs arrive. That's that's really the key part. And then you can translate, you know, some of what we build here into your own systems and systems that you're going to be working on in the future. Um accidents stem from these uh systematic failures and interactions.

So some of the benefits and uses um so it really focuses on these complex interactions. we've kind of talked about that um it's proactive uh for the development side uh broad applicability across diverse systems. Uh we talk about this open source handbook uh that's also available. So STBA SEC is also welldeveloped well known out there and and now we'll kind of talk about how you bridge that piece into into these AI uh systems. So case study we'll we'll dig into a little bit more more detail here for uh AI decision support systems. Um, we've got two that we'll we'll go into. So, challenges of AI systems. Um, sure everybody in the room is is really

starting to think about what these challenges are. It's not magic. It's not going to solve all of our problems. Uh, it is very powerful. Uh, but you know, what are what are the things that we need to be concerned with? What are the things we need to start analyzing from a security perspective? Um, so modern systems are increasingly software intensive and complex. uh clearly uh traditional safety analysis again uh in the AI space uh falls short and then there's new you know emergent behaviors there's there's all sort like uh hallucinations there's all sorts of things that are that are new from this AI space um that are a little different from kind of your traditional software

security uh behaviors um and then our focus here on these case studies is this AI decision uh support system >> uh so Josh had a really good point there. We're really thinking about emergent behavior. So, this is a planning tool. Um, and it's focused on the mission and business level, not component level failures. So, if a hard drive goes bad, what happens to the AI? We're not thinking about that here. Um, we're not thinking about like an AI system necessarily that has levers like training a model, right? We're thinking about what happens when you take an AI model and you put it out in the world with uh in the wild where there's other uh objects, people, you know, weather,

environmental conditions interacting with uh either this autonomous system or artificial intelligence agent. Um so that's where STPA really thrives uh is looking at these emergent and complex interactions which is perfect for AI. Uh it's totally living at this mission business level, right? We have mission objectives. Let's see if an AI can handle it. We fire up some chat GPT, throw all our documents in it and something good maybe comes out. That's as coupled as you can get to mission business level uh with a technology. Uh so it's very important that we do analysis like this. Uh if you look at technical readiness levels uh which is maybe an arcane topic but uh it goes from like a transition level one to

nine. Um and then you do different kinds of testing all the way up at the ladder. So lower levels of the ladder, you're doing uh lab testing and then you take operational capability out in the world, you need to do operational testing. Um so STPA is a way to do that. It's a way to project and then we can also talk about how you might use it for red teaming and blue teaming. So quick quick quick thing I'll add is that um an interesting aspect of AI that's that's kind of new for for some of these uh systems that are out there especially at the operational kind of mission level uh is that humans are

going to start relying on AI to augment their role. So it's kind of like a human plus technology which is a little different from from the way we've kind of analyzed systems in the past. Um so having some sort of methodology like this that helps us do that analysis is is really important. Uh good segue. Like how many of you have seen this disclaimer like really really recently? It's in everything that has a an AI prompt, right? Uh in the DoD, you don't get to have bad days. You don't get to have an AI decision uh model like give you bad recommendations and then operator acts on those. So control actions here, right? I wanted to find an

image that really like told the story of control actions. So you have a human operator, you have some kind of autonomous bird in the sky that's taking these footage. That's a controller. Um, and then if you add AI into the mix, maybe an AI model is making a recommendation to this controller. This controller may not trust it and may not take action. That could lead to a loss. So that makes it unsafe control action. The operator could take the wrong action and you could have a greater loss. You could have a loss of life, loss of a military asset, loss of military secrets. Um, those are huge compromises that aren't acceptable in a DoD mission

space. Okay, so we've got a couple case studies we'll go through. We'll we'll kind of show the system diagram modeling of of what this looks like from a high level. I'll go into some of the hazards, uh, some of the use cases. Um, so this first one here is about an AI coding system. So, uh, seemingly something you would want if you're software engineered, you want, you know, some augmentation of your workflow. Um, so clearly LLMs are going to be a very critical part of of something like that in an AI system. Um, so we want to automate, you know, kind of the goal here is really automate repetitive coding tasks, generate code snippets. There's all sorts of other

things you could imagine you'd want to do with this uh AI coding system, but that's that's a clear uh benefit there. Uh you might also see proactive bug and vulnerability detection. Um some of you might be cringing at the fact that that's probably not true. Um but it is a thing that you could imagine being able to do versus having an engineer you know just sit there at the terminal and and you know type Python. You might be able to introduce some of these things. Um so bunch of bunch of system losses you can think about here. Um one of them is just inoperable or buggy code. Who's doing like vibe coding type stuff or real

coding with AI? >> Scaffolding. >> Okay. >> Scaffolding. Scaffolding. >> Just one, >> two. >> Wow. Okay. >> Okay. Okay. We got a couple. All right. Half dozen. >> Anybody sell their vibe going company for a million dollars yet? >> Okay. I see there. Um so kind of from a high level again uh a simple control diagram of of this AI coding system. Um so you know some of the components here controller would be developer another controller would be your agent plugin um IDE uh and then you get to uh kind of where where things live in the in the uh lower parts where you're doing log logging you're doing some feedback store and then you're

finally kind of doing a training pipeline. And so you might send a prompt to uh the agent plugin. That's that's your control. You might get a AI response back. That's the feedback from that agent plugin. Um kind of and so on. You see, you know, existing code, generated code coming from that uh agent plugin to the IDE. Um and so on. So this is kind of how you would start analyzing uh an AI coding system. Obviously, you could get much more detailed than this, but this is kind of a from a high level what you what you should be considering as a kind of starting blocks. I'll let you do this one. Okay. So, this one's uh kind of

predicated on like a government analyst or a DoD analyst using an LLM to gather open source intel. Uh so, LLMs are really fantastic at parsing through data. It's really easy them easy easy to point them at Google or like a rag database or something and say make sense of this for me tell me what I need to worry about in this giant pool of open source intelligence u well if you've ever used an LLM they are gaslighting machines and will outright lie to you uh could be a problem for an analyst that needs to do something actionable right um so immediately we can see kind of losses that that can occur that Um here's a control loop diagram uh for

such a system. It's exemplary. Um but what you have is again these controllers at various different points. Um this one has nice color coding. So the blue lines are control signals and the return lines are like sensor signals. If you think about it from terms of like an actuator, uh you maybe you have a pos excuse me position sensor and an actuator. Uh you sense a position, it returns the position. The act controller says I need you to move here. The actuator moves feedback circle happens and then when the actuator gets to the sensor's position, uh it stops. So that's the whole control loop. So that's what all this is modeling. control signals, feedback loops, and the thing that does

the action.

Okay, so kind of summary slide. So, you know, why why we'd want to apply STPA sec for AI systems. So, it actually does uh start to address this emergent behavior, non-failure risks in AI that are a little bit beyond the sort of normal complexities of of software. uh reveal systemata uh systemic risks from misaligned recommendations and feedback. We saw that in the in the diagrams. Uh we can explore diverse causal factors in AI system workflows. Uh we can proactively integrate safety and security into the system design u by looking at those diagrams and we'll see next uh how we uh dive into hazards. Um and then also it's applicable across kind of various uh complex anable AI

enabled systems. So, you know, we just gave two case studies. You can you can kind of go through the same process for sort of any AI system. So, identifying hazards. So, hazard identification and STPA. So, just from a from a high level back to uh basics of STPA. So, uh it's vital for complex systems uh because these hazards are are really what you're you're after. Uh traditional methods again fall short of of this for complex systems. Um, STBA is a modern approach that helps us uh integrate uh hazards and loss into into what we're trying to do. Uh, and it views it as a control uh safety as a control problem. So, defining losses. So, uh this all

comes back to stakeholder values. So, what what are uh the things that the stakeholders actually care about? What are they trying to protect? What are the things that they can't lose? um start by defining what are the unacceptable negative outcomes. Um you've probably done this in some sort of risk management uh type of way before um but this is kind of a a different way of of thinking about it. Um so losses you know especially for you know DoD missions as Chris was mentioning you know that can include harm to life property and environment. So um could be you know really really large uh things like that u but it could be things that are just important to your organization.

So modern systems uh add mission and data losses. Um and then we really want to use this to uh include the specific uh security lo uh losses. So not only thinking about kind of what the stakeholders value um but also putting in things that are very specific to security. So defining system hazards. Um so these are conditions that lead to loss. So that's really what the hazard is all about. So you want to start with defining these losses. U hazards exist within the systems control boundary. Um so you you can't really build a hazard for something that's outside of your system. You're trying to focus on what is covered by your system. Um what can

you do something about? Um focus on controllable system states for design influence. Um, and then you know there's some examples. We're obviously going to continue with the uh case studies that we had. Um, but they can include security and operational violations in addition to uh, you know, things that you're trying to protect from a a stakeholder perspective. So moving this to AI systems. So we want to establish control structure of the AI system. Um, so we want to model commands, feedback, decisions between humans and the AI. So we saw some examples of that. Um, especially in like the OSM one, the OSENT, uh, where there's an engineer, uh, somewhere in the mix that's a human and then there's

a system, an LLM, so interacting. So that's that's the scenario that we really want to kind of examine, uh, closely. Uh, and then we want to identify >> the power button. Is it coming back? All right. Yes. All right. Uh and then we want to identify critical system hazards. Um like inaccurate intelligence. I think we had, you know, kind of an example of that. Um but what are the really uh critical hazards? Uh could go back uh to some of the losses, but that's that's really what we're looking at there. Um and then you want to analyze these these UCAs, the unsafe uh control actions. um even from non-failures. So even in a case where it's not a drastic failure,

you know, I think the gaslighting is a is a good example. I think generating incorrect uh code is is one that could be very subtle, might not be seen as a failure. Um so you want to exam kind of kind of past that. Okay. Uh so let's look at this from that AI coding system perspective. Um so one system loss that we can consider that we talked about before is this inoperable or or buggy code. Um we might have inaccurate code generation and workflow uh uh errors as key hazards. Um so if we're reliant on the system to provide us with code that we're actually going to use on this real system um then you

know incorrect inaccurate code is is going to be a pretty bad hazard for us. Um and then AI unpredictability obviously creates this emergent and non-failure risks uh that are that are key to this analysis. So the control diagram uh we'll revisit that real quick. So we've got the developer agent plugin the IDE all the way down to your training pipeline. Um we kind of see uh from a high level you know what the interactions between these things would be. And now we're going to take a look at what that translates into from a hazard perspective. So these are not necessarily prioritized but these are these are some of the identified hazards. Um so agent generates incorrect vulnerable or

malicious code that the developer unknowingly accepts. Uh feedback and logging data expose sensitive or proprietary code obviously one uh that's very important. Uh prompt context includes misleading, ambiguous or incomplete information, degrading the model performance, obviously bad for future versions of that model. Um updates, we have cursors specifically, but you know any any sort of AI coding uh system. Uh degrades the functionality, introduces regressions or misalign with with what the user is actually trying to do. Uh telemetry collection could fail or is manipulated. uh and then the training pipeline might retrain on biased or lowquality feedback data from from the process that you're actually in instantiating. So all realistic hazards uh that need to be kind of enumerated uh to understand how

to protect against these. >> Sure. So I actually want to go back a slide because there's a really interesting attack that just came out. Um, so if we added GitHub on here, which uh these kind of tools have access to GitHub now, they can pull repos, they can make commits, um, they can clone repos. Uh, there's an attack vector where a readme in a git repository has an adversarial prompt. And so if you tell your AI coding app to pull that repo, clone it, you've now essentially jailbroken your AI coding assistant. And now you don't know what it's doing. So it could be passing API tokens, sensitive information, making unauthorized commits, uh super fun stuff. So what that would look like is

uh probably another controller that says GitHub hooked onto this IDE um and then ingest the repo adds it into your codebase. So without that extra box, you can't really do the analysis like Josh was saying. So we'd have to add that on. That becomes an extension of our system. Um so it's very important to capture that because uh that shows you parts of your attack surface uh that are available to the adversary. Um I don't want to spend too much time on this osent LLM. Um but you also need to we don't even have the control loop here. So you would need to go back to the control loop and that's how you start building out hazards. Um and then

the next step which Josh is going to talk about is start identifying the unsafe control actions. they're going to lead to those hazards. So, these could be because of accidental operation in the environment. It could be um unsafe control actions induced by an adversary to lead to a loss or it might be just something that you're considering like how do we put a control on this and how do we safeguard it so adversary can't come in and tamper with this control. Yeah, I think I think some of these are self-explanatory. you you can see, you know, one loss would might be the inability to categorize data accurately, which, you know, when when the analyst is actually relying on that information,

that may not be uh, you know, something that that you you want to happen. Um, so, you know, there's going to be lots of different hazards that kind of come out of that system. Um, so modeling uh control structure. So, uh, you know, we want to look at this from a hierarchical point of view. uh try to understand the system components and their interactions. Um define these control actions and feedback loops and then we really want to model uh these AI components explicitly as controllers. And so we've seen that in the in the past couple slides um where these AI pieces do actually control things. They actually have uh functionality beyond you know just receiving signals.

So identifying unsafe control actions. Um so we've we've gone over those four types before. Uh but we really want to define these clearly for the systems that we're talking about here and and for those hazards. Um and we want to do that beyond the component failures as that slide uh Chris showed a while back. Um we're not just operating at the component level. We're not just operating at the system level. We're at kind of the mission operational level. So for the AI coding system um kind of related back to th those hazards um so we have some identified ones here. So we have a control action and then an unsafe when some some something is done. So

developer accepts uh AI generated code um that could be fine uh but it's unsafe without proper review leading to the deployment of insecure or incorrect logic. So makes sense. Um but you kind of go down and you enumerate these. Um so we have for example you know we have a suggestion being returned uh that could be fine but if it's based on uh you know undated or relevant in info then that might not be uh you know what you want. Um all the way down to things like developer feedback um you know is applied to training uh could be great but but if you're not auditing that feedback if you're if you're not controlling who has access to give that

feedback to the model um then it could be incorrect feedback. It could be fe feedback that ends up in bias in the training data um etc. Um so these are all potential uh uh unsafe control actions based on some of the hazards that we identified. But you can see that as you kind of blow this up and start to build out the system diagram to you know really control uh use use everything uh that's in your system um as as a as a control point and a and kind of feedback. Um similarly Sorry. Similarly for the uh OSENT uh you know we have some uh nonfailure that leads to an inaccurate intelligence. We've gone through some

examples of that where you might get uh inaccurate intelligence or completely hallucinated intelligence. Um may not be uh a failure in a in a usual sense but that that might lead to a failure uh down the way. U we might actually see a situation where we're missing feedback. Uh that causes a misalignment between the model outputs. Um, and we're really trying to do this in a proactive way so that we can identify these risks as as soon as we can. Okay. So, the loss causal scenarios. So, we want to identify what these causal factors are for unsafe control actions. So, we're not just kind of identifying hazards, identifying these UCAs, and then, you know, calling it calling it

good. We actually want to know what what are the causal factors? How do you go from one thing to the next? Um so inadequate control algorithms can also lead to uh UCAs. Um inconsistent process models definitely that can be a significant factor. So you want to make sure those are correct and and uh detailed. Um missing feedback or incorrect uh inputs can also cause these issues. Um specifically to AI LLM uh insufficient training data can impact that. So uh that could be insufficient from a collection point of view specific to what you're trying to do. It could just be training data uh as a whole insufficiency. Um and then lack of confidence uh really uh affects this

intelligence uh workflow. So if you can't trust the data that's coming to you then obviously that's going to have a big impact on how you do your your workflow. So STPA for AI. So some of the benefits so it addresses AI's unique and emergent hazards. Um provides comprehensive causal analysis uh enables proactive design and integration of safety applicable across you know diverse complex AI systems uh by extending it all the way to to AI. Uh we can do this. Um and then it also integrates with various safety and security standards. You can bring in now you know what is what does this RM you know AI RMF say like what what do we have to what do we

have to think about when we're designing these systems security by design great tool to use in handinhand with something like this okay um so we're we're now at the place where we're going to be applying controls based on these these UCAs Yeah. So, we're applying So, we're going to transition from this hazard identification to risk mitigation. So, so we've identified the hazards. We're we're happy with the things that we've we've we've built there. Um, but now we want to try to mitigate against those. So, we want to apply controls to prevent these occurrences. So, we want to integrate safety and security into the engineering process. So, feed this back to the engineering team. Um and then we

want to develop uh inherently safe and secure systems as close to the left as we can possibly get. So core principles. So we want to enforce constraints. So safety is a control problem not just uh component failures. Um accidents result from inadequate control or uninforced uh constraints. Uh controls enforce these constraints preventing the hazardous states. And then safety constraints are critical boundaries for the system behavior. So you want to have uh some sort of constraints within the system of how you're going to uh do this analysis. So deriving requirements. So now we have these unsafe actions. We have we have these things enumerated. We want to derive a requirements. What does our system need to do in order to uh keep

itself safe uh from these actions? So we want to formalize the safety and security constraints. Those are the constraints from the last side. We want to create those boundaries. Uh we want to guide system design and implementation based on this information. And then we want to prevent hazards through these concrete requirements

and then formalizing the requirements. Um we want to formalize any sort of informal safety requirements that we have. um use formal methods like LTL for verification. That's for another talk. Um but then ensure rigorous software safety verification. So any place that we have these these hazards identified um where can we do something to ensure uh that we're doing the right things from a safety and security perspective uh in those hazards. Uh and then we want to bridge the gap to formal verification approaches. So we don't have to just end here. we can actually move what we've done analysis wise into formal verification and then safe behavior modeling. So we want to model this software behavior for

safety. So we can construct uh with designers and analysts. We can do this collaboratively. Uh we can focus on safety related variables. we can visualize using UML, other other types of uh you know state chart uh notifications, state machines, however you want to do it. Uh and then we incorporate these STPA derived safety requirements back into uh the the uh full plan. And we've done this kind of thing with people even in kind of a tabletop exercise kind of point of view. So even even something as informal as that can really inform a lot of of a lot of what this is uh doing. So generating safety test cases. Um so we can automate this uh uh we can do

this generation uh from an automated point of view. We can convert the model uh into testing tool input language. We can do uh suitability test coverage uh generate test data, remove duplicative tests, uh all sorts of things in order to generate these test cases. um might add we can use AI to do this. As long as we're doing this in a safely and secure manner, we can we can utilize AI for this software verification and execution. So we can verify the safe behavior model uh against those STPA requirements that we've formed. Uh we can assure that the model satisfies all of that safety criteria that we've we've set. Uh convert abstract test cases into executable scripts. So now we're moving

over into the actionable uh side of this. Run the scripts to validate software implementation and then link those test cases that we've built um back to the requirements for traceability.

Um so fun little image but uh you know one one thing you can do with STPAC that kind of building up to this is that you know wargaming mitigations. So addressing kind of intentional threats from adversaries. So that's that's kind of going back a few slides, but thinking about security as as really one of the hazards um one of the one of the uh what you really want to protect from a stakeholder point of view um against uh adversaries. So if there's intentional threats trying to model those, uh wargaming is a is a great uh mitigation tactic for that. Um, you can involve your red and blue teams uh to build this from a kind of simulated emulated point

of view. Um, and then you assess the effects and costs of those countermeasures. And then you're going to bring what you learn from that back into your your system design and analysis system level interventions. Uh, so I'm running a little low on time so I might run through this. So, we want to address hazards beyond the component failures, feedback paths. Um, really what we're getting to at the at the bottom here is we want clear accountability for any harms that might come to the system or to the users of the system. And then as always, continuous improvement and integration. So, we want to iterate this throughout the entire system life cycle. Not just at the

beginning, not just in the middle, not just at the end. You want to continue to do this um refine safety and security measures continuously. Uh we want to integrate with uh software and engineering standards and with those those teams um and support uh uh sorry future work uh involves tool support and automation. So um as this gets more adapted into the AI space, you can expect to see more tools uh being developed in this in this space. So a place where AI is definitely helping in STPA analysis is uh just enumerating and coming up with hazards that could cause an unsafe control action. That's usually a stage where you need like a few humans in a room like smashing their head

getting really creative. Um AI really helps you kind of like go through a bunch of plausibles and and see if you can get to these actions. And the hallucinatory as aspect of it was kind of a benefit in that regard.

Okay, couple quick slides on takeaways and then we'll open up for questions. So, um I think we've beat this over everybody's head, so maybe there's nothing to to continue on here. Um but one one is this risk compliance and governance. So, uh sometimes a complicated space that's very different from system design um but still needs to be integrated back into your your workflow. uh you can you can use this methodology to to bring those things in earlier. Um and so now early in your system design you're thinking about risk compliance and governance instead of towards the end. Um so you can derive detailed safety requirements from these UCAs. So that helps connect back um and

then address intentional security threats back to kind of that red teaming piece um and then enhance uh compliance with these industry standards that are out there. And with that we'll open it up for questions. [Applause] I thought it was interesting the point that you raised where the systems not trustworthy. I thought it was interesting the point that you raised that if the operator finds a system to be untrustworthy, not only are you then going to have the risks of the system causing damage due to bad logic, but you're going to have the risk of the operator failing to allow the system to actually do its job. >> Yep. So, >> yeah, I can give you a couple concrete

examples. Uh, the radar system I worked on, it didn't have AI, but it had like automatic gain control, which is very new at the time. And what it was supposed to do is, uh, adapt the filter of the radar automatically to filter clutter out. Well, if you turn this on, um, it sees a lot of clutter, so it lowers the gain all the way to the bottom. Nice clean screen, but you're not going to detect an inbound missile with a radar cross-section like smaller than a B. Uh, because your filter is so high. Um, we just turn it off and not use it. So, it didn't save us any time and it cost the Navy a whole lot of

money. um another system uh computer vision uh physical security camera detecting intruders, right? Um so the the DoD sponsor paid us to come in and do an analysis of how could this go wrong. There's a couple of specific adversarial attack vectors that we want to do analysis for. Um so one was injecting adversarial artifacts into an image stream. Another was creating these adversarial patches that you can like put on a wall and if the camera sees it, it suppresses object detections. So very effective. We do the analysis. Not only can you suppress detections, but you can actually create so many false positives that the user instantly turns the system off. So you just undermine the entire

security system. >> When situations like that arose, what did you do to regain trust in the operator once you had repaired the or improved the problem? So for that one, uh it kind of underscored that these adversarial patches are a huge problem in AI space and you have to control them somehow. There were no controls for that before. So if your system encountered this in a wild, it's a new novel threat. There's no control mechanism to suppress it or even deal with it. Maybe a human user would see it and be like that's a weird pattern. I don't know why it's making all these false positives. Um so now there's controls. You can do training on your model against those

patterns. You can detect the patterns, things like that to like alert an operator. You can um say that we have really low confidence in this detection, so maybe like don't use the system right now. Things like that. >> One one thing I'll add to that is that another thing we learned is that the system just wasn't robust enough. um it wasn't it wasn't built to not only not withstand these these patches that we built the adversarial pieces but once you started to dig into the system itself uh you could give it you know kind of noisy samples and it would fail miserably so it just it all the way came all the way back to like good TE and V&V

um so they needed to get back to the drawing board any other questions we've got time for one

That's all. Thank you very much. Thanks everyone for joining. >> Thank you. >> The next password contract talk will be at 5:00 p.m. The HMAC trap security or illusion. >> I think a professional person did pictures. [Music] Oh, [Music]

hey.

[Music] Down. Beauty. [Music] Boo! [Music] There you go. [Music] Hey hey hey.

[Music] Hey, [Music] hey hey. [Music] Ah hey. Heat.

[Music] Heat. Heat. [Music] Hey. Hey. Hey. Heat. [Music] [Applause]

Heat. [Music] Heat. Heat.

[Music]

Heat. Heat. Heat. [Music] [Applause] Heat. Heat. Heat. [Music]

Heat. Heat. Heat. [Music] Heat. Heat.

[Music] Heat. Heat. [Music] Heat. Heat. [Music] Heat. Heat. N. [Music]

[Music]

[Music]

[Music] Heat. Heat. [Music] Heat. [Music] Heat. [Music] Wow.

[Music] [Music] Heat. Heat. Heat. [Music]

[Music] Heat. Heat.

[Music] Heat.

[Music] Heat. [Music] Heat. Heat.

Heat.

[Music] Hey. Hey. Hey. Heat. Heat. [Music]

Heat. [Music] Hey. Hey. Hey. Heat. [Music] Heat. Yeah, [Music]

[Music]

yeah yeah. [Music] Black [Music] item. Yeah, [Music] down down down down down down down. [Music] Down

down down down up down.

[Music]

Heat. Heat. [Music]

[Music]

Data

baby. [Music] Heat. Heat. [Music] Heat. Heat.

Heat. [Music]

Hey Heat. [Music] Heat. Heat. [Music]

Heat. Heat. Heat. Heat. N.

[Applause] Heat. Heat. Heat. [Music] Heat. Heat. Heat. [Music] Heat. Heat. Heat.

Heat. Heat. N. [Music] Heat. [Music] Heat.

Heat. Heat. [Music] Heat. Heat. N. [Music]

[Music]

[Music] Hey. Hey. Heat. Heat. [Music] Heat. Heat. [Music] Wow.

[Music] Heat. Heat. Heat. [Music]

[Music] Heat. Heat.

[Music] Heat. Heat.

[Music] Heat. Hey. Hey. Hey. Heat. Heat. [Music]

Heat. Heat. [Music] Heat. Heat. N. [Music] Heat. Heat.

Yeah, [Music]

[Music]

yeah yeah. [Music] Keep [Music] it back. Yeah, [Music] down

[Music] down down down down down down down. [Music] Down. Down.

[Music] Heat. Heat. [Music]

[Music] Do you remember? Heat. Heat. [Music] Heat. Heat. [Music] Hey, [Music] hey, hey. [Music] Hello. Hey.

[Music] Heat. Heat. [Music] Heat. Heat. [Music]

Heat. Heat. [Music] [Applause] [Music]

Heat. Heat. N.

Heat. [Music] Heat. [Music] [Applause] Heat. Heat. Heat. [Music] Heat. Heat. Heat. [Music] Heat. [Music] Hey Heat. [Music] Heat. Heat. [Music] Heat. Heat. N. [Music]

[Music] Woo! [Music] Woo!

[Music] Heat. Heat.

Heat. [Music] Heat. [Music]

Wow. [Music] Yeah. [Music] Heat. Heat. [Music]

[Music] Heat. Heat.

[Music] Heat. Heat.

[Music] Heat. Hey, heat. Hey, heat. [Music]

Heat. Heat. [Music] Heat. Heat.

[Music] Heat. Heat. [Music] Yeah, [Music]

[Music] down. [Music] Hey hey hey. [Music] Down.

Down. [Music] Down

down down down.

[Music]

Heat. Heat. [Music]

[Music] Boo. Down. Heat. Heat. [Music] Heat. Heat. [Music] Hey, [Music] hey, hey. [Music] Down.

[Music] Heat. Heat. [Music] Heat. Heat. N. [Music] Heat. Hey, Heat. Heat.

Heat.

Heat. Heat. N.

Heat. Heat. Heat. [Music] [Applause] Heat. Heat. Heat. [Music] Heat. Heat.

Heat. Heat. Heat. [Music] Heat. Heat. [Music] Heat. Heat. [Music]

[Music]

[Music] Woo! [Music] Woo! Heat.

[Music]

Heat. [Music] Hey, [Music] Wow.

[Music] Heat. [Music]

[Music] Heat. Heat. [Music] Heat. Heat.

Heat. Heat.

Heat. Heat. [Music] Heat. Heat. [Music]

Heat. Heat. [Music] Heat. Heat.

Heat.

[Music] Heat. [Music] Yeah, [Music]

[Music] down. [Music] Hey hey hey. [Music] Down.

[Music] Down. [Music] Yeah.

[Music]

[Music] [Music] Do [Music] you don? [Music] There you go. [Music] Hey, [Music] hey hey. Heat. Heat. [Music] Heat. Heat.

[Music] Heat. Hey. Hey. Hey. Heat. Heat. [Music] Heat. [Music] Heat. [Music] [Applause] Heat. Heat. [Music] Heat. Heat. Heat. [Music] Heat.

Hey. Hey. Hey. Heat. Heat. N.

Heat. Heat. N. [Music] Heat. Heat. [Music]

Heat. Heat. [Music]

[Music] Heat. Heat. [Music] Heat. [Music]

Wow. [Music] Heat. Heat.

[Music] Heat. Heat. [Music] Okay, welcome to Passwords Con again. We're glad everybody is here. Just some reminders. Um, as we've announced before, we'd like to thank our sponsors, uh, Prismacloud and Vanta, our diamond sponsors, also our gold sponsors, Adobe and Sam Grip. It's along with their, uh, support and also the support of everybody including yourselves and all the volunteers and everyone that makes uh, this conference possible and thus passwords con possible as well. So, cell phones, if you have a cell phone on you, please put it on silent so that uh everybody can enjoy without any disruption. Um photos, uh please don't take the besides Las Vegas photo policy is not to take photographs of anybody

without their consent, whether they're a speaker or whether they're an attendee or whether they're inside or outside or whatever the story is. I believe the speaker said it's fine to take photos if you want to of her or her content. Um but anybody else in the room please don't take any pictures that includes anyone else without their consent. HMAC uh yeah we use it everywhere. I think many of us think that we are quite good at how we've secured it. So looking forward to this talk especially the HMAC trap security or illusion. So we'd like to invite to handle this part for us. >> Thank you. Hello everyone. Um, so today we're going to be talking about HMAC.

Um, is something like he said is everywhere and we use it quite often even though we sometimes don't realize that that's the thing. Um, so let's go ahead and just get right into it. So my name is Marloan Clear, but I also go as better to remember that way. Um, um, currently I'm a penetration tester. I love to find out how to break into things, how to fix things. Um, and I also, um, like to share that knowledge in a blog that I host on hexbadheads.com. And this content will also be up there. So, if you guys want to take pictures is fine. U, but other than that, it will be uh, available later uh, tonight.

So, I love the beach. I'm from Puerto Rico, so that is my go-to. Love sushi and yeah, pandas. So, that's my spirit animal. So that's a little bit about myself. So today what we're going to be talking about is a little bit about what HMAC is. I will have some demos. Um they're actually pre-recorded videos because I didn't want to test the demo gods on this today. So we're just going to go ahead and have the pre-recording parts. And then we're going to go over a little bit of best pract uh best practices, what things you guys can do whether you're a developer or um in any realm on the cyber security field, what things you should be looking out when it

comes down to HMAC. And then towards the end, we'll have some takeaways and questions that you guys may want to ask me. So out of every single topic that I can possibly have, why HMAC? So like the quote says there, security is not a product, it's a process. So before I became a penetration tester, I was a system security engineer. And my job was to go through the designing phases of a system and trying to figure out what is the best way to make them cyber security resilient and secure. Now I go to work one day and my client says you need to sit in this me in this call and see what is going on with HMAC.

And at that point I did not know what it was. I'm being quite honest about it. And um so I sat down and it came down to three things at the end of that meeting. Can we do we have to implement it? Can we accept the risk and not have it? or if we do have it, how long is it going to take for us to have it implemented? Now, what it became just a research of a high level overview of the threat landscape with or without it. It became like a challenge for me. So, I needed to understand okay if I how hard is it for somebody to implement the HMAC, right? Is it going to be just

a few lines of code? Is it going to break something else? So, I needed to take it upon myself and figure that out. So before I did all of that, I needed to find out what HMAC was. So we know what MAC is. So the message authentication code is a short string of bits used to verify the integrity and authenticity of a message, right? So a message is generated with a share key between the server and the client and that message alongside with the share key creates the MAC value. Right? So unlike hashes, the MAC has a better resistance when it comes down to tampering um because it requires a secret key in order for it to

work. Um it also ensures the integrity unlike the digital signatures you will always know who sent that message based on that. Now we know what MAC is but what is HMAC right? So the HMAC also attached the hashing function which I'll show you guys here in a minute. So we have here the sender, right? It's going to have the same share key between them and the receiver. We have the message and the combination of the share key and the message creates the MAC value. Once that message is sent over to the receiver, if they if they do match, that means that the data has not been altered. So the receiver end will go ahead and use that same key and that

message and make sure that the value that he received is the same. If it doesn't match, then that means that the data has been altered. And well, there's a problem. You either have two things that will happen. either the data packet will just drop or you have to go ahead and reinitiate the transformation of that data set again. So HMAC comes along. So Hback is just adding the hash base into the cryptographic function for Mac. So this will just have any cryptographic hash that you want to implement into it and then it will just go ahead and generate a code and send that over um alongside with the message. So why is it important? The HMAC just

ensures the confidentiality, right? It's ensuring that all the sensitive information that is going to be accessible only for authorized systems. It also maintains the integrity. So all the data that has been sent is not being modified by nefarious people. And then it guarantees the availability that once it is actually what is intended and it goes where it needs to be uh that you're going to get that message. So in this case HMAC how does it work? So we have Alice here because she's the the person of this year and she wants to send a message to the Matterhatter, right? So she has her message and she has a key that she shares with the matatter. Now once she's done with the

message, she's going to go ahead and attach the hmat value into the message. It's going to send that over. Once that um message is received by the MA header, if the secret key um is going to compute the HMAP value that came alongside with the message. Once that is done, um, if it is good and has not been altered, everybody's happy, everybody can see their message. If they don't, then that means that there's some type of tempering going on. There's a mismatch between the values, probably some um logging and and troubleshooting might have to happen, but you know, we never know. So, um, that is one of the main things that we need to be very

careful about it. So things like the TLS will also use HMAC when it comes down to the authentication and the mismatching um and the rejection of connections if they don't match. So once I have all that information send it over and in my brain I needed to figure out okay how do I make this work? So I created a simple client and server uh Python environment in my home lab right and then there's four things that are very critical when it comes down to implementing HMAC. Uh one of them you need to import the HMAC library. You also have to make sure that once you do that you select the hashing algorithm to import. So the hashlib in this

particular scenario is just important in MD5, not the secure, but that's what we're going to start with. And then we're going to go ahead and call for the secret key. Not also the greatest secret key, but it just get the point across. And after that, what is going to happen is I'm going to go ahead and generate a message. that message is going to go ahead and associate the secret key and put it into um a hashy method for the MD5 and it's going to send that over. This particular pieces of information is really important because it has to match between client and server. It cannot be different otherwise the message is not going to go you're going to have a fail.

So let's go ahead and take a look at how that looks like. So in this particular scenario on the left side you guys are going to see my server is going to going to have a listening port on 1 2 3 4 5 waiting for a connection from my local um host. So I'm just going to go ahead and start typing um hello besides Las Vegas 2025. And from my client I'm going to go ahead and send that to my server. Now this is going to show us that the message has been received. There is my HMAC value right over there and then it was verified. So both computations between the HMAC and the server and the

client is the same. So I had no issues there. Great. So next I was okay. So, how do I go about trying to figure out what happens if somebody gets my message and the HMAC value? So, we're just going to go ahead and see if we can crack it. So, we go to hashcat and assign it the MD5 mode because that's what I had. Um, and then there it is. So, now I have my HMAP value, I have my messages, and I have the secret key. So this was a major milestone for me because I'm like, okay, so what else can I do with it, right? So the next step is like, let me just go ahead and go a

little bit further and just go ahead and try SHA 256 just for the heck of it because why not? So go ahead and send that message hello again to my server. I got the shot 256 there. It was verified. All is good. And then I'm just gonna go ahead and go to hashcat and see if I'm gonna be able to get away with that again. So in this case, it took a little longer, but I still was able to find the secret key within Rocku um in there.

So now that I know how it looks when it does work, I needed to figure out what happens if I am able to intercept the data packet. So that's when we started to look into data packet manipulation. So for this particular scenario, I use a burp suite um B app called nope. Um, and I had to create infinangle with the with the client server in order to get the HTTP request um, crafted so this demo could work. Um, so I'll show you guys what that looks like. So here I already have nope proxy already installed. So the first thing that we need to do in order to get this to work is turn off the proxy setting from Burp Suite. So

once we do that, we go into the nope proxy

and once we're there, we're going to go into the server configuration settings. So here we're looking into our server um information. So we're going to use the 8080. We're looking for our local port and 1 2 3 4 5 as our listener. We're going to start our intercept also. And once we do that, we're just going to go over to my client and server environment and I'm going to see what happens when I turn that on. So, I'm going to go ahead and type a message. And you can see that the connection has been established from my local host into the server, but nothing came through. Right? So I'm going to go ahead and go

into the burp suite and I can see that my message is there and the hmap value is also there. So I want to say so what happens if I just modify a little bit before sending the packet over to the server. So I added some stuff in the message like hello are you there? And I go ahead and forward that message over. Now based on all the information that we have discussed so far, it should fail, right? Because the match the message and the HMAP value should not be the same. And that's what happened. We have a integrity check failed right there. Meaning that whatever I send the HMAP value of that message should not be

that. Therefore, it didn't work out. So I went ahead and tried to send another message and just like hello somebody there. Same thing here. Connection is established. I go back to Burpuite and this time I'm just going to go ahead and send that over. Um it was better for me to see if it's actually working. Um so integrity verified, everything is good. The HMAP value is the same. No issues there. So what happens if I try to go ahead and modify the HMAP value instead of the message? So I went ahead established the connection again. And then I'm going to just change a few other characters of the HM value and I'm going to send that over.

And in this particular scenario, it also failed. So the server is doing everything in in their end to make sure that whatever that message is, the HMAP value is also the same. If it's not, it's just going to go ahead and discard it. So now that we know that, I wanted to see how does this look in Wireshark, right? So go ahead and and have my little server and client going on. And I'm just gonna go ahead and just craft a message.

It was verified. Everything was good. I go to wire chart looking for that data packet. And I'll just go ahead and follow the TCP dump for that. I'm going to zoom in because I, you know, I wear glasses, I can see. And once I have that, I'm going to craft that into a hash.txt file. And I'm going to take all of that into hashg and see if I can um crack it and get the key.

So after long time thinking and there is Mikey.

So now that we have covered a little bit of how the client and server communication kind of interacted um this from this point on we're just going to see a little bit of examples of different attacks and methods that people uses when it comes down to HMAC. Um, all of the values that you're going to see here for the for the algorithm is going to be shot to 56. Um, and the word list that I'll be using is a crafted one. So, I'm not going to use rocku we'll be here forever. So, uh, very just simple proof of concepts when it come down to this. So, we have the information. We know that the keys are the most valuable pieces of

information when it comes to HMAC. Uh so once I do that, can I do more? So in this case, let's say that we have been able to get information from somebody um that is trying to log into a server, right? So we have all that information. We have an admin user. We have their HMAC and we know what the algorithm is. So, we're just going to go ahead and try to do a dictionary track to brute force and see if we can get the key. Now, once we have that key, then everything is anything can go right. Um, let's see if that goes any faster.

All right. So, I was able to find that that user was using secret 123. And now that I have the actual key, I'm just going to go ahead and do a message. So, anything that goes from this point on, when it comes down to the messages, I can introduce a malicious payload in there. It doesn't matter. The server is going to take it as true because I have the one important piece of that and that's going to be the key.

So in this case, I'm just going to go ahead and send a message called like I found you and I'm just going to go ahead and see if that is going to come back as a true and then it was received successfully.

All right. So next we have what do we do um if we modify the timestamps. So in this particular scenario we have an HMAP value that is protected by timestamps which everybody should use when it comes down to implementing HMAC. Anyways, um the server is going to check for the check um for the timestamps of value when I send my messages over and if there is any type of discrepancy a type of replay attack is happening the actual HMAP value and the message is going to change throughout a period of time. So at that point the payload itself is going to be too old and the server is going to be you know what I don't know

what you're trying to do. This is not working. It already expired. So here I'm just verifying that the HMAT value is true. Oh no, there you go. So I know that the HMAT value is true and that's right. So then I try it again and it went to a false. So that means that the timestamp itself within the HMA value on the server has already changed,

which is what we see right here as a result.

So again, it is invalid. It's too old. I don't recognize it. The server is going to go ahead and try it again. And that's the best way to counteract what it we're talking about, replay attacks. So now that we know what replay attacks work, how about timing attacks? So the timing attack is a little bit of a flaw when it comes down to it. So if you have a string comparison with an equal equal on the actual HMAC implementation, the attacker can actually measure how long would it take to get the right hmap value. And so in this case um I know that the false comparison because I changed something in the MAC is approximately

320 milliseconds. Right? So what if I just take a few of the characters out of the HMAT value and see what I get for timing. So I still have a comparison of time. So what if I just remove everything and just try the first character here for the hmat value. So now it's 5 seconds. So within the timing attack we have a way that the attackers can indicate okay I am getting close to knowing what the hmat value it is for this and they just keep like hammering towards everything until they get the right amount and the right characters in here. So the closer they are to get it right the less amount of time will be on that

counter.

Next we have the logic bugs. So this is something that has been seen in the wild before. It's just a matter of understanding how to implement the logic when it comes down to the server and the presence of the HMAC in here. So in here, I'm just going to go ahead and paste a different message that it was originated before with a different HMAT value that is probably not what hello world should be. And once I do that, everything is going to come back to true. So if the attacker send whatever garbage they want to send, whatever malicious payload is in there, the server doesn't know how to respond to that. So everything is going to be

true even if the HMAC value is not accurate or if the message itself is not accurate. So that will eventually get you your actual um server compromise at that point. So we also have HMAC presence on Java web tokens. And in this one in this particular scenario we have a user that goes by admin one low privilege person just somebody right and then we have here what their Java web token looks like. Once we go over that, we can just do an um an analysis of it and we break it down. Okay, so we have uh hatching algorithm for shot 256 there. Um we know what type of token it is. We know the username and the role and it signature.

So, in order for all of the Java web tokens to work in a secure manner, you should have the signature requirement flag implemented there because if you don't, I'll show you guys what. But, um, so we have an admin one, the user, and a secret key. So, we know what all of those things look like because I was able to do a Bruce for attack. Um, because my secret key is not the best.

Now, in order for us to make sure that the Java web tokens are secure, we need to make sure that the header is showing up. The algorithm none is not there. You always should have the signature requirement in there because otherwise the server will skip the verification and it will accept any token that sends through with without the key.

All right. So we're down to the best practices. So everything around HMAC revolves around the keys. So the stronger the keys, the better you are. We should not be using P user passwords when it comes down to creating keys. Is going to be probably easy um to crack. So we want to make sure that we avoid that. Um once the key is compromised, then everything will work and until that key is changed. So unless you change it um you will be compromised for the duration of that key on that server. I would recommend um establishing a key management plan. Find out what length the key should be. Implement key rotation so that way you're not stuck with the same key for

eternity or six months depending on who you work with. Um establish audits and revocation. So, if there's something within the audit locks that you guys see that is kind of like iffy about it, then go ahead and revoke that key. Try to figure out the steps to issue a new one. Next, we need to make sure that all of those keys have a strong algorithm. CHA 256 is okay. RSA, CHAT 3, um, all of those things will actually be able to help you guys secure those keys. Um, never hardcode the keys in the configuration files. That's just just not good practice. Um, and apply lease privilege. Not everybody needs to have access to all the keys. Um, so make sure

that those are also part of your key management plan. For securing the code, make sure that you include the timestamps and the nonsense uh the nons. um that will help the server identify if there's any type of replay attack trying to happen and everything was just gonna get dropped by it. So that's a good thing to to do. Um validate timestamps rejected and reuse any um expired messages just get them thrown out. that will also alleviate the issues with the timing and attack replays and also secure comparison functions. So in this case um you should have for if you're writing stuff in Python you should have an HMAC compare digest. So it's just going to make sure

that it's going to compare what the server is getting and what the client is sending. That way you don't have to have through any go through any of the issues that you might encounter if you don't have that for the Java tokens. Uh like I said, make sure that you have nice um and strong keys. Also, algorithm validation. Just make sure that that flag is also included that you don't have the alg none in there. And also key rotation, make sure that you rotate those Java web tokens keys when you're signing them off. And for takeaway, so HMAC is still a way to protect from unauthorized access and message tampering and forgery. Um, but it's going to be as strong as you

implement those. So if you use strong algorithms, if you have the random generation of keys and if you can go ahead and update the secret key and keep it safe, then you should not have any issues with HMAC at all. Um, HMAC is not broken. It's just misused, mismanaged sometimes. Um, so just I don't want you guys to think that just because you have a strong algorithm, everything's just there. um you need to make sure that you have the proper way to manage and safeguard those keys because those keys are technically the key to the kingdom when it come down to the server. And I think that is it. So I'm open for questions if anybody has one.

Well yeah >> it's coming. It's coming. Oh.

Um to what extent and in what context do uh timing attacks on HMAC comparisons occur in the real world? Uh in particular over the network is would be relevant for my work but uh in general >> in particular with what? I'm sorry couldn't hear you. >> Uh in particular over the network would be particularly relevant >> in this particular scenario. the timing replay I already had access so I'm just assuming a breach so the likelihood of that happen is not as high as you would think on the regular like on the network >> I I don't necessarily think it's particularly likely but I'd like to know I'd like to know their opinions >> yeah that is something that I still need

to delve into and research more. But yeah. >> Okay, let's take uh this one. Start with you. >> Thank you. Um thank you for this talk. Um I had a question about timestamp uh the inclusion of the time stamp in the HMAX. So first of all, are there any best practices for the actual mechanics of doing that like concatenating it to the payloader? um or whatnot. And then the second question was or I guess second part of that question is do you have a recommended like maximum clock drift um after which you're you would like no longer accept um uh an expired time stamp I guess. So for for the for the projects I was working on um we

added the time stamp for 30 to 40 seconds. And that is going to depend on your system because in in my case it was something that I cannot have too long or too short because that will create a delay on whatever was going to happen. gonna talk about it but um that is going to depend on your system and your architecture. So in my case it was 30 to 40 that was based on the mission that it had back then but it can be shorter. It can be probably 5 seconds.

I was wondering did you actually uh implement a timing attack? Um or was it just sort of like theoretically I mean you know the timing was shorter for the shorter one. Um I just tried to I'm just curious because I've tried implementing timing attacks before and it's extremely difficult for me and I just was wondering if you had any tips um that you did. >> So in this particular case um it was an assume bridge and it was like super simple. It was just a matter of understanding how the timing rotation it is. And you are right, it's going to take longer because there's many sequences and according to the longer of the algorithm, the the more inputs you

will have to have. So no, I do want to uh but no, for this example, it's just a matter of showing you guys what the difference will be between a correct input and a and an incorrect one. Yeah, I I I want to meet somebody who's actually successfully implemented timing attacks because I've even tried introducing artificially long timing delays and it still doesn't work. And I'm like, why is this not working? I don't. So, I'd love to find somebody who can do it. >> But another thing that we and and I know we all hear about all the buzzing about quantum computing. So that is something that it will affect all of this hashing algorithms, all of this implementation.

So something that you guys need to also take into consideration on this old boom happen about quantum and and all the things that are going behind it. Then we might need to find better implementations when it come down to securing our hashes and maybe time time based attack will actually be a little shorter. >> Okay, we still got time for some more questions. Also, I mean, we can have it as a discussion as well. So, if you would like to answer a question that's been asked or if you have an example that fits in, you can do that as well. >> Yeah. And just as part of the story, I don't know if they implemented it or not

because I moved on from that project. So, who knows? I did recommend it to implement it though. >> Okay, let's go back here.

Hello, I'm back. Um, >> welcome back. >> Thank you. Um, so in some of the frameworks that I've worked in, I've seen mention of uh password-based key derivation functions. Do you have like any recommendations on whether or how to use those in deriving your shared secrets? So, I don't I don't like the password derivation piece of things. I understand why people do it. It makes sense. Um, but as far as the implementation of it for secret keys to HMAC, is it a good key? So, those are the questions that you have to see. How long is it? How good of a key is it? And can you use it? Definitely don't use secret one, two, three. like that's just a

given. But um with all the changes about password um length and all the things that we have to do now is like 20 characters long or all of that. So there might be a some type of leeway that you can use them, but I just don't recommend that. >> Cool. Any any further questions? I was thinking about the best practices that you're mentioning um over there. Was anyone in this morning's talk that could that uh could just remind everyone what uh there was an issue. No one here was in this morning's talk. Okay. I was hoping somebody could bring it up. Okay. Um, it was about the secret keys and about uh how you keep and about

how uh everyone loves putting their code on GitHub and sending all of these secret keys. And um if you get a chance, watch it as well because it ties in well with this talk because it shows just how bad the exposure is of uh secret keys and the keys used for the derivation of HMAC keys that people are just leaving lying around facing the internet and uh yeah anybody can just gain access. Obviously it then takes the hard work out of doing all all of this because your keys are now just lying around um and it's easy like that. So uh yeah, so that ties in well, you know, keeps the thread going about how that best

practice comes into your HMAC security as well. >> No more questions. If there's none, then we'd like to thank uh Isney. >> Thank you. [Applause]

[Music] Dirty. Down. [Music] Heat. Heat. [Music] Fire

home. [Music] Heat. Heat. [Music]

Down. [Music] Down. [Music]

[Music] Heat. Heat. [Music] Heat. Heat.

[Music] Heat. [Music] Heat. [Music] Heat. Hey. Hey. Hey. Heat. Heat. N. [Music] [Applause] Heat. Heat. Heat. [Music] Heat. Heat. Heat. [Music] Heat. Heat.

[Music] Heat.

Hey Heat. Heat. Heat. N. [Music] Heat. Heat. N. [Music] Heat. Heat.

[Music]

Wow. [Music]

[Music] Heat. Heat. [Music]

[Music]

Heat. Heat. [Music]

Oh yeah. [Music]

Heat. Heat. [Music] Heat. Heat.

[Music] Heat. [Music]

Heat.

[Music] Heat. Heat.

[Music] Heat. [Music] Heat. [Music] Heat. Heat.

Heat. Heat.

Yeah, [Music]

[Music]

down. [Music] black hey black

hey [Music] you hey you hey you hey you hey you hey you hey you hey you hey you hey you hey Yeah, [Music]

down. [Music] Down

Black.

[Music] Heat. Heat. [Music] [Music] Fire.

Fire. [Music] There we go. >> Okay, welcome everybody to our last talk of the day for Passwords Con, but certainly not the least. Just by way of reminder, if you are uh first time attending uh a talk with us today, uh just reminder on the on cell phone usage, um please don't take any photos of the attendees around you without their consent. Filipe has said you can take pictures of him and or his slides. So, you're welcome to do that. There's no need to take any video because uh it's being streamed and recorded. So, no need to do that. And please put your phones on silent um so that it doesn't interfere with anybody else. Again, a

quick thank to us to our sponsors, our diamond sponsors, Prisma Cloud and Vant, and our gold sponsors Drop Zone AI and Project Circuit Breaker. and then all the other sponsors and volunteers as well that made this conference possible for us including yourselves for being here um that make bides enjoyable for everybody to learn and to have fun. So we're going to welcome uh Filipe um from Brazil. So I will try and say Filipe. >> Yeah. >> Right. Good. Right. So, we're going to hand over to Filipe who's going to do machine identity and attack path, the danger of misisconfigurations, and then afterwards there'll be some uh Q&A as well. So, let's hand over to Filipe.

Okay, thank you. Thank you. Can you hear me good? Right, that's cool. Your Portuguese is very cool. And uh yeah, thank you so much for being here mailing the last talk. Are you tired? I'm tired. >> Come on, sir. Who's tired here? Yeah, everyone is tired. Okay, thank you for being here by the way. And uh yeah, so let's talk about our main topic. Um actually our conversation will be divided in two parts. The first part is more [ __ ] part. The theoric part is kind of [ __ ] I know that but it's necessary. But the second part is more sexy or let's say the more technical part. So please stay until the end because in the

middle I share more of the funny things that more sexy party. So by the way who here work with the you know AWS just to okay who works with Azure who work with um Google yeah or OCI who work with nothing because someone worth nothing. Okay, cool. So, basically I'm a head of identity thread labs and global product advocate at Seagura and I'm responsible for doing investigations uh about the threads understand how the thread works and mainly how the attackers are you know investigation the attackers are creating new techniques and explore identities actually and machine identities. This is a kind of type of name by Gartner. Let's say [ __ ] Gardner. I can say [ __ ] Gartner. It's

not polite, right? Sorry guys. This is the community event. Okay. Anyway, so I'm part of the red team village director of the team responsible for sponsors and I'm organizer besides Porto in Portugal. By the way, I'm living in Portugal right now. Actually 50% of my time I live in Portugal and another 50% I living out of Dallas here in US. So but I'm one of the organizers uh at Besides Porto. So I know how this event works. So I'm found I'm founder of this community called the red team communities. This community is focused on red team in Brazil. Basically, I'm Brazilian as he said and uh but I'm living in Portugal. We talk Portuguese and I'm a part of the high cyers.

Basically, hiisis or races or we can it's a kind of root. It means root. Basically, the idea is to spread the message and to helping people to get inside of the you know cyber security stuff. This created for the Spanish people and Portuguese people as well to helping you know to growing and to get inside of the cyber security. That's uh if you see I just received in salary for the first company here and the other is no proof it initiative and the community events let's say okay cool by the way first questions just who was last year here anyone is who last year watching my talk here cool this would be you are here last year

>> I think so >> yeah okay I will bring some things to you and you watching my talk at hackspace con right at Florida okay cool So first of all my company it's called it segura it means secure in in Portuguese language we responsible for providing solutions for identity and mainly pen solution when I mean pen is privilege access management just to let you know so we are is a Brazilian company but we are have an officy here in US and we are growing okay let's talk about our main topic so what is machine identity just to putting every people on the same page basically machine identity refers this unique identity because we are using two to use on the user and

password right but nowadays we need to have the let's say um not more password so probably you heard about passwordless technology right and sometimes when you have a two different applications in the cloud for example or even prime is you don't need to have the user password you can use you should use in service account right it's more best practice to integrate those type of things and you talk about this is about machine identity or no or human or no human identity right because to have a permission above those identities and you need to set those permissions between those different applications to talk between applications one and application two right you don't need to have the user like flippy user or

password because if I leave the company the application is going down right because should be based on the service account that's cool so basically machine ident refers to that okay so about secrets tokens or mainly now we are involved with the docker containers ers you know like the kubernates and many things about that. So we talk about this machine identity when you talk about the human identity we are talking about the user and based on user password and many things you know about that okay so basically our vision about machine identity just to understand everything is about machine identity how you manage the government's privilege accounts secrets cloud entitlements it's quite new another [ __ ] word of Gartner

anyways okay and access management certification lifetime identity poster manager of the famous ITR R another [ __ ] word I'm not good in this to be polite anyway identity thread detection response is ITR and you have like um many others you know security posture but I know that's necessary for organizations for to manage cloud providers and so on and so forth okay so that's the vision about machine identity how you can manage this first is when you look into the kind of solutions so we are like let's say I'm supposing that you work with the you company You are analyst or you are like a principal, you are a staff whatever the position when you need to look into this kind of

solution you need to figure what is the best solution that you should using for discovering for this identities let's say the machine identity the server containers pipeline many cloud workloads when you need to you need to look into the governance let's say the best practice to enforce the policy or even have a kind of control or the ownership the other one is to automate it again to thinking about just in time access because I published it I think one week ago one the big attack that happened in financial sector in Brazil I don't know if you have opportunity to read but you can came to my social medias after this talk you can see this completely article

that I investigate and this attack is is happened because the company that suffered this attack didn't have the just in time access enabled because the attacker happened during the night like happened to the started at 4 a.m. in the morning. So you know the attacker they didn't many fraudulent transactions during the morning. So it starting 400 p.m. actually start before like 2 3 p.m. So like if the company had the just in time you access to block at this access or this transactions during the night or in the morning at let's say the company could block at this attack. So when you think about the identity access management you need to look into this type of things. Okay. And to be secure

like looking or working with this kind of concept called the list privilege. Okay. Just to understand what is machine identity. Okay. So talking about cloud. So if you think about offensive perspective in the past when you talk about on primes we have the high value target. So we look into the active directory and the active directory had the administrator guys. Okay. So how do you works in the cloud or how do you manage those type of things? So high value targets comes to the military as the terminology here from US. So to refers to the person or the resource that the enemy commanders requires to complete the mission. Okay. So basically this is the talk about military

perspective. However, if you think about for example the organization so you need to think who is the high value target in my organization. So think you who could be the high value target in your company. So maybe is a C level maybe could be the like the CFO because the guy responsible for pay the salary. So usually we think that okay who could be the most impacted position in my company if the attacker gain the access and this identity or if the guys should have a kind of uh let's say the permissions attach it to this guy. So what is the impact? So think about that. So maybe we think okay the high value target can be

the C level board member or can be the senior executive management sometimes we think that this guys is the high value target however we have here people with elevated privilege so now I have another point about that case that I share with you about the Brazilian financial attack the guy responsible for uh helping the criminals the facilitator he was a developer junior developer Who is developer here in this room just to Jesus okay sorry for that but it's not your guilt that's the point here the point is about VS code let me explain to install VS code VS code requires what administrator access to the you know the guilt is about the VS code because I'm

kidding you know like the many differ