Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

IPMI Protocol Vulnerabilities Have Long Shelf Life

samzenpus posted about 3 months ago | from the protect-ya-neck dept.

Security 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."

cancel ×

62 comments

Sorry! There are no comments related to the filter you selected.

IPMI vulnz (0)

Anonymous Coward | about 3 months ago | (#47190371)

Good thing IPMI gets some attention. IPMI doesn't seem to be very reliable at all. I was using IPMI fuzzer a while back from Codenomicon (same guys that found Heartbleed) in our data center and it was pretty sad how crappy the implementations were. Anyways - ended up disabling IPMI entirely in our environment.

Re:IPMI vulnz (2)

lgw (121541) | about 3 months ago | (#47190411)

It seems like every machine I've ever used in a co-lo has had it's drac/ilo card available remotely. That's the point of those cards, after all: so you can get into a machine that has crashed hard and do something to recover it.

Cloud service providers, at least IME, lock down this stuff pretty thoroughly since they only give VMs to customers and so don't need to allow direct access to the management cards from outside the datacenter, and are strict with ports and ACLs even inside the DC. But small companies with a few machines in a co-lo? This could get ugly.

Re:IPMI vulnz (2)

NormalVisual (565491) | about 3 months ago | (#47190659)

But small companies with a few machines in a co-lo? This could get ugly.

It doesn't have to. Just set up a cheap hardware firewall and keep the IPMI ports on local addresses only accessible via VPN. If the firewall/router can handle the traffic, it's often a good idea to NAT the servers' public interfaces as well so that if you have to change your public IPs all you have to change is the firewall/router config without touching the servers themselves.

Re:IPMI vulnz (0)

Anonymous Coward | about 3 months ago | (#47190861)

We make sure our IPMIs are behind a VPN. For precisely the reasons stated in the article. The size of the risk outweighs the benefits of clients who don't / can't set up openVPN.

Is it Linux's fault ? (1)

Anonymous Coward | about 3 months ago | (#47190425)

Since the IPMI runs Linux, and the researchers are uncovering tons of vulnerabilities on them, would it be correct to say that Linux shouldn't be used on those IPMI, and instead, Microsoft's Windows should be used, instead ?

Re:Is it Linux's fault ? (0, Troll)

gweihir (88907) | about 3 months ago | (#47190527)

No.
Linux => insecure if incompetently configured
Windows => always insecure

Fortunately, you cannot even get Windows to run on these very small systems or some cretins would surely do what you propose.

Re:Is it Linux's fault ? (0)

Anonymous Coward | about 3 months ago | (#47190571)

Absolutely. You can't exploit a machine that has crashed, after all. Of course, you lose remote admin capability that way...

Re:Is it Linux's fault ? (1)

MoreThanThen (2956881) | about 3 months ago | (#47193701)

HP have recently released new firmware in May 2014 for their vintage (think DL Gen 5/G1 blades) iLO v1 and v2 after network scans searching for heartbleed vulnerable systems crashed the management processor/BMC. Ah, just reset the device from the OS with the HP windows/linux hponcfg tool, nope, doesn't work as it can no longer talk to the crashed management processor.
The best bit is the fix for these 'remote support' devices, send someone to pull the power cord and wait for residual power to dissipate. For blades you can trip the fuse via telent to the OA.
Search 'iLO heartbleed' for the HP advisory.
 

Is it Linux's fault ? (0)

Anonymous Coward | about 3 months ago | (#47193667)

Windows is what got us here in the first place. Ever used old Sun gear with LOM? Nice and simple. Unfortunately Windows meant that server vendors needed to make ridiculously complex management cards that do clever things like remote mount optical drives and KVM console over IP, just because it's impossible to install or manage Windows via simple text console as it is with any real OS. This is what happens when an OS and hardware platform designed for desktops gets shoehorned into a 'server' - remote management becomes a complex hack and we end up with overly complicated and buggy management hardware.

Re:IPMI vulnz (4, Insightful)

gweihir (88907) | about 3 months ago | (#47190473)

That may be a bit over-the top. IPMI is vulnerable, but it is also useful. Giving IPMI its own physical network with access only after authentication is usually enough. A secure jump-host or firewall that requires authentication to pass traffic does serve well to secure IPMI.

Re:IPMI vulnz (0)

Anonymous Coward | about 3 months ago | (#47193611)

Usually secure?

Re:IPMI vulnz (2)

Z00L00K (682162) | about 3 months ago | (#47190519)

It's not surprising, and everyone running a datacenter should be aware of this already and run the devices on a separate network isolated from the other networks. Any use of the devices is purely of system administrator interest anyway, which means that it's easy to isolate.

Re:IPMI vulnz (1)

Anonymous Coward | about 3 months ago | (#47190849)

Many think they are safe just because they used a different IP subnet for the IPMI, until they get screwed by a back-doored switch that can redirect crafted packets from one port to another.

Re:IPMI vulnz (1)

niftymitch (1625721) | about 3 months ago | (#47192081)

Good thing IPMI gets some attention. IPMI doesn't seem to be very reliable at all...........

Yes worthy of attention....
The interesting bit is they are built with OLD micro-controllers and designed with OLD economics.

It is clear that modern hobby and educational devices like the Raspberry Pi or Beaglebone Black
shatter the old cost models. Same with the little Chromecast bug with a smaller yet footprint.

It is time to demand updates... and it is also important to know that a little card for very low
budget can do a fine job as a firewall protection resource.... on one side of an inexpensive switch.
Sadly rack hardware is much more expensive than it should be but computer hardware and software
economics are so changed that "Yes worthy of attention".

Common sense (1)

Anonymous Coward | about 3 months ago | (#47190385)

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

Re: Common sense (1)

allan marcus (3380849) | about 3 months ago | (#47190561)

I think these are connected to a second NIC.

Re: Common sense (1)

Anonymous Coward | about 3 months ago | (#47190743)

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.

Re: Common sense (1)

sjames (1099) | about 3 months ago | (#47190771)

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 having a BMC).

These days, it's fairly reliable, but I am not sure how well the soft vlan actually isolates the BMC from the host's vlan.

Re: Common sense (0)

Anonymous Coward | about 3 months ago | (#47190859)

Many people think they are safe just because they used a different IP subnet for the IPMI, until they get screwed by a back-doored switch that can redirect crafted packets from one port to another.

Be safe, don't even plug IPMI network cables into the same switch as others.

Re: Common sense (1)

sjames (1099) | about 3 months ago | (#47190957)

It's not necessarily a choice. Only some systems offer a separate management connection.

Re: Common sense (0)

Anonymous Coward | about 3 months ago | (#47192233)

IMO, "same port" usually is an electronically connected ethernet switch on the motherboard, installing the IPMI module attaches it to this switch.

As for how to keep IPMI safe, you need to physically have all your servers next to each other and have the BMC's only connected to their own switch. My servers don't even have that luxury, I just have the ethernet ports the BMC's sit on connected to the neighboring server. Worst case scenario is if one server is hacked, the other has a small chance. I say small because they are IPMI 1.0 servers connected to IPMI 2.0 servers and the 1.0's don't seem to work.

Slashdot Beta has a short shelf life (0)

Anonymous Coward | about 3 months ago | (#47190397)

If they go 100% Beta than this site will lose all of its users faster than water through a sieve.
 
Boycott Dice!
Boycott ThinkGeek!
Boycott Beta!

That's why IPMI should only live on intranets. (3, Interesting)

mmell (832646) | about 3 months ago | (#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?

Re:That's why IPMI should only live on intranets. (0)

Anonymous Coward | about 3 months ago | (#47190429)

Very much this, and even better, a segmented intranet (physical/vlan)

Re:That's why IPMI should only live on intranets. (1)

Spad (470073) | about 3 months ago | (#47190449)

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

Re:That's why IPMI should only live on intranets. (1)

mmell (832646) | about 3 months ago | (#47190483)

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

Re:That's why IPMI should only live on intranets. (1)

gweihir (88907) | about 3 months ago | (#47190499)

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

Re:That's why IPMI should only live on intranets. (1)

mmell (832646) | about 3 months ago | (#47190587)

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?

Re:That's why IPMI should only live on intranets. (0)

Anonymous Coward | about 3 months ago | (#47190835)

Lowest bidder is a fucking scam. Very often the "lowest bidder" is the ONLY bidder, meaning there's nothing low about it.

When they go looking for bidders for a contract on Raytheon doodads model number QZRK and it just happens that Raytheon is the only company that makes a model QZRK doodad... lowest bidder... LOL FREE MONEYS from tax payers because they think they're getting the best deal!!! :D Thanks for playing!

Re:That's why IPMI should only live on intranets. (1)

sjames (1099) | about 3 months ago | (#47190827)

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 said simple. How about DH exchange and a secure cipher) as an option at least.

Re:That's why IPMI should only live on intranets. (1)

Junta (36770) | about 3 months ago | (#47196337)

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 ditch the serial channel.

would suggest simple encryption (no, not SSL, I said simple

Well, that's what they have. Simple encryption using Kuid as a shared secret scheme. The challenge being that the key derivation is dead simple (just use the ascii password directly) and the server proves itself first (which is due to mimicking SSL behavior I assume, but stupid since the private key is not a generated computer value but usually 8-10 characters selected by a human). As a backend protocol, it actually can be done quite securely so long as the configuration limits passwords to impractical to crack values.

Re:That's why IPMI should only live on intranets. (1)

sjames (1099) | about 3 months ago | (#47198001)

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 user set string and a nonce chosen by the client together should suffice.

I could be convinced that an actual rs232 connection warrants it's own channel (always channel 2), but I expect that to be fairly rare these days.

Anything involving MD5 needs to go.

Re:That's why IPMI should only live on intranets. (1)

Junta (36770) | about 3 months ago | (#47205397)

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 localized based on a server identifier meaning the secret need not be stored in the clear on the management target.

Anything involving MD5 needs to go.

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.

Re:That's why IPMI should only live on intranets. (1)

sjames (1099) | about 3 months ago | (#47206475)

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 password or storing passwords in plain text. MD5 is quite weak in that scenario.

intra-nets must be secure too (0)

Anonymous Coward | about 3 months ago | (#47190713)

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.

So? That doesn't mean it shouldn't be updated and secured.

The initial point of entry for the attack against Target which caused tens of millions of CC numbers to be compromised was the network that the HVAC equipment sat on. Both Iran (Stuxnet) and the US DoD (agent.btz) had their air gaps jumped over. Networked printers have also been compromised and used to attack the rest of the network.

If an air gap can be attacked then so can your internal networks. Everything with an IP needs to be secured otherwise it can be used to attack other network elements. Just because it's "inside" means nothing.

Re:That's why IPMI should only live on intranets. (0)

Anonymous Coward | about 3 months ago | (#47190733)

The difference between intranet and internet very often doesn't matter. It's an archaic view where in fucking idiots think that their firewall will protect them from everything. It will not. You will have an infected box behind your firewall making your concept of an intranet useless. The only way an intranet approaches greater security is if it's on a physically separate network (hard to do when fuckwads at Dell want to bundle the "service" on the same Ethernet module as everything else and transparent to your OS's influence).

Your firewall is the first layer of security. Expect it to be compromised and that you'll have to rely on other layers to protect yourself.

Intranet is not a silver bullet. More often than not it's a false sense of security for bad IT "professionals" that want to trust every thing on one side of a router. Morons.

Re:That's why IPMI should only live on intranets. (0)

Anonymous Coward | about 3 months ago | (#47192123)

Dell offers a DRAC module with a dedicated ethernet interface. It costs a little more but it's available. At least that was the case a few years ago - I haven't been involved in server procurement since then.

Re:That's why IPMI should only live on intranets. (1)

amorsen (7485) | about 3 months ago | (#47190757)

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.

Re:That's why IPMI should only live on intranets. (0)

Anonymous Coward | about 3 months ago | (#47191553)

any Intel based board that's geared for business users with remote management capabilities. Hell I've got a budget Q87 board that includes the fucking Intel Remote Management feature and it's impossible to completely disable it because the NSA doesn't want it disabled

Re:That's why IPMI should only live on intranets. (1)

mmell (832646) | about 3 months ago | (#47191625)

I'm not familiar with that particular piece of hardware. Since you don't seem to want to use it, I'll consider you sane.

Sorry to hear your PHB isn't.

Re:That's why IPMI should only live on intranets. (1)

mcrbids (148650) | about 3 months ago | (#47193183)

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.

Re:That's why IPMI should only live on intranets. (0)

Anonymous Coward | about 3 months ago | (#47195537)

Workstations now have similar capabilities to servers:
http://www.intel.com/content/www/us/en/processors/vpro/core-processors-with-vpro-technology.html

You're doing it wrong. (2)

SuperTechnoNerd (964528) | about 3 months ago | (#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?

Re:You're doing it wrong. (1)

gweihir (88907) | about 3 months ago | (#47190521)

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.

Re:You're doing it wrong. (0)

Anonymous Coward | about 3 months ago | (#47191829)

There's an additional point that most LOM/iLO/whatnot approaches are... not built to scale. They're complex, quite often require a lot of client-side functionality (java or dotnet runtimes that aren't free of holes either, further denting robustness and availability), and end up serving pictures that are hard to script like you can script a serial with expect. All that complexity that ends up serving you something that isn't as useful as it could be comes with additional security and maintenance burdens you could do without, if only the starting point wasn't about bolting on some sort of semblance of network tranparency on the concept of a human inserting a cd and booting a computer and walking it through bios and initial set-up.

To me the right approach would've been building on top of a serial* giving access to a bios that understands text-based commands and can fetch boot images off disk, or usb, or tftp (at minimum, can fetch a small loader that understands fancier things), or whatever else you can fit in a flash rom in place of the text or these days graphical menus that consumer stuff just has to have. Then stick that serial in an ssh console server, that gives you fine-grained access control, a nice convenient place to serve mountable images to the management (v)lan, and all the other stuff that's useful in modern multi-sub-tenant datacentres but really too hard to put in embedded stuff that rarely gets updated and becomes a security hazard because of that.

That approach used to be the state of the art, but no longer isn't, because commodity kit is king. Even if said commodity kit isn't really suitable for datacentre use, not even with bolted-on afterthought-design extras.

* Possibly with different line coding and higher line rates, maybe steal firewire's, but still a "bare" byte pipe; no frames and higher level functions like ethernet or usb would require.

Re:You're doing it wrong. (1)

The_Other_Kelly (44440) | about 3 months ago | (#47194791)

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, the techs manage to actually do competent "Design, construct, test, ship" loops,
then they will be head-count reduced, since there is "fat" there. Wash, repeat.

The reality is that a trained chimp with Google, and either Office or some open source components
and 2 weeks worth of web-design, can duct tape together a minimal version that can fulfill at
least *some* of the customer's requirements. Even if only the color!

Obviously it will be crud, with low performance, no security and completely unmaintainable.

But this becomes the baseline cost!

What are customers willing to pay, over that cost, for the additional quality?
Guess what! NOTHING.

To pay the bonii, investors and the marketing costs, what are most modern tech companies willing
to pay, as a premium, for their employees, to exceed that baseline?
Guess again. Little or nothing.

This is not 1985. Software guys should be aware that electricians, plumbers and car mechanics have
better prospects, more pay and get paid overtime.

The only thing worse, is QA.

Not protocol vulnerabilities (1)

Burdell (228580) | about 3 months ago | (#47190453)

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 so regular VNC clients won't work); for those, I either set up a minimal X desktop VM or use a VPN to the trusted host.

Re:Not protocol vulnerabilities (1)

sjames (1099) | about 3 months ago | (#47190915)

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.

Competent people do IPMI over jumphosts (4, Informative)

gweihir (88907) | about 3 months ago | (#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.

Re:Competent people do IPMI over jumphosts (1)

drinkypoo (153816) | about 3 months ago | (#47194075)

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.

Current IPMI stinks (1)

nine-times (778537) | about 3 months ago | (#47190533)

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 properly, it gives an attacker a frightening level of access.

I don't know why they implemented these things without thinking it through. It's too hard to use legitimately, and too hard to manage security. I don't really even understand how I'm supposed to access and manage these systems in bulk, especially considered how often modern IT departments need to deal with remote machines that they never physically touch. If someone would develop a solution for IPMI that's not completely stupid-- think Meraki meets LogMeIn meets MDM-- an awful lot of IT departments would be falling all over themselves to buy hardware that supported it.

crude fix (1)

callmetheraven (711291) | about 3 months ago | (#47190579)

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.

Trust in Cloud Data Centers? (1)

BoRegardless (721219) | about 3 months ago | (#47190699)

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?

Warned about this years ago. (2)

Animats (122034) | about 3 months ago | (#47191177)

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 1.2.3.4 bmc guid
(replacing 1.2.3.4 with the IP address) and see if it answers. If it responds to that from the outside world, you have a big problem.

Re:Warned about this years ago. (1)

manu0601 (2221348) | about 3 months ago | (#47192801)

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?

Re:Warned about this years ago. (1)

Animats (122034) | about 3 months ago | (#47193023)

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

HP uses a dedicated Ethernet port for IPMI. (1)

Hohlraum (135212) | about 3 months ago | (#47192391)

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

Is IPMI enabled? (1)

manu0601 (2221348) | about 3 months ago | (#47192785)

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?

Re:Is IPMI enabled? (1)

Gumbercules!! (1158841) | about 3 months ago | (#47193191)

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 switch (makes sense to use a different switch as IPMI is usually 100mbit and not worth wasting space on expensive switches for) and only a handful of machines can see that network, which, frankly, if those machines got compromised, we'd be f*cked anyway (domain controllers, etc).

The default config for a Supermicro (which is what I use) is the IPMI is enabled and set to DHCP, so if you left it like that, yes, everyone on your network would probably be able to find it.

Re:Is IPMI enabled? (1)

Gumbercules!! (1158841) | about 3 months ago | (#47193197)

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.

Re:Is IPMI enabled? (0)

Anonymous Coward | about 3 months ago | (#47193727)

Eurgh, please don't tell people to use Super Micro tools; they're terrible. In this case, they're unnecessary, too. If you want to find any IPMI devices on a network, install OpenIPMI (called "openipmi" on Debian & Ubuntu) and just run the rmcp_ping utility; by default it'll ping the broadcast address.

If the broadcast address doesn't work for you, try:

nmap -sU -p623 --open $RANGE | grep -B 3 "open|filtered" | grep "Nmap scan report" | awk '{print $5}'

Where $RANGE is the network range you want to scan.

Worthy of attention, but a tad alarmist... (1)

Junta (36770) | about 3 months ago | (#47196207)

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 some vendors today (cipher suite 0, auth none, null user). There are things that can be more complicated and probably should be limited (same username can mean different things on different ports or even the same port but different circumstances). Finally, there is the rather significant peculiarity of the 'password'. The 'password' is really a shared secret, meaning that the target must store it in the 'clear' ultimately. Additionally, the target issues a solved challenge first to prove itself to a client, meaning an unauthenticated entity can get a solved challenge and then offline crack the password if it is simple enough (roughly 1,000 times easier than cracking an entry in /etc/shadow).

So now what to do? Well for one, you should know whether your vendor will share a bmc on it's "normal" ethernet by default. You should have ipmi traffic unreachable by internet systems unless you really know what you are doing (it's not the best long haul protocol anyway). If you can stand it, use random passwords that are unique to each BMC (meaning that an offline attack is rendered futile and a janitor attack can only compromise the system that is already dissected). IPMI can be implemented and configured to be internet-facing secure, but there really isn't a lot of compelling reason to be internet-facing with it. Vendors like Dell, HP, and IBM are more likely to feel the pressure to provide safer defaults than bare board vendors and lower cost vendors.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>