IPMI: Hack a Server That Is Turned Off 90
UnderAttack writes "A common joke in infosec is that you can't hack a server that is turned off. You better make sure that the power cord is unplugged, too. Otherwise, you may be exposed via IPMI, a component present on many servers for remote management that can be used to flash firmware, get a remote console and power cycle the server even after the normal power button has been pressed to turn the server off."
Gets some things wrong, misses some *big* problems (Score:5, Informative)
IPMI is good when used correctly. A quality vendor (e.g. IBM) will select the appropriate security measures for default (*except* still allowing a default password, which really must be changed), but get a random white box, make sure that *this* won't work:
ipmitool -I lanplus -U correctusername -P someincorrectpassword -H youripmidevicehere power off
90% of the time it will. Cipher suite zero is the most idiotic thing in the IPMI spec, it by design allows you to access a system without knowing a password at all.
To Mitigate, ipmitool lan print 1. You'll see what cipher suites are supported and how they are restricted. Usually the supported ones will start out like '0,1,2,3'. In that case, you ipmitool lan set 1 cipher_privs Xaaa' Note the '1' may be different and the '0' in the protocol sequence isn't guaranteed, so adjust accordingly. Also use matching letters if the other cipher suites are not 'a'. xCAT on service processor setup disables cipher suite 0 automatically.
IPMI is actually capable of some very good behaviors if configured correctly.
-In the standard cipher suites, passwords are *never* sent over the wire (encrypted or in the clear) as of 2.0 (in 1.5 this was *usually* the case in sane implementations, but there was a mode for password on the wire). The password is actually a shared secret between client and service processor. In a good client, the service processor cannot be impersonated, as it *must* know the password to respond to the client correctly. ipmitool can be deceived but xCAT cannot.
-Additionally, payload can be AES encrypted as of 2.0 (and usually is, 'cipher suite 3' is the most common incarnation since it has been available since 2.0 of the spec).
-It is pretty much the *only* very specific spec for systems management. If the payload is the sequence of bytes '0,2,0' that means 'turn the server off' no matter who the vendor is. Other specifications tend to fall short of this, in the name of giving the vendors the 'freedom' to do as they wish.
That out of the way, article gets a few things wrong:
eliminate IPMI access over insecure protocols like HTTP. Use HTTPS with proper certificates, or SSH
IPMI cannot be done with HTTP(s) or SSH. IPMI *specifically* has its own UDP protocol in its remote incarnation. Most remote management solutions implementing *also* have a web and cli, but that's not covered in IPMI.
review the BIOS configuration option for IPMI. If you can't have a physical management network, at least try to use a VLAN if supported.
While this is possible in many current shared nic solutions, it generally suffers from two problems:
-In some shared NIC implementations, the OS driver for nic is more likely to mess up the remote access unless it behaves *just* right. This reduces the point of IPMI, to service a system when things have gone horribly wrong. Some older shared nic implementations made it risky even without the complication of tagging, but that's largely no longer an issue.
-It likely doesn't provide significant additional protection over an aliased private IP subnet. The theoretical additional benefit with VLAN being you are protecting service processor access if one server is compromised in-band. The problem is, you can generally coax the shared nic to let the OS onto any tagged vlan (just ask the local BMC what the compromised server's current vlan tag for IPMI traffic is, vconfig add eth0 , and usually you get right on that 'secure' vlan).
try to integrate IPMI authentication with existing authentication systems. Options typically include RADIUS and AD.
Actually, since the *standard* security mechanisms are all shared secret base, this isn't possible. There are some proprietary IPMI cipher suites that have the client transferring a password, but since normally that doesn't happen, you have no user password to check against the authentication server.
The video they showed was a web interface, *not* IPMI. I know companies like SuperMicro have really made this confusion, but I already mentioned that.
Re:Different networks (Score:5, Informative)
On shared chassis servers (blades, etc...) you may have common I2C sensor busses, and IPMB.
Absolutely, remember to ask your vendor *specifically* about this. Various solutions have varying degrees of resilience. Some even treat that topology as *trusted* and made certain design choices based on that.
Surprisingly, IBM BladeCenter is a tad frightening. While the management bus is pretty much isolated from the running OS requiring some hypothetical service processor exploit to get at, the 'CIN' is extended to server processors via VLAN tagging on shared nics. To its credit, they have taken some significant measures to prevent the NICs from behaving in certain ways that seemingly prevent it, but it all seems more complicated than I would like.
Despite BladeCenter frightening me, IBM Flex actually is perhaps the most strongly isolated chassis design. Servers in an enclosure have no i2c or similar connection between them, it's a point to point between the management module and each service processor. The ethernet topology is hard-isolated from the OS. Even if you found a service processor exploit in theory, that service processor has a distinct authentication scheme from everyone else, meaning they can't take the exploit further into other parts of the chassis.
Re:Dummies IPMI question... (Score:4, Informative)
It's a SoC. Each vendor's solution exhibits different levels of restrictions and ambitions.
I recall years ago, one whitebox just gave you root ssh access to the linux system that was the BMC.
On the other hand, most of the time it's very tightly restricted to specifically do things like alerting, power on/off, remote video and serial, event logs, etc. Mostly because the whole point of the stack is to *always* work, and the more complicated you go, the higher the risk gets that you will fare no better than the OS instance on the server you are trying to manage.
IBM and the like will do things like system firmware management and changing things like hyperthreading via service processor, but still steers very clear of allowing open-ended usage of their service processor.
Re:Change the password (Score:5, Informative)
Disclaimer: I'm an IBM employee.
My personal take is that if you are going with supermicro or similar, you best understand how the standard(s) work and use vendor-agnostic tools and steer clear of the tools that SuperMicro and similar provide. For example, understand how IPMI security model works, disable cipher suite 0, refrain from using ipmi 1.5 straight authentication, set user table up so that the first user is effectively disabled, and all other ipmi account slots are all managed securely by your processes. Rather than use setup dialogs and utilities from supermicro, use tools like ipmish from freeipmi and/or ipmitool for one-off usage or to build your own infrastructure. If you want a bigger infrastructure that is a bit more designed from ground-up for mass server management, then something like xCAT can help, but it's not exactly easy to use, might be a bit more ambitious than what you want to do, and despite best efforts it will still be no substitute for understanding the security implications of the implementation provided by the vendor (e.g. right now it only messes with the first 4 user slots, assumes that if cipher suite 0 is there, it's the first one, and so on and so forth).
Now if this seems overly complicated, then buy from a vendor like IBM or HP (Dell I have heard varies more between the spectrum of direct Tyan/SuperMicro and IBM/HP standards, but perhaps closer to IBM and HP for the most part). The standards based tools still continue to work, but the factory default in modern systems is more carefully considered and what proprietary tooling provided is generally more robust than the white box vendors have time/resources to bother with. While these vendors have an increasingly difficult job to distinguish themselves from cheaper competitors from Taiwan, they still do spend some of the money entailed in the price premium on a more finished and confidence inspiring experience.
Keep in mind that as recently as 3 or so years ago, us 'tier one' vendors had pretty crappy defaults and inconsistent tooling as well. However, at least in IBM world, that was all very forcibly corrected for as of the 'M2' generation (the models that released with Nehalem processors).