IBM Integrated Management Module (IMM/IMM2) IPMI 2.0 RAKP implementation: The vendor-acknowledged instance of the IPMI

Impact

The vendor-acknowledged instance of the IPMI 2.0 RAKP design flaw. The BMC hands the salted HMAC of any named account's password to an unauthenticated client as part of the session-setup exchange - this is what the specification tells it to do, not a coding mistake. An attacker asks for the hash of the admin account, cracks it offline at leisure with no lockout, no rate limit and no log entry on the BMC, and comes back with a real credential. In a datacenter where BMC passwords are provisioned from a common template or a per-rack scheme, cracking one recovers many, which turns a single reachable BMC into fleet-wide out-of-band control.

Who can reach it

Network, pre-auth, UDP/623 (IPMI-over-LAN). Requires only the ability to send RAKP messages to the BMC and knowledge or guessing of an account name.

What to do

Firmware update mitigates the vendor-specific handling but does not repair the protocol - RAKP hash disclosure is inherent to IPMI 2.0 authentication, so any BMC still speaking IPMI-over-LAN retains the exposure. The durable controls are structural: disable IPMI-over-LAN entirely and manage out-of-band through the vendor's authenticated HTTPS/Redfish interface; where IPMI must stay on, use long random per-device passwords generated by a secrets manager so offline cracking fails and one recovered credential unlocks exactly one node; and keep UDP/623 unreachable from anything but the management bastion. Treat this as mitigate-only rather than patchable.

References