On August 28th, HP published a security bulletin regarding a critical vulnerability in HP Integrated Lights-Out (iLO) 4. This blog post aims at giving some details about this vulnerability, and a few hints for administrators to protect their servers. This research only applies to iLO version 4.

Context

This vulnerability has been found during a security study of HP iLO performed by Alexandre Gazet from Airbus and Fabien Perigaud. Now that a security bulletin and a fixed firmware have been released by HP (4 months ago), there is a significant risk that the vulnerability has been found by people doing binary diffing between two versions of the firmware. We thus decided to give some details so that HP iLO administrators could understand the impacts and protect their servers.

We plan to release the full details of our study in an upcoming conference, stay tuned!

Introduction

iLO is the server management solution embedded in almost every HP server for more than 10 years. It provides every feature required by a system administrator to remotely administer a server without having to reach it physically. Such features include power management, remote system console, remote CD/DVD image mounting, as well as many monitoring indicators.

All these features can be accessed using the IPMI protocol, but also through various interfaces such as SSH, HTTPS, SNMP, and XML / JSON APIs. All these interfaces represent a huge attack surface for a critical, embedded component.

Regarding the technical aspects, iLO 4 runs on a dedicated ARM micro-processor embedded in the server, and is totally independant from the main processor. It has a dedicated flash chip to hold its firmware, a dedicated RAM chip and a dedicated network interface. On the software side, the operating system is the proprietary RTOS GreenHills Integrity. Interestingly, the iLO runs even if the server is turned off, and is directly connected to the main PCI-express bus.

All its features and its crucial position in the server hardware makes iLO a really juicy target from an attacker's point of view.

Looking for vulnerabilities

iLO firmware can be directly downloaded from HP website. It is usually distributed as a PE file containing a big binary file which is sent to the iLO. Fortunately, the firmware is signed, but not encrypted, meaning that we can start looking for vulnerabilities without having to desolder the flash chip!

The most interesting target to look at is the webserver, which is very often exposed to the LAN, even if HP recommends to connect the iLO administration interface to a dedicated administration network. A quick Shodan indicates that some iLO interfaces are even directly connected to the Internet...

After a few hours of reverse enginnering to understand the memory layout and the various embedded libraries, the webserv binary can be correctly loaded in IDA Pro and analyzed.

Heap buffer overflow in HTTP headers processing

(CVE-2017-12542)

When a new client connects to the web server, one of its 4 threads handles the connection and starts parsing the HTTP request.

The parsing is handled in a function reading each line one by one, and trying to identify and parse the various possible HTTP headers.

When handling the Connection header, the sscanf() function is called with an insecure format string:

This insecure call results in a heap-based buffer overflow when processing an overlong Connection header. This can lead to arbitrary code execution if sensitive elements on the heap are overwritten; and from there to a full compromise of both the iLO and guest (server's) operating systems. This is not a theoretical threat, as we do have a full working exploit.

Affected products

iLO 4 is known to be embedded in HP ProLiant Gen8 and Gen9 servers.

Recommendations

Administrators running iLO interfaces on their network are strongly advised to upgrade to version 2.54 or greater (HP removed version 2.53 due to a stability issue) as soon as possible, as this vulnerability could lead to a complete server compromise.

HP iLO is an administration tool, and as such should only be accessible from an isolated VLAN, different from the users' VLAN. More specifically:

Do not connect iLO to your network if the interface is not actually used;

Do not expose any iLO interface to any untrusted network;

Use strong, randomly generated passwords for each server instance.

As a reminder, HP iLO 4 also exposes the IPMI interface on port 623. The IPMI v2 authentication protocol is affected by a design weakness that allows an attacker to retrieve a hash of the password, provided only the username is known. The hash can later be brute-forced off-line. This can not be patched or mitigated, except by proper network isolation.

Finally, as for every service running on a corporate network, iLO event logs should be centralized and monitored to detect unauthorized connections.

Timeline