PODCASTS

BTS #79 - InfraTrust - Understanding Infrastructure Vulnerabilities & Risk

In this episode of Below the Surface, Paul Asadoorian is joined by Chase Snyder and Vlad Babkin for a conversation about InfraTrust, InfraTrust Pulse, and the hard problem of making infrastructure vulnerability data useful for defenders.

The first half of the episode focuses on why infrastructure advisories are harder to track than ordinary CVE feeds suggest. Paul, Chase, and Vlad explain why vendor advisories, OEM firmware updates, exploitability context, and CISA KEV activity often tell a more actionable story than severity scores alone. The discussion also introduces InfraTrust as a free, searchable resource for security teams trying to understand what infrastructure vendors are actually patching.

The second half turns to a long-standing BMC and IPMI issue that has resurfaced because exposed management interfaces remain visible on the public internet. Vlad explains why some of these problems are not simply patchable software bugs, but design and exposure problems. The episode closes with a broader warning: as AI-assisted vulnerability discovery improves, attackers may find it easier to identify and exploit the infrastructure blind spots defenders still struggle to monitor.

Key Topics Covered

  • InfraTrust and InfraTrust Pulse: Paul introduces InfraTrust as a project designed to collect, organize, and expose infrastructure security advisories that are otherwise scattered across vendor sites, public databases, and news coverage.
  • Why advisories matter more than CVEs alone: The group explains that a CVE describes a vulnerability, while a vendor advisory usually tells defenders whether a patch exists, which products are affected, and how the issue appears in a real OEM environment.
  • The supply chain delay in firmware patching: Paul describes how chipmaker fixes from Intel, AMD, Insyde, AMI, and others must move downstream into OEM-specific firmware before end users can act on them.
  • A monthly infrastructure patch snapshot: InfraTrust Pulse is framed as a 30-day view of vendor advisories, known exploitation, and infrastructure risk, rather than a simple list of recently issued CVEs.
  • Infrastructure data is difficult to collect: Vlad and Paul discuss inconsistent vendor formats, missing CPE data, RSS feed gaps, advisories without CVEs, and the difficulty of crawling vendor security pages at scale.
  • Risk scoring can obscure real urgency: Chase argues that internet-facing, unauthenticated vulnerabilities may deserve priority even when their CVSS scores are lower than local privilege escalation issues.
  • Patch priority should account for exposure: The July InfraTrust Pulse discussion highlights the importance of exploitability, reachability, authentication requirements, and whether a device sits on the public internet.
  • FortiBleed as an infrastructure foothold example: Paul uses FortiBleed to show how attackers can use a firewall or VPN device as a foothold, credential collection point, and tunnel into the internal network without relying on traditional malware.
  • Network devices as blind spots: Chase connects InfraTrust to Eclypsium’s broader focus on network devices, where defenders often lack visibility into firmware, integrated operating systems, and attacker persistence below the OS.
  • Recency bias in vulnerability management: Chase notes that organizations often focus on what is new or in the news, even though older vulnerabilities may become more dangerous when new bypasses, exploit chains, or KEV listings appear.
  • AI and vulnerability discovery pressure: Vlad and Paul discuss the likelihood that AI-assisted vulnerability research will increase the volume of vulnerabilities, patches, exploit development, and prioritization work facing defenders.
  • The BMC/IPMI exposure problem: The second major topic is a BMC issue involving IPMI on UDP port 623, where the protocol itself can expose password-derived challenge-response material when queried.
  • BMCs were not designed for public exposure: Vlad stresses that BMCs, IPMI, Redfish implementations, and router management interfaces should not be exposed directly to the internet; VPN access and isolated management networks are the safer pattern.
  • BMC compromise can be highly destructive: Vlad explains that a compromised BMC can enable shutdown loops, lockout, firmware-level persistence, and recovery scenarios that may require manually reflashing SPI chips across many servers.
  • Visibility below the operating system: The episode returns to a core Eclypsium theme: defenders need ways to monitor firmware, BMCs, network appliances, and management interfaces that traditional endpoint tools often do not see.

Timestamps

  • 00:00 – Pre-show setup and LinkedIn livestream troubleshooting
  • 02:20 – Episode introduction: InfraTrust, InfraTrust Pulse, and a new-but-old BMC vulnerability
  • 02:35 – Paul welcomes Chase Snyder and Vlad Babkin
  • 02:58 – Eclypsium resources, eclypsium.com/go, and the setup for InfraTrust
  • 04:36 – Vlad explains the need for a centralized view of infrastructure advisories
  • 06:39 – Paul compares InfraTrust Pulse to Patch Tuesday and explains why chipmaker advisories are not always actionable
  • 08:50 – Why OEM firmware updates often lag behind original vulnerability disclosure
  • 10:23 – Chase distinguishes InfraTrust from InfraTrust Pulse
  • 11:00 – Why security teams need advisory-level infrastructure data
  • 13:19 – The technical challenge of collecting data from inconsistent vendor sources
  • 15:18 – Vlad explains why vendor scoring can differ from generic CVE scoring
  • 15:45 – Cisco Firepower Management Console example: medium CVSS, high advisory context, and CISA KEV
  • 17:45 – Why InfraTrust tracks advisories rather than only CVEs
  • 19:11 – Vlad discusses the early state of the InfraTrust website and future possibilities
  • 19:22 – Paul describes using Claude for his internal proof-of-concept tooling
  • 20:46 – Chase connects InfraTrust to Eclypsium’s work on hard-to-see infrastructure data
  • 22:13 – Patching speed, exploitation windows, and the Verizon DBIR discussion
  • 24:24 – The role of InfraTrust Pulse in helping teams sort through monthly infrastructure risk
  • 25:00 – Why internet-facing, unauthenticated vulnerabilities may outrank higher-scored local bugs
  • 26:05 – CopyFail, FortiBleed, authentication bypass, and footholds on network devices
  • 28:31 – Living off the land on firewalls and infrastructure appliances
  • 29:35 – KEV additions outside the 30-day disclosure window
  • 30:48 – Recency bias and the need to reassess older vulnerabilities as new exploit paths emerge
  • 32:48 – AI-driven vulnerability discovery and the future growth of InfraTrust data
  • 33:33 – Local models, frontier models, and AI-assisted security research
  • 35:01 – Vlad’s concern that AI companies misunderstand the offensive/defensive link in security
  • 37:09 – Compute economics for attackers versus defenders
  • 38:41 – InfraTrust growth as vulnerability discovery accelerates
  • 39:34 – Transition to the BMC/IPMI vulnerability discussion
  • 40:00 – UDP port 623, IPMI challenge-response behavior, and why the issue is protocol-level
  • 41:31 – Vlad’s recommendation: expose only VPN, not BMCs or internal management interfaces
  • 43:10 – IPMI as UDP and why interception risk matters
  • 43:42 – Redfish as a successor to IPMI and the risks of implementation-specific flaws
  • 45:26 – Why BMCs still end up exposed to the public internet
  • 46:18 – The level of control an attacker gains through a compromised BMC
  • 46:37 – Vlad describes server shutdown and recovery risks involving BMC firmware and SPI flash
  • 48:00 – AMI MegaRAC, patch adoption, and the uncertainty around unpatched BMC deployments
  • 48:51 – More than 36,000 BMCs observed exposed on IPMI and UDP port 623
  • 49:49 – VPN alternatives, Ubiquiti, MikroTik, and safer remote management patterns
  • 51:07 – Router management interfaces and other exposed management protocols
  • 52:05 – AI, exposed infrastructure, and why defenders should take the issue more seriously
  • 52:26 – BMC ransomware notes and possible attacker playbooks
  • 53:40 – Vlad’s concern about stealthier BMC abuse, proxying, and data theft
  • 55:35 – Visibility gaps and the difficulty of detecting BMC compromise
  • 56:08 – BMCs as embedded Linux computers inside servers
  • 56:33 – Closing remarks

Core Episode References

Transcript

Paul Asadoorian (02:20.023): This week we’ll be talking about InfraTrust and the InfraTrust Pulse, and a new but old BMC vulnerability. Stay tuned — Below the Surface, coming up next.

Paul Asadoorian (02:35.009): Welcome to Below the Surface. This is episode number seventy-nine, being recorded on July thirtieth, twenty twenty-six, the week before what we lovingly call Hacker Summer Camp. I’m Paul Asadoorian, joined by Mr. Chase Snyder. Chase, welcome.

Chase Snyder (02:50.240): Hey, Paul.

Paul Asadoorian (02:52.361): And Mr. Vlad Babkin. Vlad, welcome.

Vlad Babkin (02:56.459): Welcome.

Paul Asadoorian (02:58.051): Do we have a new ad yet? I know we’ve changed things. I think we may have to go with the old one. So — 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 that at eclypsium.com/go.

You can also check out infra-trust.org, which we’re going to dive into on this episode. I should have some new and exciting things for our listeners to check out on the next episode. But on this episode we’re going to focus on a new project that we worked on for quite some time. I’ve talked about it on a couple of different podcasts, so I want to get Chase and Vlad’s perspective and view on InfraTrust Pulse.

Vlad, you got pulled in to do a bunch of technical work, which is hilarious in its own right. This idea morphed and became a full website that allows you to filter, search, sort, and find vendor advisories and vulnerabilities in OEM gear and network devices, as well as chipmakers.

Vlad Babkin (04:36.461): Before that, all of the advisories were scattered around. We have NVD, right? It doesn’t provide an easy filter to see infrastructure vulnerabilities. You cannot quickly find all of the device vulnerabilities. Maybe you can find them for a specific vendor, but you don’t get any kind of global view. And a second source would be news websites — as soon as something happens, everybody is writing that here is yet another vulnerability in vendor A. But there is…

Paul Asadoorian (05:20.065): Vlad, sorry — can you just move your microphone a little closer to your mouth? I think it was rubbing on your shirt a little bit.

Vlad Babkin (05:30.103): This should be better. It’s a directional microphone which also has Omni mode — it becomes a little bit quieter when it is directional. Anyway, the point of this website is to have visibility into all of the advisories that are happening right now, and also historically. InfraTrust Pulse is pretty much highlighting what happened in the past month.

Paul Asadoorian (05:31.661): Yes, thank you.

Vlad Babkin (05:57.646): So it’s a short summary of everything. The whole point is that we want to keep this database updated and be a singular source of truth, so that you can come in and find all the relevant advisories and exploitability data for specific devices — network infrastructure, anything else you can call infrastructure. That’s how it morphed into the website we have.

I don’t know what plans we have for future evolution right now, but potentially we’ll have statistics charts and maybe extra data that doesn’t exist there yet.

Paul Asadoorian (06:39.747): That was the exciting part for me. We’ve got Microsoft Patch Tuesday, and a lot of vendors jump on that bandwagon and try to release patches the second Tuesday of every month. There were also publicly published efforts that did a Chipmaker Patch Tuesday — advisories from Intel, AMD, Qualcomm, and Nvidia as the major ones. Not that that’s bad, but the problem is those fixes usually have to be consumed by OEMs who actually make the end-user product using those chips. So it’s great to know about vulnerabilities from Intel, AMD, and others, but it’s not actionable.

This project had multiple different names and takes. It was originally just supposed to be a report — we were supposed to go find the data and issue this report, what we originally called a “hardware Patch Tuesday.” We realized quickly that querying public CVE sources doesn’t give you all the information you need. We wanted a snapshot of not vulnerabilities, but vendor advisories — of patches. That’s the big difference between a CVE and a vendor advisory. A CVE is a vulnerability; there could be multiple vendors with multiple products that issue patches for a single CVE. I wrote an internal tool to help me query those sources, and I realized I was missing data because a vendor can issue an advisory without having a CVE associated with it. If you’re just querying public CVE data, you’re going to miss that. There was also the time delta — when a CVE is issued, there can be more than thirty days before a patch appears. We’re working on thirty-day snapshots.

Vlad Babkin (08:50.231): Yep.

Paul Asadoorian (09:02.305): If I just snapshot public CVE data in the past thirty days, I’m not getting all the vendor advisories that have been issued fixing vulnerabilities older than thirty days. Lenovo’s a great example — not picking on them, but they’re taking downstream fixes from Intel, AMD, Insyde, AMI, and the like, and it takes time…

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

Vlad Babkin (09:13.741): It trickles from the bottom.

Paul Asadoorian (09:30.115): …to test those, to incorporate those into their custom firmware for all of their affected devices. It could be sixty, ninety days or more before Lenovo issues a patch — even though the vulnerability was published sixty or ninety days ago or more. That’s just the way it works; it’s the supply chain challenge. What I love about InfraTrust is that it relied heavily on our data team, which has been…

Vlad Babkin (09:43.254): Yeah.

Paul Asadoorian (09:58.999): …since the inception of the company. I call them hoarders — but they’re hoarding vulnerability information, firmware images, all the things we need to enrich our product. This is a snapshot of the data we collect that’s super useful for teams, because it gives you the actionable results. That was the big deal for me.

Chase Snyder (10:23.220): Something that stood out to me in the process of not only building out and clarifying the idea, but in actually building the assets — so we have two things, right? We have InfraTrust, which is a website you can go look at that is an ongoing, updated knowledge base of all these advisories.

Paul Asadoorian (10:45.207): Right. Which is free, by the way — no registration, no cost. You can go to the website today and use it.

Chase Snyder (10:51.254): www.infra-trust.org. And then there’s InfraTrust Pulse, which is our 30-day snapshot report — more of a Patch Tuesday-style report. But as we were building this out, deciding what sort of data to include, deciding whether to use aggregate risk scores or build our own, whether to include CVEs versus advisories — which would be an order of magnitude different numbers — the more we worked on it, the more it felt like there should be something like this already. This is such critical information that security teams, or teams responsible for patching IT infrastructure, really need. Patching is getting harder and harder as more and more patches get introduced. After Mythos was announced and the rapid progress of AI, we talked about Patch Tuesday — the most recent one had five hundred and seventy-plus patches in it, which was way more than any previous Patch Tuesday. Microsoft attributes that to their internal AI tool, which is called Dash — if you know, you know.

Vlad Babkin (12:14.337): They know what happens.

Chase Snyder (12:17.424): Ball’s in their court over there. But yeah — it seemed like there should be something like this already that pulls it all together, because every organization has different vendors in their environment. There’s no real one-vendor shop where literally every piece of gear is from Cisco or Palo Alto or Lenovo or whatever. They all have different stuff, they need these different advisories, and someone inside is having to manually scrape that stuff together. That must have been a terrible, terrible job.

I have high hopes that the people whose job it was to manually trudge through different websites, different formats, and URLs that get popped into and out of existence when vendors release their advisories — I hope they find InfraTrust and think, “This is what I always wanted.” But it turned out to be remarkably difficult to build. It’s hard to collect and organize that data. And Eclypsium was really well positioned to do it.

Paul Asadoorian (13:19.724): Yeah, because we already have a team established whose mission is to do that. There are several technical challenges that have to be addressed to collect that data. It turns out vendors don’t really like it when you crawl and scrape their websites. If you’ve ever pasted a URL into an LLM and said, “Hey, go fetch this and do some analysis on it” — there’s maybe a thirty to forty percent chance the LLM comes back and says it can’t get that. So unless you’ve built a harness for your LLM work that does it for you, it’s going to tell you no. If you want to collect this data at scale, you run into…

Vlad Babkin (14:03.821): Mm-hmm.

Paul Asadoorian (14:16.992): …all kinds of challenges. Some companies have RSS feeds, some do not. Every company formats their data differently, so even if you work for an enterprise with six different vendors — Dell, Lenovo, Cisco, Palo Alto, for example — getting all of the data about what advisories they’re releasing requires you to go to individual websites…

Chase Snyder (14:18.422): It’s…

Paul Asadoorian (14:46.090): …and look at the advisories being published. There’s no great solution. I did this years ago — I tried to subscribe to all the RSS feeds so I’d know about all the new stuff coming out for the products we support. I was maybe forty to fifty percent successful putting things into my RSS reader, into Feedly, and getting halfway decent telemetry. But a lot of stuff is missing. And that’s the power of our data team.

Vlad Babkin (15:18.611): And it gets even better. Vendor advisories often provide different scores than what’s in the CVE. Moreover, when this is a generic CVE with a score of 10.0 — scary — but the way it appears in a specific vendor’s environment, the scoring can be different for that vendor. For example, let’s imagine there’s an OpenSSL vulnerability…

Paul Asadoorian (15:40.833): Yes.

Paul Asadoorian (15:45.805): Actually, we don’t have to imagine. Cisco did this yesterday. They published an advisory for the Firepower Management Console. They stated that there is a static user credential — which I’m pretty sure means a default username and password, although they use the term “static user credential.” The CVSS score they calculated was 5.3, which would be a medium. However, if you look in the upper left-hand corner of that advisory, it’s listed as “High.” And when I woke up this morning and checked, it had been added to the CISA KEV.

Vlad Babkin (16:31.181): Yeah. There is no easy way to find all of this data. Sometimes it’s less, sometimes it’s more. You have to pretty much scavenge for it. Moreover, if you want to see which product a vulnerability is in, that’s also not easy to collect. If you go to just the NVD, there are usually wild inconsistencies in where the vulnerability is listed.

Paul Asadoorian (16:58.188): Yes.

Vlad Babkin (16:58.751): It’s not easy data to collect. For some vendors it’s easy because they’re good citizens and provide really good data. Others, not so much. And sometimes the vendor advisory contains a lot more data.

Paul Asadoorian (17:12.204): Yeah. I noticed that in the tool I wrote. I would look at CNAs publishing CVEs — some would fill out CPE information, some would not. I was scraping all the CPE information, putting it into a web interface, and I was like, “Wow, some really big vendors just don’t fill out the CPE information.” Then you have to go to their advisory page and…

Chase Snyder (17:12.512): Yeah.

Paul Asadoorian (17:39.402): …it’s a lot of work to figure out which products are affected.

Vlad Babkin (17:45.166): Yeah. Sometimes there’s an advisory with fifteen different CVEs and one patch for all of them. It’s super hard to track — okay, you just patched one CVE, now you have to check fourteen others and track down which ones relate to this one advisory. This is why we decided to track the website by advisories and not by CVEs. That was a deliberate decision; there’s a lot of thought behind it.

Paul Asadoorian (17:51.137): Right.

Paul Asadoorian (18:09.121): Yeah, that’s a great point, Vlad. What we were running into is — you can look up all the CVEs Cisco published in the past thirty days and get a big list. You go to the advisory linked in the NVD record, and that one advisory says, “Yeah, we have a patch and it fixes these ten vulnerabilities.” That’s good information to have, but you had to do a query and jump through a lot of hoops just to get it. One of the things we did early on was start grouping those — “This advisory is critical from Cisco because it fixes these ten CVEs, one of which is on the KEV and has a really high rating.” That’s the piece this ties together.

Chase Snyder (18:20.042): Yeah.

Paul Asadoorian (18:37.099): One of the things we did very early on was start grouping those, and saying, “This patch or advisory is critical from Cisco because it fixes these ten CVEs.” If you look at the artifact, one of those CVEs is on the KEV and has a really high rating, and it relates to this advisory, which relates to these patches. And that’s the piece this ties together.

Vlad Babkin (19:11.329): Right now the website is relatively simple — it doesn’t quite have everything that belongs there yet, but it’s very young. Go give it a shot, leave us some feedback.

Paul Asadoorian (19:22.603): Vlad, you did an amazing job coding this. I had my proof of concept — and yes, we used Claude. I used Claude to create my tool, but my tool I wrote for myself. I wasn’t writing a CVE analyzer that was going to be incorporated into the product or be publicly facing. I needed it for my work — to find stuff to cover for this show, to find stuff to cover on my other show, to feed our threat detection team.

Vlad Babkin (19:27.063): You mean Claude?

Paul Asadoorian (19:52.415): I need the telemetry on what vulnerabilities are being disclosed and made public, and artifacts about them — is it publicly exploited? Which products does it affect? I used Claude to create that, and it’s a good proof of concept. But when it came time — and I think it was Yuri who drove this direction — rather than just a report, let’s have a website that people can interact with and query this data that they would have to work really hard to get on their own. Vlad, you were tasked with creating the website, which uses some amazing technology on the back end and is very robust. I know you’re very critical of your own work, but what you put together and developed is pretty awesome.

Chase Snyder (20:46.464): There’s sort of an analogy or a similarity here. Eclypsium can’t stop going after data that’s hard to get at. At the product level, what we’re doing is providing visibility into the underlying operating system of these network devices and infrastructure things that vendors make difficult to get at — at least if you are a buyer or customer.

I’m not totally sure why they do that. Is it intellectual property? They lock down the OS, they have their custom Linux version, intellectual property under the hood — you have to buy the support. Or maybe they don’t want you to shoot yourself in the foot — if you’re buying all your firewalls or your network routing and switching from a vendor, they don’t want you to cause an incident, so they say you have to buy a support contract and they’re not going to let you under the hood.

Whatever the reason they make it so hard — Eclypsium keeps going after it. There’s a black box, there’s a blind spot inside these boxes that we can help you monitor. And now in this exact case with InfraTrust, this is public information. It’s out there on the internet. The companies are publishing it on the internet. But for some reason it’s remarkably difficult to…

Vlad Babkin (21:59.682): Yep. Mm-hmm.

Chase Snyder (22:13.418): …gather and aggregate and present in the way that would be most useful to the end user — the person who has to patch it. We talk a lot about the Verizon Data Breach Investigations Report and its statistics on the speed and efficacy of vulnerability management and patching programs. The most recent 2026 report said that the speed and efficacy of patching peaked in 2024. They kept getting faster and better — more critical vulnerabilities were getting patched sooner and sooner after disclosure — up until 2024. Then the timeline started extending. Fewer and fewer critical vulnerabilities were getting patched at all, and it was taking longer and longer. The time window from disclosure to patch kept expanding. More vulnerabilities started getting discovered, and more and more of them were being disclosed…

Vlad Babkin (23:12.215): Yeah.

Chase Snyder (23:12.550): …after already being known to be exploited. The time window during which a vulnerability was being actively exploited was expanding. There was often exploitation before disclosure, then disclosure happens, then an extended period of exploitation before a patch gets issued by the vendor — and then well over thirty days median before the patch actually gets deployed inside major organizations that have a whole team whose job this is. The overall time window for exploitation of known vulnerabilities has gone way up. Yet this data about the patches, the risk scores, the content of these advisories was so hard to aggregate and present in a useful way to help defenders compress that exploitation timeline and take back the…

Vlad Babkin (23:41.037): Yep.

Chase Snyder (24:09.706): …advantage. There are a lot of factors making things hard for defenders. I’m glad and proud to have participated in one small step to make it a little bit easier and faster — just making this information available and searchable.

Paul Asadoorian (24:24.278): Yeah. And that’s also the point of the Pulse — to help people sort through a time range. We’re going to do that monthly.

Chase Snyder (24:33.908): Yeah. And a little interpretation. We’ve got experts in-house — yourself, Paul, Vlad, the whole team that works on gathering this data — who know how to interpret it and say, “These are the ones that are important to focus on now.” A big part of the theme of the first InfraTrust Pulse post was that regardless of the severity score…

Vlad Babkin (24:46.391): Yep.

Chase Snyder (25:00.850): …if something is reachable from the public internet and doesn’t require authentication, even if it hypothetically has a lower risk score, it’s more likely to affect you. Something that is 9.8 CVSS — super high critical score — but isn’t reachable and isn’t exploitable without prior authentication requires attackers to do a lot of homework first. But if it’s pre-auth and exposed to the internet, those are the ones to patch first. But that’s not what you would do if you were just patching in order of severity score.

Paul Asadoorian (25:39.178): Or even the KEV too. This actually contradicts some of my advice I’ve given on podcasts, where I told people you really need to pay attention to local privilege escalation, because they sometimes carry a much lower score — usually in the medium category because they require someone to already be on the box. I’m not saying ignore those, but…

Chase Snyder (25:48.182): Well, we all update.

Paul Asadoorian (26:05.708): …what this first report surfaces, as you’re saying, Chase, is that you may have classes of medium CVSS score vulnerabilities that require more attention because of the access vector — authentication bypass that doesn’t require authentication. That surfaced in the first July InfraTrust Pulse. There was the CopyFail vulnerability, which is a local privilege escalation that’s on the KEV. The knee-jerk reaction is, “Oh my god, it’s on the KEV — highest priority.” But if you look at it in context, there were other things disclosing authentication bypass vulnerabilities reachable from the network. They give the attacker a foothold. In some of these cases, because there’s no remote code execution piece, it may get a lower score.

But as we saw with FortiBleed — if you’ve got a Fortinet device exposed to the internet and there’s an authentication bypass vulnerability, sure, that might not get you a shell. It might not get you a root bash prompt on the underlying Linux. However, it gives you access to the Fortinet device. And as we’ve observed attacker behavior even before FortiBleed, attackers would use the Fortinet device and essentially live off the land on it. I’m using Fortinet as an example — there are multiple vendors where we’ve observed this behavior. As an attacker who now has full control over a network firewall with VPN capabilities, what can I do? I can build tunnels into the internal network. I can have a Windows machine and join the domain because I’m on the network. In the FortiBleed example, I’ve got access to a Fortinet device, so I can run sniffer commands, collect credentials, and crack them offline. None of that activity leaves behind what we would traditionally hunt for as malware indicators. What we need to hunt for are configuration changes and behaviors of the actual device — not just looking on the file system or inside memory for malware.

Paul Asadoorian (28:31.798): Because in a lot of those cases they’re not even deploying malware — they’re just using the device to live off the land. Those are the vulnerabilities you’ve got to pay attention to, above and beyond some of the local privilege escalation that is being exploited in the wild. While still important, you’ve got to close the front door before you clean up the house.

Paul Asadoorian (28:56.950): I thought that was super interesting. There were a couple of examples of that in the report.

Chase Snyder (29:04.128): Yeah, I’m really excited. That was just the first issue, the first pass at it, and I think it’s already extremely valuable inherently — and also uncovering more gaps, like the initial gap where it’s like, “It seems like there should already be something like this. Why isn’t there?” The more we work toward building it, the more obvious it is that there’s more value in adding more data. We get a signal about what kind of data is valuable to include and what sort of interpretation is going to be most useful. This is just the beginning.

Paul Asadoorian (29:35.978): Yeah, and the other signal is what’s being added to the CISA KEV that is outside the thirty-day window from a vulnerability disclosure perspective. That was something we noticed very late in the process of developing the first report — “Wait a minute, they just added a FortiSandbox vulnerability from five months ago to the CISA KEV, so now it’s being actively exploited.” We thought…

Chase Snyder (29:46.763): Yeah.

Paul Asadoorian (30:05.548): …we should include in the report known exploited vulnerabilities that were added to the KEV within the thirty-day window, even if the vulnerabilities themselves were disclosed before that window. FortiSandbox was one of those. We don’t always observe exploitation the moment a vulnerability comes out. Sometimes it takes time. It doesn’t mean attackers aren’t exploiting it immediately — we just weren’t able to observe it within that time window.

Chase Snyder (30:39.370): Yeah.

Chase Snyder (30:48.168): Yeah. There are a couple of biases that affect vulnerability management — and vulnerability tools — that we’re kind of having to change our assumptions about. Recency bias is a huge one. Obviously if something is in the news, there’s going to be organizational pressure. People are reading about it, getting asked about it. If you’re a company, your customers are asking, “What are you doing about the FortiSandbox thing?” If you’re a vulnerability management individual contributor, your boss is asking, “Hey, there’s this one in the news. What do we say if someone asks?” Depending on the scale of the news, your execs or board might ask, “What are we doing about it?” That happens at every scale — your executives are asking, “What are we doing about Mythos?” We have to have an answer. But the recency bias, especially in the age of AI vulnerability discovery, which is just going to the moon right now…

Vlad Babkin (31:39.553): Yeah.

Chase Snyder (31:46.643): …means older vulnerabilities and mid-risk vulnerabilities that may not have been patched are getting discovered. Vulnerabilities with medium risk scores that were assigned lower scores because they required some sort of authentication — well, the auth bypass is coming out now. Do you go back and say, “This one from several years ago is now much higher risk because the auth bypass that gives you access to it has been disclosed?” Nobody’s really doing that work to retroactively adjust risk scores based on new information, as far as I know. The information you’d need to really act in a data-driven manner as someone in charge of patching at an enterprise is really hard to get, if it’s available at all. And that’s only going to get worse with the continued escalation of exploit development and vulnerability discovery driven by AI.

Paul Asadoorian (32:48.949): Yeah, and that’s really what’s going to drive a lot of the future InfraTrust Pulse data and reports — the onslaught of vulnerabilities and patching we’re going to see based on that. Go ahead, Vlad.

Vlad Babkin (33:01.197): Yeah, and it’s only gotten worse. It’s only a matter of time until actual attackers also get missus-level models. Consider that Kimi K3 already exists. I didn’t have a chance to test this model by hand, but the claim is it’s pretty close to Fable. Open source models will not stop and will continue to grow. And there are other well-funded attackers who would be willing to train something like this.

Paul Asadoorian (33:29.259): Yeah.

Paul Asadoorian (33:33.533): My friend Josh Bress was just talking about that — how the local models are catching up with the frontier models, gaining ground every day, to be on par with them. In other words, we’ll have the same capabilities as Fable 5 or Opus, as time goes on. It may lag behind a little bit, but let’s say in six months or a year we’ve got a local model that produces the same results as Fable 5 or Opus. I still think there’s some catching up to do. I tested the Antares model — that’s Cisco’s model for finding vulnerabilities, which they claim was on par. They made it open; you can get it from Hugging Face. I ran a code base through it.

Vlad Babkin (34:10.765): …and that is as dangerous and then important.

Paul Asadoorian (34:32.171): Antares claimed to find twenty-seven vulnerabilities in my code base. Those results were analyzed by Opus 5 from Anthropic, and none of those vulnerabilities were confirmed real by Opus. However, in the process, Opus found three new bugs in my code and asked, “Do you want to fix them?” And I’m like, “Yeah, absolutely.” Combining models is going to get better.

Vlad Babkin (34:54.856): You don’t know what’s…

Vlad Babkin (35:01.517): AI companies fundamentally misunderstand security and how it works. You don’t get defensive capabilities without also getting offensive capabilities, and vice versa. One drives the other. The moment you try to cut out offensive capabilities, you get a situation like the Hugging Face one.

Paul Asadoorian (35:12.470): Yeah.

Paul Asadoorian (35:24.107): That’s where the model broke out and exploited the JFrog Artifactory zero-day.

Vlad Babkin (35:31.938): Yeah, and it gets even more interesting when you start to think about this. Anthropic claims that Opus was substantially less successful in exploiting vulnerabilities. Yes. But do you care if it exploited four RCEs in your codebase? It’s still code execution. You just need one. And the whole point is…

Paul Asadoorian (35:50.540): Yeah. You just need the one. Attackers just need the one.

Vlad Babkin (36:00.288): Attackers have all the time in the world. With your guardrails, defenders don’t. Locking down the models is actually detrimental to defenders. What’s happening right now is detrimental to pretty much everybody except attackers.

Paul Asadoorian (36:12.641): Yeah, I think…

Paul Asadoorian (36:23.093): Right. Attackers are going to use local models as they get better to find vulnerabilities. We know this is coming. The hard part is: what do we do about it?

Vlad Babkin (36:34.585): And the even harder part is: what do we do about frontier companies hiding these capabilities behind walls that attackers can probably climb, but defenders can’t? It becomes a bigger societal problem. At some point we must start putting a lot of pressure on these companies to stop doing this. The moment open source models catch up to missus, all hell will break loose — running those local models will cost money. Guess who will be running them? Well-funded attackers who have hardware to spare, not companies who can’t defend themselves.

Paul Asadoorian (37:09.995): Yeah. Or budget to spare. The other interesting aspect of FortiBleed was that while they weren’t using AI, they needed a ton of compute to crack the hashes. They rented a GPU cluster. If that cost them ten or twenty thousand dollars, whatever it cost, it made sense to do it because the data that resulted was super valuable — return on investment. What’s your return on investment from a defender’s perspective? It’s a little harder to justify.

Vlad Babkin (37:52.502): Nothing. Yep. And it gets a lot worse when you start thinking about what this means for US companies and US AI. You’re pretty much handing the lead over to China for free. What Anthropic and OpenAI are doing right now — at some point it made sense, but open source models are already catching up.

We don’t have a window anymore to just wait for a better approach and start releasing this stuff to the public. Because people are going to have to start running Kimi. And this means that a lot of companies will just feed their source code to Chinese AI because they have no other choice.

Paul Asadoorian (38:41.888): I think it means there are going to be more vulnerabilities and more patches, and our InfraTrust database is going to grow exponentially.

Vlad Babkin (38:42.157): Hopeless?

Vlad Babkin (38:49.729): Yeah, it’s going to grow really fast. And hopefully somebody who has decision-making power hears this and starts to actually think about it like a defender. I get that you don’t want to give this capability to basically anybody, but this is why you have a CVP program — Anthropic has one, I believe, and I don’t remember the program name for OpenAI. You should just open cyber models to people who have actually validated their identity. If they try to misuse it, you have their passport, literally. You can ask a lot of unpleasant questions. It’s not like you’re opening it to the general public — it’s usually companies who have something to do with security.

Paul Asadoorian (39:34.050): Well, you can certainly check it out at infra-trust.org. Give us feedback. Let us know what you think, what you want to see in the future. This is now a living, breathing project, and you can expect reports every month, which is awesome.

One of the other things we observed was research from a company called Lava on a BMC vulnerability that was published in 2013. The TL;DR is essentially that if you query UDP port 623 on a system, the challenge response spits back an HMAC hash seeded with the user’s password, and from that you can derive the user’s password. This vulnerability was discovered by Dan Farmer in 2012 — it got a CVE and a paper you can still read on Dan Farmer’s website that describes the vulnerability.

People are going to gravitate toward “Why are BMCs exposed to the internet via IPMI?” — that’s the protocol that contained this vulnerability. IPMI was created in 2004. The vulnerability was discovered and disclosed in 2013. The more interesting angle is: this isn’t a patchable vulnerability. It’s a vulnerability in the way the protocol works. Your remediation is: don’t put it on the internet, lock down your BMC, monitor users, and practice hygiene rather than applying a patch. Vlad, I really want to get your take on this. Your research was cited in this report. You’ve done a lot of research into BMCs and disclosed several vulnerabilities.

Vlad Babkin (41:31.021): My honest opinion: don’t expose anything but VPN for your internal network.

BMCs, especially older ones, were never designed to face the public. IPMI — there is just a vulnerability in the protocol itself which forces you to disclose hashes. That’s it. Simple as that. There is no other way to put this. Unless we remake the entirety of the IPMI protocol, we are not going to be fixing it anytime soon.

And if you think, “Hey, there are public tools only for certain types of hashes” — newsflash, we have a private tool that does it for all types of hashes common in IPMI. We just didn’t publish it. Making this tool is super simple. The public tool actually does it for MD5 and one other hash type. There’s SHA-512 for which there’s no public tool — exercise for the listener: take two hours of research and make this tool happen for that hash type. You don’t even need AI. I made this tool before the era where AI started to be relevant. You don’t even need to rely on a massive framework; a small Python script does all of this. IPMI is just that bad.

The second question is: if you expose IPMI, IPMI does not have a certificate. If you’re talking to IPMI over the internet, how are you sure nobody is intercepting your communication?

Paul Asadoorian (43:10.262): Right, because it’s just a UDP protocol.

Vlad Babkin (43:12.639): It’s literally just UDP. There is literally nothing. So what are you doing? Don’t expose IPMI. This is the worst idea ever. Moreover, if your BMC provides a nice web UI, go ahead and read our BMC vulnerability findings.

Paul Asadoorian (43:36.450): Yeah.

Vlad Babkin (43:36.641): Surprise! Redfish is not much safer even if you expose it that way.

Paul Asadoorian (43:42.338): I was going to say the replacement for IPMI is Redfish, but as Vlad has demonstrated, Redfish has its own onslaught of issues.

Vlad Babkin (43:52.088): Well, not exactly Redfish, but specific implementations. Most of Redfish, if fully implemented correctly, has only post-auth vulnerabilities. But it’s not always implemented correctly, because nobody expects those devices to face the wide open internet.

Paul Asadoorian (43:55.574): Yes.

Paul Asadoorian (44:04.983): Yes.

Paul Asadoorian (44:11.434): It’s in the interpretation of the standard in my implementation. We did find implementation-specific vulnerabilities.

Vlad Babkin (44:19.565): Yep. Some of the bugs were fixed, but there are minor bugs even in good open implementations. We reported them. I don’t know the disclosure status yet. Not a big surprise that they exist — I’m not disclosing anything unexpected. More importantly…

Paul Asadoorian (44:28.354): Yeah.

Paul Asadoorian (44:39.382): Yeah.

Paul Asadoorian (44:46.486): Well, if you pay attention to the git commits in open source projects, you can discover vulnerabilities that have been fixed.

Vlad Babkin (44:51.905): Yeah, you probably already know about them. But look at all of the research people have done on other implementations — iDRAC, iLO. There are a ton of problems with them. Just don’t expose this stuff to the internet. Do yourself a favor and lock them down. You’re already having a bad day with everything else. Don’t also let AI break your IPMI stuff.

Paul Asadoorian (45:26.732): Yeah, I’m still curious how BMCs end up on the open internet. We’ve been talking about it for so long. It’s a separate Ethernet port, a physical port, on all the servers that have it. I understand why — maybe you want remote access — but it should come with a warning label. It should…

Vlad Babkin (45:45.517): Yeah.

Paul Asadoorian (45:55.362): Maybe we need to build code into the BMCs, Vlad, that recognizes when it’s on the public internet and gives the user a warning or shuts it down. That’s how dangerous it is to expose your BMC to the internet.

Vlad Babkin (46:10.815): It’s very dangerous. Even if you keep it patched, I don’t trust the implementation.

Paul Asadoorian (46:18.605): No, because you could do some kind of credential reuse and log into the BMC. The level of access you’re handing over to an attacker — Vlad, you’ve got some really evil attacks, which obviously we never released, that can pretty permanently break a server. There are ways to recover it, certainly not easy ways.

Vlad Babkin (46:22.701): Consider…

Vlad Babkin (46:37.549): An attack that, if you take my vulnerability and do enough research into it, can put the server into permanent shutdown within maybe four or five lines of code. And with a little bit of firmware config, you can lock yourself into that IPMI chip so that nobody else gets access. Breaking the server is trivial.

Unbreaking it requires you to get a programmer and re-flash the SPI chip manually. Doing this for one server — maybe doable. Doing this for multiple servers, if you have a couple thousand…

Paul Asadoorian (47:18.147): Yeah.

Vlad Babkin (47:25.367): Yeah, there is a problem.

Paul Asadoorian (47:27.629): Yeah, it could take months to go through a thousand servers and reprogram the SPI flash on each of them. It’s a manual process — it requires opening up the server and…

Vlad Babkin (47:31.350): Yeah, it’s going to take a while. In some cases the SPI flash is actually deep inside — sometimes it’s not easy to flash; you might need to unbolt the chip. Depending on what exactly it’s stored in, there can be surprises. And consider, we’re speaking about just my single vulnerability, but…

Paul Asadoorian (47:46.477): Yeah.

Vlad Babkin (48:00.044): This vulnerability applies to a good number of servers because many of them run AMI MegaRAC. AMI patched all of them, but — how many of you actually patched them? Did you update your AMI MegaRAC implementation after every single part of my vulnerabilities? Probably not. Did every single vendor update all of your servers to a new version? Are there any other vulnerabilities we don’t know about?

Paul Asadoorian (48:05.560): Mm-hmm.

Vlad Babkin (48:30.091): I scanned one service. There were guys from Nvidia who scanned IPMI and found vulnerabilities in there, which were also pretty nasty. Maybe other services have more vulnerabilities we don’t know about. Do you want to bet that all of this stuff is still secure? That AI is not going to find any new surprises? And I’m not even speaking about humans.

Paul Asadoorian (48:35.213): Yeah.

Paul Asadoorian (48:51.542): It was a staggering number — over thirty-six thousand BMCs exposed to the internet on IPMI and UDP port 623.

Vlad Babkin (49:00.161): Yeah. AMI is the most popular one because it’s in everything — half of them are probably AMI. But other implementations aren’t much more safe — they all have fun stuff happening. Just don’t expose stuff that you know can be vulnerable to the internet when you can totally avoid it. Buy yourself a Raspberry Pi…

Paul Asadoorian (49:08.151): Yeah.

Vlad Babkin (49:29.899): …install an OpenVPN server on it, and suddenly you have remote access to all of this.

It doesn’t cost that much. If you’re going to be running a server on the internet, you’re probably paying a lot for the internet. A Raspberry Pi’s price is not that much bigger.

Paul Asadoorian (49:49.229): And there are a ton of vendors that make a solution for that. There are multiple Ubiquiti products that make it even easier to set up that remote access and VPN. While they have their share of problems too, when something gets identified it gets fixed. My Ubiquiti system auto-updates, which is great — a lot of these other devices don’t. My home gateway is Ubiquiti and it’s set to auto-update every night at 3 AM.

Vlad Babkin (49:53.506): Yeah. Yeah.

Vlad Babkin (50:06.317): Get yourself a MikroTik router.

Vlad Babkin (50:17.409): I use MikroTik, and a high-end device for your home costs 300 bucks. A good device for a data center is probably not going to cost much more than that. You can connect that and connect your BMCs to it. It’s just going to provide a VPN. You don’t even have to do much setup beyond that. It might take you maybe two days to get around the UI and config settings to set it up securely.

Paul Asadoorian (50:27.500): Yeah.

Vlad Babkin (50:45.387): But this is really cheap hardware with a lot of power and relatively good security. MikroTik has their own CVEs, so don’t expose their management interface to the internet. Expose only VPN from MikroTik, and that’s it. Don’t expose anything else.

Vlad Babkin (51:07.359): Do yourself a favor and it will be more secure. And by the way, I’m not speaking only about BMCs. Router management interfaces are the same problem. Everything faces the same issue.

Paul Asadoorian (51:18.007): Yeah.

Paul Asadoorian (51:22.220): Well, there was that report a couple of weeks ago where SNMP was exposed to the internet, and so was the Cisco Smart Install interface — exposed to the internet. This is stuff we’ve said for over twenty-five years that you shouldn’t have exposed to the internet. It all falls in that category of management protocols that just shouldn’t be on the internet, and yet people are still doing it. I don’t know what it’s going to take to change the tides. I want to see…

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

Paul Asadoorian (51:52.194): …reports of that stuff exposed to the internet show nothing. There should be next to nothing like that exposed to the internet. Should be honeypots. That’s it. I don’t know how we get there, though.

Vlad Babkin (52:05.591): Yep. My recommendation is for people to start taking this really, really seriously. Because in the past it was like, “Who’s gonna target me?” Now there’s a whole swarm of AI, probably from bad actors, who are going to target you. We saw the Hugging Face attack, which was accidental. But consider that all of this…

Paul Asadoorian (52:26.262): Yeah. And one of the BMCs they found had a ransomware note on it.

Vlad Babkin (52:32.045): Mm-hmm. Yep. People are talking about this.

Paul Asadoorian (52:33.516): Which I had never seen before. If I was an attacker and I hit via a BMC, I would disable a bunch of things and then put the ransomware note that forced…

Vlad Babkin (52:37.131): We saw it before. I saw it before during my research.

Paul Asadoorian (52:53.014): …the administrator to use the BMC to access their server — because everything else has been cut off — to see the ransomware note. We didn’t get the details on any of these ransomware attacks against BMCs. But if the threat actors were smart, that’s what they would do. There are lots of ways to do that. Once you’re in the BMC, you have complete control over the server. You just lock the administrator out, turn the server off — the BMC is still live but the server’s off.

Can you disable the power button? I’m sure if we put our evil hats on we could construct really evil ransomware attacks against BMCs. Let’s not give threat actors any ideas, but…

Vlad, I think you’re on mute.

Vlad Babkin (53:40.008): Ransomware attack is not what I would be afraid of. There is a lot more scary stuff. Look at any of the hypothetical attack scenarios. Out of more realistic stuff — let’s imagine a nation state, not going to name any specific country, but there are quite a few who would do this and who do this regularly. Wouldn’t it be great if you had custom proxies to actually ferry data through to the US, to Europe, or to any other country you want to attack? We have AI models like Kimi K4, shared by Kimi — and again, I’m not implying just Kimi, it can be any company, just the most well-known one with the flagship model. Suddenly they have an AI model that can attack all of this stuff. They’re just going to keep it running with an evil prompt — “Get us as many as you can” — and the model is not going to care which vulnerability it exploits; it can just make exploits on the fly. How much is it going to cost? A bunch of electricity and GPUs. If you’re talking about nation states, they have millions to do this.

And if you have any sort of value, they’re also going to steal your data. Let’s say you’re in a data center and somebody breaks into your server — suddenly they have access to the whole data center to intercept stuff on the network. They’re going to be very stealthy about it. Moreover, they’re probably going to fix your bugs so that you never touch the BMC again, and you think everything’s fine.

Paul Asadoorian (55:30.688): Yep. The stealthier attacks can be almost more impactful.

Vlad Babkin (55:35.051): Stealthier attacks with BMCs are much more scary than everything else. And because vendors are stingy with visibility for defenders — which I’m going to keep saying every single BTS episode until vendors stop being stingy, which is probably never, so get ready to listen to my rant forever — you don’t get visibility into this. Your only way to see that something is happening is by literally…

Paul Asadoorian (55:47.458): Yeah.

Vlad Babkin (56:02.433): …attaching a physical hardware programmer to the actual SPI chip. That’s not a very good place to be in.

Paul Asadoorian (56:08.310): Yeah. We forget these are just Linux computers that are inside your server.

Vlad Babkin (56:14.593): Yeah. It’s super easy to get malware compiled for this stuff. We had an opportunity and were asked to actually try to compile tunneling software for it — software that runs on BMCs. Not that hard, as it turned out.

Paul Asadoorian (56:33.240): Scary stuff. Well, Vlad, Chase — thank you so much for appearing on this edition of Below the Surface. Thanks everyone for listening and watching. We’ll see you next time.

Chase Snyder (56:42.902): It’s been real, guys. Peace.

Back to all Podcasts