Guest

IPMI Security Vulnerabilities

Contents

Overview
Security Vulnerabilities
      IPMI Usernames and Passwords
         Tech Support Collection
         Improvements
      One IPMI Password Gives Access to All Servers in IPMI-Managed Group
      Root Access on an IPMI-Managed Device Grants Complete Control
         Remote Serial Console Access
         User Privileges
         Root Access and Hardware
      BMCs Often Run Excess and Older Network Services That May Be Vulnerable
         Improvements
      IPMI Access May Grant Remote Console Access to the System, Resulting in Access to the BIOS
      Few Monitoring Tools Are Available to Detect if the BMC is Compromised
      Unclear Documentation on How to Sanitize IPMI Passwords Without Destroying the Motherboard
      Certain Types of Traffic To and From the BMC Are Not Encrypted
         Cipher Suite 0
         Cipher Suites 1–14
         Default Settings
         IPMI Configuration
         Improvements
         Reset to Factory Defaults
Glossary
References

Overview

In July 2013, the U.S. government and several independent researchers have described several security vulnerabilities in the Intelligent Platform Management Interface (IPMI) specification. The Cisco IPMI implementation diverges from this public specification in some areas. This document addresses the security concerns described by the U.S. government and other independent researchers for both Cisco UCS B-Series Blade Servers and the Cisco UCS C-Series Rack Servers.

Security Vulnerabilities

The United States Computer Emergency Readiness Team (US-CERT) issued an alert (TA13-207A) on July 26, 2013, warning of the risk of IPMI. The alert summarizes several IPMI security vulnerabilities and offers possible solutions. This section addresses the various risks outlined in the alert and offers solutions, if necessary, to avoid, minimize, or eliminate the risks.

The Cisco UCS C-Series servers have two modes of operation: Unified Computing System Manager (UCSM) mode and standalone mode. Please consult the Cisco UCS C-Series documentation for details on each mode. Unless stated otherwise, comments or data referring to Cisco UCS C-Series applies to both modes.

IPMI Usernames and Passwords

In various companies, often a single username and password authenticate against numerous services and applications. Thus, IPMI usernames and passwords are often the same usernames and passwords used to log into other services at the same company. The alert and various researchers claim that servers containing a baseboard management controller (BMC) often store the username and password databases locally on the non-volatile memory of the BMC. Furthermore, these databases are often stored unencrypted. If attackers had physical access, or gained access to the BMC's username and password, they would also gain access to numerous services as those users.

In the Cisco UCS B-Series Blade Server, a copy of the IPMI database is stored locally and unencrypted, and is sent down by UCSM where it is securely stored. However, that data is volatile on the Cisco Integrated Management Controller (IMC). If the blade server is removed from the chassis or the power is lost to the entire server, this database is lost as well. Thus, if the user returns the server to Cisco for any reason, that data would be lost. The original username and password database is stored at the Fabric Interconnect (FI) level in non-volatile memory. The FI storage method depends on the configuration of UCSM. The username and password data is either encrypted in the FI database using either a symmetric key algorithm or the standard Linux /etc/shadow methodology.

In the Cisco UCS C-Series, the usernames and passwords are stored in non-volatile memory but the password is encrypted using a symmetric key algorithm. Finally, in standalone Cisco UCS C-Series server, the default administrator username and password should be changed.

Tech Support Collection

In Cisco UCS C-Series servers only, the collection of tech support also gathers the username and database information. Although this database is encrypted, the customer may still not like this information leaving the Cisco IMC.

In UCSM, tech support collection also grabs the username and password information but the passwords are sanitized. The username appears in a text file. It does not gather the FI database. The following options are currently available for such a circumstance (not in any particular order):

  • Deliver the tech support as is but force all users whose names are in the FI database for UCSM mode or locally to that server's Cisco IMC for standalone Cisco UCS C-Series to change their passwords.
  • Do not gather tech support. This severely hinders the ability for Cisco to troubleshoot the reported issue.
  • Remove the username and database in the tech support file before delivery.

Modifying the Tech Support File

To remove the username and password information in the tech support file, complete the following steps according to the operating system. These steps assume tech support has already been collected. Please see the appropriate server user guide for details on tech support collection.

Cisco UCS C-Series Cisco IMC Tech Support: Linux-Based Operating System
In a Linux shell, complete the following steps:

  1. mkdir temp;
  2. tar –xf $(tech_support_file_name).tar –C temp
  3. cd temp
  4. rm –f $(tech_support_filename)/mnt/jffs2/avct_ems_cfg/etc/avctpasswd
  5. tar –cf $(tech_support_file_name).modified.tar –C temp
  6. Deliver $(tech_support_file_name).modified.tar

Cisco UCS C-Series Cisco IMC Tech Support: Windows-Based Operating System
Several third-party tools can interpret a TAR file (for example, WinRAR and 7-Zip); however, the use of these tools is outside the scope of this document.

  1. Open the TAR file using one of these third-party tools.
  2. Locate the username and database information under mnt/jffs.
  3. Delete the file.
  4. Re-create the TAR file or save the changes.
  5. Deliver the modified file.

UCSM Tech Support: Linux-Based Operating System
In a Linux shell, complete the following steps:

  1. tar –xf $(ucsm-tech-support).tar;
  2. cd $(ucsm-tech-support-file)
  3. mkdir A;
  4. mkdir B;
  5. tar –xf UCSM_A_TechSupport.tar.gz –C A
  6. tar –xf UCSM_B_TechSupport.tar.gz –C B; if this tar file is present
  7. cd
  8. Open sw_techsupportinfo with a text editor.
  9. Search for username. If found, remove any sensitive information.
  10. Save the file as: sw_techsupportinfo.modified
  11. Open sam_techsupportinfo with a text editor.
  12. Search for show local-user detail.
  13. Remove any sensitive user information.
  14. Save the file as: sam_techsupportinfo.modified
  15. Close all files.
  16. rm –f sw_techsupport_info sam_techsupportinfo;
  17. cd ..
  18. cd B;
  19. Change to B directory and repeat steps 8 through 16.
  20. cd ..
  21. echo "Customer modified tech support file to remove sensitive user information." >> ATTENTION.txt
  22. cd ..
  23. tar –xf $(ucsm-tech-support).modified.tar –C $(usm-tech-support)
  24. Deliver the modified file to Cisco: $(ucsm-tech-support).modified.tar

UCSM Tech Support: Windows-Based Operating System
As aforementioned, several third-party tools can interpret a TAR file; however, the use of these tools is outside the scope of this document.

  1. Open the TAR file and extract it to a directory of the same name.
  2. Open UCSM_A_TechSupport.tar.gz found in the extracted directory and extract the file to a subfolder named A.
  3. Open UCSM_B_TechSupport.tar.gz if found in the extracted directory. Extract the file to a subfolder named B.
  4. In subfolder A, open sw_techsupportinfo with a text editor.
  5. Search for username. If found, remove any sensitive information.
  6. Save the file as: sw_techsupportinfo.modified
  7. Open sam_techsupportinfo with a text editor.
  8. Search for show local-user detail.
  9. Remove any sensitive user information.
  10. Save the file as: sam_techsupportinfo.modified
  11. Close all files.
  12. Remove the original sw_techsupportinfo and sam_techsupport_info.
  13. Change to subfolder B and repeat steps 5 through 12.
  14. Remove UCSM_A_Techsupport.tar.gz and UCSM_B_Techsupport.tar.gz.
  15. Create a file named ATTENTION. In that file, state the "Customer removed sensitive user information in tech support."
  16. Create the TAR file again and name it $(UCSM_techsupport).modified.tar.

Improvements

Cisco continually strives to improve its products and security. Cisco bug ID CSCuj13125 has been filed against the Cisco UCS C-Series server and Cisco bug ID CSCuj23543 against UCSM for gathering such information. Cisco bug ID CSCuj13203 has been filed against the Cisco UCS B-Series server to enhance the protection of usernames and passwords stored on the Cisco IMC.

One IPMI Password Gives Access to All Servers in IPMI-Managed Group

Many companies' infrastructures allow a user to access various services with a single username and password. The "IPMI Usernames and Passwords" section highlights that vulnerability. That vulnerability, however, is not IPMI specific and can be applied to many companies' use of a single password for a user to access multiple services.

Best practices advise that usernames and passwords used for management purposes should be different from those used for daily activities. Passwords should be sufficiently long and complex. A best practice for IPMI would be to use 20 characters, which is the maximum allowed.

Using the same concept, for a standalone Cisco UCS C-Series server, a different password can be assigned to each server for a given user. For UCSM C-Series or B-Series, depending on the configuration of UCSM, each UCS system can be given different passwords for each system.

An alternative is to expire a user password more frequently. There are many solutions; however, because this issue is not IPMI specific and not an IPMI-only issue, the solution is outside the scope of this document.

Root Access on an IPMI-Managed Device Grants Complete Control

Root access on any system gives full and unlimited control to the system's software and hardware. Root-level access has been an industry standard in many software applications such as Linux-based operating systems. The issue here specifically relates to IPMI-managed devices. Although IPMI has been around for a while, the goal of IPMI as intended was to manage both the physical and software aspect of the server, remotely and locally. The physical aspect requires certain control of the hardware to perform tasks such as environmental monitoring. The software aspect provides control often between the BIOS and the operating system such as a watchdog timer to detect a hang on the host side and to respond as specified by user action. Thus, IPMI requires software and hardware control.

This section discusses IPMI privilege levels and certain IPMI important remote management features.

Remote Serial Console Access

The advent of remote management, like IPMI, begins to close the gap between host-side operations and server-management operations. Consequently, this could blur the line for security, or present security vulnerabilities where none existed before. In general, the solution is often to enable existing security features.

One such feature of remote management in IPMI is Serial over LAN (SOL) where access to the server's physical serial port is routed over the network to ease customer's IT management of the server. IPMI administrative-level access will have access to this serial port. Depending on which operating system is installed on the host side and the configuration of that operating system, this may imply that the user may also have unintentional root access to the host operating system. Newer versions of operating systems often have a login prompt and timeouts if the previous session did not log out. Please consult the operating system user manual for more details on serial console or serial console redirection.

SOL also plays a role during BIOS POST. In Cisco UCS B-Series and C-Series servers, BIOS must first be configured for serial console redirection on COM1 for SOL to have an effect. In Cisco UCS B-Series and UCSM mode C-Series, the control for enabling or disabling serial console redirection is handled in UCSM. In standalone C-Series, the control is available via the command-line interface (CLI) or web-based GUI. In all servers, BIOS setup can be protected by adding a BIOS password to gain BIOS control as additional security.

In Cisco UCS B-Series servers, IPMI does not offer SOL. The SOL functionality is provided via Secure Shell (SSH).

Although SOL offers ease of management, the customer can close this unexpected security vulnerability by enabling or disabling aforementioned security features.

User Privileges

Root-level access in IPMI is analogous to administrative level. In IPMI, there are many user privileges ranging from the lowest level that can only issue commands that retrieve information from the system, to the highest level, administrative, that can perform such tasks as powering off the host.

In both Cisco UCS B-Series and C-Series servers, the user privileges are divided into only two domains: IPMI read-write users and IPMI read-only users. IPMI read-write users are fully privileged like a root user and read-only users are the lowest level, which can only issue retrieval-based commands. In Standalone C-Series, there are three user privileges: admin, user, and read-only. Admin is the equivalent of IPMI administrator. User is the equivalent of IPMI operator and a read-only user is the lowest IPMI privilege level.

In Cisco UCS B-Series and UCSM mode C-Series, the controls of privilege assignment to a particular user are controlled via UCSM. In standalone C-Series, the control is in the C-Series CLI or web-based GUI.

For additional information, see the following:

Root Access and Hardware

As stated, root-level access in IPMI grants access to the server's hardware. Although hardware control is required to perform the majority of IPMI functionality, this does not mean all hardware on the platform has the potential to be compromised. The following is the list of hardware that can be controlled via the Cisco IPMI.

Cisco UCS B-Series Servers

The following Cisco UCS B-Series hardware components can be controlled:

  • Environmental sensors (for example, voltage and temperature)
  • Cisco UCS Virtual Interface Card (VIC) adapters
  • Host power
  • Numerous I2C devices

Cisco UCS C-Series Servers

The following Cisco UCS C-Series hardware components can be controlled:

  • Environmental sensors (for example, voltage and temperature)
  • Cisco UCS VIC Cards
  • Host power
  • Numerous I2C devices
  • Serial port
  • BIOS flash
  • SD cards

BMCs Often Run Excess and Older Network Services That May Be Vulnerable

The Cisco IMC, which is a baseboard management controller (BMC), does indeed offer various network services. These services are virtual media, KVM, SOL, IPMI, SSH, SNMP and web-based GUI. SSH and web-based GUI are features only on the Cisco UCS C-Series server.

All the services listed offer authentication, integrity, and confidentiality. In addition, IPMI as a network service can be turned off. In Cisco UCS B-Series and UCSM mode C-Series, SOL and IPMI can be disabled or enabled at the UCSM level on a service profile basis. In standalone Cisco UCS C-Series, IPMI can be disabled.

In Cisco UCS B-Series or UCSM mode C-Series servers, the configuration of the network services resides at the UCSM level. Although the servers may have it locally enabled, the FI level prevents all unnecessary network traffic from reaching the Cisco IMC if the service is disabled in the FI.

The following table summarizes the service information:

Service Default Port Standalone C-Series Default Mode B-Series/UCSM Mode C-Series Default Mode Configurable
KVM
2068 Enabled Enabled C-Series Only
vMedia
2068 Enabled Enabled C-Series Only
NTP
123 Enabled Disabled Mode-Only
HTTP
80 Enabled Enabled Yes
HTTPS
443 Enabled Enabled Yes
SSH
22 Enabled Enabled C-Series Only
XMLAPI
443 Enabled Disabled Mode-Only
IPMI over LAN
623 Enabled Disabled Mode-Only
SNMP
161 Disabled Disabled Mode-Only
Telnet
23 N/A Disabled Mode-Only
SMASH CLP
- N/A Enabled No
SOL
22 See SSH and IPMI over LAN Disabled Mode-Only

For configuration information on standalone Cisco UCS C-Series, see the following:

For configuration information on Cisco UCS B-Series or UCSM C-Series severs, see the following:

Improvements

For IPMI over LAN in Cisco UCS C-Series server, Cisco bug ID CSCuh85575 was filed to change the default setting to disabled. Cisco bug ID CSCuj51374 will drive additional coherency between the FI and Cisco B-Series servers in terms of IPMI enablement. Cisco bug ID CSCuj51380 is the C-Series equivalent of CSCuj51374.

IPMI Access May Grant Remote Console Access to the System, Resulting in Access to the BIOS

Cisco remote console access is the same as SOL. See the "Remote Serial Console Access" section for more details.

Few Monitoring Tools Are Available to Detect if the BMC is Compromised

This is a general statement as there are few monitoring tools to detect if any software or hardware is compromised. In Cisco UCS B-Series and UCSM mode C-Series, UCSM offers logging and auditing for security-related issues. For standalone mode C-Series, the Cisco IMC provides logging and auditing. In Cisco UCS B-Series and C-Series servers, the Cisco IMC has numerous security features to enhance the overall security of the server.

Unclear Documentation on How to Sanitize IPMI Passwords Without Destroying the Motherboard

In Cisco UCS B-Series servers, the username and password database is stored in volatile memory. Thus, to sanitize the IPMI passwords, the blade server need only be removed from the chassis and set aside in a secure location for a few days for the DIMM memory to lose all its charge.

In Cisco UCS C-Series Servers, the username and password database is stored in non-volatile memory; therefore, the only way to sanitize these passwords is to destroy the motherboard.

To further improve Cisco UCS products, Cisco bug ID CSCuj23654 was created to allow sanitization of Cisco IMC non-volatile storage.

Certain Types of Traffic To and From the BMC Are Not Encrypted

IPMI 2.0 offers encryption and the Cisco UCS B-Series and C-Series IPMI is based on this version. In IPMI 2.0, the authentication, confidentiality, and integrity mechanisms are done through cipher suites, specifically suites 1–14. These cipher suites use the RMCP+ Authenticated Key-Exchange Protocol (RAKP) as described in IPMI 2.0 public specification as the basis of authentication. This section discusses cipher suites 0–14 and how to configure the server for encryption.

Cipher Suite 0

Cipher suite 0 is the most unsecure of the cipher suites because it lacks authentication, confidentiality, and integrity. Cipher Suite 0 should be disabled. Please see the "Cipher Suite 1–14" section for details of the other cipher suites. See the "IPMI Configuration" section for information on IPMI server configuration. To disable cipher suite 0, perform steps 5 and 7 in the "Configuring IPMI through the Host Operating System" or "Configuring IPMI over the Network" sections.

Cipher Suites 1–14

Each cipher suite in this range offers some combination of authentication, confidentiality, and integrity algorithms. All cipher suites are based on RAKP, which works on a foundation of symmetric keys. This implies that both the client and server side must know the symmetric key prior to session establishment.

According to Table 22–19 of the IPMI specification, cipher suites 1 and 6 use only authentication. Cipher Suite 2, 7, and 11 use authentication and integrity algorithms. The remaining Cipher Suites 3–5, 8–10, and 12–14 use all three algorithms. This means the most secure of the cipher suites are those that use all three algorithms.

Default Settings

Cisco UCS B-Series and C-Series servers come with IPMI enabled at the Cisco IMC level with cipher suite 0 enabled. In a UCS environment, Cisco UCS B-Series and UCSM mode C-Series server, the IPMI settings at the UCSM level override the Cisco IMC-level settings. At the UCSM level, the default is disabled. In standalone mode C-Series server, IPMI is enabled by default.

Cisco does not ship servers with embedded default keys because they would present the same issues for security and deployment. Thus, the customer is expected to configure the server to their security requirements.

Cisco bug ID CSCuj23676 warns customers about a possible IPMI configuration that may lead to security vulnerabilities.

IPMI Configuration

Cipher suite 0 was not intended to be a secure protocol. Although IPMI does not clearly explain the configuration process of the cipher suites, it does specify the commands used in this process. This section describes two methods for configuring Cisco UCS B-Series and C-Series servers: configuring IPMI over the network and configuring IPMI through the host operating system.

First, read the steps in each method before deciding which configuration method to use. Then, read the "Security Configuration Notes" section that follows for additional security information before implementing the steps.

Configuring IPMI through the Host Operating System

This is the most secure method because the installation of the symmetric keys is not visible over the network as long as the method used to connect to the host operating system is deemed secured by the customer's security requirements. After connecting to the host operating system, a third-party tool is needed. For Linux-based operating systems, OpenIPMI and IPMITool are needed. The KCS driver is needed and is typically provided by OpenIPMI. Check the operating system repository to see if there is an existing package for the installed operating system variant. For Windows, the utility is ipmiutil and the IPMI drivers are needed. In either Linux or Windows, the drivers should be using KCS to communicate to the Cisco IMC.

The exact command line parameters are outside the scope of this document. Please consult the documentation for the tool. When selecting the interface to communicate to the Cisco IMC, specify KCS as the interface.

The examples below use ipmitool on a CentOS server with OpenIPMI installed. The examples assume the user has been given the appropriate privileges to execute the commands as well as set up IPMI for communication.

The following steps outline IPMI over LAN configuration:

  1. Generate two 160-bit (20-byte) keys. Choose one key to be the KR key and the other to be the KG key. The generation and strength of the keys are outside of the scope of this document.

  2. Use the Get Channel Info Command (Net Function = 0x6, Command Number=0x42) to find the appropriate channel number. This means the Channel Medium Type (byte 3 of the IPMI response) should be 802.3 LAN. 802.3 LAN is encoded as 4 in byte 3 of the IPMI response. The actual channel number is in byte 2 of the IPMI response. Record the actual channel number. 

     

    Example of non-existent channel:
    [user@localhost ~]# ipmitool -I open raw 6 0x42 0x0 
    Unable to send RAW command (channel=0x0 netfn=0x6 lun=0x0 cmd=0x42 rsp=0xcc): Invalid data field in request

    Example of LAN channel:
    [user@localhost ~]# ipmitool -I open raw 6 0x42 0x1
    01 04 01 80 f2 1b 00 00 00

    Note: The first byte displayed is actually the second byte with respects to the IPMI specification. A completion code of 0 for success is hidden. Thus, according to bytes 2 and 3, channel 1 is the LAN channel on this server.

  3. Use the Set Channel Security Keys IPMI command (Net Function=0x6, Command Number=0x56) to set these two keys. The channel number to use in the IPMI request (byte 1) is found in step 2. Issue the command twice, once for each key.

     

    Example of setting the KR key:
    [user@localhost ~]# ipmitool -I open raw 6 0x56 1 0x1 0x0 0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8 0x9 0xA 0xB 0xC 0xD 0xE 0xF 0x10 0x11 0x12 0x13 0x14;

    02
    Note: A lock status value of 0x2 means the key is not locked.

    Example of setting the KG key:
    [user@localhost ~]# ipmitool -I open raw 6 0x56 1 0x1 0x1 0x11 0x21 0x31 0x41 0x51 0x61 0x71 0x81 0x91 0xA1 0xB1 0xC1 0xD1 0xE1 0xF1 0xF0 0xF1 0xF2 0xF3 0xF4;

    00
    Note: A lock status value of 0 means the key is not lockable.

  4. From a different computer, issue an IPMI command over the network to the Cisco IMC on the server involved in this process. Ensure the parameter that is used forces the client to use the IPMI 2.0 RMCP+ connection method.

     

    Example of successfully retrieving the Device ID using cipher suite ID 3:
    [myself@my-company-laptop ~]# ipmitool -I lanplus -C 3 -H $cimc-ip-address -U $username -P password -y 112131415161718191A1B1C1D1E1F1F0F1F2F3F4 raw 6 1 
    20 80 02 01 02 3f 8b 16 00 0d 00 00 01 f0 e1

    Example of failure to retrieving the Device ID using cipher suite ID 3:
    [myself@my-company-laptop ~]# ipmitool -I lanplus -C 3 -H $cimc-ip-address -U $username -P $password -y 112131415161718191A1B1C1D1E1F1F0F1F2F3F5 raw 6 1 
    Error: Unable to establish IPMI v2 / RMCP+ session
    Unable to send RAW command (channel=0x0 netfn=0x6 lun=0x0 cmd=0x1)

  5. If the previous step succeeds, then determine which cipher suites IDs should be disabled. If it does not succeed, perform steps 2 through 4 again or perform the steps in Section 2.8.6 and start over. Finally, if failure still occurs, please collect tech support and contact Cisco. Using the Set LAN Configuration Parameters IPMI command (net function = 0xC, command number = 0x1), modify the appropriate cipher suite ID in "RMCP+ Messaging Cipher Suite Privilege Levels" parameter by using a value of zero in the corresponding cipher suite ID. The IPMI specification uses 1st, 2nd, 3rd, etc. to refer to cipher suite ID 0, 1, 2, etc. The channel ID is the one found in step 2.

     

    Example of Disabling Cipher Suite 0:
    [user@localhost ~]# ipmitool -I open raw 0xC 0x1 1 0x18 0 0x40 0x44 0x44 0x44 0x44 0x44 0x44 0x4

    Note: If successful, there is no message or text given back by ipmitool.

  6. Decide whether IPMI version 1.5 authentication should be disabled according to the customer's security requirements. To disable IPMI version 1.5 LAN entirely, use the Set LAN Configuration Parameters IPMI command as in the previous step. This time modify the Authentication Type Enables parameter and zero out the respective privilege levels.

     

    Example of Disabling all IPMI version 1.5:
    [user@localhost ~]# ipmitool -I open raw 0xC 0x1 1 0x2 0 0 0 0 0

    Note: If successful, there is no message or text given back by ipmitool.

  7. Verify the configuration applied in steps 5 and 6 are set correctly by attempting to connect over the network. If set correctly, the network connection should fail.

     

    Example of Cipher Suite 0 Successfully Disabled:
    [user@localhost ~]# ipmitool -I lanplus -C 0 -H 10.193.71.52 -U scott -P scott raw 6 1
    Error in open session response message: no matching cipher suite

    Error: Unable to establish IPMI v2 / RMCP+ session
    Unable to send RAW command (channel=0x0 netfn=0x6 lun=0x0 cmd=0x1)

    Example of Disabiling Administrator Access over IPMI version 1.5 using No Authentication:
    [user@localhost ~]# ipmitool -I lan -H $(CIMC-IP-Adress) -U $username -P $password raw 6 1 
    Authentication type NONE not supported
    Authentication type NONE not supported
    Error: Unable to establish LAN session
    Unable to send RAW command (channel=0x0 netfn=0x6 lun=0x0 cmd=0x1)

  8. Based on the security policies, decide if the KR key should be locked down. This is a non-reversible action. After the KR key is locked, there is no way to unlock it, which could render the server unusable due to its potential to be compromised.

     

    Example of locking the KR Key:
    [user@localhost ~]# ipmitool -I open raw 6 0x56 1 2 0
    01

    Note: The lock status, 0x1, indicates the key is locked.

Configuring IPMI over the Network

This option is the most convenient and eases deployment, but it is also the most insecure because the delivery of the keys will not be encrypted over the network. The steps at a high level are similar to the previous section. This section assumes UCSM and the server's server profiles are correctly configured for Cisco UCS B-Series, UCSM mode C-Series, and standalone C-Series servers, and the Cisco IMC CLI or web GUI has IPMI correctly enabled.

If during this process, the user accidentally cuts off the network connection, please follow the same process described in the "Configuring IPMI through the Host Operating System" section to recover and configure the server.

  1. Generate two 160-bit (20-byte) keys. Choose one key to be the KR key and the other to be the KG key. The generation and strength of the keys are outside of the scope of this document.

  2. Use the Get Channel Info Command (Net Function = 0x6, Command Number=0x42) to determine the channel ID of the LAN channel. This means the Channel Medium Type (byte 3 of the IPMI response) should be 802.3 LAN. 802.3 LAN is encoded as 4 in byte 3 of the IPMI response. The actual channel number is in byte 2 of the IPMI response. Record the actual channel number. 

     

    Example of LAN channel:
    [user@localhost ~]# ipmitool -I lanplus -C 0 -H $CIMC-IP-Address -U $username -P $password raw 6 0x42 0xE
    01 04 01 80 f2 1b 00 00 00

    Note: The first byte displayed is actually the second byte with respects to the IPMI specification. A completion code of 0 for success is hidden. Thus, according to bytes 2 and 3, channel 1 is the LAN channel on this server. The value of 0xE in the request byte is a special byte indicating the channel of the request.

  3. Use the Set Channel Security Keys IPMI command (Net Function=0x6, Command Number=0x56) to set these two keys. The channel number to use in the IPMI request (byte 1) is found in step 2. Issue the command twice, once for each key.

     

    Example of setting the KR key:
    [user@localhost ~]# ipmitool -I lanplus -C 0 -H $CIMC-IP-Address -U $username -P $password raw 6 0x56 1 0x1 0x0 0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8 0x9 0xA 0xB 0xC 0xD 0xE 0xF 0x10 0x11 0x12 0x13 0x14;

    02
    Note: A lock status value of 0x2 means the key is not locked.

    Example of setting the KG key:
    [user@localhost ~]# ipmitool -I lanplus -C 0 -H $CIMC-IP-Address -U $username -P $password raw 6 0x56 1 0x1 0x1 0x11 0x21 0x31 0x41 0x51 0x61 0x71 0x81 0x91 0xA1 0xB1 0xC1 0xD1 0xE1 0xF1 0xF0 0xF1 0xF2 0xF3 0xF4;

    00
    Note: A lock status value of 0 means the key is not lockable.

  4. To verify the settings, issue an IPMI command over the network to the Cisco IMC on the server involved in this process. Ensure the parameter that is used forces the client to use the IPMI 2.0 RMCP+ connection method.

     

    Example of successfully retrieving the Device ID using cipher suite ID 3:
    [user@localhost ~]# ipmitool -I lanplus -C 3 -H $cimc-ip-address -U $username -P password -y 112131415161718191A1B1C1D1E1F1F0F1F2F3F4 raw 6 1 
     20 80 02 01 02 3f 8b 16 00 0d 00 00 01 f0 e1

    Example of failure to retrieving the Device ID using cipher suite ID 3:
    [user@localhost ~]# ipmitool -I lanplus -C 3 -H $cimc-ip-address -U $username -P $password -y 112131415161718191A1B1C1D1E1F1F0F1F2F3F5 raw 6 1 
    Error: Unable to establish IPMI v2 / RMCP+ session
    Unable to send RAW command (channel=0x0 netfn=0x6 lun=0x0 cmd=0x1)

  5. If the previous step succeeds, then determine which cipher suites IDs should be disabled. If it does not succeed, please follow the steps in the "Configuring IPMI through the Host Operating System" section. Using the Set LAN Configuration Parameters IPMI command (net function = 0xC, command number = 0x1), modify the appropriate cipher suite ID in the RMCP+ Messaging Cipher Suite Privilege Levels parameter by using a value of zero in the corresponding cipher suite ID. The IPMI specification uses 1st, 2nd, 3rd, etc. to refer to cipher suite ID 0, 1, 2, etc. The channel ID is the one found in step 2. After this step, the user must switch to the appropriate cipher suite for their IPMI LAN connection.

     

    Example of Disabling Cipher Suite 0:
    [user@localhost ~]# ipmitool -I lanplus -C 0 -H $CIMC-IP-Address -U $username -P $password raw 0xC 0x1 1 0x18 0 0x40 0x44 0x44 0x44 0x44 0x44 0x44 0x4

    Note: If successful, there is no message or text given back by ipmitool.

  6. Decide whether IPMI version 1.5 authentication should be disabled according to the customer's security requirements. To disable IPMI version 1.5 LAN entirely, use the Set LAN Configuration Parameters IPMI command as in the previous step. This time modify the Authentication Type Enables parameter and zero out the respective privilege levels.

     

    Example of Disabling all IPMI version 1.5:
    [user@localhost ~]# ipmitool -I open -C 3 -H $CIMC-IP-Address -U $username -P $password -y $KG-Key raw 0xC 0x1 1 0x2 0 0 0 0 0

    Note: If successful, there is no message or text given back by ipmitool. Also, another cipher suite is used with the appropriate key specified.

  7. Verify the configuration applied in steps 5 and 6 are set correctly by attempting to connect over the network. If set correctly, the network connection should fail.

     

    Example of Cipher Suite 0 Successfully Disabled:
    [user@localhost ~]# ipmitool -I lanplus -C 3 -H $CIMC-IP-Address -U $username -P $password -y $KG-Key raw 6 1
    Error in open session response message: no matching cipher suite

    Error: Unable to establish IPMI v2 / RMCP+ session
    Unable to send RAW command (channel=0x0 netfn=0x6 lun=0x0 cmd=0x1)

    Example of Disabiling Administrator Access over IPMI version 1.5 using No Authentication:
    [user@localhost ~]# ipmitool -I lan -H $CIMC-IP-Address -U $username -P $password raw 6 1 
    Authentication type NONE not supported
    Authentication type NONE not supported
    Error: Unable to establish LAN session

  8. Based on the security policies, decide if the KR key should be locked down. This is a non-reversible action. After the KR key is locked, there is no way to unlock it, which could render the server unusable due to its potential to be compromised.

     

    Example of locking the KR Key:
    [user@localhost ~]# ipmitool -I lanplus -C 3 -H $CIMC-IP-Address -U $username 
    -P $password -y $KG-Key raw 6 0x56 1 2 0
    01

    Note: The lock status, 0x1, indicates the key is locked.

Security Configuration Notes

The user must be aware that IPMI commands can be sent from the host to the Cisco IMC on the same server using a hardware path called KCS. IPMI assumes accesses to IPMI across any physical interfaces on the server is considered authenticated by the host operating system and therefore grants unlimited access. If the host operating system user is given access to IPMI, that user can potentially undo or compromise the existing IPMI configuration.

Improvements

Cisco recorded Cisco bug ID CSCuj23684 to ease deployment of Cisco UCS B-Series and UCSM mode C-Series servers. Cisco bug ID CSCuj23691 was recorded for standalone C-Series servers to warn about improper IPMI configuration and provide easy deployment of servers. Cisco bug ID CSCuh85553 will track the disabling of cipher suites 0, 1, 2, 6, 7, and 11 and all of IPMI version 1.5 LAN connection methods as the default shipping configuration for Cisco UCS B-Series servers. Cisco bug ID CSCuh85575 will track the disabling of cipher suites 0, 1, 2, 6, 7, and 11 and all of IPMI version 1.5 LAN connection methods as the default shipping configuration for C-Series servers.

Reset to Factory Defaults

If at any time, the user wishes to restore IPMI settings to factory default, UCSM and standalone C-Series servers provide a CLI command to perform the action. This will remove any installed cipher suite security keys.

To reset C-Series servers to factory default settings using CLI and GUI, see the following:

To reset UCS servers to factory default settings, perform the following steps:

  1. Log in to UCSM CLI
  2. scope server $(chassis)/$(slot) where $(chassis)/$(slot) is the location of the B-Series or C-Series server
  3. reset-ipmi
  4. commit buffer
  5. Wait at least two seconds
  6. Exit the UCSM CLI session

Glossary

Term Definition
Cisco IMC
Cisco Integrated Managment Controller. This micro controller physically resides on the server and is responsible for numerous management activities from environmental monitoring to remote management.
BMC
Baseboard Management Controller. This is the same as the Cisco IMC.
FI
Fabric Interconnect
UCSM
Unified Computing Server Management
IPMI
Intelligent Platform Management Interface

References

IPMI specifications

http://www.intel.com/content/www/us/en/servers/ipmi/ipmi-specifications.html

US-Cert 
http://www.us-cert.gov/ncas/alerts/TA13-207A


This document is part of Cisco Security Research & Operations.

This document is provided on an "as is" basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information on the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document at any time.

Back to Top