Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Security Cloud Networking Hardware

IPMI Protocol Vulnerabilities Have Long Shelf Life 62

msm1267 (2804139) writes "If enterprises are indeed moving services off premises and into the cloud, there are four letters those companies' IT organizations should be aware of: IPMI. Short for Intelligent Platform Management Interface, these tiny computers live as an embedded Linux system attached to the motherboards of big servers from vendors such as IBM, Dell and HP. IPMI is used by a Baseboard Management Controller (BMC) to manage Out-of-Band communication, essentially giving admins remote control over servers and devices, including memory, networking capabilities and storage. This is particularly useful for hosting providers and cloud services providers who must manage gear and data in varied locations.

Noted researchers Dan Farmer, creator of the SATAN vulnerability scanner, and HD Moore, creator of Metasploit, have been collaborating on research into the vulnerabilities present in IPMI and BMCs and the picture keeps getting uglier. Last July, Farmer and Moore published some research on the issue based upon work Farmer was doing under a DARPA Cyber Fast Track Grant that uncovered a host of vulnerabilities, and Internet-wide scans for the IPMI protocol conducted by Moore. Farmer released a paper called 'Sold Down the River,' in which he chastises big hardware vendors for ignoring security vulnerabilities and poor configurations that are trivial to find and exploit."
This discussion has been archived. No new comments can be posted.

IPMI Protocol Vulnerabilities Have Long Shelf Life

Comments Filter:
  • by Anonymous Coward

    Any function on the motherboard that is connected to the nic, IPMI/EFI/AMT/vPro/etc, are just back doors waiting to be kicked open (if not already opened by default).

    • I think these are connected to a second NIC.
      • by Anonymous Coward

        That's what they want you to think. Even if IPMI is on a private NIC, everything on the motherboard is ultimately connected to the chipset (c216 connection map [bestofmicro.com]), you'll never know what kind of magic packet any of the back-doored components will respond to because there won't be any logs.

        Anything from NIC1/NIC2/PCIe can activate vPro in the chipset, that has built in KVM.

      • by sjames ( 1099 )

        Sometimes they are, and in that case it's easy to put it all on a separate LAN segment. In other cases it's an odd little setup where BMC and main system share the physical port but have seperate MACs. The BMC gets it's own IP address that the host and it's OS is unaware of. In the bad old days of the mid aughties the the BMC side of the shared port crashed more often than the server. In the worst cases, the host side would crash as well and the only recovery was a hard power cycle ((defeating the point of

  • by mmell ( 832646 ) on Sunday June 08, 2014 @12:10PM (#47190401)
    Every enterprise I've worked for that uses IPMI (BMC, ALOM/ILOM, etc.) has put it on their intranet, not the internet - and as often as not, an especially inaccessible corner of the intranet.

    Y'know, TCP/IP is inherently insecure. In fact, there's no effective built-in security there. IPMI itself is not secure because the security should not be implemented there; any more than network security should not be implemented in TCP/IP. Since this is a server related issue, IPMI implementers and users are presumed to understand this. Workstation users need not concern themselves with this. What sane workstation user will pay the extra money to get hardware with RAC technology?

    • by Spad ( 470073 )

      That still doesn't excuse shoddy IPMI implementations and not fixing vulnerabilities when they're discovered.

      • by mmell ( 832646 )
        Okay, I can agree with that - but frankly, there are huge amounts of this already implemented in the world - implemented in hardware, incidentally. It's orders of magnitude harder to fix (which is why firmware and embedded systems usually go through so much more testing and evaluation prior to being made available).
      • by gweihir ( 88907 )

        Hey are just following "industry standards". Shoddy, incompetent implementations are the norm basically everywhere, and that includes firewalls, routers, commercial "mainstream" operating systems, etc.

        • by mmell ( 832646 )
          We used to joke about this all the time in the Army - set the highest possible standard, then buy it from the lowest bidder!

          Anybody see a problem with that?

      • by sjames ( 1099 )

        Completely agreed. In this case, the vulnerability is deep in the specification for IPMI. They'll need a new spec.

        Step one, lose all the channel crap. There should be two. Channel 0 which is accessed via the host OS requiring root/Administrator access. The second is for any sort of remote access (normally LAN). Channel 0 SHOULD skip authentication entirely, channel 1 MAY NOT skip authentication (no NULL user or password). They can take it from there, but I would suggest simple encryption (no, not SSL, I sai

        • by Junta ( 36770 )

          I will say that the serial channel is useful as well. But this 'all channels are arbitrary' should go. CHannel 0 being the 'in-band, channel 1 always being *the* lan (currently some people have multiple lan channels, this should go away), and channel 2 always being a serial channel, if applicable, could make sense. Usually the serial channel serves as a way to indicate SOL related data and is rarely used for initial purpose of rs232 connected devices, so perhaps reimagine that as just more commands and d

          • by sjames ( 1099 )

            They have encryption, but it is not mandatory and when used, it is shared secret rather than DH or similar. For the purposes of this discussion, an actual rs-232 connection should be considered remote.

            I'm not so sure an SSL cert like system is really practical for target (server) authentication. Management firmware can be expected to be in the field for a long time and never updated. Honestly though, once encryption is established through DH, a simple scheme involving hashing the session key, an arbitrary u

            • by Junta ( 36770 )

              They have encryption, but it is not mandatory

              Same can be said of http and https. Nothing specific to IPMI.

              it is shared secret rather than DH or similar.

              Well that may be a better way to settle the symmetric key value, but then you have to discuss authentication as a separate item, since Kuid currently serves both in establishing keys as well as authenticating the parties to one another. SNMPv3 USM seems to be a pretty appropriate model for this scenario (where certificate systems are likely to be ignored), which is pretty similar in kind to IPMI except that the client goes first and the key is l

              • by sjames ( 1099 )

                Well, one IPMI does SHA256 or SHA1. For another, I'm unaware of any attack even against MD5 that would compromise the security when used in an HMAC scheme, as is the case for the hash function use in IPMI.

                An actual dump from a BMC:

                ID IANA Auth Alg Integrity Alg Confidentiality Alg
                0 N/A none none none
                1 N/A hmac_sha1 none none
                2 N/A hmac_sha1 hmac_sha1_96 none
                3 N/A hmac_sha1 hmac_sha1_96 aes_cbc_128
                6 N/A hmac_md5 none none
                7 N/A hmac_md5 hmac_md5_128 none
                8 N/A hmac_md5 hmac_md5_128 aes_cbc_128
                11 N/A hmac_md5 md5_128 none
                12 N/A none md5_128 aes_cbc_128

                As for the rest, yes, http can be done without encryption, but there are substantial low-risk use cases for taht. Http doesn't generally allow rebooting a server into single user mode and resetting the root password..

                As for the rest, see A Penetration Tester's guide to IPMI [rapid7.com]. Note that using a DH exchange to negotiate a session key offers forward secrecy and allows for a much more secure authentication protocol that doesn't involve handing out the MD5 hash of any chosen user's passw

    • by amorsen ( 7485 )

      The problem is that it doesn't help unless you implement security on your switches as well (private VLAN or similar). One compromised server can take over the IPMI interface and transmit on the isolated network. This is supposed to be impossible; the host is not supposed to be able to use the IPMI interface to source traffic (assuming it has been assigned a dedicated interface and not shared of course). Unfortunately it is not impossible in practice.

    • by mcrbids ( 148650 )

      Nobody should ever put IPMI or AMT enabled systems on the public Internet deserves the hacks and system compromises that they deal with. At the *very least* it should be contained within a firewall/VPN on a private LAN or Intranet.

  • by SuperTechnoNerd ( 964528 ) on Sunday June 08, 2014 @12:17PM (#47190437)
    It confounds me that still, in today's world, new technologies are designed as such:

    Design core features.
    Write and test/debug core features.
    Then, if there is time, do a security audit and glue some security on top otherwise just release what you got.

    Security must be built in from step one, step two, etc. and must be and integral part of the design.
    Have we not learned our lesson yet?
    • by gweihir ( 88907 )

      New technologies get security audits if there is time? News to me. The money is needed for bonuses for the "manager" that do not even manage to understand the basics.

      Most people that make these decisions are not even aware there is a lesson to be learned.

    • Then you have never worked for a modern commercial, technical company!

      + *All* benefits go to management, so their incentive is low cost, rapid delivery.
      + Any and all negatives, are laid on the heads of the technical staff, so again
      the incentive for management is low cost, rapid delivery.
      + While the technical staff, sometimes, have a different opinion, by definition
      nobody cares, since they are "non management". Monkeys make noise? They get the hose.

      If by a miracle,

  • Bad subject alert: the protocol itself is not vulnerable (any more than any other protocol), the problems are in the implementations (and lack of on-going support for most).

    I always set up IPMI on a private VLAN, with only a couple of "trusted" hosts having access. Most things can be done with the "ipmitool" command-line program, or I can port-forward port 80 for the BMCs with a web interface. There are a few web-based BMCs with crappy Java applets for remote KVM (they mangled the VNC protocol just enough

    • by sjames ( 1099 )

      No, actually the protocol has some ugly parts that make it very difficult to secure, that's why isolation from the internet is the only choice.

      I truly despise the funky almost VNC and java app. It makes it quite hard to use it over a secure forwarded port.

  • by gweihir ( 88907 ) on Sunday June 08, 2014 @12:22PM (#47190463)

    Even firewalling it is not enough, unless you only let authenticated traffic from very few sources in. In any case, IPMI needs to have its own network segment, anybody putting it into the same segment as other traffic is grossly negligent and utterly incompetent.

    And people putting IPMI where it is reachable from the Internet? I think that is grounds for immediate termination with a performance report that makes sure these people never do anything security-related ever again. That level of stupidity is hard to top.

    • Even firewalling it is not enough, unless you only let authenticated traffic from very few sources in. In any case, IPMI needs to have its own network segment, anybody putting it into the same segment as other traffic is grossly negligent and utterly incompetent.

      The problem is, all you have to do to get complete access to that segment is own either the jumphost or any of the servers with a module on that network. The unpatched vulns in IPMI modules are simply inexcusable. These days, full decent computers are available on a module that size, so they really ought to be able to run a decent OS which gets updates. I vote for Debian. This, finally, is a perfect use for Debian Stable.

  • As an IT guy, I really like the concept of IPMI. I would love something like LogMeIn, but that allows you to take control of machines on a baseboard/lights-out level. The only problem is, there aren't any solutions that I'm aware of that offer that kind of easy, useful bulk management of lots of machines from a single pane. But more importantly, the concept of that kind of bulk management should trigger the thought, "Holy crap that opens a dangerous can of worms!" If lights-out management isn't secured

  • From TFA

    Mind you, doing all of this on a BMC might well crash or wedge it into a sullen silence, as they are very easy to DoS into submission even unwittingly (Iâ(TM)ve completely broken BMCs from my testing both Dell and HP servers.)

    This sounds like it might be a usable workaround to plug the huge security hole, aim your own DDOS utility at it, definitely using a case of using sparkplug for a lugstud, but if it gets the job done...

    am I smoking crack here or were the specification authors?

    A common lament on my world.

  • Given the numbers of attack vectors in data centers from social engineering to software to hardware faults, would you trust your company's IT data system ONLY to "cloud suppliers?"

    Something like 2/3rds of small businesses that lose their digital data go out of business within 6 months, so it is a real risk issue to not have a totally local backup data system that can be brought up within a day.

    Do you totally trust big cloud data centers?

  • by Animats ( 122034 ) on Sunday June 08, 2014 @03:00PM (#47191177) Homepage

    I posted about the IPMI threat on Slashdot years ago, after reading the IPMI docs. Now, it's not only a real threat, it's one that's probably being widely exploited.

    Even if IPMI packets aren't being accepted from the outside Internet, an IPMI vulnerability means that any break-in to any server allows an easy attack on all servers inside the firewall.

    Anyway, for now, if you have a server, do
    ipmitool -A NONE -H bmc guid
    (replacing with the IP address) and see if it answers. If it responds to that from the outside world, you have a big problem.

    • It says

      Error: Unable to establish LAN session
      Get GUID command failed

      Does that means there is no IPMI service, or that there could be one but not with NONE authentication?

      • by Animats ( 122034 )

        "Unable to establish LAN session" is good. If you can establish an IPMI connection, per Dan Farmer's paper, an attack is likely to succeed.

  • Maybe they still have some functionality that allows IPMI over the regular NICs though.

  • Is it the kind of beast that is enabled while you never enabled it? Is there a way to test whether there is an IMPI service available from LAN? Would nmap -sU -p 623 $hostname be enough?
    • The majority of IPMI would be enabled by default, yes - however the majority (not all, some are virtual IPMI) are on dedicated NICs - usually labelled management interface or port or something. They're not usable as a normal NIC (although as mentioned above, yes, some are virtual and share an onboard NIC). As such, you're best putting them in a different VLAN. We use differently coloured network cables for them, too, in our datacentre, so there's no confusion. They're in a different VLAN, on a different swi
    • Oh sorry, forgot to say, yes, it's easy to find all IPMI devices on your network. Please take a look at: ftp://ftp.supermicro.com/utili... [supermicro.com] - you can download the IPMIView tool from there, which will find all IPMI devices on your LAN. The default password and username for all Supermicro IPMI is ADMIN and ADMIN, so, of course, super secure.
  • One thing is that the materials do not distinguish 'service processors' from 'IPMI' the protocol.

    The general facets on service processors broadly are no different than any 'appliance': vendors (particularly cheap ones) are lax about security and updates and there is not a lot you can do about it other than pick a vendor that seems to care or isolate the devices. This is nothing unique to the world of 'IPMI'.

    In terms of IPMI, there are things in there that should be and in fact are effectively removed by s

"If it's not loud, it doesn't work!" -- Blank Reg, from "Max Headroom"