The flaw here is in the IPMI 2.0 specification itself, not a given implementation. The RAKP (RMCP+ Authenticated Key-Exchange Protocol) handshake has the BMC return, in RAKP message 2, a salted HMAC computed over the requested user's password, before the client has proven anything. So an attacker who initiates the exchange for a username receives a hash of that account's password and cracks it offline. Because it is specification-mandated, essentially every BMC speaking IPMI 2.0 is affected: an unauthenticated attacker retrieves a crackable password hash for root and any other account, and weak BMC passwords (common) fall quickly.
# retrieve the RAKP hash for a user and crack it offline
# Metasploit module automates the RAKP exchange and outputs a hash
# auxiliary/scanner/ipmi/ipmi_dumphashes (RHOSTS, USER_FILE)
# the output is a crackable format:
# <user>:<16-byte salt/exchange data>:<HMAC> -> feed to hashcat mode 7300 (IPMI2 RAKP)
hashcat -m 7300 ipmi_rakp.hashes wordlist.txt
Exploitation notes#
- This is pre-authentication and specification-level, so it applies to almost all IPMI 2.0 BMCs; the attacker needs only to know or guess usernames (
root,ADMIN,adminare near-universal) to request their hashes. - The retrieved value is a salted HMAC crackable offline (hashcat mode 7300); BMC passwords are frequently defaults or weak, so cracking commonly succeeds.
- A cracked BMC password gives authenticated administrative control of the controller (power, console, virtual media), the same impact as the cipher 0 bypass but via a recovered credential.
- Enumerate usernames first (defaults and any disclosed); combine with BMC default credentials (the cracked password is often a default anyway) and cipher 0.