Exploiting iLO: The Dangers of Out-of-Band Management Systems

Lab Environment

This exploit chain was performed on a device with the following specifications:

• Model: Hewlett Packard Enterprises (HPE) ProLiant ML310e Gen8 v2 Server
• iLO Version: HPE iLO 4, firmware version 2.50 unless otherwise stated
• Host OS: Windows Server 2016 Standard Edition

Introduction

During internal network penetration tests, I have seen us obtain access to an out-of-band (OOB) management system interface many times, write it up as a finding, and simply move on. The report would then explain in a generalized manner that attackers can use these OOB systems to compromise the underlying server.

Eventually, some of us started asking: why don’t we?

And so, we sought to outline a proof-of-concept (PoC) exploit to get from OOB management access as far as domain credentials. Notably, we wanted this PoC to work without relying on social engineering or the action of an authorized administrator. That said, there exist a variety of OOB management implementations, and so we had to make a choice.

One of the most common OOB management systems that we run into during tests here at K logix is HPE’s Integrated Lights-Out (iLO). For those unfamiliar, iLO provides remote, hardware-level access to the host device, allowing an administrator to control the power, apply patches, and upgrade the operating system remotely. This can be done most directly through iLO’s remote console, which provides a direct interface with the host server that uses the same session that an administrator would have if they were accessing the device in person. Intuitively, this already seems dangerous should an attacker gain access to an iLO instance. So surely, authenticating into iLO has to be quite secure, right? Not quite.

Preface: Ways to Get Initial Access to iLO

What a surprise! Out-of-date software/firmware is all too common to find on internal network tests. As such, it’s not so rare to find a device vulnerable to a long-known vulnerability (CVE-2017-12542), originally described by Synacktiv [1]. Synacktiv documented working exploits that achieve a variety of effects, including authentication bypass and remote code execution (RCE), on iLO 4 firmware versions prior to 2.53 and 2.54. That said, there exists one key caveat: in Synacktiv’s demonstrations, they show that the HTTP Connection: header is vulnerable to buffer overflow. In versions after 2.00, due to how the Redfish-like iLO RESTful API is set up, there exists a localConnection flag that, when set to any nonzero number, allows unauthenticated requests to complete. This applies to the user creation endpoint, making it possible for an attacker to create an iLO administrator account without credentials. However, in prior versions (e.g., 1.53), the older REST API implementation does not allow unauthenticated requests to complete when launching the same buffer overflow attack. Outside of this case, the tools provided by Synacktiv are highly effective in gaining access to an iLO web portal.

Leveraging weak passwords is another easily preventable but common occurrence. The Intelligent Platform Management Interface (IPMI) is meant to monitor and control these systems at scale, in an automated way. For whatever reason, the IPMIv2 standard responds to a certain message query with the salted SHA1 or MD5 password hash given that account’s username. As usernames such as root and admin are common, there exist tools such as Metasploit Framework’s ipmi_dumphashes module [2], which iterates over them, attempting to retrieve password hashes from any IPMIv2-compatible system, including iLO 4. These hashes can then be cracked offline to gain access to the iLO 4 web portal:

PWNing the Host: An Exploit Proof of Concept (PoC)

iLO 4 has several means of accessing a remote console. Using a Windows device or VM makes using the .NET integrated remote console (IRC) simple.

Being able to boot into the device doesn’t necessarily mean we can access any important data, as the host OS will still require authentication. As such, we need to get our own interface with the device. The easiest solution? Hosting a live-boot instance of Kali Linux on our target server. Using the live-boot Kali ISO (version 2026.1) from the official website [3], we inserted it as a CD-ROM/DVD image file into the IRC through the “Virtual Drives” tab, as seen below:

Booting into the Kali ISO provides another boot menu. Choosing any of these options will boot into Kali’s desktop environment, but this took too many computational resources to be feasible in this lab environment, causing the desktop environment to be extremely laggy and causing drive mounting issues. As a solution, modify the boot command as follows:

1. Highlight the “Live system (amd64)” option
2. Hit the Tab key to show the command
3. Append 3 to the end of the command to boot with runlevel 3 (indicating text-only mode for Kali). Optionally, remove the quiet and splash keywords to avoid the splash screen and see systemd boot messages

This opens a command-line interface (CLI) to a Kali instance with root access. First things first, we need to identify the target: the Windows Server storage device. Looking at the device files in /dev/, there were two main storage device files, /dev/sda and /dev/sdb, each with two partitions:

Using fdisk to gather metadata on these devices showed that /dev/sda and /dev/sdb were mirrors of each other. Furthermore, the size of the partitions indicated that /dev/sda2 and /dev/sdb2 were the partitions with the Windows Server files:

Great, so now we can just mount one of these partitions, right? Well, not quite yet. One barrier remains. Windows has a fast startup feature which puts the system in a hibernation-like state when shutting down, storing some memory state data persistently. For us, that ultimately means that Windows ends up locking the filesystem [4]. As such, trying to mount fails.

Luckily, this is a very simple fix. Using ntfsfix [5] restores the device to a mountable state:

Now, mounting works properly, giving us read-write access to the main Windows drive.

With the Windows filesystem mounted, we can run Impacket’s secretsdump [6] tool to discover locally stored secrets, including hashed local credentials, DPAPI keys, and the NL$KM key.

And done! In this lab environment, this just dumps various local keys and hashed credentials. However, in a production environment, this server may have cached hashed domain credentials. Even if there aren’t cached domain credentials, it’s also quite common for local administrator passwords to be reused across systems. In some environments, we’ve even seen local admin passwords being reused for domain user accounts!

Spooky Action at a Distance

Technically, one could host the entire Kali Linux ISO in an Apache server’s webroot, provide a link to it in the “Scripted Media URL” field under “Connect CD/DVD-ROM,” and press the “Insert Media” button. This will have the same effect as above (except for taking an age and a half for the OOB management server to download it). After doing this, boot or reboot the system, and the live/installation media will be available to the managed system. (Please use the “Live” version.) If any tools are missing, create floppy disks for all the tools you need: download the tool you need, create a “virtual” floppy disk, then use the “Connect Virtual Floppy” menu options to attach the downloaded tool installer to the live Kali instance running on the managed system. Seems archaic, but here it is at work with kpartx:

Place each of these in the same webroot as the Kali Linux ISO and one-by-one provide a link to them in the “Scripted Media URL” menu item after pressing “Insert Media” under the “Virtual Floppy/USB Key/Virtual Folder Status” button. Use the dmesg command to identify the new device with 1.474 MB disk space, mount it, and install the contained tools by entering the following on the managed system:

Following these steps, you can load your managed target system in Kali Linux and equip it with almost any tool you need.

Limitations

Given the simplified nature of this lab environment, there are many important caveats. Within a realistic enterprise environment, there may be additional barriers in place. For example, here are some of the many possibilities:

• The host server has full-disk encryption (FDE): This would reduce the impact of this specific attack path, as an attacker could not mount any meaningful data.
• The host server is a hypervisor hosting multiple guest virtual machines (VMs): This is quite common to see in enterprise environments. Rather than sensitive data being on the host server, it will exist in guest VM filesystems. This does not prevent this attack path, as it only adds some complexity to mounting the guest filesystems.
• This likely requires rebooting the managed server. On a penetration test in a non-test and non-dev environment, if the managed servers are not already down, this could cause unpalatable production outages and should be discussed with project stakeholders first.

Impact

Given that iLO is a side feature of certain HPE servers by default, some network administrators fail to keep iLO firmware up to date. As such, this exploit chain has already seen use within our internal network penetration tests, making it much clearer to these administrators why weak iLO passwords or outdated iLO firmware versions are so dangerous and how critical it is to implement consistent, network-wide auditing procedures to prevent weak password usage and keep software and firmware updated.

References

[1] Synacktiv HP iLO Talk at Recon Brx 2018

https://www.synacktiv.com/en/publications/hp-ilo-talk-at-recon-brx-2018

[2] Metasploit Framework ipmi_dumphashes Module Github Documentation

https://github.com/rapid7/metasploit-framework/blob/master/documentation/modules/auxiliary/scanner/ipmi/ipmi_dumphashes.md

[3] Kali Linux live-boot

https://www.kali.org/get-kali/#kali-live

[4] Windows fast startup

https://learn.microsoft.com/en-us/windows-hardware/test/weg/delivering-a-great-startup-and-shutdown-experience

[5] ntfsfix manual page

https://linux.die.net/man/8/ntfsfix

[6] Impacket GitHub

https://github.com/fortra/impacket