IPMI over LAN vulnerability and some BMC "features"

I don't want to pull away credit or page views from Dan Farmer's great work, but this needs more exposure...

For those of you who manage servers with IPMI over LAN enabled, there is a very severe vulnerability that may allow anyone full root access to your iLO/iDRAC/IMM/ILOM/whatever (aka BMC).  This is independent of the OS, though once rooted the attacker can then take over the OS in the same way they would as if they have physical access.  They can control power, boot settings, serial over LAN, BIOS settings (via serial), KVM, and can even read/write arbitrary system memory.

For those of you who do not have IPMI over LAN enabled, there may be some stuff that affects you too...

 

Cipher zero vulnerability

 

The IPMI over LAN cipher 0 flaw is easy to test:
ipmitool -C 0 -H $my_bmc_hostname_or_ip -I lanplus -U root -P r00t mc info

(You may need to try a different username instead of root: admin, Administrator, ADMIN)
If that returns something, you are vulnerable.  The "-C 0" is the trick.  It enables a null cipher (aka cipher 0) that allows you to use any password as long as you know the correct username.  This has been identified as working on at least HP, Dell, and Supermicro BMCs.  I chose the IPMI command "mc info" for illustrative purposes.  You could also do "power cycle", "sol activate" (to use a serial console), or other fun things.

Some, though not all, vendors have released updates that fix this vulnerability.  If not and if you're lucky, you can disable cipher 0 by using bmc-config from freeipmi (Linux only, I believe).

You can do this from a Linux server using:
bmc-config -c -e Rmcpplus_Conf_Privilege:Maximum_Privilege_Cipher_Suite_Id_0=Unused

You can also do this remotely, which is especially useful for non-Linux systems.
bmc-config -h $a -u root -p "$your_real_psw" -D LAN_2_0 -c -e Rmcpplus_Conf_Privilege:Maximum_Privilege_Cipher_Suite_Id_0=Unused
Or you can exploit the vulnerability to fix it, assuming you use a recent version of bmc-config:
bmc-config -I 0 -h $a -u root -p hellothere -D LAN_2_0 -c -e Rmcpplus_Conf_Privilege:Maximum_Privilege_Cipher_Suite_Id_0=Unused

(More instructions on using bmc-config and other freeipmi tools, in case you're interested)

Unfortunately this doesn't always fix the flaw even if it claims to have disabled cipher 0.  If it doesn't, you need to try upgrading to the latest firmware release for your BMC (or whatever your vendor calls it).  If it's still broken, it's time to contact the vendor.

There is one other vulnerability I have read about but it hasn't worked on any system I tried:
ipmitool -H $my_bmc_hostname_or_ip -I lanplus -U '' -P '' mc info

The following script scans all hosts on 192.168.0.0/16 for vulnerabilities. Boot a Knoppix CD or something if you don't have any Linux systems to run it on.

#!/bin/bash
for a in {1..255}
do
    for b in {1..255}
    do
        n=192.168.$a.$b
        ipmitool -C 0 -P helloworld -H $n -U root -I lanplus mc info 2>&1 |grep -q 'IPMI Version' && echo $n
    done &
done |tee ipmi-vuln.$(date +%s)

Anything that ends up in the ipmi-vuln file is vulnerable.  If your systems are fixable by a method I described up top, you can do that inside the loop rather than just check for vulnerabilities.  Only run this on systems you are authorized to access, don't blame me if it ignites your servers, etc.

Hash, anyone?

 

Whoever thought of the following "feature" should probably find a different line of work:  you can easily grab the hash from a remote BMC without authentication or exploiting anything.  That is by design.  It's built into the authentication method that IPMI uses.  That means that you can grab the hash off of the remote BMC then crack it offline.  It's quite easy to do, so use maximum length passwords.

This can only be mitigated by doing two things, assuming you want to leave IPMI over LAN enabled:
1) Use passwords of either 16 or 20 characters (depending on if you need to support IPMI 1.5 or not)
2) Have a password rotation policy.

At least they only store the hashed password in Flash... right?

 

Uh, no.  The BMC is required to store your passwords as plaintext as part of the IPMI protocol.  Technically the password must only be recoverable, but the fact that the BMC can recover the plaintext means an attacker could too, so that's plaintext enough for me.

The fun part of this "feature" is that it may affect you whether or not you enable IPMI.  I'm not positive that this is the case for all vendors, though it is the case for most vendors:  whatever your iDRAC/iLO/IMM/ILOM password is set to is likely the same as your BMC password, meaning it is stored in plaintext on the motherboard somewhere.  Some vendors will even grab the hostname of the system and store it on there as well; we have seen refurb boards with some something.something.example.com (or similar) address on them.  If you sell your system or RMA it and ends up as a refurb, you may be sending other people your password and some information about where to try out that password.

This means that you absolutely need to remember to change your password before selling your systems or RMAing a motherboard (good luck with that...).  Dan Farmer, from whom I got much of this information, has also shown that it's quite easy to lift the plaintext password off the motherboard if you have physical access to it.  Since there are no auditing methods, it's hard to tell if changing or deleting your password actually completely deleted the password.  Even if an attacker doesn't want to bother physically opening the server, he could still plug the BMC in, figure out what IP it has, talk to it using normal IPMI methods, download the hash, then crack the hash.

I've probably gone on long enough at this point, but there is some really good reading at Dan Farmer's website (read the papers).  There's more in there about how rooting the OS of a single server with a BMC can give an attacker root access to *all* of your servers that share that BMC password.  Basically you can recover the password through some tricks after attacking one server.  You then have the password, something that is probably universal to an organization's servers.  If you can exploit one of the the BMC's many services and load code and files there, you now have access to its OS (typically Linux) and can hide stuff there.  You can also disable system services, such as the ones that listen for requests to update the firmware... ignore those requests and it may be impossible to oust an attacker.

There are other problems too, such as some BMC setups allowing the OS and BMC to snoop on each other.  For this and other information, I refer you to Dan Farmer.