A critical vulnerability in the Intelligent Platform Management Interface (IPMI) protocol, dating back 22 years to its inception, has left approximately 24,000 servers exposed to offline password cracking attacks. The flaw allows unauthenticated attackers to retrieve password hashes during the RAKP authentication handshake, enabling them to crack administrator credentials offline without triggering login attempt alerts. Organizations using IPMI-enabled baseboard management controllers (BMCs) face significant risks of unauthorized remote access and complete server compromise.
Introduction
Server management interfaces are supposed to be the keys to the kingdom—secured, monitored, and protected. Yet a decades-old design flaw in IPMI has been hiding in plain sight, exposing thousands of enterprise servers to a remarkably simple attack vector. The vulnerability isn’t the result of a coding error or recent software update gone wrong; it’s baked into the protocol specification itself.
Recent scans have identified approximately 24,000 internet-facing IPMI interfaces vulnerable to password hash extraction attacks. What makes this particularly concerning is that IPMI provides direct hardware-level access to servers, including remote power control, console access, and firmware management. In the wrong hands, compromised IPMI credentials represent a complete system takeover—no operating system-level defenses can prevent it.
The flaw affects IPMI versions 2.0 and earlier, which remain widely deployed in data centers, enterprise environments, and cloud infrastructure worldwide. Despite being documented for years, many organizations have failed to properly secure their BMC interfaces, leaving them exposed to internet-based reconnaissance and exploitation.
Background & Context
IPMI was developed in the late 1990s by Intel, HP, Dell, and NEC to provide standardized, hardware-level management of servers independent of the operating system. Version 1.0 was released in 1998, with version 2.0 following in 2004. The protocol enables remote server management through baseboard management controllers—specialized processors embedded in server hardware.
The authentication mechanism at the heart of this vulnerability is RAKP (RMCP+ Authenticated Key-Exchange Protocol), introduced in IPMI 2.0 to improve upon the weak security of version 1.0. Ironically, while RAKP was designed to enhance security, its implementation contains a fundamental flaw that actually exposes password hashes to anyone who can reach the BMC network interface.
During the RAKP authentication handshake, the BMC responds to authentication requests with a message containing the password hash before the client proves they know the password. This “authenticate-then-verify” approach means an attacker can initiate authentication attempts and collect valid password hashes without completing the login process or leaving obvious traces in authentication logs.
The issue has been documented in security research for over a decade, with tools like Metasploit incorporating IPMI hash dumping modules. However, widespread exposure persists due to misconfigurations, legacy deployments, and insufficient security awareness among infrastructure teams.
Technical Breakdown
The vulnerability exploits the RAKP authentication handshake sequence in IPMI 2.0. Here’s how the attack works:
Step 1: Discovery
Attackers scan for UDP port 623, the default IPMI port, or TCP port 623 for RMCP+ implementations. A simple probe reveals whether IPMI is present and responding.
nmap -sU -p 623 --script ipmi-version Step 2: Hash Extraction
The attacker initiates a RAKP authentication request with any valid or guessed username (commonly “admin”, “root”, or “ADMIN”):
ipmitool -I lanplus -H -U admin -P '' user list Even with an incorrect password, the BMC responds with RAKP Message 2, which contains:
- A session ID
- Random numbers for session establishment
- A HMAC-SHA1 hash derived from the password
The hash is computed as: HMAC-SHA1(password, session_data)
Step 3: Offline Cracking
With the hash captured, attackers can perform unlimited offline cracking attempts using tools like Hashcat or John the Ripper:
hashcat -m 7300 ipmi_hashes.txt wordlist.txtThe attack succeeds without:
- Triggering account lockouts
- Generating failed login alerts
- Creating audit trail entries
- Requiring continued network access
Step 4: Exploitation
Once cracked, credentials provide complete hardware control:
- Remote power management (power on/off/reset)
- Serial-over-LAN console access
- Virtual media mounting
- Firmware manipulation
- Sensor and event monitoring
Impact & Risk Assessment
The impact of this vulnerability extends far beyond typical authentication bypass scenarios:
Critical Infrastructure Access: IPMI provides hardware-level control that bypasses all operating system security controls, including firewalls, intrusion detection systems, and access controls. Compromised credentials grant attackers god-mode access.
Stealth and Persistence: Because the hash extraction occurs outside normal authentication flows, defenders often remain unaware of the reconnaissance. Attackers can crack passwords at their leisure without alerting security teams.
Lateral Movement: IPMI access in one server can facilitate attacks across entire data center environments, particularly when default or shared credentials are used across multiple systems.
Supply Chain Implications: The vulnerability affects hardware from virtually every major server manufacturer—Dell iDRAC, HP iLO, Supermicro IPMI, Lenovo XClarity, and others—making it a widespread, cross-vendor issue.
Exposure Scale: The 24,000 currently exposed systems represent only internet-facing instances. Internal network deployments likely number in the hundreds of thousands globally.
Risk Factors Amplifying Impact:
- Weak password policies on BMC interfaces
- Shared credentials across multiple servers
- Lack of network segmentation for management interfaces
- Insufficient monitoring of BMC access
- Legacy systems that cannot be easily updated
Vendor Response
Server manufacturers have responded to this issue with varying degrees of urgency and effectiveness:
Dell: Recommends disabling IPMI 2.0 RAKP authentication in favor of RAKP+ on iDRAC controllers. Provides configuration guidance for network isolation and strong authentication.
HP/HPE: iLO firmware includes options to disable cipher suite 0, which is most vulnerable to hash extraction. Recommends iLO security best practices including network isolation.
Supermicro: Advises customers to isolate BMC interfaces on dedicated management networks and implement strong password policies. Newer firmware versions include enhanced security options.
Lenovo: Documentation emphasizes network-level controls and access restrictions for XClarity controllers.
The fundamental challenge is that the flaw exists in the IPMI protocol specification itself. While vendors can provide configuration options and workarounds, truly fixing the issue would require a new protocol version—which has essentially happened through vendor-specific implementations like Redfish, though IPMI remains widely deployed.
Mitigations & Workarounds
Organizations can substantially reduce risk through multiple defensive layers:
Network Isolation (Most Critical):
# Ensure BMC interfaces are on isolated management VLANs
# Block IPMI ports at perimeter firewalls
iptables -A INPUT -p udp --dport 623 -s -j ACCEPT
iptables -A INPUT -p udp --dport 623 -j DROP Disable IPMI 2.0 Where Possible:
Configure BMCs to use more secure authentication methods or disable RAKP authentication entirely if supported by your hardware.
Strong Password Requirements:
Implement minimum 16-character passwords with complexity requirements for all BMC accounts. Use password managers to generate and store these credentials.
Disable Cipher Suite 0:
ipmitool lan set 1 cipher_privs XXaXXXXXXXXXXXXThis disables the weakest cipher suite most susceptible to hash extraction.
Access Controls:
- Limit BMC access to specific IP addresses
- Implement jump hosts for management access
- Use VPNs for remote management connectivity
- Deploy network access control (NAC) on management networks
Account Management:
- Disable default accounts
- Use unique credentials per server
- Implement privileged access management (PAM) solutions
- Enable multi-factor authentication where supported
Detection & Monitoring
Identifying potential exploitation requires monitoring at multiple levels:
Network-Level Detection:
# Monitor for IPMI discovery scans
tcpdump -i any port 623 -w ipmi_traffic.pcapUnusual patterns to investigate:
- Multiple RAKP session initiation attempts
- IPMI traffic from unexpected source IPs
- High volumes of UDP 623 traffic
- Authentication attempts outside maintenance windows
SIEM Correlation Rules:
- Alert on successful IPMI logins after periods of inactivity
- Correlate IPMI access with privileged operations
- Flag authentication from new geographic locations
- Monitor for virtual media mounting events
BMC Audit Logs:
Regularly review BMC logs for:
- Successful authentication events
- Configuration changes
- Power management operations
- Virtual media sessions
- Firmware updates
Scanning Your Environment:
# Identify IPMI-enabled systems internally
nmap -sU -p 623 --script ipmi-version
# Check for cipher suite 0 vulnerability
ipmitool -I lanplus -H -U '' -P '' cipher info
Best Practices
Comprehensive IPMI security requires ongoing operational discipline:
Architecture:
- Deploy management interfaces on physically separate networks
- Use dedicated management network hardware
- Implement zero-trust principles for management access
- Segment BMC networks from production environments
Operational Security:
- Conduct regular audits of BMC configurations
- Inventory all IPMI-enabled devices
- Document authorized access patterns
- Test password strength against common cracking techniques
- Rotate BMC credentials on a defined schedule
Governance:
- Establish formal BMC security policies
- Include BMC access in privileged access programs
- Define change management procedures for BMC configurations
- Require security review before BMC network changes
Modernization:
- Evaluate migration to Redfish API where possible
- Plan hardware refresh cycles considering BMC security
- Prioritize vendors with strong security track records
- Test BMC security features before procurement
Incident Response:
- Include BMC compromise scenarios in IR playbooks
- Define procedures for BMC credential resets
- Establish out-of-band communication channels
- Plan for hardware-level forensics if needed
Key Takeaways
- A 22-year-old design flaw in IPMI 2.0 allows unauthenticated password hash extraction during the RAKP authentication handshake
- Approximately 24,000 internet-facing servers remain exposed, with likely hundreds of thousands more on internal networks
- Offline password cracking bypasses all traditional defenses like account lockouts and intrusion detection
- IPMI access provides complete hardware-level control, bypassing operating system security
- Network isolation is the most effective mitigation—BMC interfaces should never be internet-accessible
- Strong passwords, disabled cipher suite 0, and restricted access significantly reduce risk
- The flaw cannot be fully patched without protocol replacement; defense-in-depth is essential
- Regular monitoring and auditing of BMC access patterns enables detection of compromise attempts
References
- IPMI Specification v2.0: https://www.intel.com/content/www/us/en/products/docs/servers/ipmi/ipmi-second-gen-interface-spec-v2-rev1-1.html
- Metasploit IPMI Module Documentation
- National Vulnerability Database – IPMI-related CVEs
- Dell iDRAC Security Best Practices Guide
- HP iLO Security Configuration Guide
- Rapid7 IPMI Hash Cracking Research
- NIST SP 800-123: Guide to General Server Security
Stay updated at https://cydhaal.com — Your Daily Dose of Cyber Intelligence.
📧 Subscribe to our newsletter at https://cydhaal.com/newsletter/
