PODCASTS

Memory Safety, AI security, Auth Challenges - BTS #84

Paul Asadoorian, Chase Snyder, and Vlad Babkin discuss newly disclosed vulnerabilities in NGINX and PAN-OS, the persistent exploitation of network appliances, and whether restricting access to AI security tools and firmware images will ultimately make infrastructure less secure.

Welcome to episode 84 of Below the Surface. Paul Asadoorian is joined by Chase Snyder and Vlad Babkin for a discussion about the growing gap between vulnerability discovery and organizations’ ability to defend their infrastructure. The conversation begins with remote code execution vulnerabilities in NGINX and quickly expands into memory-safe programming languages, secure application frameworks, authentication failures, and the impact of AI-assisted vulnerability research.

The hosts then examine a campaign that compromised edge devices to resell proxy access, including attacks exploiting older vulnerabilities in D-Link NAS devices and Ubiquiti video systems. The persistence of these attacks raises a familiar question: if vendors are improving the security of their products, why are so many older devices still vulnerable? The discussion connects technical debt, insecure development practices, difficult firmware updates, and the economics of inexpensive IoT hardware.

A recurring theme is whether defenders are being placed at a disadvantage as AI makes vulnerability discovery and exploit development more accessible. Vlad argues that restrictions on advanced AI models may prevent legitimate researchers from validating vulnerabilities while doing little to constrain well-resourced attackers. An OpenBSD privilege escalation involving decades-old code illustrates how much legacy software remains to be analyzed.

The episode closes with a debate prompted by cybersecurity researcher Matthew Green’s suggestion that vendors should remove publicly accessible firmware images for critical infrastructure. Paul, Chase, and Vlad explore the consequences for independent security research, device maintenance, and vulnerability disclosure. Their central argument is that restricting access to firmware may make legitimate security research harder without meaningfully preventing determined attackers from obtaining the same code.

Key Topics Covered

  • NGINX remote code execution and configuration-dependent vulnerabilities: The episode opens with recently disclosed NGINX vulnerabilities that could enable remote code execution under specific configurations. Paul and Vlad discuss why flaws in mature, widely deployed web servers remain significant, particularly when internet exposure, memory protections, and deployment configurations determine exploitability.
  • AI-assisted vulnerability discovery and exploit development: AI models can help researchers identify vulnerable code paths, compare patched and unpatched software, and investigate complex exploitation opportunities. The hosts consider how these capabilities change the economics of vulnerability research and why defenders must prepare for more vulnerabilities being discovered in less time. Eclypsium explores the same challenge in Mythos Finds Vulnerabilities. But Can Anyone Patch Fast Enough?.
  • Memory safety and defense-in-depth: Paul and Vlad examine the importance of memory-safe programming languages, compiler protections, and operating-system mitigations such as ASLR. They discuss the tradeoffs between C, C++, Go, Rust, and Python, emphasizing that stronger memory protections can raise the difficulty of exploitation even when vulnerabilities remain.
  • Secure frameworks and declarative input validation: Vlad argues that framework selection can prevent entire categories of application vulnerabilities. Using FastAPI as an example, he explains how type enforcement, parameter declarations, explicit HTTP methods, and automatic API documentation can reduce validation mistakes, hidden functionality, and type confusion.
  • Authentication design as a recurring infrastructure weakness: Authentication bypasses remain common across software and embedded devices. The discussion covers the complexity of implementing OAuth 2.0 correctly, the benefits of established authentication frameworks such as Ory, and the security tradeoffs of exposing JSON Web Tokens to external clients. The hosts connect these design problems to persistent authentication vulnerabilities in network appliances.
  • Compromised edge devices and residential proxy services: Paul describes a campaign affecting 143 edge devices across 34 countries, where attackers exploited known vulnerabilities in D-Link NAS systems, Ubiquiti video recorders, and SAP NetWeaver installations. The compromised systems were used to resell proxy access, with attackers sometimes installing SSH keys for persistence. The discussion highlights how attackers continue exploiting weaknesses that have been publicly known for years.
  • Why IoT and network appliance vulnerabilities persist: The hosts examine insecure development practices, resource constraints, outdated software, and the economics of inexpensive connected devices. Vlad questions whether manufacturers should face enforceable secure development requirements, while Paul observes that newer hardware and firmware releases are often more resilient than the aging systems still deployed in production.
  • AI model restrictions and the defender disadvantage: Vlad argues that limiting access to advanced security-capable AI models can disadvantage legitimate security researchers without stopping attackers who possess their own compute infrastructure and less restricted models. Chase explores the tension between preventing malicious model use, supporting defensive research, and the commercial incentives of frontier AI companies.
  • OpenBSD privilege escalation and decades-old code: The conversation examines research involving a local privilege escalation in OpenBSD that chained vulnerabilities, including an integer overflow traced to code approximately 37 years old and a use-after-free condition involving a race. The example demonstrates how security-focused operating systems can still inherit subtle vulnerabilities from historical codebases.
  • Active PAN-OS exploitation and the business impact of vulnerabilities: Paul discusses reports of active exploitation involving CVE-2026-0322, described in the episode as an authenticated command injection vulnerability in PAN-OS. He also cites a report connecting the disclosure to a 4.2% decline in Palo Alto Networks shares. The hosts consider whether vulnerability disclosures and exploitation activity can influence financial markets. For related research, see Eclypsium’s Supply Chain Risks in Security Appliances.
  • Should vendors remove public firmware downloads? A social media post from Matthew Green prompts a debate about restricting access to firmware images used by critical infrastructure. The hosts argue that determined attackers can purchase hardware, extract firmware, or obtain images through other channels, while independent security researchers and legitimate operators would face additional barriers. Eclypsium’s firmware analysis of MSI updates provides an example of security research enabled by access to vendor firmware packages.
  • Critical infrastructure, secondary markets, and security through obscurity: The discussion expands the definition of critical infrastructure beyond industrial control systems to include financial networks, telecommunications, VPN gateways, and management systems. Paul and Chase explain why secondary hardware markets remain important for maintaining aging infrastructure and how restrictions on hardware resale or firmware distribution could interfere with legitimate maintenance and security research.
  • Cryptography, openness, and the value of independent scrutiny: The episode concludes by comparing the public scrutiny of cryptographic algorithms with the debate over restricting firmware access. The hosts discuss AI-assisted mathematical research and why mature encryption systems benefit from sustained independent examination. Paul argues that widely scrutinized cryptographic algorithms provide a useful analogy for why open security research can strengthen firmware security rather than weaken it.

Timestamps

Based on the timestamps provided in the episode transcript.

  • 01:20 – Episode introduction: NGINX, PAN-OS, edge devices, and infrastructure security
  • 03:18 – NGINX remote code execution vulnerabilities and configuration requirements
  • 05:01 – AI-assisted vulnerability discovery and the need for stronger input validation
  • 06:27 – ASLR, compiler protections, and memory safety
  • 07:37 – Choosing programming languages: C, Go, Rust, and Python
  • 09:12 – AI-assisted patch diffing and exploit development
  • 10:24 – FastAPI, declarative validation, and secure web application frameworks
  • 12:37 – Authentication mistakes, backdoors, and insecure device design
  • 14:05 – IoT authentication bypasses and the limitations of custom authentication
  • 15:03 – OAuth 2.0, Ory, JWT, and session management
  • 17:21 – Why authentication is difficult to implement securely
  • 20:05 – Compromised D-Link, Ubiquiti, and SAP systems used for proxy access
  • 22:06 – Log4Shell and long-lived vulnerabilities in connected devices
  • 23:35 – Secure development lifecycle weaknesses in IoT products
  • 24:36 – Firmware modernization, newer hardware, and the problem of outdated devices
  • 25:32 – IoT economics, secure development costs, and regulation
  • 28:15 – AI model access restrictions and their consequences for defenders
  • 31:20 – OpenBSD privilege escalation involving decades-old source code
  • 33:04 – Why defensive researchers need to validate exploitability
  • 34:53 – The asymmetry between attacker and defender access to AI capabilities
  • 37:15 – PAN-OS exploitation, CVE-2026-0322, and market consequences
  • 39:01 – Matthew Green’s proposal to restrict public firmware downloads
  • 40:44 – Defining critical infrastructure and evaluating security through obscurity
  • 41:37 – Why attackers can still acquire hardware and extract firmware
  • 42:45 – Firmware distribution, secondary hardware markets, and intelligence agencies
  • 44:57 – Third-party firmware repositories and supply chain risks
  • 47:00 – Encrypted firmware and the limits of restricting reverse engineering
  • 48:02 – CISA’s definition of critical infrastructure and broader network dependencies
  • 50:23 – AI, mathematical research, and cryptographic resilience
  • 51:20 – Why open scrutiny can improve both cryptographic and firmware security
  • 53:02 – Closing thoughts

Core References

  • Eclypsium – Infrastructure security research and technology focused on protecting critical software, firmware, and hardware.
  • Below the Surface Podcast – Eclypsium’s podcast covering infrastructure security research, vulnerabilities, exploitation, and emerging threats.
  • Eclypsium Listener Resources – Resource page mentioned by Paul, including infrastructure security guides, research, and product information.
  • Matthew Green – Cryptography researcher and academic whose remarks about restricting public firmware downloads prompted the closing discussion.
  • OpenBSD – Security-focused operating system discussed in connection with a local privilege escalation involving legacy code.
  • CISA Critical Infrastructure Security and Resilience – Background on the broad range of infrastructure sectors referenced in the debate over firmware access.

Vulnerability Research & Infrastructure Security

The episode also discusses CVE-2026-0322 in PAN-OS, NGINX remote code execution vulnerabilities, a historical Log4Shell issue affecting UniFi Video, and newly discussed OpenBSD privilege escalation research. These references are preserved as described in the transcript; the conversation does not provide complete advisory links for each finding.

Concepts & Frameworks

Tools & Platforms

  • NGINX – Widely deployed web server at the center of the opening vulnerability discussion.
  • FastAPI – Python framework Vlad recommends for typed request validation and explicit API contracts.
  • Ory – Authentication and identity software discussed as an alternative to building security-sensitive authentication infrastructure from scratch.
  • Go and Rust – Languages discussed as alternatives to C and C++ for modern software development.
  • gRPC and OpenAPI – API technologies discussed in connection with strongly defined interfaces, validation, and documentation.
  • Feedly – Tool Paul mentions using to monitor authentication bypass vulnerability disclosures.
  • Palo Alto Networks PAN-OS – Firewall operating system discussed in connection with active exploitation.
  • SAP NetWeaver – Enterprise application technology mentioned among the affected systems in the proxy-access campaign.

Transcript

Paul Asadoorian (01:20): This week, NGINX fixes with some very specific RCE conditions. Palo Alto’s PAN-OS flaw is under active attack. AI assisted espionage turns government Linux servers into bad things. Edge devices hijacked to sell residential proxy access in an OpenBSD root exploit that goes back decades. Stay tuned below the surface coming up next. Welcome to Below the Surface. It’s episode number 84, being recorded on October 19, 2026. I’m Paul Asadoorian, joined by Mr. Chase Snyder. Chase, welcome. Mr. Vlad Babkin here with us. Vlad, welcome. Quick announcement before we dig into the topics for today. Below the surface listeners can learn more about Eclypsium and how we help organizations assure and secure the infrastructure their operations depend on by visiting eclipsium.com forward slash go. You’ll find our guide to AI data center security, our white paper on eradicating hidden threats in network edge devices, and a case study showing how a major cloud provider used Eclypsium to protect its infrastructure hardware during a merger IT consolidation. You can also request a demo to see how Eclypsium verifies device integrity, hardens against risk, and detects active exploits across enterprise infrastructure, from AI data centers to network edge to user endpoints, all that and more at eclipsium.com forward slash go. Well, we certainly got a lot of fun topics to talk about. I thought the remote code execution in NGINX is interesting. I think anytime there is potential to have a remote code execution vulnerability exposed on your web server, which of course has to be exposed to the internet, is a significant event. What’d you guys think about this one?

Vlad Babkin (03:18): That’s very fun, let’s put it this mildly. NGINX is one of the de facto most used web servers as far as I remember. And yeah, and like it’s one of the most well tested ones. Like if you use NGINX you know that this is one of the most reliable pieces of software you have. Like maybe we’ll encounter a bug every few years. Like which is not often, considering what it does.

Paul Asadoorian (03:27): I think so too. Yeah.

Vlad Babkin (03:47): So finding code execution in it is like a major surprise.

Paul Asadoorian (03:52): I’m not sure if these were AI assisted bug disclosures. If that was mentioned anywhere, but it does require p specific configurations to exist. But as you said, Vlad, NGINX is the number one web server exposed to the internet today, so the likelihood that one of these configurations are being used in production is probably pretty high. And I also think it’s a testament to using AI for vulnerability discovery, which is a topic we come back to on the show, because it just keeps getting better and better all the time. I’ve used it and it does it finds some pretty cool vulnerabilities. You still have to validate them, obviously. But it’s leading us to like these really interesting vulnerabilities that we’re finding at scale, right? Ones that would have taken a human Years or months or maybe as a human you just you never find that particular path because you can’t do that much correlation in your brain. So

Vlad Babkin (05:01): So to be honest, like this is this pushes software to a more fundamental shift. Like r in the past we allowed ourselves to make some sloppy choices in the software, hey, who needs validation for this because this is never gonna be exposed? Hello there, AI will find it for sure. And like a lot of bugs on the web are usually lack of validation, lack of sanitization. Like and a lot of the flaws are like this, including the ones found by AI. Like If you look at all of the kernel escalation bugs, it’s usually some kind of memory corruption or someone forgot to check the boundary or something like this, right? So if you add a draconic policy on validating everything in your code, suddenly your code will be this much more secure. Right? It will not protect you from all of the bugs, obviously, but it will save you from like a good number of Even if you don’t use AI heavily to like actually develop and scan your software for vulnerabilities. Right? So this resonates with another piece of news, I don’t remember where I saw it. Bank of America hired like extra 33% of their engineering workforce in contractors just to handle all of the vulnerabilities they found. In like their software and their dependencies and whatnot. Right? So AI can find a lot more vulnerabilities than us humans, that’s for sure. So the question is how sloppy were before beforehand.

Paul Asadoorian (06:27): Do you think it also okay. Yeah, but I think is whether we’re writing code as humans or with AI, there’still gonna be vulnerabilities introduced. And do some of the memory protections now become also equally as important? They mentioned in the article that remote code execution may be possible if ASLR is disabled or bypassed. And to me that’s the like point we need to perhaps dig in on. If you haven’t checked your binaries to see which compile time flags have been enabled for memory safety, you should. You should also check that, is a twofold thing, right? A lot of these memory protections have to be in the binary and enabled on the system. And that leaves a lot of room for error. And I think as an industry, we have to be much better at ensuring that all these memory protections are enabled because it’s gonna make an attacker’s life much harder. As even with AI is gonna churn, ask me how I know, a lot more when it has to write an exploit that has to bypass these memory protections. It raises the bar of difficulty. And that’s what I think we should be doing.

Vlad Babkin (07:37): Just don’t expose your memory and safe software like C++ to the outside world. Like C like I mean yeah, there are some legacy software which we have to care about, but like any modern software, question yourself if you really want to know C. Right? So what is your reason for using C? Because like if it is great efficiency at control and like you’re developing something for a microcontroller, maybe it’s the right choice.

Paul Asadoorian (07:44): Yeah, well that’s hard. I mean the NGINX is written in C so

Vlad Babkin (08:07): But don’t develop software in C for normal web servers anymore. There’s very lot of like any new web server spawning is like say Caddy out of new names, right? They’re in Golang, I believe, or Rust. In reality, you have to make a choice, and I would say your choice right now is between do you want a slow and expressive language like Python? Because there is a good number of software which will not benefit from compiled languages, right? Even though python is considered slow, first of all they’re slowly improving it, like they’re adding stuff like JIT, right? You will not write anything heavy heavyweight on it, but like what do you want in Python, right? If your Python piece of software is not intended to sit on the hot path, Python is a strong choice. And your alternative choices are probably Golang right now and Rust, the two biggest contenders, right? So Pick one or the other. I would say Golang more for human developers and Rust more for AI code and agents. Because like Rust is a little bit harder to read in my opinion.

Paul Asadoorian (09:12): Yeah, and I but I think this is and this is good advice and something we all need to be thinking about, right? So like what I’m hearing is that we need memory safe languages. We have to improve the code of memory of languages that aren’t memory safe for certain, and we have to make sure all of the memory protections that we have available are enabled. And if we do those three things, our software as a whole will become that much more resilient. And that’s a priority because we have AI that can find vulnerabilities. We also can use this same AI to analyze the patch. What was the code before the patch? What was the code after the patch? And dig into those details to write reliable exploits. For this happens to be, I think NGINX, I don’t know how if it’s all open source, I know there’s also a commercial offering as well. Open source makes it easier, right? Because you have access to the source code. But in commercial software, when you just have patches, patch diffing is great. I think it’s you know something that many are looking at and have implemented and threat actors are one of the folks that have implemented diffing the patch to create an exploit.

Vlad Babkin (10:24): I’ll give you another piece of advice, very important one. When you start a web server, use a framework that is actually safe. Right? I don’t mean memory safety, I mean web safety. Like in Python, don’t use stuff like Django if you can avoid it. Like if you don’t need a website, don’t use Django for Web API. Don’t use Flask for Web API. Like these are great frameworks depending on what you want to use them for. But 99% of time in the modern day and age you will want FastAPI. Because it provides you with a lot of tools to make your code actually safe. And I don’t mean memory safety, I mean you declare a parameter, you declare its type, and you know for sure that it is correctly validated. With Flask, with Django, with

Paul Asadoorian (11:11): And that helps with command I see a lot of authenticated command injection ’cause I think AI is really good at identifying it.

Vlad Babkin (11:17): This eliminates a whole vertical of bugs. So this eliminates any hidden methods because now every single method is documented because FastAPI mandates that. It eliminates hidden parameters, which is a problem. You might not even know that parameter exists. It eliminates validation bugs. It eliminates method mismatch because FastAPI actually allows you to define what HTTP method you wanna attach it to. It also eliminates type confusion bugs. Like they just cannot happen anymore. Right? And suddenly your dynamic language is like much more protected from all of this stuff. Right? And for every language there is a choice like this. Like for Golang, generic advice is to go gRPC. We are trying to build in-house solution for OpenAPI for it. But like in general you want something which does specifically declarative validation. I believe this is how it’s called. I don’t know what the industry name for it, but the grand idea is that you declare things. And let your framework handle the mechanics how to validate it. This b makes the code more readable for you as a developer and more safe from for guys like me, and also more documented for guys like me. So when your external pentest teams comes in, you can just give them full API reference. Suddenly they don’t have to dig through five hundred Git repositories you might have, or however many.

Paul Asadoorian (12:37): And I mean real li you guys know this, right? This is just one attack path. If we look at some of the bugs in our back doors that are being uncovered, you could have a really great architecture or pieces of your architecture that are very resilient and secure. However, like we looked at the I don’t know if we talked about on this show, but the refrigerators in France that were hacked, right? And where the admin password was automatically had a password value of the date. That was accepted as a valid password and that changed every day and it was a backdoor that was built in. So you can have the most secure code on the planet. However, if you make other mistakes like that, it has to be resilient, from the top down. So

Vlad Babkin (13:22): Making authentication system is a draconically complicated task. Like my advice if you know what you are doing, build it yourself. If you really know what you’re doing. Like you can read OAuth 2.0 security model document and fully understand it. Or if not, go for something like Ory. L or o R Y, right?

Paul Asadoorian (13:29): Yeah, especially on these small devices, yeah.

Vlad Babkin (13:49): They have a whole suite of stuff to actually help you make a safe OAuth 2.0 server. You can still trip up on them, but it will protect you from stupid issues hey, you forgot to hash your token, so now an attacker with a SQL injection just dumped all of the sessions. Congratulations. So

Paul Asadoorian (14:05): I ag and it’s funny, Ed Skoudis said this on my other podcast ten plus years ago. He said, one of the problems we have with IoT and firmware based systems is the when you implement authentication, there’s a million ways to do it and a lot of people are messing it up. What we need is a really good solid standard for these smaller devices to implement that authentication. ‘Cause I and he’s right. And I don’think we ever got there ’cause if you look at the proliferation of authentication bypass vulnerabilities. In fact, I had just created a custom feed in my Feedly that looks for the term authentication bypass and there’s ten new ones or every day almost, right? And some of those are duplicates from other feed but there’s new ones every day in software, in devices, in all kinds of things. The ones that make a big splash or the network edge devices that have those vulnerabilities for sure.

Vlad Babkin (15:03): It gets much it gets much worse. Like there is like only one framework that I know of that’s in public. Again, readers, listeners, if you know of other stuff, ping me, of the same quality. The only framework I know for implementing authentication that actually defines a full security model, defines a full standard, follows a full OAuth 2.0 security spec, made reasonable choices is Ory. Literally. There is a reason why named them. I reviewed a lot of them. And a lot of them, hey, we just make this. How do you store your tokens? And suddenly you have to dig through a ton of source code just to find answer to this simple question. Right? And like a lot of frameworks, even built into languages even recommended, don’t store tokens properly. They just drop a session into the file system wherein anybody can read it. Not a great choice, right? And moreover, a lot of the frameworks just say, hey, we will just expose JWT on the outside. You don’t do this. Like JWT is like great for internal inter-service house, but it’s not great to expose it to a customer. So

Paul Asadoorian (16:12): A hundred percent. Like if you have an authentication problem and you implement JWT, now you have two problems. Right, ’cause if you don’t do it right, it’s there’s a long history of issues.

Vlad Babkin (16:19): Now you have now no so Paul it’s worse. If you do it right, you have to have revocation. JWT does not have revocation, so to revoke a JWT you need surprise a database of JWT tokens. Because how else would you revoke them? So you need to check them against the database anyway. So there is barely any upside to actually giving JWT to a Client, like external client. But there are a lot of a lot of mistakes you can make about it. JWT is only great for microservices, literally. It’s not great for exposing it to the outside.

Paul Asadoorian (17:00): It’s interesting. We need to talk after the show ’cause I found JWT in a place I need you to look. Welcome back from vacation.

Chase Snyder (17:07): This is Yeah.

Vlad Babkin (17:07): Sure. Show me. I don’t mind. I love authentication bugs. But if you found it, let’s not talk about this on the show. You will probably hear about it later, guys.

Paul Asadoorian (17:13): Yes. Yes, that’s after the show. Right. Chase.

Chase Snyder (17:21): The question is so like okay, you guys have you guys are dropping fire takes about this and also just good advice. Why is it so prominent that this that people are not already fault do people just not know how? Like Vlad, when you say if you know how to build it, build it yourself. Okay, a very dangerous advice because people don’t know whether they know how to build it or not. People will absolutely under or underestimate their own capacity to understand the OAuth documentation.

Vlad Babkin (17:47): Chase, I can g I can give you I can give a benchmark. Find the OAuth 2.0 security model RFC which exists, read it, and if you can understand every little thing in there, then you can start building. Because if you cannot, you are not prepared. Like I have read this pack at one point when we had to build our own authentication system and their Ory was like just not there yet, right? So And there was literally nothing else. So like it was like build it yourself or just go without authentication system. So I had no choice. And like believe me, that spec is incredibly complicated. Like a lot of things can go wrong in there. And even with like full understanding of it, you can still make a lot of bugs. So like I’m saying here that I like read it and built something out of it, and I still left a few bugs in there, even with full understanding. Like this is why I recommend you to even start looking at Ory first rather than building it yourself. You will save yourself a lot of time and not just building time, but also like just not being bitten by bugs later down the line and g hetting having reputational risks. And that’s an ad that’s an advice from a guy who actually, had to go through with this because there was no other choice. And like if I started the same project now versus when I started that like ten years before, when I have Oriel probably yeah, no, I’m not building this myself, thank you very much. So think about it twice. And like if you want to build it for some something else, like for example for UT and you’re saying that, hey, what we have there is too heavyweight, start it as an open source thing. Invite community to help you build it once and build it for everybody. Like it’s not gonna be what you sell. Like just not. Not really. Like you cannot really sell this because people are not gonna be buying authentication frameworks from you. And building a good L Z is very hard, especially when you have to build it generically. So just build an open source version, everybody will thank you.

Paul Asadoorian (20:05): Well, I wish more people were listening, because there’s 143 edge devices in 34 countries that are getting popped and being used to resell proxy access. They say and these are based on known vulnerabilities in D-Link NAS devices, Ubiquiti video recorders in SAP NetWeaver. And in some cases they added an SSH key, for continued access because, these devices run Linux and That’s on the table. And our own infrastructure is basically being reused by attackers using these known vulnerabilities. And if those don’t exist, they’re just gonna try and password spray to get into these devices. Which is certainly a thing as well. And that’s a continuing problem. I mean this isn’the first time we’ve seen an IoT botnet. They crop up quite a bit and have over time. And we still haven’t solved the problem. Which is worrying. The IoT infrastructure is very fragile and threat actors continue to take advantage of it.

Vlad Babkin (21:15): It’s like recurring problem. Like almost nobody in IoT space implements authentication well. It’s not just this, it’s also like a lot of people just go for hey, my device does not have resources, so I’m gonna use C and I’m gonna implement my own web server and they forgot that Boost exists. So like there are libraries which solve this in C++ even, right? I don’t know how heavyweight they are and how applicable they are for IoT space. But this is literally problem, right? If you decide that you can implement your own IoT authentication framework in something as low level as C, good luck. Like I’m not gonna criticize you for this choice because you literally have to build this device, but don’t expect it to be very safe. Expect there to be bugs.

Paul Asadoorian (22:06): So I got one I got one for ya on this one. The UniFi Video was a Log4Shell vulnerability. Like it still lives. And the D link one was from 2024. Yeah.

Chase Snyder (22:18): Still at it, maybe. What is that how many when was Log4j f happened? That’s at least two years, if not three or four.

Vlad Babkin (22:20): Guys like guys I’ll give another exumeron here. You’re using Java on a device which you’re saying resource constraint. Make or pick. You cannot have Java and resource constraint in one sentence. That’s not a thing.

Paul Asadoorian (22:40): Well, I see a lot of Java but I see a lot of Java code on devices that have to be really interactive like that. Like a video system will often implement Java. IP KVMs, terminal servers, right? Where you need to give the user an interactive screen. BMCs, do we see Java on BMCs as well? Or is usually similar technology ’cause you gotta get a console and typically they implement a heavier language to do that.

Vlad Babkin (23:00): Belief no. I believe that I have seen Java for clients, but like recent versions I don’think use Java all that much. I have seen Lua used as a scripting language because like resource constraint. In this case for real resource constraint, it was not like resource constraint because we said it is, but like for real this resource constraint. So we’re like having to exploit the device we had to like fit our exploit into two megabytes.

Paul Asadoorian (23:14): On BMC is yeah.

Vlad Babkin (23:35): With like full shell and full everything, right? Because like there was literally not enough space to store it. Yeah, there are cases where it’s actually legit small resources. But like again, you got my point, I think. So IoT devices is like notoriously bad with SDLC processes in general. It’s not just like framework choice. It’s the whole s development security process. Like you just open the code that you see sometimes, like when they use a scripting language, and you’re just don’they have any SUS tools at all? I’m again I’m not gonna call out any specific vendors, but if you invite a third party valu estimator and they like say you that hey guys, do you have an SDLC at all? That’s probably a sign that you probably should start doing better SDLC.

Paul Asadoorian (24:36): Yeah, and I think but I mean on the more positive note, I have observed that later versions of the hardware and software for these devices are much more resilient. And I think a lot of the exploitation that’s happening today is preying upon these older devices that people just aren’t updating. And I do think that if you pull latest versions of firmware, you’re gonna have to work a lot harder to find bugs in let’s call it enterprise IoT. Anyway. I even think consumer IoT, Netgear’s had a bug bounty for a long time. They’ve been actively trying to clean up their code. I know later versions of Fortinet, for example, implement much better security than previous versions. And I’m speaking FortiOS. Some of the problems we’ve seen are with FortiManager, Cisco kind of same thing, email gateways, things like that. So th I think they are more resilient. It’s just getting people on the latest versions is hard.

Chase Snyder (25:32): I mean the way that IoT devices are built in particular is they’re supposed to be kind of cheap and throwaway. They’re building them to be as cheap as possible. And any addition of more of a better, security practice or development lifecycle makes it more expensive and people are just gonna buy the cheap one. Like the consumer is trained for it to be cheap. And the makers are, racing to the bottom with that, and none of that is that boosts security.

Paul Asadoorian (25:56): Yeah. But on the

Vlad Babkin (25:58): That’s not healthy at all. It’s like at some point at some point we have to go as hard as just ban this practice on the level of the government. Like if your device does not follow a full SDLC that can be audited, yeah, we are not allowing your device on the market at all. It will make devices pricier, but like there is literally no other choice because like viz with AI, like I myself hate all of this AI doom nonsense. We are not doomed to be killed by modern AI that I know of. It doesn’t even have persistent memory yet. What are we talking about? It’s literally just a pre-trained model. It cannot forever reason. It’s limited by its context. All of the runaway swarms are de facto running on the hardware in the labs, right? There is some talks about AI worms, but you cannot run AI on an IoT device at any reasonable speed. Good luck getting one token per minute out of it. Like it’s not a real threat yet, right? But what I will give as a real threat is that a lot of attackers can use it to actually analyze stuff for threats and for vulnerabilities, and that’s actual problem. Which you cannot solve with like more access control to the models. At some point like we will have to actually concede and say yes we allow free access to Misus to everybody. Because literally all of the attackers already have it. Like the gap between models in China and models in US is like maybe five months. Right? So they probably already have something maybe not Misus quite Misus level yet, but something reasonably strong, right? Where they can actually do a lot of this stuff. And it will o the gap will only be closing. Like they have to acknowledge that the gap is only like a few months. If you are blocking Defenders from getting access Mythos, including Mythos Red, for like whatever they call it. I believe they break red, I don’t know what Mythos version is called.

Paul Asadoorian (28:11): Yeah, Daybreak is blue and red. Mythos I’m not yeah, I’m not sure how they do that.

Vlad Babkin (28:15): This is no idea what they call I’ll call it miso thread, everybody gets what I’m talking about. So the main point is that if you don’t give defenders access to these tools, you’re literally cnick up in your own infrastructure defenders. And like getting access to these models is draconically difficult. Like you guys are literally pushing companies into using Chinese models because they don’t have choice. And that has extra risk for them. But they literally don’t have any other choice. Like Bunning Chinese models are not gonna do anything. Like they’re just gonna keep using it but now secretly. Like

Chase Snyder (28:54): A couple of different incentives at play. Like there’s obviously broadly an incentive to improve our national cybersecurity and to limit the access tools that enable cyber attackers but then there’s also the like corporate incentive of the frontier labs and so they are they’re trying to get the government to do things that are a little bit in the government’s own not in the government’s interest And it’s driving the adoption of the other mod like if you can’t if you get blocked on a defender type task, you’re trying to like deal with an active attack or conduct an investigation and you keep bumping up against the guardrails. The guardrails were put in place, hypothetically, to make it hard to do the attacks, not hard to defend against the attacks, but I’m not sure why they haven’t been able to sort of differentiate well enough to be able to stop you from doing the attacks. It’s kind of a dual use challenge. But what they want is the regulatory capture. They want it to get regular.

Vlad Babkin (30:04): Yeah, they want a regulatory capture. And like my point about this, like in this case, I’m pronoun I’m gonna probably go contra a lot of messaging by AI labs. Like I’m not gonna sign any kind of document from an AI lab that is def the targeted at defenders, up until such a point where they give defenders more offensive tools. I don’t mind if you require validating the defenders, like you need my passport. You need like company’s name, you need to make sure that it’s not from China or from like other governments which are potentially not friendly to US. Like China is just a ephemeral example in this case, the biggest competitor in AI training space, obviously. But like up until such a point where AI labs start being a lot more open about this, I’m gonna just be contrary to all of the claims they do. Like their claims are actually bad for security. Even though they’re literally creating these tools. Again, sorry to say this. Sorry to say this, but there is like fellow in bench dot com just visited. Your models actually breaking other companies is not a sales pitch.

Paul Asadoorian (31:20): Yeah, I think it’s I also think it’s interesting like how we are trying to regulate these tools and we have a lot of software to check. And I think that became apparent to me when I was reading the Calif research where they found an OpenBSD vulnerability. And it says here like right in the second paragraph, right? They trace back one of the vulnerabilities. So they had to chain I believe two vulnerabilities together.

Vlad Babkin (31:20): That’s what I’m saying. That’s it. Nothing else.

Paul Asadoorian (31:50): To get a local privilege escalation on OpenBSD, which also has a lot of other memory and security protections enabled on it. Remember, OpenBSD is touted as the more secure version of BSD, right? Security is top of mind for this project. It has been since the dawn of time. And they trace back one of these vulnerabilities to a 37 year old line of code that originates from the original BSD sources. Which is when you think about 37 years ago, weren’t writing very secure code. There wasn’t a lot of training on it. There wasn’t a lot of understanding of some of these flaws. And I believe it’s an integer overflow that dates back 37 years. That was coupled with a use after free via a race condition. All very difficult vulnerabilities in my mind to discover and also weaponize, especially on systems like OpenBSD that have a lot of memory and exploitation protections on them. Now of course they did fix it, but if you think about we have to worry about code we wrote 37 years ago, we had a lot of work ahead of us and we needed all the AI models to help us review that code.

Vlad Babkin (33:04): And like and moreover, you need models to be able to actually build exploits for defenders. Yeah, you might disag you might disagree with me. You might say that I’m asking for something very dangerous. But like my question to you is, how do you validate if it is actually vulnerable? Either you have to invest time and do all of this work manually, which is not possible with the amount of like vulnerabilities discovered. You’re not gonna be building ten thousand exploits manually.

Paul Asadoorian (33:10): I agree. That’so frustrating.

Vlad Babkin (33:34): Right? Or you use an AI model for this. But because of the guardrails and because of how restrictions are built right now, there are barely any companies which can do this. Right?

Paul Asadoorian (33:48): AI refuse the frontier models refuse to build an exploit for me.

Vlad Babkin (33:53): Yeah, and the point is Chinese models are gonna catch up. So Chinese guys are gonna be first to all of this. And they are gonna be first to attack our software, whether you like it or not. This is like I’m not like I’m against all of the AI scare points, but this is not AI. This is literally just arms race. And like there are actors within our own home who are acting against us at this point. Again, I’m not saying that it is a like companies as a wall. Obviously there are people operating within these companies to make these tools available because we all know that Mythos got released to a whole bunch of people recently, including private physical persons. This didn’t happen out of the blue. So it’s definitely not like evil AI company blocking everybody, because otherwise we would not be seeing such releases. But like all of these releases are too slow.

Paul Asadoorian (34:53): Do you it sounds like Vlad, you think that like the playing field’s already stacked against us, basically. The game’stacked against us because while we’re there’s a lot of regulation and guardrails on the models, but threat actors are using models that can look at source code, find vulnerabilities, can do patch diff, find where the vulnerability is and develop an exploit for it.

Vlad Babkin (35:18): Because like attackers have like okay, I’ll just give you one example. Analyzing source code with frontier model is allowed. Do you have three racks of GPUs in your basement? No, because Chinese guys do. Because like intelligence agencies, okay, let’s not say Chinese, let’say of any country. Like any reasonable country probably has a whole rack of those GPUs, right? You cannot you can regulate them at scale and not allow countries to purchase a data center of them, but a few racks probably made them into basically every country including hostile ones which you regulate against, right? Let’s be honest here. So

Paul Asadoorian (35:34): I don’t, unfortunately, no.

Vlad Babkin (36:01): The main pain point is that they do have rack of those GPUs. And they can run models like GLM 5.3 on them. And they can obliterate those models. And like if you analyze the vulnerability and give GLM 5.3 exact places in source code to build an exploit, it will. The point is you need a rack of GPUs, which is a lot to ask considering their prices. Right?

Paul Asadoorian (36:23): Well, and if you whether you do or you don’t, whatever hardware you have, it just gonna take longer, right? So maybe it takes rather than a few hours to get an exploit, maybe it runs over the weekend and writes an exploit. Who cares?

Vlad Babkin (36:36): Yeah, but because like attacker just needs one and you need to patch a thousand of them. Attacker is definitely more incentivized to buy this rack of GPUs. And like no matter who the attacker is, attackers are now just in a lot better position exactly because of regulations. And even if you block Mythos access, they still have GLM 5.3. Yeah, it will take them Maybe not a few days to find the vulnerability, but let’say a month to find the vulnerability with GLM 5.3 and a little bit more manual instructions. Defenders will now be blinded entirely. So more restrictions does not work.

Paul Asadoorian (37:15): And well, I mean we’re starting but also I think we’re starting to feel the impact. If there’s ever an incentive for more resilience, given everything we just said about attackers having access to these models to create exploits, it I’m not picking on Palo Alto, but I just happened to see an article that was talking about the market and their shares that are being publicly traded. Their shares fell 4.2%. Now, the article I quote says that this is a direct result after reports of active exploitation of CVE-2026-0322, which is an authenticated command injection flaw on PAN-OS.

Vlad Babkin (38:00): Yep. Yep. That’s a massive point.

Paul Asadoorian (38:03): That’s interesting that the stock price was they didn’they didn’t even say maybe. They were This is a result of that. Now will the stock probably rebound? Probably, but

Vlad Babkin (38:11): Yeah, this is Yeah, it will rebound, like obviously, but like stock price is affected by this and like attackers can actually manipulate the market with exploits. Like they can just drop a vulnerability st that’s not crazy. That has been known since twenty years ago. So like one of the most epic cases I know was about stock market price manipulation and it was in pre AI epoch where like vulnerabilities were

Paul Asadoorian (38:23): Isn’that crazy? Yeah.

Vlad Babkin (38:40): Some kind of secret knowledge which nobody even knew yet. But like again, jokes aside saying Attacker is like if you think that more regulation is gonna help you, well yeah, you can outlock crime. Obviously it will stop it.

Paul Asadoorian (39:01): Chase, you had a couple of articles in there. Yeah. I like the Matthew Green one. Yeah.

Chase Snyder (39:06): Yeah, let’s talk about it. Matthew Green, professor who teaches you know personally.

Paul Asadoorian (39:13): Matthew Green’s a nice guy. He’s a very prolific cybersecurity researcher, presenter. I’ve met him like in passing. I don’t know him very well. I’ve seen him present BSides Charm.

Chase Snyder (39:25): Cool. I only know him from Twitter, but that’s how I know a lot of cybersecurity people. I still call it Twitter. Yeah. Post. Let me just read the post out loud. And then we can talk about it. I have to it seemed sincere, but I always question when something that gets this kind of engagement about whether it was intentional. Kind of joking or sincere rage bait or engagement bait, but we’ll take it in good faith. He says, I hate to say this because it goes against everything I believe in, but people are going to need to take down public firmware images for critical infrastructure like yesterday. And this got like a ton of a ton of engagement, right? Tons of respect. Replies of people saying security by obscurity, good idea. A lot of sarcastic replies and a lot of like authentic engagement of people saying why they think mostly why they think this wouldn’t work or that the ship has already sailed on it. But because it’so on target for what we like to talk about here. Public firmware images for critical infrastructures just about as close as you can get to our bread and butter here. Yeah, I don’t know. What’s your guys’ take on it? I kind of think

Paul Asadoorian (40:44): I think it’s I think it’s interesting to define what critical infrastructure is because that’s a relatively broad swath of devices and like where do you start putting boundaries around the scope of what’s critical infrastructure? I tend to expand my scope out a little more than just like PLCs or stuff that’s directly involved with critical infrastructure and expand it out to management devices, VPNs, other things that are garnering access or control.

Chase Snyder (40:48): Sure. Yep. Okay. Point one.

Paul Asadoorian (41:14): Of those environments. I but I also I agree with the comments that this is security through obscurity. Just because there is not a publicly available firmware image, is that will that really move the needle in terms of protecting these devices? I know Vlad does not ag you’re no to that question a hundred percent. Mm.

Chase Snyder (41:15): A hundred percent.

Vlad Babkin (41:37): Immediate no. There is just no point in even discussing this. Like attackers can buy the same device that you have in your lab. They can actually like in your production system. They can build their own custom tools to dump the firmware off of that device and analyze it. Building that custom

Paul Asadoorian (41:59): My fear is what if they start regulating that? What if they go to ebay and be You can’t sell this stuff on ebay anymore?

Vlad Babkin (42:05): Sure, attackers will still find a way. If we are speaking about critical infrastructure, it will just make it impossible for companies like us to buy such devices from eBay to Bing, but it will not make it impossible for like intelligence agencies to acquire these devices. And that’s the main point. Now your attacks and your devices will only be visible to intelligence agencies. Suddenly we will be back to like two thousand five. And like we will hear about big vulnerabilities not because some security firm found them and made good marketing out of it, but because somebody has been abusing them for three years. Somebody with budget to actually bypass the restrictions.

Paul Asadoorian (42:45): It’s true. If the firmware let’s enter w but I think you’re that’s a great point, Vlad, and we’ve got historical evidence that backs it up that this is the way it would pan out. If you start taking down every single firmware for downloading, one, you’ve got a problem because you people still have to get that firmware to make updates in their devices, which means you have to put some kind of authentication or account in front of it. So it’s really it’still accessible, but just the customers, which means some people have it. You’re not wiping it off the face of the planet. The second point is if you restrict hardware sales, let’say on the like third party market such as eBay, you say you can’t sell these devices. One that’s a double edged sword for a lot of reasons. One that just comes to mind is what if I’m a customer in critical infrastructure and I need to go buy a device and maybe the company doesn’t have one, maybe it’s end of sale. And I do need to go to eBay to buy it to keep my critical infrastructure running. Well, that’s certainly a problem. But let’say you do restrict that. Intelligence agencies, there’s many stories where they create front companies to be able to conduct business. It’s in a lot of the books from former CIA people and other intelligence agencies. That’s like what they do, right? Let’s put up a front. I mean they do that when they recruit people all the time. They pretend to be someone else in order to recruit to get information. This is really just another form of getting information. So I put up a front company and I go buy all the devices and now I have them. And so it’s not stopping it’s not really it’s not helping. Like you said, Vlad, it’s preventing legitimate security researchers like ourselves from finding and responsibly disclosing vulnerabilities in these devices.

Vlad Babkin (44:28): Yep. But it’s doing

Chase Snyder (44:29): Particularly in the current sort of environment of the secondary market being super important because all hardware and compute components are super expensive. So there’s a whole swath of businesses that are having either A, keep stuff running way longer past end of sale, past when it stops getting updates, and buy secondary market stuff because new stuff is so expensive in every aspect of the supply chain for this gear is so constrained right now.

Paul Asadoorian (44:57): If you look hard enough as well, there are shady believe it or not, there’shady places on the internet. Now we all know there’shady places on the internet of all different kinds, but of this particular type, there’shady places on the internet that guess what? They post firmware that you can go download. Now, is it dangerous? Is it scary? Is it the does the company that makes that firmware probably owe them legal action? Some of them are based in other countries where legal actions are ignored. And that software is freely downloadable by anyone. Now, could it contain malware or back doors? Yeah, a hundred percent it could. But the internet has shady places. So that’s what’s gonna happen. The more you lock down this firmware, the more those shady places are gonna show up. And look, some of it’s just like my support contract right now and I just need the latest firmware and I don’t wanna pay the support. Now, is that legal, ethical, moral? Maybe not, but some people are forced into that. Some countries are gonna do it because they’re sanctioned and they can’t get that. They have the hardware but they now they can’t get the software. So guess what? They resort to shady means to getting that firmware. So yeah, I don’t I don’think it helps move the needle. I think it’s preventing the good people from doing good things.

Vlad Babkin (46:11): It will literally just block us but not do anything about attackers. And like it will even block legitimate defenders that are larger than us, to be honest. For example, there is a lot of research published by companies bigger than Eclypsium, like obviously there are companies larger than us. And guess what? They also depend on publicly available firmware. So like blocking this download is gonna do literally nothing. Moreover, attackers And defenders probably all have a huge set of pre downloaded firmware. Let’s be direct and open here. Like if you are an attacker and you’re not doing this don’t gonna give you any advice.

Paul Asadoorian (47:00): Now, they could be the I have seen more of a trend of encrypting the firmware, but y usually someone figures out how to decrypt it. Right? I mean that’s just the key is the key is somewhere. The key is somewhere.

Vlad Babkin (47:15): The key is somewhere. Like you might need actual device to actually get the key. But again, as I have said, it’s more problematic for actual legitimate defenders to get the key for all of the devices they have to analyze, versus like literal attackers needing to buy just one. Like the problem is that whatever the hell you do, like you can do a lot of things. Like you can try as hard as you might, right? To make it Really hard to get all of this stuff, right? But it’s not gonna do anything to defend yourself because like attacker only need one bypass for one device to actually bite you. And defenders need all of them.

Chase Snyder (48:02): Well, I know I want touch what you said about critical infrastructure and the definition of it, because it did the use of that term took this discussion down the direction of things like you said, like PLCs and sort of power and water and that kind of stuff. But as our listeners probably know, CISA defines the critical infrastructure. Industries or verticals and it includes a lot of other stuff besides that, including banking and telco and things that are not strictly using that sort of yeah, PLCs and that kind of hardware. So I don’think it’s a stretch at all to talk about network gear that all the big banks and everything use as being critical infrastructure devices. And yeah, I don’t know. I mean in his post he said, I hate to say this because it goes against everything I believe in. And I that seems to have sort of a moral stance attached to it, like no things should be open. So I’m really curious what he what the belief was that he was espousing by saying but it isn’t it goes against what I believe in, but people need to do this. Like I’m genuinely curious what he read or saw or thought that made him think that would be a good idea. But per your also comment about firmware being encrypted and speaking of other Hot topics going around on the socials. I’ve seen theory or the take that, the big frontier AI labs are all solving these age-old math problems, that the millennium problems, these problems that seemed insoluble. And yet no big breakthroughs have come out about breaking the current big cryptographic algorithms or other the tools that we use to encrypt everything. And I saw someone theorize that. The big labs are, basically we’re gonna lose public key encryption because the labs are gonna unravel it basically. Like if they’re solving these esoteric math problems that nobody knows how to really do a use practical applications for, surely these other widely used math challenges. So anyway, yeah, okay, go for it. Vlad, I can tell you have

Vlad Babkin (50:23): I will drop I will drop a counterpoint to this. A massive counterpoint to this. There was a recent breakthrough with RSA that I believe came out of an AI lab with a new potential vector for attacks, right? That’s point one. Point two, another AI lab actually did bite into remand hypothesis, which is directly related to primes and thus RSA. Right? So they are actually doing breakthroughs and research into this department. It’s just that A lot of our cryptographic algorithms, like for example, IS, for example, right, or RSA, they are really well researched. As per why everybody is looking at them. Like some of the older mass problems probably like quite if quite less people looked at it, right? Because there are not enough people to look at all of them. But RSA, IS, everybody is looking at them. And this is why we don’t hear about breakthroughs. I suspect there are no breakthroughs yet.

Paul Asadoorian (51:20): I love this, Vlad, because what you’re saying is the cryptographic algorithms are open for anyone to analyze, coming off the heels of talking about how restricting access to firmware gets us better security. What you’re saying is these algorithms are hardened and resilient because people have had access to them to test them. But if we’d put that back on firmware, we’re doing the complete opposite, right? We’re not getting them out there so people can look at them. And therefore we’re gonna have more vulnerabilities in firmware. I mean it’s a great analogy.

Vlad Babkin (51:53): And again, restricting access to these tools is not gonna do anybody any favors, right? So again I say this with a full weight of understanding that we have software like everybody else. And like everybody else we might get our own software analysed. Like obviously I’m not saying that all of the software should suddenly become open source, that’s not the way to go. But like restricting access to stuff like firmware images is like counterproductive. And Again, if you think that hiding soak your firmware image will save you from somebody reverse engineering it and using it in a competitor product, I have bad news for you. As I have said, they only need to buy one device of yours and rips for that. And

Paul Asadoorian (52:41): Or the threat actors they just need access to the computer you use to download that firmware. It’s again, it’s not a big secret.

Vlad Babkin (52:47): Like yeah, it’s not possible to protect it from attackers. It’s only possible to protect it from defenders. And again, you can outlaw crime. It’s not gonna do anything for the crime, but you can outlaw it, sure.

Paul Asadoorian (53:02): Well, gentlemen, thank you very much for the discussion today. I want to thank everyone for listening and watching this edition of Below the Surface. That’ll conclude the episode for today. Thanks for tuning in. We’ll see you next time.

Back to all Podcasts