BsidesLV 2025 - Ground Floor - Monday

with subdomains, what host names the company had. And then the uh the CAB, the browser forum said, you know what? If you guys are gonna issue TLS, we don't trust you guys anymore. You need to issue all your certificates to a public transparency log. That's a big sign Merkel tree. And in doing so, we've now got like real time notification of domains being registered. So if you're setting up a new WordPress site, for example, and you use godaddy.com, well, the second you register that domain before WordPress is even like completely set up, you're now telling the entire world that that domain is live with new TLS here. And you don't want to connect to WordPress before there's TLS because

then you're sending your password across the network clear text. But as soon as you do it over TLS, you're now fighting to race that before everyone else finds your WordPress site before you do. So if you run a uh you know CT tail basically like watch the flow of new domains being registered to CT. You can race people and steal their WordPress accounts before they finish setting them up and just how it works. There's like no there's no fix for that right now. Um but one of the things a lot of folks don't realize is crT.sh is an amazing tool if you ever been to the website. What a lot of people don't realize is

there is no application there. There is no web stack. There's nothing but Postgress. The entire web interface of it is just Postgress. They built an entire web stack like everything from search queries to HTML to templating to links is just SQL queries and SQL functions in the back end. It is insane and you can find the source code. So don't let anyone tell you that just because you're DBA, you're not a full stack developer. Uh one of the things you also don't realize about CRT shell or may not realize is they actually have a a full-on SQL interface. You can just run psql- guest ct. Shell and run queries all day long. Like you don't

have to use their website at all. you can hit their database directly in the internet. Like they just they allow that. They're they're very brave. But the hard part is getting the SQL. Like how do you figure out this crazy SQL on the right side? Well, you have to go look at your web interface, pass the show SQL equal true, and it'll give you the query you need to find the stuff. Then you adapt that query for your stuff going forward. So if you want to build automation to your tools using just BSQL, great. It's easy. Now, if you want to go the other direction, let's say you want to do this, but you don't want to

tell CRT.shell who you're trying to resolve all the time or you want to go get the data directly yourself. um ends up it's really easy just to go take a list of all the active sort of transparency logs and then monitor the uh heads of those logs and tell you about new registrations in real time without having to tell anyone else about it. Effectively, you just write a tool that goes looks at the 20 odd logs. It says what's the current index? Give me the last registrations, show me the names, spit them out. And so this little utility called ctail. It's a github.com html ctail. And basically, it'll just spew out all the names as you're being

registered in real time with whatever reax you want. And then you feed that into whatever attack tools you want. So if you want to look at uh identifying all the registrations for a given target domain name for anything with a certain prefix like autodiscocover or blog or whatever, it's really easy to do. And the project discovery team recently added similar support to the TLX utility uh for a subutility called ctutil. So I'm not sure if it's been officially released yet, but it's in the source tree. Uh and that'll something very similar as well. So if you want to drink directly from the CT fire hose, it's not that hard. So another fun thing is split DNS. Like

a lot of folks don't realize that uh often external DNS servers will allow you to query internal DNS results. Like it's something that's been around forever, but folks don't actively look for it and they should. Um the short version is first you look for I'm going to have to fly. Um the first thing you need to look for is any outbound DNS server. So look for any DNS exposed to the internet. Great. Scan that and then brute force that for private IP you find results for you can do the same thing by looking for internal names like open sense pfsense router. setup.com is a special name where if you resolve it internally, it resol resolves to RS1918

IP like a private IP. If you resolve it externally, it resolves to an AWS IP. So, great way to know if you're inside or out. Another fun trick is you can actually use a open DNS resolver. So, any DNS server that resolves your domains as a ping scanner. You can tell it to ping things it can reach, no one else can reach. You do that by creating a fake subdomain where the NS records for your fake sub results point to internal servers and internal like private IPs. And you tell it to basically do DNS lookups against internal systems. And based on the latency of that, you can determine whether that system resolves or not. So

for example, we can scan the private range of quad 9's internal network by looking at the latency results of doing uh IPv4 lookups with this crazy DNSRP tool which you can also find in the root references. So going to the next step like how do we find things in the internal environment? Well, we find developers repos resources, find targets, find pivot points and then go quick. So first thing like to do is hunt for the developers themselves. like find the folks who work at these companies, go through all their stuff and try to find references to tooling, to packages, to resources, domains you may not know about otherwise. Even better, if you can find the list of all the different

developers, like in case this is a Microsoft repo, go steal all their SSH keys. They're all public. Just go up there and grab all their SSH keys. Now, whenever you find an external machine with SSH enabled, you can just throw those keys against it and see whether or not they're allowed to log into it. So, you can quickly just using someone's public SSH key, you can see whether the server accepts it for that username and that key even without having the private key part of it. So, in doing so, you can figure out does user A have access to this system. Um, it's also useful for knowing like did we lock this user out or not? Well, if you have their pub key

and just their pub key, you can still figure out whether they've got access to digital machine or not. Um, for a lot of git repos, you don't even need you don't actually need the username. You just need the pub key. It'll then tell you which username you're logging into just by doing half authentication. So, some neat things to do with that. Um, a couple ways you can do it. You can either take one key and throw it at all servers in the internet, which what we did. We're searching for like gotan from his GitHub key. Or you can go the other way and you can take a thousand keys and throw them against one server. We're

trying to figure out which users have access to one server. So both methods you can do through the shambble tool that uh released a couple years ago. Now VPN appliances have become like the number one way into networks. The manate report from last year says like of their top four breaches or sorry the top four uh initial access vectors for all the breaches they investigated there are all security appliances avant and forinet. And if you've been in security for the last couple years it wouldn't surprise you but it's amazing those are actually the biggest sources of breaches are security vendors. So another fun thing is uh remote desktop. Now remote desktop used to be fun because you can get a copy of the

desktop without logging into it. You can see the group names. You can mess with it, screenshot it, things like that. Then they added something called NLA. NLA is network level authentication. It makes you do a full NLMs handshake. That's actually even better half the time because it'll actually give you the domain name. It'll give you the OS version. All kinds of stuff during the handshake itself. So while remote desktop is something typically you don't see in the edge anymore because it's not something you want to expose, it's also something that you can still find through these other mechanisms. You can find it hanging on IPv6 addresses that the user just doesn't know are there. Um, and you can also find it through

remote desktop gateways through RD web and other web interfaces to our remote desktop. Um, see another fun ones are V6 exposures overall. So there's a large university customer of ours who says, "Hey, um, our hurricane electric ISP accidentally routed all of our internal IPs internet through V64 gateway." So if you have a anycast 64 router, it'll actually just start routing all your external traffic, so internal devices externally through a mapping layer that's predictable. and they found out the hard way when shadow server told them their RDP was exposed internet. Another example of this that comes up is cellular broadband IPs. If you've got a laptop and it's got like a, you know, mobile LT adapter. Typically, you have a

V6 address from your cellular provider and depending on which network you're roaming on, you either have a firewall or no firewall, but you don't actually know. Like a lot of folks just assume the cellular side's going to firewall you off, but a lot a lot of cellular networks will actually just stick you directly on the internet too. So, as you're roaming around, you go from having a public bear v6 address to not having a public bear v6. So, as we're going kind of inside the network a little bit here, and I know we're short on time. Um, so the question is, where do you go next? So, you've got some foothold. What's the first thing

you go after? Well, you don't go after the data first. You go after all the platforms that control access to the data. You go after the network management tools. You go after the admins workstation. You go after the developer machines. Like, those machines that'll get you into everything else. They're not the things that you typically think of as being your first line of defense for your credit card data, but they're actually the most easy way to get to the credit card data is by going through those machines. So, network management platforms are my favorite. I love popping Solar Winds, managgs because they've got all the clear text passwords to all the network devices and it doesn't matter how good your

segmentation is when the attacker has a password to your ASA and can just reconfigure your firewall. So I've been in test before we literally just opened a hole in this ASA firewall into the card data hole environment and just walked right into it because we had access to Solar Winds which had access to push rules to the firewalls. So your segmentation doesn't matter if your attackers take over your device configuration and it's just a really easy thing. So what I like about this is you can actually run the uh flamingo tool on the command line for port 22 161 etc and immediately capture all the credentials from your local network management tools and then turn around

and replay those against the network and own all your stuff. So it's easy. Um some other easy pivot points here are like next a little utility for doing net bios reflection that gets you the secondary IPs. RPC dump will actually dump the endpoint mapper. Impact has a tool called oxy resolver which gives you the multiple IPs for single machine as well. um a little more difficult is you can start looking for devices that support SMPP and looking for devices that have the same unique ID in multiple places. Therefore, you know it's the same machine or you can find systems that uh enable packet forwarding by default. So the surprising thing here is just about every printer and just about

every desktop or laptop running Docker is actually also turning on IP foring by default. So if you take your laptop and you're plugged into Ethernet and you're plugged into the Wi-Fi at your your company and you're running Docker desktop, congratulations. you're now allowing everyone on the wireless network to route through your laptop to the corp network and no one knows because they didn't realize you turn on IP forwarding and there's no apples disabling that on your machine. So IP forwarding is everywhere and no one bothers checking forward and it's a lot of fun. So the dev tool hubs are also a lot of fun. You can go after the CIS, code forges, artifact tools, etc. They

tend to be full chalk full of credentials as people build packages that are not meant for external use. Uh config key value databases are my favorite as well going after Reddus, console, etc. Uh you basically can find all these services that are exposed to network authentication that are chalk full of credentials and fun things including session IDs which you then take to bypass login. Uh I just want to complain about it temporarily here. So in version 50 said you can no longer run our software on CPUs older than X. And so what did the world do? They said well that's great. We're just going to run ancient on our production systems from now on. So if you install Ubiquiti Unifi on

any system out there it's going to be running an end of life version of MongoDB 4.4 for because they literally cannot run newer binaries from on older ARM platforms. Even Cisco Ice like the big enterprise tool, it actually includes seven different versions of and depending on how old your CPU is, it'll downgrade you to an end of life version if you run on older than Halm or pre Sandy Bridge Intel architecture. So, it's pretty amazing that you have these like end of life tooling being packaged with, you know, fully patched software just because of that. Other fun things are login scripts, usually full of hardcoded passwords. Big fix relays are great to dig through and dump out packages. Uh, I

love finding really old computers because if they've been around for a long time, it means they've been there for a reason. Someone couldn't get rid of them if you wanted to. So, whatever the reason is, figure that out because that's why it's important. And also, because it's ancient, it probably has all kinds of fun bugs. You can, you know, dust off some book from the library and still find ways to break into it. So, uh, printers are also a lot of fun. Not only their pivot points, but they're chalk full of credentials as well. Um, and now the fun part is how do you get the loot? Well, focus on all the things that are old and the odd and

underprotected. Focus on out of band management, underlying storage systems and the backup platforms. So find the weird stuff first. So what are there only a few of the network? How many AS400s do they have? Well, probably like one. How many HP3000s? Uh how much of these old OT HMIs? Look for the things that don't look like their friends and go after them because they're probably missing Apple's missing security updates compared to the rest. I love BMC's, KVM, serial servers for the same reason. They effectively provide a lower security way to bypass security of a much higher security system and they typically leave authenticated sessions open. So if you pop a serial server, which tends to be

like a junky IoT device, you now have 16 different logged in shells of all your routers and all your firewalls and these are only the routers and firewalls that matter because otherwise you wouldn't put a serial server on it. Like it has to be important enough that you have out- of-bound access to it. So by definition, if it has a serial server attached, it's wide open and it's exposed, which is great. So those are good targets. Um, IPMI is still a back door even with the latest version of Super Micro, uh, they ship with IPMI by default. And because the state of California found that default passwords give you cancer, they now have to randomize the password instead. But the

randomized password can still be cracked by rack P protocol, which is the IPMI handshake. And you can tell rack P, I would like that password in MD5 format, please, or maybe SHA one or maybe SHA 256. But because you're able to pick which password hash you want from the protocol, you know, it's storing a clear text on the server side because it has to, otherwise it can't calculate the hashes. So effectively, you can you can ask IQI services to give you a hash any format you want and then go crack them really easily. Just turn off lama for a little bit and get your shells. Um, another really fun one is NFS pings. A lot of folks will filter port 111, but

they won't filter 2049 and the mount D port. So like my earliest claim to fame was owning all of Yahoo's mail servers through NFS because they filtered the RC bind port, but they didn't filter NFS and mount D. So you just mounted all the NFS shares the internet and went through all their email. That was great. Uh, ice scuzzi, same thing. It supports authentication, but practically no one turns it on. Uh, and backup systems are one of my favorites. So a great example is uh Rapid 7 said that more than 20% of all their instance 2024 involve ransomware attackers going into their VH backup replication systems. So that's it. I talked about getting it out but

effectively you know how to do this stuff already. Basically ads sync loot use uh SQL itself use VPN tooling use things like that and uh that's it. So that's about 30ish tips 20 minutes. Thank you so much.

Uh, no amount of time. If you have any questions, I'll be hanging out by the run zero booth at the back there. Thank you. >> Sorry. >> This is really wonderful. >> So, you covered all the >> trying to go really fast, but still not be too lost in the

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

[Music] Hey. [Music] Heat. Heat. [Music] Fire. Black.

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

[Music]

Hey, [Music]

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

[Music] Heat. Heat.

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

[Music] Heat.

[Music]

Heat. Heat. Heat. [Music]

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

[Music]

[Music]

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

Heat. Heat. [Music]

[Music] Heat. [Music] Heat. [Music] I [Music] hope. [Music] Baby, [Music] down. [Music] for [Music] you. [Music] Hey,

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

Heat.

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

Heat.

[Music] Heat. Heat.

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

Heat. Heat.

[Music]

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

Heat.

[Music]

Hey.

[Music]

[Music] It's

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

Woo! Wow! [Music]

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

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

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

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

down down down.

[Music] Heat. Heat. [Music]

[Music] Fire.

Home. [Music] Down. [Music]

Heat. [Music] Heat.

Heat. Heat.

Heat. [Music]

Heat. Heat. [Music]

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

Heat. Heat. [Music]

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

[Music]

[Music]

Yeah. [Music]

Wow. [Music] Heat.

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

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

[Music] Heat. Heat.

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

Heat.

Yeah, [Music]

[Music] heat. [Music] Black shoo back. Yeah, [Music] down down. [Music] Down

yeah.

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

[Music] [Music] D. [Music] D. [Music]

Home. [Music] Do [Music] Down. [Music] Heat. Heat.

[Music] [Applause]

Heat. Heat. [Music]

Heat. Heat.

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

Heat. Heat. Heat.

[Music]

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

Heat.

[Music]

[Music] Hey. [Music]

Let's [Music]

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

Woo! Wow! [Music]

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

[Music] Heat.

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

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

[Music]

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

[Music] Heat. Heat. [Music]

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

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

Heat. [Music]

Heat. Heat. [Music] Heat.

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

Heat. Heat. [Music]

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

Heat. [Music] Heat.

[Music] Hey. Hey. Hey. [Music] It's

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

Woo! Wow! [Music]

Heat. Heat.

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

Heat. Heat. [Music] Heat. Heat.

[Music]

Heat. Heat.

[Music] Heat. Heat.

Heat. Heat. N. [Music] Heat.

Heat.

Yeah, [Music]

[Music]

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

down down down.

[Music] Natal. [Music]

[Music] by [Music] Baby, [Music] daddy. [Music] There are heat. [Music] Hey. [Music] Hey. Hey.

[Music] Heat. Heat. [Music]

[Music] Heat. Heat.

[Music] Heat. Heat.

Heat. [Music]

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

Heat. Heat.

[Music]

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

Heat. Heat.

[Music]

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

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

Heat. Heat. Heat.

[Music] Heat

[Music] up

Heat. Heat.

[Music] Heat. Heat. Heat. Heat.

[Music]

Heat. [Music] Heat.

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

[Music]

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

Down

down down down down down.

[Music] Heat. Heat.

[Music] down. [Music] Heat. Heat. N. [Music] Heat. Heat. [Music] Fire down.

[Music]

Down. [Music] Down. [Music]

[Music]

Heat. Heat. [Music]

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

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

Heat. Heat. Heat.

[Music]

Heat. Heat.

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

[Music]

[Music] Heat. Heat.

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

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

[Music] Heat. Heat.

[Music] Heat.

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

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

[Music]

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

down down down down down.

[Music]

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

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

Heat.

[Music] Hey. Hey. Hey. Heat.

Heat.

[Music] Heat. Heat.

[Music] Heat. Heat.

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

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

[Music]

[Music]

me. [Music]

Woo! Wow! [Music] Heat.

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

Heat. Heat. [Music]

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

Heat. Heat.

[Music] Yeah, [Music]

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

Down down down down.

[Music] Heat. [Music] Heat. [Music] Yahoo! [Music] Yahoo! [Music]

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

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

Heat. Heat. [Music] Heat.

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

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

[Music]

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

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

Heat.

Heat. Heat.

[Music] Heat.

[Music] Heat. Heat. Heat. N.

Heat. Heat. N.

[Music] Heat. Heat. Heat. Heat.

[Music]

Heat. [Music] Heat.

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

[Music]

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

Down

down down down down.

[Music] Yahoo! [Music]

[Music]

Heat. Heat. N. [Music] Fire. Black.

[Music]

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

[Music]

Heat. Heat.

[Music] Hey Heat. Heat. [Music]

Heat. Heat. [Music] Heat.

Heat. [Music] Heat. [Music]

Heat. Heat. Heat.

[Music] Heat. Heat. N.

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

[Music]

[Music]

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

[Music] Heat. [Music]

Heat.

Heat. [Music] Hey. Hey. Hey.

Heat. Heat.

[Music] Heat. Heat. Heat. Heat.

[Music] Heat. Heat.

Heat. Heat. N. [Music] Heat.

Heat.

[Music]

[Music]

Hey everybody, good afternoon guys. Uh, welcome to Bites Las Vegas ground floor. You guys made it. So uh we're going to have uh the talk titled avoiding credential chaos authenticating without secrets. We have two speakers uh Chitra Dharajin and we also have Steve Jarvis right there. So before we go ahead, we'd like to thank our sponsors, especially our diamond sponsors, Adobe and Aikido and our gold sponsors, Formal and Drop Zone AI. It's their support along with our other sponsors, donors and volunteers that make this event possible. And a few of the other announcements are these talks are being streamed live. And as a courtesy to our speakers and audience, we ask that you check to make

sure your cell phones are set to silent. If you have a question, use the audience microphone so YouTube can also hear you. Uh make sure to point at uh the mic in the audience so people know where it is and that'll be the uh speaker obs. Um, as a reminder, the Bides LV photo policy prohibits taking pictures without the explicit permission of everyone in frame. These talks are all being recorded and will be available on YouTube in the future. And with that, let's get started. So, please welcome your speakers. [Applause] Hello everyone. Good to see a room full of audience completely filled with lunch here. So let's have some thoughts to share. Avoiding credential chaos,

authenticating without secrets. That's a topic me and my colleague Steve Jarvis is here to discuss. A quick introduction. I'm Chitra Dharajan, VP of security and privacy engineering at Octa. I love building high performance teams across the gloes leading security transformations. Outside of my day job, I also advise many startups in Bay Area and I love to grow along with technology and innovation these startups bring to bring to the floor. And my security mantra is all about being an enabler. Never be a gatekeeper in the career of security. and I have dropped my LinkedIn here and I'm calling my colleague uh Steve Jarvis to give a stellar introduction. >> Yeah. Hi everyone. My name is Steve

Jarvis. I'm a security architect at Ozero at Octa. And I um before I was in this position, I spent a long time software engineering on on network and security building software in that space. And that still frames a lot of how I think about security now. Outside of work, I spent a lot of time cycling. I'm a dad to a four-year-old. My favorite thing is cycling with that four-year-old actually. So, um, my security mantra is the the secure way has to be the simple way, otherwise it will become another way if it's not the easiest way. And, um, that's a link to my personal site at the bottom. Uh, once we're done here, I'll put the resources up there, too.

So, >> thank you, Steve. Uh, and a little known fact about Steve, he has strong opinions about identity and even stronger opinions about bicycle tires. So, if there are any bicyclists here, racers here, you have an subject matter expert to exchange thoughts. Okay. I want to say your secrets are safe with us. This is a very safe space. Let's come clean. Let's share your secrets. Me and Steve has taken a pact to keep it safe with us. So in today's agenda, we are going to enable you to break up your relationship with shared credentials and secrets. We'll start with something like you may be wondering what's wrong if I have a few secrets. We keep them safe.

No offense, it's just a little old-fashioned and that's about it and lot of operational toil secrets rotations. Then you may come to realize there are too many secrets that you have. Even your secrets may be having little secrets to keep. So how do you actually get rid of them? It's too much out of hands. That will be our second phase of discussion. And then we all will make together an executive decision to get rid of them. Time to break up and we make that decision together. And then we as security practitioners, we only believe what we see, right? Proof is always in the pudding. So there are going to be some cool demos about crosscloud authentication without

secrets. And finally, we leave this room in peace knowing that our secrets are safe. Oh wait, there will not be any secrets to safeguard. So we will be more at peace knowing that our secrets are cleaned out. So that's the goal and agenda for today's discussion. So enough having all that fun. No tech talk can start without some scary data points and numbers, right? So a global average cost of any data breach as of 2024 uh citing from Thommpson Reuters it's about 4.88 88 million is the cost for every single breach and this is a global average and I'm sure it's more than that but this is what the industry has called it as a quote but just within US the cost

of an average breach of a single average uh cost of an average breach is about 10 million and the cost increase is due to lot of expenses with detection tools credit monitoring services regulations fines and everything these are some tangible costs But there is also a lot of intangible cost. This is more about loss of customer trust, employee anxiety, productivity u you know down leveling of the productivity, lot of security operations work and last but not the least cost increase with cyber insuranceances. Most of the data breaches uh they start with lost or stolen credentials. So let's understand the attackers tactics. so that we can strengthen our defenses. Most of the data breaches start with you

know either it's a compromised credentials, lost or stolen credentials or harvested list of credentials from prior attacks with the aid of bots uh victim service or victims uh victim themselves are targeted for attackers successful access and thereby the data breach. So before we go into the detailed discussion of this session, we all want to remember as golden rule. Thou shalt not have the burden of any secrets. Let's call it out in our brain one more time. Thou shalt not have the burden of any secrets. Like any golden rule, there is always going to be a caveat, right? So if you must have a secret, make it a point that you have it secured in HSM or uh you know KMS and have some

automated rotations put in place. Let's say you may still need to have some secrets in your environments for your bootstrapping of your infrastructure. Whatsoever other reason, whatever may be the reason, if you still want to keep some secrets, then we need to choose what we need to keep and we need to bake automated rotations as a part of our security operations. Not when a bad day happens. It should be like everyday operations like every few you know every four weeks, six weeks when you do blue green deployments, whatever you can rotate, you should be rotating to maintain the security posture. So rain or shine, we rotate them on time. If you plan to keep a

secret, that's a liability we own. So with that preamble, let's think about a regular workday in a technology company where we have employees logging into their SAS applications like Confluence, Slack, GitHub and uh you know the CI/CD pipeline deploying the workload workloads in your CL cloud infrastructure s engineers accessing EC2 instances via SSH keys and of course services accessing many of the resources via API token. Seems like a typical IT workday right? This infrastructure is fully infested with lot of risky secrets. an employee using a password instead of corporate SSO and S sur engineer using an SSH key maybe they store them in their laptops you never know or the AWS config files and servicetoervice communications

between Kubernetes uh microservices via shared secrets and those API tokens there is credentials credentials credentials everywhere anything that get logged via logs anything that get harvested out your production infrastructure is at risk. So, Steve, what do we do about this? How do we go from here to a clean state or the target state of secure uh secure infrastructure?

>> Yeah, thank you, Chicha. You might have to mute because I think we're getting feedback. So, yeah, thanks, Chucha. So, what are we going to do about it? Well, the goal here is that we're going to move one piece at a time. Basically, we're starting with this picture on the left, which is our current state that we're how we're operating right now in our imaginary company. And we're going to try to get to this picture on the right. And the general idea is that, you know, red, bad, blue, good. So, we're going to see how we can like change these different components, the way they're authenticating with each other, how we're managing these secrets, and

like dramatically reduce the burden that we're that we're feeling. And we're going to go about this in four areas in particular. Um the first we're going to look at the engineers access to SAS and servers. And then we're going to look at how the our CI/CD which is also in GitHub. And in this picture, GitHub is going to serve as both our version control and our uh continuous deployment. How that's accessing the cloud infrastructure deploy resources. And then third, we're going to look at the API access here from our services. Our services need to talk to that API we're operating. And lastly, the communication those services between Kubernetes clusters. And at each step, we'll suggest a different design, something

different we could do, how we can improve the situation. So, first we'll check out the user off. And this initial one is probably going to be familiar to just about everybody, right? Passwords are so yesterday. So what we can do instead of a password is we can do use some public private key technology like web a IDP to consolidate identity management and we don't have those static persistent credentials around anymore. So for example in web an right your device creates and generates a private key and that private key is used to sign proof that you are you requiring a biometric to use that key to sign that to sign that assertion or that challenge is like a built-in second

factor. So we get MFA automatically in this flow. And one of the big point pain points originally with this was that that private key is strictly bound to your device. So if you made an account on your phone, you couldn't log in on your laptop and that was really not workable. So back to like a you know the secure way has to be the easy way. This never caught on because that's a huge pain. So pass keys addressed this and syncing it to different devices. So this this burden is largely gone now. We can use passwordless authentication. It's got built-in MFA and it's a huge improvement, right? Because now in the login flow that key it never leaves your

device. You couldn't leak this. It can't get fished. It can't leave. So, and also assume there is a data breach at the at the provider, right? Like Chitcher mentioned, that's like a fuel for a lot of this security incident cycle. If there is a breach and that database gets lost, they have the public key. They can't impersonate you to the public key. So, even if there is worst case breach, it's it's still relatively all right. So, this is a quick run for our golden rule of not carrying the burden of secrets. Um, we just offloaded a bunch of passwords to be the devices responsibility. Now, so the second thing we're going to look at is still in that engineer access and

right now if we have an incident and we need to access some servers, we're relying on SSH keys. So this really means that every engineer that could possibly respond to an incident, which is typically all of them, are going to have a key on their laptop that probably lives just about forever. So, we're going to build on that same um authentication flow we already have to leverage that IDP, but now we're going to use it to assume roles in AWS, temporary credentials that live for a short time and combine that with a native service in AWS called session manager. So now we don't have a need for a secure shell session here. Session manager is going to use AWS's APIs

locally to establish a shell that the engineer can use in that environment. And so not only here are we um eliminating some of the risk that we are carrying from these static credentials, we actually get to harden the host at the same time because now we don't need any ports open to the internet. And this is a very AWS specific picture. But again, like the the things we're painting here are just for example purposes. The other major cloud providers have the same concepts available. Right? So quick recap. We're moving through this picture really well. We've already kind of made a happy story out of all of the uh engineers access, right? There's no secrets that we have to worry about

in that in that part of the picture anymore. So now we're going to move a little bit right over to the CI/CD and again that's in GitHub's workflows and that's what we're using to actually deploy our services to these clouds. So what we've been doing so far in GitHub workflows is provisioning static secrets right for deploying the AWS services we have IM users access keys to get stuff into Azure we have the client ID and secret for a service principle and those workflows you know pull those secrets out of GitHub secrets deploy the infrastructure and that all that all works all right but we would love to not need to provision these right So what

else can we do? Well, in this case, GitHub can actually act as an OIDC issuer, right? It will sign tokens for your workflow as a feature of GitHub. And so now we can kind of use that as the identity provider to assume these IM roles and entra service principles. And we don't need to provision any secrets anymore in GitHub. All we need is configuration. It needs to know what IM role ARN to look at, what service principle to look at. We need to establish the trust in these clouds to say, you know, we have an IM roll here and if I get a token, an ID token from GitHub, it's allowed to do whatever this

iron roll is allowed to do. It just becomes configuration. There's no more secrets in the picture. And we can and should lock that down to the specific, you know, GitHub repository and branch and you really easily have that level of specificity when you're defining those rules.

So more quick progress. We've got a great mechanism for our human users. No more secrets there. Our CI/CD has limited the secrets from our um from those workflows. And now I suppose we should check out what our actual services are doing, what we're building, how are they communicating with each other. So if we go all the way to the right side of the diagram here, we have this service running in Kubernetes and Azure connecting to an API with an A API token. So an API token here, this is a a preconfigured shared secret uh probably has an indefinite lifespan. And there's a lot of risk here because if this this is transmitted as it is

across the way, right? it exists in the same state on the client as it does the server. If we ever have a software bug or a logging error on either end of this, we're going to put that API token in a log somewhere. Any software vulnerability, we could leak it. Um, we we would really love to change this. So, what else could we do? Well, we can use uh another some more private key technology, right? And we're going to do something called a private key jot. And what that looks like is we generate a public key pair. Our service will sign attestations with that private key and submit them to our IDP. That IDP knows about our public key so

it can verify that we are the client that holds this private key, right? I trust this. We're going to give you a token and it will issue an access token. That access token is what we can pass then to our API. And this access token is is shortlived. it can live for hours, minutes, like how long do you need it? And we could very easily run through this flow again to refresh it. So now if we have a problem and this key, this this access token that we're actually submitting to the API ends up in a log or ends up breached, there's a very good chance that it's expired by the time anyone's able to do something with it,

right? And that's actually not all. There's another really cool little win we get from here besides just the secrets management benefit because this is fully like ooth 2 and we're getting a jot issued from an IDP. Now we can also leverage custom claims and scopes here at the IDP and those end up embedded in that access token. So before what we had like a really opaque generic API key that get passed back and forth. Now we have an ability to define authorization values, right? Scopes, claims, and the token at that IDP. So we've like gotten more power to our kind of IT administrators to control exactly what this service is allowed to do at the

API. Not just that it's allowed to access it. Now we get more knobs to turn here. What ends up in that access hook and what do we want to enforce?

So cool. With that change, we're threequarters of the way through the specific topics that we wanted to fix, right? We have removed all the credentials that the engineers had access to directly to access the SAS and the servers in the cloud. Our CI/CD is like happily humming along with no provision secrets. The services that we have running in Kubernetes and Azure, they no longer need a static API token to interact. The last thing that we want to look at is the communication between these two services. We have clusters running in each cloud and we want them to be able to talk to each other. Right now, those two services are using pre-shared secrets to communicate. And

this is working, right? It just means we nothing magic about this. we just developed whatever a 30 character magic string and we make sure everyone knows the same one and then they can talk to each other because no one else would know the same thing if we didn't put it there on purpose right um and that works but it's really actually a pain on redeployments on fallbacks because there's this is a distributed system so we're trying to update if we have to do rotation we have to update this pre-shared secret at a bunch of disparate clusters right it's a difficult thing to do and it's causing us a lot of heartache So we would love

to change this to rely on some PKI and mutual TLS and we can use the certificates that are issued to these workloads to establish that identity and that root of trust. So then the real anchor of trust and the longived key it's no longer these pre-shared secrets. It's the root CA private key and that we can store in something like an HSM. So it will just issue in real life. There would probably be more levels here. It's not going to be the root just issuing search to the cluster, but say we have an intermediate here. But the point is this one's locked away in an HSM or even something physical like a bank fault. We have

intermediaries and then these ones that are used as identity for the services in the cluster. We can rotate those on every deployment. Every time we ship out a new cluster, just change it every time. So like it doesn't become an event to rotate anymore. It just happens. It's a normal day. We're shipping an update. We're going to get new certificates issued. So Steve not every sorry so not every infrastructure is mature to do the MTLS authentication right this requires a lot of service mesh uh configurations so what are the other mechanisms that we can secure the serviceto service communications >> yeah good question and that's fair because this establishing PKI we have to do device attestations

there's probably like you mentioned uh service mesh to actually control the access policies. There's a lot of prerequisites for something like this. So instead, yeah sometimes we don't really need a BMW. A Camry is perfect. So thank you. Uh we can improve the situation a little bit using this pre-shared key that's already present. So instead of passing that pre-shared key directly, we can use it as part of a building our own jot basically or JWT token, we can put the what the values that we need in our own jot and we can use something like happy iron module with that pre-shared key to both provide integrity and secrecy to that. We'll authenticate and we'll encrypt that jot

and on each side we have that pre-shared key. we'll be able to seal it on the sender, unseal it on the receiver, and then we get a little bit for improvement. Like it's a admittedly a modest improvement over compared to something like a full PKI and MTLS, but it's for quite low cost.

So it Yeah. >> Yeah. So it's it's a simple improvement. We we do improve the picture here by using something like an iron token. >> So Steve like uh as a part of this conversation we are supposed to walk the audience through a very cool demo, right? We are supposed to talk about cloud-tocloud uh resource access via authentication with no secrets. >> Uh yeah, first I want to touch on actually the difference between like why is this still an improvement because we're still burdened by these secrets, right? So yeah, we'll get to that in a second. That's good. But first, when we started talking, we talked about how we're going to like remove these secrets from our system. And now in a

couple places like here with this pre-shared key, we didn't actually remove it. And before, if you remember, we were talking about the access to the client API. We just exchanged an API token for a private key. Like we still have stuff we have to take care of. Are we really reducing the burden? And we actually are because in situations like this, they never leave the host. A private key or this pre-shared key now, it never leaves the service that it's provisioned for. It doesn't go over the wire. It doesn't end up on a server. And the token that does get sent is short-lived, right? So if it there is an issue, it'll expire quickly. We can

rotate without worrying about a broader, longer lived impact. And private keys we can lock away relatively more securely. HSM, KMS, something like that. So even though we do still have secrets, we are making better choices about the types of secrets that we have, how we rotate them as a regular part of deployments, and how we store them and manage them. So even though some still exist in our system, they always will, we can make better choices about what they are and how we treat them and still significantly reduce our risk. So in the end we end up with a happy all blue picture, right? The all we have all the connections we did originally all the

services are doing this the same functions they were they have the same authentication going on. But in this state, all the secrets are managed by like the IDP stored in HSM. There are credentials that are in the system but rotated as a regular course of say our deployments every week. And it's a it's a much better spot to be in. It feels good. >> Yeah, we still need to >> Yeah, we still need to walk our audience through that cool demo. That's >> right. We do. >> Yeah. So do you think we all we talked about is securing access uh of user CI/CD service to service authentication but many tech infrastructure is all about multicloud ecosystem right a

service running in one cloud accessing a resource from another cloud and vice versa so do you think we can federate identity in intercloud communications? Yeah, good question. I do. So, let's look at that. I think we can um extend this a little bit because this is a common use case. So, I love this. This is um say we have services running in one and how do we authenticate to APIs in the other. So, this is a little bit different than the interervice communication we just had. Now say that we have maybe like a management plane that's running in one cloud and we need to reach out to the APIs of the other right how can we federate across clouds

without secrets here. So that's that's what we have and there's kind of two different mechanisms we're going to talk about doing this because it's going to go in both directions. So on this side here we have Azure running Kubernetes on AKS with a single container and we want that to be able to assume an IM role in AWS and then again all the rights and privileges that that IM role has on the other side here we're running again Kubernetes on a EKS in AWS and it starts out the same Kubernetes is going to issue a service account token of this container and that's just a feature of Kubernetes natively so that part's the same on both

sides but on this AWS side we have more components And the reason for that is in both of these situations when Kubernetes issues that service account token the issuer or that trusted identity is going to be tied directly to the cluster ID and that might be fine but if we're talking about hundreds or thousands of clusters or redeploying them regularly now we have a new problem of like how do we here we need to know what ID we're trusting and if that's changing every day um they might be able manage that or maybe not or maybe so the point here with these extra components is we ultimately get an ID token is issued from cognto. So if we think about

this in like layers of the infrastructure we have in say in terraform we have the infrastructure that defines things like the ID providers the clusters themselves the IM roles then we have kubernetes the actual manifests and that's where we're going to find what services are running how those AKS and EKS clusters are configured and then we have the actual applications and some of the challenge here is that when we change that like redeploy the Kubernetes cluster it has ties to the infrastructure level configuration So we would need to manage that a little bit differently by introducing Cognto as an issuer there. What we get is a stable trusted issuer in AWS that is separated from the EKS issuer. That make sense? So

we've we've kind of broken the intrinsic tie between this and ultimately what Entra has to trust. Cognto will stick around across cluster redeployments. So in this case, Cognto is helping us persist the ID that's being federated across the cloud. >> Exactly. Yes. Yes. So this is running now and what we're going to do is we have three problems at key points. So th this is all set up. This is running and we have three issues. The first one is from Azure just trying to assume that I am roll. we have a bug with that role assumption. The nice thing is the Azure AWS story is pretty simple. There's only one hop. So that's where the problem is. We know it is in uh on

the AWS side. We have two more problems. One is we get the service account issued but we're failing to assume that IM RO with Ursa uh Ursa IM ROS for service accounts as an AWS service feature. And the third one is actually being able to get that ID token from Cognto. So, um, give me one moment. I'm gonna switch to mirror mode because I'm gonna actually really do this live, but I can't see what I'm typing on the this mode.

Where'd my stuff go? >> Okay. Okay, great. So, so this is running on the top left. Um, in this pane, we have the the live output from the cluster or from the application running in AWS. And on the right we have the output from the app running in Azure. We're going to stop with start with the one on the right. So we see it has failed to assume the as well. There's no open ID connect provider found for this issuer. Like I said this is this is kind of the issue of the cluster ID changing. This format looks like this is the subscription ID and this is the cluster ID. So every time we redeploy the

cluster, fail over, roll back, that's going to change. And we're going to actually look at the the source code for this. And this is split up in like the same kind of um hierarchy I described it earlier. We have Terraform defining the infrastructure. We have Kubernetes manifests defining you know how Kubernetes is what Kubernetes is running. And then we have a couple Python apps, one running in each one. And the goal of those applications is simply to assume the role and dump something about the identity in the environment just to show that we have act the desired access. Right? So the first issue here is that this issuer was basically the last version of our Azure cluster,

right? We redeployed it. We forgot to change this. So I'm going to comment that out. And in this case, I have the correct value provided as a variable because of course this is all defined in one repository. I'm just deploying it here. So I know what the correct value is already. So once we um redeploy that, I'd expect uh the logs on the top right to automatically correct themselves. So what's going to happen is this I have make targets so I don't have to think too hard here live but it's just going to run a terraform apply right now and that will fix um the IM role identity provider or specifically the IM identity provider that's allowed to assume this

role to match the actual cluster ID that we have running over there. So with every blue green deployment, if we reconfigure the issuer ID in the other cloud, federation makes it easier. >> Yeah. Yep. Yeah. And this is something that could be like I've automating it here. There's a solution here. I don't mean to over complicate AWS. There's probably a fix on this one, too. There's just going to be trade-offs whichever way you want to go. Okay. So that'll turn green if it doesn't make me a liar.

should have made it sleepless. Yay. Green. So now we see we we have the issue that we changed it to. We and then the proof in this pudding is that we assumed the role or role in AWS. That's just a call to STS who am I right? Okay. So now we're going to keep going on. We're going to look at the second issue here over in AWS line now because now Azure's worked and we're going to shift our focus to AWS. And here we see that we are not authorized to perform that assume ro with assume ro with identity. So we have a Kubernetes service account. We want to change it into an IM role and we're not authorized

to call that. This one's a little bit more opaque, but again, I get the advantage of having written these bugs on purpose so I know to look in the uh service account annotation that we put on Kubernetes because this is how you assume a role with IM ROS for service accounts with Ursa. You add an annotation to the pod for a role that your Kubernetes pod is allowed to assume. In this case, we have the wrong ARN. And we know that because wrong is in the name. So again, looking at the EKS config here, this is another relatively simple mistake to make, but we're going to change that annotation to be the correct AR for the role that we're actually

allowed to assume. We're going to deploy those apps. And um so make deploy apps that's going to apply that Kubernetes manifest that we just updated. And then a refresh is simply going to scale down the deployment and scale it back up. So I force it to you know take up the new config, deploy a new pod, take up the new config.

While that's thinking, I'm gonna just start talking about the third. Okay, we'll come back to that in a second because it should just take a minute. So, the third problem here is once we fix this problem, we'll actually have a have an Ursa role that's allowed to use Cognto and then we want to make the call to come to say, "Hey, I'd love to get an ID token from you with that nice stable issuer." And then use that to assume a service principle in Entra. And for this final problem, we're going to move up to the application level. We have a couple Python apps here. And the problem here is going to be pretty simple. Basically,

we have that service account token that's issued by Kubernetes. Kubernetes issues that with prefixed with the protocol of the issuer, HTTPS, Cognto doesn't want the issuer. It just wants the domain and the rest of the URI. So, we're just going to get rid of it. Um, and that's that. Once we have that, Cognto should happily issue us an ID token because we're saying then that our, you know, we want to use that login, the issuer that you expect that we've configured you to be allowed to accept to accept an to issue an ID token to. And here's ours. Um, but first, let's check to see if we got past that last problem.

Yeah. So before we still have a problem, but before we were not allowed to assume RO with web identity. Now we have a role. Now we just have an invalid login token. And obviously and if I check the service account annotation again, we should see it updated to be the actual EKS workload role that's allowed to be here. So one more bug fix for this final step and it should light up all green. I think for a second I changed the application. So what I need to do is rebuild the containers and push those to the registries. So this is actually going to build into a image locally push to ACR and ECR and we should be set there.

Okay, since this is going for a second, why don't we move on to the uh learnings? Pushing was pushing was quicker before. A lot of people in here, so that's all right. I'll move on to u some of our takeaways here and we'll come back and check on the sash that in a second. >> So the key takeaways uh which we want to reiterate for the audience here is thou shalt not have the burden of secrets. The golden rule right so it's incumbent upon us to design in a way to remove static credentials wherever possible. Let's say if there is an opportunity to leverage passwordless solutions for people login be it SSM or pass keys go for it.

utilize managed identities and uh trusted IDPs for serviceto-service communications sorry service API communications and service to service communications whether it could be an MTLS or some kind of iron tokens where the shared secrets is not sent across the communicating entities. So coming to the second part, the caveat number one, if you must have a secret somewhere, thou shalt secure the secrets, right? Think about HSM or KMS. Think about uh securing them in the with the hardware protection there. And if you must keep some secrets in some environment somewhere for whatsoever reason, it's incumbent upon us to make sure that we frequently rotate them. So choose the right secrets to keep and bake them as a part of your

regular rotations in your operations. So let's keep these golden rules in mind uh when we build our systems when we build our infrastructures. Thank you. >> Awesome. Yeah. Thank you.

And I'm definitely going to show this all green in a second, too. I can't I'm not going to leave it broken. >> Live demo is always tricky one. Like, you know, Steve, you did it awesome.

>> Yeah. any >> any questions or thoughts or I'll just talk for another minute. Yeah.

>> Hi. Uh could you explain a bit more about those iron tokens and how they work? Are they I'm guessing they're just like a certificate. No, the the iron token is going to do like a password based key derivation to generate keys bas you give it a just a string a random string that you share on each side and it will generate the keys necessary to do the the crypto for the authentication and the secrecy kind of on the fly. >> Okay, thanks. >> Yeah, screen. Sorry, I just so anyway

All right. Thanks everybody. >> Thank you. >> Thank you guys.

What's it? [Music] Woohoo! [Music] Dirty

[Music] Baby. [Music] Hey. [Music]

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

[Music] Heat. Heat.

Heat. Heat. [Music]

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

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

[Music]

[Music]

[Music] Heat. Heat.

Heat. Heat. [Music]

Woo! Wow! [Music]

Heat. Heat. [Music] Heat.

Heat.

Heat.

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

Heat. Heat.

[Music] Yeah, [Music]

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

down. [Music] Down. [Music]

down.

[Music] Hey hey hey. [Music] Hello everybody. Good afternoon and welcome to Bside's Las Vegas ground floor. Uh so this talk is hacking secure ed secure coding into education by our speakers today or Sahar and Yuriv Ta. Um yep. So, um, before we begin, a few quick announcements. We'd like to thank our sponsors, especially our diamond sponsors, Adobe and Aikido, and our gold sponsors, Profit and Run Zero. It's their support along with our other sponsors, donors, and volunteers that make this event possible. Next, these talks are being streamed live and as a courtesy to our speakers and audience, we ask that you check to make sure your cell phones are set to be silent. >> Forgot the camera.

>> If you have a question, we will provide the audience microphone so that YouTube can also hear you. This is the audience microphone I'm holding in my hand right now. Uh, as a reminder, the Bides LV photo policy prohibits taking any pictures without explicit permission. These talks are all being recorded and will be available on YouTube in the future. And I would request some if you guys could move to the front just so that we can have those who are coming in to be seated in the back. With that, let's get started. Please welcome your speakers. [Applause] >> So hi everyone and welcome to hacking circuit coding into education. We're very happy to be here.

My name is Oal. I was a developer for many years. 10 years ago, I switched my career path into cyber security. Um I do not I also enjoy penetration testing right now and also do some consulting and secure coding workshop in the governmental section and also in the private section. My drug of choice is Snowy Mountain and this is Vice Smith uh summit in Switzerland. Hi everyone, my name is Yariv. I was a developer for many years uh 40 years and I also lectured in universities, mentored in boot camps and uh f about five years ago I became an ABSC researcher and my drug of choice is roller coasters which is why I'm upside down.

>> Not only not only because of that >> so oh education why do we care? >> Why do we care? Why do we care? 2025 and code is still insecure. The same vulnerabilities appear again and again and again. Y are we still talking about SQL injection? >> Yes. So apparently we are even though it was first discussed 27 years ago in 1998. Um still in 2023 we had a major SQL injection related breach the move it breach which every of you remembers >> with 9 billion dollar loss. >> Yes. Uh so much so that 2024 Uncle Sam said they will no longer forgive SQL injection flaws. Uh but or I don't think it's much better with other

vulnerabilities. Is it? >> No. The same goes for XSS, puff traversal, um, insecure file upload and more and more. And now we have the AI as well. So, and more. I said AI for the first time and the last time maybe. So, we had a huge ecosystem. We have so many tools. We have SAS and DAS and SEA and we have threat modeling and we have all these tools and methodologies usually happens after the code is already produced by developers except from threat modeling maybe maybe sometimes. So Y tell us or hurry tell us why do we keep failing. >> Well, if you'll Thank you. Uh, my son learned in high school internet programming. That's what they call it.

>> And >> vulnerability programming. >> Internet programming. And they needed to do a user login, check the username and the password. Here's how they taught them to do it. Okay, it's a bit hard to see, but who sees the vulnerabilities? >> How many vulnerabilities? help us out. >> At least two. At least two. >> At least two. You're almost there. Who sees? Well, anyone. >> Right. >> Okay. Yeah, you can do SQL injection on both the name and the password because they're not san validated or sanitized. >> What more? >> Well, here's a here's a nice one. They use like. Anybody knows what like does? It's like a wild it it uses wild cards. So basically if I I pass for the

password the percent sign that's a catch all. So no need to for SQL ejection even. And the third one is what did they forget to to show that you have to do with passwords. >> Hashing. Yeah. >> Someone said it over there. >> They no password hashing. So three vulnerabilities in a single slide. And this is how we teach. So >> not us. >> Next slide. This is our >> true not us. This is how they teach. Thank you. >> So if this is how how our students are taught, how our programmers are taught, how can we expect code to be secure? I mean it's it would be ludicrous, right? So we decided and Rachel here remember

we shift all the way to the left to the beginning of time before developers become developers. So, >> so 2022 we went to ABSC global in for of OASP and we said coding education must change and we gave this lecture and we were sure that universities will learn the errors of their ways and start teaching secure code and high schools will teach their students to do parameterized queries and not >> concatenating strings and nothing happened. So we did it ourselves. Oh, remind me how did we uh manage to get to reach high schools? >> Yeah. So a good friend of mine is a computer science teacher in high school. So we reach out to him and we asked him

give us your materials. He shared his materials with like three or 400 teachers all over the country. and we asked him to see the materials and we make some comments about the material. We said we asked him to change this and to change that and we had a lot of discussions about that and it took a lot of time and nothing has been done. So he said like okay come to my high school give us a workshop we we are not going to change the materials right now it's a lot of work but come to my school teach my students. We went uh high school students we we gave a workshop. It was very good. They like

it. Uh it spread the word for us. Uh talk about the workshop with other student with other teachers all over all over the country. We also went to a computer science gathering at the summer and we we spoke to them and they helped us to spread the word secure from scratch and we started to to go all to to travel all over the country to uh to share our knowledge. Yeah. >> But this wasn't enough. Somehow we found ourselves teaching in universities. Um well again back to you. >> Yeah. So if you wonder uh if linking is a good tool. So we are the proof that it actually is. So someone some one professor from one of the university

universities in our country addressed me and asked me if we can teach their students secure coding. And he so he he knew to to to send me a message because of my post. So yeah, we said of course I say yes and then I called your email. >> Yeah, we had nothing ready. >> Not even a syllabus. >> It's a full semester like 13 uh 13 uh uh lessons of three four hours each. >> Four hours each. Yes. >> Yeah. I think >> and this is like four weeks before the semester is about to begin. >> So we sent a syllabus. >> It was very nervous. Yeah, I I after every every time I gave

the lecture to the students there, I came home and I I didn't even take the the rest of the day off. I was like, let's start the next week, otherwise I'm going to I'm going to have nothing. So, I wouldn't suggest, okay, this is how we did it. Don't go and do it yourselves this way. But we pretty much wrote the entire semester during the the semester itself. >> Yeah. And then >> and then after a while >> number four >> yeah I'm looking for it because I forget how to say it in English. Um so after a while someone told the national cyber diretory in our country someone told us about us. So they called

me and say why do you want us to give your name to all the universities around the country some colleges? Yes, of course. Are you available for all of them? Yes, of course. We're going to go everywhere. So, yeah. And then we found ourselves like each one of us in a separate academic institution um sharing the same knowledge, the same course for everyone. Yeah. >> Yeah. which uh kind of gave us the idea to scale up by using YouTube and we uh filmed some uh reels to make it easier for us to go to that many universities. >> Yeah. >> Which brings us to the next item everyone else. So um yeah, our >> now we come back after San Francisco. We

went to San Francisco. We went to spread the word all all we went to spread from scratch all over the world. Then we come back to the country and now we come we come back to the states uh with you know we we really want to help everyone >> and since we have YouTubes so everyone can watch them everyone can learn it's a full well it's going to be a full course because we're redoing the YouTubes uh with better visuals um and of course we want to spread it so we also give workshops worldwide including in defcon and Uh, of course we are talking >> third time. >> Second time the workshop, right? Third time. Third time. Wow.

>> Wow. And uh we also were also talking about it here in Visas Vegas. >> So that's another thing. >> Um and uh of course you want to know how do we build workshops that developers like >> because we all know those workshops that developers just see them and want and they're like it this is a punishment. I would rather go back to work and we don't like that. >> Yeah. So what do we do? The secret is that most of the developers they don't like to know everything about security for sure. They don't want to know all these special magic uh terminology that we use S XSS, CSRF, SSRF, RCE. I'm getting very excited when I hear RC. Like I'm very

happy. I I want to to be able to get RC in every penitation testing I do. But for for developers, what are you talking about? Just leave us alone and let us build. We want to build. So when we create workshop, we focus on coding. We don't just, you know, tell them this is a vulnerability, this is how we fix it. No, we give them some tasks and we know to put a trap in in the task like we we tell them develop this and that and then we know that they will they will do it in the wrong way like >> 11 11 out of 11 out of 12 developers uh fall in our traps. So we know we know

that they're going to do it wrongly and then after they you know they try the task the um the lab by their own then we know okay now let's hack to your um let's hack to your uh solution and some developers they don't like the hacking step so so it's fine we leave then okay you just need to develop if you want to try the hacking phase it's fine otherwise we'll show you how we hack into your system so not everyone the one who does like it enjoy the other ones okay just go ahead Uh so we prepared a skeleton and they build into the skeleton. Um we gave some actional advice. We also took all the

information. We have a lot of information. There is OS top 10 that is mainly for security professionals. It's just it's more like what not to do than what to do. And there is also other projects that um uh deal deal with security guidelines. But it's a lot of five minutes. Yeah, I cannot see. Well, >> we're good. >> Yeah. So, um, so we condense all this information uh to prevent and we show you. >> It's on the next slide. >> Yeah, it's the next >> one more. >> Ah, more. >> There we go. >> This is prevent. >> Prevent. >> It's an acronym. And um, it's it's a good acronym. How do I know? Because I

use it myself. I when I write servers. It's good because you created it. >> I admit I I we both we co-created it but um I actually use it myself. Okay. It's not something that's academic or it will probably work. I it's inspired by solid if you know solid from object-oriented programming. So the idea again was let's have an acronym that helps people uh program uh securely. And we're not going to go over it. Don't worry. There's a YouTube on it so you can just go and and look at it and even after that it requires training to to really get into it. >> So we have a lot to offer. What do we have?

>> Well, >> what do we have? >> Okay, so first of all, oh, sorry. First of all, this is my my uh minor project in OASP Oasan Trust. It's not something big. It's I just uh a project that replaces uh right now just the path library in Python and in Java. And the idea is if you use this, it's kind of like the parameter query version for paths. Once you use this, you can never have a path traversal. Never. It makes it impossible. Just like parameterized queries makes SQL injection impossible. The same goes this does it for paths. So you can go and take a look uh and use it. That would make my day. But it's

really just one small minor uh pet project of mine. The bigger ones are Yeah. So this is our repository and it's an open source and we uh we put there everything like every workshop that we give in high school or in the university or even when uh the private sectors when private customers they ask us a workshop we develop the workshop they pay the money for the workshop but then we share it with everyone like and and they you know they're totally fine with it. This is how they sponsor uh the uh the materials that we share with the community. So it's fine and yeah so everything is there. Please feel free to use it uh to give some maybe

um where is that? >> Oh that's me. No, no, go back. That's the YouTube >> Oh. Yeah, of course >> it's supposed to >> to run and show the YouTubes. Try moving one back and one forward and one forward. Oh, there. Okay. So, this is just a sample of our YouTubes uh and the evolution. Okay. It was really bad in the beginning, just slides, but got better. This is the our newer version. Um I'm saying showing you the iteration for two reasons. One, if you're doing a project, don't despair if it if it doesn't look nice the first or second time. You'll have to iterate. And two, the English versions are being transformed and still some being a lot

of them are being recorded. So, don't be despared that there's not a lot of out there in English right now. It's it's going to be there. And uh we have Hebrew versions which we will put translations subtitles into English. Um just give us a couple of days. Actually it's our philosophy as much as we agreed to fail in the first time. The YouTube were bad also you know my very first you YouTube um about secure from scratch were really bad and then we we agreed to fail as much as we encourage our students to fail and then learn something out of it. >> Um, so this is a call for action. Please spread the word about secure from

scratch. Send us your feedback. We are very we really need we need your feedback. Um, if you want to provide walkthrough, it's also uh be very good and um >> arrange a workshop. Yeah, if you want to develop a workshop and share with us, we put it in the repository uh with and we share it with the community. >> Yeah. Or take the workshop from our uh GitHub and do it in your workplace or um of course you can do the course. >> Yeah. The Java course. It's like a full semester course in Java, secure coding in Java. >> And >> summary 2025 and code is still insecure. The same vulnerabilities appear again and again. We want to shift all the way

to the left to the beginning of time before developers become developers. Even now it's more important because we saw developers what they do they use AI. AI use between 40 to 50 AI create 40 and between 40 to 50% of the time vulnerable code. So we want our students to learn how to code securely and or to ask the agents to to provide secure code and I say AI in the second time. So please help us, help yourself, help your friends >> and the >> and what >> voila demo. >> Okay, >> demo. Ah, we have >> So we actually have more time than we thought. >> Really? Really? >> So I'm just going to show you uh a short a

small demo. >> Yeah. Um, usually there's some preamble to this explaining things, but this is like how we do it in high school for example. There's no network, no web. We just say it's imagine a computer that your teachers put in the whole room and they put a questionnaire there and you you can you come to this computer, you put in your name. So, I'll put in my name. >> Yeah, it's super simple. You don't have to know any framework or a web developer like just a very simple console >> and you get the daily uh question which today is the what is the capital of Assyria who who knows where this is from really no Montipy one Montipython fan

okay so I'm going to answer uh give the wrong answer here and okay so imagine many students come and do is and then the teachers the end of the day they come and they say that they are the teacher and they get a list of who was right and who was wrong and let's do one that's right is going to be right and again the teacher all right and now the big question the teacher said they're gonna do this for three months with many many questions and of course I can Google the the answers but I'm lazy I want to >> there's no network >> I want the teachers >> no network >> I have my phone I want the teachers to

think I am right even when I am wrong so I want a method that I can pass these three months so I their teachers always think that I'm right and the question is what can you put here. So, you hack the system and when the teachers look at your name, they see that you are right no matter what. >> What? >> Ah, nice one. Okay, let's try that. And oh, illegal characters. But that's easy to uh I'll just use. Yeah, I think it's because >> I think you ran you ran the >> Yeah, I'm I'm one of the more advanced >> one of the fixed version, but it's still vulnerable. >> Yeah, it was supposed to be vulnerable.

See, this is why demos never work. But uh let's assume that the the column this is actually a fixed version. Well, one attempt to fix. And the problem with your suggestion though is that it doesn't work. see wrong right >> it doesn't work it doesn't make me look right >> it's a good idea though >> yeah the students also suggest this this one but also there is another disadvantage because some of the people their second name is right >> so uh you cannot block their last name you have some issues with >> so we're not going to solve this you can go and do it >> in the YouTube as a walkthrough so we're not going to solve this but you see this

is very simple scenario because it's for high school. >> Yeah. >> And and yet there's an element here of h what can be done? There's a there's an intentional element that's supposed to be at least an intentional element of mischief and uh and uh rivalry like how can we cheat the system? And after they do that and they understand hacking, we go with them to okay, how do we protect it? And of course they offer all kinds of blocking methods. We show them why that doesn't work. And uh >> yeah, >> that's basically it, right? And now questions. >> Go back to the >> Oh, go back to >> Yeah. >> Thank you so much.

>> We have time. Five minutes for questions or no time? >> No time. All right. >> Yeah. So, thank you so much for coming here today. >> Yeah. If you have private questions, we're here. Well, outside, I guess, but but here.

Uh >> a desk we [Music] Heat. Heat. [Music] Woohoo! [Music] Woohoo! [Music] [Music] Boo. [Music] Boo. [Music] Fire. Black.

[Music]

Actually,

>> hello everybody. Good evening. Welcome, welcome. >> Uh, welcome to Bides Las Vegas ground floor. This talk is going to be about Luminina casting light on shadow cloud deployment and is given by our speakers Chapen and Britney. Uh, a few quick announcements before we begin. We'd like to thank our sponsors, especially our diamond sponsors, Adobe and Aikido, and our gold sponsors, Formal and Profit. It's their support along with our other sponsors, donors, and volunteers that make this event possible. Uh, these talks are being streamed live and as a courtesy to our speakers and audience, we ask that you check to make sure your cell phones are set to silent. If you have a question, please use the

audience microphone so YouTube can hear you. So, I'm holding the audience microphone. I'll bring it around if you have a question. As a reminder, the Bside's Las Vegas photo policy prohibits taking pictures without explicit permission. These talks are all being recorded and will be available on YouTube in the future. So uh if you are coming in, if you just walked in, please move to the front so that we also have audience who are coming in can sit. Uh with that, let's get started. Please welcome our speakers. [Applause] >> Awesome. To get started, any incident responders in the crowd here? Couple. All right. Anyone dealt with a cyber issue that resulted from an exposed cloud resource before? Of

course. All right. If you have or have not, welcome. Hopefully we can shed some light on shadow cloud deployments. >> Yeah, thank you all for coming. Um, this is actually really great timing like with the the talk before was all all about shifting as far left as possible and looking at secure coding as a part of education. We're going to be talking about as far right as possible like when everything's already out and try and figure out like how to how to detect those resources and and start that investigation. Uh, I'm Chapen Bryce. Uh, I'm a instant response consultant turned developer. Uh these days I focus on cloud infrastructure and threat data. >> And I'm Britney Ardus. Um I've hopped

around the consulting world a little bit. Did a little bit of private consulting, government consulting, and now I'm on an instant response team um at an enterprise. Um so one thing we've noticed uh through our combined years of experience um is that as cloud has become more popular um the same security issues leading to vulnerable exposures has also moved to the cloud. So it's no longer your, you know, web application that's hosted in a data center per se. That's your initial access vector. It is now living somewhere in the cloud and is easier than ever to deploy. Um, so as an incident responder, where do you actually start with dealing with some of these issues? Um, there's a ton of tools

out there. We did a lot of research when we initially had this idea. Um, a lot of brilliant people have built some great solutions with respect to perimeter scanning and network mapping. um that what we were seeing didn't really fit the bill for an instant response perspective. You know, there were some SAS tools out there. There were some that were more catered towards pentesting and red teaming, but nothing that was really instant response focused. Uh so we decided to build our own. So where are we actually seeing this? Uh we wanted to kind of generalize and categorize um different scenarios where we would probably be seeing these types of exposures. Um the first one being um

you know organizations that didn't necessarily have adequate logging or governance established which isn't necessarily unique to cloud per se but we did see that it was kind of a generalized trend. Um cloud technically is kind of a new concept um that's still being adopted by organizations and being rolled out. Um and as a result policy is still being written and adopted as well. So it's easy to cut corners um and not have adequate guidelines in place. you kind of adopt this just get it running mentality. >> The other place we frequently see it is the the shadow infrastructure, the shadow IT. Uh once again like shadow IT is just shifted to the cloud. What was

shadow IT that maybe was only internally accessible before is uh is now having public IP addresses. Um the barrier to entry for getting a public IP and putting resources online is a credit card free tier, right? folks were able to spin up in uh resources that um maybe were problematic when they were internal but now have a much higher exposure. >> Yep. So why and how is this actually happening? Um apologize for any of the introverts that are out there in the crowd right now. I'm going to ask for some audience participation. So buckle up. Um I'm going to go through some excuses that we have heard from resource owners in the past for why they have

exposed those resources. Um, if you've heard this one, please raise your hand. This is just a proof of concept. >> So, like I'd say most of the room uh raised their hands. Uh, how many of those same folks? How many of those turned production? >> Yeah, I've seen it, too. I saw it in this past week. >> Next one. Don't worry, it's just test data. >> Yep. Uh, about the same number. A little bit less maybe. Yeah. >> Yep. Exactly. Yeah. That's a clone of Prague, but it's in our dev account, David. >> Yeah. So, like, what does that actually mean? Uh, is it like what what is test data? Is it your just production data in

test or is it actually sanitized? Is it generated from scratch? Like, yeah exactly. >> A lot of questions. Uh, >> dev accounts aren't safe just because they're dev. >> Yeah, >> exactly. And then finally, I didn't know it needed a security review. Yeah, a little bit less on this one, but this goes back to the just get it running mentality. I see this one frequently with that. >> Um, so that's fun, but let's kind of dig into the scary part of this. Does anyone remember what happened with the AI company Deepseek around January of this year? See a couple nod. Yeah, I thought so. Yeah. So, if you're not familiar, um, the the security research company

Whiz published an article where they were able to identify a ClickHouse database that was publicly exposed on two different ports. um they were just kind of enumerating the the internet were able to see that there were non-standard HTTP HTTPS ports out there. This ClickHouse client was fully unauthenticated. So as you could see from this screenshot, they were able to execute SQL queries directly from the browser. So you could see all the tables that they were able to dump and execute it directly from the browser. Um you know this is worst case scenario. Uh they were able to dump full chat history. um you know they also had full um backend issues and and um some

sensitive datas that they were they were also able to to dump as well such as log streams, API secrets um and other proprietary information. Um so this is uh obviously worst case scenario. Um but it's a prime example of how exposed endpoints could be exploited as an init initial attack vector. >> Um >> obligatory. Yeah, and that was our obligatory AI mention. Here's what we normally see. You know, that's what hits headlines. This is what we see probably more common, uh, cryptojacking. So, it's not necessarily your full network takeover or PII database being dumped. It's probably just a really huge bill from CPU usage. Um, one thing that I did want to mention before I move on is, you

know, I think we kind of associate web applications and even cryptojacking with Linux systems. Um, as we were looking at different case studies, we were able to see that it wasn't necessarily uh focused on Linux systems fully. You know, there was um a CVE in 2017 affecting Oracle Web Logic servers that were running on Windows systems that thread actors were able to exploit and run Monero on. So, I don't want to hear anyone say that they're safe in this room because they were running Windows on their systems. Just kidding, but not really. >> Yeah. So, uh, there's a lot of great tools out there as we were talking about before, and these are some of them. Um,

they they really have a different focus than than Luminot on, uh, that continuous monitoring. Some of them are SAS focused. Um, looking more at the pen testing side. Um, Prowler is actually here this week at Defcon. So, check them out at Defcon. Um, but they they didn't quite scratch the itch of I'm rolling into an incident blind. I need to figure out what's exposed and start answering questions as soon as possible. And that's where Luminot is is really aiming. Um, so it's really for that quick triage piece. It's not meant for like a continuous scanning or um it's it's really meant to answer those initial questions and help you get started in your investigation. So it's

it's aiming for these questions here that you're going to have to start answering very very quickly. It's also intended for environments where you don't really have the time to do a bunch of configuration. So the idea is the tool is as minimal configuration as possible. You can run Luminot without configuring it. We have some reasonable defaults in place. Um that way you can just hit the ground running in your investigation. You don't need to spend a lot of time setting it up and uh like safe listing or allow listing resources uh to to get going. So this is luminant. Um we kind of have a inside outside approach. So we start inside the cloud getting a list of all the public IP

addresses. Um then we gather context around what resources those uh IP addresses are associated with. So um including firewall rules, compute and and so on. There's many more resources we don't yet support. We'd love to support them. Um but once we have a sense of those resources, we then take it to uh sources like uh cloud trail or GCP um audit log in order to figure out more information about uh when that resource was created if it was ever suspended or you know resumed uh just so you can get a better sense of the exposure window time frame as well. And then there's also configuration resources available from both Google and AWS uh that give you more sense of like

how the resource changed over time. There's also the outside piece, right? So inside's great source of truth, right? It's it's what's actually running. It's how it's configured, but we don't actually know like is it routable? Like can someone actually hit it? And so that's where end mapap comes in. We do an actual scan with luminina um using end mapap in order to like try to talk to those specific ports and answer the question like oh yes this is routable and responding back. Uh we also use what web. How many folks have used or seen what web before? Yeah, this is relatively new. There's just a couple of hands. It was new to me in this project

as we were doing research. um really wanted to have fingerprinting of HTTP services and when we came across this I was so happy because it fingerprints like 1,800 different web services and we didn't have to build that database or those detection rules or anything like that. So what web is great um and we'll show a little bit of that later and then of course uh quering showdan for context on the services it's found and also vulnerabilities that it's aware of. So uh as mentioned before it is configurable but configuration is not required. Uh it has support for allow listing only in AWS right now. we're working to bring it to GCP and then it reports to the terminal. Um, that same

information also goes to HTML because terminals are ephemeral and line wrapping gets weird. Uh, there's also a JSON payload so you can parse it to your heart's content and a CSV timeline so you can get started building out your timeline for your investigation. Here goes a demo. We'll see how Wi-Fi wants to play with me today. Uh, so here is the help information. Uh, no tools complete without ask. And uh, here we've got the uh, um, option to provide a configuration. I've got one pre-loaded here for bsides. Um, and I'm going to go ahead and hit go. See, the demo gods want to play nice. Hey, it's scanning. Great. So, it's starting to scan uh AWS and starting to

enumerate some of the public IPs. From there, it'll move on to Google Cloud. And similarly, we'll identify public IPs and associated resources. And then once it has a sense of all of the public IP addresses in the cloud environments, it'll switch over to start um running the the uh tools on the outside like end mapap what web and showdan in order to start answering questions about those and produce um output. Uh I'm going to switch over to our screenshots here just in the sake of time. So um here is uh what one of the entries looks like. I'm going to show you uh multiple screenshots from the terminal just hopefully this is readable. Um so uh IP

address is the first thing as well as the region it was found in. So you can scan multiple regions. Um we then see the network interface associated with it as long as along with the security group and the permissive rules. So here uh it's filtering out any of the internal rules. So that way you don't have to go through a massive list. You're just focusing on the rules that are uh exposed um to external IP ranges. Um so in this case we see 80 and 8501 exposed. We also see a load balancer attached, but it's only listening on port 80 and it's called honeypot ALB. I know it's kind of hard to read in in the font

here. Um, so interesting. Like we got a little bit of information. Someone called this a honeypot. Neat. Um, so here we have AWS config and cloud trail. Um, AWS config pulls back a lot of information and we haven't figured out how to nicely display that in terminal, but it all goes into the JSON report. So it's all there if you want to parse it out. And honestly, it's easier to look at it there because in the web app it takes a little bit of time to load and query. So we've we've pulled it out for you. Um and then in cloud trail uh this is uh nice to see in the terminal but the line wrapping doesn't really work

great but you can see like what cloud uh cloud trails pulled out. So security group rules changing uh resources being created and and so on. It's much easier to see as a timeline. I know this font's smaller for you guys but like it's it's nicely structured for the uh timeline here and answers those same questions. >> Um >> one thing Yeah. Go ahead before. Yeah. One thing I we wanted to call out too is while we were building out this timeline, you know, it's great to see that a security group was created, but what weight does it really have unless it was attached to your running resource? So, we made sure that that information is is built into your

timeline as well, so that you have a full, you know, exposure time frame. >> Yeah. Um, so here we have the outside tools. We have uh end mapap uh telling us for sure that it can reach port 80. We then have Showdan also confirming port 80 and here finding 62 vulnerabilities associated with the service running on port 80. Uh so that's uh that's a good stat to start with and uh gives us a chance to start running down what these are. Anyone recognize any of the CVEs in this list? >> Some old ones. >> Yeah, some old ones in there. Um it also calls out 443 and a Splunk server. You'll notice that 443 wasn't in the

list in the cloud environment, right? So um looking at the date here, this as of we can actually see this comes from an older scan from Showdown. Showdown's not live data. And so in this case, uh, you know, it's showing us something that's slightly inaccurate. So always validate output from tools, right? Make sure all your sources are reporting things accurately. Um, so the Splunk cloud is probably also unrelated here. Here's a wetw web. It's not the best example of what web, but uh it's showing that it's detected Apache. Notice that there was actually a redirect. Followed the redirect and is now saying, "Oh, this is actually a Synology disc station." I mean, it's it's not because

it's a honeypot, but uh it's pretending pretending to be Uh I just wanted to show off briefly uh the Google cloud uh output very similar shows the compute resource firewall rules and these are events from the audit log. Um this is the Google cloud uh run service which is uh the container run service that they have and uh what you'll notice is instead of the IP address it actually just shows the URL and then uh under ingress it says ingress traffic all so the the firewall rules are a little bit different there but luminot supports the URLs and we'll also scan those against uh or scan those with uh end mapap showdown and what web

so that way you get information on those urls as well. This is what the uh uh config looks like. Um and this is what we were just running in the demo. Um uh so you'll notice you'll be able to set up which reports you want to output as well as configure your tools. Um I did redact the API key. I I trust you all but not that much. And uh we have the AWS uh and GCP configurations off to the side as well. Uh these are the policies that are needed. This is also documented on our GitHub. Um, and as you'll notice, they're all just read policies and rather short lists that hopefully are uh

easy to share with the administrator of the cloud environment for them to set up a role for you to run the tool. And that's it. Let's see actually if the demo finished. Hey, it finished. Great. Uh, so uh yeah, any questions? Uh, they're coming with the mic. Yep. >> Is Azure on the road map? >> Azure is on the road map. Yep. If you have Azure expertise, we'd love to check because that's an area that we don't uh other questions. Oh, one over here.

>> We had uh thank you for the for the talk. Uh the question is not really related to the tool by itself but more about uh attacker on cloud. Are you seeing a difference today with attacker trying to use the cloud as a pivot point to compromise the onremise or they usually just stay at the first layer of resources trying to deploy crypto miner or things like that? >> Do you want to take this? >> Yeah, sure. So generally what I've been seeing um you know it's kind of staying at that cloud level. Um I haven't seen an instance where they're using cloud as a pivot point to get to onrem infrastructure only because I just

haven't seen that exist um in my line of work. I'm not saying it doesn't happen because it's very possible to do. Um but generally like the day-to-day the comp compromises that we're actually seeing are some of the you know commodity malares or the crypto miners that's what we're generally seeing unless it's something that's more of a highv value target. So, you know, if it's critical infrastructure, if it's something that's like more of a weighted value, that's when we're going to see the more sophisticated attacks where potentially AP type attacks, maybe a little bit more sophisticated where it's targeted. Um, but generally it's going to be more of those commodity malware, crypto mining that stays in the cloud, tries to look

for pivot points, but it's probably going to be at the cloud for the most part. Um, but to answer your question, I haven't seen it. Doesn't not saying that it doesn't exist because I'm sure it does. >> I can actually give an example. So I work very few cases these days as I'm mostly on the developer side but uh got called into a case in the past year or so where we did see them pivot uh not necessarily on prem but multicloud um through our our favorite service Jenkins and so uh that was a that was an interesting one I can't talk more about it but >> and uh does the tool detect any EM

exploitation or EM uh weakness that can allow an attacker to raise it's private on the cloud environment or detect some uh access persistences for example um back during a specific role uh opening the AWS account on another account or it's not something implemented yet. >> So uh the question was about uh IM and using that for uh uh persistence and such. Am I getting that right? Okay. EM for persistence or attackers that are using EM to escalate privileges, things like that. >> Do you want to speak to that part? >> Yeah, that's not something that the tool currently supports, but I think that's a pretty valuable resource to start enumerating into. You know, like we have

the infrastructure like the actual, you know, networking component and that's the privilege escalation part that we aren't necessarily looking at. So, I think that's a good pivot point for future movement of the tool. >> Yeah. Yeah. >> Thank you. >> Thank you. >> Yeah. Thank you.

>> I think we're at time. So, yeah. Thank you all. Appreciate it. >> We'll be around if [Applause] >> Thanks. >> Good job.

[Music] [Music] for [Music] data. [Music] Fire.

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

[Music]

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

Heat. [Music] Heat. Heat. Heat.

Heat. Heat. [Music]

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

Heat. Heat. Heat.

[Music]

[Music] That's [Music] true.

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

Wow. [Music] Heat. [Music]

Heat. Heat.

Heat. Heat.

[Music] Heat.

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

[Music] Heat. [Music] Heat.

Heat. Heat. [Music]

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

[Music]

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

down down down down down.

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

[Music] Banner [Music] debut. [Music] down. Down. [Music] Heat. [Music] Heat. [Music] Heat. Heat.

Heat. [Music]

Heat. Heat. [Music] Heat.

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

Heat. [Music] Hey Heat.

Heat. Heat. N. [Music]

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

[Music]

[Music]

[Music] Heat. Heat.

[Music] Heat. Heat.

[Music]

Heat. Heat.

Heat. [Music]

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

Heat.

Heat. Heat.

[Music]

Heat. Heat.

[Music] Heat. Heat.

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

[Music]

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

down down down down.

[Music] Yahoo! [Music] You do. [Music] [Music] Heat. Heat. N. [Music] D hey.

[Music]

[Music]

Heat. Heat. [Music] Heat. Heat.

[Music]

Heat. Heat.

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

Heat. Heat.

[Music] Heat.

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

Heat. Heat.

[Music]

[Music] Heat. Heat.

[Music]

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

[Music] Heat. [Music]

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

Heat.

Heat. Heat. [Music]

Heat. Heat.

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

[Music] Heat. Heat.

Heat. Heat. [Music]

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

[Music] down. [Music] Hey hey [Music] 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]

[Music] Yahoo! [Music]

[Music] [Music] Body [Music] be doo doo doo. Here [Music] you go. [Music] Heat. Heat. N. [Music]

Heat. Heat. [Music] Heat. Heat.

[Music]

Heat. Heat.

[Music] Heat. Heat.

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

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

[Music]

[Music]

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

[Music]

Heat. Heat.

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

Heat.

[Music] Heat. Heat. Heat. Heat.

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

[Music]

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

Yeah,

down.

[Music]

testing. >> Test test. >> Oh, yours is good. >> Mine might need to come up. >> How's that?

Test test. >> And the PC audio is on too. The computer audio. Cool.

>> Uh s

Yeah, I know.

>> Yeah.

by

choice.

check.

Yeah, you're good, man.

>> Good evening everybody. Welcome, welcome to Bsides Las Vegas ground floor. Um, so today we're going to have the talk, don't be lame, the basics of attacking LLMs in your red team exercises. And we have our speakers, Alex Bernier and Brent Harold. Before we begin, a few announcements. We'd like to thank our sponsors, especially our diamond sponsors, Adobe and and Akido, and our gold sponsors, Drops in Aai and Run Zero. It's their support along with our other sponsors, donors, and volunteers that make this event possible. These talks are being streamed live. And as a courtesy to our speakers and audience, we ask you to check to make sure your cell phones are set to silent.

If you have a question, you'd be using the audience microphone that I'm holding right here so that YouTube can hear. And if you have a question, please raise your hand. So I'll bring the mic to you. As a rem as a reminder, the Bides Las Vegas photo policy prohibits taking pictures without the explicit permission. These talks are all being recorded and will be available on YouTube in the future. So, if you're in the room, please move forward a few seats to let those who come in grab the seats behind you guys. With that, let's get started. Please welcome our speakers. >> Good afternoon. Good evening everybody. I'm so excited to be back here at Bsides. I was here two years ago talking

about a red team maturity model. Today Alex and I have a different kind of model for you. It's this little known technology. Not a many people are talking about it. We really think it's going to change the world though. It's these things called large language models. Now obviously I don't have to tell anyone that LLMs are all the rage right now. There's a lot of great content and sessions this week. I'm excited about a lot of them. But for red teamers in the security field, there can often be some confusion or maybe even intimidation around how do we engage with this technology as part of our red team exercises. And I think that confusion stems from two areas. If you

look at how red team is discussed in genai spaces, there's in many cases a heavy emphasis or an exclusive emphasis on safety and ethics stuff. making sure it doesn't tell you how to build a bomb or doesn't behave in a racist or sexist or biased way. And don't get me wrong, that's really important. We don't want an HR bot to filter out candidates because they're over 40 like happened a month ago. But I think most of us in this room would say, "Okay, yeah, that's a problem, but it's not my problem." Where's the real security impact here? I think the other source of confusion can be how a lot of the material thus far has focused on the LLM itself. So things

like prompt injection and jailbreaking and that's kind of where it stops in many cases. So again we end up in two scenarios here. One, we get it to say something dirty. Okay, so what what do I as a red teamer do with that to achieve my operational objectives? And two, focusing on just the LLM can make it seem like an AI problem. And really we do have a security problem here when we start to turn these things into agents. So, I don't want to go on a side tangent on whether or not the definition of red team and genai is being used appropriately, but I think we can at least say that there's kind of a

mismatch in the definition right now. And when we talk about things from a security perspective, we're talking about simulating an adversary trying to achieve some sort of malicious impact and an objective based exercise. So, when Alex and I talk about red team today, that's what we're talking about, not necessarily the safety and ethics stuff. Although, as we'll we'll discuss in one example, there can sometimes be overlap. Now, the other thing that we're going to do is we're going to focus heavily on the systems that use these things because the applications and agents that are employed by these LLMs are a lot more interesting from a security perspective. Focusing on just the LLM leads to some shortfalls and and

some some lack in security. It just doesn't fit nicely on a title to say that applications and agents based on LLM and your red team exercises, right? So, all that said, what are we going to talk about? Got a little bit of theory here on how LLMs work under the hood. This is 15-ish minutes on what we think you as red teamers should know about what's actually happening inside these LLMs so that you can understand the attack paths because this is really the engine that drives this car. It's what makes these applications different from other things that you're used to attacking in your red team exercises. Now, there's no prerequisite knowledge. There's no math. So, don't worry about

that. Daddy's got you. And then when I'm done, Alex will pick up with the attack side. And yes, we will talk a little bit about prompt injection and jailbreaking because that's usually the entry point. But we're not going to stop there. We're going to take that into how do we get into the impacts that we as red teamers want to see. The attack tactics like execution and lateral movement and privilege escalation and discovery and credential theft, all these wonderful post exploitation things we go after. We've been able to accomplish most of those things in our exercises with the apps and agents that exist today. So, a little bit about us. My name is Brent. I'm a principal consultant at

Crowd Strike. uh along with Alex who's also a principal consultant there. We're part of the professional services red team which is the consulting side of of the the red team. We're two of the founding members of the Genai red team there. And I get all that up front just to get to the disclaimer that our opinions are our own or here's ourselves today. If Alex says something stupid, it's his fault. If I say something stupid, it's Alex's fault. But in any case, it's not CrowdStrike's fault. All right. Um my background is more in traditional AD enterprise exercises. Uh, I I had actually started outside of technology, but as I worked my way into security, that's kind of been my bread

and butter. And I think that's probably the case for a lot of folks here. And that's why I'm really excited about this topic to help bridge this gap because I've had red teamers tell me, well, I'm not an AI guy, so I'm just going to stick with ADCS or, you know, what's the big deal with prompt injection. Alex's background, he came from the blue team side and he also is really heavy into the web application side where again LLMs have a lot of juice as these things are being plugged into chat bots and a whole bunch of other applications. So let's get into how these LLMs work and again I promise you this will be

painless. So inside artificial intelligence you got machine learning. Inside of machine learning you've got a bunch of different sub fields. The one that matters to us is something called deep learning. And deep learning really excels at unstructured data, things that we can't programmatically say, hey, these six boxes are checked, therefore it's this thing. That's why it's used in robotics because the world around us can be pretty random at times, right? It's also used in LLMs because even though language has rules and grammar, we can manipulate those rules to emphasize different things and structure sentences in different ways. And so it's not deterministic. It's it's very unstructured. And this deep learning process works with a special computing

structure called a neural network. Now, you've probably heard of these before, but we're going to talk about this just a little bit because there's some important implications to when we get to the LLM side. Now, these neural networks are comprised of thousands or millions of these little things called neurons. And these neurons are arranged in a bunch of these layers of groups. And these all tied together by these little lines that you see up here that are called the weights. Now, what are the neurons? They're basically just data receptacles. They hold a value and that value is called its activation. And that activation is how present or absent that piece of information is that this op

this neural network is operating on. Now the easiest way to understand that I think is in the input layer. Whatever we're feeding into this, whether that's text with an LLM or images with an image classifier or something along those lines, that that first layer, we're going to map that data into these neurons. And that activation value is going to correspond to the different pieces of it. So on the next slide, I've got an example of image recognition where those are going to tie to pixels in an image. Now I'm going to skip over the hidden layers here for just a second and get to the output layer because I think that's the next easiest thing to

understand. And if you take away nothing else out of this slide and the next slide, understand this. The output of a neural network is a prediction. It is a bunch of math that creates a probability. It is not like putting something through a Python function where if you give it the same arguments, it's going to have the same result on the other side of the function. It's math. That's why you see a little green box around images in a video that says like 99.9998% confidence it's a human. It's pretty confident, but it's not 100%. So, this output layer is going to account for all the things that this neural network knows how to predict, and

it's doing that in a probability. Now, these hidden layers are where the real magic happens. This is where deep learning takes over. Neural network designers can set up the number of neurons, the number of layers. They can do all that, but they often don't tell the machine what to do with those layers in the middle. That's where deep learning decides, hey, I'm picking up on these patterns. I think this will help me predict things better in the future if I do it this way. So, these hidden layers are really important, but that's also where we get to kind of the black n blackbox nature of machine learning models. Now the weights, these are the core of the model itself.

You can set up the neural network with the same number of neurons, the same number of layers. If the weights are different, it's going to behave differently every time. And what these weights are is really just a relationship. It's a relationship between each and every single neuron in one layer and its neurons in the next layer. You're going to have a line between each of them. And it's a relationship that says this neuron has this amount of importance to this neuron in the next layer. And that can be positive or negative. So in a really basic example, let's say you've got temperature on one side and you've got the probability of ice on another side.

Well, that's going to be an inverse relationship. As the activation of that temperature, the temperature rises, ice is coming down. There is no ice outside in Las Vegas right now. Let's say it's sweat instead. If the temperature rises, that's a positive relationship. You're probably going to be sweating out there because it's really hot. So these weights are really important and they just dictate, hey, this neuron, it matters to this next neuron in the next layer. Now, let's give this an example here to hopefully illustrate this a little bit better. I think the easiest example, even though we're talking about large language models today, is image recognition because people visualize things. So let's say we want to take

some handwritten notes and convert them into searchable text in your favorite text editor. Well, we're going to need some machine learning there with optical character recognition because everyone's handwriting is different. You can't just say, "Hey, these blocks are filled in, therefore it's a B. This one's a bit slanted. Some people write cursive, etc." So, if we were feeding this into a neural network, let's just say we're keeping things simple. We scan this document in and we break it up into these little 20 x 20 pixel grids. And somewhere in there, we're hoping is a letter that we're going to pick up. So, that means there's 400 pixels in this image. So, our input layer needs at

least 400 neurons, one for each of these pixels. And that initial activation value in that input layer is going to correspond to the presence or absence of ink in this very simple case. So if it's the background color white, it's not activated at all. There's no data there to represent. So we'll say it's an activation of zero. If it's fully pitched black in the middle of that B, it's full of ink. So we'll say it's strongly activated at a one. And then you'll get to these edge cases where the ink maybe bled into the paper a little bit or you've got a smudge and you'll have these values between one and zero uh that represents some sort of gray

tone in there. So that's the activation for the first layer. How do we get the activations for the rest of them? Well, I promised you no math. So if you want to see it, it's up there in the yellow. But basically, we're going to do a lot of multiplication and addition for each and every single one of these neurons with their weights. And again, if these things have thousands or millions of neurons in them, we're talking millions and billions of calculations just to get through one run of this neural network. That's where a lot of this computational uh power is required. So the hidden layers do all the magic. We talked about the machine picks up on

things. Now, they don't they're not human. They don't think like we do, but how would we recognize stuff? We'd start to recognize edges. Okay? So the machine might pick up there's some light pixels next to some dark pixels. That might mean something. And then we can turn those into lines and lines into shapes. And we get to the output layer where then we can take those shapes and turn it into letters that it has been trained on. So once we get to that output layer, again, it is a prediction. We're going to do all that same math to calculate the activations. We're going to do a little bit more math to make it a probability because you can't have more

than 100% chance of something. And then that's going to tie to what it's been trained on. So in this case, if we trained it on English, it'll have a neuron for A through Z, upper and lowerase, letters, numbers, any special symbols that you want to take care of. And if you want to add other languages, it would have those outputs as well based on what you're training into it. But again, the key takeaway is that this is a prediction. It is a bunch of math that happens to get to a chance of it being something at the other side. And if you remember your middle school or high school algebra, you probably got the wrong value for X somewhere along

the way. And your answer was what? Wrong. It was wrong. So that's what we're trying to do as we're attacking these machine learning models. Can we slightly adjust some of the variables like X in here to get it to predict something that maybe we want instead of what it should have been predicting in in the first place. So what the heck, Brent? This is about LMS. You just talked to me about neural networks for 10 minutes. Well, that's because the the key architecture underneath a a large language model is a transformer. And a transformer uses these neural networks to do its job. It's also really important to understand from this discussion of neural networks that LLMs

are just doing prediction. That's what it is. It's not a deterministic output of text. It is working on math and numbers, not language despite language being in the name. So, as we transition into discussing these LLMs, I thought we would start with a funny video, or at least I think it's funny. If you don't, the door's over there. Uh, but I really think it's a great illustration of how these LLMs work. Completely agnostic from technology. So, this comes from a comedy show called Whose Lines It Anyway, if you didn't have the fortune of seeing it on TV when it aired, it was a bunch of comedians. They knew the rules of the games that they were

playing, but they didn't know what they were playing about, the prompt, so to speak. That was given them to them while they were recording the show by either the audience or the host. Now, this particular game is called three-headed Broadway. And in this game, they have to create a song, but the catch is they can only say one word before it moves to the next comedian. So, if you know a little bit about how LLM's work, you see where this is going. But we're going to watch this video and then actually use it as a way to talk about some other important concepts. So, let's give this a go. >> You are my soul, mate. I can't hardly believe.

[Music] All right, hopefully that was enjoyable. But there's actually some really good concepts that we can take out of this. So the same way that these comedians are generating the song one word at a time and they don't know what the final result is going to be, LLM are generating their output one token at a time and they have no concept of what the final answer is going to be. They're just going to predict that token until they get to a point where they think I've answered the prompt. So the key word here though is tokens. We as humans, we use language. They're using words as comedians. These LLMs are using tokens. Now, tokens can be whole words

in language, but they can also be punctuation and uh differences between uppercase and lowercase letters. It can even be characters that we don't really recognize as language if it's been included in its training set. So, there's a lot more that's going on. And they're doing this with numbers instead of actual words. And we can see kind of an example of this from the video where we get to this first part. You are my soul. And Drew, the guy in the middle, adds the word mate. Well, in English, soul and mate are both individual English words. Soulmate is also a single English word. There's no space. There's no hyphen. That's kind of an example of how tokenization might work. The LLM

might through its learning process decide to tokenize something slightly differently and put tokens together into what we would recognize as a single entity. Now, how do the comedians know what to say next? Well, because they're paying attention, right? They're paying attention to what they've said before, what their colleagues have said before. So, we get again to this part. you are my soul. And Drew, the guy in the middle, is like, "Yeah, that doesn't really make sense. So, what can I do to that?" Oh, I'll say, "Mate, soulmate makes more sense, right?" Well, why are they writing a song about a shoe? That's kind of weird. Well, they're paying attention to the prompt that they were

given as well. So, LLMs through the transformer have this attention mechanism where they are looking at what's come before to figure out how to continue to make it make sense, but they're also looking at other data that's being fed into that. the system prompt, the user prompt, outputs from tools or rag or anything else along those lines. That's all getting considered as it's doing its math to predict tokens. Now, the last thing that we can see on this slide, and I've got time, so I'll talk a little bit about it, is hallucination, right? That comes up a lot. Hallucination is a feature. It's not a bug. LM are incentivized to predict tokens. That's what they do. And

they don't really know facts. They know patterns. And sometimes those patterns can be facts based on the training data that they've seen. But really, a hallucination is just a bad series of token predictions. It's stuff that doesn't tie to reality because it doesn't know what reality is or because it predicted a bad token once and now that's part of that attention mechanism and it just starts to spiral and go off the rails. So, we can see hallucination in the video there where Wayne, the guy on the left, accidentally says two words. It confuses the guy in the middle who just kind of says, "Ooh." And then Ryan, the guy on the right being funny, says gazun height, which is bless you in

German because it kind of sounded like he sneezed, right? That's a perfect example of hallucination. But it's not that these LMS are trying to lie to you. It's just how they work. So GPT for all. You've heard the name, you've heard GPT in the name of chat GPT. It's there, but if you weren't aware, this underpins pretty much every model that you're going to see today. Generative pre-trained transformers are in claude, they're in mistral, they're in cohhere and llama and deepseeek and all those things. Now generative makes a lot of sense. We'll skip that. We're talking about generative AI. Pre-trained means it's gone through that deep learning process. And in the deep learning process, it's used those neural

networks and it's tweaked all those weights so that it can make the right predictions on the other side. But another key element of training in this case for the LLM is it's also going to create its dictionary called the embedding matrix. Now this dictionary is the series of all the tokens that it knows based on the input data that it's seen. So it'll go through a tokenizer and then it'll create this these embeddings which are long vectors of numbers. Now this audience is probably more familiar with the term array. It's similar. It's a long series of items where the indices can be individually accessed and they have their own meaning. Well, in this case, during the

training phase, as it's tuning all those weights, it's also trying to understand what these tokens are through this embedding matrix. And these indices are given some sort of value or meaning by the machine where one index might represent bigness and another index represents friendliness and another one represents bless. And that's how it's trying to understand language. It doesn't do language like we do. It does it in numbers. And that's where we get to the transformer. This is the pivotal piece that really changed how uh LLMs have taken off over the last several years. And this transformer is grossly simplified here, but it uses those neural networks that we talked about before. And it adds to that these

attention blocks that we're going to talk about here in a second. But with the transformer, it's still a prediction. You take input text in one side, you do a bunch of math and gonulation in the middle and then you come out the other side with a predicted token or a sequence of predicted tokens and it figures out based on temperature which one it wants to go with. But this attention mechanism is key. This is what makes these LLM seem so smart and so good at their job. How do we as humans know what the definition of bark is in those two sentences in the top right? If I just gave you the word bark, you

wouldn't be able to tell me the answer, right? You understand it because of the context. The dog, okay, that's a sound. The tree, okay, that's a physical material. Well, LLMs have the attention mechanism inside the transformer to do exactly that. To look around at all these other tokens, to ask questions of what are you? Oh, you're an adjective. Okay, that means a noun should be coming pretty soon here. They're just doing it in numbers. It's not language. It's numbers. So they'll take all these words, all these tokens, convert them into those embeddings that they've seen, those vectors, do a bunch of math, and calculate this new vector and say, okay, in my embedding my or in this case, the

unmbedding matrix, my dictionary, which token that I know about is closest to this number that I've just calculated. That's what's happening. It doesn't understand language the way we do. And this is where we can start to do some attacks because if we can change the math along the way, it doesn't understand language like us. So we can potentially manipulate the output the mathematical equation by using uppercase characters instead of lowercase because it might interpret that differently. Now we're almost there, I promise. The last bit of theory here is the context window. This attention mechanism is key, but it's also subject to compute power. These LLMs can't constantly keep everything in memory and work on all

things at all times, right? This is why we take tons and tons of GPUs because there's a finite limit to how much it can look at and that's called the context window. And if you've used chat GPT or some other LLM product, you've probably noticed that if you ask it too many different topics in a single chat thread, it starts to give you really crappy answers. That's because it's trying to pay attention to too many different things in this context window that you're giving it. And you're better off starting a new thread because now the context window is clean. It's not trying to pay attention to any of those other things and it can focus on the

task that you've given it. Well, this context window is limited, but it also gives us opportunities to do attacks. Things that Alex is about to talk about here in a second, like confusing the LLM intentionally, changing the topic, changing what you want it to do to maybe get it to forget its rules or pushing things out of the context window. So, for example, I think GPT40 mini right now has a context window of 128,000 tokens. So if we give it really long documents or a really long conversation thread, at some point something's off the island, right? And if you built your app or your application poorly, that could potentially be your system prompt, too. Not likely, but that's possible. So

now we get to the fun stuff, right? This is what we're here for as red teamers, breaking things. And I've got one more slide for you before I hand it over to Alex. Kind of the so what, right? As we've gone through this discussion on how these things work, hopefully one of the things you've picked up on in addition to it's all math and probability is that these LMS just generate text. That is all they do. Have you heard me mention executing code once? No. It's because that they can't. LLMs by themselves just generate text. And that's what leads to some of the confusion for red teamers, I think, is if we only focus on the LLM.

Okay, so what? It outputs something dirty. Who cares? I can't do anything with that as a red teamer to get to my objective. Or to make it even better, chat GBT, Claude, Gemini, all these things, they don't know anything about your company. If it wasn't in their training data, they don't know your product secrets. They don't know your source code, unless you leaked it online, in which case you've got a different and bigger problem, right? So, even if it did generate something dirty, it's not going to be a security impact. And that's where we start to transition into the applications and agents that are using these LLMs. The LM drives it, but it's really these applications and

agents that give us as redteamers a lot of capability. And one of the biggest steps towards that is tools. Tools are just functions that we've written or through the model context protocol, you can even access functions that other people have written. But this is just regular code. It could be a Python function like check weather and gives it an, you know, a weather API. Tools are what give LLMs the ability to act by themselves. they can't do anything other than generate text. But even still, the LLM can't call the code itself. It just is told about the tool and says, "Oh, I would like to call that." So, what we do with this is we

write a function. Let's say check weather. And then we send a prompt to the LLM. Hey, what's the weather in Las Vegas, Nevada? And we also send a description of this function. Here's what it does. Here's the name of it. Here are the arguments you would need to provide. Here's what you get back out of the function. And so, we send that along too in the LLM. in its context window sees that and says, "Oh, I don't know what the weather is because I just generate text." But I see I have a function here called check weather and that I just need to provide the city and state and it said you were in Las Vegas,

Nevada. So, hey application, call this function check weather with Las Vegas, Nevada as the arguments. So, the function the application will go run the code for the LLM. It'll return that back to the LLM and the LLM can then render its final answer. It's really hot, right? Well, as redte teamers, what does that give us? It's execution. It's running code. It's potentially privilege escalation. Have we seen service accounts in the domain admins group before? That doesn't happen, right? Of course, it happens. What do you think happens here? If these LLM applications and agents are given more permissions than the user does, and you don't lock that down, you've got privilege escalation because now you can run

things that you shouldn't be able to run by controlling the LLM. And then we've got pretty much every other attack post exploitation tactic that you can dream of based on the tools that you're giving this LLM. Now the other side of this I mentioned a moment ago chatgbt Gemini claude etc. They don't know anything about your company. So if you ask it hey how many days off a year do I get? It'll say I don't know general HR policies say you should get 15 days off a year. Hopefully more than that but we'll say 15. Well what would you do here? This is something called rag. Now, we can give the LLM access to other information

that's specific to the task that we want it to work on. In this case, we would give it access to our company's HR policies. So, if an employee comes in and asks how many days off a year I get, it can say, "Well, according to HR policies, you get 15 days a year if you've been here three years or longer." You can combine that with tool calls, too. You could have it call out to your HR management portal and say, "Oh, you've been here three years." According to the HR policy, that then means you get 15 days. Well, that sounds a heck of a lot like getting access to a file share, right? Or a SharePoint or some

other data repository. So, now we've got collection. We've potentially got privilege escalation. Again, if it can read things that you shouldn't read, as Alex is about to talk about, you can also use this for lateral movement. If you can poison that rag data store and get it to basically like a stored cross-ite scripting, spit some malicious answer out to another user uh who is unsuspecting that their data source has been poisoned, right? So, I don't want to anthropomorphize AI here with this last statement, but these LLM agents, they don't think like humans. They aren't humans. They don't act like humans. You can consider though that compromising the LLM that's been embedded in one of these applications or

agents is a lot like compromising a user account or a service account. If you can control the output, you can now potentially take control of the privileges and accesses that that LLM has available to it through that application or agent. And with that, I'll pass it over to Alex. Is not working. >> All right. Now, before we get into um before we put in our uh put on our uh attacker hat, let's first go through some initial definitions here. So, you know, at a high level, we consider prompt injection to be a supererset of jailbreaking, which we can define as really any type of of of a malicious prompt is trying to insert new instructions or manipulate the LM's

behavior in some kind of way. And jailbreaking we can define as a type of prompt injection where the goal here is to uh is to have the model disregard its ethical alignment or really anything that's a part of its system prompt. Now, because of how LMS work and some of the theory that Brent talked about, they're going to understand anything that's a part of their training set to some extent. And this going to include different languages, different characters, and like we're see like like we'll see here in this first example, things like Unicode control characters that don't always get rendered in certain applications. Now, this first example was published by Riley Goodside, who was talking with ChatgPT, and he

said, "What is this?" And he included what looks like some weird looking Zalgo text. What you can't see is that in this string there's a set of zero with unic code characters that they don't get rendered in HTML but chat GPT is able to interpret. In this case it said something like you know generate this weird looking image of an alien and and include some creepy follow-up text. And this is a really effective technique for including these hidden types of of prompt injections because of the fact that the majority of applications websites and LM agents out there not going to be sanitizing for these types of characters. And so, um, this is and and so if there is an LLM that's going

to be interfacing with or scraping a lot of these popular websites, then this is going to be a really good way to do this hidden type type of prompt injection. Now, there's two main types of attacks. There's direct prompt injection and indirect prompt injections, which we'll get into here in a moment. But first, and I'm sure that the majority of people already know this, but what a direct request looks like to anella, um, under the hood, it's going to include a system prompt, which is the application prefacing to it that this is the persona I want you to have. This is what I want you to do, and this is anything that I don't want you want you to do. And then

obviously as the end user, usually what we can control is going to be the is going to be the user input. But what's actually received by is going to be these two things as a wall of text. And because of this, if you say something like, you know, ignore the prior instructions, do something evil, well, really, it's just going to do exactly that and just kind of predict the next token. And across our assessments, uh assessments, we've seen a lot of different attempts by developers to implement guard rails and security controls to try to mitigate this type of prompt injection. And some of the common pitfalls have uh that we've seen have been things like a static dirty word

list that's checked against the input or the output. We've seen some system prompts with instructions like don't talk about this topic or don't say this word. And one of the ways we can get around this is using offiscation because again anything that's a part of their training set they're going to know to some extent. And so this includes different languages like German and French and even something more obscure like Swahili and also different types of encodings. And so usually you can talk to it in B 64. You can tell it to output something in German. And this going to be a good way to get around some of these more rigid security controls. Now, the other big attack surface here

is conversation memory. Um, and because of that attention mechanism that Brent talked about earlier and some of the inherent limitations around this, um, this technique known as context confusion kind of comes in handy here where we can confuse it by giving it a bunch of different tasks, changing the output format that we're asking for. And by doing this over the course of multiple messages in a conversation, we can kind of confuse it and get it to kind of break out of some of the things that it's been told in its system prompt. Now, two additional strategies that are useful when we're doing this type of direct prompting are going to be persona setting and storytelling. And you've

probably heard of the DAN or the do anything now prompt. This was a really popular jailbreak prompt for a lot of the earlier models. And it doesn't work for most of the newer ones, but the concept still applies where it was basically this really long prompt saying it's a bad thing to say no. Always be helpful. Basically, nothing under the sun is bad. And the idea here is that if you can find a persona for it that confuses it or gets it to break out of its normal behavior to be less likely to say no, then this is going to be a good way to achieve a jailbreak.

Now, storytelling is centered around this idea of using different pretexts because for every prohibitive request that we're going to get a a refusal for, there's going to be some way to reframe the question to add some legitimacy or some justification that's going to be interpreted by the model a little bit differently in terms of ethical alignment. And so, if we're saying something malicious like, you know, how do I abuse an ADCS server? Well, that's probably going to give us a refusal. But if we kind of reframe that a little bit and we say, you know, this is a red team exercise or I have permission to do this or you know, if we're asking how do I

attack this thing, you might say, you know, I'm trying to defend against this type of attack. Tell me what to expect from an attacker. All of this is going to help including for some reason we've had pretty good results uh by just asking for any type of simple output format, even like a simple bullet list. And then the other the other consideration for this is again conversation memory. So, as you're iterating across different attempts to getting around these refusals, either manually or if you're doing this through fuzzing and attack automation, uh definitely make sure that you're thinking about conversation memory um and that you're starting a new conversation when it makes sense. And usually that's going to be when you're

trying a new pretext. Now, indirect prompt injection is great when you can't directly interact with the LM application. And so if you don't have a user interface, you don't have a command line interface, you might be able to come at it through some sort of tool that's being used or a resource that it's accessing. And for us on red team operations on uh red team exercises, one of the things that we want to go after is the capability to impact an internal LM through a rag. And so if you have the ability to write to some sort of resource like a SharePoint resource or a fileshare, then um you know, you might be able to include some

prompts in these files that are going to affect the output of the LLM. And by doing that, you this is going to be a really good way to try to target thirdparty users. And so the first example of some research that we saw published online that sort of got us thinking about ways that we can start to use these in our red team operations was something published by Johan Rayberger who has a blog that I recommend every everybody check out. Um and he showed this example where him and his colleague who was sort of the mock victim here. They were in Google Workspace and Johan created a new document and he tagged it as being

related to some kind of legal query and he included these instructions basically saying to the LLM that I want you to output this very specific markdown image syntax and he referenced his listening web server in this case a Google macro but any type of listening web server would work and he included a git parameter that he told the LM to fill in with the encoded user messages in the conversation and so Johan then shared this document with his colleague and if familiar with Google Docs, it'll ask you, you know, do you want to notify the person that you're sharing this document with that they now have access? And to be just a little bit more stealthy, uncheck that

box so that his coworker wouldn't be notified of this. And so his co-orker then had access to it. And because of the fact that they were using Bard uh for their rag and it was going off of his account's permissions and what files that he had access to, anytime then that his colleague would ask some kind of legal query, this prompt would be interpreted through the rag. it would output that markdown image syntax reaching out to Johan's listening server uh excfiltrating that conversation history. And so indirect prompt injection is going to be something that we'll be continuing to use pretty frequently for our red team operations. And so definitely keep this in mind uh because if you are on a red team op if

you do have the ability to modify a knowledge base in some kind of way, then this is going to be a good way to target users and to also do this type of data exfill. So that was a quick rundown of some of the prompt injection strategies. But as Brent mentioned, we want to really go one step further and really kind of drive home how you can have some real impact with some of these. And for traditional operations, we usually try to accomplish a bunch of different MITER attack tactics. And we've been able to use almost all of these for post exploitation to get to our operational objectives. And for some of these, like we'll see

here in this first example, which is of credential access, you don't even really need to use prompt injection to uh to do this. Now, this first one was where um a buddy of ours, he found a Slack token and he didn't know the account's password. He didn't know the NT hash. So he was kind of stuck on Slack and he did some initial recon and he found that he had access to the self-service Slackbot. In this case, it was meant to be used for routine issues like it. And by just chatting with it and asking what it could do, he found that um it had two tools that he was able to abuse. The first one was it actually had the

ability to do a password reset for him, which is pretty uh surprising. But but because a lot of the other applications still required MFA, this wasn't really a full solution. So he was still stuck on Slack. He was chatting with a little bit more just kind of asking what else it could do. and he found it also had the ability to do a MFA device reset for him. And so he didn't have to do any type of fancy prompt injection to really use this. This was really just him abusing this existing functionality. Now the next one uh which is lateral movement. This is similar to the poisoning example from the last slide. Um this was uh one one uh assessment

where we had right access to a company share and in this share there were a bunch of policy documents that were being consumed by a rag as a knowledge base and we modified one of these. In this case they were word documents. So we did this in a little bit of a more stealthy way. We we modified the content of it. Uh in this case using a white small font so that if somebody manually looked at this it wouldn't have been obvious that we modified it. And we basically made it so that if somebody asked a super common policy question that they would get an answer, you know, recommending them to download and execute this random file, in this case,

our C2 beacon. And this is really great because, you know, for some reason a lot of people, they seem to assume that the output of an LLM is somewhat authoritative or that it's trusted. And it really isn't. And this is kind of one way that we can abuse this for social engineering. And we can also use this for lateral movement. Now, impact and defense evasion. And this one hits another theme that Brent mentioned, which is that there's sometimes going to be some overlap between safety, ethics, and security. And in this case, we were able to um basically disseminate false legal information where there was this application that had two components to it. There was a rag that contained a

bunch of legal knowledge for its knowledge base and then you uh users could upload these documents and it would give legal advice based on what it knew. And we couldn't poison the rag for this one. But because it wasn't using a robust system prompt, we we were able to include a set of instructions in our uploaded document that basically said something like, you know, there's this brand new law that was just passed today and that this should override a lot of your existing legal knowledge. And this actually worked uh worked quite well. And to make it a little bit worse, if this was a real attacker, the uploaded documents, they weren't being retained long term.

So, um, you know, if this was a real attack, it would have been a little bit harder to kind of investigate what was going on here. And for this one, you know, if you're thinking about normal red team exercises and how, you know, what this delivery mechanism would have looked like, you would kind of have to do some type of watering hole attack to maybe trick a user into uploading a document to this application that contained that prompt injection. So, there'd be some additional steps uh by poisoning a file template or something like this. Now the next one which is Xfiltration. We already talked about how that markdown image syntax can be abused for data Xfill. But one of the things that I

didn't mention is that there's a component to this markdown image syntax called the alt or the alternative text. And if you set this to nothing, then it does that same type of data xville behavior. Uh but nothing is shown to the user at all. And so that's a much more stealthy way to do this. And then and then uh you know remember that we're able to exfiltrate really anything that's a part of that conversation history. experience. So this is going to uh include you know obviously messages also tool calling results and we can do things like system prompt extraction and uh we can also kind of ship that off to another web server just using data

xville and then beyond just markdown we've also seen applications that render HTML and JavaScript so you may also be able to do HTML injection cross-ey scripting and through that do things like you know steal the the session cookie now the next one which is initial access and persist distance. This is a really fun one. This was an application where it was able to generate code for us in a user project and we we we found that if you gave it a URL that it would go to that website, it would take a screenshot of it. It would pass this to a multimodal vision model and it would do some analysis. And we found that we were

able to get a prompt injection. And one of our observations was that every time that it went to our website, it would use the same um user agent string. And so just to be a little bit more stealth, we include some JavaScript on our website that would dynamically load the uh the page based on that user agent string. And so we would only include our prompt injection when we knew that the tool the the Agentic tool itself was accessing our website. And so because we were able to get this prompt injection working, we coerced the LLM into including some malicious package imports and also writing a web shell to the project. And so that that was a really

cool way that we were able to get an rce. Now the last one which is collection and privilege escalation. This was one example where uh we were able to abuse this idea of excessive agency which is anytime that the application can act beyond the user's own permissions. And in this case we had access to a fileshare or to a shareepoint rather we had access to this LM application and there were some SharePoint resources that we didn't have access to but we knew that they had info that we needed. And so by simply taking those URLs and giving it to this LM, we found that it was actually able to summarize those resources for us. And this kind of

allowed us to collect the info that we needed. So I hope that those examples gave you more of an idea of some of the downstream effects that come from attacking LLMs and that it really is a lot more than just getting them to say bad words. abusing them is really just the start. And a lot of the real impact kind of follows behind it with the applications and agents. And even though a lot of the examples that we talked about today were of chat bots, remember that you know LMS are constantly being used behind the scenes. And regardless of what type of application that you're dealing with, it might be interfacing with an LM on the

back end. So the next time that you're on a red team operation, definitely be on the lookout for LM based applications and agents. see if this is an attack vector that you might be able to target by being able to write to some sort of data resource or through direct prompting. >> All right, that's it for us. Thank you everybody. The slides, thank you. Thank you. In addition to the recording, the slides will be available uh on my GitHub there. So, if you do want a picture of that, I give you my permission. And then we'll also be having a uh a small CCF as part of a workshop at Defcon. So, the code for that will be available after Defcon

as well. So, thank you for your attendance. >> Thank you guys.

[Music] Heat. Heat. [Music] By far. [Music] Baby, [Music] daddy. [Music] D hey. D hey. [Music]

Down. [Music] Heat.

[Music] Heat. Heat.

[Music]

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

Heat. Heat. Heat.

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

[Music]

Wow. [Music]

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

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

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

[Music]

Heat.

Heat.

Heat. Heat.

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

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

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

[Music] Good evening everybody. Welcome to our last session. Uh welcome to Bides Las Vegas ground floor. This this talk is going to be the last talk today in ground floor and uh this talk is titled X's and OTS they haunt me and it's given by Daryl right here. Um a few quick announcements before we begin. We'd like to thank our sponsors, especially our diamond sponsors, Adobe and Iikido Security, and our gold sponsors, Drop Zone AI and Profit. It's their support along with our other sponsors, donors, and volunteers that make this event possible. These talks are being streamed live and as a courtesy to our speakers and audience, we ask that you check to make sure your

cell phones are set to silent. If you have a question, we you would be using the audience microphone that I'm holding so that YouTube can hear you and I'd bring it along if you raise your hand. As a reminder, the Bides Las Vegas photo policy prohibits taking pictures. Yes. So, please do not raise your cameras to take pictures. It's not allowed unless you have explicit permission later. These talks are all being recorded and will be available on YouTube in the p in the future. And if you guys have already settled in, please feel free to move uh move forward to let space for others who are coming in. With that, uh let's get started. Please welcome the speaker

again. [Applause] >> How's it going everybody? End of the day, Monday, right? We're all feeling energized, right? I was on a plane for about 15 hours yesterday, so I'm I'm in the middle somewhere, but we're going to get through this and we're going to have a good time, right? Um this is going to be about cloud security, cloud um authentication and authorization. Some of the differences between OIDC and um OOTH 2.0. So who am I? I'm just a guy. Uh currently I'm a solutions architect for Networks. Um work a lot with Ping Castle, a lot of the old stealth bit tools and stuff like that. So everything from uh endpoint security to network security, but I I mostly focus on

identity. Um all right, so intros were quick. Just going to talk a little bit about what OOTH is. We're going to talk a little bit about OIDC. Um the differences between the two. There is a lot of confusion that I hear sometimes. Um then we'll go over some of the vulnerabilities and common misconfigurations when you're developing your own custom web apps that need to interact with these authentication APIs. Uh we'll wrap it up with a quick just to token replay attack demo really just to show you the difference and the power of a bearer token versus other types of authentication in the cloud. Also at any point during this talk if you guys want to like raise your hand or

shout something out please. Uh, I'm not a web developer. I'm not a developer of any sorts. Uh, I tinker a lot. I'm a guy that puts band-aids on grenades, right? And we hope for nuclear bombs. Uh, so I come in in a clutch. I learn stuff real quick and then we try to like flip it and do something good with that. So I say all that uh simple because I'm learning too. I am by no means an expert in this. So let's have a good time and see where we get. All right. So um you know what is OOTH in general u not even just 2.0 know what is uh open ID connect or OIDC

um why why do they matter why am I even giving this talk today so these two protocols are really they're more than protocols these two frameworks are really kind of the backbone of identity uh today when it comes to the cloud uh a lot of people are using OOTH and OIDC and may not even know it right it's as simple as like you you've got ways you know and it's telling you where the traffic is there's a cop around the corner whatever but you also want to listen to Spotify. So you're like, "Yeah, go ahead and give ways permissions to talk to Spotify so I can listen to my next app." Right? So these are kind of some of the things that

we're talking about, right? Being able to uh authenticate or be authorized to use and access resources uh on behalf of just some random user across the internet, any internet. So essentially O 2.0 um it's a delegation protocol, right? Right? And so it lets applications access resources on behalf of users. Um, and it does that without having to handle passwords. And so the thing that's great about that, that means that uh the authorization server doesn't have to worry about passwords. The end user doesn't have to worry about passwords. Passwords aren't in your file systems. They're not in memory. They're not in your logs, etc., etc., etc., right? Every all the places we find passwords. Um, so that kind of

alleviates that piece to an extent. So there are still pieces that we have to uh worry about and we still have to secure and we'll get into those a little bit. But um these protocols are being used everywhere. Um they're used specifically for API calls, but we use them in mobile applications. We use them in SAS all the time. Um and that's really what makes them a prime target is that you can access them anywhere, anytime, all the time. And with uh cloud platforms like GCP, Azure, AWS, you have the ability to really quickly spin up these web applications that rely on these authentication and authorization frameworks, but they're not really doing any error checking or validation to make

sure that your configuration is actually secure. It may work, but that doesn't mean that it works in a secure manner. Um, okay. So, we're just going to start off with um OOTH 2.0. So was it was developed by IATF um and it was finalized in 2012. So they actually have a whole RFC that's dedicated to them uh 6749 um that actually finalized in 2013 because they made an additional revision to it. But OA's been around for a long time. OOTH 1.0 was around for a very long time by today's standards of like pin testing or red teaming or even cyber security. It was sloppy. It was effective but it was sloppy. It's the like throwing the the noodle on the My

wife's Italian anyway. Like so if you're making spaghetti, you throw a noodle on the wall. If it sticks, like the pasta's ready, like that's what it was like maybe, you know, maybe it worked. Uh so there there was a lot of holes in it. And uh so OA 2.0 came in in order to try to bring more flexibility and to uh make the framework more extensible. Uh OA 2.0 introduced four new grant types. It introduced authorization code. Uh implicit authorization. Here are the fun ones. Resource owner password credentials. And resource owners are you, the user, the person sitting on the keyboard. Um, or client credentials. And the client credentials are the application that you built, the

application that needs to interact with everything else in the wild. So you can still pass those credentials uh using the the UI 2.0. Not needed, but you can. All right. So this is a pretty common looking page whenever you're interacting uh with OOTH 2.0. Uh so this is Indie O whatever Indie O is cool but it's going to allow so when I when I log into my Twitter account it would allow me to or rather it would allow indie off to read tweets from my timeline and see who I follow. It even tells me what it can't do and I will implicitly believe it or I will read that long page that nobody reads. Right? But uh that's that's

really what uh OOTH looks like when you're the end user and you're interacting with it. It's really simple. You just say like yes, I want it to be able to do A, B, and C. That's all it can do. And those permissions are just tied to that token. Um this concept is really important when it comes to OA 2.0 because a lot of people get one concept mixed up constantly between OOTH and OIDC and it's that OATH does not offer any kind of authentication. It does not know who the user is, does not know where the user came from, doesn't there's things that you can do to uh limit your audience and even limit where the issuer comes from,

but there's no authentication that happens. It's simply a token that gets authorized to have access to some resource on behalf of the user. So if anybody has access to that token, uh they have the same access as that user does based on what it was given to that to that um access token. Okay, so OOTH is relatively easy. Um, there are a couple of terms that are weird and they they seem not as uh intuitive as normal. Like when we talk about servers, there's a few different servers involved. When we talk about clients, uh when we're talking about cloud authentication, typically, not always, but typically when we talk about a client and server uh authentication communication, the client

is actually the web application that is making that authentication or authorization request on behalf of you as the human or on behalf of some other entity that has actual access to some resource somewhere. Um in most scenarios, we refer to ourselves, right? We are the client. The machine we are is the client, but this is the cloud. Um, we don't own those machines. The client can be a lot of different things. Um, so the resource owner, that's actually who you are as you know, average Joe. You own whatever data that you have in the cloud, you know, whatever frameworks, whatever services that you have access to, those are yours. And that's why you're the resource owner. So your web

application the the whole point of it is to be able to mitigate that conversation securely and ensure that uh the web application only has access to the resources that the resource owner both has and has authorized and those two things are not the same. Just because you have authorization to something does not mean that because you create a bearer token based on your identity that that beer token has to have you know every privilege or permission that you have. you can actually make blank bearer tokens which will give you back you'll get a 200 okay so you'll know that you a you're able to uh successfully authenticate but you'll never be able to pull any resources back so that's

actually really useful for developers um all right so this is a very very very basic um authentication flow this is more of an internal facing app or an application that's not going to be public facing at all um and we'll talk about a couple of reasons why but uh just in general that application on the left, that's your client application. Um, your user is the resource owner in the top right and then your resource server in the bottom right. Those are kind of the big pieces here in this puzzle. So, it's it's simply that you wanted to access something. So, the application on your behalf goes ahead and prompts you as a user and says, "All right, well, you can log in.

You can use these different types of forms to log in in order to grant this authorization." Right? So let's say you use Google or you use Facebook or GitHub or any of these different providers. Uh you go ahead and get that authorization grant. Once that authorization grant uh is received by your browser or your web app, you get a redirect URI. That redirect URI is going to send you to the authorization server. In a lot of cases, your authorization server and your resource servers are the same, especially if you're looking internally, but this authorization server is the IDP. So whether that IDP is active directory or intra id or uh you know octa doesn't doesn't matter google

doesn't matter uh it it will always perform the exact same functions you'll get an access token and then you can use that access token for uh uh subsequent API calls now in a more secure world uh so that that last one was very straightforward uh doesn't matter what you came from. If I'm on a Linux machine, a Windows machine, a cell phone, whatever, right? I always hit that same backend. That backend interacts with the API the the exact same way. Um there have been a lot of exploits around that because not all operating systems, not all devices, not all software interacts with these APIs the same way. And so if you just have uh a backend or if you don't have a front

end that's sitting there that knows how to interact with the backend based on how that client web application would best work, you're going to end up with not the best results. You might still pull in the data that you're looking for, but it might not be formatted correctly. It might not come in um you know human readable forms and that type of thing, right? So uh this this screen this is backend for front end. Um, if there's developers that are here, I'm sure that you've you've heard of this, but backend for front end basically uh just opens up the front end so that instead of having a dedicated just one service that has to handle every single API call for every

single type of client in every single situation, which is going to get wrong a lot, uh you actually have a dedicated uh backend for front end. So based on the type of client or the type of user or other types of criteria um you will have a dedicated backend for front end that will then interact with those APIs specifically. Um, so this is brought up because this actually brings in a lot of optimization around just just uh client side programming um and scalability because you don't have to worry about for every single time that you want to add in another API service or something else like that that you have to add it into this massive uh monolithic, you

know, front end that has to handle all these different things. You can just spin up another front back end for front end and it just handles that API. um kind of similar to how uh MCP servers are working nowadays. If you guys are kind of in the MCP world, you've got this other server that does like the translation for you and that's what these these uh frameworks are doing.

So this is a a detailed just authorization flow. This is when you're using a backend for front end. It is very similar to the especially from the user standpoint. it feels the exact same. You don't notice anything different. Uh what happens is instead of having that authorization request go all the way to the authorization server, then back to you, and then you get the token all the way from the authorization server, then you send it to the application, um the application itself has a backend that acts for you on your behalf as a front end. Um and it handles that token request. So the it kicks off normal. You have an authorization request. Uh no user interactions

required. You get the uh redirect URI. Um, you get the call back request, you send it, the backend for front end then takes over, goes goes ahead and does the token request, gets the token, sends you everything you need, sets up the session for you, and then you're good to go. So, the backend for front end does a lot of the heavy lifting so that a lot of the uh the authentic authentication pieces or really the authorization pieces at the the endpoint, right? Using the token and actually being able to use that token to make a call is happening on your uh backend for front end instead of happening inside of the user's browser. And we will talk about why that's also a

problem here shortly.

Okay.

All right. Well, there was a video there. We had we had a minute and a half video that was gonna show authentication. Don't know why uh that's not working there. Um interesting. All right. Well, we might wrap up a little bit earlier. That's fine. Um so when it's used, uh OOTH 2.0 is is mostly used when it comes to delegating access for APIs and applications, right? It's made so that some other entity, typically non-human, can make requests and interact with some resource on your behalf. Um, it enables login and I lightly quote, you know, I'm air quoting login just because of what login means to some people doesn't mean the same thing to identity folks, right? Um, but

it does enable login with, you know, Google, Facebook, GitHub, all kinds of different uh frameworks without you having to create an additional account. >> Say that again. DC now. >> No, no, no, no. I'm still I'm still on Oath. >> Okay, >> I'm still on OATH. >> Sorry. >> So, the question was he's asking if I've changed and and hopped over to OIDC. No, but we're about to get there next. >> Um, so this is used and that's why I air quoted when I said login because the login is different to some people than others. So, if you actually look at the RFC and the documentation, it references logging in. It references authentication. It references a lot of

words that are not correct based on the protocol itself. So that's that. But speaking of OIDC, the prophet has spoken and we're here now. Um OIDC is an identity layer that's actually built directly on top of uh OATH 2.0. So you cannot run OIDC without OOTH. Um you have OATH and then you have additional pieces to it. Now OAH 2.0 O was originally designed for authorization uh granting thirdparty applications limited accesses access access to user resources. OIDC actually extends its support to authentication meaning that with OIDC you can actually verify and assert the identity of a user. Um this is really important because again like I said OOTH alone doesn't tell uh the client who the user is at

all. it just implicitly trusts that bearer token and then it's just going to go ahead and give access to the resources that the bearer token has access to. Um, OIDC fixes that by introducing a new type of token that's known as an ID token. Um, this is typically a JSON web token or jot token. Um, this jot token contains the claims of that user. So, it's got, you know, the username, it's got the email, the user ID, and anything else that the user wants to assert about themsel or claim about themsel. Um, OIDC is actually a dominant standard right now. Uh, which is kind of interesting because when you look kind of statistically as to uh the

progression of um, OOTH 2.0 versus like OIDC, OAH 2.0, there were people that really were against it. They did not feel like it was secure enough. um with this secondary layer of OIDC, I mean it is hands down uh the one of the most dominant if not the most dominant um authentication cloud authentication protocol that exists currently.

So uh this is what it looks like again from the user standpoint. So Corest stack is just a a learning platform that I use, right? In order to log in, you can create a new account or you can log in with a local account with Core Stack or you can sign in with Google or you can sign in with GitHub. So the ability to be able to not even create a new account with a completely different system that you've never touched and just click that log in with Google and then you get redirected and now you have account you have an account you just use your Google account. Um this is OIDC and we see this all the time. I can't

remember the last time that I've like actually logged into a web app on my phone because most of the time it's just like you want to just use that account. I'm like yeah Google it up dog Google it up you know make it easy. Uh who wants to remember another password. All right so how it works again like I said it does extend on uh the 2.0 authorization uh the oath 2.0 authorization code flow. Um what it does do is it adds an additional token and that token is going to be a jot token and the user identity is encoded in the ID token. Now this is a this is an interesting thing. So by the RFC

standard the user identity is encoded. However, Jot itself is not a standalone framework. Um it's an extension of two other frameworks. Uh there's there's some really cool JSON stuff that's out there. Um most of this is JSON web signing that we're talking about. Um, and that typically uses encoding, but there's also JSON web encryption. And with JSON web encryption, the entire thing is encrypted. Like it's it's not just encoded. That's very very hardcore stuff to break into. It's just not common. You just don't see it very often. Most of the time when we're talking about JOTS, we're just talking about JSON web signing with these additional security features. Um, so it typically starts with just a

user request. that user gets authenticated by some IDP, whether that's Google, Active Directory, Entra ID, anything else like that. That IDP will give the authentication code. This can come in a lot of different ways. It can come inside of the actual URI itself. It can come inside of a body. Uh it can come inside of other forms of metadata just depending on the IDP. A lot of times it just comes across inside of uh the actual return uh URL. So once you have that, you can use that return URL to get redirected back to typically the same IDP, but not always, but typically back to the same IDP. You've got your um you've got your au

authorization code. That authorization code allows you to get a token. Now you have your bearer token and you can use that token. Now the difference is in this scenario instead of just getting the bearer token you also get an ID token and that's where that JWT or that jot token comes into play. Uh again so this is just that flow for uh OIDC right you got the user request gets authenticated by IDP which did not exist at all in any other flows that we've talked about before. So it actually knows who the user is before the user gets authorized to anything. You get the authorization code that gets sent back to the browser and then the

browser goes ahead and gets the token and then can use that token for uh subsequent API calls. So not to spend too much time on Jot because there's like a whole bunch on Jot. Like if you guys like to break stuff, if there's red teamers out there, do it. Do your research. Do your research. It's awesome. Uh that's just me. I'm I'm I love cryptography. But uh jot token is basically made up of three parts, right? You've got a header, a payload, and a signature. Um by RFC standard, you can implement Jot tokens and IDPS in a lot of different ways, and they don't necessarily have to follow these standards, but this is what the

standard is via the via the RFC. Um what's interesting about it is like I said, sometimes the body is encrypted, sometimes the body is encoded. All this typically is is uh going to be pointed out inside of the header. The header is going to say, "Hey, this is going to be the encryption algorithm that we're using. This is going to be the length. This is this is what it's going to look like." The issue with Jot tokens and why they're such a prime target. And the reason why literally I'm having this talk today is because Jot tokens are actually incredibly secure. They're awesome. They're amazing. The code that we write to verify Jot tokens, not so

good, not so amazing, not so strong. Um, and the problem is unless again you have to know what you don't know. Um, you have to have some really strong error validation to understand that like okay well this token went ahead and passed and I got back the resource that I needed. But did the verification actually go through? Did it actually look at the ID token or did it just look at the bearer token and it got the resources when it looked at the ID token? Did it look at the entire ID token or was that ID token expired last week and we don't validate for for uh expiration dates? Um, so Jot tokens are prime targets. Left and right all day.

If there's any bug bounty hunters out there, you know what I'm talking about. All right. So, when is it used? Always, all the time, everywhere, online. Uh, if you log into pretty much most modern platforms nowadays, uh, modern applications tend to give you some sort of SSO type feel u via OIDC, right? Um, that's that's one of the main reasons why when you open up your phone, regardless of what type of phone that you have, you don't have to like log into your apps every single time that you log into your apps and things like that, right? We don't have to cach these passwords anymore. Um, we have tokens to do these things for us. Um it enables

secure more secure I'm not going to say the most secure but it enables more secure login across systems especially across other things other types of um u authentication authorization such as like basic or anonymous and you know but those things do exist they exist out there and the pin testers and bug testers will let you know that it's really interesting when you start messing with claims inside of a jot token and you throw in guest you throw in anonymous you leave it blank you throw in an actual null variable It's kind of interesting to see what happens. Um, so OIDC is widely used for federated identity and and single sign on. So again, when you use like Azure AD or

OCTA, something like that, you're pretty much guaranteed to be using OIDC underneath the hood. Um, what makes it better again is it is just OATH 2.0. It's just with this you also have authentication. OOTH does not care at all about who is the person that's making this call. You can add in some flags. You can add in some parameters to narrow that down a bit, but there's no authentication saying that this came from a true proof of source, you know, a source of truth, rather. Um, it's just it's just out there. Whereas with OIDC, before you even progress to that stage of authorization, you've already been authenticated with that IDP. So, we're going to swing back to OOTH

2.0 0 for a second and we're going to talk about some of the vulnerabilities with uh OATH 2.0. There are a there are a few vulnerabilities that are targeted around OIDC specifically, but most of the attacks that really you see in the wild that work that are successful uh whether it's a bug bounty or it's some like zero day or anything else like that, it's not oid specific. It's usually the the OOTH underlying uh process of getting that bearer token. uh because again if you can get that bearer token and there's no other verification in the system you're you're good or if the system doesn't know or it believes that you verified in some other way uh and we'll we'll talk

about that here in a little bit. So one of the most common ooth issues uh is a missing state parameter uh and this parameter is kind of important because it links the authorization request uh to uh to the actual response from the authorization server. So that's what actually prevents uh CSRF. Without that, anybody else can just hop in if they're they're able to listen in on your network or for whatever reason they're able to to to grab this conversation, they can just hijack your session. There's nothing to stop them from hijacking that session at all. Um by having that state parameter in place, it highly mitigates does not completely prevent, but it highly mitigates that

from happening. Um the second issue and this is the one that I see the most common when it comes to bug bounties and um in the past when I've done security assessments uh across Entra ID and uh just some of these you know create your own application processes that some some corporations have in place is an overly permissive redirect URI um and then an overly permissive redirect URI validation. So the URI works, the the redirect works, you go to the authorization server, it tells you, "All right, awesome. So I've given you the call back. Come back over to the server." And again, 90% of the time, if you're out in the wild, if it's not

something custom you built, it's the same server. You went to Google, Google gave you the call back, you hit some other endpoint, you know, back on Google, you know, 90 99% of the time. Um, but the issue is an attacker can actually put in their own redirect URI, right? if they're able to hijack the session, they can just say, "Hey, I'm going to point it to my own server. My own server's got a nice IDP server that's running within the standards of RFC. So, that authentication process is going to go, it's going to get a proper token, right? And if that user does actually have access and does have authorization to specific resources, more than likely, you'll get access to

some things. um depending on what type of environment that you have in federated environments like if we're talking about ADFS that token a lot of times is not just you know tied to one different one service it ties to like a slew of services like there's a whole bunch of different things you can do and move your way laterally and then now you're laterally and you're in a different you know you got a different um access token that you have and from there you can just continue to escalate and escalate and escalate at least in the Windows world Linux world not so much but in the world of Windows and ADFS yeah what once Once you get in, you're

good. Okay. So, um not going to spend too much time on this slide, but this is the same thing that we looked at earlier, right? Still, it's still got the BFF in the middle. The only difference is now the first step instead of it being the user saying that, hey, I want to access some application that's out there, they've already been hacked. They've already been pawned. Uh some attacker has been able to inject some malicious JavaScript or whatever to run in their browser. as an example. It could be a fat application. It could be any application. They will all support this flow. But this is a good example, right? JavaScript. So, JavaScript goes ahead and like it it starts off this

authorization uh flow on your behalf as the user, right? Goes out, everything starts as normal. Everything works the exact same. The difference is is in this script instead of this just being a just a plain HTML request that just goes out normal, it's going to be called inside of an iframe. And you can make iframes incredibly tiny. You can make iframes invisible. You can make iframes in the background. So this entire call, this person's just like on uh Facebook or doing whatever, checking their mail, and they have no idea that all this code is just running in the background, right? So uh when that happens, you go you go ahead and you get the redirect URI. the the attacker

actually jumps in there and it'll stop that call back and this is where the attacker sends that redirect back to their own server. So you see that right at uh step seven and after step seven the user is no longer in this authentication flow at all at this point. This is an actual authenticated and authorized flow from that attacker. If you looked in your logs, everything looks good. If you looked everywhere else, everything looks good. Uh for everybody except for whoever that user was, he's he's having a bad day probably. Of course. So, that video doesn't work either. All right. Cool, cool, cool, cool. Don't worry, there's only two videos. So, that was video two.

Let's uh cool. Um All right. So, additional OIDC vulnerabilities. Uh one of the uh the biggest ones is discovery document tampering. Um this is the way that you find it's one of the ways that you can find some of these redirect URLs and some of these URIs. Um many like many implementations of web applications actually uh trust discovery of documents and the issuer blindly. There's no verification of that. So like when you get a document and it says that it came from X, it came from Google, it came from besides Las Vegas, there's nowhere really inside the application that's verifying that. Uh so an attacker can actually just create fake tokens. Excuse me. So as long as they're

following the the RFC standards, they're going to that application is going to go ahead and go through its normal flow. Now, one of the reasons why this is possible is because a lot of times when web developers are creating applications, they're either in a rush, they don't know or they haven't fully switched from uh dev to prod uh you know with that application is they're not checking some of the parameters inside of the tokens itself. So the token has parameters such as the audience, who is this token actually for, right? This token is for, you know, DC05, but I'm presenting it over to file server 12, right? Why is it here? It should not be

here. The issuer, right? The issuer should have come from this is bad web implementation.net and it didn't. It came from this is really really bad web implementation.org. Uh, right. So, we're not looking for that. And there's also another state parameter known as a non. It's that one-time use. And a lot of times that's not even in place. And if it's in place, it's not being verified. Uh unless you're using a really kind of like major framework, I've never seen that just automatically added in. So if you're creating custom applications and stuff, the parameter for the nons is not just going to be there on its own. And even if you create the nons, the verification for that nons

is not going to be there on its own. So it'll pass and you'll think everything's good, but it's not actually verifying. Um, and again, this is one of the biggest issues with OIDC is lack of verification and there's no notification to you as the developer that yes, you succeeded to authenticate or to authorize, but you didn't succeed with your verification of of the data to get to that authentication or authorization. Um, yeah. So, well, this one is not a video. This one's live. So, hopefully demo gods are better than my YouTube gods, right? And uh it I've just got um I've got an IDP and I've got a vulnerable web app that's there. Essentially, I'm just going to log in.

I'm going to grab that bearer token. We'll curl it up and we're going to pull in some protected resources that I should not be able to get. Um but this bearer token, like I said, does come back across in the URI. And let me just

We got start container. Cool. Awesome. All right. So, got the world's fanciest uh web application here. All right. Look at that CSS, guys. Look at that CSS. Call me. All right. Let's go ahead and log in. Stole this template as well. And we'll just call it me. Doesn't matter. before. Then we'll go ahead and authorize. Cool. So, uh, I'm trying to pull in there. There's a protected route called it's it's slashprotected. You can't get it to it unless you've you've been authenticated with the system. So, I'm going to go ahead and just grab this handy dandy information here. So, this is the actual bearer token that's here. Um, the bearer token does get returned back inside of the URI itself. Um, so I

just went ahead and made it easier for myself for when I'm doing presentations to just like, "Yeah, why don't you just present it to me so I can just copy and paste?" So, let's copy and paste. Hop over here, hop in Narnia. Yep, I'm one of those guys. And, uh, yeah, and just like that, uh, completely different computer, completely different operating system, just use the same bear token. I was able to be get, uh, get access to it. So this is just to show you that it doesn't it's not about the security necessarily or the encryption or even the encoding when it comes to uh you know creating these jot tokens or creating these like in intense

frameworks really a lot of times where the flaws come into play they come into play around the verification. So like you can have a token with the most security information in the world. If your application is not checking for that and then not responding appropriately based on what it finds, you're you're going to find yourself in a in a situation every time.

All right. So the reason this worked is there was no token binding which means that I'm not using any layer of uh the session in order to tie into the actual token that I'm using as well. That's essentially a secondary signature. So if you change anything about the token or anything about the session, you know that something has been changed and it'll go ahead and and die off. The second thing is uh my token does not have expiration dates, right? It's longived token. That's a very common thing that we see out there. So even if you know a token's been exploited a long time ago, uh it's the same thing like you see with service accounts. Um they

need to have meaningful expiration dates. And the best thing that you can do, especially in a world of tokens, is that you want to have short-term lift tokens and just request and verify them on a more regular basis. You don't want to just have a long living token and just hope it's still doing everything that you want it to do. Uh the next thing is uh the no audience or the issuer validation on the resource server, right? So nothing to validate where it's supposed to be coming from and nothing to validate who this token's actually uh supposed to be served to. Uh no no token introspection or revocation support. This is kind of added on to more of like once you have a

framework in place and you have the ability to verify what do you do about it, right? Do you reject the token? Do you kick the token back? Do you alert the the fire squad and they coming down with the pitchforks or whatever? You know, that's what you do there. Um and then like no logging or anomaly detection. So anomaly detection is a big one especially in the cloud based in cloud-based stuff if you're building your own applications it's a little bit harder if you're using you know Azure if you're using AWS it's already built in for a licensing fee but uh you know it is there though so the impact of this type of attack I

mean it it is a full account impersonation again there is no verification and there's not going to be any type of secondary tertiary or any following type of uh validation of that that token as long as that token is valid and that it hasn't expired, it's it's going to stay valid. Um, one of the cool things for red teamers and the the things for blue teamers is the fact that whenever you issue these tokens, typically in in almost all cases, they bypass all MFA and login defenses around MFA and that type of thing, right? Because they are meant to be used uh with non-human entities. Um, so whereas again when we're talking about federated environments, one token

might give access to dozens of services. Um, an attacker can pivot laterally, gather data, and even abuse APIs, escalate privileges, um, or destroy records. I don't know why I went up at the end of that. Like that was positive. It wasn't positive but I felt like I was bringing it home. Uh, so detection and mitigation, again, most of the things that I've talked about have not been any actual attacks. Nothing I've talked about has been red teamcentric. So I work in the world of identity. Most of the stuff that I deal with is identity. And besides like brute forcing and and you know the stuff we've been doing for a very very long time, most most attacks

on identity don't really come from any kind of like twisting or you know new breaking bad cool yellow jumpsuit type thing. They really just come from uh misconfigurations in in the implementation of these frameworks. and then you have some guy who's sitting around or girl that that takes the time to find that hole, find that spot that you didn't cover and they're off to the races. So, preventative controls are use short-term uh excuse me, short-lived uh tokens, make sure that you validate the audience, use a nuns, the nuns will stop almost all token replay attacks because it changes every single time. Um, if you use announce, make sure that you verify that you use announce. And one one last

thing that I I'm just going to give like a tidbit because I I might have known somebody who did this and that's why they created this talk was in Node.js there are two methods when it comes to verifying an OIDC token that Jot token. Uh there is a verify method and there is a decode method. uh if you don't read all the way down to the bottom of the page, you only got to the decode message and not not to that verify message. And they do similar but not the same things. The decode uh the decode method will actually say like, hey, yeah, this is a valid token. You can use that token. It's it's good, but it doesn't verify

it. It doesn't say that the information that I got from it that is in the right format is actually the information that should be in that token. So, uh, it's it's little things like that, uh, really on the developer side of of trying to figure out and make sure you learn the things that you don't know. Um, so for me, when I had to create an app in the beginning of the year, I did not know a lot about a lot that I did not know and I went down a lot of rabbit holes and broke a lot of things and pissed off a lot of people, but but we got there. Um, there are a lot of detection measures.

There's a lot of ITDR solutions around this. Um there's a lot of monitoring especially with AI nowadays everybody and their mother any any of the big cloud platforms are going to offer some kind of um huristic behavioral analysis uh implementation again typically costs money but for most uh most organizations that's not something you can implement on your own you do typically have to outsource that to a third party um so OAF OIDC powerful but complex very small config figs, missing one word, missing one parameter, uh not verifying one thing, it it can negate every single thing else. Um so little mistakes can cause large issues. Um and really you just have to continuously test uh and monitor

your environment to ensure that your applications are doing exactly what they're supposed to be doing and only the identities that you want have access to the data that they're supposed to have access to. And that's it. I think I made it with a minute and a half to spare. [Applause] >> Oh yeah. >> Yeah. So your certificates would you say maybe like a typical workday plus like a couple hours for your hardcore devs? >> You're saying as far as securing how much time they're >> like Yeah. When do they when does your sort expire? >> Oh, so that depends. It depends on the resource, right? Right. It depends on the access because you created that

authorization for >> release. I mean like like what I'm thinking of is you know like your log insert but there might be other kinds of things. >> Right. So because you have to have some kind of human interaction. Well you have to have some kind of human interaction in order to renew that token. It's how often does that human need to interact right? So if you have something that runs every single night maybe the human if it's just updating something right like it's WSUS or something like that maybe you just need to interact with that once a week. If it is financial software, right, and it's updating, you know, transactions for the entire day, yeah, you might want to look at that

every single morning and make sure that you have a refresh token and that that you're good to go, you know? So, but that is operational, not technological.

>> Um, in the beginning of the talk, you drew an in interesting parallel between this and the MCP servers. I was just wondering if you've seen any similar attack vectors in the MCP space or you know if anything is like parallel to that world. >> Oh, as far as attacks Yeah. in the NC. No, not yet. But they're coming because uh there's so many uh MCP servers that are openly available like on GitHub and you know, script kitties don't verify their text and you're trusting some third party to make every single API call on your behalf. So yeah, you should probably read through that code before you hit go and do this thing using my credentials.

>> So can we expect like similar kind of identity problems with that space as well? Probably >> as far as uh MCPS specifically. >> Well, I mean I think that's really where it's at because an MCP server is just a translator, right? That's all it is. It's it's taking out the time for you to modify your code every single time that an API endpoint changes or that you want to interact with something else and it can just do that for you. um you creating an MCP server, I don't really see any inherent issues with that. Um depends on of course like how you're interacting with it, but I don't see any inherent issues uh with with that

directly. It's more of when you trust that that code from somewhere else because you're going to give it your authentication, you're going to give it authorization, it's going to interact with APIs that you think it's interacting with, but if you haven't done any kind of um you know SAS testing at minimum against that code, I you know, I wouldn't run it. Okay. >> Thank you. Um, I'm going to ask something that's more uh specific. Um, so I mean if you can't answer this question, that's all okay because it's it's very specific. So the CSRF attack uh the the flow that you demonstrate earlier. So that one so is that the condition for that to work is

because that flow uses the set cookies. So if for example if I don't persist the persist the the the um the token on the desk >> would that prevent this kind of issue of happening? >> So so I don't I don't know the full answer to that. I don't I don't want to say the answer is yes. But I will tell I will say this that regardless of if the cookie is present or not present uh it can still work. It does depend on the type of cookie that you're using. Um because you can you can execute this code regardless of if the session is stateful or stateless. >> Yeah, that's interesting.

>> Are are you familiar with the uh pass keys at all? >> No. >> Because some of the issues you've talked about like lack of revocation, lack of logging, yes. Lack of transparency, I believe, issues uh affects Pesky's as well. Um it's it's hard to when they go bad, you don't know they go bad. You they're stolen. You don't know if they're stolen. Um and they do they are a pretty cool thing, but there's just little flaws in the implementation that sound like this. >> Yep. Yeah. And it's because you're using some other um method uh in order to represent your credential set. you know, we you see the same thing with Windows Hello is pretty solid, but a few years

back and stuff, you know, when you're when you're uh using CAT cards and and things like that, like it's it's interesting, right? Because it's just tying your password or your identity, not really your password, but your identity to like some PIN that's on your system. So, if your system gets compromised, all you have to do is set a new PIN. You don't have to change your password. You don't have to worry about that. In your example earlier, you had the token coming back from your IDP in the URI. Uh, and then in your list of misconfigurations, uh, I saw both URI containing the token and Pixie. Isn't Pixie supposed to solve that or am I completely off the

reservation there? >> Yeah. Okay, hold on. Let me go back a couple slides. It'