Cloud Visibility, Fortibleed, hacking things the easy way - Sandy Bird - PSW #932

Speaker A: This week. First up is Sandy Bird from Sunray discussing how to protect our cloud infrastructure. Then in the security news.

Speaker B: Help.

Speaker A: I'm forta bleeding. Cisco SD WAN needs help. The secret life of probe requests. Help. I'm also squid bleeding cross site scripting to remote code execution. And why CVSS isn't the full picture. Your TV is spying on you. Foundational security practices. Cybersecurity costs money. Happy it's too late to update your Microsoft CAC key day. You don't have security flaws if no one can report them. Rickrolling, FIFA, domain takeovers, end of life, out of luck, and the key to encryption. All that and more on, um, this episode of Paul's Security Weekly. Broadcasting live from Gunit Studios in Rhode Island. It's the show where exploits run wild, packets aren't the only things getting sniffed, and the cocktails flow steady. It's Paul. Paul. Security Weekly, coming to you from the Hacker Syndicate Studios. This is Paul's Security Weekly. It's episode number 932 being recorded on Wednesday, June 25, 2026. I'm Paul Sidorian, joined by Mr. Larry Pesce. Larry, welcome.

Speaker B: Thanks for having me. Yeah, it's been an interesting week so far.

Speaker A: I know. This is my first day back from vacation, so you can imagine we just get busy.

Speaker B: Just got back from college orientation, so.

Speaker A: Yeah, busy summer. Mr. Lee Neely is here with us. Lee, welcome. Sorry, Lee, I saw that you were muted, and then I called on you because you were just next in the order that I had. It's totally cool.

Speaker C: I muted because something started making noise all by itself in the background and finally got it to shut up.

Speaker D: What's Shelly doing?

Speaker E: Something?

Speaker A: Um, no, actually, it's not her fault at all.

Speaker C: It's me. I'm the one to be clicking on stuff.

Speaker A: Uh, Mr. Josh Marpet is here with us. Josh, welcome.

Speaker E: Thank you. Thank you, Lee. And that's when you hear your name. That's when you click on the. The mute button.

Speaker A: Just.

Speaker E: Just letting you know. Okay.

Speaker A: Man, I always thought it was when

Speaker C: I heard your name.

Speaker A: And live From Tour Camp, Mr. Dave Johnson is here with us.

Speaker E: Hey.

Speaker F: Hey, everybody. This, uh, is not the worst on site reporting I've ever done. Definitely having a great time already.

Speaker A: Looks nice. Uh, Mr. Jeff Mann is here with us. Jeff, welcome.

Speaker D: It's not Tor camp, but now I'm getting anxious to head up to upstate New York for Gray Fox Bluegrass Festival in a month.

Speaker E: Nice.

Speaker A: Awesome. Quick announcement before we get into it. Uh, let's be real. Your scanners are dumping thousands of vulnerabilities. Half of them are noise. And you still don't know what's actually exploitable in your environment. Patching everything isn't possible and chasing CVSS isn't working. A great example of that. Uh, probably a couple actually. At the Vulnerability Management Virtual Cyber Security Summit, you can learn how to prioritize based on exploitability, reduce false positives, and actually fix what matters. Security Weekly listeners can register for free@securityweekly.com vuln management using the promo code CSS2.6S. This segment is sponsored by Sunree Security. We have with us today Sandy Burr, the CTO and co founder. Sandy, welcome to the show.

Speaker G: Hey, thanks for having me.

Speaker A: It's good to have you. Sandy. Start off by telling, uh, us how you got your start in information security.

Speaker G: That was 20 plus years ago. I was one of the co founders of.

Speaker D: So you're a noob.

Speaker G: Definitely a noob. Only 20, 25 years, whatever. Um, yeah, I was one of the founders of a company called Q1 Labs many, many years ago. And, uh, that created a SIM product, if you remember those things. Before AI socked. Yeah, exactly. And, uh, you know, years went by. We ended up selling that to IBM. And when I moved over to IBM after the acquisition, I was the CTO of their security division for five years actually, which is, you know, most people say, oh, you know, IBM acquisition, you're going to leave. But I actually stayed for a while. Um, it was really neat. We had all the security researchers as part of our group and I lear tons of stuff about quantum encryption and stuff that even my head does, still doesn't quite understand. Um, and so that was all kind of fun. And then at some point in time I said, look, I got to get out of a big company that has 300,000 employees and get back to, uh, you know, some people in a whiteboard. And so we founded Sunrays Security. And we, this is like the 2018 era. And we looked at these cloud platforms, you know, the Hyperscalers, aws, Azure, gcp. And I looked at all the stuff I'd done in the sim world for years and said, oh, you know, for years I'd been selling this stuff, saying it understands these clouds fine. And then I actually went and looked at the clouds, said we didn't have a clue what we were doing. We were looking at these clouds.

Speaker A: Right, right.

Speaker G: And so we, uh, unwound that, discovered there were some really serious identity, I'm going to call them problems or opportunities in the clouds to solve. And so we really, really focused on that. And so I spent years building least privilege inside of these hyperscalers for people. And a, uh, couple of years ago I actually sort of gave up on that vision. Um, I discovered that we were generating like 10,000 tickets, 100,000 tickets for a team and saying, go fix all the stuff that you've done. Nobody's going to fix 100,000 tickets. It doesn't make any sense. And so we found a way to do least, uh, privilege without the developers having to do any work. So that was much better. And uh, they have a tendency to like that better in their life and uh, it gets you the least privilege and security without having to do the work. So that's my.

Speaker A: So it's really, uh, more privilege management and control, not so much like cloud security posture management, which is like auditing your configs, Right?

Speaker G: Correct, exactly. Like when we started. So when we started that was all one thing. Like nobody really differentiated any of it. And then over time you had kind of the CSPM world, the CIEM world, which was the identity side, cwpp, which was the workload protection and the vulnerability stuff. And it all became CNAP at one point in time. Still, um, is, I think still use that category. And then so at, you know, we were quite narrow compared to say Wiz or something that does everything for, for everybody. And uh, so that was where that kind of came from. But we've really focused over the last couple years to just solving this kind of identity problem that happened within the uh, within the cloud. So.

Speaker A: Yeah, because it's, it's so much work. Right? I mean this is my day job, right? We're very, very careful about privileges. Right. And um, when I joined the company I was in marketing and so like by default like that role gets like, no privileges. Right? And but they're like, you're going to do like, do security research too. And so I have to request every, you know, bit of privilege that I need and it's very, very daunting. Um, and that kind of, you know, like it culminates. So I, funny story, I vibe coded an app for myself and then all of a sudden everyone in the company wanted to also use it. And I was like, well, I never intended for that to happen. And they're like, we should deploy it to insert cloud provider here. I'm like, great. Never used that particular, you know, infrastructure or hyperscaler before. So here I go with AI. I'm like, can you just go deploy my app, like link it to GitLab? Uh, make it, you know, a pipeline. And I'm like, I don't know how that works. I'm just relying on the fact that we've got privileges in people looking, looking over that. Right. And that's just one small use case. But there's so much, so many details there. Sandy, how do you tackle that problem and how do you allow developers like myself, especially for like a small internal app, to go within the guardrails and not create a huge exposure for the organization? Right, that's the goal.

Speaker G: Yeah. And again, I think this was kind of my epiphany two years ago after doing this and we had, like I say, all these customers were saying to the developers, you have to go fix the stuff that they had already put in. Right. They that time they were maybe weren't vibe coding the app, but they built the app, they deployed the app and it was there. And now we had to go clean it up. And so we, Yep, we changed the model. Instead what we did, we used all this analytics to go back in history and see everything that the app had done previously. And instead of telling the developers, go fix the identity on the app, we used all the cloud providers, all the hyperscalers have these, um, global security policies that you can put in place in AWS. They're SCP service control policies or RCP's resource control policies. And so what we did, we inverted the logic to basically restrict the privileged permissions at the global level. So everybody was denied. No one could create a vpc. No one could create a created access key. No one could do that. But we use the history to then make exceptions in those global policies for the things that needed them. And so all of a sudden, everything that had ever created an access key before, whatever, was still able to do it, but everybody else that was privileged to do it, that hadn't, didn't. And so you had this kind of based on activity. Yeah, exactly. So it almost creates a white list of the things that need privilege. And basically default denies everything that doesn't need privilege. And so you end up in this least privileged state with no work. You don't have to do anything.

Speaker B: Uh, yeah.

Speaker A: It reminds me of when I used to set up firewalls and just put allow rules in and then monitor and go, oh, I should definitely be blocking that.

Speaker G: You got it.

Speaker A: Allow that. And then culminate in the. Okay, now that rule is not allowed. It's deny and just hope that I got it right. And I monitored long enough. Right. This was before AI tooling and all that stuff. And uh, usually you got it wrong. Right? Usually there was an exception, but the tooling we have today can monitor that activity and, and create it. That's, that's pretty cool. You're probably sick of the word agent, but here's the problem. Your dev team is handing every new agent in your cloud way more permissions than it needs. And when one goes rogue, you've got four minutes before your data's gone. You need a default deny button that doesn't break every workload. That's Sunree's cloud permission firewall. Native IAM controls, not newfangled AI Nonsense. Default deny on every agent in human identity automatically. Learn more@securityweekly.com sunri that's S O N R A I and I think the

Speaker G: exceptions are interesting in that this is where my security background comes in. You know, if, if something has never pick your. Pick your poison. Created a pre signed URL before, you know, used a certificate to sign something, whatever it is, it's never done that before. That is maybe intentional. You're building a brand new workload and you need it to do that. Okay, well, uh, it's okay to put a little bit of friction in front of that and say somebody has to press a button in Slack to say approve it or something. Right? You can do that and it's acceptable. But it's also a really high fidelity signal to the soc to say, this workload just woke up after two years, it's never been used and it just did this. Do you want to wake that up or not? Uh, you probably don't actually, in many case you want to investigate why it did it. And so that's the way that we kind of do it. We put all these hooks into the cloud to know when these things that need the exceptions are there. We pass it to the team, they can approve it and it becomes normal. Or they can say, this is really suspicious. We need to hand this to the SOC to do some work on.

Speaker A: Right. It's that never before seen or haven't seen it in a really long time. Events, right, that are usually the ones that you can, uh, do some investigating with or want to do investigating with.

Speaker G: Yeah, uh, go ahead, go ahead.

Speaker E: I was just going to comment. I just, I just read that you named your company in Gaelic.

Speaker G: We did name the company in Gaelic. It's uh, by the way, super, super hard to find a domain name that has anything to do with identity or data. They're all taken.

Speaker A: They're all taken.

Speaker G: Yeah, they are all taken. And uh, we, we Stumbled upon this, uh, word sunrise, which in, uh, Irish Gaelic, specifically Irish Gaelic means data. So it's kind of neat.

Speaker D: And it's got AI in it.

Speaker G: And it has AI in it. Yes, exactly.

Speaker E: Oh my God, that's awesome, dude, congrats. That's really, really cool.

Speaker G: Now everybody's running out.

Speaker D: What else in Gaelic has got AI in it? And I can name my startup, uh,

Speaker E: in Gaelic, what other language AI in it?

Speaker A: Hey.

Speaker C: Little does he know that Larry just bought up all the Gaelic domain names.

Speaker D: But we were, since we were going off topic slightly. I'll, I'll just continue on. You're in, you're in Canada. What part?

Speaker G: So I am in New Brunswick, Canada, which is on the very east.

Speaker D: Home of the bowling ball.

Speaker G: There you go. Exactly.

Speaker D: Have you ever been to, uh, any of the Canadian security conferences? Do you, are there any that you recommend?

Speaker G: Yeah, Tor sec is a, is a decent one. Um, CCTX or sector. Sorry, yes. Maybe I'm dyslexic, I don't know, whatever.

Speaker D: Tor camp sector. We got it. Yeah.

Speaker G: And cctx. I was actually just, uh, I think it was two weeks ago we did the Toronto aws. We're very cloud, so broad scale security conferences aren't really always our thing. We prefer to have the cloud security conferences. They work better for us. Um, and I was at the Toronto AWS Summit, uh, last week and, or two weeks ago maybe. It was pretty good actually. It was decent.

Speaker A: So one of the things that uh, I think we're all concerned about, but especially um, you know, engineers working in these cloud environments and that's management of secrets. And there's obviously the wrong way, there's the wrong way, the right way and like every way in between. If that, if you've done that, I think that that probably makes sense to you. How does your product give us insights into that? Because that seems to be maybe one of the number one exposures. Right. Is how these apps in the cloud are dealing with secrets.

Speaker G: And again, it's different in each cloud, by the way, because the story is different in all three of them for sure. And then you have the fact that most of the cloud identities themselves should have done away with secrets and are using short lived credentials anyway, if you're using them properly. So you shouldn't have to use secrets, but you know, you always have to do it. So first of all, for the AWS secret side of this, if you were cutting real like AWS access keys, that's one of those privileged permissions. Right. So we're just Protecting the creation of them to begin with. Because you probably shouldn't be doing it. You should be using Tor Lib credentials. Then we're also protecting editing of the secret access policies. So it's one thing for the secret to be accessible to this workload. Too many people put it in where it's accessible to the whole account. So once the attacker's in, they can grab the secret versus the workload doing it. So we're protecting all of that on that side, which is also good. Um, again, and we can flip clouds here if you go to GCP as an example. I actually think we're probably one of the only companies. Datadog by the way is the other exception. Datadog and us are probably the only two that do access, um, to their cloud via third party without using secrets. Most of the vendors create a service account, cut a key on it and use it. Which is horrendous by the way. Yeah, because you can do it using short lived draft. So again we're protecting the secrets to make sure the secrets themselves are protected. Um, you know, we're actually making sure that, you know, you're not cutting long lived access keys and things of that nature for that. But what's most important, I was going to say before we just move on,

Speaker E: a 10 year key is a problem. Come on.

Speaker G: I like the 2099 ones, those are the good ones. Uh, the other thing that's super neat about what we do is those keys in those clouds, whether it's however they do it, you know, whether it's a long lived secret or it's even a short term one, they often have privileged permissions. And so what we do is make sure that if that key has never ever used any of those privileged permissions before, it's going to be blocked before it does and somebody's going to have to approve it. And the idea for this actually came from watching. You got to remember we have history, right? So we were building those Kim products before that were generating these least privileged policies which nobody ever applied. Right. You know what I mean? There'd be like 10,000, they wouldn't do it. And they would get red teamed and so the red team would obviously pop the git runner. Then they would use the git runner to use that to create a iam, uh, user, put an access key on it and then, then come back into the account that way. It was a super common problem. And they would go back and say, well, why didn't you catch the center? It's like we did, we gave you A least privileged policy a year ago that you never applied to Git Runner that said it shouldn't uh, create access keys. And so that was kind of the idea behind this thing was like but wait, if it's never done it before, why did we let it do it in the first place? And so by basically putting these global policies in that says no one cuts access keys unless we have already have them in the approved list removes all of that risk. So when the red team goes against this they just bang up against a wall. And um, there's been some great stuff in the last little while in aws like these intentionally vulnerable AWS accounts like Cloud Goat, there's Datadog just did a really new one with I think it's island something. Um and if you put these controls in it completely destroys attacking those. You can't get through them because something would have to approve you going through all the. The paths. So works quite well.

Speaker A: It's great. Yeah. A lot of security is about exceptions and we tend to make lots of exceptions but never audit our exceptions. And sounds like you're just making it so that the exceptions are never valid. Right.

Speaker G: Yeah. The um, there's this kind of neat thing on that exception thing too which we've seen a difference in the last six months. Maybe our customers would always put like their golden pipelines in the exception list and say like just let them do. If it's the build role putting in whatever, just let it do whatever it wants. We don't ever want that to be interrupted. And kind of in the pre. We'll call it the pre AI era, especially with these kind um, of interesting supply chain attacks now or bad NPM repo, whatever it is. You end up with these problems. They're now actually starting to gate those actually. They're saying look, that thing shouldn't have, you know, just launch permissions all the time when we're doing a deploy. It should have. It should have for the privilege that it needs but no more. Um and that's been a real change in the last six months. Before that people, almost everybody was just deploying them completely wide open.

Speaker A: So does that go for. For like general access to. Because the cloud basically has its own firewall.

Speaker C: Right.

Speaker A: And so when you deploy an app you, you state oftentimes programmatically like infrastructure as code, like what should this be exposed to? And you have lots of options as to how that can be configured. I'm assuming Sunray also kind of helps you with the keys aside like that general ah, like this shouldn't be exposed to the public Internet, it should only be exposed to this set of vpn. And it's not in vpn, right. It's some cloud, cloud based thing or cloudflare or whatever.

Speaker G: There's uh, two parts for us. So we're not, we're definitely not the network firewall. Right. That's not where we are. And so we're not necessarily looking at every one of those controls and stuff and saying, what did you do? You built the app, you do what you need to do with it, but in almost all of the clouds in order to change those things. So you know, as your example, change a security group rule in aws. You want to change those rules, that becomes the privileged permission. So generally speaking, there's only one or two things in the account that should ever be able to do that. And so those are blocked for everything else just by default by us. So you would never be able to expose it to the public. But then the cloud providers have created all these crazy bypasses for this stuff. So like SageMaker, which is this AWS service, allows you to, you know, train new LLMs and all kinds of cool stuff in it that you might want to do for analytics. One of its permissions, like the API call you can make, creates a pre signed URL and exposes the SageMaker notebook directly on the Internet, bypassing all of those rules you just talked about. Uh, however, it's very rare that anyone ever does that because they're using it internally and all these things. And so that becomes one of those privileged permissions. It's like if the very first time somebody goes to use a pre signed URL at a SageMaker, somebody should say, yeah, I intentionally wanted to make that public. That's something I wanted to do. And so we just put those blocks in. But, and I, you know, think about something like expensify, where you know they're grabbing all these receipts all the time, right. Those end up being public objects in an S3 bucket. It's how they do it. They all have, you know, weird whatever URLs to them, you know, that are supposed to be super secret claim. If they are, they're not. Doesn't matter. That's what they're supposed to be. And uh, those are all public object. You would, if you put our app on top of that, we would detect that that's normal behavior for that application. So that's okay.

Speaker A: Right.

Speaker G: But if you logged in and all of a sudden started to create these pre signed URLs, then no, uh, you got to go through another hoop to get there.

Speaker E: So you have multiple applications, behaviors mapped so that you can say this is normal, this is somebody doing something stupid, effectively.

Speaker G: We have this amazing compression of every identity by every permission, by every resource. Was it allowed? Was it disallowed? When was the last time it happened? And we have this thing that we keep. So we have this kind of summary and we use that to basically build all of these models out to know that, you know, Joshua absolutely changed security groups in EC2 and Paul absolutely URLs. Yeah, they found you. But you know what? Jeff never does any work. He just uses read only access and list stuff. But he doesn't actually do anything, you know, so we have that map there all the time.

Speaker D: Obviously, he's a longtime listener.

Speaker E: That's.

Speaker B: There you go.

Speaker A: Um, Jeff, there's a lot of noise coming from your mic for some reason. I don't know why it just changed.

Speaker D: I just moved it. I might have jostled the wire. Oh, okay. Are we good now?

Speaker A: I think we're good now. Yeah.

Speaker D: Okay.

Speaker A: So, Sandy, one thing that's interesting, uh, I think it's especially true when you're first developing and deploying a new cloud application, because the first time you do it, at least when I did it several years ago, my permissions were very relaxed because I needed it to work right. And, um, we've evolved in that. But I'm still, There's still a. Like, you're new to GCP and like, in order to get this working, like, oh, I had to relax the permissions. Like, can you identify like a new app that has more relaxed permissions because it doesn't have that history. But engineering was like, well, we got to create this and make it work and we'll always go back and secure it later, which, as we all know, never happens.

Speaker G: Never happens.

Speaker A: Can you help identify those scenarios? Because I feel like those happen.

Speaker G: So again, if we are in place. So if you've deployed sonrai, you've got 100 apps already running and you're going to deploy the 101st app, because you're doing that in each of these clouds. You're going to have you say gcp, you're going to have a test project in GCP that you're building it in or your sandbox, then you're going to move it to some QA environment and then production. What we do is that Sunray is a deny first scenario. So when you deploy that in that sandbox account, almost everything privileged you do is denied by Default. And so it's kind of annoying in that first time you're like, oh well, the very first time you create the network, you're going to have to get an approval. And so we do two things to alleviate that. One is most of our customers in that zone of development sandbox just allow self approval of the developers themselves. So the person hitting the rule is allowed to self approve it. The second thing we do is we group up permissions that are common together. So if you create a network, you're probably going to create subnets, you're probably going to create an Internet gateway, you're going to put some security groups rules in, you're going to put some firewall rules in. So we kind of group those all up together and you can choose to time box them. So you give it to the thing for an hour while it deploys or you give it to it forever, depending on the way the application works. And so during that first deployment, yeah, you got to hit approve a couple of times in slack or teams or wherever it comes. But it's instant. Like you just run the app, you run the terraform, it hits the wall, we detect that instantly, we send you a message that says you need to approve this. You hit approve, you run it again, you do it three times, you're done, the things deploy. What's nice about that is now you have the exact list you need when you promote it to staging and when you promote a production. And so.

Speaker A: Right, um, right.

Speaker G: But you take the friction because the developer fixes it themselves. They don't have to go ask the person that does iam permissions to go fix this stuff. Or in your case, they just don't give it star. They actually may give it star, but it doesn't actually have star because we put the global policies in to block that stuff.

Speaker A: Yeah. Uh, so you have a good. Yeah, global policies help people not deploy an app, uh, that has too many permissions, which is all too common.

Speaker G: Yeah, well, and things just never get those permissions in the first place. If they've, you know, you can deploy it with Star, but if it never uses bedrock, then it just never has those sensitive bedrock permissions in the first place because they're denied globally.

Speaker C: So.

Speaker D: Yeah. Ah, so if I can interject, um, uh, on the, on the show the last month or two, we've been having sort of this ongoing discussion about the fundamentals of security and we've had some lively discussion and debate about what that means. I'm curious as to uh, from a cloud perspective and A cloud security perspective, all the things that we've been talking about, I'm hearing glimpses of this. Sounds like it falls into the category of what some might consider a security fundamental. So what's your take on the fundamentals of security, especially as it applies to cloud security? And how are you tackling that? How are you making your system, to use an archaic term, idiot proof?

Speaker G: Yeah, um, so first of all, identity is kind of having a rebirth I guess of importance, uh, lately. So definitely, ah, it's always been a fundamental, um, and certainly one of the most important things, you know, in this exact moment in time. Vulnerabilities are having a moment, of course, but identity, uh, is still really important. So it is absolutely fundamental. The idiot proof part of this product was, and this is the challenge we gave ourselves two years ago when we were trying to figure out how to fix people or fix not having a thousand tickets to go fix. We said the users of the cloud must continue exactly as they did before. They do not need to change their behavior. And so by actually building this kind of, you want to call it default deny with whitelists, but using the history and analytics to figure out what is normal. So that gets applied by default. The users don't have to do anything. And on day one when you deploy this and you all of a sudden go from everything was open too wide and too open and we see that it's, the statistics are insane. Like 92% of the identities in any cloud, the humans, the workloads, the AI agents are over privileged in every cloud. And so when you turn this on,

Speaker D: is it uh, not the cloud equivalent of plug and play?

Speaker G: I mean we can say that, yeah. It's uh, in the reality is there's one step before plug and play and that you've got to build, you know, these rules and you've got to learn. And then you plug that in and when you plug it into the, these global policies, you're now in that state, but it doesn't impact anybody that's there, so it doesn't break the developers, you know, and things like that. And so they just keep doing what they were doing. And the worst case example is they uh, they have to hit approve and slack. It's really easy.

Speaker B: Cool.

Speaker C: So I remember back when we were working with cloud services, they were always introducing new functions, new features and um, we always had the conversation about is it secure enough?

Speaker G: Yeah, blah.

Speaker C: Um, so I'm thinking you've got to be constantly evolving to accommodate these. I mean, what's that? Uh, are you Just the snake eating its tail.

Speaker G: How do you do that again? We've got years in doing this. So every week there are new permissions in all these clouds. And so we go through those every week to make sure get lots of analytics that do it. And some AI, um, say is this privileged or not? And then the cloud providers change stuff, so stuff that wasn't privileged yesterday becomes privileged today because they add functionality to the API call. So you have to keep track of all that. And so from our customers, what happens is as soon as one of those things becomes privileged, we actually bootstrap that into their permissions and they're automatically protected for it. They don't have to keep track of it. Um, and the great thing about Default Deny is a brand new service shows up. It's never been used before, so it has no history. The very first person that hits the button, somebody's got to hit approve. And so a lot of our customers use this. Like in the early days of Bedrock they would want to try it in one or two accounts, but they wanted to globally deny Bedrock everywhere else. And so that's what they would.

Speaker A: What is Bedrock?

Speaker G: Sorry? In AWS world Bedrock is where you go build all of your AI agents. So in gcp you do it in Vertex and Azure's got some other service but every one of them has their set of AI services. Yeah.

Speaker C: So I'm thinking, you know, I'm flashing back to remember when we first messed with S3 buckets. Nobody realized they were world read.

Speaker G: Yeah.

Speaker C: Um, or, and you had to, you know, lock them down and that lovely global namespace not here to bash on them. I'm thinking it sounds like you got a, you're in a pretty good position to Prevent the next S3 bucket, um, adventure.

Speaker G: Yeah, there's been several examples of this as these new Ace I services rolled out like Bedrock where there were vulnerabilities in them by default. You know there were, uh, again there's lots of research on our website. People can go look at that if they want. But Bedrock had some pretty, uh, pretty big gaping holes there for a while and lots of container escapes and you could sneaker net data through DNS and all kinds of uh, interesting things with it. So

Speaker A: yeah, I mean I love it because I mean any organization has so many developers that are deploying stuff into the cloud infrastructure and you need something that is preventing them from shooting themselves in the foot. Even the like most well intentioned engineers. Because of the complexity and the ever changing landscape in this cloud infrastructure, it's, it's super easy to shoot yourself in the foot. So I feel like you need. I'm like you, as you're describing it, saying, like, I need this just because I want that stop gap. Right. I want some kind of backstop, uh, protection because it's too easy to make a mistake and create an exposure for your organization is.

Speaker G: There's a. There's a kind of neat other thing that we do, which I, I love. And it's one of those things that our customers love. Um, we also just detect stuff that gets left behind. So there's another, another cool stat if you've been in the cloud for five years. So if you've been there for five years, you've been building an AWS as your GCP50.50%. Half of all of the identities sitting there are unused in that.

Speaker B: I believe that.

Speaker G: Uh, yeah.

Speaker A: 100.

Speaker G: And the.

Speaker C: The.

Speaker G: And again, back to my history when we were trying to do this perfect, we would generate tickets and say, you go, need to go and remove this stuff. And none of the developers would delete it because they'd be like, but if I delete it, I don't know how to put it back.

Speaker A: It's gone.

Speaker G: Right? And it's gone. I don't know.

Speaker A: We all like to hoard. We all like to hoard stuff.

Speaker G: Hold on for a second.

Speaker A: Yeah, yeah, yeah.

Speaker G: So we did this kind of neat thing when we built this model and said, well, if anything is older than X, you pick X. 90 days, 180 days, 366 days, I don't care. You pick the time. If it's older than that, we put it in quarantine. And it's super simple. In the global policy, we basically just say, default, deny the thing, doesn't work anymore. But then we also put these hooks in to say, if it ever wakes up and does something, tell the team about it and ask them if they want to wake it up. And so you'll have this thing that sits there asleep for 368 days, wakes up and lists buckets or tries to access a certificate or something. And the team gets a note saying, this thing hasn't been used in two years and it just woke up today and did this. Do you want to wake it up? Yes or no? And you know, clearly you don't most times, but if you do, you say yes. It's the yearly report. We need it to wake up. And it goes and runs.

Speaker C: Yeah.

Speaker G: And we.

Speaker F: It's.

Speaker G: So what's so neat about it is you have customers with like 50 or 100,000 of these things in quarantine and the number that wake up in any given week is like five.

Speaker F: It's.

Speaker G: The risk reduction is massive and it's the simplest feature. It's so simple, but yet it's one of the most powerful things. And it's, uh. Anyway, the statistics on it are super neat.

Speaker A: I feel like there's a lot of like sci fi movie references to like things waking up after like thousands of years or something like that.

Speaker C: Right.

Speaker B: It almost feels like given sort of that exercise, like, hey, we're putting in quarantine because we don't want to lose it. That you're getting that message that it wakes up. Like, to me, my first reaction was, of course I want to. It woke up. I want to allow it to do something. Of course, in reality, it's probably. It's a very good possibility that something bad has happened.

Speaker G: Yeah, exactly.

Speaker B: So like, yeah, I think that's a. That's a little bit of a human nature thing that probably need to get past that particular set of rules.

Speaker C: Well, I'm wondering if. Okay, let's say we got this thing that wakes up over every 363 days. If you model that in such that if it wakes up after 200 days, you're saying whiskey Tango, Foxtrot.

Speaker G: Yeah, it's too early. There's something really wrong. Yeah, yeah. I mean that compression model is super

Speaker F: neat that we use.

Speaker G: You actually could gather a lot. We don't do that, by the way. We just do it. We kill the thing after whatever days and we wake it up when it wakes up. But it, uh, you could absolutely do some pretty neat analytics on it to say, well, yeah, this one, this one's early. Why is it doing it now? So.

Speaker A: Right.

Speaker G: It's a good idea, Lee. We're going to put that in. We'll. We'll.

Speaker A: Good job, Lee. Attribute it to you the lead, Neely.

Speaker E: Cool stuff. I. Sandra, I got to tell you, this is really like. I. You explained it very well. This makes sense. This is needed. I don't think anybody's going to argue it's needed where permissions and identities are just desperately bad right now. Okay. Like, it's bad.

Speaker C: Yeah.

Speaker E: So the ability to do one click full cloud. Done. Have a nice day. Thank you for playing. Bye. Is.

Speaker D: Is.

Speaker A: Chad, did you have something.

Speaker B: Go ahead.

Speaker D: Well, I'm noodling. I mean, a lot of my clients are in the cloud, but they're very much relying on third parties to ostensibly do a lot of the security fundamentals for them. I'm just trying to figure out, you know, how do you encourage companies to do this kind of thing when they think just because they're in AWS or GCP or Azure, that so much is being done for them automatically? Um, it's got to be, it's got to be built into your pitch somewhere along.

Speaker G: We do, we do. Again, we always do these kind of interesting assessments where, you know, people for. You can actually just go to our website, sign up for a free trial. What's nice is the main dashboard gives you the view of how bad things are, but it only has like five statistics on it. It's not super complicated. It's like, here's five bad things. You get this many zombies, this many overprivileged identities, this many services you don't use, this many third parties. And so you kind of see that very quickly. And then from there it kind of sells itself. It's like, oh, you want to fix it? There's a button, press the button, fix it. Um, but a lot of people will do that. They'll just plug it in for a, uh, thing and say, oh, this is.

Speaker D: Man, literally. I thought I was interview with your package. I want to see an online live demo of, you know, we'll pick it, we'll pick a victim.

Speaker G: That would be, we, uh, should definitely.

Speaker D: That would be fun.

Speaker C: Yeah.

Speaker A: Awesome.

Speaker D: I'm upselling, maybe.

Speaker E: I'm sorry,

Speaker A: Sandy, anything else you want to share with our audience?

Speaker G: Look, I. Again, if anybody's interested in our product, we would love to love, uh, to interact with you. You can reach us on our website, LinkedIn and all of those things. Sunraysecurity.com you can sign up for a free trial. We do all kinds of risk assessments and those things too. So again, we'd love to connect with anyone who's interested.

Speaker A: Awesome. Sandy, thanks so much for joining the show today.

Speaker G: Thank you.

Speaker A: With that, take a short break. Come back with the security news. Stay tuned. Zero Trust is clearly the future as threats get faster, quieter and harder to detect. But implementing it shouldn't disrupt the business. Threat Locker enforces default deny at execution in a way that remains enterprise ready, scalable and operationally clean. Unknown software is stopped cold. Trusted apps stay contained and drift is locked down across the environment. It's Zero Trust that works in real enterprises and prepares you for the threats ahead. See why CISOs are adopting it@securityweekly.com threatlocker and we are back with the security news. We don't have Josh Marpet yet. I think he's still on. On break, but we'll, we'll bring him back momentarily.

Speaker B: That's why we assign all the work to him.

Speaker A: That's right. That's what happens when you don't show up to a meeting. You get all the work,

Speaker C: all the action items go to the missing person because they don't object.

Speaker A: This is true. Where do we want to start tonight? Is there anything that you guys really caught your eye before we kind of warm up, um, into.

Speaker D: What caught my eye is you're not Paul, you're. I use arch. By the way, did you happen to watch last week's or listen. Last week's segment is.

Speaker A: I listened to some of last week. Did you not hear?

Speaker D: We had, we had a special.

Speaker B: Listened all the way to the end for just for you.

Speaker C: Yeah, we had, we had just for Paul. Segments. What the hell.

Speaker A: I do listen when. When I, I just haven't completed the episode yet. So.

Speaker C: Okay, so I'll go back.

Speaker A: I'll go back and listen.

Speaker D: Spoiler alert.

Speaker A: Yeah.

Speaker C: How many of us talked about for bleed?

Speaker A: I mean, if we do we talk about it last week?

Speaker C: No, no, we did.

Speaker B: Um, so I think that's where we start.

Speaker A: Yeah. So there's. We could literally devote the rest of the time, most likely to this, but I will try and summarize the most important things. Um, so here, bear with me for a moment and then, uh, we'll, we'll discuss. So threat actor left all their tools and data exposed to the Internet. Uh, someone found it and grabbed the tool, set the tools and the data, uh, that they were collecting via, uh, this campaign. Um, there are many ttps in here, but essentially the threat actors were scanning, identifying, exploiting and capturing data, especially credentials, uh, primarily with the. Through Fortinet firewalls. Although there was some evidence of Sophos, um, and other technologies, Microsoft SQL Server and other things in that campaign as well. But it was very, it was interesting. Kind of mirrored a tool, a tool set that I did a proof of concept on that scans the Internet tries or a network segment tries to figure out what the device is, tries, uh, to log in, you know, based on what it fingerprinted. Uh, and the attackers had a, I thought a very good design, uh, to their malicious activities in, uh, the way that it was implemented. And we're able to map all of that because they leaked all their tooling and a bunch of, uh, folks in different companies analyzed, uh, that data. One of the interesting things was they were able to collect SHA256 hashes. They were able to rent I think it was 40 something GPU cluster to crack those hashes, which was kind of interesting. Um, inside their tradecraft one of the things that you could have easily glossed over is they had technology to detect honeypots. Um, so in their system of scanning, if you were able to log in successfully like three times in a row, they were like, well that's probably a honeypot. Because most production systems we probably wouldn't be able to guess the first three passwords and have them be uh, accepted. I think that was the extent of their checking uh, for that. They were also filtering a lot of the device fingerprints and credentials. So they went through multiple passes of going, is that a Fortinet device? Is it really a Fortinet, uh, device? And then if so, you know, go do the next stage. Um, once they compromised a Fortinet device, they were primarily living off the land. This is an area I spent some time investigating because I'm like, if they did stuff or deployed malware to a Fortinet device, I want to be able to go detect it. And really what I saw was them, um, just running the, I forget the exact command, but it's the command that allows you on a Fortinet device to sniff packets. And so they didn't need extra malware for that. They used built in Fortinet functionality to sniff traffic. And they weren't just sniffing for more Fortinet logins, they were sniffing for all kinds of credentials and building out a database. Um, this is where it gets like I had to spend a lot of time and to really fully understand this. So this is important. So I talked about SHA256 Ah, hashes. Um, if you're running Forta OS versions prior to 7.2.11. 7.4.8 and 7.6.1. So before those versions you are storing passwords that are either SHA 256 hashed or some other hashing algorithm. Both of which by the way are, can uh, succumb to being cracked, especially the SHA256 as evidenced by the GPU cluster. So versions prior to the ones that I listed, you're basically vulnerable, right? Uh, to this hash crack vulnerable. But it's more of like a misconfiguration. You're storing the passwords in a format that anyone with a credit card can go to a hosting provider and with 40 GPUs and crack it. So if you're running the newer versions of Fortinet, I won't keep saying the version numbers, but after that version number or Later Fortinet switched it so that the passwords are being hashed with PBKDF2, which is a much just for the sake of simplicity, much better hashing algorithm, more resilient to password cracking. Um, but there's a caveat there. So you run the older version, you're hashing your password sha256. Once you apply the update that gets you the pbk df2 hashing your password like the value stays the same. So you still log in with the same credential, but in the surface. So if you do a show running config the equivalent on for OS it shows the PVK DF2 hash. And uh, so your password has been basically rehashed uh, with a new hashing value.

Speaker B: However,

Speaker A: it stores the SHA256/in the config somewhere in that storage post upgrade is only in the show full a uh, configuration backup. So you have to do like a full configuration backup. Like you have to go either run the commands, go in the interface, go, I want a full configuration backup. And that's where your SHA256 hashes live. And it does that because I was questioning this, I'm like, why does it do that? Well, let's say you upgrade from 7 to 7 11, now you get the new password hashing algorithm. But something else broke and I need to revert to 7 due to 10. Well if I don't store that old hash, I can't revert, uh, my password would be invalid. So it does that so that you can revert and it still stores the previous hash so administrators don't get locked out. I understand the problem. Not saying I agree with how Fortinet necessarily went through the process of trying to fix that. Um, so that presents a problem in that once you've done the upgrade from version that stored passwords insecurely to version the passwords are stored securely, you've now got new password hashes, old ones still stored there as an admin I have to log in in order to wipe out that old password hash. So it's only on first successful login that it wipes out that older SHA256 hash. And it does that not uh, just for one admin, right. But for all of the admin accounts that you have on there. Um, so that's the kind of weird thing like if you're vulnerability scanning and you're just doing it based on version, there's this like weird nuance where you could be still be storing an old password hash, right? So that's basically in a nutshell, like

Speaker C: change all your passwords because that would also force it to be written with the new hash.

Speaker F: Right?

Speaker A: Yeah. Uh, but in this case you don't have to actually change your, I mean you should to your point, lead change your password because someone change it to

Speaker C: the same thing again and get there. Right.

Speaker A: But you should change it because it could be that your password was leaked.

Speaker B: Right,

Speaker A: there's that. So definitely change all your passwords. Enable multi factor authentication. Um, you know, obviously you can still log in through the web interface, but for SSH key based authentication, obviously way better than password based authentication. That certainly you can do that on Fortinet firewalls. Um, would be a good thing to do. But if your admin web interface is exposed, you know the SSH key doesn't mitigate that thing. So it's best to change all your passwords, rebuild all your devices. Uh, if there is no software update available for your Fortinet device because it's end of life, you should throw it in the trash and go buy a new one. Um, so there's that.

Speaker C: So I actually there was a couple things about this that caught my eye. One was the scope. They identified, what was it? 74,000 Fortinet devices in 21,000 domains in 194 countries. This is not a small attack.

Speaker A: Yeah, essentially they use MassCan to scan the entire Internet for Fortinet and did it in a way like it's, it's kind of frightening actually they did it in like the same way that I built my proof of concept. Um, that would do mass scanning. Mine was of your internal network. Find all the live IP addresses, then go run another tool, identify what kind of device it is, enumerate all of the protocols available on that device, do some more investigative work that based on the protocol, what it responded. Is it a Fortinet device or is it a Cisco device? What is it then based on that? What credentials do I have that I want to send to it? Right. I mean that's the like fundamentals for, for, for doing this type of work. I was doing it so defenders could have a tool that did this for them. But the attackers basically built the same tool that I kind of envisioned in my proof of concept, which is, it's kind of frightening. Right. I was building it with my vision of defenders running this tool to enumerate all the issues in their environment. Like do I have Fortinet devices with a default and or weak credential. Well, I need a tool to go Help me with that. Because volume scanners, traditionally, as Jeff can tell you. Right. Haven't been great at that. Um, and. But the attackers built like the same. Like the workflow was. I'm like, the workflow is identical to the proof of concept I, I built, uh, for my engineering team. I'm not saying we, we didn't necessarily implement my crappy proof of concept, but it was just like a. If we were to do this, like, here's, here's something that like stimulate your brains. Right. Wasn't production ready or anything. Was proof of concept. But the workflow matched almost identical to what the attackers built. That's what freaked me out about this one. I'm like, that's kind of freaky.

Speaker C: So did, did you have a chance to look at the Hudson Rock lookup tool?

Speaker A: Yeah, uh, there were many lookup tools and I. All it's doing, I believe, is just matching your IP address to all data leak.

Speaker C: Yeah, I mean there's the domains and it's got the compromise credentials and both the, the, the. The IP URL to the little login or whatever the heck, as well as the account that was compromised. Not necessarily all the details like obscured@oracle.com. um, but, uh, I just thought it was interesting at the time. I only saw. It's been a couple days, the, the one lookup tool popped out. And I thought, okay, that's kind of neat because it's like, have I been pwned? If you don't. If you have somewhere to look.

Speaker A: Right, right.

Speaker C: But I was wondering how good it was because you didn't.

Speaker A: You've dubbed it have a lot deeper

Speaker C: in this than I have. Yeah.

Speaker A: Uh, basically I had to for my, My day job. Right. Because we want to give people coverage for this.

Speaker C: Of course.

Speaker A: But, you know, I can't find that exact. The exact command the attackers were running in sniff packets. There is a way to pull that from your logs, by the way. There's a lot of great resources out there that, uh, if you turn on like, uh, auditing on your Fortinet firewalls, which I don't believe is on by default, it'll actually audit the commands that were run, um, and write those to a log so you can tell, uh, have an indicator in a log file that someone issued the. I wish I could find the command. I didn't put it in my show notes. Uh, but you can tell when people run the command, uh, to sniff Pat, use your Fortinet firewall as a packet sniffer. I wish it was a way to Turn that off.

Speaker C: Right.

Speaker A: Like in Linux and containers, you can kind of cherry pick what functionality and what binaries are in that Linux container. So any suid root binaries, you can just remove them from the container and reduce your attack surface. You mean on um, a Fortinet firewall, I can't go in and like pluck the binary that gives attackers the packet sniffer? I mean because if I could I would, I would just be like, I would just tell people, just remove that.

Speaker D: Historically, lots of problems with. You know we used to call network devices routers. Uh.

Speaker A: Right.

Speaker D: And switches. Now they're all in one devices. But promiscuous logging for troubleshooting and network detection. Network troubleshooting really? That was a problem a long time ago and it sounds like Fortinet was trying to address that in turning some of this stuff off. Um, of course in theory in the old days you wouldn't start with the logging turned on, you would just turn it on and forget to turn it off.

Speaker A: Uh, right.

Speaker D: But I was, I was also curious, I mean a very thorough discussion of the issue. But uh, I'm, I'm a little bit fuzzy on uh, what if you ran a scanner, what the scanner isn't going to pick up and what you have to find, uh, you know, sort of manually.

Speaker C: You mean, you mean as in you're, you're threat hunting or as in you're looking.

Speaker D: Well, I mean for looking for whether your devices are vulnerable to this fortibly detect.

Speaker A: Yeah. So that's the. I scan a Fortinet device and it's running a version that air quotes is not vulnerable. Right. It's running a newer version that is storing passwords more securely. Right. So that's determined by version number, how it stores the passwords. Right. So version 7.211 is configured is automatically your passwords are stored using a more Secure hashing algorithm. 7.2.10 in previous was using an insecure password hashing algorithm. The caveat is if I'm running the newer version and my password is still stored in the configuration backup as a SHA 256/the insecure one until such time I log in for the first time post upgrade. Then it goes oh, Paul was able to log in. Cool, I'll just wipe out the old hash. And the reason for that is I upgraded to the new version and something went wrong when I reverted.

Speaker D: You got to be able to still

Speaker A: wanted to preserve those old hashes so I could log in, I wouldn't be locked out.

Speaker D: Right?

Speaker C: Yeah.

Speaker D: Right.

Speaker C: So one of the interesting things I read in the Hudson uh, Rock article was that the way they found these was for sweeping the Internet for exposed Fortinet management interfaces. How long have we been talking about don't expose your damn management interface to the freaking Internet.

Speaker B: But I wanted to, Lee. I wanted to.

Speaker D: Oh, it'd be easier default on. And if I'm at home, I want to be able to telnet into my device.

Speaker C: Well, yeah, well yeah, because you know, telnet is really robust and lightweight.

Speaker A: I mean it certainly helps though. But this attack was sophisticated enough.

Speaker B: Mhm.

Speaker A: Conceivably it could have gotten my credentials.

Speaker B: Uh-huh.

Speaker A: Without that.

Speaker C: Yeah.

Speaker A: And here's a couple of different ways that this particular campaign did that late. And I don't get me wrong, I don't think you should expose your firewall management interface to the Internet. However, the cautionary tale here is even if you did your due diligence and you're like, I'm not exposing that stuff to the Internet. If one of your admins, for example, got malware that was an info stealer, they would collect your credentials to your Fortinet device also. However, they could get into a Fortinet device, whether it was a remote code execution or through some other credential abuse, uh, of some kind or, you know, they had your credentials or guessed your credentials, whatever, they put a password sniffer on it so that if you logged into another Fortinet device, they got the credentials for that one. And that's how they had so many credentials for so many Fortinet devices. Was, I don't want to say it was like a worm, but it was like an attack that built. It was collecting credentials and just kept using those credentials to collect more credentials. Even outside of attacking Fortinet firewalls, you got an info stealer on your Windows machine and it's going to, it's going to, you know, collect credentials there, which is, I mean it's smart. Right. On, uh, an attack from an attacker standpoint, super smart.

Speaker C: I mean they had what, 2.1 billion credentials they were trying against Ms. SQL and MHM. 1.6 billion credentials they were trying against Fortigate targets. 320,000 attempted targets.

Speaker B: Um,

Speaker C: they got into like a third of them. If they got into like 75, you know, it's okay, about a quarter of them. Still crazy.

Speaker A: The other thing too, and this is the link that I put in there because it was super interesting, it was Kevin, uh, Beaumont's follow up article, um, on Affordably, which is I think even better than the original One just kind of goes over a lot of the. Not to. I don't want to downplay Kevin's writing. Kevin was early on in writing about this, so. But that's basically all stuff I covered in the newer one. He was like some uh, of this stuff doesn't make sense. And one of the things that doesn't make sense is one of the like most used or prevalent credentials in the data set was a credential of like admin3 in some password. I forget what it was. Like admin3 doesn't exist as a user account on a default like fortinet device. Your default username is admin. Um, your default password is going to vary. I think newer ones might actually make you set a password, uh, when you log in. But the username is still admin. So we're like wait, what is admin3? Well that's a backdoor account that threat actors added after they compromised a bunch of Fortinet devices through remote code execution vulnerability or any of the number of RC's for Fortinet and put a back door on it. And so the attackers somehow discovered that credential or they were the attackers that put it there and just started using that and found another like backdoor into the Fortinet devices which just crazy. Crazy.

Speaker C: Yeah, just giving, just giving the article you linked. Yeah, he. This is actually. Yeah, this is. Somebody had time to take a breath and write.

Speaker A: Mhm.

Speaker C: Like I said, no, no offense on the first article. I mean you got to get the information out there, right? And the um, you know, the Hudson Rocks Post quoted a lot of the numbers and information that he came out of that he wrote in that first article. So I said absolutely no, no beer truck running over Kevin on this one.

Speaker A: Um, but uh, yeah, there's actually more detail. There's even more details. I didn't cover that. Kevin. Oh yeah, in here from uh, you know, helping, helping customers. He also links to the cloud, sex cloud. S E K had uh, a great article on it as well, uh, that I read. That's where I picked up the little tidbit about their honey pot identification.

Speaker F: Uh,

Speaker A: So this is a pretty crazy campaign. Uh, again, a lot of it's just like password stuff. It's credential abuse, most of it. I mean some cracking in there too. Uh, Kevin seems to really make a point that, you know, uh. Oh, he says it right here. Um, this is a side impact of the drunk gen AI stupidity gripping organizations worldwide getting a 36 Nvidia GPU cluster a few years ago. Would have required talking to providers, getting racks and lots of setup. Now you get a Visa card, you rent by the hour and log in a few minutes later. All your irreversible encrypted passwords aren't looking so hot in the age of on demand. Compute at scale where attackers who put things in open web directories can brute force large volumes of passwords at scale does like he says, something indicates some things in there that doesn't explicitly call out. What he's saying is these threat actors were not sophisticated enough or their OPSEC wasn't uh, up to par enough that they left their tradecraft open to the Internet. Which speaks to their level of sophistication over their attack. Was actually pretty well designed if you read through all the. The way they constructed this attack.

Speaker C: Right.

Speaker A: He's also saying like today you can just go rent this stuff and put it on a credit card. Now, I'm not sure exactly how he we could calls it out, Paul.

Speaker C: He says degenerative AI craze has lowered the bar so far that Mr. Bean can wreck. Mr. Bean can crack passwords quickly using his mom's credit card. I mean that's pretty much laying it right on the line that this was not sophisticated.

Speaker D: Right.

Speaker C: Um, and it's actually something we as cybersecurity professionals will be paying attention to is that you know what adversary capabilities are out there for thanks thanks to our AI work that's developed.

Speaker A: But. And he's also saying, and this is the reason why I linked to this one article on affordably because I think it has some of the best insights even above and beyond this campaign. In Kevin's section that he levels some of my learnings from fortibleed, he says organizations are constantly worrying about generative AI threats. But this incident has tens of thousands of organizations without even multi factor authentication set up on boxes providing VPNs. Still, there's a massive gap between what many cybersecurity people are talking about frontier AI and what's happening at the organizations they manage. And what, what Kevin's saying here is I don't want to put words in his mouth, but that we're our eyes not on the ball. We're focused on this geni threat and mythos and all this stuff. Meanwhile, you still have infrastructure deployed that has remotely exploitable vulnerabilities, weak password hashes and lack of, um, multi factor authentication. One could turn to. One could turn to many standards such as pci. It will probably tell you, Jeff, right that those three things are things you should Pay attention to M. Did somebody say pci?

Speaker E: Oh, dear God, the pci.

Speaker A: Exposing your management interfaces to the Internet. End of life or vulnerabilities. You know any one of those? No. Multi factor. You're using weak password hashes. I mean, how many standards talk about which password hashes you should? And also how much do we consider that SHA256 was not as secure as we thought it was? Yes, we knew that. But I think this shined a spotlight on. Yes. Not only is it, uh, secure until it wasn't. Right? All you need is a credit card and 40 GPUs and it's effectively meaningless.

Speaker C: Yeah, I had a conversation. I was in the conversation the other day and I had the wherewithal to ask about password strength and I had a wherewithal to say it's 2026. Why are we talking about reusable passwords and not multi factor or other stronger.

Speaker D: Multi factor is a pain in the ass. Uh, and I finally figured out, since I'm onboarding to a new company, I finally figured out why they call it Multi Factor Authentication and not Two Factor Authentication. Because I've had to set it up like 42 times in the last few years.

Speaker B: Multiple times.

Speaker A: Right.

Speaker D: Holy. I gotta set up Multi Factor Authentication to set up the Multi Factor Authentication and it's, it's.

Speaker C: I, I need to give Kevin a call. 42 is the. Too, too low a number. Um, the. No, seriously.

Speaker A: Um, the product is six times seven.

Speaker C: Okay, Lee, yeah, I get it. Um, but, uh, you know, and I don't mean to make light of, of Jeff's point because, yeah, it is a pain in the ass, but it's like in the corporate environment we should really be talking about that. There are ways to make it easier, but if you don't send people there,

Speaker D: just, there's ways to make it easier and Soapbox moment. The, the fact that everything's tied to this, whether it's an SMS or whether it's a, an authentication app. You lose this, you're screwed. Or if you're in a certain small room in a house that you don't usually take this into because it's plugged in, charging, but you're trying to be productive, you can't be productive.

Speaker B: But so what you're saying, Jeff, is that you work on the crapper?

Speaker D: Something like that.

Speaker C: Yeah. Yeah.

Speaker D: Just trying to be efficient, you know,

Speaker A: that, that aside though, you know, Jeff, you've been this year, I think, harping on the fundamentals. I have, and I think this is a, a clear Case where we've lost focus of the fundamentals. We've lost focus or we never had the. The right thing stand is what's fundamental the first place? Yeah. Are. Are we, like the question is, are we using secure password hashing algorithms? Well, like, uh, that would have really helped you in this case, affordably. Right. If you actually paid attention to that. And I think part of the problem. And Josh, this is something you and I have talked about. What, what are some great tools and methods for discovering how your passwords are being hashed, identifying those and helping you fix them. I think that's, I think that's kind of a weak point.

Speaker D: Maybe not the best example. Paul, and I'll say it because of this.

Speaker C: Um.

Speaker D: Uh, while I agree with you at one level, you know what, what, why aren't we talking about the ways to protect against your stored hashes being compromised? Because if the, you know, whether it's weak or not is immaterial if the bad guy can't get to it. And how many different ways are there for a bad guy to gain access? I mean, in the old, in the good old days, it was a world readable file that anybody could look at.

Speaker C: Right?

Speaker D: Um, yeah, we got over that mostly.

Speaker C: But

Speaker D: there's, there's still too many ways to gain access to the hashes, which make this a really interesting conversation. And you know, let's, uh, let's get stronger hashes. But you know, why aren't we saying don't uh, put the hashes somewhere that. Where bad guys can get to them? And what fundamental was being missed that's enabling that? Yeah, I think we should at least consider that as part of the conversation.

Speaker A: Yeah, I mean, I think, you know, while in this case you can't necessarily patch your way out of it, we can't lose sight of the fact that keeping up to date with these firmware updates is, is huge.

Speaker C: Right.

Speaker D: Well, I mean the thing that doing

Speaker A: that in incremental steps. Because if I have already, if I, and this is a great, um, example, if I had last year or the year before upgraded all my fortinets to these versions, gone through the pain of having every admin log in making sure the old hash wasn't being stored. Now I'm in great shape. If I haven't done that. Now I'm playing catch up.

Speaker C: Right.

Speaker A: And that's. You're just. You've accumulated too much technical debt. You need to chip away at your technical debt as you go and not let it build up until you're like, oh, uh, crap. All 5,000 of my Fortinet firewalls need an update because we're storing password hashes insecurely now. Now you've got huge problems.

Speaker D: I was going to say something and now I forgot it. Dag NAB it.

Speaker C: Yeah, two questions for you guys. Do you remember the old C2 secure script? At least one of us and two

Speaker A: never heard of it.

Speaker C: In the HPUX universe, there was a time where when you moved the hashes out of etc password, it actually created a separate security file for each user in a very tightly secured directory tree. Um, so it was like you had to walk a tree to find them all. It was a pain in the ass. And I was wondering, would that be have been an improvement instead of all of them in one? And I'm thinking, well, what would it take an extra 30 seconds for the hackers to find them?

Speaker D: I mean, that's obscurity through obscurity. Uh, while there is some legitimacy to adding steps and complexity and layers, that one could easily have been scripted and

Speaker C: you know, uh, but it, and in HP's defense, they actually had other metadata in each file relative to the user's account. And some commissions and some aging stuff. Uh, they were, they were adding some, you know, password aging, rotation and some other things into this when there wasn't a standard yet. So, you know, let's not throw HP under the bus. But you're right, Jeff, I agree with you. I just think, yeah, once somebody figured it out.

Speaker D: Well, and you helped me to remember what I was going to say. I mean, you know, the, the for bleed example with the uh, the hash being stored, you know, just in case you have to back out and, and revert back to the older version. I mean that's a, that's not a weakness as much as that's a, that's a design decision. You know, that that's a risk decision that's been made. And somebody, you know, they may not have known this was possible, but in theory they would have considered this as a possibility. What if somebody gets to the older hash? But you know that. And that's a somewhat legitimate risk decision to make. You know what, you know, what would our conversation be if we were finding out, oh, fortinet, if you change your password, uh, and you screw it up somehow, you're screwed because they don't have a way to back up or revert back to the older version.

Speaker A: I would dare say it'd be a bigger problem, but I think we do this a lot. We're like, well, the barrier to entry is high. In other words, in order to crack these passwords, you need a 40 GPU cluster. So that's, that's a barrier.

Speaker D: Right.

Speaker A: But as technology evolves, it's less and less of a barrier. And ah, we're not even talking about quantum encryption. You know, a lot of us are worried about quantum safe algorithms. This had nothing to do with that. Right? It was just. Well, I just need more GPUs accessible.

Speaker C: Huh.

Speaker A: Not a problem.

Speaker D: Does hashing become a problem with quantum computing? I don't know the answer.

Speaker A: Oh, that, yeah, that's a good question.

Speaker D: I'm not sure that because hashing is not. Hashing is not encryption.

Speaker E: Hashing is not encryption, but it's a mathematical transmutation of the characters that are in the clear text.

Speaker A: Um, and can of how. I don't.

Speaker D: We used to call that algorithm. But I mean I'm sure there's people

Speaker A: that know the answer to this.

Speaker D: I just don't happen to know the answer to it.

Speaker E: Wait, sorry. Ask the question again. I need to hear it. I'm sorry.

Speaker D: You know the, the quantum is making asymmetric public key cryptography vulnerable, right? Because it's a math formula. Whereas symmetric encryption, which is just really, really big ass keys that you're still brute forcing. Now hashing is a function, is an algorithm. And all the password cracking for millennia have been essentially brute forcing or guessing. Does quantum lend itself?

Speaker E: Yes,

Speaker D: efficiently.

Speaker E: Sort of. Bear with me. You know what the ultimate answer to hashing is? Is a rainbow table.

Speaker B: Right?

Speaker G: Yep.

Speaker C: Huh.

Speaker E: M. So a quantum computer of sufficient power and size can create a rainbow table like that.

Speaker D: And just for giggles, define a rainbow tape. Good, good ride.

Speaker E: Ah. Since a rainbow table. Sorry, A hash. Give it a lookup. Yes, effectively, um, a hash function given the same clear text always produces the same ciphertext, right?

Speaker B: Uh-huh.

Speaker D: Hash text uniquely, uh, unique.

Speaker E: The same, given the same is the same.

Speaker D: But the idea is no two different inputs produce the same output. That would be a collision.

Speaker E: We're on the same page. I'm stating just something for the clarity here. Okay, so the same cleartext produces the same ciphertext, right?

Speaker C: Yep.

Speaker E: Yep. With a hashing function, the concept of a quantum computer is that uh, a classic binary computer does one thing at a, ah, time. A quantum computer does all of them at the same time.

Speaker C: Right.

Speaker E: So a rainbow table is effectively calculating a hash algorithm or hash system. Um, a hash function. Thank you. And, and pre compute. Uh, the rainbow table is pre computing all of those hash functions. Yeah, Every single letter, double letter, triple Letter, quad, letter, five, five penta letter.

Speaker D: It's doing the brute forcing ahead of time and creating this big massive lookup table, which means you don't have to do the math. Once you have a hash, you just look it up.

Speaker E: Right.

Speaker A: I will defer this to security. Cryptography. Whatever. I'd love to hear their, their take on it because they're classically trained, uh, cryptographers that have an awesome show. Uh, what AI told me is that, uh, quantum computing doesn't make like SHA 256 as an example, instantly breakable. It effectively halves their classical security level to 128 bit.

Speaker D: You were playing Paul.

Speaker A: Yeah, Jeff. Jeff is well played, Jeff. Very, very recognized.

Speaker F: Not a cryptographer we recognize. And you're a Fort.

Speaker A: It's different.

Speaker F: We recognize your authority in Fort Kick Ass. Not to worry, Jeff.

Speaker B: Yes. Huh. Yeah. And classically trained, I might add.

Speaker D: Classically trained meaning I know how to break the puzzles in the newspaper.

Speaker C: Um, not that the nuns hit you with a ruler on your hand.

Speaker A: And then something about Grover's algorithm. Anyway, what about Ernie? I'll defer that to the. To the. I thought it was Shor's algorithm in that. But it, it doesn't. This context. Right? It doesn't matter because the. You can go rent a 40 GPU cluster.

Speaker E: Vast AI baby.

Speaker A: And that's, you know, like threat actors just, they care about results and they're like, wait, I just need to have a credit card in 40 GPUs and I can go crack these.

Speaker D: But to summarize, what I'm trying to add to this is, if hashes are, uh, susceptible to quantum based attacks, why aren't we running around like the sky is fall, falling, trying to come up with quantum resistant hashing algorithms?

Speaker A: I don't think we're running. So if Ford is a great example, there were. They did make an update to be like, yeah, you know what? We probably shouldn't be storing them in SHA256. We should store it in something more secure. BBK DF2. Um, and they made that update.

Speaker D: But I'm sorry, I kind of got distracted because I. Go ahead.

Speaker F: I think you're touching on something. Kind of. The last probably five minutes of discussion are revolving around a couple of different concepts. Um, but there's something in the middle of that. So the first part is we're having troubles with fundamentals and basics, and we've been a thing forever. Um, it's like a sandwich. Um, and then on the other end, we're also focusing on the really, really like bright shiny objects of what is new. Um, but we're not. So as defenders we are focusing on the new thing and we're kind of getting wrapped up in that and forgetting the fundamentals. The good part is it sounds like some of the threat actors are too. The problem is there's a difference in the amount of effort necessary to do both of our jobs. And that is I think the thing that's really going to hurt us the most moving forward. It's, it's at a, uh, at a magnification it's even more easy for them to be more dangerous than it is for us to be more defensive.

Speaker E: Wait, say that again.

Speaker F: It's. Long story short. It is. Yeah, I'm just going to repeat the whole thing.

Speaker A: Uh, no, um, no, just the last part. The last part was good, Dave. I mean it was all good. But the last part was the point

Speaker F: you wanted to drive the delta here of how easy it is to defend and how easy it is to be an attacker. It feels like it's getting larger because as defenders we've got more things to pay attention to, we're getting excited about more things and we're leaving the fundamentals behind even more so it seems like when theoretically we um, could be doing them better, um, with AI.

Speaker E: I can show you the proof on that if you want. I can show you the proof on that. I just threw a link in chat. I actually just. We did a research report about a month ago, uh, at the non profit that I, that I work at, that I volunteer at and for software supply chain security. So similar to what you're talking about, Dave.

Speaker C: Right.

Speaker E: And yeah, it's incredibly bad. It used to be about 11 days, uh, for a vulnerability to be created as an exploit and to get out there and start being exploited. Right now it's about between 11 and 30 minutes at most. So yeah, it's a lot harder for the defenders rather than the attackers. So value chain risk.

Speaker A: Think about what Dave is saying because Dave, what you said was extremely awesome.

Speaker E: He normally is.

Speaker A: This is the. But this is the problem. Dave hit um, on the problem that we have today. And I think it's one of the biggest problems we have today is that we tend to chase the shiny new things and constantly refocus on the new stuff, the new attacks, whatever's new and we lose focus on the fundamentals. However, and I'll extend what Dave said, if we focus on the fundamentals and do those really, really well and don't lose focus on the shiny new things but, uh, keep doing those fundamental things really well when the shiny new thing comes out, because you've done those fundamentals really well, that shiny new thing is not going to be as much of a vulnerability, a threat, or an exposure.

Speaker D: I wholeheartedly agree. And then we all lose our jobs and nobody watches our show. Yeah.

Speaker A: Hey, if we just sat here and said, you need to update your firmware every. Which, I mean, we do, but if that's the only patch. Patch. And when you patch, you get new, better hashing algorithms. When you, you know, it's the whole thing. Had you just tried. And true.

Speaker C: Right.

Speaker A: Had you stuck to the plan and not deviated from that, to go focus on the, uh, oh, my God, there's a new thing. You would be able to defend those new things you would build. We need to focus on building resiliency. And resiliency is not necessarily going to chase the latest and greatest thing and combat the latest threat. Resiliency is how do I do things really well so that the next latest threat doesn't matter?

Speaker B: Or maybe doesn't.

Speaker A: It still matters m. Much.

Speaker B: Uh, yeah, it doesn't matter as much.

Speaker A: Or we have a lot more time reducing the impact. You're right.

Speaker B: Or we have a lot more time to detect. Yeah.

Speaker F: I meet a lot of people at conferences. They're absolutely panicked that they're not using AI to the optimal, uh, within their defensive posture.

Speaker E: Um, but unless you're using it smart, it doesn't matter.

Speaker F: Right. To be fair, there's a whole bunch of stuff that they're probably overlooking that are fundamental, that just like, close the back doors, shut the windows, whatever it is you have to do. Do those first and you'll get potentially more bang for your buck.

Speaker A: Yeah, I mean, I guess, unless you're running Cisco Catalyst, sdwan.

Speaker B: Uh, good. Nice.

Speaker A: Yeah, like, I. Look, I don't want to pick. I don't pick on Cisco.

Speaker B: No, you do.

Speaker A: I'm not sure of the lineage or history behind.

Speaker D: Why should today be any different?

Speaker A: Yeah. But I'm not sure about the history or lineage of the SD WAN or SD WAN manager products, uh, that they have. They acquire what it probably acquired. Right. But it would be a safe bet, what I can say. And so I ran this analysis through my. My vulnerability analysis tool. I ran this query based on some of the articles that I was reading, uh, just to validate what they were saying, because a lot of people generate articles using AI. Go figure. And it hallucinates. Go figure. Uh, but in. So, uh, I. Using my tool, which I used AI to create. But uh, in less than a year there have been seven vulnerabilities in the Cisco Catalyst SDWAN family of products. Seven vulnerabilities added to the SISAKEV tells me all of them are exploited in the wild. All seven? Uh, I couldn't really confirm 100%, but based on what I've read, I'm pretty certain all seven were exploited as zero days. So they were being exploited. Someone observed them by Lee. Thank you. As zero days. And I'm just struggling to like come up with great defensive recommendations. If you're using Cisco's SD WAN products, like what. What do we tell you? I uh, treat all your SD wan, Cisco, SD WAN stuff as already compromised. I don't know. That's a really bad recommendation, I think. But that's. But is it the best I got? Like, but is it. But that's telling. I. I guess. Thank you, Larry. First of all. But that's the best I could come up with because like that is a staggering statistic.

Speaker D: But that statement implies that. We know that implies you should take some sort of action.

Speaker B: Mhm.

Speaker D: But we also know companies rarely take the actions we want them to take.

Speaker A: Yeah. What is that action? So it's okay.

Speaker D: It's okay that you made this statement,

Speaker A: uh, like treat that as. What is that? I mean that could mean a lot of things. It's up for interpretation. But when you are treating it like it's compromised, what does that mean? Does it mean least privilege? Does it mean increased? There's a lot of actions to your point, Jeff. Right. You should take to treat something as well if it's already compromised. What do I need to do? There's a lot there. There's a lot there.

Speaker D: Can't do that.

Speaker A: There is a lot there. I mean, you could also just say the recommendation is throw it out and go get something else. Which I don't. I mean in this case, maybe it's less work than trying to defend it. That's interesting how from a cop. Like from a cost perspective. Uh, one second, Dave.

Speaker C: Right.

Speaker A: From a cost perspective, am I going to spend more money trying to defend something than I will ripping it out and replacing it? Because there's a cost of both. And what if it's more economical for my business to go. You know what, I know we made this investment in Cisco SD wanna. But you know what? Given where we're at now, we're better off just going with a completely different technology and it's probably going to cost us less in the long run. But what I Haven't done the study.

Speaker B: Yeah.

Speaker A: But I guess I'm, uh, like trying to motivate you folks out there that are listening. You should probably do that research because you may come to the conclusion that. Well, I think something else.

Speaker D: I think a lot of companies do go through that mental exercise to some degree and what, what they often try to do. And I don't know if anybody can definitively say, okay, we've thought of everything, but there's all sorts of incidental costs associated with an upgrade. Like you've got a whole, you've got some number of staff that are trained on the one product.

Speaker A: Oh no, I get it. Oh yeah. There's a lot of. You go on and on, like hidden compatibility issues. Sure, sure.

Speaker B: Dave.

Speaker A: Dave was trying to pipe in there. Oh yeah, let Dave have the floor. Yeah.

Speaker F: Uh, so, I mean, how long until the next SD WAN product that they buy potentially gets compromised? That's potentially predictable. You, uh, look in history.

Speaker A: Sure.

Speaker F: So therein lies an argument, and I guess it's reasonable. I've noticed over the past, say, 10 years or so that it's become increasingly common for security leaders to, to just buy a security product and expect that they're going to need a backup of some kind. Um, and so they'll say, hey, I'm going to buy this thing, but I'm also going to keep something on hand in case this thing just stops working. Uh, effectively security double bagging it. Um, what's the equivalent protocol for SD WAN in this case?

Speaker A: I don't know. But also like three of those CVEs and SDWIN are CVSS 10.0. Like they're breaking all new records. Like seven, I think. I haven't done all the research, but, um, I'm Fairly confident that 7 CVE is on the Kevin, Less than a year in the same product could be a record, three of which.

Speaker D: Definitely the All Star team.

Speaker A: Definitely the all star team. Three of which are 10.0 on the CVSS. That might be a record. So like, at what point do we really look at like out, like outliers? Like this product is so vulnerable that it is surpassing all other levels of vulnerable for all other products. Which means like the, the second product on my list, even if it had two CVSS10s, there's a, there's a military term. Five things. Maybe that's better. I don't know.

Speaker D: There's a military term for this. Paul, if you've watched Saving Private Ryan. Fubar.

Speaker C: Mhm. Yeah. Yeah.

Speaker A: At what point does it crosses FUBAR on the Scale.

Speaker B: Yeah.

Speaker A: And then I just could do something

Speaker D: different to keep moving.

Speaker F: Does this segue into. Into Article 17 now? Because, like, you're touching on recent history of just the magnitude of cyber security impact, and your Article 17, I think, sums up really well.

Speaker A: Oh, that was one I didn't. I didn't write up.

Speaker C: Uh.

Speaker D: Or does everybody get a free pass now because AI is discovering so many more vulnerabilities? Everybody gets a pass.

Speaker B: I don't.

Speaker A: I don't know. I don't. I did have stories about AI finding vulnerabilities. Um, well, Squid Bleed was one. It's a pretty amazing vulnerability in that it slipped past humans for 29 years, which I think is kind of interesting right now. There's definitely some certain, like, select conditions that make this work. Um, I was just kind of. With my. My SQUID proxy, I was kind of transported back to, uh, over 25 years ago or so, where we set up squid proxies on FreeBSD boxes because we only had so many T1s that we had to cache the pages going out to the Internet to save bandwidth, which is apparently still one of the top use cases for squid proxy.

Speaker C: And I'm not.

Speaker A: Uh, look again. I have a rich history of squid proxy. One of my co workers at the time was all about it, and he was also big into FreeBSD, and he showed me what he built, and I was like, dude, that's actually really awesome. And he's like, yeah. By the way, I can monitor what websites people are going to, so I can tell they're going to, like, a website that's going to get them hacked, or I can tell if they're doing something inappropriate in violation of our policy. Like, well, that's interesting, because usually those sites also lead to them being compromised as well. Instead of, like, a great system, I'm, um, like, dude, I think that's awesome. Like, 2000 year, 2000 it was. I have FreeBSD running, and all our web traffic is going through a squid proxy. I'm like, that's pretty awesome. Um, and I was kind of. It was more nostalgic for me than it was, but apparently people still use it for that. Um, uh, to cache that data to save bandwidth, which is not as much of a concern as it was, you know, 26 years ago. But, uh, people still use it for that. And they had, like a. It was like a heart bleed. Do they call it heartbleed, like, attack?

Speaker C: Uh-huh.

Speaker A: It leaked memory. Yeah, it was like a heartbleed, like, attack that leaked contents of Memory. Um, and so I thought it was kind of cool that I found this vulnerability. Anyway, that's squid bleed, Larry. I wanted to go just something completely different. The Secret Life of Probe Request. Did you get a chance to read this? I know you were out today.

Speaker B: I did. I did get a chance to read this after.

Speaker A: So you can summarize it better than I can and most certainly better than AI can.

Speaker B: Yeah. Which, which story was this for viewers?

Speaker A: Uh, my story number three.

Speaker B: Your story number three. Ah, yes. Yeah. So we've made some changes over the years about, uh, how our devices deal with preferred network lists. Back in the day.

Speaker A: This is the Karma attack. This is like one of our most famous favorite attacks of all time, right?

Speaker B: Yeah. So, yeah, Karma attack. Your device was out there probing for networks you've connected to in the past. Hey, I want to connect to Linksys. If you're asking for Linksys, we can become Linksys.

Speaker A: I'm Linksystem.

Speaker B: Yeah, I'm link says come connect to me. Um, rich and broad history of that and lots of attacks. And we saw that this was really, really harmful. Um, so manufacturers have changed and the WI FI setup has largely changed to try to prevent some of this type of stuff. Um, but, uh, as a result, to change this to better improve, we've changed the way we do per requests or preferred network lists and so forth. It still happens out there. There's legacy devices out there. Um, there are devices that, uh, you know, case in point, uh, one of my, uh, Apple devices should not be probing for named networks anymore. But because it's been migrated and migrated and migrated and migrated onto multiple iterations of intel hardware, um, that some of those networks are still being probed for by name. Um, I don't know about moving it to an M M, an M series Mac. Um, but in any case, there are still devices out there probing. And this one was actually kind of fascinating in that, uh, the author, uh, Zachary might have found that there were devices out there probing and in fact, lots of devices out there probing and probing for a very specific network known as default ssid. And there was another one that he noted. Um, so why. Why are all these devices out there probing for default ssid? Well, tldr, these devices are out there probing for that ssid because that is the default SSID that they look for to perform their initial setup to connect to WI FI networks to be, uh, to enable their IoT devices.

Speaker E: Default passwords. Boot us on the butt again. Jesus Christ.

Speaker B: Well, not so much default password.

Speaker E: It's just any Default network piece of data. Come on.

Speaker A: It's basically a device going like, hey, is this SSID available? Because if so I really want to connect to it.

Speaker B: Yeah, so you can configure me.

Speaker E: Wait, was it named Free Public WI fi?

Speaker A: No, it's default ssid.

Speaker B: Ssid.

Speaker E: I know.

Speaker A: This is what it was probably there's lots of different devices do this even still today.

Speaker C: Right?

Speaker B: So uh, the fascinating part about this one, um, is uh, that the researcher, uh, uh, Zachary went and said great, well I can be default ssid. So he stood up an open default SSID WI FI access point and the device refused to connect. Why IT expects a WPA2 pre shared key network and not an open one. Okay, so what's the password? Well, using a um, the uh, uh, it is referred to as the WI Fi. Um. Oh, uh, where is it?

Speaker C: Here.

Speaker B: Half uh, handshake attack. You can set up an access point. You go through the four way handshake process. Step one, from access point to client, client to access point to exchange some nonces. You know the nonce. Once your nonce from the access point, once you receive it from the client, it is based on the pre shared key. You can now take those nonces and that output generation even though you don't have the full four way handshake and effectively use stuff like hashcat to recover the expected key for that network.

Speaker A: Wait, so you can intercept a uh, nonce and derive the pre shared key?

Speaker B: Well, you're not so much intercepting is that you are becoming the legitimate access point.

Speaker A: Okay, yeah, I got you. You are the access point. So you're receiving the nonce, not intercepting it. You're. Yeah, because you're the SSID it's looking for. You're receiving the nonce. Once you receive that nonce, then you can derive the pre shared key.

Speaker B: Correct? Correct. Because the M, the math at that point for uh, deriving the pmk, which is where the nonces come in.

Speaker A: Right.

Speaker B: Is based around some known math for the two nonces. One that you know because you're the access point. The one that has been provided to you by the.

Speaker A: Just an FYI, I'm so turned on right now when you're describing this. So nerdy. It's so erotic.

Speaker B: Nice.

Speaker D: Do you guys want us to like, you know.

Speaker G: Yeah.

Speaker A: I need a moment.

Speaker B: Yeah. Sometimes a cigar is just a cigar. Paul.

Speaker A: So awesome.

Speaker B: So yeah, so you've got both of these components, you know how the math is constructed and as a result you can now brute force the pre shared key. Into that function that was derived from those nonces, those unique numbers.

Speaker A: So that's what he did here. Right. He basically set up uh, in uh, access point, AP mode, collect the half, the handshake as they, as they put it, um, and was able to derive the key. And then what do you do once you have the key? You can now I can become an access point that has that key and it will fully authenticate to me. Right?

Speaker B: Correct.

Speaker A: Yes.

Speaker B: And now you can observe all the traffic where it's going and you can end, map, scan it and you can do all sorts of other fun stuff. Um, and through that investigation, he was finding that the Mac addresses were to a specific set of uh, wireless adapters, uh, from uh, Mitsubishi. Uh, they were uh, the Mitsubishi Mac 5771F. Uh, sorry, if 2E Wi Fi adapter. Specific WI FI chipset from Mitsubishi.

Speaker C: Yep.

Speaker A: It uh, says uh, in my description they use an air conditioners, water heaters and rice cookers.

Speaker B: Yep. I don't know about rice cookers, but he definitely noted that um, a little bit more on the industrial side. Pseudo industrial. Uh, so room, air conditioners, refrigerators, heat pump, uh, water heaters, uh, bathroom drying, heating and ventilation, um, smart ventilation switches, um, induction cooktops and rice cooktop.

Speaker A: Everything has WI fi now.

Speaker B: Yeah. And this is that this was the point. Like you could go.

Speaker D: Everything has an off switch to the WI fi too.

Speaker B: Just saying you can go buy a rice cooker and not ever care that it's connected to your WI FI network because you press a button and it cooks your rice and then you're done. So these are those devices that are now in those modes. And then as a result, uh, he found some scripts for some devices here, uh, that you could actually use some python to change the values of temperature and interact directly with the device to potentially create some bad situations there.

Speaker A: Yeah. So Jeff, even I think what Larry's saying is even though you have this device and had no intention of configuring the WI Fi, uh, that it. Because it's defaulting to go look for a specific WI FI network, an attacker can capture that and take control of your device. So to your point, Jeff, like, but

Speaker D: it's still not on my network.

Speaker A: It's not on your network, but it's connected to an uh, attacker's network.

Speaker B: And that now, that attacker, that now attacker now effectively has controls.

Speaker A: That device can control that device.

Speaker D: I'm gonna lock my bag of rice up tonight then.

Speaker B: Well, you should also lock up your air conditioner and your heat pump.

Speaker A: But it begs a question, terrifying to Jeff's point. How do you turn off the WI FI on these devices?

Speaker D: I mean if the WI fi is disabled, how's the attacker getting to it?

Speaker A: And I've always thought, because we're talking about TVs in a moment too, I've always thought like, oh, I have a tv if I just never associate that to my WI FI network, like I'm safe. But what this attack is highlighting is you need to turn it off because if you don't configure it, potentially somebody attacker can configure it and talk to it on their own network and then uh, potentially interact with that device if they know what it's expecting or how the authentication works or if there's vulnerabilities or whatever.

Speaker B: Right Jeff, I kind of know where you're going like this. Uh, well one, how do you turn it off? Well, you probably have to configure the device to be able to get into the device to turn it off, which is kind of ridiculous. There's no button to turn it off. The other one. And not knowing which devices that these are being used and the types of environments, these devices could very well be connected via some other medium such as say Ethernet or modbus, um, to, to other types of networks which could then potentially be used for a, ah, pivot into a modbus network to do other types of control or you know, potentially even, you know, pivot into other networks. IP based once, once the access for WI Fi.

Speaker D: Well, and I understand I'm, I'm somewhat of an anomaly because I'm not like, what else can I control from my phone? And I'm automatically everything I buy plugging it into my WI fi so I can, can see what's inside my refrigerator when the door's closed and stuff like that.

Speaker B: You're just weird, Jeff.

Speaker D: I am just weird.

Speaker E: Just get your ass up out of the damn chair and look in the damn fridge, man, for God's sakes.

Speaker B: But I'm not in the chair, Josh. I'm at the grocery store and I forgot whether I needed to get cream cheese or not.

Speaker A: But this story may, but this story makes me want buy it again.

Speaker E: You'll have three of them. You know what, you'll go through it.

Speaker A: You know what's frightening? This, this makes me want regulation that mandates that manufacturers put like a switch that I can turn off connectivity. To Jeff's point, if I buy some kind of appliance and I don't want the smart functionality, I want a physical switch that I can go turn off like all WI Fi, Bluetooth. Some devices have this, right? Like the privacy minded devices. Um, names escape me at the moment. I think this is a feature on some laptops too. There was a feature, right?

Speaker B: There was a physical.

Speaker A: Yeah, there's like a physical switch. I can turn off WI Fi.

Speaker B: And do you know how many support calls that they got complaining because people

Speaker A: left it on if I couldn't connect? Yes.

Speaker B: Or, or didn't realize that they had switched the actual physical switch.

Speaker A: Yes.

Speaker B: Hours.

Speaker A: And that's probably why we don't see them on. It's exactly why we don't see them on devices today because people. And I think I uh, you know what, I think I've been guilty of that. Like why can't I connect to WI Fi? Well, I'm like, oh, because I hit that stupid kill switch.

Speaker B: Yeah, but now I want the kill switch. Yeah, but also to your point Paul, uh, you think about some of these connected devices. Where do you put the kill switch on the device that it's easily accessible and not going to get bumped. Or um, now you have to have this kill switch and it's a switch and you have to redesign your cases or you have to have some other considerations in the cases which is now an additional expense to these devices.

Speaker C: Right.

Speaker B: It is where 100 where, where uh, you know, margins are already razor thin.

Speaker A: Like uh. But if you're a hardware hacker, like many of us, you're into hardware hacking. It's a lot of work to be able to go what do I do to disable that chip and have the device still function? I don't know that I would go there in a lot of these devices. Like that's dicey. Then the next thing that my brain goes to is do I just put my whole house in a Faraday cage? But that's a huge expense and prone to hey, leakage and copper.

Speaker D: Copper cladded buildings are. Yeah, they were a thing.

Speaker A: Oh well they exist. But it's big cost, right?

Speaker B: Yeah, yeah, I used to work in

Speaker D: one but it was cheaper than providing the tempest protection on each individual 50 pound monitor that you were.

Speaker A: Yep. But it go. But it goes to my story number seven. Um, nearly half of the LG smart TV apps contain residential proxy SDKs. And this is just a continuation of the ridiculous stuff that goes on uh, with the devices as consumers that we buy and put in our homes. Um, and this is just super shady. So ah, Spur Intelligence Lab scanned over 6,000 apps. They specifically looked at LG's WebOS and Samsung's Tizen platforms, they found that just over 2,000 of them contained embedded residential proxy SDKs.

Speaker B: Okay, so what does that mean, residential proxy SDK?

Speaker A: So they say, um, these apps quietly route third party Internet traffic through your home TV and its IP address without most users ever. Well, you would notices as a user, um, says the apps involved are not the kind you would think to audit. They're screensavers, fish tanks, clocks, casual games. Right. So they're basically poisoning somewhat like on the surface harmless apps, but under the covers they have an SDK inside the app, uh, that gives other companies bright data was one of the ones mentioned that is the most abusive of this. They are monetizing the TV's Internet connection in the background. And as we know this is the rev. Like this is the economics of it all. Samsung wants M to make a tv. They want an app store on the tv, they want people to put apps on the tv. And Samsung and um, I'm convinced this is how it happens. Samsung's going, hey, I can make your app like not uninstallable or I can make your app prominent in our app store and you give us some money. But you'll be able to make money on your app. So you're going to give us money to be in the store and then you can do whatever you want with your app. We're not going to put restrictions on it. And the company's like, great, I'll make a screensaver. Then in the background I can let Russia or China use this as a proxy network and charge money for it. So like everyone's making money. Seems like I'm selling TVs, I'm getting kickback from the apps that are installed in my environment. I'm locking my users out of the visibility into these apps. I'm um, locking my users out and to be able to uninstall them or monitor them or whatever. And the companies that make the apps are like, great, I'm making money because this is basically a proxy out of this person's Internet access. The whole thing is shady. This is again a case where I would call for regulations and legislation to be like, this should never happen, so I should not be in the situation at all.

Speaker B: I've got, I've got, I've got two questions, um, and specifically about this, this research. And the first one is more technical and Josh, this is something that you and I deal with with every day. So the research says that, yeah, there are uh, confirmed proxy SDK stuff in here. And now is this Just a function of the fact that the software components for the proxy SDK are included in the app. Uh, and their analysis saying, oh yeah, hey, these can do proxy SDKs because the software exists in the binary. But are those particular functions that allow the proxy SDK functionality to happen actually active? Or is this just left over because these, this stuff is used by an IP stack to go gather data from the Internet, like they're saying that their EULAs are doing? So my question is one, is this really a threat? Like, uh, are the components for the proxy stuff actually reachable by any of the software in use or is it just present in the apps and they don't really get into that in the article?

Speaker A: Yeah, I mean they cite other instances of this from Krebs that talked about the Kim Wolf attack, which we talked about on the show. I don't, I don't think they. I think they were just analyzing the apps. Larry, it's a great question. Did they actually observe this in the wild or is it based on just reverse engineering the apps?

Speaker B: Yeah, basically what m. I'm seeing here, like, it's looking like they reverse engineered the apps and how deep did they reverse engineer the apps? Are the function calls there? Oh my God. Danger. Are, ah, the function calls ever actually activated? Are they ever actually accessed as part of any of the program functions?

Speaker E: I'm going to say yes. And the reason I'm saying yes is not because I have proof of it, but because the way that the. In the article, it shows you some of the consent screens that you can consent to do this or you can decline and just watch the ads to play the game or things like that, Right?

Speaker C: Uh-huh.

Speaker E: And it says, uh, for example, play Pac man without ads for an ad free experience, Please allow web indexing by bright data to use your device's free resources and IP address to download public web data from the Internet. Uh, and I'm going to tell you that that sounds pretty much like they're saying either go ad supported. That's cool, because we'll make money off you anyway.

Speaker A: Either pay us or let someone need

Speaker E: to make money off you somehow.

Speaker A: Yep,

Speaker B: yep.

Speaker E: So I'm sorry.

Speaker B: That's fair. That. That is absolutely fair.

Speaker E: That's not cool, man.

Speaker C: That.

Speaker E: That allows.

Speaker A: They also said in the article though that, um, Roku and other manufacturers don't allow this to happen. So rather than like overarching legislation, it's up to the individual companies that are making these devices to regulate whether or not they want apps like this in their store or Not. And so what I believe the threat actors and or shady companies do is they go to LG or Samsung who are like, yeah, you can put an app like that in our store. But Roku and others are like, no, you can't have that in our store. And since. And again, it's, uh, it's economics. The TV from Samsung or LG is air quotes cheap, but the Roku device or whatever is like an add on. You have to buy after you buy your tv. Uh, so the more money you pay up front, the more maybe a lockdown environment that you get. It's why I love Nvidia Shield. And actually I bought some Roku devices and I find them to be better, uh, than some of the other offerings out there.

Speaker B: And so, Paul, I mean, you're a heavy user of some of these types of devices and when you compared like those devices to the tv. Uh, uh, my second question is, who actually installs this crap on their tv?

Speaker A: Yeah, dude, dude, I'm gonna say two

Speaker E: words to you, Fonzie, buddy.

Speaker A: But it's very similar to when we first got iPhones. We experimented with a lot of like, flashlight apps. And because the app thing was kind of new, it's the same thing with these TVs and or entertainment devices. When they first came in the market, you explored the App Store and you're like, oh, like, cool, I can put like a fish screensaver. Like, that's kind of. I did that like the very first week I got some of these devices 10 or 15 years ago. And very quickly I was like, well, all that is crap. Uninstall that stuff and have gone.

Speaker B: Now what do you, what, what buttons on the remote do you use to play Pac man in.

Speaker E: In.

Speaker A: I mean, Nvidia has like a gaming platform on it, but other than that, I agree with you, Larry. Like, um, you're not doing that now.

Speaker D: I just want Joystick to play Pac Man.

Speaker C: Oh, they.

Speaker A: Well, they have like a full.

Speaker B: Yeah.

Speaker A: Nvidia still have gaming controller cars and scabs from that. Right. But now I, I just want my entertainment apps. Right. Like, I want my streaming apps.

Speaker B: Yeah.

Speaker A: And that's it. I don't want any other apps on my tv.

Speaker B: Yeah, I mean, I, I mean I can get like, you know, maybe the kids stumble across and they want to play Pac man and then they find out that it sucks and it's still installed there. But like, for the most part I don't. It just feels like not many people are actually installing these types of apps on the TV because The experience probably sucks. Or they don't know how to do it right.

Speaker D: Speaking for my generation.

Speaker A: Mhm.

Speaker B: Talking about my generation.

Speaker A: We were supposed to be dead by now.

Speaker E: Just, just remember, uh, you know, Jeff, don't trust anybody over 30

Speaker D: inches.

Speaker B: Including himself.

Speaker D: Including myself.

Speaker A: Jeff, did you had, uh. A couple of your stories were interesting.

Speaker D: I hope so. That's why I put them up there. Uh,

Speaker A: I'm trying to think, uh, which ones I flagged. Foundational security practices. Your story number four, looming AI fueled threats require urgent cyber security improvements. Says the five eyes. You had a quote that said executives should focus on risk assessment and found air quotes. Foundational security practices.

Speaker D: There's that pesky foundational fundamental conversation coming up again. Mhm. And then my last story, seven or eight. I forget what my number was. I actually found there.

Speaker A: Seven was the actual statement of what.

Speaker B: Right.

Speaker D: Um, and I apologize. I don't know who these five eyes are, but it's from Australia, so it's got to be good.

Speaker A: UK, Canada, Australia, New Zealand, England and U.S. is that five?

Speaker E: No, no, it's.

Speaker A: It's New Zealand. It's not Zealand.

Speaker D: It's not the us.

Speaker A: New Zealand, Australia, Canada, uk In the US or five eyes. Yes.

Speaker D: Yeah. So it was a little bit of a Captain Obvious thing, but at least somebody's saying it out loud. Um, and M, of course we've been.

Speaker A: What are the fundamentals?

Speaker D: What are the fundamentals?

Speaker A: We just keep coming like, what are the fundamentals?

Speaker D: Guess what my next talk at some future conference is going to be.

Speaker A: We should like talk. Yeah, it needs to. It's a conversation that has to be had because so many people. Ah, I think, uh, to your point, Jeff, are throwing around this terminology about security basics. Security fundamentals. Like what does that mean? And we've, I think on this show defined many different items that could fall under what security fundamentals are. Do we all agree on that or not? That's the question. Right. And we don't. So what are the security fundamentals that we agree on? We almost need a, And I think I said it last year, guidelines where we all try and get together and agree. I don't on what different verticals and different aspects, but.

Speaker E: Well, that's a good point that you make.

Speaker F: Liar.

Speaker D: Get it. Liar.

Speaker A: Liar.

Speaker E: That's a good point, Paul. But let me, let me throw this into perspective a little bit. At least we can talk about. Iam. We can talk about OT and it and Iot we can talk about lots of different individuals.

Speaker D: I don't think those are fundamentals though.

Speaker E: But that's the point. Bear with me. Uh, the fundamentals are something I've been working with for a little while. They're attestational fundamentals. I can attest. And what I've been using is IEEE UL 2933. That's based on a clinical IoT standard, or it is a clinical IoT standard, and it goes for trust, identity, Privacy protection, Safety and security tips is what they call it. So those are fundamentals. Do you trust the system that you're working on, the people, the data, the technology, the process, the facilities, the AI? And how do you trust them? How do you manage their identities or manage the risk of the identities? And in every which way that that works, and that's the kind of thing that we're talking about. And actually, and I'm not trying to be a jackass, but I built it. Uh, so if you want to go to valuechain risk.org and click on beaconscore at the top, you can grade anything you want for free. It's free.

Speaker D: Well, Josh, I agree with everything you're saying, but I think that that's perhaps a second tier. Uh, I don't think you were on last week or whatever recent week where I was saying this, uh, debate that my eye. Way of my idea of a fundamental of information or data security. Maybe we throw, Throw in the cyber security term is sort of deciding the goals and objectives and, you know, what do you care about? What do you want to protect? What, you know, what are you up against before you start talking about the technology? Now, there are fundamentals of we've got technology involved, but I think, I think there's a layer of fundamentals that sort of come before.

Speaker E: I mean, uh, that's what I was just talking about. Or am I misunderstanding? Well, the trust, the identity, the like.

Speaker D: Yeah, I mean, you, you, you, you said a lot of the terms that. No, you were saying a lot of the things, but you, you. I thought you were wrapping it up in terms of applying it to systems, applying it to technology. If we're, if we're saying the same thing, that's fine. Um, a few years ago, uh, I was at a. You know, once in a while, us old NSA information assurance people get together, and a couple years ago, we had a gathering, and Chris Inglis, who was the first National Cyber Director, and, you know, he was some muckety mucket, um, and I say. I forget what his title was it. And I say, hi, Chris. Not that he listens, but he was giving a talk and you Know, we, we talk about people, process and technology. And he said the same thing, only he said it was people doctrine in technology. And I've been muddling that over in my head for years now, trying to

Speaker E: get doctrine in this case, that's what I wanted.

Speaker D: I mean, he's coming from a government, uh,

Speaker E: like process, you know what I'm saying? Doctrine, process, guiding principles, that kind of thing. So I think.

Speaker A: But there's something about culture too that I think seeps into this. Right. Like you, you can have all these more technical definitions, but, uh, also there's like the higher level thing that defines your approach in almost like tolerance to risk and security at a very high level that I think plays into all of this. Right. I didn't. I've experienced that at a lot of different stations. Right. Like when I worked for university, there was, there was not much. The guidance at the high level.

Speaker D: Academic freedom.

Speaker A: Exactly. 100 Jeff.

Speaker B: Right. Like.

Speaker D: Oh, absolutely.

Speaker A: It was like, we need to preserve academic freedom. And then I work for cybersecurity companies and we're like, well, our doctrine is like, no one should have access to things they shouldn't like. It's very, very locked down. And there's two. Those are two opposite ends of the spectrum.

Speaker C: Right.

Speaker A: But both are equally important to kind of define your, I don't know, tolerance or culture as it, as it relates to security.

Speaker D: Yeah. I think culture is an important, fundamental element to discover who you are, what you are as an organization, what business, what profession, what vertical you're in. I mean, in the early days of consulting, 30 years ago, coming out, when I was talking to companies about, you know, if you're going to plug into the Internet, you got to get secure, one of the common questions was, what's everybody else in? Yeah. And I'm paraphrasing. In my vertical doing, I don't want to do any more or any less because I don't want to be blamed for, for not following best practices. So what are the best practices for me? M. More than a university.

Speaker A: I don't want to do more. Yeah. There was a huge thing in university. I don't want to do more than any of my peers, but I also don't want to do less than any of my peers. Right, but that's like a flawed model because, like, who's setting the standard? Well, it is absolutely.

Speaker D: I mean, best practices. And in those days nobody was doing anything.

Speaker A: So you were.

Speaker B: Good practice was to do nothing.

Speaker C: Right.

Speaker A: Right.

Speaker B: M. You always do more, just a little bit more than best practice.

Speaker D: I Think so. But, uh, you know, I would counter that with, well, you know, I would try to start a conversation on what's valuable, you know, what are you trying to protect?

Speaker C: And.

Speaker D: And back then it was really, you know, what's, uh, your. What's your CEO think or your board think about, uh, how much they want to invest in not being the next company named in, you know, Wall Street Journal as a company being breached. And most always, they're like, oh, we

Speaker A: don't want that to happen.

Speaker D: I'm like, great. Nobody wants that to happen. How much you willing to invest in making sure that doesn't happen? And. But by the way, it could happen. Anyway, really hard conversations to have, but I think more and more we need to have them.

Speaker C: And.

Speaker D: And I think our industry has been built around, uh, that sounds really hard. You're going to make us think. And. And that's difficult. Just telling me what I need to do. Tell me what I. Whoa.

Speaker A: Yeah,

Speaker E: tell me what, Silver.

Speaker A: Yeah, exactly. But look at all the history we have on this podcast and stuff. We've talked about all the nuanced things, like, do those fall into some kind of policy procedure or cultural doctrine that we have? Like, we. We come up with all these new, new things all the time. And.

Speaker F: Yes.

Speaker A: No, one thing I. But one thing I would. Jeff, I wanted your. Your thoughts on in. You're gonna love this. Right. Was the 2021 Honda Civic infotainment system can be jailbroken via USB.

Speaker B: Yep.

Speaker A: And like, on the surface, that doesn't relate to what we're talking to, but it's does because someone or group of people made the decision knowingly or unknowingly that they would implement and roll out into production test keys.

Speaker D: Right.

Speaker A: Like cryptographic. And I've seen this in UEFI and in, you know, things in my day job. Oh, uh, we're just going to sign in with test keys. Like, where does. Where does that fall in the doctrine?

Speaker B: Paul, do you have the story in your list? Yes. You do?

Speaker A: Yeah, it's my story number 10.

Speaker B: Because I think we had, uh. We may have talked about this story last week or.

Speaker A: I had it last week in.

Speaker B: Last week. Yeah. Yes, the evil valet one. We did not talk about it last week. We had it in the list.

Speaker A: You had in the list? Yeah, it's fine.

Speaker B: Um, this is also crazy, uh, because if we think about this, though, um, after they dug in and they noted that the stuff was signed with test keys, we think about how the security industry has evolved and the implementation of the Android operating system on these vehicles in 2021 was designed and implemented in 2011.

Speaker A: Right.

Speaker B: So it was a 10 year lead time which is not all that unusual in the automotive industry, especially in 2021. That, hey, I was going to say

Speaker D: not unusual in the evolution of cyber security either.

Speaker B: Like in 2011 we weren't really thinking about that as much as we were nowadays. Uh, we should have been.

Speaker A: But this is my like encryption is only as good as the key and how you protect it.

Speaker C: Right.

Speaker A: Like Jeff, this really speaks to so many conversations we've had on air and off air about specifically encryption.

Speaker C: Right.

Speaker A: Um, encryption is great.

Speaker D: Encryption algorithms are hardly ever broken. It's always the implementation, the implementation key distribution and key manager.

Speaker A: Dude, like I, I heard say that when I read this article. I was hearing you in the, in my ear, right. In all the conversations we've had over cigars or uh, and on the podcast, the whole thing, I'm like, oh my God. This is the shining example of mhm encryption. Great.

Speaker D: Many people, like as we know, many shining.

Speaker A: So many really super smart people develop the algorithm, they test it, we, we run through multiple iterations. Like look at all the algorithms we talked about a couple of weeks ago that are uh, trying to be deemed as quantum safe in all the things they go through. But so like most of them are hinged on can you protect the private key?

Speaker C: Mhm.

Speaker A: And in this case, well, if it's

Speaker D: a public key algorithm, the, the, the

Speaker A: can you protect the private key was not private. It was a test key that multiple people had access to.

Speaker B: Right.

Speaker A: And therefore like all integrity and privacy is out the window. Like that's how easily it's just, well, a security control anymore.

Speaker D: And I think in a uh, an analogy which more people can understand if they don't have this, you know, if they're, if they're hung up on the crypto thing, um, uh, web forms, web applications, you have fields to fill out. The early days of E Commerce where you have to type in, you know, let's say a credit card number which is 16 digits.

Speaker C: Mhm.

Speaker D: Why would anybody. Or you're just filling out your address with a zip code of five digits. Why would anybody put 10,000 digits into a field that's only looking for five digits?

Speaker A: Because I can, because I can.

Speaker D: And it can be exploited to break things. I mean it's, it's that type of mentality or lack of mentality. You know, it's.

Speaker A: Yeah.

Speaker D: Who would possibly use this for anything

Speaker A: other than what we assume? Because it's encryption and There's a key that no one else.

Speaker D: I can't read it where it must

Speaker A: be, uh, it must be. But this. And I've dealt with this numerous times in UEFI and all the other things like. Oh, uh, more than one person had access to the key or the key leaked and it's public knowledge like.

Speaker D: Right.

Speaker A: That's often the downfall. It's not the algorithm, it's not the attacker. In our previous example, you started the, the new segment. Right. Someone has access to a 40 GPU cluster, they could, you know, cryptographically break or use rainbow tables to break it. Right. It's not that, it's.

Speaker D: I wish I had one of these 40 years ago.

Speaker A: It's like you used a key that other people had the knowledge of that key.

Speaker C: Mhm.

Speaker A: And there's so many times in history, in the past 30 years where that's happened and we. Which we haven't learned, right? Oh, uh, it's, it's, it's frustrating. We haven't learned though. We haven't learned those fundamentals about security, privacy and encryption that get us here.

Speaker E: Surprise, surprise.

Speaker A: Right.

Speaker D: And what did you pre select the title for this segment to be? Because I feel like a title is coming here.

Speaker A: Oh, it's a great question. We can have a discuss. We can change it. I said hack. Uh, so Cloud Visibility, which is our um, uh, sponsored segment. Right. For To Bleed, which we talked about a lot. Hacking Things the Easy Way, I think covers. Yeah, that covers it. It does.

Speaker D: That works.

Speaker A: That could almost be the encompassing title for this whole show. Hacking Things the Easy Way. Specifically what was I referencing in that? Probably most of our articles, right?

Speaker B: Yes.

Speaker D: I mean at least the one, at least the ones we've talked about.

Speaker A: 100%. Oh. But I was also referencing, um, domain takeovers and this happened to be a TB link example. But this exists in. There's been so many. We've covered articles on this, on the show. And this is a huge thing in cyber security, right. Where you find a, in this case a firmware or a system that uses a domain name to, in, in whatever capacity right inside the product and they like forget that they registered that domain name and they let it lapse and either a, uh, security researcher or an attacker takes over that domain name because it's lapsed and it's baked into a product and they're able to collect information about it. Shining example, I think is, um, Malware attack. Uh, Marcus Hutchins. Right.

Speaker E: Uh-huh.

Speaker A: Was, um, like, oh, that domain names available. I'll just Register and see what happens. And it happened to be. What was the big. What was his big thing?

Speaker B: It was effectively the, the neuter.

Speaker A: The shut off.

Speaker C: Off of.

Speaker B: Of what? Uh, one of the big.

Speaker A: Wanna cray. It was.

Speaker E: Wanna cry.

Speaker A: Yeah. Because Marcus has done great work. Well above and beyond that. Right. But, uh, that. That was a great.

Speaker D: He's also done great work. Well, and uh, below that too, which he acknowledges.

Speaker A: He is amazing, awesome person. Uh, much respect.

Speaker C: Right.

Speaker A: But it. But there's so many occurrences of this. This is just the most recent one. Right. Like TP Link. Uh, someone leaked like a TP Link thing where the. Someone could download all the firmware for all TP Link devices. They specifically analyzed it for all the domains they were using. And they're like, hey, so there's one domain. Like, I registered it, and all of a sudden there's this TP Link devices that are communicating with this domain, allowing me to do stuff. Um, and by the way, that person reported it to TP Link, it was like, hey, I got this domain, by the way your devices are reporting to it. And TP Link is like, yeah, that's an issue. He's like, can I just transfer this domain back to you so you can fix it? And they're like, yeah. And he did that. And that's. That's the way it should be. Right. Like, that's. That's awesome.

Speaker B: So I just want to call that

Speaker A: out on the show. This person did the right thing. TP Link did the right thing. Like TB link made a mistake. But I'm not faulting TP Link in this case because there are so many things we need to keep track of and if we lose track of one domain, that could be an exposure. And that happens.

Speaker B: So, yeah, the one that kind of bugs me a little bit about this whole thing is. Yeah, I get the initial disclosure. And the, the initial disclosure here was it bugged me a little bit when I think we talked about, um, was from, uh, Simone Margiotelli.

Speaker A: Yeah, I recognize that researcher's name. Yep.

Speaker B: Evil Socket.

Speaker A: Evil Socket. Yeah, that's Evil Socket.

Speaker B: Um, I found an unrestricted S3 bucket where I can list all the versions of firmware for the devices. And guess what? They have them listed on their website.

Speaker A: Sure.

Speaker B: All the versions and you can just click on stuff on their website. This just made it easier like that. I don't know so much that that was a vulnerability, but that as a result, you know, we get. It gets called out. It just made it easier so that now, um, you know, Researchers could take larger quantities of uh, firmware for, for analysis such as this.

Speaker A: And that's also a double edged sword like yep, I am glad that a researcher who got access to that, analyzed the firmware, found something, reported it responsibly.

Speaker B: Uh-huh.

Speaker A: And then like the end result was transfer the domain so we can make the world a more secure place. But if a threat, I kind of get both sides of this. Right. Like if a threat actor gained access to that they may not go through responsible disclosure. And I get that. Yeah.

Speaker B: Now the other one that I think, and I'm trying to read through the article because I remember seeing it in here before for um, the, I think kind of the intent here was um, uh, around the long line domain collision attack. Like uh, and this may have been one that you know, they, they never intended to um, you know, have registered because it was being announced via uh, MDs on the local network. Like we use like you know the dot local MDNs stuff for, for that now. But can we other uh, do other tlds via ah, um, uh, MDNs? Yeah, absolutely we can. And maybe this was only ever intended to be on the local network for MDNs and so many um, IOT uh, manufacturers. Oh, this was Fritzbox back in the day with the dot box top level domain which then later that became an actual thing box tld.

Speaker A: Right, right.

Speaker B: Um, so if it was Only local um, MDNs, I get it, you're bringing me back, man. Um, yeah, I'm not going to register that. It's only local stuff. But what happens when now MDNS isn't

Speaker A: supported on your network. It wasn't a top level domain previously, but it is now, which afforded the opportunity for an attacker to register the domain.

Speaker B: Yeah. I mean I can, I can understand the potential developers reasoning why they never registered it.

Speaker A: No, agreed. But there's so many times when the attack is as simple as oh, I just need to go register a domain because someone lapsed on that and that that happens.

Speaker B: Yeah. I mean these are all things that uh, I've, I've exploited over the years.

Speaker A: Yeah. 100%. So I mean we've, in the past 20 years, we've so many examples where the attack was as simple as oh, I just need to go register that domain.

Speaker C: Yeah.

Speaker A: Or things.

Speaker B: Yeah. Case in point. Uh, you know I've talked about this eons ago as part of a presentation. Josh Wright, as part of one of his classes many, many years ago made this fake like clown dating site as part of a CTF challenge.

Speaker A: Yeah.

Speaker B: And he uh, the. One of the email addresses I think for the fake administrator of this fake dating app was damnclowns gmail.com and he hadn't registered it, so I did.

Speaker E: Oh no.

Speaker B: And I never told anyone about it.

Speaker A: Mhm.

Speaker B: Never. I told.

Speaker A: Not even a domain, just a Gmail

Speaker B: address, Just a Gmail account. No, no periods, no nothing. I know. I told nobody about it. I never used it anywhere. I just sat on it and listened, waiting for it to happen. And sure enough, like five years later it starts getting email.

Speaker E: You serious?

Speaker B: Serious. Because some dude in North Platte, South Dakota thought it was his email address and I don't know whether his like he misspelled damn with a D a M and everybody else actually put D A M N spelled M correctly.

Speaker C: Right, right.

Speaker B: Um, but I started getting like his PlayStation account emails.

Speaker D: Yeah.

Speaker B: The ability to do password resets for like PlayStation and his bank and his uh, he apparently worked for a very large company where I would receive notifications that he had received and could sell his uh, monthly stock options.

Speaker A: Oh my God.

Speaker B: And had access. So like I understand how these things happen and we've abused them for a really long time. I still have that email address by the way.

Speaker F: Do you?

Speaker A: Seriously? I love you. Never gave it up.

Speaker B: Yeah. Uh, the only pro. The only problem is, is that I haven't logged into it in a really long time.

Speaker A: Oh, they might have recycled it. Yeah, Gmail did a huge recycling.

Speaker B: Yep.

Speaker A: Not that long ago. Yep.

Speaker D: Yeah.

Speaker B: And I uh, haven't logged into a long time. They probably did a recycle and uh, I think I lost the password to it in some system move and couldn't actually log back in.

Speaker A: So I think we've have many of us have lost more emails and access than we may have.

Speaker E: Oh, I have pretty close uh, for so many domains it's not even funny.

Speaker A: Yep.

Speaker E: So yeah, yeah, absolutely.

Speaker A: Well with that we're a little over time. Thanks everyone for listening and watching this edition of Paul Security Weekly. Larry, take us out.

Speaker B: Over and out. Sa.