Rapid7 Discloses IPMI Vulnerabilities

Published: 2013-11-06
Last Updated: 2013-11-06 23:56:46 UTC
by Johannes Ullrich (Version: 1)
3 comment(s)

Rapid7 today disclosed a number of vulnerabilities in Supermicro's IPMI implementation [1]. The vulnerabilities include static encryption keys as well as hard coded, non updatable, passwords. Sadly, these are typical embedded system issues, and not just common in IPMI implementations. In addition, several buffer overflow vulnerabilities are disclosed in CGI programs, some of which are accessible without authentication. For those that require authentication, the hard coded password will provide easy access.

Metasploit modules to test for these vulnerabilities are comming according to the blog post.

There is little one can do to protect an IPMI interface if the interface is needed to remotely administer the system, in particular given the backdoor fixed passwords. The best you can do is limit access to the IPMI interface via a firewall, and maybe by changing default ports if this is an option. Once exposed, an attacker will have the same access to the system as a user with physical system access. Remember that turning off a system may leave IPMI enabled unless you disconnect power or network connectivity. (Hacking Servers that are turned off)

[1] https://community.rapid7.com/community/metasploit/blog/2013/11/05/supermicro-ipmi-firmware-vulnerabilities

Johannes B. Ullrich, Ph.D.
SANS Technology Institute

Keywords: ipmi
3 comment(s)


It may not be possible to configure iptables on these devices, but you can still configure routing. You could set up a static route, via the correct gateway, to external IPs that should be allowed access; then remove the default route, so that packets from any other external IP will be dropped.

To isolate IPMI devices from each other in the same subnet sounds more complex. You'd need a static route to the gateway, static routes to allowed IPs via that gateway, then change to an artificially small subnet size. Be careful to not to lock yourself out if you try this. You may also be able to add blackhole routes to deny specific IP ranges.
On 05 Nov, Sourcefire published a new software patch for versions, Version, and Version with three security issues resolved, one of which deals with IPMI and CVE-2013-4782.

Their support site has this to say about the IPMI issue:

"Security Issue: Eliminated a vulnerability that could allow a remote attacker to execute unauthorized IPMI commands if Lights-Out Management was enabled on a Series 3 appliance. For more information, log in to the Customer Center and access the KB article at https://na8.salesforce.com/articles/Informational/000002045."

[the KB further says]:
"IPMI Vulnerability on Sourcefire Managed Devices

Vulnerability Description
The Intelligent Platform Management Interface (IPMI) on Series 3 managed devices is prone to a remotely exploitable vulnerability that allows a remote attacker to execute IPMI commands. To exploit this vulnerability, Lights-Out Management (LOM) must be enabled. An attacker could gain full access to IPMI functionality if they provided a valid username and configured cipher suite 0 to disable password authentication.

Mitigating Factors
By default, Sourcefire products are not configured with Lights-Out Management (LOM) enabled. Lights-Out Management is typically enabled on a secured management network not connected to the Internet. To exploit the vulnerability, an attacker must remotely access a device with Lights-Out Management enabled, enable cipher suite 0, and execute IPMI commands using a valid IPMI username.

As a workaround, disable Lights-Out Management for your Series 3 managed devices."
It is worth mentioning that the firmware on the Supermicro machine was written by ATEN Technologies, a Chinese company located in Taiwan. I do remember a US government contract a number of years ago to buy Lenovo comupters being canceled because they were made in China, the fear being that the hardware or firmware could have back doors.

Diary Archives