PODCASTS

BTS #80 - Exploring BMC Vulnerabilities

In episode 80 of Below the Surface, Paul Asadoorian is joined by Chase Snyder and Vlad Babkin for a wide-ranging conversation about the infrastructure risks that remain easy to overlook until attackers start using them. The episode begins with a brief reflection on Black Hat USA coverage, then moves quickly into BMC exposure, IPMI weaknesses, AI-assisted vulnerability discovery, embedded Linux, router backdoors, weak randomness in hardware wallets, and speculative execution research.

The central theme is not that any one vulnerability class is new. In fact, many of the most important problems discussed are old: IPMI hash disclosure, poor random number generation, speculative execution side channels, and embedded device visibility gaps. What has changed is the attacker’s incentive and tooling. As Paul frames it, threat actors are increasingly targeting the “dusty corners” of enterprise infrastructure where defenders have limited telemetry and weaker operational processes.

That includes BMCs, network edge devices, firmware, and embedded Linux systems that sit below or adjacent to the operating system. These are systems organizations depend on, but often do not inspect with the same rigor as endpoints, servers, and cloud workloads. The episode makes the case that firmware and hardware integrity are not niche concerns; they are part of the foundation modern security programs need to verify.

Key Topics Covered

  • Black Hat coverage and the attention economy: Paul opens by noting the surprisingly limited media coverage coming out of Black Hat USA, while Chase points out that AI security stories are dominating attention and crowding out lower-level infrastructure research.
  • AI accountability and human responsibility: The hosts compare AI-assisted work to self-driving cars: the automation may help, but the human operator remains responsible for what gets deployed, shipped, or trusted.
  • Using AI without outsourcing judgment: Vlad explains Eclypsium’s internal principle: AI can help create code, but engineers still need to understand and maintain what it produces. The concern is not using AI, but letting “AI slop” become unreviewed production work.
  • HD Moore’s BMC research at Black Hat: The team discusses HD Moore and runZero’s discovery of more than a dozen new BMC vulnerabilities across vendors including HPE, Supermicro, Avocent, Huawei, Lenovo, and Dell, along with telemetry showing large numbers of exposed or vulnerable BMCs.
  • Why BMC discovery numbers matter: Paul highlights the importance of runZero’s internal network data, not just internet-facing exposure. Vlad explains that detection methods matter: scanning Redfish alone finds fewer systems than scanning IPMI, HTTP, TLS, Redfish, iLO, iDRAC, and related management protocols.
  • IPMI, RAKP hashes, and old protocol risk: The hosts revisit long-standing IPMI weaknesses, including Cipher 0 and RAKP hash disclosure. Vlad notes that hash dumping and cracking are not theoretical; public and private tools exist, and AI makes reproducing these techniques easier.
  • BMCs as an under-communicated business risk: Chase explains why BMC risk is hard to socialize inside organizations. Security leaders can usually explain ransomware or AI risk quickly, but describing a management controller inside a server requires more context and creates friction in budget and prioritization conversations.
  • Firmware and embedded Linux as the common thread: Paul connects BMCs, network edge appliances, DPUs, AI infrastructure, and IoT devices through embedded Linux. These systems often have rich attack surfaces but limited security visibility compared with traditional operating systems.
  • Network devices as living-off-the-land infrastructure: The discussion links BMCs to broader attacker behavior on network edge devices, where adversaries can use existing device capabilities to sniff traffic, collect credentials, and persist without deploying conventional malware.
  • Cisco IOS XE vulnerabilities found with frontier AI models: Paul covers Cisco’s advisory for seven IOS XE CVEs discovered during internal review using frontier AI models, including high-severity OS command injection and improper access control issues.
  • Patch bundling and operational risk: The hosts discuss why large vendor updates create friction. Organizations may need to apply broad upgrades to fix a small number of CVEs, but those upgrades can introduce configuration changes, compatibility problems, and regression-testing burdens.
  • AI is better at finding bugs than fixing them: Vlad argues that AI may accelerate vulnerability discovery faster than remediation. Paul adds that AI can help evaluate patches, configurations, and upgrade risk only when grounded in reliable data rather than hallucinated assumptions.
  • ZBTLink router firmware backdoors: Paul reviews VulnCheck’s research into ZBTLink router firmware images that allegedly shipped with a startup-script-enabled backdoor based on an old GitHub project. The team debates whether this is best understood as a supply chain compromise, vendor negligence, or intentional backdooring.
  • Cold storage and weak randomness: Chase, Paul, and Vlad discuss hardware wallet failures caused by weak pseudo-random number generation. Vlad emphasizes that poor randomness is one of the oldest cryptographic mistakes, but it continues to cause real losses.
  • Speculative execution and quiet fixes: The episode closes with MIT research showing a practical Spectre v2-style attack against AMD Zen 2 under modern Linux mitigations, plus a discussion of why research can reveal exploitability that vendor advisories do not fully communicate.

Timestamps

00:00 – Livestream setup, audio checks, and opening banter
02:29 – Episode intro: BMCs, cold storage, factory backdoors, and bulk CVEs
02:49 – Welcome to episode 80 with Paul Asadoorian, Chase Snyder, and Vlad Babkin
03:10 – Eclypsium updates, listener feedback, and Black Hat coverage observations
05:35 – Why AI security stories may be crowding out infrastructure research
06:37 – AI accountability, CFAA jokes, and the self-driving car analogy
08:22 – Vlad on using AI while still owning and maintaining the code
09:14 – HD Moore’s Black Hat research into BMC vulnerabilities
11:57 – Internet-exposed BMCs, internal telemetry, and runZero’s visibility
12:37 – Redfish, IPMI, and why scanning methods change exposure counts
14:00 – OOBScan, protocol probing, and device identification
15:27 – runZero’s wide scanning model versus deeper post-auth inspection
16:04 – Cipher 0, RAKP hash disclosure, and IPMI’s long-lived design problems
17:17 – Why IPMI should not be exposed to the internet
18:10 – Hash cracking support in released BMC tooling
18:49 – XDP, Intel ASD, H3C XTP JTAG, and unfamiliar management interfaces
19:17 – BMC hardening as part of broader infrastructure security
19:48 – Attackers targeting “dusty corners” defenders do not monitor well
21:20 – Why BMC risk is hard to explain to leadership
23:33 – Embedded Linux as the shared weakness across BMCs, edge devices, AI infrastructure, and IoT
24:33 – AI lowering exploitation friction and BMCs in AI data centers
26:31 – Vlad notes that the new BMC tool includes Eclypsium BMC&C research
27:34 – Cisco IOS XE CVEs discovered using frontier AI models
29:58 – Patch bundling, regression testing, and operational risk in network upgrades
31:18 – AI’s limits in patching vulnerabilities at scale
32:35 – Using AI to evaluate patch impact and why hallucination matters in operations
34:44 – Why enterprise network configurations are hard for models to reason about
35:23 – Public update experiences versus private enterprise fleet data
36:41 – AI-generated patches, legacy code, and limited test coverage
37:14 – Paul’s guarded use of Claude for chipsec patches
38:22 – Vlad on the risk of unreviewed AI-generated code
39:17 – Bad AI usage KPIs and token-burning incentives
40:56 – Vlad on building InfraTrust quickly with AI while preserving quality
41:30 – Paul on test harnesses, VMs, and making AI-assisted projects reliable
42:40 – VulnCheck research into ZBTLink routers with firmware backdoors
43:56 – Whether the backdoor is a vulnerability, supply chain compromise, or intentional implant
45:24 – Detecting firmware backdoors through device and network analysis
46:24 – Vendor responsibility for shipped firmware, regardless of where the implant entered
47:12 – Vlad’s skepticism about blaming the supply chain
49:13 – Hardware wallets, weak pseudo-random generation, and crackable keys
49:57 – Historical cryptographic failures caused by bad randomness
50:52 – Bitcoin theft, destroyed inventory, and firmware updates
52:26 – Why cryptographically secure random should be the default
54:14 – Paul’s lottery-security experience and the challenge of generating true randomness
56:06 – Lava lamps, entropy, and public randomness experiments
56:50 – Core Impact’s mouse-movement entropy collection
57:40 – Old vulnerabilities, recency bias, and risk that grows over time
58:44 – MIT speculative execution research against AMD Zen 2
01:00:32 – Vlad on research that turns out to be more exploitable than originally reported
01:01:28 – Closing thoughts

Core References

  • Eclypsium – eclypsium.com/go is mentioned as the place to find supply chain security resources, webinars, a ransomware and supply chain paper, a DigitalOcean case study, and product demo information.
  • Black Hat USA – Referenced as the conference where HD Moore presented the BMC research.
  • HD Moore – Founder of runZero, discussed in connection with BMC exposure research and internet-scale scanning.
  • runZero – Referenced for internal and external asset discovery, BMC telemetry, and the OOBScan tool.
  • Accenture – Mentioned as having acquired runZero, NetRise, and Dragos.
  • NVIDIA – Referenced for prior BMC research and the paper “Breaking BMC: The Forgotten Key to the Kingdom.”
  • Eclypsium BMC&C research – Referenced by Chase and Vlad in relation to MegaRAC BMC vulnerabilities.
  • VulnCheck – Referenced for the ZBTLink router firmware backdoor research.
  • MIT researchers – Referenced for speculative execution research affecting AMD Zen 2.
  • AMD – Discussed in relation to a quiet fix for the speculative execution issue.
  • Cisco – Discussed in relation to IOS XE vulnerabilities discovered using frontier AI models.
  • Galaxy Research – Mentioned as confirming bitcoin losses connected to the hardware wallet randomness issue.
  • Cloudflare – Mentioned for its lava lamp randomness wall.

Concepts & Frameworks

  • Baseboard Management Controllers (BMCs)
  • IPMI
  • Redfish
  • RAKP hash disclosure
  • Cipher 0
  • Embedded Linux
  • Firmware backdoors
  • Supply chain compromise
  • Living off the land
  • Token replay
  • Multi-factor authentication bypass
  • AI-assisted vulnerability discovery
  • AI hallucination and operational risk
  • Patch regression testing
  • Cryptographically secure random number generation
  • Pseudo-random number generators
  • Speculative execution
  • Spectre v2 mitigations
  • Time-of-check/time-of-use style timing windows

Tools & Platforms

  • OOBScan
  • runZero
  • Claude
  • Claude Code
  • FEDL
  • chipsec
  • GitHub
  • Cisco IOS XE
  • Arch Linux
  • Manjaro
  • Core Impact
  • IPMI, HTTP, TLS, Redfish, iLO, iDRAC, Lantronix, Moxa
  • Intel ASD
  • H3C XTP JTAG

Vulnerabilities & Exploit References

  • CVE-2026-66747 – Referenced in connection with the ZBTLink router firmware backdoor.
  • Cisco IOS XE CVEs – Seven CVEs discussed as being grouped into a Cisco advisory.
  • BMC vulnerabilities across HPE, Supermicro, Avocent, Huawei, Lenovo, Dell, and others – Discussed as part of HD Moore’s Black Hat research.
  • IPMI Cipher 0 and RAKP hash disclosure – Discussed as long-standing weaknesses that remain relevant.
  • AMD Zen 2 speculative execution issue – Discussed as fixed quietly without a CVE, according to the episode discussion.
  • Debian OpenSSL 2008 and Netscape 1995 randomness failures – Mentioned as historical examples of weak randomness causing cryptographic failures.

Transcript

Paul Asadoorian (02:29.365): Let’s do it. This week: BMCs are still broken. Cold storage runs hot. Backdoors come factory installed, and CVEs are sold in bulk. Stay tuned — Below the Surface, coming up next.

Paul Asadoorian (02:49.557): Welcome to Below the Surface. This is episode number eighty, being recorded on August sixth, twenty twenty-six. I’m Paul Asadoorian, joined by Mr. Chase Snyder. Chase, welcome.

Chase Snyder (03:01.185): Hey Paul, hey Vlad — glad to be back.

Paul Asadoorian (03:03.989): Mr. Vlad Babkin is here with us. Vlad, welcome.

Vlad Babkin (03:07.184): Hey guys!

Paul Asadoorian (03:10.211): 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, and a customer case study with DigitalOcean. If you’re interested in seeing our product in action, you can sign up for a demo — all at eclypsium.com/go. Version 4.4.1 is probably coming to a demo near you — that’s out there now, with some exciting things in our latest release. We’ll also have some updated copy; you’ll find new stuff on eclypsium.com/go.

I do want to put out a call to our listeners: thank you for listening. I actually heard from some friends — “Yeah, we listen to Below the Surface, it’s great.” Thanks for that. Hi, Josh. Leave us feedback on social media and on your podcast catchers, give us a rating, tell us what you want to hear on the show, what you like, what you don’t like. We would love to hear from you.

I’m somewhat astonished at the lack of media coverage coming out of the Black Hat Briefings USA conference. The training happened over the weekend, the briefings started through Tuesday, and at five or six o’clock Eastern time yesterday I had almost zero coverage from media on the Black Hat briefings. Today — we’re recording this at 2 PM Eastern time on Thursday, August sixth — we got a couple of stories. Someone posted some pictures and covered one thing, and then we got a TechRadar article covering runZero’s research that we’ll probably talk about first. Am I missing anything? I’ve been messaging people: “Hey, if you hear anything cool coming out of the conferences, please let me know,” because I don’t know why media coverage is so poor.

Paul Asadoorian (05:35.424): Any theories, conspiracy theories? Is there a gag order that media can’t talk about? Usually someone does a presentation at Black Hat and then they immediately go meet with media, media takes notes and cranks out a blog post. TechRadar is one of the few that did that. Help Net Security was another — other than that, it’s been radio silence about what’s happening.

Chase Snyder (06:00.437): It’s just noisy out there. Not from Black Hat per se, but when there’s a new AI agent swarm inside one of the frontier labs that broke out and coordinated to hack the frontier lab’s major partners every week — those are highly compelling, relatable stories. Everybody’s excited about the AI cybersecurity landscape.

Paul Asadoorian (06:37.633): The AI breaking out — can we file felony charges against AI for violating the Computer Fraud and Abuse Act? Which it clearly did.

Vlad Babkin (06:40.090): Yeah.

Chase Snyder (06:47.147): What’s that meme? “A computer can never be held responsible, so a computer should never make a management decision.” We’re really about to test that reality.

Paul Asadoorian (06:59.583): I get the same discussions with my car. I’ve got a Tesla and I have Full Self-Driving, which I like most of the time. People always ask me, “If you have a few drinks and get in your car and put it on autodrive, won’t you get a DUI?” And I’m like, “Yeah, I will. If I get pulled over, I am still responsible.” It’s the same thing here at Eclypsium — one of our kind of —

Chase Snyder (07:19.189): Yeah. I think it’s pretty clear on that front that you are responsible if you’re the —

Paul Asadoorian (07:29.415): — spoken rules. I’m not sure how official it is, but you can use AI to create stuff — just realize you’re responsible for it at the end of the day. Vlad knows this very well, and that’s kind of our mantra here. I encourage others to adopt the same. That model holds up when you translate it to the car. You’re still responsible. You’re behind the wheel — it’s you.

Vlad Babkin (07:57.489): Yep.

Paul Asadoorian (07:58.603): The automated driving — which it demonstrated to me the first day I drove it off the lot with the salesperson calibrating it — the sign clearly said “No turn on red,” and it did a right turn on red. If a police officer had seen that, I would have gotten the ticket, not the car. So when AI breaks out of the guardrails — anyway, Vlad.

Vlad Babkin (08:22.906): The rule is: if you have to write code that gets deployed to a customer, you have to know enough of that code to maintain it. You might not need to know every single line, but you need to know enough to be confident it actually works. Because if you don’t, what you get is the actual bad side of the AI slop situation.

Paul Asadoorian (08:33.172): Yeah, sure.

Vlad Babkin (08:51.512): A lot of companies now regret that and are trying to hire people back. At Eclypsium, our mantra is that we are not replacing people with AI. AI is a tool. We want everybody to use AI, but we also want people to be able to maintain whatever AI produces. Because if we don’t, there is a problem.

Paul Asadoorian (09:14.036): Yeah, a hundred percent. Something that did come out of Black Hat, which I find very interesting, is BMC research. As we’ve established on the show, Vlad has done more than your fair share of BMC research and published CVEs. NVIDIA researchers that we’ve covered in the past — Chase, I know you have that article and paper from NVIDIA who discovered —

Vlad Babkin (09:28.646): Mm-hmm.

Paul Asadoorian (09:39.979): — vulnerabilities in BMCs. Last week we covered the Lava Security company that published research about scanning the internet and identifying weak IPMI protocol issues. And then just this morning, this was HD Moore’s presentation at Black Hat. HD Moore is of course the founder of runZero, which was recently acquired by Accenture along with NetRise and Dragos. HD presented at Black Hat and disclosed more than a dozen new vulnerabilities in BMCs from HPE, Supermicro, Avocent, Huawei, Lenovo, Dell, and others, with details withheld until the vendors have shipped fixes.

What I find super interesting — we have just a few of the details here, aside from the GitHub, which is all linked in the show notes. HD found eighty-six thousand internet-exposed BMCs, fifty-four percent carrying at least one critical flaw, plus a hundred and twenty thousand more inside corporate networks, with twenty-nine percent of those affected. I like those numbers for a lot of reasons. One, I’m excited that we got the internal numbers. You may be asking, “How do we have internal numbers?” Well, that’s what runZero does — they analyze your network from the inside and they’re very good at that. They do a great job inventorying from inside the network. If you’ve ever tested what was once Rumble and now we call runZero, it will run inside your network. So we get some of the first real telemetry and numbers about just how many BMCs are on the inside of enterprise networks today. I would assume — and I’m just assuming since I don’t have all the details — that the hundred and twenty thousand comes from runZero’s own database. So runZero customers are what’s represented.

Paul Asadoorian (11:57.493): runZero is still somewhat of a young company. They obviously had a lot of growth recently with being acquired. I do think that’s a good number — obviously the true number is much larger. I also find it interesting that HD was able to find eighty-six thousand BMCs on the internet, whereas previous reports from Lava put that at around twenty-six to twenty-eight thousand. So we’re more than doubling what’s on the internet based on recent research. And it’s much larger than when we were just looking at Redfish exposed to the internet, Vlad — it was only like a thousand or two, right?

Vlad Babkin (12:37.156): We were looking at a very specific type of Redfish exposed on the internet. I remember the number being around four thousand, specifically for AMI MegaRAC Redfish. And to be honest, I don’t remember exactly what scanning method we used. Another question is what method did HD Moore use, given that he has runZero under his belt.

Paul Asadoorian (12:41.514): Mm-hmm. Okay.

Paul Asadoorian (12:49.504): Okay.

Paul Asadoorian (13:05.290): Yeah, and also to shine a light on that — HD Moore has done several very large projects encompassing internet scanning over the past several years. That’s why he created Rumble, now runZero, because he had previous experience at Rapid7 — and even before that — scanning the internet. He’s put a lot of time and effort into this, and he’s very smart.

Vlad Babkin (13:30.480): Mm-hmm.

Paul Asadoorian (13:33.289): And one of the nicest people you ever want to meet in your life too.

Vlad Babkin (13:37.007): Yeah. My biggest question in this case, to HD and everybody else, is what they scanned — because not every BMC exposes Redfish, but quite a lot more expose IPMI. What is their detection method? Did they scan on standard ports? Because if so, these numbers are actually explainable. If you actually scan in depth, you’ll probably find quite a bit more.

Chase Snyder (13:37.645): Triple threat.

Paul Asadoorian (13:46.955): Mm-hmm.

Paul Asadoorian (14:00.406): Yes. They did publish a GitHub. So they do an identity probe. This is based on the open source tool released as part of their Black Hat talk — a tool written in Go that can be implemented as a library. They probe IPMI, HTTP, TLS, Redfish, iLO, iDRAC, Lantronix, Moxa.

Vlad Babkin (14:03.590): — and also he might have multiple scanning locations. There’s a lot of interesting stuff here.

Paul Asadoorian (14:30.688): They fuse the signals into a device class plus vendor plus product. This is HD’s very mature skill set and knowledge base being applied to BMCs. One can surmise they developed this tool to do the comprehensive scan and then said, “Let’s just release it open source.” Maybe they had different things they used during the scan that aren’t open source, but they’re also baking the stuff into their product — which is fine. It’s their work. They did great stuff. I think it’s a BSD-licensed Go project. OOBScan — out-of-band scan.

Vlad Babkin (15:27.270): I would not be too surprised. runZero are insanely good at pre-auth scanning. To compare what they do with us — we do in-depth scanning and try to go as deep into the device as we can. They scan wide and cover a lot more protocols. But as far as I last checked, I don’t think they went into post-auth.

Paul Asadoorian (15:35.291): Mm. Yes.

Paul Asadoorian (15:55.368): No, I don’t believe so.

Vlad Babkin (15:58.651): Not fresh data — I might be mistaken.

Paul Asadoorian (16:04.404): They could have pivoted since being acquired — I’m sure lots is happening on that front. But it’s interesting: the tool they released ships with the check for Cipher 0 and the RAKP hash disclosure that was disclosed in 2013, which we talked about as part of the Lava research, and we’re still dealing with it today. Because it’s baked into the IPMI protocol and no one really fixed it.

Chase Snyder (16:39.821): Well, it’s kind of unfixable, right? It’s in the protocol. It’s been there since like 2001 or 2003. And as you noted, you would have to disable IPMI, which would have a lot of downstream impact on management capability — which is what the BMC is for. So the juice isn’t worth the squeeze.

Vlad Babkin (16:45.711): Mm-hmm.

Vlad Babkin (17:02.630): Mm-hmm.

Chase Snyder (17:09.993): So far I’m always a little shocked that —

Vlad Babkin (17:10.438): Yep. Yeah.

Paul Asadoorian (17:11.154): Is it though? Should we not be recommending people not use IPMI in favor of Redfish and harden their devices?

Vlad Babkin (17:17.990): What I would recommend is not using IPMI, at the very least not exposing it to the open internet. And another newsflash — there is a public tool to dump these hashes, integrated into several tools. The last time I checked, they dumped two out of three hash types: SHA-1 and MD5, but not SHA-256. But it’s very trivial to write an SHA-256 tool.

Paul Asadoorian (17:30.484): Yes, several.

Paul Asadoorian (17:40.426): Mm-hmm.

Vlad Babkin (17:44.359): We have our own private tool which extracts all three types of hashes. It’s not like, “Hey, this public tool doesn’t work, so we are safe” — no, you are not. The point is that this tool exists. It took us a few days to construct, and that was before the AI era. With AI, it can probably be done a lot faster.

Paul Asadoorian (17:49.032): Mm-hmm.

Paul Asadoorian (17:54.183): Mm-hmm.

Paul Asadoorian (18:10.176): In the tool they released, there is a hash crack function, and the comment says “crack leaked IPMI RAKP hashes offline — SHA-1, MD5, SHA-256.”

Vlad Babkin (18:18.416): Mm-hmm.

Vlad Babkin (18:24.034): So they actually released the full tool as well. It’s public now — great. And it’s included in scanning. What we have is just a hash dump tool with no brute force attempt. I did it mostly as a proof of concept just to prove a point. We didn’t release it. But it was only a matter of time until somebody did.

Paul Asadoorian (18:25.962): It’s public now. Yeah.

Paul Asadoorian (18:35.390): Mm-hmm.

Paul Asadoorian (18:49.480): Interesting. What’s XDP?

Paul Asadoorian (18:56.958): I’m just reading the tool. It says you can interact with a single target — authenticated and targeted operations. They support IPMI, Redfish, and XDP. And the comment says “Intel ASD, H3C remote XTP JTAG client.” I’ve never seen that before.

Vlad Babkin (18:57.421): XDP.

Vlad Babkin (19:15.086): I don’t think I had either. Interesting — they interact with some protocol I didn’t even know about.

Paul Asadoorian (19:17.588): I think the goal here — now that we’ve seen these two pieces of research — is to really start shining a light on these vulnerabilities and exposures and raise awareness that if you have BMCs, you need to secure and harden them like you do all of the rest of your servers, hardware, firmware, operating systems, and software stacks. I think this is a trend.

Paul Asadoorian (19:48.031): If someone put me on the spot today and asked, “What’s the trend happening in cybersecurity and with threat actors today?” I would say they are very much targeting the dusty corners that we as defenders are not paying attention to. This comes to light not just in BMCs. This is how attackers are using AI today to extract data from people’s networks, how they’re using —

Vlad Babkin (20:06.982): Mm-hmm.

Vlad Babkin (20:14.490): Mm-hmm.

Paul Asadoorian (20:16.606): — token replaying to get around multi-factor authentication, and in identity protection. They’re just letting all the security happen on the identity front, then stealing your session token because you’re already authenticated. You’ve jumped through all the hoops, done the multi-factor authentication, all the checking. And so they’re just replaying that. We see that translating to living off the land on network edge devices. They’re saying, “Well, if you don’t have great visibility into network edge devices, we’re just going to log in to your Fortinet device and use it to sniff traffic and collect more credentials.” To me, that’s the trend — attackers can get tripped up if they use traditional techniques that typically involve getting to root, trying to get domain admin, trying to deploy malware. Now they’re thinking, “How can I just live off the land, and where can I attack where defenders are paying the least attention?” And BMCs, as we’ve pointed out many times, is one of those areas.

Chase Snyder (21:20.809): Yeah. There are certain attack paths or techniques that are just a little bit hard to grasp, or for some reason they don’t capture the public imagination, so they don’t get as much coverage as they deserve impact-wise. Technical people understand the presence and purpose of BMCs, but I’d guess it’s a little bit hard to describe that risk in a compelling way to get people to take action — both up the chain and across the org. Something like “we got a ransomware problem” — ransomware is extremely well understood, it’s splashy, and it’s easy to get investment and dollars allocated to preventing that. But if you try to tell your org, your manager, and your board —

Paul Asadoorian (21:57.149): Mm-hmm.

Vlad Babkin (22:11.856): Mm-hmm.

Chase Snyder (22:19.233): — “Hey, there’s this BMC vulnerability thing happening — the BMC is this management chip inside the servers” — there’s a higher barrier to understanding it. With any increase in friction in explaining why it’s a problem, we run into this all the time at Eclypsium, because —

Paul Asadoorian (22:33.429): Yeah.

Chase Snyder (22:43.541): — historically we focused on firmware, and now we’re focusing more on network devices, BMCs, and so on, where there’s a level of technical understanding you have to have to really grasp the level of risk at hand. It’s just hard to propagate that through the right channels in an organization so that the people who can allocate resources to solving the problem will do it, instead of focusing on something splashier or more currently buzzworthy — like securing AI agentic systems. You’ve got to secure your agentic AI systems, but the BMC is this huge risk that they’re just not seeing in the news as much. Nobody’s breathing down their neck about it, and meanwhile it just keeps getting more and more urgent.

Vlad Babkin (23:32.325): Mm-hmm.

Paul Asadoorian (23:33.109): I think the common exposure and weakness is embedded Linux. If we were to point at something where you don’t have great visibility and which represents vulnerabilities and exposures that threat actors can take advantage of, one of the common threads is embedded Linux. These BMCs are largely embedded Linux. Network edge devices and appliances are embedded Linux. Your DPU and AI infrastructure is embedded Linux inside the device. IoT devices are essentially embedded Linux. And threat actors are just having a field day because Linux has such a rich feature set. Since it’s embedded inside the system, you don’t have great visibility and control over the security posture of these devices.

Vlad Babkin (24:27.226): Yep.

Paul Asadoorian (24:29.364): And that’s the problem — threat actors are having a field day.

Chase Snyder (24:33.003): Yeah. And as you said, the amount of friction to exploit this stuff is getting lower and lower, partly because of AI — just the speed at which you can discover systems that are vulnerable and find the path in. It used to be kind of a hard thing to do, and it’s now radically easier — and probably more successful because there just isn’t as much security visibility or security energy being allocated to monitoring or preventing those paths. Multiple things are happening at once that are leading to that.

The BMCs specifically are an increasing risk and being targeted more and more. And because BMCs are present in all the giant AI data centers being built out, NVIDIA published this paper — mostly not new vulnerabilities they were disclosing, more of a summary — it’s called “Breaking BMC: The Forgotten Key to the Kingdom.” It actually cites some research from Eclypsium written by Vlad in 2022 about the BMC&C vulnerabilities in MegaRAC BMCs. So NVIDIA put the word out that, by the way, NVIDIA AI hardware and infrastructure has BMCs in it —

Vlad Babkin (24:45.883): Yep.

Paul Asadoorian (25:42.240): Yep, it tracks.

Chase Snyder (25:58.412): — that use IPMI and have a bunch of these potential risk factors, but you just don’t see a lot of action on it. But with the increasing drumbeat of publications about it — up to and including this recent one from HD Moore at Black Hat — you’ll start to see more investment or attention on it. I hope so anyway.

Paul Asadoorian (26:23.766): I hope so.

Vlad Babkin (26:27.045): Yep.

Paul Asadoorian (26:27.094): Vlad, did you have a comment there?

Vlad Babkin (26:31.022): I’m just looking at the tool. It does include our research for BMC&C, of all things, and a lot of other things. This looks like a very comprehensive tool.

Paul Asadoorian (26:36.630): Mm-hmm.

Paul Asadoorian (26:41.984): So it does include our BMC&C stuff. Okay.

Vlad Babkin (26:46.234): Yeah — pre-auth vulnerabilities at the very least. It doesn’t check for post-auth code injections and stuff, but I don’t think there’s a lot of value in checking for those once you have pre-auth checks. Because if you can bypass authentication, it’s still really bad. This tool provides a lot of visibility. Also, it looks like it scans multiple ports. In our research, I believe we scanned just Redfish port 443 and looked for specific Redfish. In this case, there are literally ten ports or so just from looking at the top of the list. This sounds like very fun stuff — this explains how they detected so many more BMCs.

Paul Asadoorian (27:27.903): Interesting.

Paul Asadoorian (27:34.699): Yes. They increased the scope. On the topic of embedded Linux — Cisco patching IOS XE. Their advisory — I believe there might be more than one, but the one I looked at covers several CVEs. The description says seven, and these seven were addressed in the same advisory and found during an internal review where Cisco states they used frontier AI models to discover these vulnerabilities. They did find a 9.8 OS command and argument injection, a 9.0 improper access control, and they bucketed it into one advisory, which is not really that helpful.

Because now you’ve got this complex matrix — multiple CVEs fixed by the same patch. Basically you have to upgrade to the latest version. If you want one of those fixed, you have to apply the patch that fixes all of them. This hits on something I haven’t complained about in a while: when we are patching and upgrading systems, it’s nice to move at a pace where you can break work up into the smallest steps possible, rather than applying a huge update just to address the security vulnerabilities. You’ve got to upgrade to version 17.9.10. If you’re at 17.9.1 or 17.9.9, you’ve got to take everything that’s in that update in order to get those security fixes. Who knows — maybe that upgrade is just security fixes, or maybe it’s also other features and bug fixes lumped in. But in order to get coverage for seven CVEs, you’ve got to do this one big update. You can’t piecemeal it. You can’t break it up. You have to apply the update from the vendor, which introduces larger operational risk —

Paul Asadoorian (29:58.560): — the possibility that something can go wrong. If I remember my Cisco days, you would configure Cisco devices and equipment very specifically for your environment using specific features in specific ways. An update could change that behavior and may not be backwards compatible with your configuration. This is one reason many organizations don’t rush to update and will lag behind on fixes — because you basically have to do regression testing within your own environment on your own devices. Sure, Cisco does regression testing in their code, but you have to do it in your specific configuration. I think that’s really bad. I’d like to see smaller, incremental improvements — maybe just patches for the security fixes that don’t introduce any other operational risk. Sometimes fixing a vulnerability could itself introduce operational risk; we’ve certainly seen that before.

And also, you’ve got to pay for updates. “Hey, we found these vulnerabilities, you’ve got to update — and by the way, you need an up-to-date support contract to get them.” This isn’t the only time we’re going to see AI discover vulnerabilities that we now have to patch. In fact, I think there are two this week where AI discovered vulnerabilities. Expect that trend to continue.

Vlad Babkin (31:18.726): Mm-hmm. Yep. And considering just how many vulnerabilities we will find, I have very high doubts that AI will be able to patch all of them. So far, what we have observed is that AI has been a lot better at finding vulnerabilities than patching them. And considering all of the huge frontier labs are stingy with letting people use AI for security purposes — you cannot even ask it to patch code anymore.

Paul Asadoorian (31:47.433): Yeah, they’re handcuffing the defenders.

Vlad Babkin (31:50.651): Yep. And as I have said multiple times during BTS, this is not going to leave you anywhere. Handcuffing the defenders like this — defenders don’t have time to deal with your guardrails. Obviously, they will not be bypassing them. But attackers are highly motivated to bypass all of your guardrails, and they will. They will use your tools whether you like it or not. If you don’t trust my word on this, just check the recent distillation attack news from Anthropic. They tried to change this attack multiple times and couldn’t. They’ll probably be a lot less loud about somebody bypassing guardrails and using their models for evil.

Paul Asadoorian (32:35.882): Yeah. Using them for defense is not without its challenges. My buddy Tyler Shields and I were talking about this last night and collectively came to this point: let’s say you’re using a model to find vulnerabilities in a given codebase. The model can hallucinate and go, “That wasn’t right, let me try a different way” — just keep making mistakes. There’s a certain error threshold where it can fail a lot. When it comes to using it for defense, let’s say I have a model with agents that I can send out to my Cisco fleet — evaluate this batch of Cisco IOS XE routers, consume the configuration, go to Cisco’s website, see what all the patches are, see what changed in each patch, see what the change log is, do an analysis, and say, “Will that update impact my configuration?” Now, you can do that. I’ve done similar things. I’ve built it into my open source tool, FEDL, but that’s just for a single user to evaluate a single workstation. When you’re doing that in an enterprise where you have thousands of routers and you’re asking AI to do that, AI has to be super accurate. It can’t really hallucinate. The more it hallucinates —

Paul Asadoorian (34:03.946): — the more you can introduce operational risk. It may tell you, “Hey, this patch is gonna work just great on your router” — and you apply it and it blows up. And the model goes, “Sorry, I hallucinated that. I thought everything was going to be fine, but it wasn’t.” That’s the difference.

Vlad Babkin (34:15.534): Yep. As a human you cannot really predict when it hallucinates. You cannot research it yourself. And the thing is, it hallucinates like this all the time, especially if you pressure it. If you really want it to be successful, it will eventually cave in and hallucinate — and it turns out it won’t work. For the model, it’s incredibly hard to inspect all of these black box update packages just from change logs.

Paul Asadoorian (34:21.578): Mm-hmm.

Vlad Babkin (34:44.474): Because at Eclypsium we constantly struggle with: we don’t know what command output even looks like for multiple commands because there are no examples online. We cannot write a parser without having a live device. Here it’s even worse — you have limited change logs which might not mention a specific interaction with your configuration. And Cisco is not providing any compatibility tools for easy checks.

Paul Asadoorian (34:44.661): Yes.

Paul Asadoorian (34:54.867): Mm-hmm.

Vlad Babkin (35:13.294): So the model is guessing as much as the human is. Even if you ask the model to find any problems, it will only find whatever is already found by Cisco. If it hasn’t been found by Cisco, you’ll hit a surprise.

Paul Asadoorian (35:13.418): Mm-hmm.

Paul Asadoorian (35:23.626): Right. Yes. That exercise of using an AI model to predict the success of an update gets better if you feed it information from other people who’ve applied that update and reported problems. That’s where I benefit in the open source world — Arch Linux, or Manjaro my specific distribution, creates a forum thread where people share their experiences applying the update. I use AI to consume that and match any of those problems to my configuration — will I run into that? That’s much more accurate because it’s not based on the model’s assumptions; it’s based on consuming other people’s experiences. If you’re the first one applying that Cisco patch, I don’t know what’s going to happen.

Vlad Babkin (35:56.324): Yup.

Vlad Babkin (36:04.752): Yup.

Vlad Babkin (36:13.552): But the problem with people who have massive fleets is that they normally don’t share configurations openly because it’s literally corporate security-related information. You don’t just publish your whole corporate network. Even if they did, it’s a great risk to themselves. So they will not. And in this case, the model is essentially running on fumes. There is nothing the model can do because there is no information for it to consume.

Paul Asadoorian (36:21.342): Right. Yeah, they can’t share their experiences.

Paul Asadoorian (36:36.254): Yeah.

Vlad Babkin (36:41.382): This is just the operational risk of upgrading. Don’t even get me started on getting the model to patch legacy code with little documentation — which is what this code is. Okay, it will produce a patch. Will it work? Maybe. Fifty-fifty. The code doesn’t have tests for the most part. Even if it does, who says the model won’t break tests in the patch? If you have five of them, you can probably review them. If you have fifty, maybe with a team.

Paul Asadoorian (36:51.498): Yes.

Vlad Babkin (37:10.480): But if you have five thousand of them, like what we’re going to face — yeah, most of those patches are not going to get reviewed.

Paul Asadoorian (37:14.740): It’s funny, though — I actually submitted three patches to the chipsec project this week. I used Claude, but I heavily gated everything it did. I said, “You need to show me exactly what we’re going to submit as a pull request,” and I reviewed it line by line. It also went back into the git history of chipsec and told me, “Hey, someone mentioned this or reported this as a bug, and there was a thread about it related to your patch. Let me analyze it.” And I was like, “All right, give me that information.” We kind of analyzed it together. Because everything is public — the source code is public, people’s pull requests and issues are all public — Claude was able to consume that and help me make decisions.

Vlad Babkin (38:05.734): Mm-hmm.

Paul Asadoorian (38:10.420): Notice it helped me make decisions, not make decisions for me. It was able to gather that telemetry and context, which allowed me to produce really good patches. We’ll see if the pull requests get accepted.

Vlad Babkin (38:22.758): The problem is, for every person like you who actually reviewed every single patch, there are twenty people who just say “Claude, make me a patch” and push it with no review. For certain types of projects, that’s just not okay — but people don’t distinguish between chipsec actually being able to fry their hardware versus a patch for some kind of Tamagotchi game application.

Paul Asadoorian (38:30.622): I know. Yeah. Right.

Paul Asadoorian (38:45.001): Right.

Vlad Babkin (38:49.636): Those are two different applications — one of them can literally fry your hardware, and if the other fails, well, you don’t get Tamagotchi for a while. People don’t get this.

Paul Asadoorian (38:56.660): Yeah. Well, we’re also in a unique position because the people who created chipsec originally work here at Eclypsium. So I was able to send some of those patches to them first — “Hey, what do you think?” And they’re like, “Yeah, those actually make sense.” So I had another human in the review process as well. But again, not everyone goes through that level of diligence.

Vlad Babkin (39:04.068): Yup.

Vlad Babkin (39:10.352): Yup. Yup.

Vlad Babkin (39:17.286): Yeah, nobody goes for this level of diligence. The biggest signals I have right now are from speaking to people working in large companies, because some companies produce stupid KPIs like “burn $10,000 in tokens or we fire you” — you know what this reminds me of? For a while, Indian development companies had a KPI of lines of code. Not sure if they still have it.

Paul Asadoorian (39:36.340): Yeah.

Paul Asadoorian (39:45.950): Right.

Vlad Babkin (39:47.386): I have seen code of that era, and quite a lot of it was written just to inflate the number of lines of code.

Paul Asadoorian (39:54.430): It’s like lots of Java code — just write as much Java as you can.

Vlad Babkin (39:57.575): Just write as much code as you can. Here it’s even worse because companies give people absolutely unreasonable limits. For example, a single person working at full speed, reviewing at least some parts of the code — with a Team plan on the cloud — can barely hit the team plan limits. That’s someone working at full speed even skipping some of the review process, because there’s just no way you review all of the code at that plan.

Paul Asadoorian (40:16.287): Mm-hmm.

Paul Asadoorian (40:24.416): The way you chew through your tokens is you do two or three projects at once — that’s how you chew through your tokens.

Vlad Babkin (40:27.718): Yeah, but even then — I didn’t hit my premium seat limit, which is about a hundred bucks. Even if I did two projects at once, I would probably just hit the limit on a five-hour stretch. I didn’t even hit weekly limits once. And this is with me working at a reasonable pace where I’ve offloaded a lot of execution work to AI. InfraTrust was built using AI very, very heavily.

Paul Asadoorian (40:36.917): Mm-hmm.

Paul Asadoorian (40:43.444): Yeah. Right.

Vlad Babkin (40:56.226): Without AI I would have built it in a month; with AI I built it in a week. It had a lot of autonomy. But the point is I didn’t manage to exhaust my tokens when asking it to produce quality stuff. A lot of people don’t do that. A lot of people just throw code at it. And now what happens is that companies are silently unhappy with people doing this. Eventually it looks fun — it looks like we can fire half of our workforce. But then —

Paul Asadoorian (41:11.894): Mm-hmm.

Paul Asadoorian (41:19.562): Yeah.

Paul Asadoorian (41:25.749): No.

Vlad Babkin (41:26.214): — who is going to support all of this stuff? The companies are going to start hiring back. It will be quiet.

Paul Asadoorian (41:30.962): Because you have to test it too. The way I’ve started using it is — I’m developing the FEDL tool, using it to maintain my systems, spotting bugs, fixing them along the way. But I’ve also had to build a test harness. I’m like, “Go build five VMs, test the tool against all five of those VMs, analyze the results,” and I walk through it step by step. So when I get to the point where I’m ready to issue a stable release, it’ll be based on — yes, a vibe-coded project — but based on it actually running against virtual machines of every single target, with every single feature tested in small batches. I’ve probably fixed a hundred different bugs just by using it to test itself. And you can’t just tell it to test — you have to tell it specifically how to test. Because as we just stated, the models will hallucinate and go, “Yeah, all the tests passed.” And I’m like, “No, no, no. I want specific tests, each module inspected — the results and guidance on what a good result is versus a bad result.”

I do want to talk about VulnCheck’s research into ZBTLink routers that came pre-installed with backdoors. They found these firmware images — roughly two dozen across twenty models — that ship an implant that the vendor, well, they say the vendor itself starts at boot. But this implant is actually based on a 2015 GitHub project, RCTL, and was found running as a fake kernel worker. Kernel processes have square brackets around them. Regular processes in Linux don’t. And kworker usually has square brackets to indicate a kernel process. This one just said “kworker” with no square brackets — which, now that I verbalize that out loud, they probably could have faked. But they’re basing this backdoor on an abandoned 2015 GitHub project. This was inside the router firmware. The startup scripts inside the router started up the backdoor, which requires no authentication — basically an ungated C2 channel. It is being tracked as CVE-2026-66747. There was no disclosure process and no fix.

Paul Asadoorian (43:56.417): This isn’t necessarily a vulnerability — though they did issue a CVE — but they felt, and I agree, that this is a backdoor inside a product. It’s not a defect, bug, or vulnerability. This is intentional. My guess is there is a probability or likelihood that the backdoor was not implanted by the manufacturer itself, that it came from somewhere in the supply chain — through the supply chain is how they acquired the firmware to run their routers, and someone in the supply chain implanted this backdoor unbeknownst to the manufacturer. Now I’m giving them a huge benefit of the doubt if that was in fact the case.

The other scenario is the manufacturer knew it and shipped firmware with known backdoors that gave them a root shell on these devices. So it initiates the process from inside, goes out through your NAT. The C2 protocol again has no authentication at all — it’s basically just a root shell hanging out there, which anyone can take over if you’re able to control DNS and control the flow of that router. Anyone could utilize this backdoor. Pre-owned. Again, we’ve talked about this situation before. This is pre-owned.

Paul Asadoorian (45:24.542): The way to spot these is you have to analyze the firmware on the device. You might spot it on the network, but if you don’t know what you’re looking for, that can be tricky. Now we know how to spot it on the network, but this one’s really interesting. My concern is when this becomes more of a trend — when we see this not just on IoT devices, but devices in general. We’ve seen it quite a bit on IoT devices — this ongoing Android saga of this happening as well.

Vlad Babkin (45:57.841): Mm-hmm.

Vlad Babkin (46:01.838): In this case, either the manufacturer had no controls whatsoever over their routers, or — how this happens is beyond me. You have to have no validation and no control over what goes into your router to allow this.

Paul Asadoorian (46:24.404): Yeah. If they had no supply chain diligence — let’s pretend for a moment that this is a supply chain attack, that whoever had access to this firmware before it was shipped to ZBTLink implanted this backdoor, delivered it to ZBTLink and said, “Here’s your router firmware.” They contracted out for firmware, it works, they did functional testing and never looked for any other type of anomaly or supply chain issue — they’re still responsible. You just shipped firmware that had backdoors in it. Whether it came from your supply chain or whether you put it there yourself — if it came from the manufacturer directly, I’m really disheartened that a manufacturer would intentionally put backdoors. I’m leaning towards this being a supply chain defect, but who knows if we’ll ever truly find out.

Vlad Babkin (47:12.614): I would not be so trusting of manufacturers. Backdoors of this level don’t happen magically. Somebody had to have really evil intentions to put it there. Chances are it might have been some misconfigured support feature or whatever.

Paul Asadoorian (47:17.846): Mm.

Paul Asadoorian (47:32.650): Doesn’t look that way, though — because it looks like they’re trying to hide it. The fact that you’re running it and calling the process “kworker” — you’re trying to hide it. It wasn’t a support feature. You’re trying to hide this process on the device. That’s an indication — that’s why I lean more towards the supply chain aspect. I don’t know.

Vlad Babkin (47:39.812): Mm-hmm.

Vlad Babkin (47:48.998): True enough.

Vlad Babkin (47:55.025): True enough. I suspect it is a vendor trying to shift blame. Think of it from my Ukrainian perspective — if I tried to backdoor my products to this degree and then got caught, “it’s a supply chain attack” would be my immediate reaction. So I’m not giving people as much benefit of the doubt as I probably should. But for me, this is just way too big of a supply chain attack. Somebody had to implant your startup scripts. There is a level of lack of controls at which point it’s not supply chain. If you don’t even check your startup script, then what else is in your firmware? Maybe it’s not the only backdoor — it’s just the most obvious one. The one that’s supposed to be found while the second one stays hidden.

Paul Asadoorian (48:32.050): Yes. Yeah. Right.

Vlad Babkin (48:53.286): At this point, I would trust it to be a supply chain attack if it were like the liblzma situation — when it was really well hidden inside liblzma and we only caught it on accident because somebody at Microsoft noticed something odd. Here, it’s in the startup script. Sorry for the strong language, but it is what it is.

Paul Asadoorian (49:05.182): Mm-hmm.

Paul Asadoorian (49:13.246): Yep. Chase, you had an article about these hardware wallets that used a deterministic pseudo-random generator instead of the hardware generator. You don’t need access to the hardware, right? Because the resulting keys are crackable because they didn’t use a good random seed. Is that the basic takeaway?

Chase Snyder (49:22.645): Yeah, the ColdCard.

Vlad Babkin (49:27.450): Ho ho ho. That’s a fun one.

Vlad Babkin (49:34.874): Nope. Nope. Nope.

Vlad Babkin (49:39.719): The whole point is, if you use a bad random generator, you can just exhaust the seed space. For example — the Mersenne Twister. If you observe 453 values from it, you can reconstruct the seed. Something like that.

Paul Asadoorian (49:57.003): The examples they published — Claude told me this is one of the oldest failures in cryptography, which I agree with. Debian OpenSSL in 2008, Netscape 1995 — if you remember that far back, I do. There have been a lot of vulnerabilities based on randomness not being truly random.

Vlad Babkin (50:09.612): Mm-hmm. Pseudo-random.

Vlad Babkin (50:18.596): Yep, and there’s also PHP random in this category. The whole point is, if your seed space is small enough, you can just start cracking. At some point you’ll exhaust all of the possible seeds, and you will exhaust all of the possible keys. The only remaining question is how do you scan the blockchain fast enough before anybody else finds it — before people understand that there is a problem.

Paul Asadoorian (50:39.892): — before you’re issuing new keys. Yep. You should have to issue new keys. Yeah.

Paul Asadoorian (50:47.008): Mm-hmm.

Vlad Babkin (50:48.280): This vulnerability is like the oldest one in the book. I have been exploiting them in CTFs.

Paul Asadoorian (50:52.128): Attackers have already drained — it says attackers have drained roughly seven thousand three hundred addresses, with Galaxy Research confirming one thousand five hundred and ninety-six bitcoins — probably just north of a hundred million dollars extracted.

Chase Snyder (51:10.987): The original reporting was like $30 million got stolen within the first ten minutes. Something I thought was pretty interesting was that the company that makes these wallets ended up destroying a bunch of the inventory they hadn’t sold yet, because they knew the buyer would have to install the firmware update. I think that was a good move on their part.

Vlad Babkin (51:11.078): Yeah, and then —

Paul Asadoorian (51:16.534): Mm-hmm.

Paul Asadoorian (51:26.665): Interesting.

Vlad Babkin (51:31.014): Mm-hmm.

Paul Asadoorian (51:32.213): Yep.

Chase Snyder (51:39.541): — destroy the hardware because they don’t know they —

Paul Asadoorian (51:41.120): Couldn’t they just flash new firmware on them, though?

Vlad Babkin (51:43.878): They can, but who is going to do this? Because you have to unpack it and then pack it again. Yuck.

Paul Asadoorian (51:49.410): You’re right, Vlad. It would cost them more money to reflash everything than to destroy it and build new ones with fresh firmware.

Chase Snyder (51:52.543): Yeah. Mm-hmm.

Vlad Babkin (51:56.359): And just build new ones. Yep. And going even further — the funniest bug possible here is that if they sold enough of them, somebody probably got a collision. Imagine: you buy a wallet, initialize it, and suddenly there’s money on it immediately. That could be the funniest bug ever. I don’t know how big their seed space was, but considering somebody actually drained so many so quickly after the vulnerability was published, it’s probably not very large.

Paul Asadoorian (52:11.270): Right. I hadn’t considered that.

Paul Asadoorian (52:18.495): Yeah.

Paul Asadoorian (52:25.013): Right.

Chase Snyder (52:25.655): Go ahead, Vlad.

Vlad Babkin (52:26.105): Another funny part is that this bug is so old that I was exploiting it in my past life ten years ago when I was a pen tester. Again, can’t give specifics, but this bug is present not only in crypto wallets. Use cryptographically secure random by default in your products and they’ll be that much safer.

Paul Asadoorian (52:36.266): Mm-hmm. Yep.

Paul Asadoorian (52:43.776): Yeah, a hundred percent.

Chase Snyder (52:52.045): And the fact that this was a product targeted at very security-minded people — not necessarily cybersecurity people, but the point of the hardware custodial wallet is that it protects your Bitcoin because you’re not relying on some company to protect it for you. You have this hardware device that protects it. And the very product that was supposed to address this risk —

Vlad Babkin (52:58.214): Mm-hmm.

Vlad Babkin (53:15.866): Yup. Yup.

Chase Snyder (53:21.025): — that people don’t want to be keeping their Bitcoin in Coinbase or whatever. And the hardware they built — hardware’s hard, okay? It’s historically, notoriously hard to do a good job on a hardware startup.

Vlad Babkin (53:29.336): It’s not even about hardware. Random is hard. Making a good random number generator in a computer is an incredibly hard problem. If you want your wallet to be secure, use an offline machine to generate your wallet, then put it into hardware — this way you sidestep any potential generator problems with your hardware wallet. But even then, the whole point of this exercise is that cryptographically secure random should be the default. Don’t use non-cryptographically-secure random. People have used it multiple times and paid for it, starting as deep as the TCP protocol. People decided that some not-very-random values were actually cryptographically secure, and a lot of TCP problems came from that.

Paul Asadoorian (54:14.571): Yeah. I’m familiar with this problem. I used to work for a lottery company — cybersecurity for a lottery company. At one time when I worked there, roughly eighty percent of the world’s lotteries were powered by this company. And obviously having a truly random number for the winning lottery draw is super, super important.

Vlad Babkin (54:23.002): Ha ha ha!

Chase Snyder (54:24.681): Okay, I want to hear more. I’m interested.

Paul Asadoorian (54:47.274): How that random number was derived was not a secret shared with the five thousand or so people who worked there. It was a very small subset of people who kept it a very closely guarded secret. And there were a lot of creative and innovative discussions about how — to Vlad’s point — from a computer, how do we get truly random numbers? Even back then — this is going back twenty-five or twenty-six years ago — we talked about the lava lamp, and how that research had been done or at least theorized: if you pointed a camera at a wall of lava lamps, the randomness generated from them is very good. Interestingly, my other podcast years ago was sponsored by a company that made such hardware to generate randomness for cryptographic operations. That was their whole business. They liked the lava lamp model — “That actually produces really good randomness.” And then fast forward a few years ago — you can probably still find it today — Cloudflare actually built a wall of lava lamps to generate randomness. But I had heard of that concept probably twenty-six years ago.

Chase Snyder (56:06.443): Yeah, they famously have the big wall of lava lamps in a public lobby where anybody can see it. And there’s a funny post that was like, “But what if you just go point a hidden camera at it and then you get the randomness?” Well, they probably have other factors in place.

Paul Asadoorian (56:11.582): Yeah. I don’t know if they use it in practice.

Paul Asadoorian (56:19.338): I’m not sure if they’re using it for anything in production or if it’s just an experiment. I don’t remember the details.

Chase Snyder (56:24.989): It’s just cool.

Vlad Babkin (56:26.714): Yeah. To be honest, my conservative assumption is that roughly fifty percent of the bytes you get from a standard PC source are actually random, and everything else is predictable. So generate 256-bit random values, and you get 128 bits of actual randomness. This is enough to generate cryptographic keys for a lot of protocols. That’s how I go about it.

Paul Asadoorian (56:41.237): Yeah, yeah.

Paul Asadoorian (56:50.538): Yep. If you ever used Core Impact’s product back in the day — a pen testing tool with lots of exploits and its own implant — it would encrypt each of your sessions. Everything that happened within your pen testing engagement was encrypted. When you installed the software, it actually made you move your mouse around enough times to generate enough randomness so that it could create unique keys. That’s how that product specifically got around the randomness problem. So again, this is a thing we’ve dealt with since the inception of computers and encryption together.

Vlad Babkin (57:24.838): Mm.

Vlad Babkin (57:33.936): Yup. Yup.

Chase Snyder (57:40.684): Which is another thing about it — this is an old problem that somehow keeps cropping up and causing, in this case, a hundred million dollars and counting of loss. We talk a lot about recency bias in addressing security issues, where folks will prioritize new vulnerabilities. We brought this up in our inaugural InfraTrust post — prioritizing on recency is not —

Paul Asadoorian (57:47.840): Right.

Paul Asadoorian (57:51.316): Yeah, yeah.

Chase Snyder (58:08.511): — necessarily the right way to mitigate the most risk. Many old vulnerabilities with lower risk scores — the actual risk represented by them has changed, possibly gone up, because of the disclosure of subsequent vulnerabilities that give you auth bypass or whatever. Just because something is old, like the IPMI thing or the randomness thing, doesn’t mean it doesn’t represent a growing level of risk against your enterprise or your Bitcoin holdings.

Paul Asadoorian (58:40.339): Mm-hmm.

Paul Asadoorian (58:44.127): One last story we had was an update on speculative execution. MIT researchers showed that unprivileged local access can time a hardware interrupt to land in the window between the CPU sanitizing its branch predictor and the kernel using it — essentially repoisoning it. So it’s very much a timing attack: time of neutralization, time of use. On an AMD Zen 2 processor with a Linux 6.14 kernel and every default Spectre v2 mitigation enabled, they were able to leak kernel memory at 5.47 bytes per second and pulled the /etc/shadow file in five of ten attempts. So they proved this is practical. It takes some iteration against a timing-based attack.

One of the interesting parts is that AMD actually fixed this, but very quietly — no CVE was associated with this vulnerability. AMD’s bulletin lists the affected processors but doesn’t really give you much else to go on to make an informed decision: “Should I patch this? Is this something I need to worry about?” I think this is where security research can really shine a spotlight — “Hey, in case you missed this, this is actually exploitable with modern protections to leak sensitive data.” That’s a feather in the cap of security research — really allowing us to understand the impact and severity that may not have been communicated clearly when the disclosure happened.

Vlad Babkin (01:00:17.296): Mm-hmm.

Vlad Babkin (01:00:32.102): In this case, researchers sometimes under-evaluate their own research. For example, especially when you find twenty-five vulnerabilities — one of the NVIDIA vulnerabilities reported in an AMI BMC was actually remote code execution in some cases. They reported, I believe, a file read. But ultimately, if you dug deep enough into this, it was full remote code execution. I don’t remember if I raised a flag on this one, but because they already had other code execution vulnerabilities, I don’t think they actually focused on this. Very often, extra research shows that a vulnerability is actually much more exploitable than originally suspected.

Paul Asadoorian (01:00:39.251): Yeah. Yes.

Paul Asadoorian (01:00:52.508): Mm-hmm.

Paul Asadoorian (01:01:14.122): Mm-hmm.

Paul Asadoorian (01:01:24.213): Mm-hmm.

Vlad Babkin (01:01:28.249): So.

Paul Asadoorian (01:01:28.287): Craziness. Well, that should round out the show. Those were some good articles and great discussions. Thank you, Chase and Vlad. Thanks everyone for listening and watching this edition of Below the Surface. We’ll see everyone next time.

Back to all Podcasts