IPMI cipher suite zero authentication bypass means a server’s management controller (BMC) accepts IPMI 2.0 logins over cipher suite 0, which skips the password check. Anyone reaching UDP 623 with a valid account name, such as the default admin, gets full BMC control. Fix it by updating BMC firmware, marking cipher 0 unused, and disabling unneeded IPMI over LAN.
The finding usually arrives next to a second one, IPMI v2.0 Password Hash Disclosure (CVE-2013-4786). That one has no patch because it is part of the IPMI 2.0 specification, so the fix is to limit who can reach UDP 623 and make any leaked hash useless.
What the scanner is actually detecting
Both findings concern the IPMI 2.0 (RMCP+) service that a BMC such as Dell iDRAC, HPE iLO, Lenovo XClarity Controller (XCC) or a Supermicro controller exposes on UDP port 623. They are separate checks with different fixes.
| Finding title | Scanner and ID | CVE | Fixable by patch? |
|---|---|---|---|
| IPMI Cipher Suite Zero Authentication Bypass | Nessus 68931 | CVE-2013-4782, CVE-2013-4783, CVE-2013-4784, CVE-2014-2955 | Yes, firmware or configuration |
| IPMI v2.0 Password Hash Disclosure | Nessus 80101 | CVE-2013-4786 | No, it is specification behavior |
Nessus 68931 tries to open an IPMI session with cipher suite 0 against several common account names. Tenable’s plugin text says cipher suite zero “permits logon as an administrator without requiring a password”. Its CVEs cover Supermicro, Dell iDRAC6 and iDRAC7, HP iLO and a Raritan PX power distribution unit. Greenbone/OpenVAS reports the same weakness under OID 1.3.6.1.4.1.25623.1.0.103840, and Nmap’s ipmi-cipher-zero NSE script (categories vuln and safe) performs the equivalent test.
Nessus 80101 fires on any host that speaks IPMI 2.0. During the RMCP+ Authenticated Key-Exchange Protocol (RAKP), the BMC returns an HMAC derived from the user’s password in RAKP message 2, before the client has proven anything. Anyone who supplies a valid user name can collect that value and try to crack it offline.
Real-world risk
A BMC is out-of-band management: it can power the server off and on, open the remote console, boot from virtual media and change its own firmware, independently of the host operating system. With cipher zero enabled, an attacker who can reach UDP 623 needs only an account name to get that control. Tenable scores 68931 at CVSS v3 10.0.
The hash disclosure is less direct. The attacker still needs network reach and a valid user name, and the result is only as useful as the password is weak. Tenable scores 80101 at CVSS v3 7.5. Short or default BMC passwords are realistic to crack offline; long random ones are not.
Context matters more than the score. A BMC on an isolated management VLAN, reachable only from a few admin hosts, is a much smaller problem than one reachable from the user LAN or the internet. Dell’s response to CVE-2013-4783 made the same point: DRACs are meant to sit on a separate management network, so verify that isolation first.
How to confirm it on the host
From a machine that can reach the BMC, check the IPMI version and the cipher zero condition with Nmap:
nmap -sU -p623 --script ipmi-version <bmc-ip>
nmap -sU -p623 --script ipmi-cipher-zero <bmc-ip>
A VULNERABLE state from ipmi-cipher-zero confirms 68931. An ipmi-version result showing IPMI-2.0 is all that 80101 needs.
To prove the bypass on a BMC you own, request a privileged command with cipher suite 0 and a deliberately wrong password. If the user table comes back, the finding is real:
ipmitool -I lanplus -C 0 -H <bmc-ip> -U admin -P not-the-real-password user list
On the server itself, with the OpenIPMI driver loaded, read the LAN channel configuration in-band. Channel 1 is common but not universal; ipmitool lan print without a channel prints the first LAN channel it finds.
ipmitool lan print 1
ipmitool channel getciphers ipmi 1
In the lan print output, the Cipher Suite Priv Max line is a 15-character string where the first character is cipher suite 0. Anything other than X in that first position means cipher 0 is usable.
How to fix it
Step 1: Update the BMC firmware
Several vendors fixed cipher zero in firmware. For example, CVE-2013-4783 affects iDRAC6 firmware 1.x before 1.92 and 2.x and 3.x before 3.42, and iDRAC7 firmware before 1.23.23. Apply your vendor’s current BMC firmware first, then check the setting, since the fix and the defaults vary by release.
Step 2: How to disable IPMI cipher 0 with ipmitool
The standard way is ipmitool lan set <channel> cipher_privs. Per the ipmitool manual, each character of the 15-character list sets the maximum privilege for one cipher suite, starting with suite 0: X means unused, c callback, u user, o operator, a admin and O OEM.
- Save the current configuration:
ipmitool lan print 1 > bmc-lan-before.txt - Copy the existing Cipher Suite Priv Max string and change only its first character to X. For example, if the current value is aaaaXXaaaXXaaXX, the new value is XaaaXXaaaXXaaXX. Do not paste a string from another server, since the other positions differ by vendor and model.
- Apply it, preferably in-band from the host OS so you cannot cut off your own session:
ipmitool lan set 1 cipher_privs XaaaXXaaaXXaaXX - Run ipmitool lan print 1 again and confirm the first character is now X.
Remotely, connect with a suite you are keeping (for example -I lanplus -C 3) and never mark that suite X.
Step 3: Disable IPMI over LAN on iDRAC, iLO and XCC where it is not needed
If nothing needs network IPMI, turning it off closes both findings.
- Lenovo XCC: BMC Configuration, then Network, and switch off IPMI over LAN. Lenovo documents that it is disabled by default and recommends keeping it off unless a tool needs it.
- Dell iDRAC: clear the Enable IPMI Over LAN option in the IPMI settings of the iDRAC network configuration.
- HPE iLO: turn off IPMI/DCMI over LAN in the iLO access settings. On iLO 5 and later the Redfish property is IPMI/ProtocolEnabled.
- Any Redfish-capable BMC: the DMTF ManagerNetworkProtocol resource has a writable IPMI.ProtocolEnabled property. Find the manager’s NetworkProtocol link, then patch it:
curl -k -u <bmc-admin> https://<bmc-ip>/redfish/v1/Managers
curl -k -u <bmc-admin> -X PATCH -H "Content-Type: application/json"
-d '{"IPMI": {"ProtocolEnabled": false}}'
https://<bmc-ip>/redfish/v1/Managers/<manager-id>/NetworkProtocol
curl prompts for the password. Some BMCs also require an If-Match header with the resource ETag; check your vendor’s Redfish guide. Without Redfish, ipmitool lan set 1 access off turns off LAN channel access.
Step 4: CVE-2013-4786 mitigation: isolate UDP 623 and harden BMC accounts
Where IPMI over LAN must stay on, for example for cluster fencing or bare-metal provisioning, treat the hash disclosure as a permanent property and reduce its value:
- Put BMC interfaces on a dedicated management VLAN and allow UDP 623 only from the specific hosts that need it, using switch or firewall ACLs.
- Give every BMC a long, random, unique password so one cracked hash does not unlock the fleet. IPMI 2.0 passwords are limited to 20 bytes, so use the full length.
- Disable or rename well-known default accounts where the vendor allows it, since the attacker needs a valid user name to get a hash.
- Be careful with ipmitool user set password <userid>: per the manual, omitting the password clears it. The BMC web interface keeps passwords out of shell history.
How to verify the fix and rescan
- Rerun nmap -sU -p623 –script ipmi-cipher-zero <bmc-ip>. It should no longer report VULNERABLE.
- Rerun the ipmitool -I lanplus -C 0 test from above. It should fail instead of listing users.
- If you disabled IPMI over LAN, ipmi-version should get no IPMI response on UDP 623.
- Rescan with Nessus or Greenbone/OpenVAS and make sure the scan policy covers UDP 623, or the finding goes quiet without being fixed. Expect 80101 to stay open wherever IPMI over LAN is still enabled; record it as a risk acceptance with isolation and passwords as compensating controls.
- Recheck after BMC firmware updates or a factory reset.
What can break and how to roll back
| Change | What may break | Rollback |
|---|---|---|
| Cipher 0 marked unused | Tools hardcoded to -C 0, which is rare | Write back the original string saved in bmc-lan-before.txt |
| IPMI over LAN disabled | Cluster fencing agents such as fence_ipmilan, bare-metal provisioning, IPMI-based hardware monitoring, scripted remote power control | Re-enable in the web UI, via Redfish, or with ipmitool lan set 1 access on in-band |
| BMC firmware update | BMC reboots and remote console drops during the update; some settings may reset | Follow the vendor’s firmware rollback procedure where one exists |
Check for fencing before disabling IPMI over LAN: a cluster that cannot fence a failed node may stop failing over. The BMC web interface, Redfish and SSH are separate services and keep working.
Common false positive reasons
- 80101 is rarely a false positive. IPMI 2.0 support is the vulnerable condition, so it clears only when IPMI over LAN is off or unreachable.
- Wrong asset attribution. A BMC has its own IP even when it shares a physical port with the host, so it often shows up as an unknown device. Orphaned assets with no clear owner keep findings open because nobody claims them.
- Stale results. The scan predates the fix, or the rescan policy skipped UDP 623.
- Non-server devices. PDUs, KVM switches and storage appliances embed BMCs too. The finding is real, but treat them with the care you would use when scanning fragile OT devices.
FAQ
Is there a patch for CVE-2013-4786?
No. The hash disclosure is how RAKP works in the IPMI 2.0 specification. Mitigate it by disabling IPMI over LAN, restricting UDP 623 and using long, unique BMC passwords.
Does disabling cipher suite 0 also fix the password hash disclosure?
No. Disabling cipher 0 closes Nessus 68931 only. Nessus 80101 remains as long as the BMC answers IPMI 2.0 on the network.
Will disabling IPMI over LAN turn off the iDRAC or iLO web console?
No. IPMI over LAN is a separate service on UDP 623. The web interface, Redfish API and SSH keep working.
Which cipher suites should stay enabled?
Keep the suites your tools use. The ipmitool manual describes suite 3 as RAKP-HMAC-SHA1 authentication, HMAC-SHA1-96 integrity and AES-CBC-128 encryption; suite 0 has none of these.
Tracking this finding across many hosts
On a large fleet, the hard part is knowing which of dozens of BMCs are actually fixed. SITEY, a self-hosted vulnerability management platform, can launch OpenVAS scans directly and import Nessus results from an uploaded .nessus export, and it can re-test an individual Nessus finding such as 68931 after you change a BMC. Duplicates are merged per scanner, so a BMC reported by both Nessus and OpenVAS still appears as two findings.