SURIQ
The most privileged computer in your rack is the one you never log into. Every enterprise server ships with a baseboard management controller, the small always-on processor behind names like HPE iLO, Dell iDRAC, and Supermicro IPMI. It can power the machine on, mount a virtual disk, and watch the console even while the operating system is off. A scan published this week found 24,650 of these controllers sitting on the public internet, each one willing to hand an authentication hash to any stranger who asks, before a single login prompt appears.
The flaw behind it, CVE-2013-4786, is 20 years old and will never be patched, because the hash disclosure is not really a bug. It is how the IPMI 2.0 protocol proves you know the password. Reading this as "apply the update" is the wrong instinct, because there is no update. The only control is network isolation, and the uncomfortable part is that many operators cannot say where their management controllers even are.
Why a management controller is worse than the host it manages
A baseboard management controller, or BMC, is a separate system on the motherboard with its own processor, memory, network port, and firmware. It runs whether the server is booted or not, and it holds the highest keys in the building: remote power control, keyboard-video-mouse access, and virtual media, which lets an operator boot the machine from a disk image sent over the network. An attacker who owns the BMC can reinstall the operating system, boot a rescue image, or read the console. That is control equal to standing at the rack with a crash cart.
Here is the part defenders keep missing. Your endpoint agent cannot see any of it. The BMC sits beneath the operating system, so the host-based detection you trust on the running server has no window into the controller's logins or actions. A compromise of this plane leaves almost no trace in the place you are actually watching. That is what turns an exposed BMC into a quiet, total loss instead of a noisy one you would catch.
What the scan actually found
The research came from Lava, an infrastructure security firm, with analysis credited to researcher Michael Katchinskiy. The team probed IPMI on UDP port 623 across the internet and found 36,872 exposed management interfaces. Of those, 24,650 returned a password-derived hash to an unauthenticated request. A further 6,240 accepted an empty username paired with a weak password, and 2,340 exposed named default accounts such as ADMIN and root whose passwords match public wordlists. The United States held roughly 39 percent of the vulnerable hosts, about 14,000 systems, with the remaining hosts spread across the United Kingdom, the Netherlands, China, and Germany.
| What the scan found | Count | What it exposes |
|---|---|---|
| Exposed IPMI interfaces on UDP port 623 | 36,872 | A management plane reachable from the open internet |
| Controllers leaking a password hash before login | 24,650 | Material for offline password cracking |
| Accepting an empty username with a weak password | 6,240 | Direct unauthenticated login attempts |
| Exposing named default accounts such as ADMIN and root | 2,340 | Passwords that match public wordlists |
Each row is a different depth of the same failure: a management plane answering to the open internet. The scan did not break in anywhere. It asked, and 24,650 controllers answered.
Why there is no patch to apply
When a client authenticates to IPMI 2.0, the protocol runs an exchange called RAKP. So the client can confirm it reached a genuine server, the server returns an HMAC-SHA1 value computed over the stored account password. The trouble is that an unauthenticated request can trigger that response, so anyone who can reach the port walks away with the material to crack the password offline, at their own pace, with no failed-login lockout in the way. Dell's guidance on the issue is blunt: there is no patch, because the behavior is written into the specification.
This is the mental shift the story asks for. A CVE number usually points at a fix. This one points at a design decision from 2004 that every compliant implementation inherits. You cannot upgrade your way out of it. You can only make the port unreachable and make the offline crack a waste of time. We made a similar point about a Fortinet exposure with no CVE to patch, where the real work was rotating credentials rather than installing anything.
Factory passwords turn a leaked hash into a leaked password
An offline hash is only as strong as the password behind it, and this is where factory defaults compound the exposure. According to Lava's report, Supermicro boards have shipped with a ten-character uppercase factory password printed on a chassis sticker and a username of ADMIN. Other vendors use their own predictable formats. Because the shape of these passwords is known, the search space is small. Lava reported recovering factory passwords offline in anywhere from under a minute on dedicated cracking hardware to about a day on a laptop, depending on the vendor and the gear used. For any controller still on its factory credential, a leaked hash is effectively a leaked password. Default secrets that ship with a product are a recurring soft spot; we saw the same shape when a config server guarded itself with a password printed in its own source.
Get the management plane off the internet
None of this needs a patch, and all of it is standard hardening that too many fleets skipped. Work in this order.
-
Inventory first. You cannot isolate a controller you cannot find. BMCs often pull their own DHCP lease on whatever network they are cabled to, so scan your address ranges for anything answering on UDP port 623 and build a list before you touch a setting.
-
Take them off the internet. Filter UDP port 623 at your perimeter firewall and move every BMC onto a dedicated out-of-band management network or VLAN that is reachable only through a VPN. A management plane should never answer an unauthenticated stranger.
-
Rotate factory credentials. Replace every default password with a long random value. This does not close CVE-2013-4786, but it makes the offline crack that follows a hash leak far more expensive than it is worth.
-
Disable the weak legacy paths. Turn off IPMI 1.5 and any cipher-zero or legacy authentication options the controller still offers.
-
Do not assume Redfish saved you. Moving to Redfish, the modern HTTPS management interface, does nothing if IPMI-over-LAN is left enabled beside it. The old RAKP path stays open until you explicitly turn IPMI off.
The real lesson is inventory, not IPMI
IPMI is the named villain this week, but the pattern is the one that keeps coming back: a privileged management interface reachable from the open internet because nobody was watching that plane. We have written the same story about an exposed management console and about a management appliance rated as low risk that attackers rode to root. The controllers in this scan were not taken by a clever exploit. They were found by a scanner, the same way an attacker finds them. Treat your out-of-band network as the crown jewels it is, send its logs somewhere you can actually see them, and the next internet-wide scan comes up empty on your fleet.