Slashdot Mirror
IPMI Protocol Vulnerabilities Have Long Shelf Life
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."
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."
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?
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.
Socialism: a lie told by totalitarians and believed by fools.
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?
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
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.
Please stand clear of the doors, por favor mantenganse alejado de las puertas
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.