Speaker 1: All right, let's dive into something pretty cool today, something
Speaker 1: a little cloak and dagger. We're going to be looking
Speaker 1: at web application hacking.
Speaker 2: Oh fun.
Speaker 1: Yeah, you know the kind of stuff gug bounty hunters
Speaker 1: use to uncover those nasty vulnerabilities. Right, we're working with
Speaker 1: some excerpts from a cybersecurity book kind of like our
Speaker 1: little secret weapon.
Speaker 2: I like it.
Speaker 1: It goes deep into advanced techniques and our mission today. Yeah.
Speaker 1: Imagine you right now are tasked with securing a web application.
Speaker 1: What are those sneaky, unexpected attacks that keep you up
Speaker 1: at night? Well, today's your crash course.
Speaker 2: I like that. And what's great about this book is
Speaker 2: it doesn't just list out vulnerability. It actually gets inside
Speaker 2: the hacker's head. It shows how they chain together exploits,
Speaker 2: how they turn even harmless features into weapons.
Speaker 1: It really does. And right off the bat it jumps
Speaker 1: into de serialization attacks. I'll admit the term itself sounds
Speaker 1: kind of techy. Did you break it down for us, like,
Speaker 1: what's going on there?
Speaker 2: Sure? Sure? Imagine packing a suitcase, right, Ok, you get
Speaker 2: your clothes, toiletries all neat and tidy.
Speaker 1: Yeah, that's like serialization in the coding world. Taking data,
Speaker 1: all those structures within an application and packing up for travel,
Speaker 1: for storage or transmission.
Speaker 2: Okay, making it compact, easy to move around exactly Now.
Speaker 1: De serialization, that's unpacking the suitcase at your destination, getting
Speaker 1: that data back to its original usable form.
Speaker 2: Got it. So, where's the danger. It's just unpacking data.
Speaker 1: Uh, that's where things get tricky. The danger comes in
Speaker 1: when a hacker messes with that suitcase before you unpack it. Oh,
Speaker 1: if they can tamper with the serialized data, slip in
Speaker 1: some malicious kind sneaky. Well, when the application unpacks it, boom,
Speaker 1: that code executes. It's like hiding something dangerous in your luggage,
Speaker 1: waiting for it to wreak havoc when you open it.
Speaker 2: So, in a web app, how do I stop someone
Speaker 2: from sneaking that dangerous something into my data?
Speaker 1: Never ever de serialized data from untrusted sources without some
Speaker 1: serious checks. It's like inspecting your suitcase for anything suspicious
Speaker 1: before you open it up completely.
Speaker 2: Right, make sure there's no weird ticking sounds. Exactly now.
Speaker 2: The book mentions PHP object injection and Python peockle serialization
Speaker 2: as common targets.
Speaker 1: I've heard of those.
Speaker 2: Yeah, these mechanisms. If they're not carefully implemented well, hackers
Speaker 2: can inject malicious objects, exploiting how those languages rebuild the data.
Speaker 1: So they're like twisting the instructions for how to unpack.
Speaker 2: You got it. Now, you've probably heard the term PIOP chains.
Speaker 1: Oh yeah, that one sounds kind of scary.
Speaker 2: It can be property oriented programming chains. It's like the
Speaker 2: hacker setting up a domino effect.
Speaker 1: Oh okay.
Speaker 2: Each domino is a little piece of code, harmless on
Speaker 2: its own right, but trigger them in the right order.
Speaker 2: Those harmless pieces can lead to taking over the server,
Speaker 2: stealing data, all sorts of nasty stuff.
Speaker 1: Yikes. So, as someone trying to keep an application safe,
Speaker 1: what are the best defenses against these de serialization attacks?
Speaker 2: You got to have a multi layered approach. First, sanitize, sanitize,
Speaker 2: sanitize user input before even thinking about de serializing.
Speaker 1: It, right like scrub it clean exactly.
Speaker 2: Second, use secure serialization libraries. One's less prone to these attacks.
Speaker 2: And of course, keep everything updated patching those known vulnerabilities.
Speaker 1: So it's not just writing secure code, it's a whole strategy.
Speaker 2: You got it. And speaking of sneaky attacks, let's switch
Speaker 2: gears a bit. Type juggling attacks heard of those?
Speaker 1: I have, Yeah, But to be honest, I'm a bit
Speaker 1: fuzzy on the details. Are they really as bad as
Speaker 1: some make them sound?
Speaker 2: Oh? They can be, They can be. It might not
Speaker 2: sound as dramatic as say, taking over a whole server, right,
Speaker 2: but type juggling exploits how some languages, especially PHP, compare
Speaker 2: different kinds of data. Like PHP might say the number
Speaker 2: zero and the string zero are basically the same if
Speaker 2: you're not careful.
Speaker 1: Uh oh, I see where this is going.
Speaker 2: Let's say you've got a log in form username, admin,
Speaker 2: password password classic.
Speaker 1: Right, yeah, not very secure though, huh huh.
Speaker 2: Right, But the point is a hacker with type juggling
Speaker 2: in mind might just enter zero for.
Speaker 1: Both zero for user name and password. That's it.
Speaker 2: And if the application uses loose comparisons, the kind that
Speaker 2: doesn't check the data type.
Speaker 1: It just sees zero matches zero, and boom, they're.
Speaker 2: In admin privileges just like that.
Speaker 1: So as a developer, how do I stop these type
Speaker 1: juggling shenanigans.
Speaker 2: Strict comparisons, my friend. Strict comparisons always, especially when you're
Speaker 2: checking user input.
Speaker 1: So not just if the values match, but if they're
Speaker 1: the same type of.
Speaker 2: Data precisely gets rid of all that ambiguity that hackers
Speaker 2: love to exploit.
Speaker 1: Okay, starting to see how those little quirks in programming
Speaker 1: languages can become huge security flaws.
Speaker 2: Oh. Absolutely, It's all about knowing those quirks and then thinking,
Speaker 2: like the bad guy, how would they twist this to
Speaker 2: their advantage?
Speaker 1: Right, get inside their heads now.
Speaker 2: The book also mentioned something called zero like type juggling.
Speaker 1: Zero Like that sounds even trickier it is.
Speaker 2: It is certain strings in PHP, when you compare them loosely, Oh,
Speaker 2: they end up being treated like the number zero.
Speaker 1: So like a blank space or something.
Speaker 2: Empty string, a string with just spaces. Yeah, that sort
Speaker 2: of thing, And a.
Speaker 1: Hacker could use those to sneak past checks that are
Speaker 1: looking for numbers.
Speaker 2: Exactly, manipulate input fields, parameters, stuff that wouldn't be obvious
Speaker 2: at first glance but can have big consequences.
Speaker 1: Wow. So type juggling really praise on the assumptions developers make.
Speaker 2: It does it does? And that brings us to our
Speaker 2: next topic. No SEQL databases. There's this myth out there
Speaker 2: that they're immune to injection attacks because they don't use
Speaker 2: SQL right.
Speaker 1: No SQL all about flexibility handling all sorts of unstructured data,
Speaker 1: right right.
Speaker 2: But just because it's not SQL doesn't mean it's safe.
Speaker 1: So hackers has figured out how to inject commands even
Speaker 1: without that classic SQL syntax they have.
Speaker 2: The book goes into some specific examples, with Mango dB
Speaker 2: and couch dB two of the popular ones. They show
Speaker 2: how hackers can craft these malicious queries that exploit weaknesses
Speaker 2: in how the database handles user input.
Speaker 1: So even if I'm not using SQUEL, I still got
Speaker 1: to be super careful about how I handle that data
Speaker 1: coming in from users.
Speaker 2: Absolutely improvalidation, standardization. Those principles apply no matter what kind
Speaker 2: of database you're using. And by the way, there are
Speaker 2: tools out there like no SQL map made specifically to
Speaker 2: find and exploit those no SQL vulnerabilities.
Speaker 1: It's like hackers have a special toolkit for every occasion
Speaker 1: they do.
Speaker 2: And speaking of toolkits, let's move on to another area
Speaker 2: where hackers are pretty creative. API hacking, especially when it
Speaker 2: comes to graph ql.
Speaker 1: APIs so graphql it's known for being really efficient, flexible,
Speaker 1: all that, but is it also known for being well insecure?
Speaker 2: Graphql itself doesn't prevent common vulnerabilities like SQL injection or
Speaker 2: cross site scripting. It all depends on how it's implemented,
Speaker 2: how secure the data sources and logic are underneath.
Speaker 1: So a hacker going after a graph QLAPI, they're not
Speaker 1: necessarily exploiting graphql itself, but rather how it's used.
Speaker 2: Exactly. Think of graph ql as a powerful tool, like
Speaker 2: a really sharp knife.
Speaker 1: Right.
Speaker 2: It can be used for good or bad. It's all
Speaker 2: in how you wield it.
Speaker 1: Okay, So walk me through this. How would a hacker
Speaker 1: approach a graph ql API? What are they trying to do?
Speaker 2: First step is usually reconnaissance. They got to find those
Speaker 2: graph ql endpoints and then figure out the schemer.
Speaker 1: Schema like a map of the API.
Speaker 2: That's it, the structure, the capabilities. They're a little blueprint
Speaker 2: for the attack.
Speaker 1: So intel gathering before the actual attack.
Speaker 2: Yep. Then they start crafting malicious queries, looking for ways
Speaker 2: to bypass authentication, grab sensitive data, even inject code that'll
Speaker 2: run on the server.
Speaker 1: Yis. So securing a graph ql API is more than
Speaker 1: just slapping on some basic login protection.
Speaker 2: Way more. You gotta think like a hacker. Imagine how
Speaker 2: they'd try to abuse.
Speaker 1: The system, right, stay one step ahead.
Speaker 2: That's the game. Now, let's not forget another big target
Speaker 2: for these guys, misconfigured cloud storage.
Speaker 1: Oh yeah, that's a big one these days.
Speaker 2: Cloud storage it's super convenient, but if it's.
Speaker 1: Not set up right, the gold mine for hackers.
Speaker 2: You got it, all those AWSS three buckets, Digital Ocean spaces,
Speaker 2: Azure blobs, Google cloud storage. If the permissions are loose,
Speaker 2: files are public.
Speaker 1: It's like leaving the door wide open.
Speaker 2: And this book has some scary examples of the commands
Speaker 2: hackers use. They probe for weaknesses, list files, download data,
Speaker 2: even delete or modify stuff.
Speaker 1: So it's not just about stealing data, it's about causing
Speaker 1: chaos unfortunately.
Speaker 2: Yeah, and what's worse, there are tools out there aws
Speaker 2: bucket dump, spaces Finder, things like that. These tools automate
Speaker 2: the whole process of finding and exploiting these misconfigured cloud setups.
Speaker 1: So it's like a shopping spree for hackers, browsing through
Speaker 1: vulnerable storage buckets taking what they want.
Speaker 2: That's a pretty accurate picture. And the scary part is
Speaker 2: a lot of companies don't even know how much sensitive
Speaker 2: data they have out there in the cloud or how
Speaker 2: bad their security is.
Speaker 1: All right, starting to feel a little paranoid.
Speaker 2: Now, don't worry, We're not done yet. There's a lot
Speaker 2: more ground to cover in this deep dive. Next up,
Speaker 2: we'll get into server side request forgery, a really sneaky
Speaker 2: attack that takes advantage of how applications trust each other.
Speaker 1: Okay, I'm all ears. Let's see what other tricks these
Speaker 1: hackers have up their sleeves. Yeah, we've been talking about
Speaker 1: how hackers target databases and APIs, and it seems like
Speaker 1: no matter what you use, there's always some angle they
Speaker 1: can exploit.
Speaker 2: Yeah, that's true. And as applications get more complex, right,
Speaker 2: you know, relying on all these different systems talking to
Speaker 2: each other, Well, that just creates more opportunities for attacks.
Speaker 2: That's what makes this next topic so interesting. Server side
Speaker 2: request forgery SSRF.
Speaker 1: SSRF. I've heard that term, yeah, yeah, but not really
Speaker 1: sure what it is.
Speaker 2: Okay, So think about it this way. A lot of
Speaker 2: web apps they need to fetch data from other systems, right,
Speaker 2: internal services, things like that.
Speaker 1: Right behind the scenes stuff exactly.
Speaker 2: And they do this by making requests within their own network,
Speaker 2: you know, where they trust everything, right. SSRF is all
Speaker 2: about tricking the application into making those requests to places
Speaker 2: that shouldn't be going.
Speaker 1: Oh so it's like the app becomes its own insider threat.
Speaker 2: Exactly, it's tricked into fetching data that it shouldn't have access.
Speaker 1: To, and the hacker is pulling the string, pulling the.
Speaker 2: Strings exactly, the app is making requests on the hacker's behalf. Essentially,
Speaker 2: in this book, it goes into some really clever techniques
Speaker 2: they use. Okay, like what well, for example, they might
Speaker 2: use tools like BURP Collaborator or SSRF.
Speaker 1: Maps sound familiar.
Speaker 2: Yeah, these tools they act like little listening posts. The
Speaker 2: hacker can see if the application is making requests to
Speaker 2: their servers.
Speaker 1: Oh so that's how they test if it's vulnerable in
Speaker 1: the first place.
Speaker 2: Exactly, if they see those requests coming in, they know
Speaker 2: they've got a potential SSRF vulnerability.
Speaker 1: Okay, So let's say they find a vulnerable app. What's
Speaker 1: the worst case scenario? What can they actually do with that?
Speaker 2: Oh, it can be bad. It can be bad. They
Speaker 2: can use SSRF to get into sensitive internal systems. Okay,
Speaker 2: steal data that's not publicly accessible, even run commands on
Speaker 2: those internal servers.
Speaker 1: Yikes.
Speaker 2: Imagine them getting into a company's financial records or they're
Speaker 2: customer database.
Speaker 1: It's been manipulating these internal requests exactly.
Speaker 2: Now, the book also mentioned something interesting, exploiting cloud based
Speaker 2: metadata APIs.
Speaker 1: How does that work?
Speaker 2: Okay, So with the cloud, applications often run in these
Speaker 2: environments where they can access metadata services. These services provide
Speaker 2: info about the app's configuration, the infrastructure around it. Hackers
Speaker 2: can use SSRF to force the application to query these
Speaker 2: metadata services.
Speaker 1: Oh, so they can learn about the whole cloud.
Speaker 2: Environment exactly, potentially revealing sensitive details that they can then
Speaker 2: use for further attacks. And what makes it tricky is
Speaker 2: that these cloud metadata services, they often have very predictable structures.
Speaker 2: It's like giving the hacker a blueprint of the cloud environment.
Speaker 1: All thanks to one vulnerable app.
Speaker 2: And the book even talks about using the Gopher protocol.
Speaker 1: Gopher that's like ancient, right it is.
Speaker 2: But it can still be effective for SSRF in certain situations.
Speaker 1: So they're dusting off these old tricks.
Speaker 2: They are they are. It just shows you how creative
Speaker 2: these guys can be. Now, let's shift gears a bit.
Speaker 2: Let's talk about application logic flaws. Okay, these are vulnerabilities
Speaker 2: that come from mistakes in how the app is designed,
Speaker 2: not necessarily from bad code itself.
Speaker 1: Oh interesting, So, like, what's an example of that.
Speaker 2: Imagine an e commerce site, right, they have discount coupons
Speaker 2: you can apply it check out.
Speaker 1: Yeah, pretty common.
Speaker 2: A hacker might find a way to mess with the
Speaker 2: logic of that coupon system, you know, to apply multiple
Speaker 2: discounts at once.
Speaker 1: So they get set for free or almost free.
Speaker 2: Exactly. The book has all sorts of examples like this, okay,
Speaker 2: like what manipulating input fields to bypass checks, exploding race
Speaker 2: conditions where multiple things happen at the same time, even
Speaker 2: tricking the application into revealing sensitive info through error messages.
Speaker 1: So it's not about breaking the code, it's about breaking
Speaker 1: the rules of the game exactly.
Speaker 2: It's like they're master illusionists, finding those loopholes in the
Speaker 2: logic to do things that shouldn't be possible.
Speaker 1: And these logic flaws they seem harder to defend against.
Speaker 2: They are. They are because you need a really deep
Speaker 2: understanding of how the application works what it's supposed to do.
Speaker 1: So it's not enough to just write secure code. You
Speaker 1: need to understand the whole picture precisely.
Speaker 2: Now, let's talk about something that's supposed to make things
Speaker 2: more secure. Authentication and authorization protocols like SAML and OTH
Speaker 2: two point zero.
Speaker 1: Okay, I've heard those terms, but I'm not really sure
Speaker 1: how they work.
Speaker 2: Okay. So SAMLUS that stands for Security Assertion Markup Language.
Speaker 2: It's a way for different systems to securely exchange info
Speaker 2: about authentication and authorization. It's often used in businesses for
Speaker 2: single sign on. You know where you log in once
Speaker 2: and you can access multiple applications.
Speaker 1: Right, makes things easier for users exactly.
Speaker 2: But of course hackers have found ways to attack SAML too.
Speaker 1: No surprise there, AMLL.
Speaker 2: It uses XML, and that makes it vulnerable to something
Speaker 2: called XML external entity injection attacks or x e XX.
Speaker 1: I think I heard of that.
Speaker 2: Yeah, it's all about exploiting how XML documents are processed.
Speaker 2: Hackers can craft these malicious XML documents okay, and trick
Speaker 2: the server into accessing external entities and that can lead
Speaker 2: to oh, all sorts of bad stuff, sensitive data leaks,
Speaker 2: denial of service attacks, even remote code execution.
Speaker 1: So it's like turning the XML processing into a weapon exactly.
Speaker 2: They can use it to read files from the server, okay,
Speaker 2: access internal networks, even run commands.
Speaker 1: Wow, that's a lot of power from one seemingly simple attack.
Speaker 2: It is, so if you're implementing SAML, you've got to
Speaker 2: be really careful about how you can figure that XML
Speaker 2: parser right.
Speaker 1: Make sure it's not doing anything it shouldn't.
Speaker 2: Be doing exactly. Disable external entity resolution if you don't
Speaker 2: absolutely need it, and always sanitize any external input before
Speaker 2: you even think about treating it as XML.
Speaker 1: Treat it with extreme caution exactly.
Speaker 2: And the book also mentions other SAMMEL attacks, things like
Speaker 2: signature stripping and XML signature wrapping.
Speaker 1: So it's like a whole world of vulnerabilities within SAML.
Speaker 2: It can be if you're not careful. Now let's talk
Speaker 2: about both two point zero. That's another popular authorization protocol.
Speaker 1: Yeah, oh, I see that all the time logging into
Speaker 1: websites with my Google account.
Speaker 2: Or Facebook, right exactly. OATH is all about delegating authorization.
Speaker 2: So instead of sharing your password with a third party app, right,
Speaker 2: you just give them permission to access your account through
Speaker 2: this secure process.
Speaker 1: Much safer than typing in your password everywhere, way safer.
Speaker 2: But like any complex system, OATH two point zero has
Speaker 2: its own weaknesses, like.
Speaker 1: What give me an example of something that would keep
Speaker 1: a developer up at night.
Speaker 2: Okay, so one common attack is insufficient redirect URI validation
Speaker 2: redirect URI.
Speaker 1: What's that?
Speaker 2: So when you authorize a third party app with OTH,
Speaker 2: there's this redirect URI that tells your browser where to
Speaker 2: go after you've given permission.
Speaker 1: Okay, so it's like the return address exactly.
Speaker 2: Now, if the app doesn't properly validate those redirect URIs,
Speaker 2: a hacker can create a malicious one and.
Speaker 1: Send the user to a fake website exactly.
Speaker 2: The user thinks they're going back to the legitimate app.
Speaker 1: But they're actually giving their info to the hacker.
Speaker 2: That's right. And the book goes into other obooth vulnerabilities too,
Speaker 2: things like cross site request forgery, Yeah I've heard of
Speaker 2: that one, and authorization code replay attacks. So even with
Speaker 2: these modern authorization protocols, there's still plenty of room for error.
Speaker 1: It seems like everywhere we look there's another potential vulnerability.
Speaker 2: It's a constant game of cat and mouse. Attackers are
Speaker 2: always finding new ways to exploit things.
Speaker 1: This deep dive is definitely making me rethink my whole
Speaker 1: approach to security.
Speaker 2: It's all about awareness. The more you know about these vulnerabilities,
Speaker 2: the better you can defend against them.
Speaker 1: Right, So what comes next?
Speaker 2: Well, in part three, we'll take all this information we've
Speaker 2: covered and we'll distill it down into some key takeaways,
Speaker 2: some actionable advice you can actually use to make your
Speaker 2: systems more secure.
Speaker 1: Okay, we've gone through a lot. Yeah, we have decerialization,
Speaker 1: sam l O Walth all those vulnerabilities, right, I gotta
Speaker 1: be honest, it's kind of overwhelming.
Speaker 2: I can't understand.
Speaker 1: That makes you realize just how many ways a hacker
Speaker 1: could get into an application.
Speaker 2: But that's not the point of this deep dive, right.
Speaker 2: The goal isn't to scare you. It's to give you
Speaker 2: the knowledge you need to build things better, more secure systems.
Speaker 1: Okay, so let's talk defense. If I'm building a web app,
Speaker 1: what are the biggest lessons here the must dos to
Speaker 1: protect myself from all these attacks?
Speaker 2: I think the biggest thing is security. It's not just
Speaker 2: a checklist, it's a way of thinking. You got to
Speaker 2: constantly be thinking like a hacker.
Speaker 1: Easy to say, hard to do, huh, Right.
Speaker 2: But seriously, you've got to imagine how they try to
Speaker 2: exploit your app.
Speaker 1: But how do I get into that hacker mindset. I'm
Speaker 1: not a security expert.
Speaker 2: Well, this book is a good start. It shows you
Speaker 2: the common attack patterns. Okay, so you can start to
Speaker 2: see your app through their eyes, and then you can
Speaker 2: build defenses that actually address those vulnerabilities.
Speaker 1: So it's not just about generic security tools, No, it's
Speaker 1: about understanding the specific threats.
Speaker 2: You face exactly now. One thing that keeps coming up
Speaker 2: again and again in this deep dive input validation and sanitization.
Speaker 1: Right, assume all user input.
Speaker 2: Is evil exactly. Never trust it, validate it, sanitize it,
Speaker 2: escape it properly before you use it for anything.
Speaker 1: Queries commands, anything like.
Speaker 2: That prevents a whole bunch of attacks right there.
Speaker 1: Doable injection, cross site scripting, even those deserialization attacks, all
Speaker 1: of them.
Speaker 2: It's like having a security checkpoint at the entrance to your.
Speaker 1: App, carefully screening everything that comes in.
Speaker 2: Another big one, secure configuration and patching strong passwords, access controls,
Speaker 2: disabling anything you don't need, okay, and keep your software
Speaker 2: up to date. Those security patches are crucial.
Speaker 1: Sounds pretty basic, but I guess it's easy to overlook.
Speaker 2: It is, and you'd be surprised how many attacks happen
Speaker 2: because of simple configuration mistakes.
Speaker 1: It's like leaving the door wide open exactly now.
Speaker 2: Besides secure coding, input validation, a good configuration.
Speaker 1: Yeah, what else?
Speaker 2: Testing and monitoring. You can't just build something, add some
Speaker 2: security features and then forget about.
Speaker 1: It, right, It's an ongoing process.
Speaker 2: Security is a journey, not a destination. Regular penetry, creation, testing,
Speaker 2: vulnerability scanning, security audits, all that stuff is essential.
Speaker 1: So it's like having a security team constantly on patrol
Speaker 1: looking for weaknesses.
Speaker 2: That's a good way to think about it. And technology
Speaker 2: keeps changing. New threats pop up all the time, so
Speaker 2: you got to keep adapting.
Speaker 1: This deep dive has definitely made me realize how important
Speaker 1: it is to stay informed.
Speaker 2: It is, it is, but that's also what makes security
Speaker 2: so interesting. Yeah, it's a constant challenge. You got to
Speaker 2: be creative, solve problems, learn from your mistakes.
Speaker 1: I'm definitely leaving this deep dive feeling a lot more
Speaker 1: aware of security, maybe a little more paranoid, but also
Speaker 1: more empowered.
Speaker 2: You know, good, good knowledge is power, like they say,
Speaker 2: And remember security isn't just about preventing attacks. It's also
Speaker 2: about building systems that can recover if something does happen.
Speaker 1: So it's not just about walls, it's about resilience.
Speaker 2: Exactly as we wrap up one less thought, Okay, we're
Speaker 2: moving into a world of even more interconnected systems, the cloud,
Speaker 2: IoT a all that the security challenges are only going to
Speaker 2: get tougher.
Speaker 1: That's exciting and scary at the same time.
Speaker 2: It is it is, but if we understand the principles
Speaker 2: of secure design, think like those hackers, keep adapting our defenses,
Speaker 2: we can build a more secure future for ourselves and
Speaker 2: for all the technology we create.
Speaker 1: Well said, thanks for taking us on this deep dive,
Speaker 1: my pleasure. It's an eye opening definitely something to think about.
Speaker 2: Remember, stay curious, stay vigilant, never stop learning, And.
Speaker 1: For everyone listening, thanks for joining us. Until next time,
Speaker 1: stay secure out there.