BTS #54 - CVE-2024-54085: The First of Its Kind
In this episode, the hosts delve into the critical vulnerabilities associated with Baseboard Management Controllers (BMCs), with a particular focus on CVE-2024-54085. They discuss the ease of exploitation, the potential threat actors involved, and the implications for data center security. The conversation highlights the challenges in detecting and mitigating these vulnerabilities, the importance of firmware updates, and the need for community tools to aid in vulnerability detection and mitigation. The episode concludes with a call to action for organizations to patch their systems and implement robust security measures.
Subscribe
Below the Surface Episode 54: CVE-2024-54085 – First BMC Vulnerability on CISA KEV
Host: Paul Asadoorian
Guests: Vlad Babkin, Wes Dobry, Chase Snyder
Introduction and Historic Significance
Discussion about CVE-2024-54085 becoming the first BMC vulnerability added to the CISA Known Exploited Vulnerabilities (KEV) catalog.
Paul Asadoorian: This week, we’re discussing BMC vulnerabilities and in particular, CVE-2024-54085, which was just recently added to the CISA KEV. We’ve also got a very special announcement, so stay tuned—Below the Surface, coming up next.
Welcome to Below the Surface. This is episode number 54 being recorded on Wednesday, July 2nd, 2025. I’m your host, Paul Asadoorian, joined by my illustrious coworkers. Vlad Babkin is here with us. Vlad, welcome.
Vlad Babkin: Hello.
Paul: Wes Dobry.
Wes Dobry: Happy to be here.
Paul: And Chase Snyder.
Chase Snyder: Hey, Paul, good to be here.
Paul: Just a quick announcement before we get started. 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.
So this has certainly been a very interesting week for all of us. Do we ever figure out if any of the vulnerabilities we’ve disclosed at Eclypsium have ended up on the CISA KEV? Is this the first?
Chase: This is the first one that I know of, but it’s also the first BMC vulnerability at all to be on the KEV. I’m pretty sure. I downloaded the comma-separated values file of everything on the KEV and I searched it. So if there’s been any previous BMC vulnerabilities on there, they are cleverly masked and poorly labeled.
Paul: Yeah, I downloaded it and I searched it using one of Vlad’s favorite vulnerability research tools called grep. I grepped for BMC, MegaRAC, and Redfish and it didn’t come up with anything other than 2024-54085. So it is a big deal.
Understanding CVE-2024-54085: The Vulnerability Details
Technical breakdown of the vulnerability discovered by Vlad and its exploitation characteristics.
Paul: When Todd Beardsley was explaining how the CISA KEV program worked—he has since left and is actually at RunZero now—he was like, “Look, we get threat reports from external parties. We validate those. Those reports contain information about how a vulnerability was exploited in the wild.” And only after they do some level of verification do they put it on the CISA KEV.
It has to meet certain characteristics: has to have a CVE, has to have a patch available in most cases. So this met all the criteria, which means there’s a threat actor out there using the exploit. When you discovered this vulnerability, Vlad, I think you still today get a chuckle about just how easy it is to exploit.
Vlad: Yep, it was. To be honest, one of the easiest bugs you can probably exploit. So this is a constant header value bug. Like, you set the header value, you get full access—admin on the device. You don’t really need to do anything else.
Paul: Technically, is this a server-side request forgery?
Vlad: I would say it is, considering it’s between lighttpd on the device and whatever runs Redfish—I’m not sure how they call it internally, a Lua-based service. And them disagreeing about specific header values and how they should be processed. So that’s kind of like an SSRF, but not quite there. It’s not quite the same, but very similar.
Paul: Because it’s like an authentication bypass and an SSRF rolled into one. I’m not sure if there’s a CWE that covers both of them where you just slap both tags on there basically.
Vlad: I honestly don’t know which one to slap on it. In this case, SSRF more classical is when you actually force the server to make a request elsewhere. You don’t really do that. So it’s kind of like that, but it’s not quite SSRF. You don’t force the server to make any requests elsewhere. You could say it’s like header injection. Maybe that would be better classification.
Threat Actor Speculation and Attack Motivation
Analysis of who might be exploiting this vulnerability and why BMCs are attractive targets.
Paul: One of the questions that collectively we’ve been asked is: who’s behind this? Who’s exploiting this in the wild? Which group is it? What are their motives? Where are they from? At this time, we have no definitive proof or evidence to point to any particular group or country.
So all we can do is speculate. I actually prompted an LLM and asked this question: given this attack, given the CVE against this particular type of technology, what groups would likely be behind this attack? And it pointed to Volt Typhoon, Salt Typhoon, Velvet Ant—largely Chinese-based threat actors that are targeting infrastructure gear and IoT devices.
Wes: You’re also going to see ransomware groups go after this kind of stuff too. Anything that enables both escalation of privilege and lateral movement is going to be a key vector that these guys use. Anytime they get into an environment, they’re going to start looking for other avenues to continue to put their hooks in.
If they get to an administrator’s workstation and they’re trying to get into an ESX environment, the first thing they’re going to do is try to take a look at what they can access. If they can hit a BMC, this is a trivial exploitation that immediately gives them capability to have full control over the device.
The trick is: if you can talk to one BMC from an admin workstation, you could probably talk to all of them. And I can do the same exploit on one system or a thousand with the same level of effort. That’s why this is such a critical thing that needs to be addressed.
Why This Vulnerability Took So Long to Exploit
Discussion about the barriers to BMC exploitation and why this is the first to appear on CISA KEV.
Chase: Why is it a big deal for a BMC vulnerability to be actively exploited? And also, what took so long for this to happen? We at Eclypsium have been disclosing critical BMC vulnerabilities—I think the earliest one that I found that we disclosed was 2019, and there have been other ones before that, known vulnerabilities like IPMI stuff since 2013. It’s a known risk, known attack surface with huge implications for what the attacker can do. Why did it take so long for this to start being exploited?
Vlad: Why was it so long? There are two options here. Option number one is that it just is not that trivial to actually exploit the target. While the attack is very trivial, it’s hard to get to the target and get something useful out of it.
The problem with this is that you need to be on a network with all of those BMCs, and organizations which have a lot of them usually are careful. If you are a data center, you probably are not going to connect BMCs to your normal customer operations network or even your normal internal network because that’s just dangerous—that’s a very obvious risk.
There are people who connect them to the internet, but there are not a lot of them. Maybe if you look through the entire IPv4 space, we maybe will find like 15,000 of them. If you look at vulnerabilities from 2013, you need to brute force hashes. If you look at previous IPMI vulnerabilities, you need to have some binary exploitation there. So they were not quite as trivial as what we disclosed.
So it’s just not a very tasty target for ransomware, and it was kind of hard and difficult to get for APTs as well, even though implications are huge. And there is option two: it’s the first time we find out about it.
Paul: Yeah, I like that answer a lot because we don’t have great visibility into these BMCs. It could be that we just weren’t looking in these areas before.
Network Architecture and Trust Assumptions
Wes: There’s another key thing here around what enterprises view from a risk perspective. When you’re architecting how you’re doing your server deployment and management networks, you’re making the assumption that only trusted entities get access to that network.
To Vlad’s point, it’s about availability of the attackers being able to reach these types of devices. When enterprises do this, they’re assuming you have a trusted entity and a person, you have a trusted device on a trusted network segment, and you’re doing best practices from an authentication standpoint.
This kind of jumps around a big majority of that piece—the trusted entity and the authentication component. By getting that easy, quick access to it, this is now opening up the avenue for huge risk. And that risk now ignores a lot of the things that as enterprises we’ve said has made BMC security much less of a concern.
This has risen in priority even after—when was that? 2022 that the NSA released the best practice for BMC security. And that was also recently echoed by an operational directive to heavily secure and monitor BMC activity as well.
Post-Exploitation Capabilities and Attack Chains
Analysis of what attackers can accomplish after successfully exploiting the vulnerability.
Paul: One of the reasons why I really want some of the forensics and incident response data is I want to know what the attackers did after they successfully bypassed authentication. Because oftentimes, when there’s an authentication bypass, it opens up the floodgates for authenticated command injection attacks.
This authentication bypass just gives you access to the web interface basically—it does not give you a shell on the Linux server running on the ASPEED chip inside of it. But once you’re authenticated, there could be an authenticated command injection that I can then pivot into shell.
Wes: If you can get to the BMC, you could go and reconfigure anything on it that you want theoretically. You can enable SSH and then jump to an SSH console that’s running on the BMC itself.
Vlad: If you want a horror story, BMC&C V1 and V2 both have authenticated code injections, and BMC&C V1 has authenticated code execution. Back in the day, those had a default account which was posted on Twitter of all places. You could just find it and hello, you have password for quite a few BMCs just hanging around which get you into root shell.
There are quite a few potential holes where you can actually dig down. And aside from us, in that same BMC—same MegaRAC, no other changes—there are about 20 CVEs from Nvidia. Alex Tereshkin was the leader of that research.
Paul: Their research was specific to MegaRAC or OpenBMC or both, right?
Vlad: Yep, it was MegaRAC and it was specifically IPMI. So while we were trying to break Redfish with everything we got, they were trying to do the same to IPMI. And they also broke it with everything they got. They got unauthenticated command injections, or chain of bugs which leads from unauthenticated to command injection.
Better yet, some of their CVEs—if you actually dig down, one of their CVEs was about “hey, we can read the password from the BMC,” but actually you can execute commands if you try hard enough with that CVE. So there are quite a few CVEs which might have not been patched by a vendor because they were just not seen as dangerous while in fact they are.
All of them are compatible with one another. So if you bypass authentication with our CVE, create yourself an admin account, you can then go to IPMI and execute code using Nvidia’s vulnerabilities, and the same backwards.
Paul: Because the BMCs today support both Redfish and IPMI, even though Redfish was supposed to replace IPMI.
The Persistent IPMI Vulnerability
Vlad: Even better yet, if you want even more horror stories: every single IPMI implementation is vulnerable since 2013—probably longer, since 2013 is known to be vulnerable—to hash leak. So you can actually, if you know a username, you can get a password hash which you can then crack reasonably fast on GPUs, and that’s for any single IPMI implementation.
You can actually just use that if you don’t know any unauthenticated bugs. The only catch is that you need to know a username. That’s it.
Physical-Level Access and System Control
Discussion about the extensive control BMC access provides over server hardware.
Wes: One of the other things we haven’t talked about here yet is just using things like Redfish to modify other things that would apply to the running operating system on the server. Getting into the BMC can get you access to IPMI and Redfish. Using Redfish to modify things that would impact how the running server’s operating—whether that’s something as simple as a hard power off of the system.
Imagine if you get into a data center and you get to an admin workstation that can access a thousand, 10,000, a hundred thousand BMCs in an environment, and then you get access to all of them through this exploit, and then you just power off an entire data center. That’s absolutely possible with this vulnerability.
But you could do something even a little bit more silent, like modifying something and adding something into the boot list through Redfish. Then you can now exploit malicious code if you have access to the server through another mechanism. The opportunities here are effectively giving someone almost physical access to a machine.
Paul: Correct. It’s a great point, Wes. It is essentially physical access to the system.
Chase: Which is also built to still work even if the power’s off or the operating system isn’t accessible.
Paul: You have the servers powered down, it’s plugged in. The BMC is typically still getting power unless you flip the rocker switch on the back of the power supply. Of course, in larger data centers, it’s probably not just a simple rocker switch in the back of the power supply, although oftentimes it is. But if that’s on, getting power, the BMC is getting power.
Network Configuration Vulnerabilities
Wes: One of the things that I learned when I used to install servers in data centers was a lot of times if you don’t plug in a BMC, it can actually ride on the primary NIC if it was configured that way. So now you plug in the primary NIC and it goes out to its data network and it’s also getting an IP for the BMC on that same interface.
So now, as an attacker, if I go and scan the service network inside of an environment, I could find BMCs that are not in protected network segments, potentially.
Vlad: I will beat it even harder. So there are two things you can do. Thing number one: if you have access to BMC—I’m not speaking about code execution, you just have admin access. So let’s say you just bypassed authentication and failed to find any code execution. What you can now do is just turn off secure boot. It’s not a thing for you anymore because you can configure BIOS from Redfish and from BMCs in general. And you can do whatever the hell you want basically from there.
It gets even better: even if you don’t connect to your BMC and even if your BMC is not configured to ride on your main primary NIC, you can still get to it from the host. So there is a thing called the host Redfish interface which allows you to get to Redfish from the BMC, and sometimes it’s by design not even asking you for authentication on that interface—it’s not a bug, it’s a feature.
There is also KCS, an older interface which allows you to execute IPMI commands on the BMC with no authentication whatsoever. So if you are on a bare metal host, you might have unexpected problems there if you didn’t configure it properly.
It’s even greater if you find authenticated code execution in the BMC from the host and BMC is connected to the network. Well, now you just got into network with BMCs.
Paul: Right, you just jumped the network. So this is dangerous, not just as an entry point from the BMC side, but also the host side, and it kind of can go back and forth.
Vlad: Yep. So there is a lot of surface there. In this case, the only way to actually protect from this is to not allow access to BMC from the host at all. So some BMCs allow you to just disable it. Some others don’t. So if yours don’t, you might have a problem with your bare metal hosting.
Wes: If you disable something like the IPMI driver, you lose functionality within the BMC itself, within the operating system. Things like sharing the screen and stuff like that. It’s one of those scenarios where if I want to use the full capabilities of the BMC, I also have to open myself up for the operating system to talk back to the BMC.
That’s the question that each organization has to weigh the risk on. If I’m a bare metal host, I need to maintain the access to that IPMI driver or BMC interface from the host OS and dramatically ensure that it’s highly secure.
Attack Scenarios and System Compromise
Detailed analysis of attack chains and the devastating potential of BMC compromise.
Paul: But if an attacker can get to the web interface of your BMC, whether internal or external, they have an authentication bypass, they create an account for themselves, they access the server. Typically included, as most folks know, when I’m on the BMC, there is a plugin in the BMC code that can give me terminal or desktop access to the host operating system.
So kind of a scary attack chain is: I get in the BMC, I disable secure boot for the system, I pop a terminal or display, I put my malware or modify the system in some way, because now secure boot’s not enabled, so it’s not going to care. They put that on there, and now I’ve just through the back door delivered malware that the system is blind to.
Wes: There’s a tremendous amount of attack vectors on that side. Especially if you do disable something like Secure Boot and the host is a Linux host, you can make kernel modifications to load other security measures. You can literally go and loosen up the security on that system that then you could exploit it from a public web interface, whatever service is actually hosting.
To Vlad’s point, the opportunities here are tremendous where this can be not only like an initial attack, but it opens up so many other opportunities. And as you think of the more capable threat actors out there, they could go and pull some kind of an attack chain together to do some incredibly nefarious things.
Paul: Yeah, I hadn’t considered just how dangerous it is and how much of an attack surface it opens up.
Vlad: It is a horror story for the administrator, basically. It’s very hard to actually approach defending it. It’s not a flip switch you can just make secure, no. You actually have to consider all of that. Do you want to keep your IPMI interface to the host and don’t want to get shell access to it and potentially leave open vulnerabilities, or you don’t and you don’t want shell access as well, which makes BMC useless for you, potentially. So you are in a tricky situation.
To the point, quite a few BMCs, modern days, allow you to disable unauthenticated access at least. So you can actually disable KCS, can disable unauthenticated Redfish at the very least. So you still have to find the bug, but still you might close up network vectors like our authentication bypass.
Paul: Right, so there’s configuration hardening. It’s not an easy remediation to do it right because there’s configuration hardening, there’s network segmentation and network controls, and then you have to update the firmware of your BMC.
Detection and Remediation Challenges
Analysis of the difficulties in identifying vulnerable systems and implementing effective protections.
Chase: Paul mentioned that you can’t really do version-based detection checks to detect the presence of this vulnerability in your environment. If you are a data center owner and you want to find out whether you have systems that are vulnerable to this in your environment, you can’t just check firmware versions because the different vendors that use this AMI MegaRAC firmware might have different version numbers for their own thing. So what do you do if you’re just trying to inventory your attack surface for this thing inside of your data center?
Vlad: You have to assume that every BMC is vulnerable to it. If I tried to inventory it like this, even if it is not vulnerable to this one, it’s going to be vulnerable to something else. There is a plethora of bugs.
If you want to find if it is vulnerable to this one specifically, and you want precise information, the only path for you is to actually try to exploit it. There is just no way around it.
Paul: We’ll talk about our blog post that went up moments before we started live streaming. If you go to our blog, you can find nuclei templates to test for this. This is hard because you can’t rely on versions because AMI makes MegaRAC, they license it to an OEM, and then that OEM makes customizations to it. Those customizations could be like they call it whatever their version is, not what AMI is listing.
AMI calls their versions like XBX underscore 12.0 or 13.0. That’s the base code, almost like the reference implementation that gets sent to the OEMs. The list is very long of who implements this. They make customizations and they call it whatever their version is. So it’s difficult to build a whole database of what version maps to being vulnerable or not.
Version Management Complexity
Vlad: It gets even better because version numbers might be per server, per model. And it gets even better yet because some of them might not even be patched. So even if you build a database of all the version numbers of all the firmwares for every server and look for CVEs and change logs to find the fixed versions, you never know if it was not fixed in some other server because it reached end of life.
There are probably servers which are not going to get patched ever.
Wes: Those servers that aren’t going to get patched ever—going back to Chase’s point about US government binding operational directive 22-01—there are servers that exist out there that can’t get patched because they’re already too old to get the update. We’ve already discovered some Lenovo systems, some HPE systems, as well as some Dell power switches that are running AMI MegaRAC through their own disclosures and advisories.
So this isn’t isolated to certain manufacturers; it’s across the board.
Vlad: Kudos to the manufacturers for actually disclosing this, because this is a massive hole. So that’s a reputational impact for them, but they still do it. That’s the right thing to do, because at the very least, the customer has a chance to isolate those devices. Otherwise, you just don’t know.
Federal Government Response and Compliance Challenges
Discussion of the CISA KEV implications for federal agencies and the challenges of rapid remediation.
Paul: Yeah, knowing is half the battle. Figuring out what’s vulnerable, if it has a patch, is a laborious process. Because if AMI will not have a patch, if it doesn’t exist for your federal government agency, typically the recommendation is to take it off the network. But if the BMC is tied to the host operating system, now you’re just going to buy a new server. That’s what it comes down to in the worst case—I got to buy a new server, I got to retire it. And that’s not happening in 30, 45 days in probably 99.9% of the cases.
Chase: When this got added to the CISA known exploited vulnerabilities catalog, that triggers binding operational directive 22-01, which means federal agencies have three weeks from that addition to patch or mitigate this. I think this was added to the KEV on June 25th, so July 16th is the date that they have to patch it.
The likelihood of the patch happening across all federal agencies for this thing is low by that time, I would say. So it’s going to be other mitigations. And we’re talking right now about how difficult and laborious the other mitigations are.
The stack of challenges and risks here continues to make me surprised that this hasn’t happened before, but also makes me feel like this bust it wide open now. There’s one on there, it’s appealing, there’s going to be more exploitation of this whether we find out about it or not, and there’s going to be more BMC vulnerabilities. There’s a huge amount of them already out there and there’s going to be more discovered. It’s going to be a whole can of worms that has just been opened up.
Persistent Threats from Hardware Lifecycle
Vlad: Even if you buy a new server, you have to move all of the stuff from it and you still have to check the new server for the same bug because there is no guarantee that you bought something top of the line. If you have a file server, you’re probably not going to buy the modern AI training system to host your files. So you might actually buy yet another second-hand server. And even better yet, it might create you more problems because now you have a fleet of a thousand servers which are vulnerable to this. Now you buy a new one for some critical systems and now you have two types of systems to manage. Your automation might break.
Paul: An interesting attack too is if I’m able to put malicious code on the BMC firmware and that server gets repurposed or resold, my backdoor goes along with it.
Vlad: Yep. A backdoor from the BMC will probably not get removed unless you actually refresh the firmware. And even then, the question is, how do you refresh BMC firmware? It’s usually through the BMC web interface. So if I would be an attacker who really wants persistence, I would probably tell them, “Yes, firmware is refreshed. It’s new firmware.”
Paul: Yeah, we’ve seen that in other platforms where the firmware update process has been backdoored to preserve malicious code even surviving a firmware update or backup and restore.
Vlad: Even better yet, the only way to actually ensure you’ve flashed it would be to disassemble the server and use a physical programmer to actually flash the memory of the BMC. So you have to find the specific chip and flash specific firmware you want on it. And even then I would not be quite so sure considering there might be more than one place malware might be in. So you have to refresh every single chip with memory in there and then you can be relatively certain.
Paul: Right. Also reflashing comes with risk. We don’t assume any responsibility if you burn out your motherboard on your server because you have to power up the chip, which means applying voltage whenever you’re doing that on a system. It runs the risk of something might short, blow up, or oops, I put five volts when it was expecting 3.3 because we’ve never done that before.
Vlad: Or oops, I connected it in a bad way. For example, physical programmer has like 8 connectors. What if you flip it 180 degrees? The chip just fries itself because of this. Or you can choose the wrong chip on the physical programmer and just do something to it which is not flash the firmware.
Paul: That’s when the magic smoke comes out is what we call it.
Vlad: Yeah, and then your technology is useless because it’s no longer powered by the magic smoke.
Chase: Every machine is a smoke machine if you use it wrong enough.
Vlad: Why right enough, not wrong enough?
Nuclei Templates and Community Tools
Introduction of the detection tools released by Eclypsium to help the security community.
Paul: We did recognize some of the challenges here and we worked internally. I was like, “How do we discover this vulnerability?” And it turns out we had nuclei templates that could test for it. When I observed the industry and the community, I was like, “Hey, I’m not finding great tools to test for these vulnerabilities on BMCs.”
So I’m like, “Can we just release our nuclei templates to give people the necessary tools to at least discover the one that’s on the KEV certainly?” And then we also added the one that’s similar to that from 2023, which is like—if you look at both nuclei templates we released, there’s really only one line that changed between them.
What we’ve done is we made a blog post just before we went live on the show and we released two nuclei templates that right now you have to copy and paste into a file and run them via nuclei. We are working on getting those in GitHub. But for now, they’re on our website.
If you’re listening to this and you’re like, “How do I find this in my environment?” We’ve written these, we’ve tested these. And I will say before we dig into any of the details on them, that if you do discover something that’s vulnerable that collectively as an industry we didn’t know was vulnerable, please reach out to us. We’re more than happy to help you with that.
Responsible Disclosure Approach
Vlad: The reason for not releasing any exploits for quite a while, especially with V1, was to let people actually patch their stuff, because the initial two vectors included code execution. I believe Nvidia didn’t release their tools publicly either at the time. But considering the cat is out of the bag and actual attackers have this, we might as well publish nuclei templates, because at least you have a chance to actually race forward.
It’s already in the wild, so we ain’t doing a disservice to the community in this case. And it was probably the right call because it took two years instead of 15 minutes to actually weaponize this. So we probably did the right call for not releasing any tools to exploit stuff back in the day.
Technical Details of the Templates
Paul: Vlad, you did a great job writing these nuclei templates. I studied them and I thought they’re great. It’s pretty cool how they work. It’s basically three POST requests and then you’ve got a conditional statement that matches the responses from those POST requests. Is that the high-level summary?
Vlad: Yeah, so high-level summary is that we have three requests in each. First one checks that it is the right BMC. Second one checks that it actually will ask you for authentication, so that in the weird case where you actually disabled it, it will not false positive. And the third case is actually trying to exploit the vulnerability and checks if it gets the response. I just made it for making sure we are not triggering on any false positives accidentally.
An important point is that we probably are not going to release more advanced code execution pieces of it—ones with post-auth, etc.—because A, we don’t see them in the wild, and B, they are all post-authentication. For now, we probably should hold off on that to not make the situation with KEV even worse. We know that authentication bypass happened. Let’s not make it easier for attackers to actually get code execution as well.
Paul: I also included an example of how to use nuclei to scan a target and discover this vulnerability. So that’s in the blog post as well. And with nuclei, you can also do a dash L flag, upload a file that contains multiple targets. And you can also output the results to JSON. And nuclei has a ton of options. I was just like, these are the two that you might want to consider if you’re running this against a whole bunch of servers. You’re not going to run against each one individually. You’re going to populate a file, you’re going to save that out to JSON and then use an LLM like the rest of us to parse that JSON file and tell you what’s vulnerable.
Chase: Man, you’re saying the quiet part out loud there, Paul. Talk to my buddy, ChatGPT.
Paul: That’s it. I have not done that yet, but I’m sure someone will. And if you release your code, great, that’d be awesome for the rest of us. I think the whole point in this post was to help the industry and the community as a whole identify which stuff is vulnerable because it could be listed on the stuff we already know, or it could be someone else’s implementation that has the same bug. And that vendor hasn’t disclosed it.
We haven’t looked at someone’s firmware to point out the vulnerability, but you’ve got it in your data center. And if you use this template, we might discover something new. And it also gives you a nice list to go, these are the BMCs you need to go update to the latest code, provided the OEMs and your vendor has given you updates for that. And it’s not end of support or end of life.
Scale and Impact Assessment
Discussion about the widespread deployment of vulnerable systems and detection challenges.
Chase: We had some people in the chat asking questions about end of life devices and whether/how those are going to be addressed.
Paul: It’s super hard. But I think Vlad and I can speak from personal experience that trying to figure out who’s got which BMC, so the vendor, and then which model of their products uses a BMC, which of those would use something like a MegaRAC that could be vulnerable, and then going to find that firmware, reverse engineer that firmware. Sometimes that firmware is not even available from the vendor’s website—it’s not even a thing. So this complicates our discovery of impact and scope.
Vlad: Unless the vendor explicitly says it’s MegaRAC or you can reverse engineer the firmware to confirm it’s MegaRAC upfront, that’s how you would detect it. If you have a server, you can actually make requests to it to check if it is MegaRAC, like look at our template, we are doing one of the tests for that. So it’s very doable. But vendors can customize UI and I have seen that happen. So you cannot rely on how the UI looks like because UI might look different and it still would be MegaRAC at its core.
It’s really hard to tell how EOL devices will be addressed because it depends on the vendor. And by the way, I also see chat. In the chat, there was a question about how many servers are there. Well, 1,000 to 2,000 servers is just the number for MegaRACs on the internet. I believe that number was like 4,000 in 2023. I didn’t do a full recheck in 2025 to actually dig down, but that number is relatively low. And that’s just MegaRACs. So total number of BMCs on the internet is probably multiplied by like, what, two, three, four, whatever multiplier you’re comfortable with.
Paul: Just MegaRAC on the internet.
Vlad: It’s very tough.
Paul: Right. Yeah, so it’s hard to get accurate data as to what’s out there on the internet too. I know Shodan gave me 1,200, 1,400. And when I looked, some of them were tagged in Shodan with the tag cloud, and they traced back to Linode and other cloud providers. Some of them were actually labeled honeypots. I don’t know how accurate those tags are in Shodan. So it’s tough to say what’s on the internet.
Chase: That’s the lowest hanging fruit—the stuff that’s exposed to the Internet. But probably a more interesting use case for this vulnerability is the attacker gets in some other way. If you’ve got your management plane exposed to the Internet, you already got problems. If you’ve done the bare minimum to not do that, this is still an exposed attack surface inside. It’s like you locked the doors to the bank, but then you just scattered the cash around on the floor right inside the door.
Vlad: If you think about a data center, we can assume that there are at least 50,000 servers in a medium-sized data center. There are probably bigger ones as well. None of them are getting external IP addresses, so we cannot scan them from Shodan. They still have BMCs in them—all 50,000 of them. I cannot tell you upfront how many of them are going to be MegaRAC. Maybe none, maybe all of them, depends on what hardware is in your data center, and none of it is exposed to the internet by default.
Yet, it is in some management plane, and there are many data centers in the world. So the total number of BMCs is insane.
AI Data Center Implications and Supply Chain Risks
Analysis of how this vulnerability affects the rapidly expanding AI infrastructure landscape.
Chase: Something we’ve been talking about a lot lately is the proliferation of AI data center buildouts. Every day there’s a new news story about however many billion dollars getting allocated to build out new AI data centers. If you’re building out a new AI data center and you find out about this, how does this affect your procurement or your due diligence about the gear that you’re actually buying?
There’s been a patch issued for this firmware. How do you make sure that you are not buying gear that has been on a shelf, making its way through the hardware supply chain—basically gear that was produced and shipped before the patch got out? So you’re going to get brand new gear and rack it in your data center that has this vulnerability in it. How do you make sure not to do that?
Paul: Well, you want to evaluate the vendor, but also you want to pre-deployment into the data center, update the BMCs. And this is what a lot of people do. Some probably don’t, but I’ve heard people that are producing commercial hardware update the BMC, check the BMC software before they ship that. Not everyone does that.
And then you’re an enterprise customer, you’re building out an AI data center. You’ve got to check before you rack and stack them. You got to check the BMC version.
Vlad: I’ll make it even funnier. What if in a year we release BMC&C V4? I’m not saying that we have anything to release, but let’s say we find something in there again, or we find something in another BMC vendor, or Alex Tereshkin does this. New vulnerability drops for one of them. Now what do you do? You have a whole data center of those, and you find out that half your gear has it. What’s your game plan?
A lot of people are afraid to update BMCs because it can be risky. Yet you have to because it’s very dangerous to keep them unpatched, especially considering we know some threat actors are using that.
Firmware Update Automation and Signature Validation Risks
Analysis of update mechanisms and additional vulnerabilities in the update process.
Paul: Can you use Redfish to automate the firmware update across your BMCs? I’m sure the answer depends on the vendor, but I’m assuming that’s an option.
Vlad: It depends on the vendor. How you do it depends on the vendor. There is no one solution fits all. It will depend on the vendor and potentially on the model as well. What I haven’t seen so far in the BMCs is auto-update—where BMC keeps itself fresh on its own. That’s not something that exists. But there is a way to actually upload fresh firmware through either UI or API or Redfish or somehow. It has a way to actually refresh itself.
Paul: And there are other vulnerabilities that are specific to Supermicro. And no knock on Supermicro—these are vulnerabilities that Supermicro has disclosed. I believe it was Nvidia that found the signature validation had a flaw. So when we talk about updating firmware, this is yet another attack vector that we haven’t talked about yet.
As an attacker, if I can use Redfish and some of these other vulnerabilities perhaps to interface your BMCs via Redfish, if there is a vulnerability that can allow me to bypass signature validation for the firmware, that means I can backdoor firmware and use Redfish to push that out to all of your systems. And that would be very difficult to detect.
Wes: You hit the nail on the head. This can be scalable and can be used to do those kinds of attack vectors where if it’s not doing the signature verification or actually doing any sort of validation against that, you could even go so far as to roll out through Redfish with this attack something that bricks every BMC.
If I shut down every server and then bricked every BMC in a data center, that would not be the fastest to recover from.
Advanced Attack Scenarios and Persistent Threats
Discussion of sophisticated attack chains and the potential for devastating data center-wide impacts.
Vlad: With BMC&C V2, we had the demo—a permanent shutdown of a server. It just starts a script.
Paul: Vlad wrote one and thankfully you have not released that to the public, and I won’t give attackers any ideas, but Vlad has proven it’s possible.
Vlad: It’s actually not difficult. I’m not going to go into details, but let’s say that it took me about three lines of the actual script to do this—a bit of sorcery to actually get code execution going and tie it to code execution. That’s about it. And the server starts shutting down itself every 10 seconds.
Paul: So it tries to spin up and then it shuts down, tries to spin up and shuts down. And this is pre-operating system or even independent. The power button doesn’t help me because it’s got its own power mechanism before the power button is even activated.
The Ultimate Denial of Service
Chase: So “turn it off and turn it back on”—you take that away. The main tool, the most important tool in the toolkit, “turn it off and turn it back on,” has been turned against you. That’s dark, man. Vlad, I can’t believe you did that.
Vlad: In my demo, I didn’t actually lock BMC interfaces, but it’s not that hard to actually get some iptables rules going so that BMC is locked within itself so that you cannot access it from outside. And then if you try to boot the system, what you get is that it shuts down in 10 seconds flat. You don’t even get to BIOS. Even if you come there with a monitor, you will be left with a system that shuts itself down.
Now imagine if I would be evil and I just would spread this across your data center and configure it to trigger on a specific date instead of showing my hand immediately on the first few systems.
Paul: Yeah, it’ll be lights out until you could physically remove power from the server and then reprogram all the SPI flashes with clean images on every server.
Vlad: You cannot do this one by one. You have to shut them all down because if I would be evil, I would make them automatically spread to any server that gets connected to the BMC network automatically. Even if you reflash the same image, it will get infected immediately again. And that would be the “shut down your data center” kind of attack. Maybe not entire data center, but a fraction of the hardware, whatever has MegaRAC.
While we are bashing AMI here, it’s not MegaRAC specific. What I’m doing there is not something that other vendors cannot really do. Every single BMC out there can power the server on and off. If you get a code execution bug in there, you can just call that feature.
Paul: Whether you’re getting it from AMI, doing it on your own, or getting it from somewhere else, you have to write an interface to Redfish. You have to implement the API in a language. I believe the language that AMI MegaRAC used that we talked about in part two was Lua. And that’s what was implementing the API based on the specification. Obviously, someone else could write other kind of web API software in any other language to implement that API. And that code could be vulnerable to a number of different things as well.
Vlad: You don’t even need to actually focus on the language. You can actually compile something like a Go binary and just deploy it there and call whatever the Lua is calling internally. You can call from Golang or from C++ or from whatever.
Paul: Yeah, there just needs to be some software that implements the API.
Vlad: So it’s not even just language, it’s just compatibility with the specific vendor model, whatever.
Defensive Strategies and Network Architecture
Recommendations for protecting against BMC-based attacks through proper network design and monitoring.
Wes: Even regular segmentation of the network is not going to be sufficient in this case. You have to have micro-segmentation or start to employ things like bastion hosts so that you can start to add layers of isolation to these things.
If I were to re-architect a data center and look at this, I would want to only have systems that manage IPMI to be able to talk to them and never have a human go directly to something like a BMC. That way I can have my bare metal provisioning solutions that are building the server—they’re the only things that can talk to it. I should never, at a certain point, have a human able to actually do that and I run it through my standardized solutions.
Vlad: If you really want to defend your network, you have to break communication between BMCs as well. So in your segment, you have to make sure that bastion hosts and only bastion hosts can talk to BMCs. If you see BMC-to-BMC traffic, even attempted traffic, that’s a red flag. You have to ring bells, whistles, whatever—that somebody is doing very bad stuff to that host.
If your BMC on a bare metal tries to communicate to another BMC on its own, that’s probably time to actually turn that bare metal server off and start investigating into it, because that’s not supposed to be happening.
Conclusion and Key Recommendations
Final thoughts and actionable advice for defending against BMC-based attacks.
Paul: Well, this is scary. I think that’s what we’ve proven. But I think the resounding thing that gives me hope is that we did release some tools for the public. We’ve been evangelizing this issue. We’ve been encouraging folks to look for patches, apply those patches, use the tools that we provided to discover this.
Any other tools you have or want to share with the community, we’d love to hear about them. Of course, if you’re running our product, you don’t have to run these nuclei templates—our product does help you discover and enumerate vulnerabilities on your BMCs as best we can.
As we’ve said in previous episodes, this is a difficult interface to really get good telemetry on just because of the design. The communication oftentimes is one way, so you’re not able to really have an EDR on your BMC.
Anything else we want to share on this topic?
Wes: Patch quickly, patch often.
Vlad: Do network controls—don’t let your BMC talk to anything.
Chase: Patch, segment, monitor your BMC.
Paul: Patch and segment. Thank you, gentlemen, for all of the wonderful tips and deep dive into this issue. Thank you, everyone, for listening and watching, especially those tuning in live. That will conclude this episode of Below the Surface. We’ll see everyone next time.
Key Takeaways
- Historic Significance: CVE-2024-54085 is the first BMC vulnerability ever added to the CISA Known Exploited Vulnerabilities catalog, indicating active exploitation by threat actors.
- Trivial Exploitation: The vulnerability is exceptionally easy to exploit—essentially a header injection that provides immediate administrative access to the BMC.
- Detection Challenges: Version-based detection is nearly impossible due to vendor customizations of AMI MegaRAC firmware, making exploitation testing the only reliable detection method.
- Widespread Impact: The vulnerability affects multiple major server manufacturers including Lenovo, HPE, and Dell across numerous product lines.
- Physical-Level Access: Successful exploitation provides attackers with capabilities equivalent to physical access, including power control, BIOS modification, and secure boot disabling.
- Attack Chain Potential: BMC compromise enables lateral movement, persistent backdoors that survive OS reinstalls, and devastating denial-of-service attacks.
- Federal Compliance Crisis: The 21-day federal remediation deadline is likely impossible to meet for most agencies due to patching complexity and end-of-life systems.
- AI Data Center Risks: Rapid AI infrastructure buildouts face particular vulnerability to supply chain attacks through pre-compromised BMC firmware.
- Network Architecture Requirements: Effective defense requires micro-segmentation, bastion hosts, and prevention of BMC-to-BMC communication.
- Community Tools: Eclypsium released nuclei templates to help organizations detect these vulnerabilities in their environments.
- Persistent Threat Scenarios: Vlad demonstrated how BMC compromise can lead to permanent denial-of-service attacks that survive power cycles and make systems effectively unrecoverable without physical intervention.
- Supply Chain Implications: Backdoored BMC firmware can persist through server resale and repurposing, creating long-term supply chain security risks.
Episode Length: Approximately 56 minutes
