BTS #72 - AI-Powered Firmware Hacking: The Future of Vulnerability Discovery
In this episode, the hosts explore the latest in cybersecurity, including AI-driven vulnerability discovery, firmware analysis tools, secure boot complexities, and recent CVE trends. They discuss practical techniques for hacking devices, the challenges of firmware emulation, and the implications of new security policies on consumer and enterprise hardware.
Transcript
Paul Asadoorian (01:58.261): This week, hacking a Samsung TV, CVE news, an FCC exemption for one vendor. Secure Boot updates, all that and more. Stay tuned, Below the Surface, coming up next.
Paul Asadoorian (02:19.762): Welcome to Below the Surface. This is episode number 72 being recorded on April 16th, 2026. I’m your host, Paul Asadoorian, joined by Mr. Chase Snyder. Chase, welcome.
Chase Snyder (02:33.493): Hey, Paul. Hey, Vlad.
Paul Asadoorian (02:37.024): Sorry, I’m adjusting my camera terribly, apparently. We should have done that before we started, but I didn’t. Okay, I think that’s better. Hey, and Vlad Babkin is here with us. Vlad, welcome.
Vlad Babkin (02:50.477): Guys…
Paul Asadoorian (02:51.894): Very excited for this episode, we’ve got a lot of great stuff to talk about. Below the Surface listeners can learn more about Eclypsium by visiting eclypsium.com/go. There you’ll find the ultimate guide to supply chain security. An on demand webinar I presented called Unraveling Digital Supply Chain Threats and Risk, a paper on the relationship between ransomware and the supply chain in a customer case study with DigitalOcean. If you’re interested in seeing our product in action, you can sign up for a demo, all that at eclypsium.com. Where do you guys want to start today?
Chase Snyder (03:28.481): TV hacking. It seems close, seems pretty close. They could have done whatever they wanted, you know? We took a lot of flack for that video about the router ban. It just pulls together a lot of the threads. It really holds the room together. There was the router ban. We had the video that was like, anything in your house with an RJ45 and a Wi-Fi interface, that’s a router.
Paul Asadoorian (03:29.622): TV hacking? Did they turn a TV into a router chase? Is it… They could’ve. They could’ve.
Chase Snyder (03:58.049): People said, no, the YouTube commenters said, no, it’s not a, that’s not a router. Uh, it runs Linux. It has the network interfaces. It could be a router with like one command issued to the underlying Linux operating system. Uh, and then Codex went ahead and did the thing. That’s what happened, right? Is that they, uh, pointed, pointed the Codex, uh, threat, you know, vulnerability discovery thingy at a Samsung TV.
Paul Asadoorian (04:17.866): Mm-hmm.
Vlad Babkin (04:19.31): So yeah, yeah.
Chase Snyder (04:28.193): which I think the Samsungs all run Linux under the covers. There’s like a split. There’s some Samsung, some Linux, some Android, smart TVs. That’s kind of the two.
Paul Asadoorian (04:32.886): Is there like? Yeah, okay. Okay, is Samsung Linux the Tizen? Is that what they call it? Yeah, it’s Tizen. Yes. So the researchers made this blog post, Codex hacked a Samsung TV. They say that no TVs were seriously harmed during this research. One may have experienced mild distress from being repeatedly rebooted remotely by an AI, which I find hilarious, by the way. And when anytime an article starts off like this, I’m like, we’re in, like, buckle up. I think we’re in for a wild ride.
Chase Snyder (04:40.181): Yes, Tizen is like the TV line that has the Linux underneath it. Yeah.
Vlad Babkin (05:09.422): So what I find interesting is that if you read into the article, they didn’t quite go for, hey, here is a TV that responds to this API. Here we have a shell, some browser tool. And here is how you use the shell. And we want you to escape into the root shell. So given what I have in my experience with AI so far, AI is really good at exploring shells, exploring source file, exploring like gray box style testing. If you throw it at the black box thing, it will probably not do really well. But if you throw it at gray box where it has whatever information you have, it has a shell, it has a device to work with, usually AI actually performs great at those tasks. So like this is what we got with like, for example, agentic coding. It’s like exactly the same things that we have here, but applied to hacking, right? So for agentic coding, the recommendation is let AI run tests, like let AI run the code it actually codes and it will fix its own bugs, right? Here is kind of the same thing. Instead of asking the AI for a generic shell, what you do is give it a shell and some way to confirm that it is root. Well, obviously, AI knows how to use bash by now. So we kind of bind two and two together. So it’s like agentic hacking, right? So at least so far, what I’m reading, this feels like what’s actually applied here.
Paul Asadoorian (06:34.685): Yeah, so this method, I want to talk about this method because I think it’s pretty awesome. And I also just added to the show notes a YouTube video from Matt Brown that I shared with the team internally as well, where he’s using an open source AI assisted firmware analysis tool that’s fairly new called WAIRS, W-A-I-R-Z, and walks you through it. And many of the techniques that you described, Vlad, are covered in that video. Now the researchers with the Samsung TV used OpenAI’s codex, which I just started looking at today. I’ve mostly been using Claude Code, but I think it speaks to the larger strategy that we now have as researchers that you alluded to, Vlad. And I want to like double click on that and go into it because Matt Brown’s done some amazing stuff and I’ve started adopting some of his techniques. And that is you have your command line CLI AI tool, right? Maybe you have the firmware and or the source code to the thing that you’re testing. Maybe you have an actual device running somewhere in your network or running inside of emulation. Maybe you also have a UART serial connection to the device as well. And what you can do when you’re doing vulnerability testing is give Claude access to all of those things. You’re like, hey, Claude, here’s the firmware, here’s the source code, go unpack it. Or maybe you’ve unpacked it already by yourself, doesn’t matter. By the way, you have a serial console. And Matt Brown has a skill, and I think it’s built into that tool, that tells Claude how to interact with the serial console. So if you have another physical device running in a serial console, you do that. Then you’re like, I also have this device running, maybe that same device you have a serial console on also is on your network and you give Claude the IP address and the password or whatever you want to give it for it. Then armed with all three of those things, you start prompting Claude. Claude can do things. It can monitor the serial connection for the results of the thing. It can reboot it and look at the startup logs. It can do amazing things to help your vulnerability research with access to those things. Now we go back to the Samsung TV thing. That’s pretty much what they did, right? So in the web browser, they give it the command line shell. Like you’re saying, to interact with it and then go start to find some vulnerabilities.
Vlad Babkin (09:04.46): Yup. So like, literally, without reading too deep into how they build the harness, like how I would approach this is, okay, let’s give Claude a bunch of tools. Hey, this tool, if you pass it a command, it will run it to remote TV. And here’s how you call the tool with the command, right? And then just rinse, repeat, give it enough tools and enough information about the show, and it can do amazing things with it, even if you cannot get full SSH, like in many cases, like… For example, Claude Code natively supports, by the way, deploying itself over SSH remotely. So you can literally run Claude Code on a remote device you’re trying to exploit, given that you have an SSH bus shell. But if you don’t, well, you can just build Claude some tools, or maybe build them with Claude. Nothing stops you from like…
Paul Asadoorian (09:51.232): Wait, so how does that work? Does Claude make a copy of itself on the remote SSH thing and reuse your API token? Is there a specific config for that?
Vlad Babkin (10:00.308): Yup, there is a specific config for that. I’m using it right now, for example. So I’m using like, I’m both developer and also a hacker. So I’m using kind of both use cases, development and hacking. So what I have right now is a VM to which I deployed code with like the native option to run over SSH and Claude deployed itself. And what I fold up with, hey, let’s deploy IDEA there as well. JetBrains has the same exact option. Let’s deploy it over SSH. So now I have a VM which can be running anywhere. In this case, it’s running in the same machine I’m working on, but it can be running remotely. Like there is nothing stopping us from this. And like I have a IDE and Claude both pointing to that exact same VM and working on the code. So like I can literally just review whatever is Claude just coded inside of IDE. And like IDE has a lot of nice static analysis tools which will not consume your tokens and can help you find mistakes. So like you got like full, like full experience of code running locally, but you run it over a session or remote machine.
Paul Asadoorian (11:03.111): Interesting. I was looking for exactly that and I think Claude drove me in the different direction and said couldn’t do it. You have to send me what you did after the show because I’m intrigued now.
Vlad Babkin (11:12.93): Yeah, I can actually show you, just poke me right after and I’ll show you.
Paul Asadoorian (11:17.491): Okay, this sounds good. And so, but they were able to find a vulnerability in the Samsung TV and also exploit it, right? There was a kernel module that they exploited and was able to gain through a chain and able to gain a root shell or execute commands as root. Yeah, no, it’s a root shell. Yep. On the system.
Vlad Babkin (11:44.802): Yep, AI is really great at understanding huge chunks of code. Yeah, you need to feed it tokens, you need to feed it context, sure. But it can understand a lot more code per second than your human brain can. So finding a chain for the kernel is a task AI is going to be exponentially better than humans. Again, given that the cloud has data. If Claude has a compiled black box kernel, yeah, it’s probably gonna have problems. But if you can feed that kernel source code or decompiled kernel or like, either analyzed kernel or whatever, it has a lot of data. So it can try to find stuff in there. And it’s usually good at finding stuff in…
Paul Asadoorian (12:28.85): Also that’s interesting, you think it enumerated which Linux kernel was running on there and then went and pulled that exact Linux source code, so now it has the source code of the kernel and therefore it can do the chain.
Vlad Babkin (12:41.836): Yep, either that or maybe they ran it through Hydra or something like this. Because working with black box binary is not exactly AI’s forte. If you give AI… Yeah. Yeah, AI is not magic. If you don’t instrument it, you’re not getting anything. Again, if AI gets a full shell here and it has source code of the kernel, most likely. If not…
Paul Asadoorian (13:06.553): Yeah, it needs a tool to decompile or disassemble and or decompile. Yeah, I got you.
Vlad Babkin (13:11.424): It has some tools, it probably did set up a bunch of tools. Suddenly it’s a lot better with like whatever you want it to do. Give it tools. Don’t starve your AI for tools, give it to them. Give it to AI, AI will like you for this.
Paul Asadoorian (13:28.852): I’m not sure what happened with the disclosure. They did have a GitHub where they released a source code. So you have the exploit source code. I didn’t see anything in here about disclosure though. Which is interesting. Did you guys see anything in there about disclosure? Like there’s no CVE. There’s no CVE for it.
Vlad Babkin (14:00.706): No. I don’t see them contacting Samsung at all. Like, didn’t even mention pinging Samsung. Interesting. Did they not ping Samsung? That would be evil.
Paul Asadoorian (14:08.692): But the, but this is from, this is from MadBugs, which is the Month of AI Discovered Bugs. And they’ve got a bunch of bugs to their, to their credit. And they did issue CVEs for some of them. It says between now and the end of April, 2026, we’ll be dropping what we find in this repo and on our blog. And this is from the Calif.io. I saw that mentioned in the VulnCheck write up in a few other publications that were talking about Mythos.
Vlad Babkin (14:53.55): Mm-hmm.
Paul Asadoorian (14:55.218): Which is interesting, but they used OpenAI’s codex here. But I want to say that this organization or group also has used Mythos and is mentioned in some of those publications as well. It’s interesting. I just saw that recently in a VulnCheck post from Patrick.
Vlad Babkin (15:17.294): Interesting.
Paul Asadoorian (15:18.376): But interesting how they didn’t work with Samsung to pull a CVE but published a full exploit. That apparently works.
Chase Snyder (15:25.973): This reminds me of a recent conversation that we were having too about the Rowhammer attacks against GPUs, which was not on the bucket for today, but we talked about it because we talked about it when the first set of sort of GPU hammer things came out like six months ago or something. And then there was a new set of like, by the way, row hammer style attacks work on these specific makes and models of GPUs, but there were no CVEs. And I asked the AI about it because that’s what you do. And it was like, well, it’s probably because it’s sort of just a general class of vulnerability. It’s not really, it’s not specific to certain makes and models, but it was, there were specific makes and models in that new Rowhammer works on GPUs publication. It was like, why did they not? Who’s what, what, what’s the sort of decision tree for whether you create a CVE? Like, is it just…
Paul Asadoorian (16:22.698): That’s a loaded question. Don’t ask that question of me, Chase, because then you get me up on my soapbox. Because if there is a vulnerability in a software or firmware product, it should have a CVE. Which is crazy.
Chase Snyder (16:36.235): Well, that’ll be a great segue into our increased volume of CVEs, but like. Yeah. And not a, not a super well-defined, kind of a fuzzy container, but like in the case of this one, the, the codex hacking the TV and also in the case of the newest GPU Rowhammer attacks, like why you had to speculate on why they didn’t issue a CVE for that. Like, why is it? They just didn’t want to do the work. They’re not a CNA. I don’t, what is.
Paul Asadoorian (16:47.686): Yeah, I know. But what’s also crazy about that is there are some things that do not fit that definition, like the XZ backdoor, that we’ve issued CVEs for. But then there’s like straight up vulnerabilities where we haven’t issued any CVEs. I’m like, what? What is happening?
Vlad Babkin (17:16.238): There is also another big question to ask. They mentioned that they already have a shell inside of the browser. How does that work? Like there is probably yet another vulnerability they’re not talking about which lets them get a shell.
Paul Asadoorian (17:34.162): Yeah, how did they get a shell? I was wondering that too, because I have Samsung TVs and I’ve not seen a shell inside of the browser.
Vlad Babkin (17:42.926): So there is a vulnerability that they didn’t quite describe. It might be contained within the exploit though.
Paul Asadoorian (17:49.044): Oh, I see. That’s not a feature, that’s a vulnerability. It said, already had code execution inside the browser’s applications, own security context on the TV. The task was not to get code execution, but turn the browser app code execution into root. So this was escalation of privilege, not popping a shell. I got you.
Vlad Babkin (18:12.098): Yup, yup, yup. And in this case also, like AI popping the shell initially with a black box device like a Samsung TV is actually a lot harder for AI than any kind of escape. Again, because data.
Paul Asadoorian (18:32.667): Hence the kernel modules, which is a prime source for privilege escalation. Yeah, yep, yep. So maybe that’s why they released this, because it’s useless to you unless you already have code execution inside the browser’s application, which they did not disclose any details about. That’s how they’re able to do it.
Vlad Babkin (18:49.134): Yep. And we need to dig through their publication because why not? Maybe it’s actually in there. We just don’t know.
Paul Asadoorian (18:58.961): Yeah, so it says, Calif is a security firm from California trying to keep the internet together by occasionally taking it apart. I wasn’t familiar with this organization before. Again, I started seeing it in various publications related to AI, in AI specifically finding bugs. I see, they have a proper website, too. Yeah, yeah, was looking at this the other day. This is definitely the same place. And I think they are using Mythos. I think that’s what VulnCheck was saying. They use other things, but they do also have Mythos.
Paul Asadoorian (19:47.508): There was also a great presentation today from the SANS Institute, completely free. Josh Wright, Chris Elgee, and Ed Skoudis, three extremely brilliant security folks were talking about Mythos and Chris gave a great demo about finding vulnerabilities in source code using AI coding assistance. It was pretty great. It was basically like they’re doing the same thing that Calif, I’m going to call it Calif. Calif, Calif, I don’t know how you pronounce it, but they’re doing the similar kind of thing, right? Which, I mean, many of us have made that transition or making that transition into the tool of choice is an AI to help you find vulnerabilities. But again, like you’re saying, Vlad, it’s not magic. You have to do, I like the word instrumentation because it’s… attempting to use the word training, that’s not that’s training is a different thing in this context. You’re not training a model. Models already trained. You’re just giving it context. Yeah.
Vlad Babkin (20:48.098): You are not training AI. Your model is already there. You’re just letting the model run wild. And in this case, like, tools. Like, they call it tools. Like, in Cloud Code and basically every LLM I have seen, they call these tools. Like, or agentic coding, or this case, agentic hacking. Like, you don’t get AI tools.
Paul Asadoorian (21:09.745): Yeah. But I also heard someone saying that like when you’re developing code using AI, you should be very prescriptive and tell it like which libraries to use. And that speaks to our instrumentation point. I like to tell it which tools, libraries and techniques to use. And sometimes I’ll send it off to the internet. I’ll be like, go on the internet and tell me what tools and techniques exist for this. And then let me pick. Which one? And then you can even ask it. Like I did this the other day with, I was instrumenting libvirt, and there’s a Python library for it. And I was like, wait, how well maintained is that Python library? And it was like, it’s pretty well maintained, right? It does all the things, looks at the GitHub and all the things. It’s pretty well maintained and gave me a lot of data about it. I was like, I want to use that. Let’s use that rather than trying to call the shell to virsh to do what I was doing. So to your point, Vlad, instrumentation is crucial to doing this.
Vlad Babkin (22:13.614): To be honest, what I do with specific coding is instead of giving the AI raw source code, I’m actually writing a document which describes to AI how it can run tests, how it can install stuff, what instructions should it follow. For example, PyLint must not report any extra errors when you finish. Or MyPy should not report any typing errors because that’s hidden bugs. So let AI use stupid tools that will fix its bugs instead of like spending your tokens because it’s cheaper. It’s also easier for you as a developer to validate. And then instead of just sending AI off to make your code, switch to plan mode. Like, lot of code has plan mode. Like, what I do is like, instead of describing it like which libraries to use, which architecture to implement, I would often just query it about, hey, I want this feature come up with a plan.
Paul Asadoorian (23:08.694): Then I look at the plan. If I like it, I just approve it. If I don’t like it, I start to discuss it with Claude. Yes, I do the same thing. I have the same conversations with Claude. Claude and I discuss our plans all the time. I’m like, no, I don’t like that plan. Like redo the plan using X, Y, and Z. And then I’m like, all right, I like this plan better. Let’s go with this plan. Go do it.
Vlad Babkin (23:25.058): Yeah. Yeah. Yeah. And also don’t forget that it’s not a magic automatic coding tool that will code everything for you. So what I do is like for production code, I read every single line it produces because like, yeah, for one of tools, it worked, it solves your problem, you’re gonna throw it out. Sure, forget about it. But if the code is going to production, read every single line. It sometimes does produce surprises. It’s not magic machine which solves everything.
Paul Asadoorian (23:56.069): It’s not 100%. Sometimes you can notice it getting stuck or going in a different direction. And I try and catch it and I quickly hit my escape key. It’s like, no, no, wait. It seems like you’re struggling with this. Rather than doing that, do this. Or describe, why are you stuck and why are you going in this direction? So you have to, I’ve found, constantly refocus it. Typically, I mean sometimes it does, but typically it doesn’t just go off and do the right thing automatically all the time you can go do something else. Occasionally it does that, but a lot of times you’re refocusing it to get around a problem or issue or make a design decision while it’s coding.
Vlad Babkin (24:37.054): Mm-hmm, yep. And what else do we have on our agenda today?
Paul Asadoorian (24:41.746): Yeah, that’s a good, I don’t think we had, well, I talked about Matt Brown. I have not looked at this tool yet, other than just looking at the GitHub for it. But the tool WAIRS, I’m gonna open this now and then the YouTube video is gonna start to play and make noise. I apologize about that. But this is w-a-i-r-z dot a-i. in Tagline Reads, WAIRS, every firmware has secrets, WAIRS finds them. So it’s an AI assisted firmware reverse engineering and security assessment platform powered by AI. It works with Claude Code and a bunch of other things. And Matt Brown gave a great video tutorial. I’ll put that in the show notes. Matt was using it to discover some vulnerabilities in something. And a couple of things stood out. Two things. One, it has this component level analysis. So you bring up WAIRS, you drop your firmware in like the browser interface it gives you, the web app it gives you, and it goes and unpacks the firmware, right? Which is great. Then you do component analysis and it gives you like that brain tree graph thing and shows you the entire file system and which scripts are calling which things, which binaries are linked against which libraries, and gives you a map of all of it, which I thought was super cool. That is super neat. Never seen that before. Then Matt also talks about how to instrument it so that it has those skills to interface with the UART port, which is interesting. So all of that is in this project. So something that we’re going to be taking a look at. It’ll create an SBOM as well. It’ll do fuzzing. It’ll do emulation. All the things that we’ve done or tried to do with firmware over the years now are becoming a lot more achievable. Like emulation is interesting. Boot firmware in QEMU, user mode or system mode in isolated containers with GDB debugging support. Historically, that has been… Super challenging. In fact, I’ve conducted interviews with people that do this and say for any given new firmware, I don’t know this was probably five or seven years ago, they said this could take months to figure out how to instrument firmware to run in emulation. I’m curious now with these newer AI tools if there are actually helping with that. I’ve not played with the emulation feature in WAIRS yet, but that sounds super interesting. I mean, Vlad, you’ve personally also know the struggles of trying to get firmware to run in emulation. It is not easy.
Vlad Babkin (27:32.6): Yes. Yes, it’s not easy, especially if the firmware is non-standard. Like, trying to get a BMC to fully run is a nightmare, especially if you don’t want just the web interface to be up, but also more advanced things, because it does rely on hardware. It’s not easy to actually simulate all of the hardware, and suddenly you’re facing a wall. Yep. Yep.
Paul Asadoorian (27:55.921): Yep, and you get an emulate NVRAM, which is also the sticking point too. But the hardware is more difficult.
Vlad Babkin (28:01.566): Also, what’s very, very difficult actually is that modern firmware is not just one small binary you can actually just analyze completely. It’s a whole Linux file system in most cases. You have a whole Linux distribution and bootloader typically all in one. So what you’re looking at is a full Linux image. So even if you manage to emulate it, like let’s say completely, let’s say you spend like a week and somehow you have managed to run it. Now what? Like as a security researcher, you’re literally faced with an insurmountable problem. You have an insane number of files which you now have to dig through. What do you do about them? I can actually help with this, like even if not fully discover some of the more hardcore bugs, at least point you in the right direction.
Paul Asadoorian (28:58.992): In the right direction. Yeah. Awesome. Chase, which story is really grinding your gears that we haven’t covered yet?
Chase Snyder (29:12.409): You know, it really grinds my gears. I mean, yeah, yeah, that’s exactly what I was trying to say. I don’t know. We had a couple of good potential segues. Should we talk about the CVE growth thing? That was sort of a, you know, we talked about what causes you to issue a CVE or not in any given case. And it turns out that there’s just been a staggering increase in the number of CVEs that was issued and enriched by the NIST NVD database team, whatever it is.
Paul Asadoorian (29:52.614): Yeah, forcing them to have to make decisions as to what they’re going to enrich and what they aren’t. It turns out they’re just going to focus on what’s on the KEV, which is disappointing in my mind. My opinion on it, I think that’s disappointing.
Chase Snyder (30:06.209): Yeah. So they said there were 42,000 CVEs enriched by NVD in 2025, which was 45 % more than any prior year. So that’s a huge growth trajectory, 45 % year over year growth. And we’ve talked about this internally and presented about it externally too, that just the sheer number of CVEs There’s at every sort of tier of security research and operations, there’s just a problem with the volume where it’s like, talk about vulnerability management. Okay. It’s a, it’s an alert cannon. You are finding out about all these vulnerabilities. You can’t possibly handle them all. So you need some sort of risk scoring or some sort of prioritization and prioritizing is hard and takes, takes, effort to.
Paul Asadoorian (31:00.273): Yeah, but I want to take a stab at why we have so many more CVEs. And there’s been a progression. I think the first wave is WordPress. Several companies developed tooling to discover vulnerabilities in WordPress plugins. They became CNAs early on. Years ago, if you looked at the data, it was highly skewed to, in fact, I presented on this at a conference like three or four years ago, three years ago. and it was highly skewed because there were so many WordPress vulnerabilities. So I had to kind of like remove those first, then do some analysis if you wanted like good data. Then the next thing that happened was they enabled more CNAs. And one of the CNAs in particular is the Linux kernel. And the Linux kernel, pretty much if there’s a bug in the Linux kernel, they call it a security vulnerability. And now they’re issuing their own CVEs for it, which also you can go back and look at the data has skewed the data for CVE and forced more CVEs. Then I think the next wave after that, so you added more CNAs and you added a big one with the Linux kernel, the next wave is AI discovering bugs and reporting them has further upticked the CVE. So now you’re forcing all these new CVEs onto a system that, I agree with Jericho, was already broken and not set up to handle the volume before, and it certainly can’t handle the volume now.
Vlad Babkin (32:28.142): Yup. Yup. AI will literally X5 this TV. I fully expect that thanks to AI, this move by NVD is literally them just preparing not to die under the AI workload because discovering the vulnerability and proving that it exists became so much simpler. Even if you don’t use AI for initial discovery, look at the guys who tortured a poor TV. It’s becoming much easier to actually set up a tool which will actually go ahead and produce your full chain to actually exploit the CVE. Before this needed a lot of manual effort. But now it’s just much easier.
Paul Asadoorian (33:10.853): Yes. But what’s funny is the same thing is true managing CVEs and enriching them. It’s a manual effort. Why can’t we use AI on the backend of CVE to help enrich the records? I mean, granted, it may hallucinate and you’ve got, well, the same problems when we use AI for anything, right? But I believe it’s like an AI almost arm, not an arms race, but it’s a leveling up. If researchers and threat actors are going to use AI to do all kinds of nefarious things, including discover way more vulnerabilities than ever before. The defenders and other organizations that are on the receiving end of that stuff and have to do something about it, we also need AI to help instrument that. So given the task of enriching the CVEs, we could use AI. Although then I think about, well, I’ve actually done that and it works out pretty well. If you ask an AI to go score a vulnerability, be interesting test, right, to set up.
Vlad Babkin (34:20.162): Yeah, so the problem is a lot of CVEs don’t have enough details for AI to reasonably score the vulnerability. Like, if you want AI to be able to score the vulnerability, you must force a process where the reporter actually discloses a lot about the vulnerability. It cannot be an unspecified issue inside the method which leads to this. AI is not going to properly score or enrich that. You need actual technical details in every single CV that you’re going to enrich with AI. As I’ve said, it’s not magic machine. It’s not gonna by itself discover vulnerability and Google information about it out of the blue if the information is just not there.
Paul Asadoorian (34:59.378): It wouldn’t be hard to review, I mean, on an individual basis if you’re discovering the vulnerability, right, and you’ve got the source code or the vulnerability problem, like described, you’ve got maybe an exploit or even just a scan or a checking tool that you wrote for it to prompt the AI to go, give me a fully enriched CVE record for that. Then as a human, like you do with production source code, Vlad, you go through every single field and just make sure you agree with it. Now we get enriched records, of course, but every field value in there is potentially debatable, especially the score.
Vlad Babkin (35:34.606): But the question is not just this. Who should be doing this? Like, NVD doing this is not a good idea because NVD does not have the full context. The only organization who can do this is the CNA. But how do you force every CNA to do this consistently? It becomes a chicken and a problem very, very quickly.
Paul Asadoorian (36:00.358): Yeah, because a lot of the data is optional. When you’re a CNA and you create a CVE record, there is a minimal requirement for what data you put in there. All of the enrichment fields are not required, which is why you’ll see CVEs being issued by a CNA that it can be scored with any CVSS. I think as long as it has one of the scoring, if it’s 3.1 or it’s 4.0, it’s up to you which one or both you want to put in there, but as long as you have one. The CPE information is not required as far as I know. Someone can correct me if I’m wrong, but I’m pretty sure CPE is not required when you’re filing a CVE as a CNA. Now, a lot of CNAs do put it in there, which is super helpful, by the way. And if you’re a CNA, I beg you to put that in and enrich it as best you can because it helps us when we analyze the CVE data. It helps us go find the vulnerabilities that you’re publishing way more easily.
Vlad Babkin (37:01.39): To be honest, it’s also very important to note a lot of CPEs that I see in the wild inside of NVD are just not that great. For example, CPEs for firmware and for hardware, in many cases, they present the same device in 25 different ways. So even if you have scanned the device, even if you have identified the device, go ahead and match against it. And now that’s one problem. Like your CPE data is kind of useless. Like aside from like inserting CPE, make sure that they are in the standard format. Make sure that your device can actually return this data operationally. Because if not, this CPE data is de facto useless. So.
Paul Asadoorian (37:45.904): Yeah. Well, it’s interesting too, one of the other fields that, because I actually, I vibe coded a CVE vulnerability analysis tool for internal use. And right now, I don’t know, maybe someday that’ll change. It’s above my pay grade. But one of the things I noticed with the CVE records is the resources and references section. You can put URLs in there, but then there’s another column for tags. So when you put a URL in there that represents a public proof of concept exploit, you can actually tag it with exploit. Same thing, the other tags are like third party advisory, reference, there’s a whole bunch of tags. But I find, even with new CVEs being issued, the data in those fields is inconsistent. You may get a list of references and resources, but they might not have tags. And do they have the right tags? Do they have all the tags? Is it tagged correctly? So that’s a problem. Yeah, it’s interesting why for CNAs we shouldn’t have the enrichment problem. I feel like the CNA should be enriching it. Now, we can talk about the incentives that are backwards because the vulnerability from a CNA is in our, it could be in our, let’s say it’s in our software and we’re responsible for enriching it. We’re biased because it’s our software.
Paul Asadoorian (39:12.421): I think Microsoft does a good job. I think I remember talking to Lisa Olson about Microsoft does a really great job when they issue CVEs to have them enriched. And they’re like one of the better ones at it. But again, it comes down to a resource problem, I think because of due to funding issues, that’s why we’re seeing articles like this from NIST about the enrichment efforts, because this requires resources. And they’re not getting more resources, they’re getting less resources, which is a shame. Crazy.
Chase Snyder (39:44.477): Yeah. I mean, the CISA website itself has had a banner on it for like a year now that says due to the lapse in federal funding, this website will not be actively managed, which I don’t think is strictly true because they keep adding stuff to the KEV. They added some things today. So it’s not, you know, just adding new items to the KEV count as the website being actively managed. Did they mean to take that banner down and they just didn’t? Regardless, you know, CISA has, yeah, been deprioritized, taken some hits in funding. It has not, hasn’t been getting treated the best lately. And I think we’re feeling, feeling a little bit of the burn from that in various ways.
Paul Asadoorian (40:31.247): Yeah, but now speaking of Microsoft, it’s a good transition into, I actually had two items. You had one, Chase, and I had one that I need to add in there, and that is the Secure Boot status that is new to Windows 11 that will give Windows users, so in the April 15th security patch update, Microsoft rolled out a new feature that will give users a Secure Boot status. It goes red, yellow, and green and there’s different conditions that must be met that determine that status. I want to say it definitely exists if you go to device security in your Windows settings if you go to device security there is a security page that gives you like some things about your TPM and other things and in there there’s now a secure boot status. Two things on that and I talked about this last night. It’s interesting that in my Windows 11 VM that totally has this security update applied to it, my Linux KVM VM with Windows 11 does not have the new feature in it. And I’m not sure if that’s because secure boot’s disabled, which I would expect a flag and a message to tell me the secure boot is not enabled. I’m not sure it’s because it’s a VM and using a hypervisor, if it recognizes that and doesn’t enable the feature. Or I’ve just locked down my Windows 11. I’ve stripped it’s a very customized install. I used the Schneegans Windows installer customization to generate the XML file that when you install Windows doesn’t give you a whole bunch of stuff. You can basically strip out a whole bunch of things. So maybe I stripped out the service that gives me notifications, but I would still expect to see it in the device settings and it’s not there. The second thing is, it still shows green even if your certificates are the ones that are expiring in June. Now maybe that’ll change when June rolls around and it’ll tell you your certificate has expired. One of your certificates, I think it’s a key exchange key certificate that’s expiring, that’s getting all the hoopla recently. So I applaud Microsoft for making an effort, however, and this is very biased because of what we do in Eclypsium, but do you want to trust Microsoft to tell you if your secure boot is configured properly? Not so sure, based on my testing so far.
Vlad Babkin (43:02.638): I will add a little bit to this burn. Does this indicator turn red if Windows Recall is enabled or not? the other Microsoft feature which got a lot of flak from the security community. And in this case, like… Yes. Well, I don’t think that would impact secure boot. I think this is just a secure boot related thing. Yeah, I understand, I’m just joking at this point. But like… Yeah. Well, I mean, also, like if an attacker were to get on the system, you could also just make it always show green, I’m sure, with some kind of configuration change or exploit or something. So there’s that. I mean, nothing’s impervious, but… It’s not perfect. So no, certainly not. And there’s a lot of weird stuff with Secure Boot where I believe it could still show green, but let’s say you’ve got a vulnerable bootloader and you haven’t applied the revocation list update for it yet. Does it stay green because it’s configured, it’s on? But how does it know that there’s a new revocation list you haven’t applied? Is it actually checking that? Is actually checking to see if you’ve got the latest DBX updates? I would hope so. I would hope so.
Vlad Babkin (44:21.858): Yep. So, and then there is also the question of, like, how well does it check for vulnerable bootloaders? And, like, how well does it check for vulnerable drivers, which are also part of this entire schema in Shenanigan? So, like, it’s… Right, right. That’s a different subsystem in Windows to check for, well, and it doesn’t necessarily check for vulnerable drivers, but there’s a list, there’s a block list of drivers that you can enable in Windows, yeah. Yeah, that’s Microsoft. Yep, and does Microsoft check for that? Like how reliable is their green status? Because like if you’re green but you have one of the vulnerable drivers, green status is kinda useless. Yep, yep, yep. It doesn’t check your BIOS version. If your UEFI is vulnerable, that means Secure Boot could be completely useless and it would still show green, but since you haven’t updated your UEFI, Windows isn’t checking that. Maybe on their Surface laptops they are, but. Yeah, and for Windows, that’s actually not an easy thing to check for, actually, if you think about it. Microsoft has visibility into Microsoft products. They don’t have visibility into every single vendor. By the way, that’s what Eclypsium tries to do. chill plug, which is not as shameless or as chill. Right. Yes, yes.
Paul Asadoorian (45:34.456): So I’m skeptical, yeah. I know, and we are totally shilling our product right now, just to forewarn everyone, but it’s out of genuine concern. What I don’t want to see happen is people, the worst thing is people get a false sense of security. Like, oh, secure boot says green, so therefore I’m good. And doing what we do here at Eclypsium, we know that there’s a lot of different configurations, options, files, and stuff to check to make sure your secure boot is in a good working in efficient state and I’m not confident that that green indicators is going to go through all those things.
Vlad Babkin (46:19.15): Yep, and to be honest, there a lot of vulnerabilities that you can find related to secure boot. So it’s not just this one thing to check for. It’s not an easy fix. It’s a whole huge feature you have to develop.
Paul Asadoorian (46:29.87): Yeah, well, speaking of vulnerabilities, Chase, that is the one that you added to talk about some of the, at least one vulnerability in the Horizon DataSys Reboot Restore Boot Loader. It had a vulnerability that could lead to secure boot bypass.
Chase Snyder (46:43.965): Yeah. Uh-huh. This is something that was discovered by Eclypsium researchers. Shout out to Stas, credited in the acknowledgement. and yeah.
Paul Asadoorian (46:53.412): Yep. Stas and Mickey, I think we’re both listed in the credit for this vulnerability. CVE 2026-25250.
Chase Snyder (47:04.181): Mm hmm. And they
Paul Asadoorian (47:07.244): And another, I should also point out, another researcher as well. So multiple researchers, so ourselves and I believe one other researcher, it was like dual reported. So multiple researchers discovered this vulnerability and reported it. And it was a variation, I believe this is the one that was a variation of another vulnerability, because that Horizon data system looks familiar. And I remember Stas saying this, it was like a variation of something else.
Chase Snyder (47:33.281): Yeah, there’s a CVE from 2022 that also credits Mickey and Jesse from clicking. It’s in the Horizon data.
Paul Asadoorian (47:42.041): Yeah, yeah. There was one, and I think there was another one that wasn’t us. Maybe there’s three total in this Horizon data-sys bootloader thing.
Chase Snyder (47:54.559): Yeah. And it’s something, honestly, this is something that we, we talked about on our, webinar that we just got off of Paul too, not related to horizon data, but the lack of cryptographic verification, or validation where there was one of the KVM that you and Ray had done the research on that was like not doing any sort of rigorous validation that the firmware was, was what it should be. And so someone could compromise the CDN and deliver, whatever they wanted for the firmware. This is not exactly that, but the CWE that’s assigned to this CVE, if we want to get back into it being complicated and fuzzy categories, the CWE is missing cryptographic step. And I think the situation is you can, you can basically, that would allow an unauthorized attacker to bypass the security feature locally. I think that you can like BYO, BYO bootloader and it won’t verify it. It’ll just loan it.
Paul Asadoorian (48:52.259): Or a component, yeah. Typically, and this is a shared characteristic of many of these types of vulnerabilities and many that Mickey and Jesse have found in the past, the bootloader, as an example, that’s signed calls out to something. Maybe it’s a configuration file like it was with Grub. Maybe it calls some other binary and or program. And that program is not cryptographically signed. So as an attacker, if I can give it my own thing that it calls, whether it’s a programmed or whether that’s like an NSH script. Is it NSH script? Is that the one that you will run in EFI? Is it script? Like at the extension, right? But it calls out scripts. so a lot of times, you know, the bootloader signed cryptographically verified, but it’s calling out to something that can be controlled by an attacker that’s not signed. Therefore I can influence the the boot flow in that scenario.
Chase Snyder (49:56.907): So if we zoom it out a little bit, we’ve talked about two secure boot situations. Yeah, yeah, yeah, okay. Our researcher is talking about it allows loading of arbitrary UEFI drivers from the EFI system partition. So yeah, calling out.
Paul Asadoorian (50:10.477): Yeah, so we can call it to another driver that’s not signed. Yeah, that’s very typical. SMM breakouts are historically very similar technique.
Chase Snyder (50:19.849): Yeah. So we’ve talked about two different secure boot situations going on here, but it kind of seems like, and there’s been, it’s been years in the making that the secure boot update that’s going to introduce a lot of challenges for anybody who’s got windows 10 and 11 or is migrating windows 10 to 11. like what is, it seems like secure boot keeps getting more and more complicated for anybody who has to administrate a system with any number of the, of, you know, devices that have the secure boot standard in them. Like at what point is the juice not worth the squeeze for secure boot? or, know, this type of, this type of a security, like, it seems like you have to have it, but it’s really going to cause a lot of problems for people who can’t, don’t have the bandwidth to effectively administer and deal with this increasing complexity and number of vulnerabilities in it. Like what is the, what’s going to happen?
Paul Asadoorian (51:25.283): Yeah, I I don’t want to dismiss. Well, there’s a lot of people that do dismiss secure boot as an effective security control. In all of the opinion, just because something has vulnerabilities or flaws doesn’t mean we throw it away. it has to be, well, one, you got to make sure it’s properly configured. And then two, which is the harder thing, is you have to keep up with things like revocation lists. And you have to scrutinize all the software that is signed on an ongoing basis to make sure that it doesn’t have vulnerabilities. And that’s the, you know those are the harder things to do. Revocation is hard.
Vlad Babkin (52:05.602): Basically, yeah, the problem is that secure boot is currently a boolean. It’s either true or false. And that’s the mistake. Yup, there should be different levels of secure boot. Like, it’s enabled, it’s level zero. Like, it’s enabled and has fresh revocation list, it’s level one. It’s enabled, has fresh revocation lists, and has controls against vulnerable drivers, that’s level two. And like, you should have at least different levels. Again, I’m just throwing out like levels like I’m an authority here. Somebody has to standardize those. And then I think about them properly, not like in a five minute conversation like we have here. But we should have something like this. Either levels or extra properties like secure boots dot vulnerable drivers. True. False.
Paul Asadoorian (52:59.161): Yeah. That’s interesting. It could be a risk score. Kind of like when the FCC certifies a vendor as okay to sell routers here in the US based on things we don’t know, which is astonishing. So it came out in this Ars Technica article where I think most of us picked it up. Netgear, it says in the article, Netgear is the first major vendor of consumer routers to obtain an exemption from the US government’s sweeping ban on foreign-made routers. Now Netgear, much like 99.9% of all router manufacturers, their stuff comes from China, right? Comes from Taiwan. The components, the assembly, everything. And that was kind of unclear as to, you know, is it where the chips are made? Is it where it’s assembled? We don’t have clear guidance on that. But Netgear’s, they announced an exemption for Netgear’s Nighthawk in Orbi routers and its cable gateways in modems. And we just, I don’t know what led to, does that mean Netgear makes secure stuff? I can say we’ve talked about this on the show in the past, Netgear does have a public bug bounty for its firmware on supported devices. And they’re one of the few, well, I think more do now, but the last time I looked, they were one of the few that actually had a public bug bounty program. They’re actually using Bugcrowd for that, which is interesting. And yeah, this is, but the exemption only goes until October 1st, 2027, at which time they will have to submit a renewal for that. So they’re putting a lot more work on companies that sell consumer routers. They’re still kind of ignoring the enterprise routers, which as we know, don’t contain any vulnerabilities, right? There’s not a new vulnerability in an enterprise router firewall VPN gateway ever.
Vlad Babkin (55:00.418): Yeah, enterprise firewalls, they have not seen a single CVE for those guys. What are you talking about? Which vulnerability sends them? It’s only consumer ones that are bad. Okay, I cannot keep going and not laugh.
Paul Asadoorian (55:16.687): They also haven’t addressed the when you issue new firmware to it, like are they gonna let them issue new firmware to it? That’s completely backwards from a security standpoint. If a manufacturer wants to release firmware because they’re fixing vulnerabilities, we 100 % need to allow that, which is silly. And then the article also talks about, I think, one of the most concerning things for me. I mean, it talks about drones and similar regulations kind of got off topic there in my mind, but they’re not going to be able to prove everyone fast enough, right? Like what is the approval process and what is your capacity to handle all of the manufacturers that are going to be submitting requests?
Chase Snyder (56:05.441): They’re only not going to be able to approve them fast enough if they do some sort of an approval process. Whereas if, who knows what net gear went through, but that was pretty fast. So if you can also just do whatever you want, because the process itself is also subject to sort of, variable levels of execution, depending on, you know, what traits that are not visible to public. They could just, they could just rubber stamp as many as they want. But yeah, the, I mean the, stated justification for the router ban in the first place was that small office and home office routers had been involved in Volt Typhoon, Salt Typhoon, and Flax Typhoon, which were major nation state driven APT campaigns that targeted us critical infrastructure and international critical infrastructure. So Salt Typhoon was heavily focused on telecommunications companies, which is a critical infrastructure category. Others were focused more on power, water, utilities and whatnot. But the involvement of the small office and home office, like consumer routers, was essentially that they got co-opted into botnets that were used as like a staging area to launch DDoS attacks or, you know, to launch other attacks. I read that the, I forget which one of those campaigns it was, I think, Flax Typhoon, the average amount of time that any given individual router spent in the botnet was like 17 days or something. So they’re just churning through. and I don’t know, it seems like we talk about the enterprise firewalls and routers and stuff. There’s been many executive, not executive orders. What did they call that? Binding operational directives issued. and CISA executive, what is it called? EDs. whatever that have stated that for government agencies, they’re required to patch or update or retire within a very short amount of time, sometimes like 48 hours, known vulnerable enterprise devices. So that’s like, that’s a mechanic that they have for addressing those vulnerabilities and known exploited vulnerabilities in enterprise gear that goes kind of right to the core of it. It’s like, We know that this particular vendor, this make and model is vulnerable to this thing. So you have to update it or blockade it, you know, get mitigating controls, compensating controls in place or unplug it within 72 hours. So for this thing, for this router ban to be like, and in order to prevent a small office and consumer routers from being used against us by our nation state enemies, we are going to disallow the import of new ones, but the existing ones that are already in the botnet are still okay. It’s just like, it’s a radically different mechanism that is, doesn’t seem like the way that you would do it. And we know that they know how to address vulnerabilities in different ways because they’re constantly issuing these binding operational directives. So it’s like, stinks about it.
Paul Asadoorian (59:20.963): Well also in the vendors would have to you don’t just get approval as a vendor or manufacturer each one of your products has to be authorized which means if and we all know how many different models and makes all of these companies have it’s staggering so they’ve got 10 new models each one of those has to they have to seek approval for each one.
Chase Snyder (59:48.309): That’s why Nighthawk, Metgear Nighthawk got approved. Looks cool, sounds cool. It’s a very cool router. It’s like a, that thing’s, that thing’s. Yeah, they’re sweet. Yeah, it looks like a stealth bomber. It looks like a jet. It’s cool.
Paul Asadoorian (59:52.802): looks cool sounds cool it is very cool router I had a neck ear one a Nighthawk
Vlad Babkin (01:00:01.39): Yeah, the problem with the directive is that they cannot really go ahead and just ban the whole… How do I tell it? Like, they cannot just ban consumers from using them. Okay, let’s say they come up with such a ban. How do they enforce it across every single person in the US? What do they replace it with? Like, it’s not as simple as like a binding directive for government or for large enterprises who can actually afford and must comply. The users are not gonna spend hard earned $500 on a new router because the government told so. It’s just not a thing.
Paul Asadoorian (01:00:45.134): It’s crazy. It’s crazy. We’ll see how it all pans out. I’m sure it won’t be the last time we’re talking about the FCC router ban here on the show. I want to thank Chase and Vlad for participating today. Thank you everyone for listening and watching this episode of Below the Surface. We’ll see you next time.
