Hacking Without Boundaries - Michael Jenkins - PSW #946
Get every episode summarized
Each time Security Weekly Podcast Network (Audio) publishes, we email you a written briefing from the transcript — the topics, who appeared, and any specific claims, with the ad reads skipped.
Email me new episodesFree for 3 shows. No card needed.
About this episode
Security Weekly Podcast Network (Audio) is made possible by:
“This week, first up, we talk with threat locker CTO, Michael Jenkins, about threat actors use of AI, and how to keep the bad things out with zero trust. Then in the security news, compiling spreadsheets, because that's why.”From the transcript
First up we talk with Threatlocker CTO Michael Jenkins about threat actors use of AI and keeping the bad things out with Zero Trust. Then in the security news:
- Compiling spreadsheets, because that's why
- Nvidia wants to put AI agents in timeout
- Citrix NetScaler gets exploited again, and again
- Spectre still refuses to die
- Your SBOM is incomplete?
- File notifications leak more than filenames
- ENIAC had cables instead of a BIOS
- Another Linux kernel root exploit lands
- Containers share a kernel
- ThinkNode M9 microSD card gets a virus notice
- Google analyst infiltrates a supply-chain gang
- Your phone speaker can transmit radio
- Reconstructing firmware with a logic analyzer
- Robot dogs learn cybersecurity
- CISA warns about third-party ICS integrators
- Dutch police arrest a ShinyHunters suspect
- A soldier goes from telecom hacking to prison
- AI companies discover their agents have opinions
- Cloudflare containers accidentally share leftovers
- OT networks are still mostly not isolated
- Florida wants to pause ChatGPT
The interview segment is sponsored by ThreatLocker. Visit https://securityweekly.com/threatlocker to learn more about them!
Visit https://www.securityweekly.com/psw for all the latest episodes!
Show Notes: https://securityweekly.com/psw-946
Get every episode summarized
Each time Security Weekly Podcast Network (Audio) publishes, we email you a written briefing from the transcript — the topics, who appeared, and any specific claims, with the ad reads skipped.
Email me new episodesFree for 3 shows. No card needed.
Transcript ready
1,602 searchable segments. Every word is indexed and playable.
Full transcript
Security Weekly Podcast Network (Audio) — Hacking Without Boundaries - Michael Jenkins - PSW #946. Machine-transcribed; use the interactive transcript above to jump the player to any line.
This week, first up, we talk with threat locker CTO, Michael Jenkins, about threat actors use of AI, and how to keep the bad things out with zero trust. Then in the security news, compiling spreadsheets, because that's why. In video wants to put AI agents in time out, Citrix NetScaler gets exploited again and again. Spectre still refuses to die. Your S-bomb is incomplete. Well notifications leak more than file names, and yet had cables instead of a BIOS. In other week, in other Linux LPE, containers share a kernel, a microSD card gets a virus notice, Google Analyst infiltrates a supply chain gang, your phone speaker can transmit radio, reconstructing firmware with a logic analyzer, robot dogs learn cybersecurity. Syso warns about third party ICS integrators, the Dutch police arrest a shiny hunter suspect, a soldier goes from telecom hacking to prison, AI companies discover their agents have opinions,
Cloudflare containers accidentally share leftovers, OT networks are still mostly not isolated, and Florida wants to pause chat GPT. Well that and more on this episode of Paul Securety 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 Securety Weekly. Welcome to our sponsored interview portion of the show. This segment is sponsored by our fine friends at Threat Locker. Please go check them out. I believe it's securityweekly.com forward slash Threat Locker to protect all the things. It really truly is amazing technology to help you thwart the vast number of threats that we see today that we're going to talk about those threat actors specifically using AI today, what that looks like, how it plays out in some of the trends.
And Josh Marpet is here with us from the Securety Weekly side. Josh, welcome. Hey, always fun to talk to Threat Locker. They're awesome people. Absolutely. And with us today is Michael Jenkins. He's the CTO over at Threat Locker. Michael, welcome to the show. Thanks for having me. Michael, give us a little bit about your background. So I've been in cyber security for close to about 15 years now. Before Threat Locker, I used to hunt around somewhere and it was kind of interesting and I enjoyed it, but I got to a point where I wanted to be able to prevent it rather than fix it after the fact. Yeah. It's interesting. Yeah, I'm in a similar event. Josh and I were just talking yesterday. Like I spent a lot of time finding vulnerabilities, exploiting things. And now I'm on the detection side trying to figure out like, how do I stop and prevent that stuff from happening, which I think is a natural, natural progression. I think it's much harder, by the way, to do that on the defender side than the offensive
side. And I'm sure that it's going to be one of the themes that we talk about in our conversation today, right, is doing that detection engineering is it's much harder. You could be accurate. You have to be very accurate. You're not going to find the threat. Whereas a threat actor, they can be wrong a lot and it doesn't really impact them. I think there's something you probably have seen as well, Michael, looking at ransomware, right? Absolutely. A lot of ransomware is just blanket attacks and hope something sticks. And you see them attacking multiple companies and they only need a couple of percent of them to actually stick to actually make them money back. Which is why I think AI is really a great usage by threat actors because we know it's wrong, right? I think there's a lot of still 80% rule. We can get AI to help us get us 80% there. I think it gets better sometimes worse depending on how you're using it. But they have these new tools and technology. Now they always have. And I think we used to think of like MetaSploit as, oh my god, threat actors, they're all
using MetaSploit. And the world's going to end. But they've always adopted new technology. Is AI that much different from adopting a MetaSploit framework where someone's written in the line of the exploits and pillars for you? The biggest difference is it's speeding up the process for them. They're able to use AI to do a lot of reconnaissance and social engineering. And like you said, it can write 80% of it. So you're right, MetaSploit, they had the tools there, but they still had to do all the work. And how they basically have an intern to do it all for them. It is very much like an intern. You're reminding me of the scene from hackers where she's like, you have to do all the scanning and probing. And that was like the medial tasks of someone just getting into the hacking scene. Now AI looked in largely automate the discovery, the scanning, even initial infection. I mean, it's really like a super automation tool for attackers. It's kind of how we're seeing it being used today.
Would you, would you folks agree? Yeah, you know, I'm going to sort of take that one a little bit. And I think that it's more than an assistant. It's more than an intern. Okay. It is, it is a research assistant and an intern and a developer and so it's an entire team. So instead of having to build, God, I'm old. Do you remember back in the 80s, the Warris teams, you'd build an entire team of people that one guy would be a careering and one person would be, you know, cracking and one, you'd build an entire team and it was tough because you had to find the right people who are willing to do it for the right price and have the right skills. Now I have one person and I can have an AI do everything I want and it's my entire team in one shot. Yeah. And so I get that whole team effect with one AI, with a $100 account or building an AI farm in my garage, which I happened to have done.
And, you know, and I get an entire team for less than the cost of even looking for one back then. So it's, it's, it's commoditized, democratized. I don't know what the right word is, Michael. Maybe you have a better idea. I see what you're saying. You're absolutely right. I mean, it is a lot more than just one person. But that 80% accuracy is, is a number that really focuses on because everyone's like, like you say they can get you 80% there. It can do 80% of the workload for you. When it comes to attackers, 80% is enough. So it might actually even be less for them because all they've got to do is say, do this for me, hit 1000 companies, 100,000 companies. They only have to have 10 companies stick and they probably just retire it. Do you find it?
Where is the sophistication level? Is being used more for speed in automation? Or do you see more sophisticated attacks being conducted now because attackers have AI? I personally don't think ransomware and attacks have changed that much over the past 10 years. I think frequency is definitely where they're going and this does make it a lot faster. They don't, they haven't needed to evolve. There's certain bits here and there, but the system still works. They hit, they attack, they lock down, somebody pays. So realistically, once people are still doing that, they're going to just, they just need speed. And I think that's where we're seeing the AI being used the most. It's covering more speed, more ground that getting more people infected and they're making the same. Yeah, it's interesting. We're covering an info stealer, very similar ransomware info stealing.
That's the primary activities, I think, threat attackers or profiting from today. It was a very great attack, but it was nothing really new. They found a driver that was signed, that could bypass every single EDR that was out there. And once they did that, they knew where to look, probably with AI assistants, to go grab all of the credentials and X-FUL trait them and skirt around the EDR. And none of the techniques they had were new. But the campaign was still successful for the attackers, which is interesting. We also need to evolve, right? Maybe they just need threat locker. I think these people didn't have threat locker, Michael. That's the issue. Josh, you're talking with your hands. It was not. Bloody hell, I'm sorry.
Thanks, something really awesome too. I know, it was amazing. You should have heard the profoundness. But Michael, when we have AI-assisted exploitation and post-exploitation, right? And AI-assisted getting in and exploitation, then we have solutions like threat locker, which are, I mean, I categorize them as default and I, right? Does it matter that it's a new volume? Does it matter that it's a new problem? Does it matter that it's a new way of doing things? What's threat locker's track record on catching this stuff? We follow the same process we've always done, zero trust. AI is, even if it's building software, it's building software. It's going to find vulnerabilities. But if the tools that it finds vulnerabilities in are ring fans that are protected and can only have access to what they need to do their jobs, then even if they are breached, you're
limiting what access they have. So that zero trust platform still applies with AI. In fact, it's becoming more important. Because it's not about saying, no, we shouldn't have AI. It's about saying, yes, have AI. And it can do this, this, and this and nothing else. Yeah, I think it's a question that on that. I didn't introduce Mandy. You were having technical difficulties, but you're here now. Thanks for joining us. That's right. You guys were trying to keep me on my toes earlier and it worked. I was already well awake though. So back to what you were saying, I'm curious then like with threat locker detection and you have AI bots, a gentegei that is being deployed. And let's say it lands on a box that is rarely used or really unmanaged like what does threat locker provide in that situation? So the way threat locker works is it's about restricting absolutely everything on your
machine that default deny approach ring venting storage control network control. So even if those boxes aren't used, even if something gets on it, it's going to be very limited in what it can do. It can only do what you've told it to do. And then obviously you get your detection telling you there's something's on there that's not doing what it should be doing or it's trying to do something else. So we're actually finding that when people are using these tools, they're able to identify problems where they may have left a box out on the edge that's been breached. But the rest of their machines are still protected because they're still following that zero trust. And it's not just about computers as well as our trust is in every aspect. We do it with users, we do it with programs. It's a mentality that once embraced, it does make you more secure in every aspect of your business.
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 has 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. CYC so is our adopting it at securityweekly.com forward slash threat locker. Yeah, it's interesting. There's still have whether they're using AI or not, they still have to do basic things. They have to somehow gain a foothold on a system. They have to execute a process. The persistence is where we typically would catch them. If they're trying to persist on the box, they have to put something on that box that stays there that is detectable most often in many different scenarios.
And they also have to pivot the attack. Michael, you mentioned if you hang your network, we love talking about network edge devices, they get compromised. It's all the rage these days that these systems that were intended to protect us and become the initial foothold, but they're pivoting from there. And so I think the zero trust model really helps with this scenario. It's not looking for a specific thing that changes. I love all these IOCs. And recently, there was a vendor that made the IOCs only available to their customers. And I'm like, okay, but what about the rest of us? Like that'd be nice to know. Also, a lot of those IOCs are very low value. And what makes them low value is the ease at which the attackers can change them. So if their IP addresses, if they're domain names or their file hashes, once they're published, and look, even if they're not published, if the threat actors campaign, if the threaters
thinks their campaign has been impacted anyway, they're just going to change their IOCs. How easy is it to change an IP host name or just change some bits in your file and get a new hash? That's not really an effective way to hunt. We have to hunt and protect our systems based on behavior. Knowing that attackers are going to have those behaviors, regardless of how sophisticated it is, they're going to exhibit some behaviors that threat locker has been great at describing all those scenarios. And we like, look, yeah, we catch that, right? You're spawning another process. You're pivoting to another system. All of those are behaviors that I think what you folks have really nailed is, knowing good versus bad behavior, smuggle. How do you do that so well? We don't. Good versus bad doesn't mean much to us. To us, everything is risky. So we take the store with everything's bad.
Pretty much. It's not about lowering on good or bad. It's needed or not needed. And that's the approach to differs because when you're looking for bad, all an attack has to do is phone you up and pretend to be from a help desk support and give you remote access software. Good software. And that's the thing. It's not good or bad. It's needed, not needed. And if it's not needed, don't let it. So okay, so the way it stopped. Let me ask you a question because this is a valid point. I have a help desk and they use remote connection software, right? I have a malicious actor and they use remote connection software. In one sense, it's needed and in other sense, it's not needed, right? So how does threat locker distinguish between the two? Yeah, that was my question too. Sorry, sorry, I'm sorry. Sorry, I'm saying. It was like, no, same thing. It was just that continuing on that and I'm so curious, Michael, because it is like, okay, so let's say you get one bad approval, then is it that there's still continuous
monitoring from threat lockers, capabilities that even that one bad approval doesn't just become, hey, well, here's a whole system wide situation for ransomware. Yeah, if something does go wrong, you've obviously got to tech telling you automated policies as well. For example, if I try and do something like trying to even stop threat locker on my machine, all of my admin tools get locked down within a second. So I don't have command prompt, I don't have power shell. You can put these policies in, you can be as strict or as loose as you want with them. And as for the remote access software, there is dozens of remote access software. Your help desk system uses one. It's the only one that's allowed. So you've already removed a massive area of attack there because you're only allowing one. So now the attacker has to be using the same one as you. And then you've added some ring venting to it. Okay, so the hacker can get on the machine. But they can't pull data from it because your remote access software doesn't need access
to those files. So you've locked it down so it can't do stuff. So even if it is breached, even if they're logged into your systems and accessing. So long as you're restricting to only giving access that is needed, then even if you give the hackers access to your machine, they're still restricted on what they can do, what damage they can do. And the biggest thing is when somebody wants to attack a system, they want one system to get a foothold on. And as you mentioned before, pivot, they need to get onto other systems. One system's not enough. If you restrict that capability of being able to spread, all they've got is one system. And even then they can't touch the files because they don't need to. Yeah, I actually love that. I never really consider that remote administration. You just need to administer the box. You don't need access to all the data on the box. You need administration. And that's separate from data, which is interesting.
To do that on that granular level is pretty amazing when it comes to zero trust, right? Zero trust does push past, like I said, programs. You shouldn't trust your IT companies to do anything more than they need to do. You put the restrictions in on IT admins. You put restrictions in on users. And then when someone in the finance department clicks on a link or puts in their passwords online because they've got phished, it won't matter. You're protecting from your devices. You're saying, okay, well, here's my username. Here's my password. Here's my MFA. Oh, you still can't access it because you're not coming from my device. So it's zero trust spreads every aspect and has to. Have your customers look at, I want to talk about it. A different aspect. As I know, many of us, myself included, we're all talking about how we're going to use AI in our organizations and how that's kind of been evolving over time very rapidly, obviously.
So we have a lot of conversations about which frontier models do we use for which purpose? And now entering the conversation more and more, which local models do we use? Where do we run them? How do we protect them? And the thing I'm concerned about is we treat local models actually with a little better security than frontier models. Like, oh, it's a local model. I can give it all my research, my source code. And that's tough because it's not hosted in someone else's cloud. I'm hosting it locally. How does thread actor, thread locker rather? It helps us apply the zero trust to our various AI models, especially local ones. I am seeing a lot about people lately where they're putting in the gun. Let's give it everything. To me, AI is a tool.
It is something you can use. It's a very powerful tool. If I hired a new member of staff who was as fast and efficient as AI, on day one, I wouldn't be giving them access to every piece of source code, every piece of financial data, every API I have access to. And that's where people have to remember when they're setting up these AI's. Yeah, it's very easy to give it access to everything, but that's not zero trust. Zero trust is give it access to what it needs. And that's where I'm trying. I'm not trying to tell companies don't use AI. I'm more focused on use it, absolutely use it. Because if you're not allowing it in your company, people are going to use it anyway. They're just going to use unmonitored, unmanaged versions of it. But restrict it. Don't give it access to everything in your company. Don't allow it that one person can send a prompt, be it intentionally or accidental, that can take your source code, change it and alter it and wipe out your accounts.
Wait, wait, wait, junior, junior personnel should not do that. They don't get that. That's what I was kidding. Are you kidding me? I thought they were supposed to play in there. Isn't that just like? Yeah, but I think a very common policy is other than your one, maybe one account that you're super admin account on your source code repository, everyone else, regardless of what level they have, can't remove anything. They can't delete a repository. That's typically a safe card that everyone puts in place to make sure whether on-purpose or accidental, like you're not deleting source code. I'll be honest, deleting source code to me is less terrifying than somebody altering source code. Yeah, no, 100% agree. 100% agree. Yeah. Especially as these models get more advanced. I think more about backdoors. The models are going to start putting their own backdoors inside of things. We really have to be diligent about monitoring what AI is doing, especially, again, these
local models that people are giving them a lot of privilege. I think it comes down to the same as any developer. A developer writes code that don't get to push it into production. It gets reviewed by someone else. Yeah. If AI is writing code, it should be reviewed by somebody else. That's the point. We can't treat it like this all wonderful thing that's going to solve every problem. We should treat it like a tool. Look, look, look. If you don't want to sprinkle the magic pixie dust on, that's fine. But don't yell at us that do, okay? Peer review is old and outdated. We don't do peer review anymore. This is how we make sure mistakes happen. I used the AI to review the AI source code. Now, Josh just, he has got new age. Now, he just takes crystals and rubs it across the code and is like, yeah, it's all good here. Yeah. So, okay. So, to be honest, in all honesty, I do want to bring up. Go ahead, Josh. Really quick. You can use AI to review AI code to a certain extent because you can use different models
to review code. That's possible. That's a great first filter. Don't get me wrong. But you do need to have a solid, if you want to call it peer review, that's fine. You need to have a solid peer review session where code that's turned out by a developer, gets reviewed by a developer, code that gets turned out by an AI developer, gets reviewed by a developer, whether AI or human. But you have to have all code reviewed. I don't care who writes it. So, my 100% agreed. Go ahead, Wendy. I'm sorry. Well, I mean, first off, Michael, I, because I adore the technical side, right? And a lot of our audience does too. And I know you have an overabundance of information, I'm sure. So, going back to July, I think it was amazing that Threat Locker got the series of, there was $190 million funding, right? And from what I read on it, it was very specific, more to AI, to malicious AI, to agentic AI. And so, in a very simple way, I've thought of it as like, well, fine, approved things are handled through ring fencing.
Unapproved things are handled through allowing. Would that be correct? And so, I'd really like to know like a technical thing you've seen in the field of people using like a specific agent. I don't care if it's co-pilot, whatever. A local one like Paul was bringing up. Can you bring together more of this because this is such a huge and brilliant forward motion that Threat Locker is bringing to the very stressed out teams in the field? The most common thing that I seem to be seeing at the moment is everyone is now a developer. It doesn't matter what their job was before. It's, oh, look, I've just wrote this tool that's going to make my life really easy. And that's where people have to be careful. It's software still has to be vetted. And that's where the allow listing comes in. But the amount of people I see now who had never thought about opening codes, who are now going, oh, well, I looked at it and this program is going to solve all our problems.
And everyone is guilty of it. They just, they get it and they get AI. It's like, oh, I have this. And they're like, well, you could write this. It's like, oh, can you build me? And then suddenly you've got an executable that's being ran that's written by AI. And AI is still not there. 80%. And I find it hilarious to trust somebody to write code that can't spell the days of the week. But you have to be really good at writing requirements. You get much better AI generated code, the better requirements that you give it. Absolutely. And the more you use it as well. Yeah. And also, I like to have it ask me questions. So I'll develop, I'll define requirements and then it'll start building a plan. And then like lately, I'm like, all right, each phase of that plan, I want you to ask me questions that will help shape the direction that you go in. And actually the larger models like GPT-6 Astra will ask me like four questions on each phase
to shape what it was doing. And then you get much better outcomes. Not to say that you get bug free code or vulnerability free code from that. But I think you get much better outcomes doing it that way. But to address your concern, Michael, someone who just prompts and goes, Hey, can you just go build me a tool that does this? The model is going to take a lot of liberties in what it builds. And that might not be what you want. And that could be something that is potentially dangerous in your environment. I think was your point, right? Yeah. And I think what you've just described is exactly what I was trying to get at. It's a tool. You use correctly. You're going to get what you need from it. Use by everyone for everything you're going to get a mess. It's we've had it's not like shadow ITs and new thing. And people have been trying to do their own IT for years. And putting programs on going, oh, look, I've got this. And the amount of times years ago I'd go onto a system. It's like, why is it running slow? Well, you have six antiviruses. Like, oh, well, I heard antiviruses stop for viruses.
I'm like, yes, but not that many. And it's just the same now. They're like, oh, how can this now help me? And they are writing code. But that's where the allowance comes in. They're writing this code. They execute it. It's blocked. And somebody can actually speak to them and be like, this is how you should be using it. And it all comes down to education. Educate someone how to use the tool effectively. And AI won't fast forward the business. Use it incorrectly. And you're just going to have a bunch of people wasting their day, building things that they don't need to. Like, I find that CTOs are usually very excited about technology. There's a quality I find in most CTOs. Is there a technology that has you particularly excited? There could be something you're building or something you're thinking about? I am not different to that. I am absolutely excited about most technology that comes out.
I've since I've been at ThreatLuckera, it has definitely turned more into me seeing the dangers of technology and how it's misused. So I'm more cautious than I used to be. But AI doing code reviews, like Josh mentioned earlier, that to me is exciting. Not because it replaces people, because it helps them more efficient. When remote access software came out, an IT person went from doing one ticket a day to 100. AI can do the same thing. It can make people more efficient. So those code reviews and integrating into that does excite me. I love the concept of AI making people more efficient and faster at what they do. I typically turn, I've talked about this on the show before, I turn different models loose on my code. I'll just tell it, go find all the bugs.
And it'll find a bunch of bugs. Then I'll use a frontier model. Go validate all those bugs. In having those LLMs, various ones looking at your code and constantly improving it, it is like I have assistance helping me improve the quality of my code as I go. I share your enthusiasm, Michael. I think in terms of AI, you fit the nail on the head of a really great use case that ultimately leads to better quality software. One of the reasons why we have cybersecurity is because we have very poor quality software that has vulnerabilities. We're not promoting that idea for job safety for cybersecurity people. We want better quality software and I think AI does help us get there. So that's awesome. Michael, thank you very much for appearing on the show today. Thank you. Have a May. Again, visit securityweekly.com forward slash a threat locker.
Josh Mendy, thanks for joining us today as well. Thanks everyone for tuning in to the interview. Coming to you from the hacker syndicate studios. This is Paul Security Weekly. It is episode number 946 being recorded on Wednesday, September 30th, 2026. I'm Paul Sardorian, joined by Mr. Josh Marpex. Josh, welcome. Hey, let's talk S-bombs. I knew that S-bombs story was going to fire you up. Me too. Me too. Mr. Larry Pesci is here with us Larry, welcome. Yeah, thanks. Before we get too far, I will have an announcement a little bit later tonight. But not wait a second. You do it when you're ready. It's fine. You're good. Mr. Sam Bounce here with us. Sam, welcome. Good evening, Paul. What was that AI thing you're talking about? I don't know. I mean, we're not calling it AI. It's actually using AI anymore. We're not doing it anymore.
Check it if order, dude, it's Shesha I know. Super intelligence. Super intelligence. I still think it's artificial. Someone who's not artificial, Mr. Lee Neely is here with us. I am not. And I figure, I will have an opinion when I program it once. But you know what, I'm just I'm weird. I won't even call it SI yet. That's right. I'm still calling it AI. To pour me if you will. A couple of announcements before we dig into it if your threat model still says hackers break in. You're about five years behind. They're logging in with stolen creds, abusing cloud identities, automating recon, and turning AI into a force multiplier. Meanwhile, you've got a vulnerability backlog that's older than some of your interns. If you're defending financial infrastructure, this one is worth your time. Join us on October 14th for the FinSec virtual summit here, how practitioners prioritize the threats. It actually matter and defend modern financial environments without chasing every shiny new security product.
You can register for free as a security weekly listener at securityweekly.com. Forward slash FinSec use the discount code CSS26-sw. InfoSec World is coming up soon. It's a fresh experience for 2026 new voices, a new venue, and new topics that reflect the challenges security teams face today. Join practitioners in leading professionals from across industries in Orlando, October 12th through the 14th. listeners can save 30% on their pass with the code ISW26-sw.savings at securityweekly.com. Forward slash InfoSec World 2026. All that is in the show notes. Case you missed it. So go there. Josh wants to talk as bombs. We want to start with as bombs. Do the stuff. What story? No. No. No. No. Larry. No. What? What? One more announcement. So this is being recorded on a Wednesday and technically
I'm off on Friday. So that would make tomorrow my last day at FinSec State. Oh. Oh really? I... This is my shock-pretend shock face. Pretend shock face. Yeah. Okay then Paul. Secret among us are really a thing in this trusted circle we have. Yeah. So if it's your pretend shock face Paul, where am I going? You know if I had to hand basket, swirl my scotch around, hold my cigar. What does the magic ball just got to say? I want to say you're going to work for a company owned by a guy named Kevin that has very secure ideas. You're going to work around a Florida? How did I guess? Yep. Yep. Yeah no. So I start on Monday it's secure ideas working for Kevin. Oh. Mr. Kevin Jackman. Thanks. Congratulations. Congratulations.
I'm so happy for both of you. It's coming to you. You realize Kevin is going to have like a list of stuff for you to do and you're just going to like look at the list and start giggling. I'm fairly short. And the sad part is I have a list of stuff that I've already given myself to do. That's great man. Yep. I'm happy for you. Thanks. It'll be a good one. Yeah. Oh she gets on with Jeff Man. Oh I do. I do. And the crazy part is that one of my roles is going to be bringing AI more into the company. I think I'm going to have to make a slack channel just for Jeff so he can ask me to use the AI for him. Like I know he's right. But actually the exception to the policy. Everyone should use this AI skill except the exception is always Jeff. Jeff. Yep. Except Jeff because he can just use this channel which we'll use it indirectly for him because he thinks he's going to be asking me to do it but it's going to do it. He'll be really asking an AI agent.
He got a slack MCP so it just does the job. Hi this is from Larry not an AI. Give me it. Yep. Yep. So yeah I'm going to be executive director of research for Mr. Ticket. It's going to be a load of fun. Congrats. Yeah. It's an awesome incredible man. You're going to have so much fun. Yeah. All right moving on with the rest of the show. The show's not all about me. It's about us. I think the headline, the caught people's attention and it's a very sensational headline. Your S-bomb is fan fiction. I know Josh is already in Alan Friedman if you're listening. I know it's a very sensational headline. It came from this project called yeet.cx. Have you guys ever heard of this? No. It actually looks pretty cool. It is a Linux tool. So it has my vote. But yeet is like a collection of data from your Linux system
and it lets you collect all these various things. I kind of like it like almost like a threat hunting tool. One of the things I'm working on is like a threat hunting. I mean, that's my day. That's my day every day. At work is thinking about reading about Linux threats, thinking about Linux threats, how they materialize on generic, general or generic Linux systems, where Linux is underneath and a lot of our network appliances. How do we analyze Linux systems for anomalies? This looks like a pretty cool way to do it. I've not tested it yet. But it looks like you can kind of build these little apps that pull from these pockets of information. Like slash proc is a gold mine. We call it at our day job, gold mine of information. And what the gist of the article is, is that you can build software.
You can generate an s-bomb for that software. But that software is going to run somewhere and have runtime dependencies. And those runtime dependencies could contain vulnerabilities or supply chain attacks that is not covered necessarily in the s-bomb. So for example, like if you really want to dig into Linux, you can look in slash proc, slash the PID process ID, slash. And then there's like a whole bunch of information in there. And like I apologize to Linux people that have been using it for years. This is like not new stuff. But you know, one of the things in that directory, it might be called map. Is it called map? Maps, I believe. Gives you like all of the dependencies, libraries and everything that it's running. Right, you can also look at PS and get child processes and things like that. And this person's argument, Josh, is that that's not covered necessarily in the s-bomb.
That inside of its running environment, it can be calling OpenSSL library that you've upgraded. But you never restarted the process. Therefore, it's still running with a vulnerable OpenSSL library. Right. So yeah. You know, my commentary, I think, is kind of along this line. Like, yeah, great headline. It's kind of unfair to s-bombs, in my opinion, you know, for all of these dimensions. Considering that they're told to build an s-bomb. It's kind of unfair to s-bombs, yes. Yeah, yeah. They're not saying s-bombs. But also on the flip side, I think it's kind of a great point that, you know, what's running and associated with your application is not always all in your s-bomb. Right. We need to recognize that limitation of those environmental factors. Right, Josh, sorry. Go ahead. No, I think, I mean, they're writing s-bombs. They're building s-bombs. They're even throwing vex on top of it. So they're not upset with s-bombs. Yeah. They're upset without s-bombs are generated. And they're generated on the program, the source code, the data.
Yeah, well, they're generated on the source code that runs in a perfect world. They're not generated on the machine. The actual punk-a-metal or virtual that's sitting in front of you, you know, data center somewhere, which has certain, not prerequisites. What's the word? It's sort of sort of leftovers. It's they haven't cleaned the oven. They've just thrown the new cake batter into something that's full of God knows what you baked in it last week. Right. And it's going to make your cake taste like salami. Okay. Okay. I know you like a good salami cake, Josh. Come on, who doesn't? So, you know, a little mustard life is good, but, you know, I'm a red velvet salami cake. Sounds delicious, actually. I mean, until you got to the red velvet with the salami, not so much. Any one. Can I say? But I mean, the point is, is that they're right. And I can respect that. Now, it's they haven't done anything in a significantly large amount. They've got a handful of examples. But it's really, really, really nice. And it's interesting that we're starting to see these,
these sort of runtime tools like Yeet Kitt, Jeff, if you're familiar with Jeff. And my very own beacon score, which is not runtime, but the collector that we built that's not out yet is a runtime evidence collector. We're starting to see if you don't have it collecting the evidence at runtime. When it's really there, not a blueprint, not a diagram, not a cake batter. When you really are there, it's not good enough. Right. But, you know, but a lot of tools are great at like if you're doing incident response. And I kind of want to tease out what we were talking about on Slack earlier. Larry. But when like you're doing incident response, these tools are helpful. Like you're basically shining the spotlight on your system and looking for things. But you only tend to do that at that level with these type of tools when there is evidence of
an incident. Right. We have a reason to. The real trick is to be analyzing our Linux systems in this case on an ongoing basis in doing that. Right. And so Fetal, the tool I built actually has some of this telemetry in it as well. And I did that not to get feature bloat. But because I was like, well, every day when I sit down at my workstation, I'm going to first thing I do every morning actually is I update all my packages. Right. And I wrote Fetal for me. If other people want to use it, it's great. But like I wrote it for me to automate all the things that like I want to do every morning. Right. So your default set of actions is something that I want to do every day. And I want to automate that. Right. So I'm like, you know, before I update packages, I want to clean my package cache. Because that tends to be problematic. I want to update all of my repositories in all the metadata about packages.
Because if I don't, that tends to be problematic. I want to identify if a package I'm about to install maybe contain some malicious scripts for activity. Right. And I want to automate that as best I can. I also have it checking for indicators to compromise. And because it's a script I run every day, like, yeah, like go check that. Tell me if like something's weird on my system. And I think it's really why I built Fetal, right. Was to just tell me about things that are weird, right. And not everything runs default every day. And I can run different commands to get better telemetry. But I want to know about weird shit on my system. And I think we need to, as is evidence by how attackers are gaining persistence and access to Linux systems today. We're not doing a great job of looking for the weird shit on an ongoing basis on our Linux systems. Because if we did, the Citrix bleed attack, the latest net scalar thing, we would have found that.
I'll give you an example. My story number seven, ironically, right below that. Yeah. Yeah. So, actually, I have a couple of examples. So this is my first one. We can get these really quick. Watchtower analyzes that pre-auth the DTLS memory overflow. Turns out DTLS is TLS over UDP. Weird, okay. I'll allow it. If there was an RFC and we implemented it, okay. Okay, I'll allow it. But has basically memory corruption overflow. Now, the thing that jumped out is at me. Couple of things jumped out. One, there were some protections and getting F5 in Citrix net scalar kind of confused. But there were some protections, stat canaries, ASLR, those kind of things. However, there was no PIE compiled into those binaries.
I believe both the F5 and the net scalar had this problem. And it's interesting when I prompted one of my AIs. I just happened to just search for PIE. And because I gave it some context that I'm a cybersecurity researcher, it was like, I don't think you're talking about the PIE that you eat. I think you're talking about position independent executable. I'm like, yeah, yeah, yeah, yeah. Because I forget what all these compiler, I don't keep the memory of what all these compiler flags mean. But position independent executable means it's a binary built, it's a compiler flag to build a binary that allows it to run in different memory locations. And accounts for that so that when you use ASLR and it randomizes where your memory is mapped, the binary can handle that. In both these cases, PIE was not compiled into the binary. And I'm like, why? Why is that? Now, AI did some brainstorming and said, you know, maybe it's performance compatibility or the appliance build process.
Those are feasible that I don't actually know why. Developers leave this out. Maybe if you're a developer and you're leaving it out, there's a good reason. I'd love to know what that is. So that was left out, which basically enabled them to weaponize and exploit against Citrix net scalar. And so back to back to back to Fetal and Linux tools. So there is a one sec. So there's a utility called checkseq. Checkseq will analyze your binaries and tell you what compiler flags you have and which ones don't have which security things. And actually I built into Fetal, kind of like this analysis system that kind of brings the ones up to the top that were compiled with the least amount of security flags. So at least you know what those binaries are. And maybe I'm like, well, that's part of a package that do I really need that package? Like I've been using the same build on my workstation knock on wood for years now.
And I might have installed a utility that I'm like, oh, I don't need that anymore. Like I can move that to a VM or whatever. And so you want to know. And so again, this kind of talks to part of my French. But like I'm just looking for weird shit. Like tell me about the binary that has like no security compiler flags. Like maybe that's something I need to pay attention to this morning when I'm looking at my system. Yep. And you know, Paul, I think, you know, despite it being my technically last day tomorrow, I think that's one of the things that where finite state has really changed the the S bomb game in my opinion. Is doing it way better than a whole bunch of other folks. Aside from doing a whole bunch of other S bomb stuff, isn't that? They can create an S bomb from like the package manifests and all that crap. But where it really excels and you get what this thing that you're talking about and that where this article was like, oh my god, S bomb sucked because they don't work right. Is through that final binary that you deliver to your customer, you take that collection of binaries, you take your ISO image, you take your Docker container, you take your firmware,
you take your application. And finite state does a binary tear down of all of the components, all of the linked components, and will make that accurate inventory of the thing you're actually shipping. Sure. And binary analysis is awesome. And you know, we do it at Eclipseium, finite state does it, reversing labs, does it binary analysis is awesome. And it's again, like speaks to kind of like, I'm going to look for the weird shit. Yeah. And if there's a bunch of weird shit, I'm like, hmm, I mean, I need to do change my strategy there. And even with that binary analysis, like it can tell you what types of acompirophags were used for PIE and all that type of stuff. The other one that they're doing too is, you know, some folks that are in that game are calling it reachability. And it's like looking at startup scripts to see if things are started up. But what real reachability means is like, hey, we've got an application and it calls out to,
you know, open SSL. And there's a vulnerability in open SSL in this specific function. But your application never calls those vulnerable functions. So this is not a vulnerability you need to send to your engineers and resolve. Until the time when you upload a new version of firmware and they've added functionality, that does actually call it and then it would flag it. Yeah. So yeah, that's, I mean, that's the way to do it really. Name of the game, man, finding weird shit. You know, I mean, yeah, Lee had his finger up there. So yeah, so the thing that's the thing, sorry, I think Josh had something to it. The thing that the, I mean, we talked, I mean, we've talked a lot about, you know, measuring the, the, the blob you're shipping. But briefly a few minutes ago, we were talking about the fact that the system is deployed on is also in the equation of, of S-bond dependencies. And that's, that's on the, that's on the company or the user side. I mean, you can't providing a process software or say, you know,
make sure you've updated and applied patches. Right? I mean, isn't, so I'm just saying, even with an ideal S-bomb, you still got skin in a game where the customer can screw it up. Or is there actually a solution for that? Aside from say, patch all the things all the time. Yeah, we all know that's not a reality. Yeah, I picked something arbitrarily, absolutely, you know, unnecessarily. Well, I can't even think of the right word. I just made a silly example. Hopefully not triggering Josh too hard. Yeah, one of the other, I don't know if I included the F-5 one in here, but there was more on the net scalar thing. I just found this today. I should have seen it yesterday, but just a round out the, the Citrix net scalar thing, which we didn't see up very well. It was something like six or seven CVEs, two, I think are actively being exploited. One of the CVEs is like the features on by default.
So like if you're running that version, you're vulnerable. And the rest of them require that a feature be enabled. The DTLS is actually enabled if you're using the VPN functionality on it. The other ones do require that you're using certain features or configuration in order to be vulnerable. And up until I believe it was yesterday, I didn't have a good beat on. So once Thread Actors were exploding this, because by the way, like we knew Thread Actors were exploding this, I think even before the patches were released, I was like, what are Thread Actors doing? Can anyone give me telemetry about like payloads, what they're, what they're dropping? And it wasn't until I believe yesterday that Mandiant's Google Thread Intelligence Group, what is that what they call them? It's Mandiant basically issued a report. And we were like detailed what Thread Actors are doing on the boxes. And I haven't gone through all of it. But when I started going through it,
one of the things that they do, apparently you get root once you exploit the process. But then if you try and spawn a root shell after that, the process denies it. So what they do is in the initial call, they put the set UID bit for root on slash bin SH. So that they can still call it as a root shell in subsequent calls, because they change the set UID bit. And I'm like, if there's one thing that should trigger like most solutions that are looking at Linux, even a lot of the open source ones like AID and there's a bunch on GitHub that older ones that I even forget existed. If one of your shells has the set UID bit set, that's just sort of all kinds of red flags. Like that is like basically just handing out root to anyone who's on the system. You don't need LPE, you don't need a fancy exploit, like the new Spectra one that we'll talk about too.
You just need the shell. So I thought that was, again, speaking to the sophistication of what Fred Actors are doing on these devices that run Linux under the covers, I'm like, this is stuff, again, like 30 years ago when probably all of us were learning Unix, I think all of us touched Unix 30 years ago, which speaks to how old we are. And we read up on like, well, how should I do it in a response? How should I harden my system? There was stuff in there about set UID bits 30 years ago. Here we go 30 years later, talking about Fred Actors abusing it still. It just, oh, God. What's old is new again. You know, I got to tell you, Paul, I love your line in this story. This is another reminder that hardened security appliance does not mean immune to memory corruption. Yeah. I really, like, I've been giggling about that for the last 10 minutes, not joking.
On F5, I don't know why I didn't include here, but on F5, dude, they bypassed ASLR and SE Linux. Because no jokes, seriously, when a process crashes on this particular F5 big IP device, it executes a shell script, I believe. And what they did was they just put malicious stuff in that shell script and then crash the process. And that got around the SE Linux stuff. ASLR, I think they had to do something different, but like not all the memory protections, not all the stack, all that stuff was in place. Which is interesting that we have these Linux primitives that are supposed to make this stuff more difficult. But if you don't configure them all correctly, if you don't compile everything correctly, it leaves these little gaps and even in public write-ups, watchtower and others are talking, it was a thing, it was watchtower that wrote up both of them. They're just getting around it. It's crazy. Which I guess in an appliance, you don't have,
you can't control that as much, because the vendor controls the underlying operating system. But even a regular Linux distribution, if you start going crazy with SE Linux and also stuff might break, and breaking his operational risk is real. So that's where we are. You know, it's, I think the biggest thing here is nothing is safe. It's really that simple, nothing is safe. There is unbelievable amounts of problems and oversights at a hard-and-security appliance. That line just kills me, man. I cannot stop reading it. I don't know why I just cannot stop reading it. Look, it doesn't matter if it's got a cool case, it's a yellow, google thing, or it's a purple, extreme networks, or whatever. If you don't do the basics, if you don't put in all of the different things, no PIE, no RELAR on the stack, and it like, come on.
Yeah, it is a good point. These are not hard-and-security appliances. It's interesting. I was building some stuff for sales. And just building a chart of all the big network appliance vendors, as the column headings at the top. And then major vulnerabilities, major malware, major thread actors, and especially the context I have with some of my AI sessions, like I was able to fill in that table with just an AI query and validate it. I'm like, yep, Arcane Door Check, yep, Tiny Shell on Juniper Check, yep, F5. All of them have these major vulnerabilities, multiple of them. And they also have malware and techniques that are documented as to how attackers are getting a foothold and conducting operations. And there are thread actor groups that we can attribute to attacking this infrastructure. Now it's like one AI query that just built that for me. And it was pretty accurate. And I'm like, you know, this is
a ripe attack surface still. And it's still unfolding as a ripe attack surface. And these appliances I, in my point, is Josh. These appliances are not hardened. Like it was what history tells us. Hopefully newer versions are better. I do want to say like newer versions of Fortinet are better. So there's, I think it was Lee was talking like something to be said for keeping up with patches. I know a lot of large enterprises love that N minus one. This is a case where your network edge appliances. You might want to reconsider that strategy and not do N minus one. You might want to do the bleeding edge. And I get it bleeding edge has its issues. But I think you're going to get a better a more hardened stack potentially. Do you do? Okay, let me ask you a question. Just to cure, I'll see a question. Do you think we can build something hardened enough that it is significantly more difficult for someone to break in?
I think it's too thin. I think it's too things, Josh. I think one, we do need to get better in hardening this attack surface on Linux based appliances, Linux based systems. Second thing is we need to build in better visibility and monitoring. We need to have some mechanism to give us that visibility. Now, nothing's perfect, right? If an attacker is in your kernel, they can make the system lie about everything. There are lots of checks and balances you can do to figure out if they lie in all the right places, in all of the places. But when an attacker gets inside your kernel, it's going to be super hard to detect on the system itself. There are other behaviors that could exhibit that are indicative of a compromise. But I think those two things, and I think today, those two things we do very poorly. I think we harden in our Linux appliances well enough, and we certainly don't have the visibility. That's why attackers are praying on it. They're like, oh, right, attack surface, not as much memory protections we have in a lot of other operating systems,
even Linux running on a server, right? Low visibility. That's why attackers don't even need a zero day. My other stuff, I need a zero day. The new patch comes out. We patched if we read an exploit. Again, we're just changing the SUID bit on a shell. This is not rocket science. Paul, I'd argue that though, in that hardening list, some of the things we keep coming back in, it's not even Linux specific, is that things like manage your interfaces, whether it's SSH or something more sophisticated, should not be available as an Internet entry point. Use your VPN, your tail scale to get into the login interface. By the way, let's make the login phishing resistant, not a password. There's certainly things you can do to reduce your attack surface. By the way, your monitoring also comes up as a thing that people just overlook. They don't
configure and set it up so that it's going somewhere separate where you can actually do, I don't know, more than the whatever is on the box analysis. They can leave. Are you saying that people don't monitor continuously all of their systems and runtime processes? Are you saying that they don't have absolute real-time knowledge of what's going on in their environments? I'm not sure. I know. Isn't that crazy? The appliance said it was hardened out of the box. What can I say, Josh? They meant the shell is steel. It's hardened steel. That is legit hardened. It's like Swiss-fricken cheese, man. Ethernet cable ran through a box. Isn't that making a firewall? I got him. I'll live and set it on fire. No, seriously, these things keep coming up. I was going to say part of the Net Scalar diagnostic. Looking for IOCs is to make sure you've got some offline logs to look at
because odds are you need 30 days and those things don't have 30 days of logs on them just to reinforce the point. I'm sorry, I have to say this. If you actually set them on fire, they are secure afterwards. That is true. That is very true. Yeah, I mean, tie it up. It becomes a solid, fused piece. Guaranteed and not be hackable. Well, if maybe you've got an axe, you could hack off a piece. I know. That's not what you meant. Oh, man. We are just so down the garden path. Paul, save us. Larry, you had one story in there that really caught my eye as your story number five. Which one was my story number five? Reconstructing device from where from spy reads. Oh, yeah. That is wild. Wrong board is wrong board is awesome, by the way. Yeah. I actually follow that person's GitHub. GitHub, Chris, I got an RSS feed. I think for all the changes
to the various repositories. I actually follow that because that person does really interesting stuff. Yeah, so this one was a different one because doing the hardware hacking and all that type of stuff, you need firmware. If you can't get it from the website or you can't pull it off the wire or the wire was just the case, maybe. The typical result was, hey, well, let's go pull the SPI flash chip off the board, put it in a reader, use some tools to do it, and if you and I have done this both independently and together, which was so much fun. And if you're not pulling it off the board, you have to pull like the power lead. So you're not powering the board back up. You're just power, uh, powering the chip itself. So you can do it partially off the board. Which is hope that you send it the right the expected amount of voltage. So we always start the lowest one and then go up magic smoke. Yep. Yeah, but this one was kind of fascinating. So instead of like having to do that, you could just put your clip on and do
it the device up. And while the device is booting and accessing, you are capturing all of the SPI reads during the access to the file system. What? Well, you just use the device and it captures all the files from the file system. What? Uh huh. Are those bits getting loaded into memory? But the article also said the CPU was accessing them. Yeah. So I mean, it's obviously reading the bootloader and all that type of stuff. And um, I like the bits from the SPI flash chip that represent the bootloader are going across the spy bus. Yep. And you're capturing it and reconstructing the SPI flash image from that. Yeah. Because they said in the article, like you're really going to get with the CPU request. You don't get a full, uh, you might miss some stuff. But what you get is he said that the uh been, he was get it loaded into bin walk. Like you get a, uh,
five five times, you can analyze bin walk. I mean, that's pretty. Yeah. Yeah. Now the trick, the trick that was the problem that he had there or I think he's still still working with is that it sounds like the kernel will load the final, the file system into memory or at least portions of it. Um, but he was missing all of that as part of his initial capturing tools. Because what will happen is that the kernel will kick into quad SPI. So instead of using single data line SPI for bootloader mode, it basically double does four channels of SPI. And if you're not monitoring all four channels and reconstructing all four channels into, yeah, interleaving them, then it's, it's missing a whole bunch. So did, did we switch from attempting to extract information out of this by to effectively making a network tap for. For cap pretty much. Okay. Yeah. That's kind of cool. And, and, and kid is, I also thought I
caught in there. He said he could use scapey to do some of those analysis. It was I being reading hopefully optimistic or is that really it was that really a thing. Yep. Uh, let's see, decoding it with scapey. That's, that's one of the ones there. Um, but because it's effective, the SPI data is effectively a network packet of some variety. Skipe can do decoding and construction of SPI data. Oh, I see. So he wrote a module for scapey to deconstruct the supply. I think it's, I think it's already, I think it's already there or it was already, it was already written. I got this is freaking cool. Yeah. Yeah. Yeah. Yeah. Need stuff. Need stuff. And you're not going to release magic blue spoke. Yep. Yep. Yeah. So this is, this is a, this is an interesting one for, for some of the, uh, part of the reason why I threw this in here because it's some interesting, interesting research for, um, you know, pen testing IoT devices where in fact, maybe you don't have access to firmware, but you say, you may want to do this in a lot more automated fashion, plug something
in and walk away and have say, AI do a lot more research for you and not have to take a chip off of the board. Yeah. Or you only have one of them. You know, my coworker Mickey always tells me by two or three of what you're testing. Or if it's a customer engagement, you request more than one, four, right? Three, four. Yeah. Um, but sometimes these devices are super expensive or really hard to get and you could only get one. Yeah. When you only have that one, you're like, oh, God. I'm like, putting heat on the chip to get it to get it off and then try to put it, but putting it back is, is a nightmare or something else. But yeah. I've got, I've got, I've got, I've got, same not much better of it. But yeah, if they're, if they're reasonably priced devices, um, you know, four is kind of the sweet spot. And you know, the thought behind that is, you have the first one and you've got to figure out how to get it open. And if there's any sort of tampered detection or glue or anything, you're going to physically destroy the first one. Yes. Then you figure, I've seen,
I'm sure you've seen it too. Some devices that do not want to be tampered with, yep, have, like you have to look up. I think we've covered some articles like of the, all the various compounds, chemical compounds that take in, in case the electronics in getting through some of that stuff. I think we did cover an article that was using chemistry, very dangerous chemistry to, uh, dissolve some of those chemicals from the board without getting them. Yeah. And it's not even so much the board. Sometimes it's the external like when you consider like, I see a SOT gear that's potentially in public, so it can't be tampered with like power meters and that type of stuff. You know, sometimes you are literally taking the first one apart with a sledgehammer. So you figure out how it goes together so that you know where to precisely drill holes or could cracks in the case to get access for the second one. And then there's a good possibility you're going to let the magic smoke out of the second one. Then you, and if you let the smog out of the second one,
you have a third, but the fourth is there for your pristine model that is the one that you do network traffic captures and they actually do some manipulation. Right. So yeah. Let me let me, Larry, how many units have you destroyed for you to build this? Absolutely precise. This is what the first one, second one, third one and fourth one, four. A lot. A lot of devices were harmed in security research. A lot. This is now why I have some of the challenges that I have nearly 200 pounds of gear to ship back to a customer at the end of my employment. Uh-huh. Yeah. So this is this is this would be a good argument for Larry having a sinkhole in his yard. Or wormhole at least. Yes. Portal. Oh, Sam, do you have to leave in like 15 minutes? Oh, sorry. Sam stories. We should have started with Sam stories. No matter that hot this time
anyway. Oh, it started Florida. Florida. That's that. That was Florida man asked for it. Yeah, chat GPT. What the hell is this? Come on. Are you joking? No, they're suing to stop to develop most chat GPT on their grounds that it pretends it's human and they're selling it to kids. And if Sam Altman means what he says about slowing down, he can slow down. That doesn't seem that unreasonable. In fact, I read another article that said that this is why open AI and and thropic are trying to get government regulations because they're about to have an IPO and they had to announce that they have an unknown legal risk because they might get sued by everybody for all the misbehavior of their AI agents. And if the government just regulated, then they'd have a defense saying, oh, we obeyed the regulation. There's actually a considerable risk there. And this Florida lawsuit is probably just the first of many. I mean, a lot of people have complaints about AI and they can all sue the AI companies. Interesting. Interesting.
Yeah, I mean, I just don't know how effective said ban would be. Well, if that's the point, but if the government was to set some rules like some compliance regulations, then they could say, well, we complied. Right. Right now that I think they're in a they have a large unknown liability. What if everybody shoots for all the bad things that come out of AI? Yeah, like revenge porn and deep fakes and kids committing suicide and hallucinations for medical, let's be kind of stuff. But Sam, right now every aspect of this can be traced back to a human. Okay. In three or two companies and company. No, no, no, no, we're starting to talk about the manufacturer's responsible for the for the use of the tool. And you know, they are if you claim it's a defect in the tool and you could reasonably make that claim. Right now, they're like people
manufacturing cars with defective brakes. They're selling the product and it had hallucinations and it fools people into trusting it when they shouldn't and stuff like that. I could make a legal case for blaming the company for this stuff. Yeah, you can one could make it. I can say that. Yeah, I can agree with you, Sam. I can also argue against it, but I can agree with you. On the other hand, I think it's more along the lines of there's a company that makes a car. There's another company or the user installs racing brakes that they bought from China. Yeah, or uses it incorrectly too. Like most of the AI models, if when you ask it health questions, puts a warning label up there like you should not be using it for this purpose. It's up to your doctor. This doesn't racing brakes go against the purpose of racing because they just stop. Yeah, sorry. I just picked up on the weird stuff. My, well, you know, when you install these AI's, I don't remember any like instructions. You see few instructions when I started using them. You had to start prompting it before it gives you any guidance. And then like guidance is
subject to prompt injection hallucinations and all that stuff. Yeah, yeah. So, you know, and like, you know, it's funny. You mentioned the add-ons. My story number eight is exactly that. There's a company called Comma.ai that adds additional hardware to your smart car to make it smarter about driving. And then it fowls up and causes it to run into cars. So, they're being soon. But they actually do sell it aftermarket addition to your self-driving car to make it more self-driving. If I buy three of them does it self-drive even worse or better? I don't know. Yes. Oh, yes. I never heard of such a thing. But it did seem like a lawsuit wedding happened. And now that lawsuit is happening. Oh, okay. I got it. I got it. I got it. Yeah. So, when a user uses a model based on vast.ai to do bad things where they rent out GPUs and such if you don't know vast.
Yeah. Can I sue vast because that's where it was built? You can if you can say that they it's defective or that they advertised it to use for this malicious purpose or all that. Just like if you bought a gun, you know, it's it depends on all the details. You could very likely claim that the manufacturer is partially responsible for the bad result. Even if the person did bad things with it. You know, I realized today and I thought I had disabled it. Maybe I didn't get reenabled. But Groc is enabled in your Tesla if you haven't disabled it. And I was driving my son to school this morning. I asked him about like allergy, the allergy index or whatever pollen ragweed. And it answered my question in my someone's impressed and I was like, but you didn't know like, you know, this car had had an AI assistant in it. And then the AI assistant answered me and it's like, oh, aha, yes, I'm your AI assistant. Like, how can I be a assistant? You can probably,
I'm like, stop, stop talking to my son's laughing because I'm scolding my AI assistant for still listening. I'm like, stop, go away, go away. Yeah. That's exactly what the Amazon echo does recently. Like it listens for a little while after you stop talking and picks up on conversation. Yes. And yeah. And then starts offering its own commentary on like, you know, oh, excuse me, I farted like, yeah, like I wasn't talking to you. I was talking to my son. Stop exactly. Yeah. So have you guys been using Chev? No, not yet. No, I haven't tried your stories. Is I knew it's really brand new and there's an open source clone that actually works. I mean, I need to my students tonight. There's homework, which I don't know how that happened. It only came out about a week ago. And there's now it's closed source and there's already an open source product version that works. But anyway, Chev is a different kind of AI. Instead of producing paragraphs of text, it just does force choice. So you say, here's an email from the customer. Tell me if this belongs to the sales department, the billing department or these two other
departments, you will choose limited set of possibilities like four and tell you what the probability is that has each of those options. And then you can say, tell me how angry is the customer from one to five. And tell me, do we have to talk to respond today? Yes, you know. And it will because it does this, it does it on one stage of processing, unlike an LLM. So it runs 20 to 200 times faster and immensely cheaper. One of the early beta testers said he signed up and got in the beta test, which is now closed. He got five dollars for the credit. He said, I ran hundreds of queries through it. And now I'm down to $4.98. So it's much faster and much cheaper. And I think this would probably give a very good thing to be a frontline security of your LLM saying, does this question appear to violate our security policy? Yes or no? And to continue that. Fast and cheap. I think we're going to see a lot of different models local or otherwise or even online, right? That rival what we're getting from the frontier models or at least our specialized, we already have
a bunch of and they just keep getting better. Yeah, but this I think is really specialized much cheaper, much faster and smaller. And therefore, it'll do something about the rising cost of AI because you often don't want a paragraph answer. You want like yes or no. We're still putting a beta center in your backyard, Sam. Well, I think there's like 20 of around here. I'm in Silicon Valley. Yeah, you know, I'm at literally in your backyard. I don't have a backyard. It's still there. We do never mind. Hey, look, if you give me an SMR reactor, I'll put a data center in my backyard. It's not a problem. Okay. There we go. Well, I guess I can power my house. What was up with cloud flares containers? I had a container. I believe in this mistake. You know, this is the mistake Amazon made at first. You would bread a virtual machine that somebody ran a forensic tool and it had the data from the last guy left on it. And this thing did the same thing with the containers except by default, it would wipe and they turned that off. So you'd run the container and it had
the last guys data. Of course, they fixed it now, but it is kind of rookie mistake. That's interesting. I wonder if it inherited the storage volumes from the previous container. Yeah, yeah. Yeah. One person was done with it. It would just hand it off the next person without wiping it first. Yeah. Yeah. Probably without cutting the storage, the container storage containers, storage volumes, the common Docker, at least the volumes would carry over with it. And the volumes is where you put your data. At least, right, if you read the best practices, that's what that's what you should do. Yeah. That could be bad. That could be really bad. Oh, yeah. Oh, yeah. Well, this is the same practice as three buckets. People just found out. Yeah, similar. Yeah. Cess free buckets had the same problem and copiers used to have the same problem. You'd find on the hard drive, the copies from the previous people had used the copier. And so rent rent, rent, charge copiers would be leaking this information out. You know, all kinds of printers. Yeah. That was I was on a pen. I was on a pen test once in access
multi-function device and got access to its storage. And there was social security numbers, credit card, all kinds of sensitive documents just sitting there that had been saved. Yeah. It was more for the copying function, I want to say. Maybe the faxing function back in the day. Yeah. If people just didn't think about data reminence. Yeah. I had a district attorney taking my Frenchist class because he had made that mistake. He had like submitted some evidence and there was leftover data on there that exposed something was supposed to be private and he decided to take a Frenchist course to understand data reminence. Wow. Yeah. Nice. Good for him though. Yeah. Yeah. It's a good response. There was a container escape. You know, it's interesting. The My story number 12 was titled containers are no longer a security boundary. Yeah. And I've argued on this show many times that containers are not never intended to be a security boundary.
I think hypervisors in virtual machines try harder to give you a security boundary. But as we've seen with a lot of research and vulnerabilities that it is not a security boundary. I want to say if we go back even further in time, we also said the same things about VLANs because all of this, there's hardware involved. But there's also software involved too. And if your software is trying to create those security boundaries in VLANs, virtual machines and containers, inevitably, there's going to be problems. Even Intel, what is Intel's SGX and other technologies, AMD, with SEV, right, are trying to protect memory regions. All of those who had vulnerabilities that have allowed you to read memory, and they're not supposed to, despite the protection. So
security boundaries are definitely a thing that have you tried to easily mention? Absolutely. I mentioned too. Yeah. Carfire, hacker, and caucho. Yeah. So there's two different mechanisms to escape the container. I've not tried this yet. The company recommends micro VM-based isolation, which again, slightly better, but not foolproof. And again, I'd argue these are not security. Containers certainly, I make an argument they're not security boundaries. And kernel bugs can bypass namespaces, set comp, and container run time to reach the host. I mean, there was a Linux privilege escalation with a container in the default configuration that like if you get cloned, this container can fig, you could become root. That worked for a long time. I haven't tested it recently, but that worked for a long time.
I mean, it's a shared resource problem. I mean, it's a sharing resources. Whatever is provisioning those resources is going to be attacked to get around those boundaries. And even when they're done with security in mind, containers were not really done with security in mind. Containers were to separate workloads primarily, right, to separate workloads, but more importantly, to have those workloads be ephemeral. That was the problem that, and it's a very important problem that containers addressed. They were never designed with security in mind. And still to this day, obviously, as Evan's by storm number 12, they still have issues. But there are two VMs, they mention that are supposedly good. Firecracker and Kata containers are supposed to be strong barriers. I just, I don't know. Okay. I'm sorry. I thought those were the attacks. Those are the micro VM isolation, such as firecracker or Kata containers for untrusted workloads. That's interesting. Yeah, there's much stronger. Yeah.
I have to try them out. I haven't tried them yet. Well, and that comes down to hardening, right? And again, like, and this is the double edged sword of open source and Linux is, you have infinite number of bells and whistles and knobs and dials to turn. And if you do all of that in a secure manner, you can make something really secure. But also, because it's all open, there's security issues with that because there's the freedoms in liberty that we have with open source are also well great. Well, great. Again, I'm a huge open source fan, obviously. But those freedoms and liberties also have that downside of not being as secure. And we would compare, for example, Linux to apples implementation. Apple runs a very locked down hardened controlled environment that has much less freedom and liberty, but offers better
security. I'll give that 100%. But yeah, it's a trade off. It's a trade off. It is. Hey, I want to switch for one second because I want to see Larry's face when I say that we should look at Sam's story number nine. Sam's story number nine. Oh, only 13% of OT network segments are fully isolated. Yeah, that's the face. Yeah. But yeah, who did you know? Was it Dregos clarity? Force. Force. There you go. Yeah. So, you know, people are violating best practices with OG as we kind of thought they would. This is not. And also doing even worse with medical tech, you know, only what only 6% of medical devices are on an isolated network. Right. So it's pretty appalling. I'm literally surprised that it's at 6% that it seems high to me. But, but, yeah, I was dead.
I sorry, I had the microphone off because I was typing, but like, yeah, possible. Yeah, hashtag possible from from the busters. Yep, absolutely. Absolutely. Why do you say 6% is hot? I mean, you honestly think that medical devices are in the vast majority of medical systems, share IT and share their VLAN, their network, their segment with. It tends to be very flat. It tends to be very flat because the systems have to be interconnected. Yep. Yeah. Now admit it's been a hot minute since I worked in healthcare, but my experience in healthcare was exactly that. Like, you were kind of lucky if you had VLANs between departments. Like, that was like the the cream of the crop. But yeah, no, your your devices and your pharmacy there, do you want all your pill counting and your med supply? Those are on the same network segment as your desktop PCs. And, yeah, the ones that might be an exception might be like your CT scan
or your MRI. Because in many cases, those were sort of in some cases in smaller organizations. They were least and they came with their own separate infrastructure. They're basically, you know, like a trailer that you back up and then you plug the trailer into your network and your car. I hope they put the billing and financial in a separate VLAN. No. I mean, don't forget a lot of healthcare organizations suffer from the same problems as universities. They've been around forever. Right. And when you were first building networks, there was no guidance for security. And there was no guidance to tell you that it should be segmented. And so they've got all that legacy to deal with. And I think many of us have dealt with that in both those environments. And it's super hard to go from I do hear my house. It's the same thing. Like, I'm talking about
the cobbler and his children's shoes, right? Like, I had a flat network and I've been over the years trying to segment, but it's hard because that's what you started with, right? And then when you start segmenting stuff and stuff starts breaking, in my house is one thing. But if patient records, imaging scans can't get to the right people at the right time, that's a patient care issue, right? Which is always kind of the crutch that healthcare leans on, but I won't ironically call it a crotch because it really, patient care is very important. Getting that information to the right people at the right times is literally a matter of life or death, right? So it's the old life safety Trump security. But I would also modify your comment, Paul, that when those networks were created, there wasn't the threat landscape there is today. There wasn't the requirement to do that. Let alone the threat to be answered to not they shouldn't have segmented, but it was a different environment.
And as I said, life safety first. And I think Lee and Larry, I mean, maybe correct me from wrong, but I think they've leaned on the data privacy issue largely driven by HIPAA, but have implemented encryption, right? So when there is communications and data traveling, they do try to encrypt, it might be on a flatter network than we would like, but that data isn't encrypted more likely in transit than maybe at rest, in my opinion, but I think for compliance reasons, I've forced them to do that data encryption. The secure chat I spoke of several weeks ago is what's the big software company in healthcare. Epic. Epic. That's an epic. That's an epic, right? So epic. Right. Huge, at least successful software. I mean, health is going to be huge. Almost monopoly, I would say, you know, recognize that need that to be compliant with HIPAA to protect, protect
patient privacy, there needs to be secure communications for a patient between healthcare workers that are involved with that person's case. So rather than going in the micro segmentation zero trust, some of the things they rely on is that data encryption. Thanks, Sam. OT networks are different though. I'm pretty shocked, but we've been talking about segmentation in this area since the dawn of time, kind of shocking that it's still not properly segmented in OT networks. Well, I mean, in a hospital, I can understand it. You've got an infusion pump next to a doctor using their iPhone, next to a computer on wheels, next to a like, it's kind of confusing. All right. But I mean, in, in, I'm going to interrupt you real quick here, Josh, just because I find it humorous. The many of the hospitals have adopted not computer on wheels.
They've adopted workstation on wheels because many, when they were referring to them as cows, the nurses were offended that they were being called fat. And if there were stations on wheels, if there were stations on wheels, there was because the nurses are amazing, which is also a true story. Sorry to a diverge. Yep. You win. You win three internet, sir. I have no comments. I'm sorry. You're railed me. What was shit? You're, you know, but with this OT stuff, you're making me think of my, my story number two, which was the guidance that came out of the FBI and CISA about third party integrators that have access to OT systems, which is also a thing. And then, and what it amounts to is not only best practices, but it asks you a lot of questions to ask about that integration,
to see what, you know, you don't just say, okay, let's do it. You, you, you, you, you think it through. The, the PDF, which I didn't, I put a link to the CISA article, not, I think it was not the PDF, which is the only four pages, but it's, it's good stuff. I'm looking at it as a, yeah, I mean, they're in your network now. And your network's flat, like we've been talking about, or not segmented, they're in your network. They're in the house, right? Yep. And, uh, now just expose the OT to the internet. That's all right. Well, then we, then we can just log into it. It's fine. It'll be fine. And I'm, oh, that's okay. I've, I've, the default password works. It's all right. Um, yeah. It works. That's the point. Yeah. That's it. You know, you run the risk of breaking it. Um, yeah, no. So it, you know, this is, I, I think I gave the, uh, I told the story of the, the modem, right, the one modem was in the data center connected to a system that allowed the vendor remote access. And everyone was kind of freaked out about that. Um, we look at different industries
that have to provide this access to a vendor. And how much that is evolved in certain sectors. For example, if you're a cybersecurity company and let's say you have, uh, financial sector clients, um, many of us can attest to on both sides, whether you work for a financial organization in cybersecurity or you work for a cybersecurity vendor, the level of scrutiny that we have with each other to provide secure access to the systems. Recognizing that there's value in, let's say, your cybersecurity vendor having access to that cybersecurity solution, but the guardrails that are in place are amazing, right? Uh, and indicated by policy, which I think is a very positive thing, right? Financial, uh, I think leads to charging could be a model for like, hey, we have this system. It has access to these things. And we have a vendor who can help us tune, maintain,
troubleshoot that system, which is beneficial, but we have to do that in a very secure manner. And that in my mind, like culturally, maybe policy procedure wise hasn't trickled down into ICS enough. Obviously, if sister's is doing a warning, hasn't trickled down. Yeah. Like, I think there's a model here. And it's, it's really, it's more about policy. It's the boring part of our jobs, if you will, in defining that policy and backing that up with solid procedures and sticking to your guns, be like, no, when you have access to this system, here are the security controls that must be in place. You have to play our rules to do that. And I think ICS, um, I would have thought would have that. Uh, type of scrutiny on vendors accessing things. Obviously, there's gaps in that again, if sister's issuing this third party in the greater warning.
Oh, I agree. Although you gave me a flashback. Do you remember when the mainframes used to call the support group? We fit detected a problem. And you'd get a call from them back saying, we're logged into your system and we're, we're, we're just running down the problem. Yeah, what's that? That was, I have vague memories. Like, if you, if you had an IBM mainframe, let's talk IBM mainframes. We had those at the university. Yeah. There were, there were times when I, I do, now the team that managed those had a lot of experience with mainframes was very, very good. Yeah. On the off chance, they did have to get maintenance. I think you're right. Like in IBM, as an example, would have access to your, it called, I'm not sure how that was provision. Yeah, they called IBM and said, hey, you know, it dialed up and established a connection. Which is interesting. Like, it's freaky. It's freaky. But like, mainframes were like millions of dollars. I'm sure they still are today. Like the very, so I can see that level of support. A thousand modelers no longer in place. I mean, well, you can get older ones now. You'd be
interesting. But they, I mean, you know, having a system call for help is nice, but you gotta think it through. Policy procedures. Larry, I want to hear about this micro SD core that has viruses. Yeah. It's just going kind of interesting to over the years, I've been finding more and more news sources from all over the place. And this one specifically came from discord. You know, one of my hardware hacking channels effectively what happened was from the factory for the Elecro think node M nine had a micro SD card included in it. Okay. And on the micro SD card was
an auto run dot INF, which really shouldn't auto run anymore. But also had an application that was supposed to be auto run, which was an executable, which turns out it was picked up as a virus by various stuff. The one they have here in the notices by ESET as virus sality, haji. Like, yeah, so this was put on the micro SD card at time of time of manufacture for the device. Supply chain attack. Yep. Very concerning for me. In most of us, right, that have like how many SD cards do we have in having forbid like you're into photography, the amount of in the money you spend on these cards.
I'm not sure if more advanced, the more likely they would have some kind of virus or something, some extra functionality in them. But I've got some really high end, not many because they're so expensive. What's the, I don't know, what the one the one I have for my camera is express, express, see what is. Thank you. See if express. Was that ties. Thank you, Tyson. Yeah, I love it. Yeah, I have one. I can afford one. See if express card for my camera. Right. And I was like, wow, wow, like if that ever had any kind of firmware, I don't know, there's is a firmware on the car. I don't think it's firmware on the card. The card is just a store. Well, storage devices have firmware. I haven't really looked into it. Yeah. So yeah, so you know, I mean, in this case, it wasn't firmware on the card itself is actually just files written, yeah, files out there. A gap in production environment security protection caused some memory
cards to be contaminated with a get this a worm virus. And I quote, a worm virus. Good, Lord, can you imagine buying a C of express card that somehow bricks your camera or something like that? Right. Now, is that an actual like the old school CF style card that like big square. It does. So it looks like a compact flash, but it's smaller. Oh, and they're just all it really is in Tyson Kerkin from wrong, but like ridiculously faster reading right speeds for cameras. Ideally for video, but also like I shoot sports photography. So I've got like a really fast capture. Like when I hold the button and takes a lot of pictures, right, and that's to write those very, very quickly. And in fact, yeah, thank you, Tyson. And I've noticed it, especially if I'm doing just raw. So I'm not shooting JPEG plus raw or just JPEG if I do just raw,
it actually writes it much, much faster. Yeah. Also, I think Tyson will probably agree, like if you have a Sony camera, you get a Sony CF express card like those in a Sony lens, those all kind of married together to let you take a lot of pictures all all at once at a very high speed. Stay within the ecosystem. Yeah. But yeah, and we've seen this problem numerous times. We've seen USB thumb drives and all kinds of storage devices come preloaded with with malware. So I think probably solid device once you get one just format it. Format it be done. Maybe not plug it into your window system first and then format it. Maybe plug it in something else and format it first, right? Because if I was smart and I was going to implant malware on removable storage, I would try and do some trade. And it looks like there is an auto run on here too, right? I would do some tricks to make it execute on Windows when I first, when you first plugged it in to infect the
system. Yeah. Okay. Moving on. Let's not have another story. Come on. Let's have another story. Did any of the first computers have a bio a bio a bio a bio a bio a bio a no, but they did have a bug. They did a bug that's where it came from right. Physical was it a moth? Greg Grace Hopper found a moth in the sucker and well, the computer has a bug and boom. That was it. You know, she did like the letterman. I saw a clip on social media where Grace Hopper did the letterman show. I am, you know, now I want to go to YouTube and find that whole that whole clip. She was amazing. Amazing. Yeah. I need to, I need to actually make a bunch of nanoseconds and hand them out to people. Nanoseconds? Did you ever see that? Yeah. So she when, when she was teaching
executives about how fast computers could actually process stuff. Yeah. Yeah. She, it was it was hard for them to understand the time, the speed. So she cut a length of wire that was a distance light could travel in one nanosecond. Yeah. It was about 12 inches. How much? 11 and a half. 11 and a half. I was going to say about 12 inches. So I was just close. And she described as explaining to like Navy Adirals. Yeah. Why it takes so long to get for communications to happen. Yeah. Exactly. Exactly. So that was the clip I saw. Yeah. She was on letterman. Here's your nanosecond. And here's your nanosecond. And here's your nanosecond. Yeah. Amazing. Amazing. Amazing. Yeah. So apparently that any act didn't, did not have a bios in the modern sense. It was programmed physically by wiring boards and switches together. There was no, no concept of like firmware that would initialize your hardware.
Like basically you would mechanically enable your hardware. Yes. Rather than have what we have in modern systems is essentially firmware that in the early stages of boot initializes your hardware. Like that was basically left as an exercise for the operator, the physical operator to do that. And it kind of just it put a lot of things in perspective. So where we are today, you know, with computers and how they boot. So I was. Any any act had the had the wired plugboard, right? Yes. Where you would, there was a board that you jump for it for what you need to do and and put it in there. The eniac was a single purpose computing device that could be reprogrammed. Yes. It was not a multipurpose computer. Right. Right. I mean, it was 1946. Oh, there we go. Yeah, there's some there's the fun. There's this which isn't there you go. Holy cow. Yes. Those are those are the they reminds me too. I love that movie Silicon Valley.
Old movie now, but but the beginnings of Apple and Microsoft. There's a great scene where where Bill Gates and Steve Allen are delivering like one of the first demos. I believe on the Altair and they realized like after Steve Allen boards the plane that they they're like we forgot to write the loader. Like the real estate operating system or stole the borrowed bought the operating anyway. They got an operating system. And they were like, oh, but we forgot to write the loader. In the loader, meaning the boot loader, like what what's going to happen when the system initializes and then you have an operating system like what's that piece of software in between that loads the operating system? Oh, you're right. That's the boot loader. And the story, the way they portray in the movie is that Steve on wrote it on the airplane or whatever or like wrote it at the 11th hour to load the operating system. If you can just imagine like, oh, I need to write a
boot loader today. Yeah, it's pretty awesome. Yeah. Yeah. No, no, we're we're we're we're we're what was that from Paul's a TV show movie? That was a movie a movie called Silicon Valley. Oh, yeah, yeah, the old old not the TV because of the TV show called Silicon Valley. Yeah. But before that, it was like late 90s, early 2000s, I think. I don't like I don't know if I've ever I don't know if I've ever seen that one. And then part of the reason why I asked that was still hold up that would still hold up today. Nice. Nice. Yeah. I know I got it now I got to do a quick and and and I wanted to double check on that because I'm starting to a messy small collection. It's a total collection of two at this point of vintage hacker movies still sealed on VHS on VHS. Oh, seriously? On VHS. So the point that what was happened was that I bought
war games because Ali Shidi was going to be at like Comic Con nearby us and I was going to get her to autograph it. And I ended up not being able to go. And then I just happened to think of it and I'm like, Oh, well, I wonder what other ones I can get like sneakers and you know, and hackers. And I think I got sneakers off of eBay from the original version. And I think it was like six dollars off of eBay. Nice. Yeah. I apologize. People are yelling at me with an listening to this recording. It was a TNT film in 1999 called Pirates of Silicon Valley. Oh, okay. No, while he no, while he plays Steve Jobs and Anthony Michael. All that while he's Bill Gates. And like their performances in this movie are absolutely epic. Like I had forgotten about this movie. It's awesome. I ventured against this. We still hold up today. The soundtrack is awesome. Awesome. Yeah. The way they portray it. Yeah. Okay. Yeah. Pirates of Silicon Valley. Hi, hi. I have a recall. I recall. But yeah. So Paul, I tried to buy hackers. The original version of the rerelease on VHS
still sealed. And it was prohibitively expensive. What's the difference between this is one aspect of the hackers movie? And I know way more about the movie hackers and have a lot of useless knowledge about it. But is there an extended in a standard edition of it? I mean, no. So for the rerelease anyways, they changed the packaging. So the original release, they had a single set of packaging that was, you know, went with all the movie posters and that type of stuff. And basically when they got through that run, they redesigned the packaging to sort of have a second run of that. And I didn't want the second run. I wanted the original run. And both cases, they were expensive for what I was willing to pay. Yeah. They were they were $50 for the second run. And the excess of 100 for the first run. Right. Now this, there's a blue rate. I have a muscle. Also, I'm also looking for original in the
in the shrink wrap still. So not like, okay. Yeah. Like original VHS in the shrink wrap. Yes. Yes. Yeah. So I have a bond. One of the rereleases was super special. And I have that in shrink wrap somewhere. I should probably put it up in my, in my office somewhere. Yeah. With all your, if you need some more stuff in there, I need more stuff. Yeah. Because I don't have enough. We need more stuff. No, no, you don't. I already have it though. I just need to relocate it. I don't need to purchase it. Just relocation. Now you got me thinking I want to do a hacker's Halloween costume this year. Yeah. That's what I'm thinking. I just did a surplus of a few versions of hackers out there with different cover art is interesting. I'd never even thought about it. Yeah. Yeah. Just up with a floppy disk and a blob of gum on the back of your head. Right. There's a lot of a lot of options there. For sure. Yeah. Dad, why are you going as a 3D printed save icon? Right. Oh, I hate you. I hate you so much. Oh, goodness.
Oh, we get another story in here by chance. There's a new specter attack. Specter will never die. So they developed branch target reuse. New specter V2 variant that have used a stale CPU branch predictions after jik and pile code is replaced. I link to the bleeping computer article in this one. There were two CVEs that were issued. The demo is kind of it's kind of interesting. I think it's just somewhat of a nothing burger. Here's the case. So it allows you to exploit the basically abused privileges to read files as root. And so they read the sys shadow password as a regular user. They get the password hash of the root user.
And while very clever, allowing someone to steal the root hashes is a thing. I get it. But my advice to my favorite part was my advice to attackers. Just wait for the next Linux LP vulnerability and exploit that instead because that's just going to get you root. Like you're going to execute this vulnerability branch target reuse in order to get the hash of the root user only to have to crack that offline to become root when you can use a number of already publicized LP vulnerabilities or wait for the next one to come up that just give you root. I hate giving advice to attackers, but also take that advice as defenders that Linux local privilege escalation vulnerabilities and exploits are like just wait a week and you'll get a new one. And speaking of that, we can go to my story number 11, which links to source code, which is
exactly that. This is a Linux socket garbage collection ordinary unproved user can trigger it without a user namespace bpf, I you ring a special capabilities. There is a proof of concept that causes a crash general consensus. This could be code execution very easily. And this is the one you should probably care more about than the spectra or V21, which by the way is radiative a kernel update that did fix this in the Linux kernel, which the fix is great. Detecting if that fixes there is problematic because we can't rely relying on version strings is highly unreliable. So you have to kind of dig into the kernel to see if that kernel is actually vulnerable like great that Linux kernel team Johnny on the spot now as you can see the eas fixing stuff. Yeah, amazing. But everyone that's down stream of the Linux kernel has to take that fix.
Everyone takes it in a different manner shape, former fashion. And though even though you want to go oh compare a version, that version may or may not include the fix, even though they have published fixes. So they could have for example, in a Linux distribution or Linux system, they could have taken the new kernel version but not taken that fix they can cherry pick, which I don't agree I don't agree with. I think you should take all the upstream Linux fixes. There's reasons why people don't, which I get for functionality, but also you should build you know have your customized Linux system so that you build it such that you can easily more easily take those upstream, especially kernel security patches. The local privilege escalation in AF underscore Unix sockets widely included in Linux kernels. And you know, that's another fix that you got to make sure it's in your kernel, but probably a more reliable post compromised escalation
path. So so I had a ghost Larry and I didn't see if you covered it hit the Apple emergency update for iOS. I saw that. It's a really bad one in there, right? And which my waste when I was bringing up, I'm wondering how many people are looking at that and then looking at the fact that iOS 2701 just dropped and iOS and watch OS and blah blah blah. And are going to go down which path they're going to go down? Are they going to update the old one? Are they going to they're going to go to the new one? Yeah, I think they're probably they think they should be updating both here, but yeah, Lee this one was an interesting one for for core graphics zero day. So basically it's just malformed images. There was another one that I put in there in mine. Oh, maybe I missed it.
There was also similar for Android with graphics library processing. And of course, now that I'm I saw that, but I missed I can't find it now because I'm saved my life. Yep. And then of course, the the final one was that I just saw and I didn't know how I missed it. There was some NFC based attacks against Android devices so that if you're sending malformed NFC stuff, it was attacking the NFC stack itself. But also NFC would be a way that I would deliver a URL to one of these malformed images for either Android or iOS so that when presented, it would already navigate there and then process the the image. So I thought you're linking your linking your linking vulnerabilities for a bigger attack. That's not a thing. Yeah, well see this one didn't really need to even just use the NFC vulnerability itself. It was just using it could have used just NFC as a as a delivery
method. So I still like the idea that you're you're training two attacks together to make something real cool. I mean, come on. That is kind of neat. Yeah. Yeah. Fun stuff. Yeah. So I think, but I think Apple's really reduced the operational risk with their updates for especially iOS devices. Although I just I just do that. I ran and cost a rant. It was forwarded to me. It might have been my showy about somebody saying with iOS 27, Apple is now going to charge for new the new features they're building in. When what it was is for I think third time, the oldest supported devices don't have the CPU and bandwidth to run all the new features just like you don't have without you don't you get get some of the co pilot stuff without a co pilot processor, right? You can you can run Windows 11 on a box, but not necessarily have these other features because it needs the hoods, but to do it. I I don't think it's a fair to choose Apple of charging. It is well, I guess it is because they
make you buy a new hardware, but they're certainly not the only one that does it. Yeah, but I think once you reach a certain point in the age of your hardware, you can probably go to your cell phone provider and get a reasonable upgrade to the new. And a lot of times you see it on you see it average doesn't TV right there. Bring us your old iPhone in any condition and you get some kind of deal to go to the new phone. So you're there's incentives to be on the latest hardware on the latest software. I mean, I looked it up. I mean, if I get to get a new iPhone of the model I have is whatever and they'll give me $600 on my old phones. Yeah. Okay, and yes, that yes, I do wipe it. Although you get my family, you get five people on the plan that sometimes gets dicey. Right. Well, if I want the newest one, I can get a air quotes free iPhone 17. Yeah, there's a lot of a lot of read between the lines in those comments. Yeah, unpack free. I mean, really unpack it. By the way, that applies whether it's an iPhone and Android,
whatever the hell, make sure you understand, you know, look that gift horse in the mouth. Be sure you know what's going on. Like when the guy stops you in the store or says, what's your cellular provider? I can get you this for less. Make sure your apples and apples. No, I'm not talking about the brand. Make sure you're talking about the same thing. I've had that happen to me in Costco and they say, look, we can get you this. What do you got? What do you got? I mean, this is how much of a cost but it's not the same service. It's not the same level of service. And then when you push them to give you the same level, they like duck and change and a lot of block. I mean, I get it. They got a job to make sales. I respect that and sales is hard. But I have a trouble if you can't give me an equivalent in there. That bugs me. But enough ranting. This has been a good show. It has. And unfortunately, right at the time, we do have more stories to talk about, but they're in the show notes for you to go read. A lot of good stuff in there. Thanks everyone for listening and watching this edition of Paul Security Weekly.
Larry, take us out. Over and out.
More episodes
More from Security Weekly Podcast Network (Audio)
State of the AI SOC, regulating AI, and can AI agents feel pain? - Aqsa Taylor -...
Security Weekly Podcast Network (Audio)
RAM, Muse, CloudSyncD, Springsteen, Software, Persistence, and Michael Jenkins -...
Security Weekly Podcast Network (Audio)
Defending at AI Speed as Quantum Threats and AI Policies Won't Save You - Nolan...
Security Weekly Podcast Network (Audio)
Venus in Furs, Money Laundering, AI Hijinx, MCP, Thunderbastard, and Aaran Leyla...
Security Weekly Podcast Network (Audio)