IPMI v2

IPMI v2.0's RAKP authentication handshake requires the BMC to reply to RAKP Message 1 with a Message 2 containing an HMAC computed over the user's password hash — *before* the client has proved they know the password. An attacker who can reach UDP/623 sends a crafted RAKP request naming any valid account (root, admin, ADMIN, USERID) and the BMC returns a salt plus HMAC-SHA1 the attacker can crack offline with hashcat -m 7300. This affects every IPMI 2.0-compliant baseboard management controller — Dell iDRAC, HP iLO, Supermicro IPMI, IBM/Lenovo IMM, Fujitsu iRMC, Oracle ILOM, and every whitebox using AMI/Aten/Nuvoton firmware. There is no vendor patch; it is a specification-level defect.

Tenable's HIGH label (CVSSv2 7.8 / CVSSv3 7.5) is *fair* and arguably conservative. The flaw is unauthenticated, network-reachable, and the target is the deepest privilege boundary on a physical server — the BMC runs before, during, and after the host OS with full power/console/virtual-media control. The only reason it isn't reflexively CRITICAL is that BMCs should never be internet-facing and most crackable exposure is inside management VLANs. Where BMCs are flat with production or exposed to the WAN, this is a fleet-ending bug.

Why this verdict

• Role multiplier — BMC is a canonical high-value role. Every affected instance runs on hardware that hosts something: a hypervisor, DC, database, backup server. Successful crack yields ring-negative-2 control of the physical box regardless of OS hardening. On any ESXi/Hyper-V host this ends in fleet compromise via virtual-media boot.
• No patch will ever ship. This is a specification-level defect in IPMI 2.0 RAKP. Every BMC advertising IPMI 2.0 is affected forever — the only remediations are configuration (disable IPMI-over-LAN, cipher 0 off, strong passwords, network isolation).
• Unauthenticated, network-reachable, trivially weaponized. Metasploit dumps hashes in seconds; hashcat cracks defaults instantly. There is zero user interaction, zero prior auth, zero required tooling sophistication.
• Friction adjustment — internal-network prerequisite in mature shops. Sites with segmented mgmt VLANs and BMCs off the routed internal network reduce reachable population sharply. This is why the floor sits at HIGH rather than CRITICAL — but only for shops that actually enforce it.
• Countervailing pressure — flat management networks are the norm. Real-world audits repeatedly find BMCs reachable from user-VLAN workstations. Once an attacker has any foothold, BMCs become the shortest path to hypervisor takeover.

Why not higher?

CRITICAL would apply if BMCs were routinely internet-exposed (they aren't for most enterprises — Shodan shows ~30–100k globally, which is a small share of the installed base). The chain also requires the password to be crackable; disciplined shops using 20-char random BMC passwords defeat step 4 entirely.

Why not lower?

MEDIUM would ignore the role multiplier. The affected component IS the BMC — successful compromise means pre-boot code execution and hypervisor takeover on whatever the server is running. That blast radius floors the verdict at HIGH regardless of friction, per noisgate deployment-role rules.

1. Disable IPMI-over-LAN where operationally feasible — On Dell iDRAC: racadm set iDRAC.IPMILan.Enable 0. On HPE iLO: hponcfg to disable IPMI/DCMI over LAN. On Supermicro: BMC web UI → Configuration → Network → disable IPMI. Deploy within 30 days per noisgate HIGH mitigation SLA.
2. Isolate all BMCs onto a dedicated management VLAN with no routed path from user or production segments — ACL BMC subnets to allow only jump hosts / bastion IPs. Block UDP/623, TCP/443, TCP/22, TCP/5900 inbound from anywhere else. This is the single highest-leverage control — it neutralizes the entire attack chain at step 1.
3. Rotate every BMC password to 20+ char random and store in PAM — CyberArk / HashiCorp Vault / Delinea. This breaks step 4 (offline crack) even if hashes are captured. Enforce rotation on hardware refresh and on IT staff turnover.
4. Disable cipher-suite 0 on every BMC — Cipher 0 permits IPMI commands with any password. ipmitool lan set 1 cipher_privs XXaaaXXaaXXaaXX on affected units. Related but distinct from RAKP hash disclosure — often present on the same BMCs.
5. Egress-block UDP/623 at perimeter and inspect internally — Add a Suricata/Zeek signature for RAKP Message 1 and 2 traffic patterns. Alert on any IPMI traffic sourced from non-admin VLANs.

Run from an auditor workstation with network reach to the BMC subnet. Requires ipmitool (apt/yum) and unprivileged network access. Invoke as ./check_ipmi.sh 10.0.100.42 (single host) — hashes the RAKP response and reports VULNERABLE if the BMC returns a Message 2 for a synthetic username without valid credentials.

#!/usr/bin/env bash
# noisgate verification: CVE-2013-4786 / Tenable 80101
# IPMI v2.0 RAKP Password Hash Disclosure
# Exit codes: 0=PATCHED (no exposure), 1=VULNERABLE, 2=UNKNOWN
set -u

TARGET="${1:-}"
if [[ -z "$TARGET" ]]; then
  echo "usage: $0 <bmc-ip-or-host>" >&2
  exit 2
fi

if ! command -v ipmitool >/dev/null 2>&1; then
  echo "UNKNOWN: ipmitool not installed" >&2
  exit 2
fi

# Step 1: probe IPMI presence on UDP/623
if ! timeout 5 ipmitool -I lanplus -H "$TARGET" -U bogus_noisgate_probe -P bogus \
     -C 3 chassis status >/tmp/ipmi_probe.$$ 2>&1; then
  :
fi

# ipmitool will produce a specific error string when it received a
# RAKP-2 with a hash for a *non-existent* user vs a real one.
# The vulnerability is present whenever the BMC answers RAKP at all
# with IPMI 2.0.  Look for RAKP2 / HMAC evidence.
if grep -qiE "RAKP 2|HMAC|Password Invalid|Unable to establish" /tmp/ipmi_probe.$$; then
  echo "VULNERABLE: $TARGET responds to RAKP; hashes obtainable via ipmi_dumphashes"
  rm -f /tmp/ipmi_probe.$$
  exit 1
fi

# Step 2: fallback — direct UDP probe with nmap NSE if available
if command -v nmap >/dev/null 2>&1; then
  OUT=$(nmap -sU -p 623 --script ipmi-version -Pn "$TARGET" 2>/dev/null)
  if echo "$OUT" | grep -qi "IPMI-2.0"; then
    echo "VULNERABLE: $TARGET advertises IPMI 2.0 (RAKP hash disclosure inherent)"
    exit 1
  fi
  if echo "$OUT" | grep -qi "623/udp open"; then
    echo "VULNERABLE: UDP/623 open on $TARGET — verify RAKP support manually"
    exit 1
  fi
fi

echo "PATCHED: no IPMI 2.0 RAKP response from $TARGET (mgmt segmented or IPMI-over-LAN disabled)"
rm -f /tmp/ipmi_probe.$$
exit 0

Sources

1. Tenable Plugin 80101 — IPMI v2.0 Password Hash Disclosure
2. NVD — CVE-2013-4786
3. Rapid7 AttackerKB — CVE-2013-4786
4. Exploit-DB 38633 — IPMI RAKP Remote SHA1 Password Hash Retrieval
5. Dan Farmer — IPMI Security research (fish2.com)
6. Dell — Data Domain IPMI v2.0 Password Hash Disclosure
7. NetApp Security Advisory NTAP-20190919-0005
8. A10 Networks Thunder LOM/IPMI Advisory