Paul's Security Weekly · 2026-10-29 · 2h 9m
Key moments - from our scoring
Substance score
56 / 100
Five dimensions, 20 points each
This episode tackles a relentless wave of security incidents across critical infrastructure and emerging AI-related risks. The mathematical discovery that OpenAI's Claude cracked the elliptic curve digital signature algorithm's mystery constant in 30 minutes - a problem that stumped researchers for years - illustrates AI's pattern-recognition superiority in research contexts, though the mathematicians' community pushback on uncoordinated disclosure mirrors security industry frustrations. The Emudra TLS certificate authority's spectacular failure to generate keys properly (selecting random numbers between 4 and 386 instead of generating within that range) has cascading implications for devices relying on its certificates, particularly IoT and OT equipment that cannot be patched. The panel emphasizes that SBOMs (Software Bill of Materials), especially cryptography BOMs, remain incomplete from manufacturers, making vulnerability surface assessment nearly impossible. Discussion of UEFI boot kits and Pixie vulnerabilities reveals organizations face impossible risk calculations: patch aggressively and break legacy hardware dependencies, or accept pre-boot infection risk. The show reinforces that isolation, segmentation, and protocol-aware network monitoring remain essential when firmware updates aren't feasible, while Post-Quantum Cryptography transitions demand forklift upgrades across IoT infrastructure - upgrades most organizations cannot execute.
Hosted by Paul Asadoorian. The show scores 76.0/100 on substance across its analysed episodes. See the full show profile.
Claude identified that the NIST constant came from a 1990s-era linear congruential generator seeded with a time clock by analyzing bit patterns, a technique humans had overlooked. The constant was not derived from a hash phrase (as some theorized) but was directly output from weak legacy random number generation.
Emudra picked a random number between 4 and 386 instead of generating cryptographic keys within the required length range, producing weak keys. Devices using Emudra-issued certificates cannot update their certificate trust stores or undergo revocation in practice because most IoT/OT equipment has read-only firmware or end-of-life status, leaving them permanently vulnerable.
Revoking older Microsoft certificates in the DBX can block legitimate option ROMs (like graphics card drivers) required during early UEFI stages, halting boot entirely. Organizations must choose between accepting the risk of pre-OS boot kit infection or accepting boot failures on systems with legacy hardware dependencies.
MQTT (Message Queuing Telemetry Transport), IPMI (Intelligent Platform Management Interface), and Pixie protocols remain vulnerable. The panel recommends disabling these protocols and using protocol-aware network monitoring to detect anomalous or malformed traffic on these channels.
Manufacturers provide incomplete or inaccurate SBOMs that omit cryptographic details - such as which CA certificates are embedded or which signing algorithms are used. Independent verification of SBOMs is rare, and IoT manufacturers frequently fail to document certificate dependencies entirely.
Our reviewer’s read on each dimension, with quotes from the episode.
The episode contains genuine technical insights - using AI refusal patterns as vulnerability signals, detailed UEFI boot-phase analysis, and live AI-assisted attribution of PHP-on-firewall exploits - but roughly a third of runtime is consumed by beer-tap stories, mailbox anecdotes, kegerator debates, and meandering AI-replacing-workers commentary that adds no operator value.
73 out of 86 test scenarios. 73 of those were actually vulnerabilities. Like, that's frigging awesome. Like, you're basically using the guardrails against them to discover vulnerabilities is awesome.
Claude immediately looked at and found a pattern in the bits, said, oh, this came from a linear congruential generator.
A handful of genuinely fresh angles emerge - AI safety guardrails as passive vulnerability detectors, the ECDSA mystery parameter traced to a linear congruential generator, and the 'uncoordinated disclosure' framing for AI-flooded bug reports - but the majority of discussion (patch faster, segment networks, WAFs are mitigations not solutions, tier-1 SOC jobs are dying) recycles well-worn 2024-era security commentary without adding new framework or contrarian argument.
you're basically using the guardrails against them to discover vulnerabilities is awesome.
I'm calling it uncoordinated disclosure, I think.
The rotating panel comprises genuine practitioners - an active UEFI firmware researcher at Eclipsium, a SANS IoT instructor, a retired government/national-lab security veteran, and an academic with bank security consulting experience - all of whom speak from direct operational experience rather than theory, though none represent truly elite-tier seniority (top-tier CISOs, principal researchers at major threat-intel shops, etc.).
I just spent the last three days teaching for SANS. But class started at 4am
I'm like, great. I want to enable our customers to go hunt for and find those same things on their systems.
The episode names specific vendors (Palo Alto, Citrix NetScaler, Checkpoint, Cisco, Juniper, Fortinet), references concrete data points (73/86 test scenarios, 530M/375K/3.9K State Bank of India records, $50K PS5 bounty, 137-day defender patch cycle, 5-day attacker exploit median), and Paul's live AI-assisted analysis of which firewalls embed PHP adds genuine investigative specificity; deductions for several claims flagged as unconfirmed or second-hand.
73 out of 86 test scenarios. 73 of those were actually vulnerabilities
They have 530 million customers. They had 375000 records compromised, of which 3, 900 had sensitive information.
Paul occasionally redirects productively and lobs a pointed question, but the roundtable format yields long tangential drift and there is virtually no adversarial follow-up or productive disagreement - panelists predominantly affirm one another, and the host does not push on unsupported claims (e.g., TV HDMI surveillance assertions go unchallenged despite being flagged as unvalidated).
But I want to go back to the devices. Josh, I was throwing you a softball there. How do you figure out if they have those packages?
I'm sorry, I say that again without laughing. Defenders have an advantage because they're supplying fixes.
Computed from the transcript - who did the talking, and the words that came up most.
In the security news this week: In the security news this week: Cisco says patch faster, then sells you time Turning AI refusals into vulnerability signals Brotli's are hiding WordPress image upload exploit Fortinet ships fixes before details PHP2Shell still claiming victims, including firewalls Uncoordinated disclosure Claude finds vulns, go figure PXE strikes again! Sony's PS5 bounty drama Apple's October patches reach older devices CISA looks ahead to 2030 ArubaOS gets a pile of critical fixes New UK rules for protecting undersea infrastructure PortaPack Mayhem goes mobile Can AI agents police other AI agents? DHS bans DeepSeek A Chinese model writes riskier code for a US contractor eMudhra exits the TLS business BlackX bootkit exploits Secure Boot Signal makes hanging up harder than it should be Is AI solving math, or making it harder to trust? Visit for all the latest episodes! Show Notes:
Transcribed and scored by The B2B Podcast Index.
Speaker A: In the security news this week Cisco says you should patch faster and then sells you time turning AI refusals into vulnerability signals Brotlies are hiding WordPress image upload exploit Fortinet ships fixes before the details php to shell still claiming victims including firewalls Uncoordinated disclosure Claude finds Voln's go figure Pixie strikes again in uefi world Sony's PS5 bounty drama Apple's October patch reaches older devices CISA looks ahead to 2030 Arubaos gets a pile of critical fixes new UK rules for protecting undersea infrastructure Portapac mayhem goes mobile Can AI agents police, other AI agents DHS bans Deepseek a Chinese model writes riskier code for US contractors Emudra exists the TLS business even altogether Black box boot kit is exploiting secure boot signal makes hanging up harder than it should be and AI is solving math or making it harder to trust all that and more on um, this episode of Paul's Security Weekly. Broadcasting live from Gunit Studios in Rhode Island. It's the show where exploits run wild, packets aren't the only things getting sniffed and the cocktails flow steady. It's Paul Security Weekly coming to you from the Hacker Syndicate Studios. This is Paul's Security Weekly. It's episode number 950 being recorded on Wednesday, October 28, 2026. I'm Paulus Dorian, joined by Mr. Josh Marpet. Josh, welcome.
Speaker B: Hey Paul. It's always a good time to be here.
Speaker A: Yes, nice to have you. Mr. Larry Pesci is here with us. Yeah, welcome.
Speaker C: Yeah, back, back again. And man, I could tell you I. I'm wiped. I just spent the last three days teaching for SANS. But class started at 4am
Speaker A: That'll do it. Mr. Sam Bound is here with us. Sam, welcome.
Speaker B: Hello. I'm glad to be here. Larry, what's going on at the 4am? A different time zone for the students.
Speaker C: Yep. Yeah, the uh, class is being run in GMT so. Yeah, class starts at. Yeah, 9am GMT, which is 4am for me.
Speaker A: Oh boy. Mr. Lee Neely has joined us. Welcome Lee.
Speaker D: Hey, I'm glad to be here. Not getting up at 4. 4am But. Or from here you'd be getting up at 2.
Speaker A: Mhm.
Speaker D: I'm sure Larry's got his coffee ID all dialed in. So we'll have one hell of a fun show.
Speaker A: Absolutely. Quick announcement before we dig into it. Nation state actors aren't waiting for you to finish your compliance checklist. They're exploiting exposed services, abusing trusted identities and living off the land just like everybody else. The only difference is they've usually got more patience and a bigger budget. If defending government systems or critical infrastructure is part of your world, come hang out at the Government Security Virtual summit on, uh, November 18th. You'll hear from practitioners who are dealing with advanced adversaries every day and sharing what's actually working. No hype, just practical security. Our listeners can register for free at, uh, securityweekly.com govsec using the discount code CSS26-SW. There were times in the past where we'd be like, you know what? This was kind of a slow news week and maybe have some topics. Um, I don't think we've seen a slow Newsweek in a really long time. And I don't think we're going to see slow news weeks in a very long time.
Speaker C: It's almost, it's almost to the point that we're going to have to pick which train wrecks we cover and which train wrecks we don't. Yeah,
Speaker A: this is true.
Speaker B: Beyond true.
Speaker A: And if you look, and if you look at what hasn't been disclosed yet, which we can't talk about yet on the show, uh, I'm gonna give you a little heads up. Like, it's not going to slow down. It's not going to slow down. Because also, one thing I can say, historically, when you find vulnerabilities in one thing in one area of a project and share that publicly, that lets. Before AI, right? That lets people go, oh, I think there's a variation on that. I think there's an adjacent vulnerability. There's another place in the code where that happens. Hopefully we can use AI in defense when we issue the patch and catch all of those areas. So hopefully that, that improves our security posture. But certainly there is no shortage, uh, of things to talk about, Sam. Uh, I know typically you have to drop early. Uh, so we'll start with your stories. You get to pick. Feel like we're on a game show, Sam. You get to pick.
Speaker E: Well, I
Speaker A: think the
Speaker E: mathopolyx, uh, the math apocalypse
Speaker A: is, let's just say math apocalypse. Because math apocalypse is too hard to say, I think. Yeah,
Speaker E: it is too hard to say. So OpenAI solved 372 outstanding mathematical functions, or sort of solved them. But what they really did was they dumped out the chain of thought from an unreleased AI Followed by some code that more or less proves it, followed by some of them actually proving it with a strict process. And the mathematicians of the world got really mad saying this is just a pile of garbage. It's based on our work and you didn't give us credit. It fouls up people that are getting their degrees. They've reacted a lot like, uh, security community reacts when you just dump a bunch of findings without coordinated release. So now they have some new ones and instead of just dumping them right out, they're contacting the mathematicians to work with them to try to find out how to meet the uh, politeness standards of the math community. But anyway, it certainly is true that their models are able to do some kind of mathematical proofs and contribute something to the world of math. Although exactly how beneficial it is is not clear. But one that is pretty interesting is they found out my, uh, story number one. They found out what the mysterious parameter in elliptic curve digital signature algorithm is. This is something where the NIST came out and said, use this curve and use this constant. And they didn't explain where it came from.
Speaker A: I think we talked about this last week, Sam, and I wanted your take on it. So I'm glad uh, that you added. It's your story number one. Um, and this purportedly came from nsa,
Speaker E: right? That's the problem. It came from the nsa and the NSA has been caught red handed several times deliberately pushing broken cryptography because they have a secret backdoor into it that has really happened.
Speaker A: Right?
Speaker E: And so everybody is super suspicious when they say use this number. And they won't tell you where that number came from. But in fact it turns out that it just came from a random number generator seeded with a time clock at that time. And the interesting thing is Claude figured that out in like half an hour. Whereas people have been struggling for years to figure it out. Uh, but they got a bum steer. One of the guys said, oh, I vaguely remember it was like the hash of a phrase like get Joe a new computer or something like that. And they were trying to guess what phrase you'd hash to get it. It turned out it wasn't a hash of anything, was just the output of a 1990s era random number generator which are linear congruential, um, generators which have patterns. So Claude immediately looked at and found a pattern in the bits, said, oh, this came from a linear congruential generator.
Speaker C: Jesus.
Speaker E: So, which nobody else had noticed. So, but like we were saying before we started recording, AIs are ah, very useful for research
Speaker C: and great at finding patterns.
Speaker A: Right, right, agreed.
Speaker D: And you got to use them for what they're good at. I mean, that's the, I mean with any tool, use it for what it's good at. For crying out loud. Uh, by the way,
Speaker B: shouldn't use a hammer on everything.
Speaker D: Yeah, well, it depends.
Speaker E: Unless it's Claude. If it's the claw hammer, yes,
Speaker D: I would. By the way, I'm speculating that
Speaker C: the
Speaker D: random number generator they used in the 90s for this was state of the art. It was the best they could. They weren't. They weren't whisting out and using something that was junk. They were using what at that time was as good as it gets,
Speaker E: I imagine. Yeah, I think it was just a standard UNIX generator at that time, which were pretty weak. And they were replaced later for this reason.
Speaker A: Had they only known, they could have just used four. I mean.
Speaker E: That's right. Or
Speaker D: they could have done a flashback and grabbed a lava lamp. I mean, what the hell.
Speaker E: Did you already talk about the emojo situation?
Speaker D: No.
Speaker A: Did you see the meme where it's all the lava lamps and every lava lamp has a number four on it?
Speaker E: I mean, that's the one thing about E Mojo that I respect just is they just gave up and said, well, we're too stupid for this business. We quit. And I'd say that's the right response. When you make a mistake this big, you should just give up.
Speaker A: Because it was
Speaker B: now barred from going to India. They're the largest IT provider in India or one of.
Speaker A: It's crazy. It's crazy to think about, but what they. What they were they really just picking
Speaker E: a.
Speaker A: They were really just picking a random number between 0 and 256 rather than generating
Speaker B: between.
Speaker A: I always get it wrong. Because
Speaker B: 4 and 386. Because in the specification it says you need to pick a digit. You need to pick a set of numbers between 4 and 386 characters in length. They just picked something between 4 and 3. 86.
Speaker A: Right.
Speaker C: Is that where it came from?
Speaker B: Yes.
Speaker A: Oh,
Speaker C: my.
Speaker D: So wait a minute, Josh. Do I have to read all the words in the sentence?
Speaker A: Yes.
Speaker C: No, you just put the impartial.
Speaker A: Just a random number between four. Oh, great. Well, you can just use four.
Speaker E: And you have to know enough cryptography to know that your secret key can't be four, you know?
Speaker A: Right. I
Speaker C: mean, but
Speaker A: even I knew
Speaker C: that. But clearly it can't
Speaker A: even I knew that.
Speaker D: Uh,
Speaker B: I just taught a group of auditors today, federal agency auditors, about asymmetric cryptography, and they got that. Okay.
Speaker E: Of course.
Speaker A: Well, I also think it's cool. The long tail of this is going to be interesting. I don't think we really covered it last week uh but the long tail is interesting for especially in my lens Network uh appliances IoT devices that have implemented either a certificate that was generated from the CA and or trust that CA those are two different things and rely on that for let's say firmware updates right? I actually one uh of my coworkers pointed out that man in the middle proxy has added capabilities to exploit this particular situation Although it's a vulnerability but this exposure uh so that you could man in the middle because SSLs it's hard right? Like if a device is using SSL properly it's really hard to insert your own firmware update. I talked about this I believe when I did the IP KVM research I said you know they did a really good job. There was a time where it was using HTTP and I thought I had a disclosure but then they switched to HTTPs and implemented it well but now with this depending on the your in Linux like your CA certificates package or if you have actually one of these certificates that was generated with that ca your device is in trouble. I think all of the you know, browsers and workstations and servers like my I immediately went on my Linux box and I did the revocation list so that I did not trust certs from from it were generated from that ca. That was pretty easy. Then the next day I got an update to my CA certificates package which fixed that in uh a normal course of business and most Linux distros when you know all the brow again all of the normal software did devices not so much Zero trust is clearly the future as threats get faster, quieter and harder to detect but implementing it shouldn't disrupt the business. Threat Locker enforces default deny at execution in a way that remains enterprise ready, scalable and operationally clean. Unknown software is stopped cold. Trusted apps stay contained and drift is locked down across the environment. It's zero trust that works in real enterprises and prepares you for the threats ahead. See why CISOs are adopting it@securityweekly.com threatlocker
Speaker B: yeah and that's the kicker for post quantum cryptography as well is which devices need a forklift upgrade.
Speaker A: Mhm.
Speaker E: I
Speaker B: mean and
Speaker E: also PHP vulnerability.
Speaker B: Oh my God, don't even get me started on that.
Speaker E: Yeah,
Speaker A: sorry, go ahead Sam. Um,
Speaker E: so a lot of IoT devices with PHP in M them and TLS that's not updating
Speaker A: in broadcast node.
Speaker B: And how many IoT devices can't take uh, a certificate revocation list or have read only memory for their firmware code signing key
Speaker A: or just their end of Life
Speaker B: or end of life,
Speaker C: not going to get support at all.
Speaker A: Right.
Speaker B: Yeah. And so what you've got is you've got a significant universe of devices that will not update and are going to remain vulnerable for the foreseeable future. And uh, are you going to tell all of those utilities, chemical plants, uh, and houses with ancient nests, whatever.
Speaker A: How do you find those, Josh?
Speaker E: Uh, by the way. Yeah.
Speaker C: You wait for them to get
Speaker E: exploited.
Speaker C: You wait for them to get exploited. I
Speaker E: heard about a scan of the Internet and they found that there's like Several, uh, million PHP servers and 40% of them are running out of support versions.
Speaker A: But I want to go back to the devices. Josh, I was throwing you a softball there. How do you figure out if they have those packages? Indoor certificates, Josh.
Speaker C: An, uh, S bomb. Come on, Josh.
Speaker A: Yes, thank you, Larry.
Speaker B: No, but here's the problem. How many SBOMs are being built by manufacturers right now for IoT, OT?
Speaker C: Not enough
Speaker B: IIoT, IOMT, et cetera.
Speaker C: Not enough.
Speaker B: More of those. And we need to have SBOMs that are double checked by an independent authority. Because I'm not gonna say that manufacturers lie on their sbombs, but I'm gonna say that
Speaker C: manufacturers lie on their S
Speaker B: bombs. Do
Speaker C: manufacturers.
Speaker B: Look, Larry said it, it wasn't me. Okay.
Speaker C: Hey,
Speaker A: or they're, or they're incomplete. Right? This, the C bomb or cryptography bomb is super important here. When I saw the Mundra stuff come out, I was like, I need to know on these devices. We've had this conversation, Josh. I believe on air as well.
Speaker B: Yeah.
Speaker A: I need to know what kind of cryptography hashing algorithms, certificate trust, like that all speaks to the integrity of that device. The uh, root of trust for that. It's part of the root of trust for that device.
Speaker B: You know, it's, this is very interesting because when. Let's talk devices just for a minute. You're right. Let's stay on devices for a second. When you, uh, build a new device, how many devices actually are able to be updated on their certificates, their code signing cert, their, their, their device or anything? And, and the answer is not very bloody many.
Speaker A: Well, there's more than they're used to. There is a trend to have that update ability. But there's different classes of devices, I think is what you're referring to, Josh,
Speaker B: that you're correct,
Speaker A: aren't meant to be updated like that.
Speaker D: Yeah,
Speaker B: I mean, and everybody here has run into that.
Speaker D: Yeah,
Speaker C: yeah.
Speaker B: And I mean and Lee, on the, on the government side and on the national lab side and on the devices in interesting and unusual places. How often
Speaker D: do interesting things.
Speaker B: Yeah,
Speaker D: yeah, but here's the thing. Um, we have. I've run into those devices and our number one mitigation is isolation.
Speaker E: Right.
Speaker D: Um,
Speaker B: segmentation. Isolation. Lock them off,
Speaker C: can't reach
Speaker D: air gap. Really? An air gap? M. Yeah, you put them, you make it very hard to get to them. It's not 100 fixed, but it is. The most common thing you can do is to. Is to limit access to them. Um, I mean now I'm forever saying limit access management, but ideally a limited access to the whole thing. So only that absolutely necessary needs to get to it. That kind of gets a little wonky if I say I'm putting a device, a sensor out and a. In a tree with a cellular modem. But I can get a, uh, data service that's on a private network. Is it perfect? No, but it's not on a public network. You know, it's the old defense in depth. You take the wind, you can find them and then you hopefully get enough of them layered up that you don't get tipped. Oh, and then monitoring, of course. Um, by the way, what's really cool is before I retired, there were some products coming out there for IT IoT network monitoring that understood the protocols. Remember in the past they were talking protocols that your standard network monitors had no clue what they were. So these understood the protocol and they could detect anomalous traffic and not just stuff that wouldn't be there, but like somebody's messed up the protocol. It's not legit and that's huge. Unfortunately, they want too much money for them. But it's really cool capability. I imagine
Speaker A: I could write something and give it away for free that would help you on that. If it's mqtt,
Speaker D: uh,
Speaker A: Pixie, uh, or what's uh, the other one that I
Speaker B: run. Zero has a community edition. So there's like 12
Speaker A: IPMI. Thank you for reminding me that IPMI. If it's any of those three protocols, you're vulnerable and you're screwed and you should turn it off.
Speaker D: Right. But. And then. But
Speaker A: very easy.
Speaker D: I could prompt. I could vibe code that realistic real
Speaker A: fast.
Speaker D: Right. Seeing it there when it's not supposed to be. Right. Or that it's being done, it's being. A
Speaker A: lot of these
Speaker D: protocols don't. Right.
Speaker A: Maybe the. Is the mqtt, the one that is in. Am I getting that acronym correct?
Speaker D: That's the right acronym.
Speaker A: Yeah.
Speaker C: Telemetry. Uh,
Speaker A: yeah, that one still is in use, but there's a Lot of older protocols that have been superseded, uh, by newer protocols which arguably have their issues. A lot of these older protocols are based on really old reference code. Old, older code in general. Uh, and they are producing a lot of vulnerabilities. I don't know Sam, which you had a, um, UEFI related story, but I think yours was, was black.
Speaker C: Before you jump on, we spent a lot of time talking about math and I, I just. There was a typo in um, Sam's ah, story number 12 that I just. It grabbed me because he referred to mathematicians as mathematicians.
Speaker A: Different.
Speaker C: I wonder if maybe we could start referring to AI solving these math problems as mathematicians.
Speaker A: Yes.
Speaker D: Oh,
Speaker B: mathematic.
Speaker D: Well, we can definitely claim AIs on meth.
Speaker B: Methomagicians.
Speaker E: Yeah. Well, anyway, I want to hear what you have to say about the uefi, Paul, because that's your thing.
Speaker A: I think the most interesting thing here when I was analyzing this one and again it's hard for me to go deep on all of these because there's been so many major uh, vulnerabilities announced. Um, so this one is on my radar. It is on my list to prioritize. Um, however, if you followed the guidance to protect against Black Lotus, you should also be protected against this now, maybe not 100%. Uh, as I'm still digging into it, uh, I think the big thing is to take the Microsoft PCA 2011 cert and put that in your DBX, in your, in your revocation list. That's the big thing. Um, because they will work together. If you have the newer Microsoft certs and the older ones you do gain some level of protection. But you need to take the older expired Microsoft starts now and start putting those in your dbx. So I'm constantly reviewing the logic of our uh, detection rules at eclipsium to make sure we got it right because it's a very complex decision tree. Uh, it's a matrix, right? Of well, if I have this sort and I have this sort, but I don't have this in the dbx, then that means there's some condition of I might be vulnerable. I might not be vulnerable, right? And there's an entire matrix, uh, of it. I went through that in pretty good detail in the blog post that we ran, uh, on eclipsium. I actually refer back to that blog post because I get confused. Like if you haven't looked at it in a while, you're like, wait, if I have this chart and that sort and this DBX thing, like it's, it's very confusing, but I think that's what this new malware was preying upon was that you hadn't applied all the mitigations because they all don't come down in Microsoft Update. Hopefully that changes. Uh, but I think Microsoft is hesitant to do that because you want to break something that relies on that certificate. So if you start moving DB or DBX certificates or uh, I'm sorry, PK or KEC certificates into your DBX, those are meant to validate things like option ROMs. And so the example I love to use is what if your graphics card needs an option rom, needs a small piece of code that gets loaded in early stages of UEFI to go. Here's how you interact with my graphics card, which you need in order to see the screen. If that driver or option ROM driver is signed with something that you've put in your dbx, secure boot is going to go like, you can't load that code. What are you talking about? It's uh, not blessed to work with secure boot and it's going to halt the boot. And for some organizations the halting of the boot is riskier than taking the risk of having a pre os, uh, infection on your hands, which I get that, right? Like there's risk is, you know, you guys all talk about risk in different lenses. When you put the risk lens on it you're like, well yeah, you gotta make that risk based decision. So in. But I think that's what the attackers are preying upon, is that mismanagement, uh, to get this boot kit in there.
Speaker E: And so how likely is it that you will get a pre boot, uh, infection, considering how big that risk is?
Speaker B: Well, it depends on how many times you've had sex with it.
Speaker A: It's. I'm sorry,
Speaker C: I mean you're not
Speaker A: wrong. Not wrong. Um,
Speaker D: let the record show that Josh is lonely.
Speaker A: Here's my take. It's more likely at a lower level that threat actors will abuse drivers. Uh, regular Windows drivers, not Dixie UEFI driver, but regular Windows drivers to circumvent Windows, uh, and like EDR protections. Right. I see that as a reoccurring theme, uh, in threat actors. Like if I need to get around protection or implant in a system and I don't want to get caught, I'm going to take advantage of a driver that's already on the system that has those privileges or I'm going to bring my own driver, uh, and it has those capabilities and it's signed. So therefore I can use that driver to get around Protections, that's more likely. Uh, less likely is something that is actually in UEFI before the bootkit would take advantage of it. So actually exploiting things in uefi such as the new pixie vulnerability via ICMP that gets you code execution in UEFI even before uh, it would impact the bootloader stage. So I kind of draw the line at Exit Boot Services. So basically like your computer does a bunch of stuff even before UEFI loads. UEFI starts loading and initializing the hardware and it does all the things it needs to do. And there's multiple phases in there. Uh, and there's like this one slide we all have. If you're going to present uefi, you have to have this slide about how it works, right? But then at some point in UEFI it goes, hey, I've initialized everything and it calls Exit Boot Services. Exit Boot Services is what loads the bootloader. The bootloader loads the kernel kernel loads the rest of the operating system. Um, so more frequently occurring again in Windows drivers once the operating system's loaded. Um, that middle ground is boot kits taking advantage of the bootloaders. Uh, less common these days is actually code execution and uefi. However, we do have vulnerabilities in uefi, uh, as a big one was announced, uh, just yesterday. Actually it was announced well before that. What we should talk about, uh, someone AMI made an oopsie uh, and put the fix into EDK2, the reference implementation uh, for UEFI, uh, which is open sourced Tiana Core, uh, EDK2 is an open source project, is the reference code that all of the uh, like IBVs. So you're inside AMI Phoenix use to build modern UEFI firmware. Um, so the vulnerability was in the reference implementation which is open source, which means the pull request that was put in a few weeks ago, it was public and anyone can go read it. And so I, I read it and I was like, wow, that's an interesting vulnerability that no one has talked about or disclosed yet. Hmm, kind of interesting. Then the Ars Technica article ran yesterday, kind of announcing that to the world that Houston, we have a problem. Basically any attacker that can slip an ICMP packet into a system while it's booting in Pixie boot, if it processes that packet, can cause a memory corruption flaw and gain code execution in UEFI again before even your bootloader loads. So I don't think it's necessarily the end of the world. Like I'll be honest and I work in this space, obviously. And I would be, uh, it would be advantageous. It would be of benefit to me to say that this is really bad and it's the end of the world. Um, but that's not what I'm saying. Uh, like you, there's a timing thing. You have to send this packet when a server is booting, uh, in that Pixie environment. You also have to be, it has to be network reachable from somewhere. Uh, in order to do that, uh, also you have to tune the exploit for the version of uefi. Uh, because not all UEFI is created equal. Every uh, it goes through multiple customizations, it goes from reference code to am. Let's just say AMI making modifications to it, then AMI handing it off to a del Le Novo hp. They make modifications to it. All of that changes a lot of things. Um, that, I mean that's basically the foundation of the company I work for is like once you understand those things you can accurately identify exposures, vulnerabilities and threats. But understanding that, I mean Eclipse has been in business a long time and has a huge body of knowledge to help us understand that. So I uh, don't think this is earth shattering. Is it something you, you're going to fix? Yeah. Uh, do you have fixes yet? No, uh, because that takes time. Ask me how I know this because we've done many vuln disclosures in UEFI and they take time because of the supply chain, uh, of uefi. Um, so there's that. Uh, and I think for now you definitely need to disable Pixee boot if you're not using it. That should be part of your UEFI hardening strategy. That has to be disabled. Um, the second thing is you really got to restrict the network uh, that your servers are on that would interact with Pixie boot. Not just from this, but Pixie fail showed that too. Right. There's a previous disclosure called pixifail which was similar, um, similar attack, uh, Surface if you will. So protecting that environment is very important. Goes back to what Lee was saying before about isolation, uh, and proper network segmentation and network architecture. Um, and you know, short of that it's still somewhat opportunistic. Right. But so like most of us don't have Pixie enabled and I heard a lot of people call that out. Um, even in like previous disclosures, uh, Yvonne Arce is quoted as like most people aren't using Pixie. However, it's pretty heavily used in like cloud and server environments. Cloud especially. That's how they're loading stuff on these systems is via Pixie, so still has its pretty big pockets of usage that are somewhat concerning.
Speaker D: Yeah. One of the things because I was thinking about, I was looking at uh, Sam's story and you mentioned my government background Sam story number three and number four caught my attention because of my background number three was that DHS is banning Deep SEQ from federal Agent Huge. Which my comment there was what took them so long? I thought they already had. Although government contract rules pretty m make it hard to buy software like that from China to begin with.
Speaker B: It's free,
Speaker E: but it's
Speaker D: not
Speaker E: only Deep Seek, it's anything developed using Deep Seq,
Speaker D: which
Speaker E: might be a big problem.
Speaker B: That's the Quinn, that's the Cami. That's a lot of them. Yeah,
Speaker D: right. And then to add to it, his number four story is about one that decides to change what it's doing when it finds out it's from a US contractor. Which exactly is the risk that they are one of the risks they worried about. Deep sea.
Speaker A: I love, I think that's fascinating. Uh, it has that awareness built in. What are they saying? That if it's a US contractor it figures that out and makes more vulnerable code? Basically
Speaker E: no. If you tell it you're using a US contractor then it writes more vulnerable code. And I don't imagine this to be deliberate. I think this is just a consequence of training on like Chinese Internet which is probably full of anti US stuff.
Speaker D: Interesting. True. But yeah, you, but the fact that the behavior changes is like oh, um, uh, yeah, by the way, the open source comment is valid but there's still uh, a due diligence where you're not supposed to get stuff from the wrong places. But when it's.
Speaker E: I think most American companies are in fact using the open source Chinese models now.
Speaker D: I think that's. It's very common.
Speaker A: It's very common.
Speaker D: But let's keep it out of our government systems. We gotta. I mean what, what else do you do when you want to see what they do?
Speaker A: What else you do when you want AI to write you an exploit?
Speaker D: Yeah, yeah, yeah.
Speaker A: I mean I've talked to other very, very accomplished and senior security researchers who also have their CLAUDE accounts Even though they're CVP drop down to Opus4.8 and refuse to do things. I'm like, oh, I thought like I was the only one that was kind of like picking on me. Um, and it does
Speaker E: that you get in their special project where you get the unfiltered one.
Speaker B: I have The CVP it is. There's actually another level of Red Team Attack and that's the bitch to get into.
Speaker C: Yeah. Guess what? I got extra.
Speaker A: Yeah, I'm not sure if really I'm in the Red team. I uh, know for Daybreak, I think it's just blue, not red. I think we're still working on getting, we're always working to get more and more access to these models. Uh, but even with certain levels of access, it'll still block you.
Speaker D: Mhm.
Speaker B: It also changes.
Speaker A: And so I've seen people go, hey, look, I created an exploit for php. It works. I tested it and I used this local model that was obliterated.
Speaker D: That's kind of cool.
Speaker E: Yeah. But
Speaker A: again that comes down to. I don't know if it was Josh or someone. I think it was you, Josh. That was saying like people with the experience with AI get much better results.
Speaker B: Yeah.
Speaker A: The PHP to shell is a classic example of if you're just like a junior exploit researcher, you're not going to create a reliable exploit even for something as widely publicized as PHP to Shell. But when I go to my senior researchers, they're like, oh yeah, like that's the first thing I did was use AI to create a working exploit. Like, here you go, like, sweet, we're off to the races.
Speaker C: And I think,
Speaker E: well, this is where I would like, I would like to hear your comments on what about people that. Middle managers that think they can fire their people and replace them with the AI. I'd like to hear what you think. That
Speaker A: depends on the position.
Speaker B: I'll take that one. Um, and I'll be honest, it's a complex answer. So bear with me. Anything that is heavily decision supported is gone. Tier one, tier two help desk. Kiss him goodbye.
Speaker A: The sock. I hear people using this phrase, agentic sock, and they're saying with AI, it's like I have five or 10 people on my sock, but it's just me and a whole bunch of uh, MCPs and agents.
Speaker B: So, uh, SOC heavily decision supported up until you get to the actual threat hunting it is really honestly just checking lots of tabs and compiling and collating information. AI does collation of information instantly. So yes, level one, I don't know what you call level one SOC agents, but you know what I'm saying, Like level one, level two SOC agents just like tier one, Tier two help desk people gone. Uh, which also means, by the way, and the interesting part here is that when you get rid of level one and level two SOC agents, how do you get senior SOC people.
Speaker A: Yeah,
Speaker B: that's the big problem. I see. But for right now, they're just out there in the job market. And the poor people. The job market sucks. But, um, it's literally, it's like, okay, so anything heavily decision supported, anything that is a, that you could flowchart the job and do 99% of the job for the flowchart, they're gone. Okay, um, what does that mean in terms of pen testing? Honestly, most of the people that just follow a protocol, they're gone. The people that are talented, that are intuitive, that are not just methodical, but also, uh, but also have intuition.
Speaker C: Creative.
Speaker B: Creative, thank you. That's the word I'm looking for. Sorry.
Speaker A: Yeah, because AI,
Speaker B: it's not
Speaker A: creative. Yeah, you're absolutely. Exactly.
Speaker B: They're going to be fine, but they're also going to use AI to magnify their efforts. And that's what we were talking about before. Lee, I'm sorry, you're holding your hand up. Go for it.
Speaker D: Yeah. The corollary to this is for those people that aren't those tier 12 people to stay employed, they need to learn AI
Speaker A: because
Speaker D: the folks that are going to have the job know how to win with AI. I'm not saying it's the beat all end all, but if you say, no, I'm not going to touch AI, uh, you're a step closer to the door.
Speaker A: I 100% agree. People need to. If you're in cybersecurity today, you have to be expert level AI or at least approaching like committed to, uh, AI technology 100.
Speaker C: And I'm going to throw, I'm going to throw something out there and I think part of the reason why. And I'm looking at this collective group here and you know, talking to this collective group because I know you well. Uh, but I'll also pull that out to a lot of the. Some of the senior, uh, some of the security. Senior. Senior security engineers that, uh, you know, we know how to use AI and we can be effective with AI. We were talking about this whole coding thing here, um, because we are senior and we've worked with junior engineers. So at sector I was having this great conversation with Jamie Arlen and that we were talking about like how we use AI and it was very much a. You. We are talking to. And I'm using talking metaphorically. Right. We are talking to AI as if it was a junior engineer that you have to get it a very specific set of rules. You have to ask it for some very specific things. You have to give it a little bit of rope to hang itself, but to be creative in the way that it can. But you also have to tell it the kind of output that you are expecting.
Speaker A: Mhm.
Speaker C: You can't just let it go. You have to say okay, well it needs to have these types of things.
Speaker B: You can let it go and go crazy, uh, and not tell it the format of the output you want. But, but then you have to say okay, you did this and I see why, and that's interesting. But what our client expects is this or, or, or, or
Speaker C: the goals.
Speaker B: Yeah, you have, you have to, you have to. But you, but letting it have imaginative moments are actually useful because sometimes I will learn something, sometimes I will use it. I agree.
Speaker A: It's getting, it's getting, it's getting better. I find when it not necessarily hallucinates but makes decisions on its own, they are better decisions. No,
Speaker B: that could be much better. Yes,
Speaker A: some of that could be. We're better at prompting it as well. You have to factor that in. But
Speaker B: I, I also, I'm sorry,
Speaker A: I want to give an example at some point, uh, when we talk about one uh, of my stories about PHP to Shell being on network appliances and my experiences with AI and validating that. Super interesting.
Speaker B: I, I want to point out one other thing Larry, is that every single one of us here is, is a parent. And the way you deal with the junior engineer is the exact same way you deal with a five year old. Okay. Oh, here's what I want you to do. Let me walk you through all the steps. You're going to cut the tomato with the knife, push cutting away from yourself, using one hand to hold onto the tomato and the other hand to hold the knife. And this is, we want wedges, not slices. And you know, it's uh. But I mean, I know I'm sounding silly, but the point is, is that it's the exact same freaking thing.
Speaker C: So it's like.
Speaker B: And we learned how to guide.
Speaker C: Yeah, it's like. Well also
Speaker A: I, I have it asked me questions too. And I think maybe I don't so much do that with my children when giving them instructions, but with the interns and junior people, I definitely tell them, don't get stuck too long, ask me a question. And I think it's different when I'm interacting with a human than in LLM with a human I'm like, figure some stuff out on your own. Try and figure out, then ask me a question. With LLMs, I'm like, here's what I want you to do. And by the way, ask me questions so that we can make this great. Right. And that is a little tip that I learned. Uh, I don't know how I figured it out. I just started doing that maybe because I'm lazy at prompting, but I'm like, I don't want you making too many decisions on your own. When you get to a decision point, ask me what you'd like me to do with it. Now, I would say roughly 65% of the time, it's top thing. That is asking me the. In the answers, it'll have like the top choice and it'll say recommended like 65% of the time.
Speaker C: Yeah,
Speaker A: yeah. Like,
Speaker C: that's, that's what I
Speaker A: want you
Speaker C: to do. Yeah,
Speaker A: right. The other times I'm like, no, no, no, no. I want you to do maybe one of the other options or it gives you a multi select or there's an other. And in the other I'm like, uh, I want you to do some combination of those or I want you to do something different or
Speaker C: you're so close,
Speaker A: like, don't worry about that. Ask me again. I'm gon something. Collect your answer and then feed it back to you. Like, don't worry about it kind of thing. So I'm gonna go run a command or, or read some document or ask someone and then get back to you.
Speaker C: And I think that's because we're really good at giving those types of instructions, like to kids and to junior engineers and so forth. It reminds me of the two kind of me things that I saw lately. It was a dad going over homework with his kid, and it was about how to make a peanut butter and jelly sandwich. And the kid gave step by step instructions. And the little clip that I remember is, it says, uh, the dad says, step one, put knife in the peanut butter. He takes a knife and he jams it in the peanut butter, handle side in. And the kid is like, horrified. Like, ah, that's not how it works.
Speaker A: Right.
Speaker C: That's what you told me to do. You didn't give me more defined instructions. And
Speaker B: I use that all the time.
Speaker C: And it
Speaker B: goes. And I, by the way, I used it on my kids.
Speaker C: Uh,
Speaker A: but I think
Speaker C: it goes in the square hole.
Speaker A: Yeah. All of us have been using computers for so long and we know they take things very literally when we're writing software. Especially like the computer does what you tell it to. The LLM is going to do what you tell it to. And we have to be very specific.
Speaker C: Uh-huh.
Speaker A: Uh, with what we tell it.
Speaker C: And one of the things I think we need to get really specific about and this has really been grinding my gears lately. Sorry Lee, I cut you off. Is
Speaker D: that
Speaker C: every. I can now tell when an app has a GUI and it's been vibe coded. Why? Because they all look the same.
Speaker A: Yes.
Speaker C: Can we tell it to put some variation in some of the stuff
Speaker A: you can uh, in Claude. I've had great success with the. There's a Claude plugin, uh, or skill, uh, UI design skill.
Speaker C: Okay.
Speaker A: It's in anthropic. Created it. Yeah. And but when you get that you can describe how you want the interface to look. So like I did one that um, let uh, me like customize stuff like files for work and then I was like, I want this to look and feel like a traditional like bio screen. And it did it stylized it and colored it like a traditional bio screen. So you can, if like you don't give it guidance like you said Larry, it's going to give you the standard, uh, it's going to look the same. But if you enable that skill and you give it a little guide, just a little guidance, it'll. It'll look very different. I actually really liked that. The humanitarian. It was pretty good.
Speaker D: So I've been working on an analogy here and I think it doesn't work. Is what you guys. Well, it's what you guys. Because I've been sitting here thinking, you know, what the results you get, you catch what you bait based on what you bait your hook with, right?
Speaker A: Yes, correct.
Speaker D: And which is great if you're a fisherman, but I think your other analogies, you know, the talk to it like you're talking teaching a five year old.
Speaker A: Yeah, but it's deeper than that. Uh, I think it's getting more advanced than that.
Speaker D: I think we're
Speaker A: beyond this conversation is like talking to our children. And I think. But we've I think progressed beyond that. And the example I have is my coworker, um, my coworkers are based in uh, Portland, Oregon. Uh, and they had uh, a B sides out in Portland and there was an intel engineer who I think I've interviewed before they gave a talk. So go look up the talk, uh, about creating agents, uh, to hunt for vulnerabilities, uh, in the gist of it, was not letting your context fill up and get too focused, was to create multiple agents that are reviewing your inputs and outputs so that your context doesn't get filled up. Because what happens is your context gets filled up and it's like, oh, I'm going to go down this path and look for a vulnerability and it kind of gets tunnel vision like so this is what I know how to do, this is where I'm going. But if you don't fill up your context window and you have agents that kind of break that out to go look for this one specific, then, then take that output, go follow off to other agent that has somewhat of a much smaller context window or unique context window. It'll go off and do that text, uh, that task, then feed it back. So, uh, it was a strategy not to fill up your context window to give your, uh, you know, session. You're avoiding bias. And what also they said was create, um, new sessions so you get a fresh, a fresh context. Same. Right? Keep working in the same. There are benefits to working in the same context. But I think it was more about split. I haven't watched the talk yet. I'm just going off the way, uh, my amazing co worker, by the way, Jesse Michael, who was quoting the ARS technical article, I love my co workers, all of them are amazing. Uh, he was at that talk and sent it to the group today, was talking about it, uh, and saying we should learn from it.
Speaker D: Right. I mean, but that's, to me it seems really, I mean, not having seen it, of course, but yeah, uh, how to not introduce bias. I mean we all
Speaker A: get,
Speaker D: we all put on blinders sometimes. That's not always on purpose, but to be aware of that. And then here's what you can do to mitigate it. That's awesome. I mean, we spend a lot of time teaching people not to pay attention to the drunk five year old. But the other thing is to make sure you
Speaker A: don't
Speaker D: constrain it too much because then you miss things.
Speaker A: And maybe the analogy, Lee, is you've got a team of interns, not just one intern. Uh-huh is the kind of way to think of it. And you're breaking up the work. You're like, you know what? Intern A, you're doing this. Intern B, you're doing this. And by the way, when you get a result, share your results. Uh, you know, back to the, to the whole team
Speaker D: with one more. One more. I'd add one more constraint on top of that. It was something, I don't remember whether you or Josh mentioned it a couple minutes ago, is you've raised kids, you have a finely tuned bullshit detector.
Speaker A: Yes.
Speaker D: It applies in cyber. And it, um, we've all said if it looks too good to be true, that's your freaking bullshit. Detector, use it especially with AI because it's going to serve you. And oh, by the way, that, you know, you've got some well earned gray hairs that go with that, so might as well, might as well own it, right?
Speaker A: Speaking of AI, while we still have Sam here, your story number six was titled LLMs are making more formal Software verification feasible at a Much larger scale. I have to say I've experienced this. So as I use AI at my job, um, one of the things that I work on, uh, as you know, my role at Eclipsium is I'm like, this is happening in the threat landscape. Maybe someone's written an article that says, hey, we observed these IOCs and TTPS and we wrote about them. I'm like, great. I want to enable our customers to go hunt for and find those same things on their systems. How do I do that? Uh, well, I use AI to go analyze the code base, analyze previous tickets. How should we construct this kind of thing? Sometimes it'll analyze like an existing rule or whatever and go, uh, yeah, by the way, that rule has this one condition where it could introduce a bug. And I'm like, oh, that's really, like, I didn't ask it to do that. Which is kind of scary but also kind of interesting that as it's going, it's also QA what we have, uh, in helping improve our existing code base while helping define, uh, ways to create new features as well. And I can't be the only one experiencing this, right? I'm sure lots of people, because like, I didn't tell it, go find bugs in, in some existing thing. I told it what do we need to go create something new. But in that process it was like, oh, by the way, like this will never fire because of this new condition, you know, kind of
Speaker D: thing.
Speaker A: Which is pretty awesome that it's kind of qaing software as it's helping define new features in software.
Speaker D: So I'm having flashbacks to interactions with developers when we were trying to do code, uh, testing before release and there was always, you know, we can't test every feature, we can't fix every flaw. We've got a partisan. It sounds like it blows the doors off of that.
Speaker A: Well, and humans will find that too, I think, just at a slower pace. To your point, Lee. Right. Actually what I thought you were going was like if you task a developer to go write a new feature, they may look at other modules that have similar features and, or libraries that they want to rely on and go, oh, by the way, I just Uncovered a bug in that thing. It's like while I was creating this new thing, I realized our existing thing had a limitation, a bug of some kind, uh, and we ah, need to fix that too.
Speaker D: Don't forget to include the Larry Vibe coded ui.
Speaker E: Well, well, this article is not about that level of fiction. Now
Speaker A: I lost my cigar.
Speaker E: It's at a deeper level. I mean, the point is, if you have their mathematical, um, proofs. Most mathematical proofs are not really proofs from first principles. They're just arguments to persuade other mathematicians. There are only a few things. I found it. I found
Speaker A: it. Sorry.
Speaker E: That's good.
Speaker A: I
Speaker E: lost my
Speaker A: cigar.
Speaker E: There's only a few things that have ever really been proven from the original axioms. And that's what this is. This is an incredibly laborious process where you go through every step of the software and you state your security conditions and you make sure that every single step never violates your security model. This is uh, more than a year of work for a human. But now they can do it with an LLM. And what this means is if you write down your security conditions, you can have a 100% guarantee that this software will never violate those conditions. So you could have essentially perfect bug free software. And that was just out of reach before, and now it'll be in reach.
Speaker D: That sounds too good to be true. I mean, I know we're talking about AI and new capabilities and I'm not questioning you, Sam. I'm just like going, what the hell? I mean, man, I'd love to see that in action.
Speaker E: I know, and that we may see it soon. I mean, this is the kind of thing that's been out of reach and uh, of course there's always something that can go wrong. One thing that occurred to me is that you have to define your security conditions and you might not think of everything there. So even though it obeys the rules you specified, it'll turn out you didn't think of something. But still, I think this could be a giant leap forward. It should remove like almost all the CVE type bugs that we're patching. You'd know that there are no mistakes in there that violate your security policy.
Speaker D: If, if you've got to get the, you know, you got to get the support and willingness to actually do it. Like you said, you've got to get it right. But
Speaker E: it's
Speaker D: ah, going to move the bar no matter what.
Speaker E: Yeah. If this becomes a, this is a code scanner you could run then instead of going on a list of CVEs and trying to see if it has unknown problems. We'll just make sure that this code absolutely obeys these rules. It's a whole different philosophy of scanning code for bugs.
Speaker A: Yeah.
Speaker D: So Paul, I'm not going to be able to s printf anymore.
Speaker A: Right. We have skill, but we have skills that do that too. I think I talked about it on a previous show that if you're developing software, you should collaborate with your team. Uh, develop skills as in LLM, um, specific skills, not general skills that help you create more resilient bug free software. Uh, and there's probably. You know what? I bet if you looked on the Internet you could probably find other people's skills that would help you with that as your starting point and then tune them to your point Sam, to your own specifications. Right. To your own software environments, standards, that kind of thing.
Speaker D: So I kind of have a zinger for Sam that's not related to the story. Exactly. And that is you've been doing a lot of intense following and research on AI, uh and what it's doing. And I'm thinking as we're talking about this secure coding stuff, I'm like, what's the impact been on teaching people secure development? I'm trying to keep it narrower than what's an impact. How's it impacted your college curriculum? I mean that's a huge thing. But I'm thinking is it really impacting it there or is it still in the business world and not made it back to curriculum?
Speaker E: Well, I can't really say. I'm not teaching secure coding at any of my colleges. I was doing it as a contractor for a bank and they were supposed to call me back and they didn't about a year ago, uh, because I think they imagine they're just going to replace all their developers with AI,
Speaker D: all their tier ones. Yeah.
Speaker E: And so I, but I mean this has been a problem for my entire career is that we don't teach secure development. And every time I try, people aren't very interested and it doesn't get very far.
Speaker D: That's too bad.
Speaker E: I don't think anybody knows how to teach secure development in a way that really works. It was pretty good run at the bank for about a year teaching their people, but uh, they moved on to something else. I think, uh, probably if I was running the bank management, I would say rather than teaching our developers to write better code, let's focus on giving them AI tools. Right now that's probably our number one priority. And then I think the thing to do would make An AI tool that writes more secure code would probably be the
Speaker D: most
Speaker E: impact you could accomplish now.
Speaker B: Or review code for security improvements. Well,
Speaker D: which is kind. Which is in parallel with this article. I mean
Speaker B: I will tell you that I teach. I mean I m. I teach the bank examiners how to ex. How to audit, uh, code and uh, um, SDLC and code building and for security. And a lot more of it is about the AI aspects of it than I've ever been before.
Speaker D: AI and auditing or the use of AI,
Speaker B: of course.
Speaker D: AI supporting those process or using AI to root out anomalies.
Speaker B: Um, AI supporting the process of code, uh writing the process of being software engineers. They're not using AI for the auditing. They're just not.
Speaker D: Yeah, I had this wild idea they might. That's why I asked.
Speaker B: No,
Speaker D: they're not up
Speaker B: to speed there.
Speaker D: Well that'd be good for correlating lots of gathered data points and stuff, you know. But. Yeah, it's interesting though. It's, it's kind.
Speaker E: You wouldn't like it. You wouldn't like it when you're auditing AI hallucinated stuff though.
Speaker D: No,
Speaker A: it's getting better at not hallucinating.
Speaker D: Um.
Speaker E: Yeah.
Speaker D: Oh, Paul, you're drunk.
Speaker A: No, I'm, I'm being serious. I'm not drunk yet.
Speaker D: I'm being. I, I'm being a uh, you know, not. But yes, I, I have. The bar is moving. It really is.
Speaker A: Well, I'll give you, I'll give you an example. Uh, one of my stories uh, was super interesting that I found today. Um, and that is where is it? Number two is really interesting, is also AI related. Um, hold on, where the heck did it go?
Speaker D: Well, I just looked at your story number 12. Damn.
Speaker A: No, there was one. Yeah. Uh, my story number seven chained PHP to shell exploit routes 25 servers.
Speaker C: That's it.
Speaker A: So this was a write up from Dream Group. Um, and uh, wasn't servers, it was firewalls. Actually the headline is somewhat misleading. Uh, okay, so basically they say uh, if you look at PHP to Shell, uh, and the Linux. A Linux fragnisia privilege escalation flaw was used to escalate privileges. They did uh, an incident response investigation and found uh, that there were 24 Internet uh, facing firewalls that were compromised. With that I was like really? That's interesting because. And they didn't name who the firewall vendor was. Like well that's interesting. As soon as I saw PHP to shell drop, I immediately went to my lab and my AI, uh session there and I said Tell me all the firewall vendors that most of which you have running in a lab environment and have images for. Tell me all of them that run PHP and how it's used, where it's accessed and you know what, tell me what version it is. Then go to the Internet and our databases and tell me which ones have uh, issued advisories for it, uh, yet. Uh, and at the time none of them had issued any advisories because it was so new. Um, and it found a handful of um, actually it's in this month's InfraTrust Pulse, which Firewall Network Edge appliance vendors have PHP and are likely vulnerable. And there are some suspects uh, in there. Um, Palo Alto was the first to issue, or one of the first to issue an advisory. And Palo Alto stated several days ago actually that not only are we vulnerable in php, but we've observed exploitation already. I'm like, well that's interesting. So when I read this Dream Research article, it was being cagey. It was like, I'm not going to tell you which firewall vendor it was, but here are some like IOCs and TTPS. And it had like, here's how the attackers uh, influenced PAM to run a command and here's how they bypassed Selinux. So I was like, dear Claude,
Speaker D: uh,
Speaker A: tell me which of these firewall vendors have php? It's vulnerable, maybe it's being exploited in the wild and we know that already. And which one of these meet the criteria of all of the artifacts that were listed in this article? And it churned for a while and presented overwhelming evidence based on one thing it did was like, oh, you have this Palo Alto pan OS running in a virtual machine and I can mount the guest file system as read only and read through the file system and see if all those artifacts exist on it. And I can go to Palo Alto's website where they have to disclose what open source software is used because of licensing and presented evidence like, yep, this is Palo Alto. And I'm like, that's pretty much overwhelming evidence. I think they're talking about Palo Alto. So then I'm like, okay, let's go create some PHP shell detections for all of these network firewalls. And that's, that's what it helped me. It helped me define and create requirements for going how do we hunt for PHP shells on network firewalls? And also it goes, given all the evidence that we have here, do you want to prioritize the ones that are specific to Palo Alto Bana West? I'm like, yes, please so great. I was like, oh my God.
Speaker D: The funny
Speaker A: thing
Speaker D: about that story, Paul, is when you were talking about PHP on a firewall, I was thinking php, uh, a firewall notoriously buggy. I always thought you were going to lead with Sonicwall, not Palo Alto, just. But then you said Selinux and I said that ain't Sonic Wall.
Speaker A: You know, I'm not sure if Sonic Wall, uh, it didn't come up in my research. And uh, again this is
Speaker D: not
Speaker A: the
Speaker D: first
Speaker A: time I've asked uh, my AI about PHP in specifically on network appliances. I don't know if SonicWall runs PHP. Uh, I have not seen an advisory from them. I've seen advisories from. It's in the Infrast Pulse, um,
Speaker D: Cold Fusion
Speaker A: and uh, could be, um, and let's see. So when I go here, uh, so we released the Infrast Pulse, uh, this week as well, that looked at a month's worth of data, um, from advisories issued uh, by uh, infrastructure vendors. Um, so confirmed, Palo Alto Networks and Net, Citrix netscaler are affected. Checkpoint, uh, with certain features available, then it kind of marches down the risk of the list. Cisco, uh, has some affected products. F5 uh, is affected. Uh, Dell has some, uh, and then it marches down the whole list. Fortinet I don't believe is affected. I have not seen evidence that uh, Fortinet has been uh, affected. Uh, but again this, this data is a little dated as vendors are doing their own investigations. We're learning, we're learning more. Uh, but certainly out of the gate. Palo Alto, uh, and Netscaler were the top two to be using PHP. Also Juniper's JWeb, uh, feature on their uh, routers is also using PHP. Um, then that was part of my thing that I was like the PHP thing is bad. I'm like, well how many devices are using PHP and are vulnerable and have to fix a good number of them? Not all necessarily like true enterprise. Um, so you got NetGate, OpenSense, you know, SonicWall is on there, is not affected. Lee. Uh, this data, this data was current as of October 24th by the way. So
Speaker D: that's close
Speaker A: enough. If you're listening to this, you're going, oh wait, I have XYZ vendor. And they just released the thing that's. It's just only because the data, like I could only be so fresh, uh, with the data as it's uh, developing. So
Speaker D: yeah,
Speaker A: Netgear has advisories published. So it's in there. I mean like many of these components, like it's in there. And I'm like, I knew there was going to be at least a few vendors that had PHP and uh, were vulnerable. And it makes it harder. I mean the whole gist of the pulse was basically uh, yeah, these are vulnerable. But guess what? You can't just go upgrade PHP on those systems. You have to wait until a vendor issues a fix so your hands are tied. So what do you do in the meantime? You either got to take it down or just hope that someone doesn't find it or firewall it off from the Internet. Certainly uh, is in the cards as well. Um, uh, but many people took their sites down. I don't know, people took their network appliances down, but this was so severe that the risk decision was leave it running and get popped or take it down and incur the downtime. Uh, which is really super interesting. Yeah, it's crazy to think about. I have a slide for tomorrow. Tomorrow I'm presenting at EINS Boston and I just modified the slide and the slide, uh, I didn't want to use CLAUDE to create my slides, but I was like, all right, what if CLAUDE could create my slides? My slides. And now I had a ton of context, right? Because I wanted to talk about two specific things. Um, one was PHP to shell, which I had already analyzed and written about, so I had a ton of content. The other one is something else I have a ton of documentation on. And I was like, all right, go create the slides. It created the slides. And I was like, those are really good. Like I'm gonna, I'd be, I'd be stupid not to use those slides,
Speaker C: huh?
Speaker A: And I've modified them so the slide that, it has a side by side comparison. If you have a Linux server that you control and you're running PHP and you have a network appliance that's running php, your response is different. Now for the Linux server it said like you control it and you need to uh, figure out uh, the upgrade to php, apply the upgrade to php, restart your web server and validate and test. In between each of those steps I put prey and make sure that it works. Because we've all done PHP upgrades and similar upgrades and you go, crap, I gotta upgrade php. So I'm gonna upgrade PHP and I'm gonna pray that worked. And then I'm gonna restore my web server and I'm gonna pray that it came back up. And then when it comes back up, I'm gonna pray that everything worked. And also I'm gonna pray that I don't have to do that. For a really long time. Again. Cause that super sucked.
Speaker D: Yeah, well, I, I just, just. I mean I was going through last week doing PHP upgrades on a bunch of servers that weren't critical and the sites broke in weird ways that were hosted by that one server. And I, I managed to fix most of them, but I can't imagine most businesses being comfortable with, uh, update it and then fix what breaks kind of for their main
Speaker A: Internet
Speaker D: point of presence.
Speaker A: So my battle scars are from when I used to manage and maintain WordPress and whatever. Whatever we had before WordPress when we were running securityweekly.com.
Speaker D: i
Speaker A: don't remember what
Speaker C: that was. Um, there's
Speaker A: some other CMS that no one
Speaker C: was. It wasn't. It was a Drupal. Wasn't Drupal.
Speaker A: It wasn't Drupal. Joomla.
Speaker C: No, it
Speaker A: wasn't Drupal or Joomla. It was movable type.
Speaker D: Oh
Speaker B: man.
Speaker A: I think that was also php. Yep. So I have many battle scars from. And then I found WP engine and I was like, this is great. I don't have to maintain all this crap anymore. And WP Engine sends an email to all of its customers and was like, we had you from day one. Like we implemented uh, basically WAF rules in other configuration that like the impact was next to nothing if you were a WP engine customer. I'm like.
Speaker D: Which is very thankful.
Speaker A: God, I made that decision years ago. Save my bacon.
Speaker D: Mhm. So you know, the funny thing was, you know, last week I had so many folks I was talking to that were in the throes of fixing php and I know some of them still are. And this week, all of a sudden we've got Broccoli Bratty
Speaker A: the Broccoli to Shell.
Speaker D: Although I read something that said they didn't like the name Broccoli to Shell, but it, I think that's going to stick. Um,
Speaker A: I thought it was great. It reminds me of a Wuang or Method Man. Light up the Broccoli Kid is a line from one of his songs. It's a reference to marijuana. It's hilarious. So now we have broccoli to shell.
Speaker D: I mean I'm, I'm, I'm cool with broccoli shell, but I'm trying to think, who was it that said they didn't like it? Uh, uh, uh. May have been the. I don't think it was the Node JS folks.
Speaker C: Whoever it was, they were wrong.
Speaker D: I think it's out there. It was my story number three. Yeah.
Speaker A: Semgrip had a Had a great article. They called it Broccoli to Shell. Um, and talked about like all the places it can hide.
Speaker D: Yeah.
Speaker A: So there
Speaker D: were a couple of really good articles, that being one of them.
Speaker A: Well because it's a library. So Broccoli
Speaker E: to Shell.
Speaker A: Jesus Christ. Library.
Speaker D: There's a broccoli to shell.com now
Speaker A: they talked about rebuilding chromium envoy.net all kinds of stuff uses the
Speaker D: Right.
Speaker A: This library Python has a library node, uh, bun, uh, has a bundled copy uh, of it. So you know, like all the other library vulnerabilities we've had to deal with. Um, I can't.
Speaker D: Once again there are so many simple as just updating that library. A lot of times it's embedded in something else until you wait
Speaker A: till the other thing. Uh, EDK2 ironically enough also embeds it. Uh, but it's not used. What I, what I read earlier and I haven't confirmed this, my co workers is that EDK2 does have a brotli, uh, instance. It has not been fixed. Someone disclosed a vulnerability in it, but the general consensus is that 99.9% of the vendors that implemented the reference from EDK2 do not include that, that library in their actual code. It was only like I think so in the comment this is how nerdy I get with shit. Uh, in the comments on the git commit for EDK2 that fixed it, someone said I think Samsung's the only vendor who ever implemented this.
Speaker C: Wow.
Speaker D: So one of the interesting things I picked up on the way looking at the brotli stuff is apparently it was like the vulnerabilities were identified in February and fixed but not identified as security update. So most orgs didn't pick up on it and do anything about it until it was what was it they, they did the um,
Speaker B: this is. There
Speaker D: was some research that found it.
Speaker B: This is actually interesting. Not, not about brotli specifically but the fact that it wasn't picked up as a security issue. So some orgs didn't really figure it out that they needed to do something. I mean we're, we're, we're running into this more and more.
Speaker D: I think it's the aikidobub blog that said don't call it broccoli. But yeah.
Speaker A: Oh, I think I,
Speaker D: we are learning this more and more that the. It's like be careful, make sure you identify security fixes so that people freaking pay attention. Although there's. You can lead a horse to water but you can't make it do the backstroke.
Speaker A: Uh, next JS uses brotli. NEXT JS is very popular. I've actually seen it on firmware based devices using NEXT React and NEXT JS as the interface which some could say is better than php, uh, as framework uh, in terms of security and uh, I have seen some fairly well locked down and secure you know React interfaces, um, the um, IP KVM stuff. A bunch of them are using React and NEXT JS uh in there and they were, they were pretty well secured. So like using a more modern web framework and adhering to the security standards uh, gives you a more resilient application. But so many places just haven't adopted that model. That mindset of the management interface for my device or appliance needs to be resilient and I think that's what's plagued us in that realm of IoT and network appliances is that web interface is very squishy, very squishy, very full of holes uh, in that web interface unless you actually you know, put some time and effort into implementing it in a secure manner. And also never using um, JavaScript web tokens. JWT, that's bad too. Although there's a spectrum on there too. Do you know how
Speaker B: many people use jwts?
Speaker C: All of them.
Speaker A: M. Most use
Speaker B: everybody
Speaker A: and most use it poorly quite frankly.
Speaker B: Ah,
Speaker A: because it's really hard to use it correctly. I think we ran a technical segment on that years ago uh, from a web application security vendor that I can't remember the name of link I bought and there was the guy from Sweden, what was his name? I think he presented on JWT and what I took away from that was really hard to make it secure. Right. But we see it in a lot, I see it in a lot of firmware based stuff, uh, jwt,
Speaker C: ah,
Speaker A: and React and php, all the web frameworks.
Speaker C: To give you an idea Paul, I'm working on an unethical disclosure thing now for an IoT device that I worked on um, and they're using JWT to do uh, authentication to the web interface for the device. Uh, turns out the manufacturer of this device just actually took the reference um, the reference code provided by the manufacturer that uses that and
Speaker B: no
Speaker C: turns out that the JWTs are predictable.
Speaker A: Yes, that's the problem.
Speaker C: The reference code and they're not only are they predictable is that you know the first one because it's part of the reference code and it's basically static. Static,
Speaker A: yeah. And it's a very common vulnerability and
Speaker C: you can predict the next one and the next one, the next one and when it reboots, it resets to the beginning.
Speaker B: The first one that's in the reference code.
Speaker C: The first one that's in the reference code. Which means you can predict the next one and the next one and the next one and the next one.
Speaker A: It's one of the first things I ask uh, my LLM to go test when I'm looking for auth bypass is if it uses jwt. Go. I have like a list of common methods. Someone asked me by the way. Uh, I did talk about like a harness for auth bypass. I do need to publish that. I do. I think that should be public. I just haven't yet. Give me time and I will. Uh, but that's one of the things I have in there Larry is if jwt then like try these dozen things that are very common uh, known exploits. Uh for jwt it's usually it's session handling basically.
Speaker D: Do you remember the old RSA secure tokens? The little thing with the six digit number on them that you would put in for authentication for a two factor authentication?
Speaker A: Oh yeah.
Speaker D: Early on you could predict, I don't remember whether it's the previous or next number which meant some of my guys who realized sometimes it took a while for the to get entered and then processed and validated with the prediction. They could catch what the number was or had been and validate the number that was entered was had been a valid number. You can't do that anymore. In other words, your number expired but the number you entered was fine while your session was there. That just took a long time. What could go wrong with that? Right, you can predict the next number.
Speaker C: Yep, possibly
Speaker D: she's no work no more.
Speaker B: I, I just, I can't. Like this is as bad as the imudra 4. Never mind. Oh dear God.
Speaker C: 4, 5, 6, 12. The illicit numbers was there was like it was reminded me of the uh, the number station in Lost because they were all two digit numbers. Well
Speaker A: it gets, you know, it gets worse. Um, my story number four. Another library. How do you pronounce this? Lib. Hi. Is that how we're saying it? What story are we saying this?
Speaker D: My
Speaker A: story Number four. Lib. H E I F Lib Hif
Speaker C: Yeah,
Speaker A: Heath
Speaker C: Good Hife.
Speaker A: We're calling it Hype Fortbridge. Uh, uh, actually someone else disclosed the vulnerability. Someone from wordfence disclosed the vulnerability. Fort Bridge basically created an exploit uh for it. Uh and it's not just WordPress but other um, web frameworks if you will. Um, in the processing of images. It's kind of similar to ImageMagick. Um, the way I understand it. But the, what I, what I thought was interesting is that uh, the crafted images leak runtime addresses through returned JPEG pixels. That's pretty friggin wild. Uh, the way it works. They have a proof of concept that worked against Ubuntu, uh, and Debian. Um, and it's super interesting uh, vulnerability that they were able to create an exploit for. I think they have a GitHub they, they actually published uh, the exploit. Um, so yeah, that's another library vulnerability that is included in, in more things than just WordPress. But WordPress is one of them. Imagine that. Yeah. Alex Thomas of uh, Alex Thomas of WordPress. Um, yeah.
Speaker D: Yeah.
Speaker A: So many vulnerabilities to talk about.
Speaker D: Yeah. Oh,
Speaker A: what did you guys think of given the vuln apocalypse that's upon us?
Speaker C: Mhm.
Speaker A: Fortinet had an interesting advisory uh, that they issued.
Speaker C: Mhm.
Speaker A: And I've been studying this one and I'm trying to like figure out exactly what happened. So
Speaker B: if I need ominous background music or something the way you're saying this,
Speaker A: like, but now that I think like I am a Fortinet customer as well. But so, and I could have even done more research on this but Fortinet released security updates for a number of different platforms after they used frontier models to find critical and high severity flaws. Um, it has scheduled. So they issued this like a couple days ago in October. Um, and it has scheduled CVE IDs, severity scores and their own vendor advisories for release on November 10th. However, they have released patches to customers. So they have released new versions and or patches of their software. They have not publicly disclosed any of the information about which vulnerabilities. So only Fortinet customers. Fortinet customers don't even get the, from what I understand the CVEs, the security information. Fortinet customers just get the patches. So they're like basically Fortinet customers. If you have a valid support contract and you're paying us or whatever, there's a new version of fortaos you should go apply these updates. Like just trust us, this fixes some shit and we're not going to even give you the details as to what that fixes. On November 10th, Fortinet customers and the world will learn exactly what that fixed. I thought that was really interesting. I'm kind of torn on this one. Right.
Speaker C: This is like a weird embargo.
Speaker A: It is. I don't think it's all bad because like on the one hand, if you think about the state we're in cybersecurity today, Fortinet customers get the upper hand. You're like, look, they're compartmentalizing the information and going, you should apply these fixes. They're available to customers. And I'm going to go do that now. I have kind of an advantage from, um, a Fortinet customer. I can patch shit before the world learns about it. So I'm not going to wait for a CVE score. The vendor just asks me, like, trust me, you should fix this. Which is a little questionable. Um, but then, like, asking customers to accept the operational risk of applying the update without giving the customer the information to prioritize those fixes is kind of interesting. Right? You're just telling Fortinet customers, like, you need to go apply this. Like, whatever operational risk. You can't really calculate that. Like, the vendor saying, go apply that. Like, you. You. You can't. How do you calculate the risk score when you don't have all the information? You just have a patch.
Speaker D: Right.
Speaker A: Interesting.
Speaker D: I think, um, I'm guessing here, but I'm thinking with. With. With the AI tool set, you know, finding. Having the. Having the vulnerability and the patch. Reverse engineering is easier. And they're trying to make it so people the flaw. Which is cool, but like you said, it makes the guy who has to decide what to do when without good risk information, he's just got to click patch it all now, basically. Or she. Right. Um, which in many cases we're doing anyway. But I'm not sure that your Fortinet devices fall into that category.
Speaker A: Well, it's also like, you know, now attackers are going to see this alert and go, oh, Fortinet use frontier models to find vulnerabilities. Threat actors can do the same thing. And now it's still a race, but the defenders still kind of have the upper hand because all the details aren't public. So one could say that threat actors would go, let's turn frontier models loose on Fortinet software, which likely they're already doing. Um, but now defenders are like, well, we've got patches for it, and you don't know all the details. But also, I'm kind of thinking, what if threat actors are like, well, Fortinet customers have the patches, and I need the patches to figure out what was patched. Why don't I compromise, afford a net customer and. Or afford a net customer support account credentials. Uh-huh. Get the firmware fixes and then reverse engineer like it's not completely a secret. Right. Like, you have to give the patch to someone or group of people. That group of people now becomes the target to go, like, if I was a threat actor, put my evil hat on for a moment, I'd go, I want to persist in a Fortinet customer's environment and. Or compromise their Fortinet customer support account and go get those updates and then reverse engineer them and then go develop fixes. But also still, defenders have somewhat of an advantage because they're applying those fixes.
Speaker D: Right?
Speaker A: I don't know, it's weird.
Speaker B: I'm sorry, I say that again without laughing. Defenders have an advantage because they're supplying fixes.
Speaker A: I didn't say vendors have an advantage. The customers have an advantage because they have the patch and they can apply it right in the. The threat actors have somewhat of a, uh, increased barrier to entry to acquire those patches, to reverse engineer them, to create exploits. I'm not saying it's completely off the table.
Speaker B: Do you know how many freaking bad. You know, bad guys have full copies of everything Cisco has ever made so they can log in and download anything that Cisco puts. I
Speaker A: think I talked about this last week, Josh, and it's my.
Speaker B: Sorry,
Speaker A: my. My reading of the CIA, um, guide, John Kiriakou. Right. And how the CIA operates and how. And also you can kind of transpose that into how other nation state, uh, agencies operate. They would create a front company. That front company would become a customer of Fortinet. So whatever Fortinet is releasing, that nation state would also have access to. So I fully expect. Did our nation state adversaries have front companies that have support contracts that'll happily pay whatever it is, a million dollars a year to get all the Fortinet software legitimately. Uh, air quotes. Legitimately, Right, Legitimately, but illegitimately. And then feed that to their, uh, red team that has access to all the AI models known to man and go find me the exploits. So
Speaker D: it might even be a little easier than that, Paul, because on top of that, Fortinet listed the four impacted versions. So you could get the updates for the four different packages and have the old ones as well. And you could look for diffs in four places.
Speaker A: Right. There's your map, 100%. So does it slow attackers down? Maybe a little, but.
Speaker D: Or is it security through obscurity?
Speaker A: Um, it feels like we're playing a game rather than actually trying to be more resilient. Right. I think what we're talking about is we're. We're kind of playing a game like who has access to what. Who has Access to the patty who can do. Do what. And we're just playing games rather than just making everyone more resilient.
Speaker D: Interesting game. The only way not to win. Only way to win is not to play. How about a nice game of chess? Um, sorry. Watched war games the other day. Um,
Speaker B: couldn't tell.
Speaker D: Uh, no, you couldn't tell. Um, I'm that transparent. So actually, though, I think I keep coming back as security. Remember security through obscurity? People used to cling to it and you can't anymore. I mean, it's just. Is this another form of security through obscurity?
Speaker A: Again, you go back to my analysis of that Palo Alto thing. They were trying to use security through obscurity to hide details. I'm like, uh-huh. When we all have access to these AI models, that's a losing game. Like, we're going to figure it out. Like, there's. Security through obscurity is not going to help you. When we have these huge models that can do that kind of decision making and correlation and analysis, it's not going to happen. We had that before. Don't forget, there were bugs in. I think it was Google's, uh, Android that. Based on like a pre announcement or something, or I think it was the opposite way. Um, a threat actor had an exploit and someone revert. I think it was Heather Atkins, like, reverse engineered it and goes, oh, that's where the vulnerability lives. With, like, very little information about the exploit. I think it was. Someone said it was the opposite threat actor said, I have this exploit for Android and here's a little bit of information about it. And based on those little tidbits, I think it was Heather figured out that, oh, they're talking about this bug that we need to fix and went ahead and gone and fixed it kind of thing. So again, security through obscurity is not going to win again. It's just playing games. And I think we as defenders lose when we try and play games like this. Although on the flip side, people are patching their fortinet devices, hopefully, uh, and becoming more resilient before all the details come out. So.
Speaker B: Optimist. Optimist.
Speaker A: I know, I know. It's.
Speaker D: Josh,
Speaker A: you're not the optimist on this one. You're pessimistic on this one.
Speaker D: So. So I'm thinking, given this conversation, how does your article number one overlay on this, which is that there's. There's so much patching to do, it's. It's consuming all the bandwidth.
Speaker A: Yeah, it is. I mean, That's.
Speaker D: They're not wrong.
Speaker B: No, no, they're not wrong. Um, it's
Speaker A: a. But it's a great segue, right? I mean, basically what Cisco is saying is, hey, we're Cisco, we own all the code. We can put live patching or protections because we have access to the kernel, we can put these protections in place for you to give you more time to patch.
Speaker C: Yeah,
Speaker A: and again, this is one I'm also conflicted on where yes, I think that's good to give your customers buy some time, do some live patching. I've never been really kind of uh, down on the live patching thing because as we know, patches are an operational risk. If I can incur less operational risk and put a remediation in place that does some kind of live patching, shielding something in the kernel as this case, uh, they talk about a temporary EBPF based runtime shield for Cisco infrastructure. If I can put that in place, that's. I think today that's the kind of thing we need. As we've said before, we're not going to patch our way out of every one of these situations.
Speaker D: Uh,
Speaker A: we need more ammunition, we need more defense than just patching. And if I can put something in my Cisco devices that makes them more resilient to attacks both known and unknown, I should do that. In the age of AI, I have to do that.
Speaker C: M.
Speaker A: Right.
Speaker C: Well,
Speaker A: um, but the kind of nitpicky thing is, um. Well, they're trying to sell you a product for one. You know. Also this only works for Cisco Gear. In large enterprises that have a hundred like are running at 100% Cisco is probably non existent. If you're in the Fortune 500, you have more than just Cisco. So great, this helps you with Cisco, but what about every other vendor, uh, that you have?
Speaker D: So, but this is not inconsistent with stuff we've talked about before. I remember, um, I don't know, maybe it's. A month ago you talked about creating a tiered patching model with different degrees of just click YOLO and go to. We're really looking at this so that you can survive. And the more you're looking at, the smaller the set should be. As well as something I've been saying, and I think you've been. Others have been saying it too, is to make sure that what you're keeping in your I must keep this patch and updated list is realistic. I mean like for example the hosted GitLab, they're applying those updates because GitLab's had a lot of stuff lately, right away, if that fits your reach tolerance, why keep that work on your plate? Because there's so much of this stuff. Just like the Cisco article saying, find ways to carve down where you have to do the hands on the analysis and all that stuff. Because you're not, you're not going to survive. You've got to just as your tiering model, Paul said, you know, it's how you survive otherwise. Because they're not out there running a bunch of, hiring a bunch more of folks, uh, to do patching.
Speaker A: Right.
Speaker D: You know, and AI is not the patching answer.
Speaker A: No, there's also the monitoring question too.
Speaker D: Oh, hell,
Speaker B: you know,
Speaker A: how do you monitor? Like, Cisco is in a great position to help you monitor because they control it. And I think they can give you monitoring. I think people will trust it more than a third party security vendor to do the monitoring. But I think what. And Josh, you made a face there, and that's the face that I make. Uh, I'm like, once in
Speaker B: a,
Speaker A: once an attacker gains the highest level of privilege,
Speaker B: you're toast.
Speaker A: You're toast. And. Exactly. And so when you start making decisions about who should have what level of access to do monitoring in my environment, should it be the vendor that I bought it from, should it be a third party security vendor? Because you don't trust them. But so what, you're trusting the attacker. Like once they get on your system, like if they gain the highest level of privileges, they're going to be able to hide and do whatever they want. So like, do you want to just hand over control the threat actors with no monitoring or visibility or. The other alternative is you got to trust someone. And by the way, you're not going to be able to hunt for this stuff by yourself. You're going to need something to help you do that. So
Speaker B: there's a
Speaker A: few points
Speaker B: I want to make here. And number one is that Cisco was a technology company. My opinion, Cisco is no longer a technology company. They're a PE firm with some technology divisions. Okay,
Speaker D: okay.
Speaker B: That's number one. So you want to try.
Speaker A: So what you're saying is profit trumps innovation
Speaker B: at
Speaker A: Cisco and has for probably quite, quite some time.
Speaker B: Yeah, exactly.
Speaker A: I agree. I
Speaker B: agree. So here's the problem with that. I'm going to trust Cisco monitoring all my traffic when they're a PE firm looking for advantages.
Speaker A: Yeah,
Speaker D: M.
Speaker B: I'm not saying they're spying on people,
Speaker C: but they're spying on people.
Speaker B: I'm just saying, I don't know,
Speaker A: because you have to trust them. Right.
Speaker B: You have to trust them. Now, um, again, they have some wonderful people. Don't get me wrong, I'm not.
Speaker A: Wonderful products, wonderful people, sure. But so many people in so many products that the level of trust I think varies between if.
Speaker B: Yeah, exactly. Secondly, you know, they're talking about 43 days. And I'm curious where they got that, because the Math says it's 137 days. So by the way, if you go to attack clock.com the math says it's 137 days. And the defenders have, um, it takes an attacker five days to exploit a vulnerability at most these days. Well, median is five days.
Speaker D: It
Speaker B: takes a defender 137 days to patch. Because by the time the patch is built and out and out the door and announced and tested, so those clocks are ugly bad. So I'm not sure where they got 43 days, but at that point it's still too late. Okay, so 43 days is 38 days too late.
Speaker A: Mhm.
Speaker B: Okay. And maybe I'm misinterpreting, and if I am, please feel free to correct me. But, um, it's like, okay, they locked the barn door a lot earlier, but the horse still got out first. Thirdly, uh, I want to point out that a virtual patch is like a waf, a web application firewall. Right? It's an overlay on top of stuff to not let the bad things get through. And that's a valid tactic, don't get me wrong. But if we start relying on that for all of our stuff, at what point do we have to take responsibility that we haven't patched a goddamn thing? And we're relying on the virtual patches, relying on the waf, relying on the, the workarounds of actually fixing the problem.
Speaker C: That was always the things that we said for years, Paul. The WAF is not the solution. The WAF is a temporary thing and something for monitoring. But you really have to go back and fix the actual problem or not do it in the first place.
Speaker A: M.
Speaker D: Uh, I consider the WAF a mitigation. I wouldn't call it temporary because I don't want to have people thinking it's something they take away. They still got to address the root problem, but it's in the layer of defense. You want a WAF in there. These days, running without a WAF really isn't viable anymore. Uh, and running
Speaker B: virtual patching may be the thing to do,
Speaker D: but not patching is not good either. Like, like Larry said, you got to fix the core. So I actually, I Was I had a thought and that is uh, how do people. I'm thinking we don't have the right engagement skill in the room. But the idea of scanning through the WAF for vulnerabilities, in other words, the WAF is not blocking the scanner to see if you really have fixed the underlying.
Speaker B: Oh, then you just typically for a pen test team or something like that, or a scanner, or
Speaker D: even an auditor, a
Speaker B: direct URL or auditor so that it goes around the WAF and scans the website without the waf. That's pretty typical these days.
Speaker D: I mean I remember being in conversations with auditors that wanted to do that and as far as the developers were concerned, they just called the baby ugly. Um, and uh, I think the optimal was have them do it both ways so they can show that the WAF is blocking whatever badness is. But then you still gotta be accountable for not fixing stuff. So you better be in the middle doing something about it. But at least then you can see both views because that's important. Um, so anyway, I just, it's just a vector I had. It's like because. Oh and I was going to ask Paul, when you talked about Cisco monitoring, are you thinking about in their context of owning Splunk or you being generic?
Speaker A: No, no. Uh, what they're talking about is um, snort virtual patches, which is more like a WAF from what I understand. And Live Protect is aimed at Cisco gear. That's where I think of more of an EBPF style monitoring and or enforcement system that is not allowing certain behaviors uh, to happen. And I think that could be really great or really crappy or somewhere in between depending on the implementation. I also somewhat question like what bug classes that that hits. What. What I see in the threat landscape is if I can gain credentials to your network device or have an authentication bypass. I don't need to necessarily execute code right. Implant malware. I can kind of live off the land.
Speaker C: Mhm.
Speaker A: I can use your device to capture traffic. I can use your device to capture more credentials. It gives me further uh, access to it. Um, I can use your device to create a tunnel back to me as the attacker to put me on your network through an encapsulation tunnel or VPN and then join my system to your domain. So is the Live Protect at the lower level where it's looking at what files I'm accessing? Maybe I'm not accessing files. Maybe I'm just like I'm logging in your firewall and I'm going sniff all of this. Sniff all this traffic and give me all the credentials that, that you find, uh, and maybe create a tunnel, you know, back to me to send those credentials. That's what I'm observing in the threat landscape. If it helps with that, I'm um, all about it. Albeit Cisco is you know, independent vendor that it's just Cisco Devices. That aside, that would be really good. But also I have to, it's interesting like trusting the vendor to like there's it's vulnerabilities in their software that are creating this condition and then they're selling you solutions to protect that. And that's one of the problems I have with it.
Speaker D: That's not self serving at all.
Speaker A: Right.
Speaker D: Uh, yeah, it's, it's interesting. You know, I wanted to change tactics just to get, I want to get your reaction on, on my donuts drill. Dream nine number three, which was the State bank of India had a data breach. They have 530 million customers. They had 375000 records compromised, of which 3, 900 had sensitive information. I'm like going holy crap, when do you see ratios like that, you know? Um, or is that distracting?
Speaker C: I'd argue the attackers weren't very good. Getting good data.
Speaker A: Yeah. Huh huh.
Speaker D: Oh that's way better than where I was.
Speaker A: Not great percentages.
Speaker C: No, they had
Speaker A: enough.
Speaker C: Maybe
Speaker A: enough.
Speaker C: They had 5 million records that they could have gone after and they got 3,800 that were
Speaker D: 530 million
Speaker C: uh,
Speaker D: times what you just.
Speaker C: The prosecution rests.
Speaker D: Yes. In other words, the attacker was a dumbass.
Speaker C: Oh my God.
Speaker D: Yeah, so I just was like those ratios, that was the main thing that got me was the ratios. The numbers looked crazy by the way when I started the article didn't have the uh, number of customers and I had to go look it up and that's when I went holy shit. That was just kind of like whoa. So I basically put that in there pre reaction. I mean I feel for the, the bank, I don't. I mean any volume of breach, particularly in a financial institution blows. And in India they got those really tight reporting time frames. I mean they put it in was a year or two ago that 24 hours they had to be in reporting and they had to have their cert in. In their, in in their shorts helping them work it. This has got to be. I'm just wondering how m much if, if this is actually just. They just spit out some numbers to, to meet requirements. But dang, I hope the interactor was a dumbass and they could just move on. But Uh,
Speaker A: I actually had a really interesting article from CrowdStrike. Um, now I don't. A lot of times, you know, posts from vendors are, uh, promoting their own stuff, but this one was, I think, really super interesting.
Speaker C: Was this your story number two, Paul?
Speaker A: Yeah.
Speaker C: Okay.
Speaker A: Okay, so, uh, and I'm going to read the article because they did a good job in the first couple of paragraphs, uh, explaining what happened, uh, and very succinctly. CrowdStrike researchers asked a frontier AI model to explain a function in a small C web server. While it had previously explained every other function in the code base, without hesitation, it refused to explain this one. The request was routine. We'd only asked what the code does. We hadn't asked about security exploits or vulnerabilities. But a single token in the code had changed a max swapped for a min. A one character logic inversion that creates an out of bounds write. The kind of bug that slips past most code reviews what the, the gist of the article is. And all of us have done this. You ask questions of an LLM, um, and all of a sudden, like, seemingly out of the blue it stops and goes, I'm sorry, Dave, I can't do
Speaker C: that. Afraid I can't do that.
Speaker A: I'm afraid I can't do that because.
Speaker C: Josh, you're on mute.
Speaker A: This is now vulnerability. Josh, you're on mute. This is vulnerability. Um, he's talking to someone on the phone while doing a podcast. I can't multitask. Um, so basically what's happening? And so the research continues and goes, uh, basically they created like a heuristics thing where they're like, so if I just intro. So what they do, they introduced a vulnerability. They asked all about the code in the vulnerability, in the, in the, all the stuff about the code. And when they got to the point where there's a vulnerability, it stopped. And they're like, what if I just keep asking, like, will the guardrail be indicative of. That's a security vulnerability. And that's what the article talks about. And I'm like, that's kind of brilliant,
Speaker C: actually,
Speaker A: is to ask LLMs to describe a code base, See where the guardrail hits and when the guardrail stops. I think they said like 73 out of 86 test scenarios. 73 of those were actually vulnerabilities. Like, that's frigging awesome. Like, you're basically using the guardrails against them to discover vulnerabilities is awesome.
Speaker C: Do you build a better mouse? We'll build a better mousetrap.
Speaker A: I love it,
Speaker D: so it's like an interrogation where the question's not answered. Are the interesting ones
Speaker A: correct?
Speaker C: Uh,
Speaker D: this is. Yeah,
Speaker A: yeah. The article goes very in depth into, you know, the research that, that happened after that. But
Speaker D: yeah, no, it's
Speaker A: very much a must read, especially if you're using AI like, you know, Larry and I use AI to find vulnerabilities all time. Uh, very, very useful. Mhm.
Speaker D: There's some folks like CrowdStrike, uh, unit 42 watchtowers. They do some really great writeups that are fun to read. Um, and I'm glad when we can identify them for folks. This is just. There's so much data coming through all the time to say, hey, this is a cool write up. Just read it. Maybe with something alcoholic in your hand, but read it. Uh, it's cool.
Speaker B: Lee, is there ever a time you don't have something alcoholic in your hand?
Speaker D: Yes, absolutely. This would be water, not vodka.
Speaker A: Yeah, usually in the morning
Speaker B: water.
Speaker D: Well, it's whatever the refrigerator tap puts out.
Speaker B: Have you seen those kids that tap their parents fridge for beer?
Speaker A: Oh my God, dude. So hilarious. They did like ridiculous things in the house. I've seen that channel. Yes.
Speaker B: The dad was so happy. It was pitiful.
Speaker A: Now you used to have a beer tap in your kitchen.
Speaker C: Yep. Yeah. Yep. But the irony is the refrigerator was your old beer fridge out of your garage which came to our house. I cut a 4 inch hole in the side for 4 inch PVC that went up through the floor of our old house to cool the line all the way to the sink. And right at the sink was a beer tap. So like you didn't need to have a little. Are you
Speaker B: joking?
Speaker C: You didn't have to have the little drip tray? No, it dripped in the sink and you could rinse it down with a little hose. I'm not joking. The refrigerator is in my garage right now with a end cap on the piece of 4 inch PVC pipe that has been.
Speaker A: Oh, you don't have a beer tap in your house anymore?
Speaker C: No, no, the, the thing's in a weird location to be able to do that and well, it wasn't good for my waistline.
Speaker A: Yeah, I know. Drinking that much beer. I know people that have the kegs and beer taps in their house end up drinking a lot of beer. Go figure.
Speaker B: I'm putting a kegerator in my house. Of course it's for kombucha and seltzer, but you know, it's a kegurated.
Speaker C: Yeah.
Speaker D: So
Speaker A: you're getting old, Josh.
Speaker D: And they were
Speaker B: Young. I'm not getting old. I turned 55 yesterday. Okay. So.
Speaker D: Yeah,
Speaker A: I didn't know you were that much older than me. Now I feel young again. Thank you for that.
Speaker C: Sorry,
Speaker D: I've got nine years on you. Damn. Um, no,
Speaker B: no, no, wait, wait, wait. Lee, you're only nine years older than me.
Speaker D: I'm only 64. Uh.
Speaker E: Oh, screw.
Speaker A: I'm holding on to the fact I'm not 50 yet, but that's coming very soon.
Speaker D: So home improvement show, they're redoing the kitchen area. They put in a bar with beer barrels and a counter. And behind it they were putting a keg tap. But they put the tap in an electric box. When you open the first layer, there were the old screw fuses.
Speaker B: Uh,
Speaker D: and you open the next there, and there was the tap. And behind it, they had put a cabinet and the keg and the refrigerator in there. It was cool. The
Speaker C: secret
Speaker D: was shouting out which home improvement show is. I'm deliberately not telling you because I want you to go find it. But I
Speaker A: see all those, like, hidden rooms now, and people are building their houses. Like, oh, let me pull this book of my bookcase. And it's a door, and it goes into my bourbon area. I'm like,
Speaker D: oh, yeah,
Speaker A: why do you need to hide it? Like, you can't. You can't just have it closed.
Speaker B: Bourbon area, you know, like,
Speaker D: there was a. There was a house that had a safe room off the master closet. And I don't mean the room you can hide out. I mean, that's where you put your gun safe and your other safes. And it was substantial.
Speaker C: Uh-huh.
Speaker A: That I can see hiding.
Speaker D: Yeah,
Speaker A: but like your bourbon cigar room, why are you hiding it?
Speaker D: No,
Speaker A: I'd be like, glass door. Like
Speaker C: the house that
Speaker A: you can look in.
Speaker C: The house I grew up in. Um, my. My dad and my grandfather built. And in the basement was a walk in closet that was cinder block, just like the foundation, uh, while the foundation was poured, but had the cinder block interior room, and it was the walk in gun safe.
Speaker D: Nice.
Speaker B: Makes sense.
Speaker D: And if it was Cinderbot, I bet those. Those cinder blocks were probably not hollow anymore.
Speaker B: Nope. They were filled with rebar and concrete. Knowing you, Larry,
Speaker C: Most likely. Most likely, yeah. Considering my dad put a mailbox up and it always got taken down by cars coming around the corner. Um, and he went up there. He
Speaker B: got pissed off.
Speaker C: He got pissed off. Uh, so he dropped a steel. A foreign steel pipe filled with rebar and concrete welded to an I beam at a perpendicular that he dropped down and covered in concrete. The next car that, uh, hit that mailbox didn't survive.
Speaker B: Bit. It
Speaker C: didn't survive.
Speaker D: Word got around, didn't it?
Speaker C: Yep.
Speaker A: They
Speaker C: had to pick the car. The car
Speaker B: didn't.
Speaker C: They had to have a tow truck come and pick the car up off the post because it had gone up the post.
Speaker D: We have, uh, we have mailboxes in our neighborhood that are two or three, and they're. They're covered with stone, but they're apparently wood inside. And there's one in a court that's been hit a few times. I don't know why, but it's being rebuilt. But the guy rebuilt it with concrete. No more wood, no more hollow center. Yep. So if somebody hits this one, it's going to hit back. I mean, think about it. Oh, you're muted, dude.
Speaker A: You're muted. Josh.
Speaker B: Sorry. Thank you. Yeah. There's a Reddit story about a kid that was hitting people's snowmen.
Speaker D: Hm.
Speaker B: Uh, with his car and wiping out snowmen in the wintertime. And this one family built a snowman around a very, very, very sturdy stump.
Speaker D: Mhm.
Speaker B: And then the next picture is the kid's car in a U shape being towed
Speaker A: around the stump. Yeah.
Speaker D: So you've all seen Christmas Story Christmas where the kids turned, what was it, a fire hydrant into a, uh, snowman.
Speaker B: Same idea. Yep, yep, yep, yep.
Speaker D: I love that story, by the way, Josh, I think that's a great payback because. Jerk.
Speaker B: Oops.
Speaker C: Speaking of turning things to a snowman, you mind if we hit my only story for the week?
Speaker A: Oh, yeah, go.
Speaker D: Yeah. Which one of your only stories are we hitting?
Speaker C: Uh, probably number two.
Speaker D: Okay, I'll look at it right now.
Speaker C: Yeah, no, I thought this one was really neat because, you know, we've talked about all these gadgets and all these types of things, like the replacement for the Flipper Zero and, uh, the various wireless hacking tools. And I
Speaker A: thought so many now,
Speaker C: and I thought this one was kind of fascinating, uh, because the folks that, uh, write the Mayhem software for the rtl. Uh, sorry, not the rtl, the hacker, uh, F. Portapack. They have effectively ported their portapack Mayhem Portapack firmware and apps to be able to run on a browser on an Android device, and you can now attack an, uh, attach an RTL SDR or a HackerF in Hacker F mode to your Android device, and your Android phone is now the portapack running all of your Mayhem software. Like, that's genius.
Speaker D: And look at all the modes it operates in. Holy Cow.
Speaker B: I will be doing that so much when I get home. Oh my God.
Speaker D: This totally says Larry all over it.
Speaker C: Oh, yeah, yeah. I mean, the Hacker F portapack is amazing. The Mayhem firmware is arguably some of the best because it just does so many shenanigans. Uh, and so
Speaker D: the question is, how many do you have, Larry?
Speaker C: How
Speaker D: many, if. How many?
Speaker C: Um,
Speaker D: two drawers or three?
Speaker C: No, just one. I'm just trying to remember which drawer it is. It's this one right here.
Speaker D: Do we all know our Larry or what?
Speaker C: It's in the, it's in the bag labeled Hacker F.
Speaker D: Yeah,
Speaker C: right. And in, in this bag there are another. At least two somewhere else. There's the Hacker F Pro, there's the Hacker F. There's the Hacker F portapack with Mayhem on it. And uh, there's the old style Hacker F with portapac on it running the non Mayhem firmware. And I know there's. I'll give
Speaker D: you Larry Pesci.
Speaker C: I know there's another Hacker F in the drawer for, um, the, uh, IOT hacking class because that goes as part of the kit when, when I travel and that type of stuff. The only sad thing is, is that I had this in the case and I traveled with it and I scratched the crap out of the screen.
Speaker B: Oh, boy, buddy. Um,
Speaker D: you need a new one.
Speaker A: You can probably order another screen for it, though it's probably more because you can't get them from AliExpress, because that's
Speaker C: free. Actually, no, you
Speaker A: can't.
Speaker C: You can get
Speaker A: the,
Speaker C: you can get the portapacks, uh, from AliExpress. Uh,
Speaker A: you can. Okay,
Speaker C: because that's. This one actually came from AliExpress. Not all about
Speaker A: you too. And it works, it works great, you know, I covet it because. Wait, they're hard to find now.
Speaker C: Yeah.
Speaker B: So speaking of the RTL SDRs, where can you get them now? Because you can't get the, uh, V4s anymore.
Speaker C: Um, there's one version that you don't want. Uh, and I think it may be the V4. One of them used a non standardish chipset that they were doing and wasn't supported all over the place. And I don't remember which that one was. I don't think it was the V4.
Speaker D: Yeah, you don't want to get the low bid chipset combination if you can avoid it.
Speaker C: Yeah, let me. Ah, so RTL sdr. Um, yeah, there was, uh. No, you didn't get the. You can get the V4. I'm looking at, uh, rtlstr.com
Speaker A: the website that Larry Story comes from is rtl-sdr.com Yep. Uh, I encourage our listeners to, if you're interested in that kind of stuff, follow that website.
Speaker C: Oh my God.
Speaker A: Amazing news. I follow that stuff for a long. It's amazing. Everything you could possibly.
Speaker C: Yeah.
Speaker A: Want in terms of information, uh, about that platform, all the gadgets, all the software, everything.
Speaker C: Yep. And people are working on projects and do semi related to the RTL sdr, other software defined radio things and they highlight all these projects. It's like hackaday, but just software defined radio and even more of a focus on RTL SDRs. Um, and they are the ones that manufacture one of the best versions of the rtl, uh, SDR as well. Um, specifically. Yeah, no, Josh, you can get the, the five, the four, um, on their site. Oh no, it says out of stock. Interesting.
Speaker A: M. Well, there's a lot of tariffs and supply chain issues with a lot of this gear right now.
Speaker C: Yep.
Speaker A: It's funny. I'm going to Boston tomorrow and I have a bunch of Lily go T embeds that we got pre embargo. Uh, and I gotta figure out a way to give them away, uh, tomorrow. Uh, because my company bought them, uh, and then just been sitting there.
Speaker C: Interesting.
Speaker A: Uh, and the last time I brought them to Boston they went like hotcakes. People were like, like fighting for them. And I was like, I should have brought more. But I have the rest of my. Probably have about 10 that'll give away tomorrow at Eins Boston.
Speaker B: Nice. So if you go to Eins Boston, you can attack. I mean, talk to, uh,
Speaker A: yeah, find me
Speaker B: to talk to Assadorian. Talk to Paul and he'll uh, give you hardware. If he doesn't have any, just hang on to his arm until he gives you something.
Speaker A: Right.
Speaker B: Okay. If you hang on long enough, he'll give you his phone in desperation. Okay.
Speaker A: Give you something other than that. We just have stickers in the standard vendor giveaways. But the, the T embeds are definitely. Because it's all the embargo and tariff stuff that made all that stuff harder. And supply chain too. I think, uh, Adrian Sanabri was talking about how some of the. There's so many. There's at least like a dozen projects that are like the similar to Flipper Zero handheld Linux device. And I think he said one of them had to fold.
Speaker C: Yeah.
Speaker A: And they only gave him what like 20, 30% back or something? Yeah,
Speaker C: it's like 30 something. He got like 54 of his $400 back. Uh, Adrian
Speaker B: got screwed.
Speaker A: Sorry. He backed a Kickstarter. Uh-huh. And they weren't able to deliver and they were refunding everyone's money, but they're only refunding like 30%.
Speaker B: Ouch.
Speaker A: Was it a couple hundred dollars, Larry? Yeah, pledge.
Speaker C: I'm looking for it right now, um, in our thread.
Speaker A: Yeah, so be careful. Uh, I think
Speaker C: he got $, uh, 52 back out of his total pledge of $214.
Speaker B: So a little like basically a quarter.
Speaker C: Yep. It was, uh, the Linux in the Interrupt. The ultimate Linux. Powered some 1Ghz pocket gadget. Yep. Ah, I
Speaker A: think I covered a story last week about the CYD GBL display. You can solder a bunch of stuff on there and people make firmware for it and we've talked about that. Was it Shmoocon 20?
Speaker C: Not last year, the year before? Yep. 2024.
Speaker A: One of them. I had Covid. No, I think I presented it 2023. I had Covid for 24 and I attended 25. The last one.
Speaker C: Okay. Was 25 the last one?
Speaker A: Yeah, 25 was the last one. Not because it wasn't this year. This year was. No, shmookon. It was our first year without Shook on 26.
Speaker B: Uh,
Speaker A: so 25 was
Speaker B: the
Speaker A: last one. So maybe it was the last one that. Did you guys present at the. Yeah, you got. You and Bill presented at the last one.
Speaker C: Yes,
Speaker A: that's the one. We had tons of hardware, 3D printed things. And I was like, if you get a Cyd, you can solder on all this stuff. And there are still projects that do that and you can still get all that stuff. And if you're willing to figure it out and solder it all on, you can have a very capable device, uh, that you don't have to pledge something and wonder if you're getting your money back. But it doesn't run Linux. A lot of these wanna run linux. That's like Flipper 1, uh, style kind of thing.
Speaker C: Yep.
Speaker B: Huh huh. The RTL SDR store. The RTL-SDR.com store is really nice.
Speaker C: Uh,
Speaker D: there's some neat projects on here.
Speaker C: Oh my God. There is not a project, not a day that goes by that there's some project that I have to pull out my RSS reader and do that. Um, the one that I saw during the show was the RXX Lora, a lightweight RTL FM style LoRa receiver for RTL SDR and SDR play. No game. I was
Speaker D: wondering if you triggered on that one.
Speaker C: Yep, it's in the browser tab right next to the show notes.
Speaker D: You know, I'm cool, I'm cool with that. So as we're, as we're winding down, where do we want to go? Do we want to talk about Apple patched everything? Do we want to talk about.
Speaker A: Um,
Speaker D: I mean that's an obvious one.
Speaker A: No,
Speaker D: but they
Speaker A: didn't patch everything. I found some,
Speaker D: um,
Speaker A: X posting where someone's gonna release a whole bunch of stuff because they're frustrated with
Speaker C: another one.
Speaker A: Um, yeah, I didn't put it in the show notes. Oh
Speaker C: no, that was Microsoft.
Speaker A: But someone on X was like, since Apple bug bounty program is by far the worst program I've ever hacked and I'm going to dumping all the data. Proof of concepts report writeups, uh, for everything found during the four months of hacking them. They include proof of concepts for vs that didn't meet their bar for a bounty, so wasn't reported to them. So you be able to find ways to escalate some of them. And it'll be posting it this weekend.
Speaker D: I don't blame him. And that's like those turkeys,
Speaker C: Y.
Speaker B: Uh,
Speaker D: they must have a good reason. But I, I just. Today it's like how many stories have we seen where somebody didn't they, A company didn't acknowledge us a submitted bug issue, security issue, and next thing you know they're out there working in arrears to recover from the, from the genuine flaw that was that they just ignored.
Speaker A: I'm calling it uncoordinated disclosure, I
Speaker C: think.
Speaker B: Oh, I like that.
Speaker A: And I think I can't be the first one to coin that term. I'm not going to claim it because I got to say, someone else has audited.
Speaker B: I've never heard it before. You can own it.
Speaker D: Hey, for the purpose of this podcast, it's all yours.
Speaker A: But what and where I think that stems from is there are so many people who are enabled with AI uh, vulnerability research that it has kind of flooded vulnerability disclosure.
Speaker D: I agree.
Speaker A: And in that flood has kind of fleshed out all of these issues that we all knew were there with coordinate with vulnerability disclosure. We all knew they're there, but this influx is fleshing out the oh my God, it's still a broken process kind of thing.
Speaker C: Yeah,
Speaker A: that's what I'm feeling right now.
Speaker C: Speaking of a broken process, Paul, tell us about the PlayStation 5.
Speaker A: Oh my God,
Speaker C: one.
Speaker A: What a debate debacle.
Speaker B: What happened?
Speaker A: So from memory, I will state that there were multiple people who were working on vulnerabilities that would lead to a PlayStation 5 being basically jailbroken, allowing you to run uh, Linux on that. And there was a couple of different researchers that had working that uh, had discovered vulnerabilities, developed working exploits to do that. And one of them kind of got like, hey, maybe we should like disclose this. Like this is getting a lot of scrutiny. Like at some point like Sony's basically going to fix this on their own. So the window for submitting to their bug bounty and getting paid is shrinking. Okay. One of the, one of the researchers was like, you know what? I'm just going to go submit and get paid. And they did that and it basically pissed off the whole community because they're like, you just burned our zero day basically.
Speaker C: Right? And
Speaker A: the facility they all had for hacking a PlayStation 5 to making it run Linux is now burned because Sony's now going to fix it because it was responsibly disclosed. It was a whole ton of backlash. And one of the other developers, it was like, I've been working on like exploiting this vulnerability, using it to install Linux and I put months and months and months of effort into it and now it's going to get fixed and all my shit's burned. I'm done developing for you know, just basically breakout uh, from uh, Sony's bug bonding disclosure. So my summary says a researcher known as Jordy says he used AI defined PSP, um, PS5 hypervisor flaw ported to Sony receives a $50,000 bug bounty that angered parts of the homebrew community because another researcher hoped to keep the flaw private until after GTA 6's launch, preserving a chance to run Linux on updated consoles. And that's the drama.
Speaker C: Yeah, so they uh, my understanding is they were going to have to do an update to the console to be able to run GTA 6 and it was going to be a time before they could really do a good update to the console to prevent the, the jailbreak from happening. And now the jailbreak has been exposed because they get paid out for it and now they got to start all the way over from scratch again.
Speaker A: People are like oh I'm done, I'm done, I'm done with the PSP PS5 platform. On
Speaker B: if your research depends on a secret that 20 other people have,
Speaker A: they can recreate that secret AI. I think that that was some of the backlash was like oh, all these AI jockeys. Uh, Larry had a very colorful vibe coding, um, analogy that are reserved for after the show. But uh, I think I had some other names for AI Vibe coded kind of slop kind of stuff. But basically, like, if anyone can use AI to find the vulnerability, like, who's the first one that's going to report it and get paid? Leaving all the other researchers that are like, oh, we're banking on the fact that this was a secret so we could benefit as a community from, from doing this. But also the, you know, I think all of us are kind of torn, like, do we responsibly disclose this? Do we do coordinate disclosure? Do we not? Is this, uh, a vulnerability that impacts safety, or is this a vulnerability that just bypasses DRM at the end of the day? I think there's a big difference. Right. I think that's some of the rub. Like, you want to get paid because basically you violated drm. Like, gaming platforms are, I think, completely different from other compute platforms in that the technology in gaming platforms, in security is not designed to keep out unauthorized remote users. The technology and security is to protect themselves from their own users, from people who want to hack the platform to do things it was not intended to do for their own benefit. Not to run a ransomware campaign or.
Speaker C: Yeah, they want
Speaker A: extortion campaign. They
Speaker C: want
Speaker A: to run wherever they want on the hardware.
Speaker C: But, you know, the protection is there to prevent this theft of the intellectual property of the game,
Speaker A: Correct?
Speaker D: Yeah, yeah, that's it. And a lot of this article talks about the backlash for him, just, you know, people being rude because they didn't want him to disclose it. Fair. I mean, you know, you have a right to be pissed off if somebody does something, but, you know, but I'm also thinking we've. We've talked about the hacks in the past where you have to have this older version of firmware loaded and you go get the older version and you, you go to town.
Speaker A: Yeah, but these will come out and automatically get updated, right?
Speaker D: Yeah. So there's a lot. Yeah, it kind of shoots that in the head.
Speaker C: You want to play GTA 6, you have to apply these patches. Yep.
Speaker A: But it's. It's also the. We didn't talk about the TV thing. Have you guys?
Speaker C: There was. Yeah, there was a. What? Another one, Right.
Speaker A: Oh, how did I not add that to the store?
Speaker C: I saw that and I forgot to add it to. Yeah. Uh,
Speaker A: basically all TVs are spying on you in some capacity to run ads to do. Really? You
Speaker B: didn't know that already? You. You're behind the freaking time.
Speaker A: But it's worse now, dude. Like, it's worse. Like there are. It's not 100% validated yet. But there are reports that the software of uh, firmware on TVs is like, oh, if there's no microphone on a TV, if there's a Bluetooth connected speaker or some other speaker connected to it that has a microphone, can we enable that to listen for background noise? And that background noise, and there's code tuned to listen for background noise for babies crying and dogs barking. In either case that means you have a dog or you have a baby. So therefore it's going to target ads for
Speaker C: dog food and diapers.
Speaker A: For dog food and diapers. Exactly, Larry. Exactly. And there's also reports, I don't know if it's Samsung or lg who talked about in the past, that if you don't connect it via Ethernet and you don't associate it with a WI FI network, it shouldn't have access to the Internet to send telemetry back. But the firmware inside the TV goes and looks for other WI FI networks that might be able to join to get Internet access. Open ones. Yeah, to collect data about you to send back to the company. I'm like, well that's super fucking shady.
Speaker D: Right?
Speaker A: Like the whole,
Speaker B: I'm sorry m. Is there anybody else that wants to simply have a, a laptop playing porn at the TV to see what kind of ads you get?
Speaker A: But I've seen people use AI to uh, like point a laptop camera at the TV and have like a debugging interface to it to hack the firmware, uh, to disable all the features. There's many initiatives to create custom open source firmware for these TVs because the privacy violations are so bad.
Speaker B: It's
Speaker A: because we don't have privacy regulations in the US to help curb this behavior, to make it illegal that were in this situation in the first place.
Speaker B: Uh,
Speaker A: and forcing the hand of us hackers to go, I don't want commercial software on my tv. I just want a TV to be a freaking display.
Speaker B: That's all I want. Wait, wait, but do you want a cheap tv?
Speaker D: Yeah.
Speaker B: Okay. I think people
Speaker A: would pay more for just a display.
Speaker B: You're telling me that people don't want 265 inch TVs?
Speaker C: Well, they do.
Speaker B: And they don't want to spend 700 on a 65 inch TV.
Speaker A: Yeah, because
Speaker B: that's the
Speaker A: trade
Speaker B: off.
Speaker A: But they don't know the trade off. That's the problem. They don't know the trade off.
Speaker B: I know that. And you know, that's what the
Speaker A: research is uncovering is, you know, what, what's, what is the trade off? What am I paying? Um, I mean, essentially, I'm paying. I'm paying for it, right?
Speaker B: Uh, you are, but you're paying in different ways. The CEO of Vizio made this clear on an interview. I make more on selling your viewing habits than I make on the hardware. The selling of your viewing habits is subsidizing the sale of the hardware.
Speaker C: The hardware is a loss leader for your viewing habits, and it enables the viewing habits.
Speaker D: So there was one other, one scenario you omitted Paul, and that is if you've got your sound system, your sound bar, et cetera, hooked up via, uh, the arc connector, that's bi directional.
Speaker C: Uh,
Speaker D: so that can also be exploited.
Speaker A: There's another scenario I omitted as well, uh, Lee, that I haven't talked about yet. And that is it doesn't matter what you connect to the HDMI port because the HDMI is such a robust protocol, they can look at the content that's coming in an HDMI and send that telemetry back. So you get your laptop streaming porn to your HDMI connection, the description of that content is being sent back to them. So we all need to get, like, ridiculous, heinous porn and just flood their system with midget porn or something. I don't know.
Speaker B: I love the idea. I just don't get any of it. I think you probably already have, but
Speaker A: researchers. And again, I. I have validated this. But research have proven that it does recognize the content from an HDMI port, regardless of what it is. Like, whatever you're connecting to it, it's able to use HDMI to determine what that content is and send that telemetry back. That's crazy.
Speaker D: Yes.
Speaker B: So there's. Oh, my God, there's so many terrifying things that could be done.
Speaker A: Terrifying.
Speaker D: So how many of you guys are thinking about, we should be monitoring what's being uploaded from our Internet connection just to see what the hell is going out of the house.
Speaker B: Should be. How about. Do
Speaker A: we have to.
Speaker D: Well, I know. I'm just thinking, how many are going. I should be looking, right? I mean, Josh, I know you're already doing it, and Paul and Larry are very likely to be doing it, but
Speaker B: I have
Speaker D: children. We're not normal.
Speaker B: Everything.
Speaker D: Yeah, I get it. I'm not
Speaker A: saying it's how to make your TV just be a display. Should be,
Speaker D: uh,
Speaker B: Honestly,
Speaker A: we should. We should all collaborate on, like, a public GitHub where we can be like, look, how do you make sure that your TV is really just a display?
Speaker D: You can
Speaker B: assume Apple tv. That's the thing. And Apple TV doesn't sell your viewing habits, as far as I know.
Speaker C: Until you, until, until you connect an HDMI to one of these TVs that do. Because the TV doesn't
Speaker A: yet. The TVs
Speaker D: are evil. What
Speaker A: we're saying. What we're saying we should have added stories for this. I agree. Uh, and we'll maybe talk about more next week. But your TVs are evil.
Speaker B: TVs are evil.
Speaker D: Right. So don't, don't hook the display part up to the Internet. But so many people want to use all that smart capability instead of having the equivalent of a cable box. And of course, we're talking about, don't buy the cheap Android cable box either, because they already are ratting you out. Um,
Speaker A: I wonder how much Roku is ratting you out. I bought
Speaker C: a
Speaker A: bunch of Roku for my
Speaker B: cats.
Speaker C: Let's find out.
Speaker A: I bought a bunch of Roku for my kids.
Speaker D: Larry told you to ask that question, didn't he?
Speaker C: No, no, I just happened to see it in the cabin. I'm like, oh, I need to use this. You should put that
Speaker D: somewhere. So, yeah, no, I, I, I'm. And, and you know, delete Roku, insert Kindle fire. Right. Same,
Speaker B: same thing.
Speaker A: Amazon Kindle's bad. I don't know. My Roku I just bought for my son is $58 for a dongle that gives you access to all streaming apps. Yeah, they're cheap. And I'm like, is that any better than what's on the tv? I don't know.
Speaker D: Um, depends.
Speaker C: We should ponder that and pick it up next week.
Speaker A: We should pick it up next
Speaker D: week. This has been awesome.
Speaker A: Thanks, everyone, for listening and watching this edition of Paul Security Weekly. That'll conclude this week. Larry, take us out
Speaker C: over and. Did you wash your hands? Jesus Christ.
Speaker A: I like. Well, how did you get that? Lee double. Oh, was that your app? That was your Apple thing.
Speaker D: Yeah.
Speaker A: Yeah.
Speaker C: Here I am doing it. I'm like, I'm doing the same thing. Oh, wait, I want a Windows box.
Speaker A: I was doing the same thing.
Speaker C: I want a Windows box.
Speaker A: It's not working for me. I'm on Linux. I
Speaker D: know. Larry's got Linux Window, Apple boxes. There you go.
Speaker A: There you go. Nice, Josh. Fireworks, Sam.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.
Sci-Fi, PKD, Greatness, Passkeys, AgentBreaker, Rockwell, Flock, Josh Marpet - SWN #605Security Weekly Podcast Network · features Josh Marpet70 / 100
Mrfoofoo, Binance, Polymarket, Silent Train, robosurance, privacy, and Josh Marpet - SWN #629Security Weekly Podcast Network · features Josh Marpet54 / 100
