Risks of using IPMI on IBM Power Systems and OpenPower Systems

Various risks that are associated with the Intelligent Platform Management Interface (IPMI) have been identified and documented in the information technology (IT) security community.

IBM® Power Systems and OpenPower Systems provide IPMI access by default. A subset of these identified risks is applicable to IBM servers.
Note: Model 9080-M9S does not provide IPMI access by default.

Vulnerability Details

The IPMI service can become unresponsive after it receives and rejects multiple authentication attempts. You might receive a insufficient resources for session message if you use the IPMI immediately after the failed authentication attempts. This situation lasts for a few seconds and normal service is restored afterward.
Important: Repeated authentication failures can cause denial of service.
A list of common vulnerabilities and exposures (CVE) is listed in Table 1.
Table 1. Common vulnerabilities and exposures
CVE ID Description
CVE-2013-4037

The Remote Authenticated Key-Exchange Protocol (RAKP), which is specified by the IPMI standard for authentication, has flaws. Although the system does not allow the use of null passwords, a hacker might reverse engineer the RAKP transactions to determine a password. The authentication process for IPMI requires the management controller to send a hash of the requested password of the user to the client before the client authenticates. This process is a key part of the IPMI specification. The password hash can be broken by using an offline brute force or dictionary attack.
CVE-2013-4031

IBM Power Systems and OpenPower Systems are preconfigured with one IPMI user account, which has the same default login name and password on all affected systems. If a malicious user gains access to the IPMI interface by using this preconfigured account, the user can power off or on, or restart the host server, and create or change user accounts possibly preventing legitimate users from accessing the system. On OpenPower Systems, the default IPMI user name is root.

Additionally, if a user fails to change the default user name and password on each of the systems that is deployed, the user has the same login information for each of those systems.
CVE-2013-4786

The IPMI 2.0 specification supports RMCP+ Authenticated Key-Exchange Protocol (RAKP) authentication, which allows remote attackers to obtain password hashes and conduct offline password guessing attacks by obtaining the hash-based message authentication code (HMAC) from a RAKP message 2 response from a BMC.

Configuration options and best practices

  • Change the preconfigured user name and password when the server is deployed. This action prevents unauthorized users from gaining access to the system through the preconfigured user account.

  • If a user is not managing a server by using the IPMI, you can configure the system to disallow IPMI network access from the user accounts. This task can be accomplished by using the IPMItool utility or a similar utility for managing and configuring the IPMI management controllers. You can use the following IPMItool command to disable the network access for an IPMI user:

    ipmitool channel setaccess 1 #user_slot# privilege=15
    Note: Replace #user_slot# in the command with the actual slot number (1 - 12) and repeat for each configured user.

    This example shows the command when it is run directly on the server. If the IPMItool command is run remotely over the network, or if a different utility is used, the command might be different. See the documentation for the utility that you are using to determine the correct command syntax. Disallowing IPMI network access removes the ability to use the weakness that is present in the IPMI RAKP protocol to discover user account credentials.

  • Use strong passwords that are at least 16 characters long with a mixture of upper and lowercase letters, numbers, and special characters. By using more complex passwords, it makes it more difficult for malicious users to discover valid user credentials.

  • Keep the management network separate from the public network. Keeping the management network separate lessens security exposures by reducing the number of individuals who can access the systems.