Alongside the disclosure, runZero released OOBscan, an open-source tool that scans for vulnerable BMCs and other out-of-band management devices.
Sitting inside almost every server is a potential backdoor that could put an enterprise network at risk.
Baseboard management controllers, or BMCs, are the hardware embedded in server motherboards that provide remote power control, console access, and firmware updates independent of the host operating system. IPMI is the protocol most commonly used to reach them.
At the DEF CON 34 conference, security researcher HD Moore, co-founder of runZero, disclosed a set of largely unpatched vulnerabilities across that layer, spanning HPE iLO, Supermicro IPMI, Dell iDRAC 10, and the open source OpenBMC project. Moore’s presentation put the total at 123 confirmed vulnerabilities, consolidated into 35 draft advisories across eight vendors.
Moore has tracked BMC security since Dan Farmer’s original 2013 research into IPMI password disclosure, and this year’s work found the exposure has gotten worse rather than better. Some of the affected devices carry a million dollars of GPU hardware, reachable through a web login with no password at all.
“These are devices that are effectively a sanctioned backdoor to whatever your real hardware is,” Moore said in his DEF CON session.
Sean Michael Kerner
How management ports end up exposed
Many servers ship with a single physical network port shared between the host and the BMC. If the device configuration resets or a checksum error occurs, the BMC can pick up its own address through DHCP on whatever subnet the port is plugged into.
“It’s usually because someone messed up and DHCP’d the wrong NIC,” Moore said, describing why researchers keep finding tens of thousands of these controllers exposed to the open internet.
An internet-wide scan combining IPMI probes across the full IPv4 range with Shodan queries turned up roughly 51,000 devices responding to IPMI. About 23,000 to 25,000 of those handed over a crackable password hash with no authentication required. Internal network sampling from runZero customers found the exposure worse, not better, since those networks were never meant to be scanned from outside.
The new research also changed how easy these devices are to break into. Before this work, roughly 12% of BMCs on internal networks could be accessed without cracking anything. After the new vulnerabilities Moore disclosed at DEF CON, that number reached roughly one in three. On internet-facing devices, the trivially exploitable share rose from about 8% to 21%. Once an attacker gets in through the BMC, the server’s own defenses no longer matter.
“It doesn’t really matter how secure your server is,” Moore said.
What an attacker can reach
Several of the bugs Moore presented start with no credentials at all. They end with code execution on the host server, not just the BMC. The research grouped the underlying flaws into a handful of recurring classes:
- RAKP state-transition bugs. RAKP, the Remote Authentication Key-Exchange Protocol, is the challenge-response handshake IPMI 2.0 uses to authenticate a session. Skipping or reordering its steps lets an attacker authenticate against leftover data sitting in memory.
- Type confusion. A session started in one authentication mode ends up reusing credentials that were meant for a different mode.
- Vendor-specific backdoor modes. Supermicro added a hardcoded password meant to stop password hash leaks, and the fix became a bypass of its own.
- Session relabeling. Two sessions sharing the same identifier can be used to escalate a low-privilege account to an administrator.
- Integrity and encryption bypass. A device accepts unencrypted commands even after both sides negotiated a cipher suite that was supposed to require them.
While multiple IPMI implementations are at risk, Moore specifically called out the OpenBMC project.
OpenBMC is the shared open-source firmware project used across Supermicro’s newest generation, Nvidia BlueField, Intel, Google and other hyperscalers. Because the code is shared, a bug in the authentication flow does not stay contained to one vendor. It reaches every product built on that codebase at once. The flaw lets an attacker authenticate as any user by deliberately setting an invalid privilege level during the handshake, which causes the session to fall back on a default key built into OpenBMC’s own code instead of the real password.
What network teams should do
While IPMI is vulnerable to multiple exploits, there are things that network teams can do to limit the risk.
- Segment management traffic. Putting BMC traffic on its own VLAN keeps pre-authentication flaws from reaching past one network segment.
- Use a dedicated management NIC. A shared port puts the BMC on the same switch port and access list as the production server, raising the odds of accidental exposure.
- Disable KCS where it is not needed. KCS, or Keyboard Controller Style, is an in-band channel that lets the host operating system talk to its own BMC using IPMI tools with no separate credentials. Leaving it on gives anyone with host root a direct path to the BMC.
- Set unique credentials on every device. Shared or default passwords remain the fastest route to a leaked RAKP hash.
- Favor Redfish over IPMI where possible. Turning off IPMI removes a large share of the attack surface, though the change should be enforced at the network level, not just in the management interface. Redfish is the newer standard for server management.
Alongside the disclosure, runZero released OOBscan, an open-source tool that runs these bypass techniques automatically. It is available on GitHub at https://github.com/runZeroInc/oobscan.
“So you know, from our perspective, we kind of won,” Moore said. “Like the majority of IPMI devices in the world now, you can go from zero to full authentication to take over the boot process to then take over the host OS.”
