华为HG532远程代码执行漏洞复现
兜兜转转终于是上手开搞iot了。
Description
- 该远程命令执行漏洞存在于华为HG532路由器，由Check Point安全人员纰漏。
- 华为设备中的TR-064实现通过37215端口（UPnP）暴露在广域网。
- 从设备的upnp描述中有一个叫
DeviceUpgrade的服务，该服务通过向/ctrlt/DeviceUpgrade_1（称为controlURL）发送请求来执行固件升级。 - 并通过两个元素
NewStatusURL和NewDownloadURL执行。 - 该漏洞允许远程管理员通过在 NewStatusURL 和 NewDownloadURL 中注入 shell 元字符“$（）”来执行任意命令。
这里有我找的一份固件，可以在这里下载：click here
开搞！
配置环境
真正的解决方案在这里，笔者最终还是去折腾网桥了（
1. 问题诊断
根本原因：网桥
br0下缺少tap0接口。执行sudo brctl show br0只显示：
2bridge name bridge id STP enabled interfaces
br0 8000.9a6776f76b27 no ens33没有
tap0，导致 QEMU 虚拟网卡无法连接到网桥，宿主机与 QEMU 之间无法通信。2. 解决方案
第一步：创建并配置 tap0
2
3
4sudo tunctl -t tap0 -u pwn # 创建 tap0 设备
sudo ip link set tap0 up # 启用 tap0
sudo brctl addif br0 tap0 # 将 tap0 加入网桥
sudo brctl show br0 # 验证（现在应该看到 tap0）
2
3
4
5
6
7
8sudo 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,macaddr=00:16:3e:00:00:01 \
-net tap,ifname=tap0,script=no,downscript=no \
-nographic关键点：
-net tap,ifname=tap0,script=no,downscript=no明确指定使用已创建的tap0。在 QEMU 内配置 IP
2
3ifconfig eth1 192.168.138.131 netmask 255.255.255.0 up
route add default gw 192.168.138.1
ping 192.168.138.130 # 验证连通性successed!
264 bytes from 192.168.138.130: icmp_req=1 ttl=64 time=5.06 ms
5 packets transmitted, 5 received, 0% packet loss网络跑通后可以继续了
2
3
4
5
6
7
8
9
10
11
12
13
14cd /root/rootfs && chroot . sh
./bin/upnp &
./bin/mic &
我这里使用端口转发方案，就不去折腾网桥了。
然后是解包固件：
```bash
wn@pwn:~/Desktop/HUAWEI-HG532$ cd _HG532eV100R001C02B015_upgrade_main.bin.extracted/
pwn@pwn:~/Desktop/HUAWEI-HG532/_HG532eV100R001C02B015_upgrade_main.bin.extracted$ ls
180 180.7z DC080.squashfs squashfs-root
pwn@pwn:~/Desktop/HUAWEI-HG532/_HG532eV100R001C02B015_upgrade_main.bin.extracted$
下载qemu需要的文件：
1 | |
启动：
1 | |
打开另一个终端，拷贝固件文件系统：
1 | |
如果上述没有办法成功拷贝的话那就是网络配置出现了问题，现在我们来搞一下qemu里面的网络配置：
1 | |
然后在解包的目录下用python跑一个http-server然后在qemu中下载：
1 | |
这里又踩了一个坑，我们解压出来的
squashfs-root目录是空的，这是因为这种文件还需要我们用unsquashfs去解压，但是华为可以改了格式，这里我们使用Firmware Mod Kit去解压
然后打包下载
之后我们进到qemu所在窗口：
1 | |
漏洞分析
我们可以在 /firmware-mod-kit/fmk/rootfs/bin 文件夹内找到存在漏洞的upnp二进制文件，并使用checksec upnp查看其信息：
1 | |
可以看到，这是一个32位大端序的mips架构下的二进制文件，并且没有开任何保护。
根据官方的漏洞报告，我们知道漏洞存在于 /bin/upnp 和 /bin/mic二进制文件中，先将其拖进IDA中进行逆向分析：
main函数里有对网络服务进行初始化的核心调用，跟进init函数，会发现里面是个循环，循环次数是第二个参数5，然后对m_astInetdApps数组中的每一项操作，跟进数组
进来之后看到这里跑了一个Socket Server，根据Socket参数定义设想v16为IP地址，我们看看这个v16是怎么定义的：
我们这里来解释一下：
v16 = v31;：v31 是解析出的 IP 地址字符串if ( !v28 ) v16 = 0;：0 = NULL = INADDR_ANY
而对应如下：
- 配置字符串格式为 服务名|IP|端口|命令
- v16 从解析出的 IP 字段赋值
- 0 在 socket 编程中代表 INADDR_ANY（绑定所有接口）
由此我们可以得出：固件没有限制该服务只能绑定在内网接口（LAN 口），导致它绑定到 0.0.0.0（所有接口），从而暴露在广域网（WAN）侧，互联网上的攻击者可以直接向该端口发送特制的 SOAP 数据包，触发命令注入漏洞，实现远程代码执行。
接下来是具体存在漏洞的文件：
在main函数中就可以看到server1监听37215端口，然后去看ATP_UPNP_Init这个upnp框架的初始化函数
看到注册upnp设备和服务的函数，继续跟进，然后就能看到整个TR-064服务的服务注册与功能注册函数，然后跟进功能注册：
从官方漏洞报告中我们得知id为21的action对应Upgrade，注册这个action的句柄是从 v9 = ATP_UPnP_RegService(v33, "WANPPPConnection:1", "WanPppConn.xml", 3, 1, 0, &v34); 处返回的。
之后一样跟进v66那个函数：
通过前面一些不知何意味的条件之后就来到了 g_astActionArray
跟进到这个函数地址：
这就是DeviceUpgrade服务的action函数，它从 SOAP 请求中提取 NewDownloadURL/NewStatusURL 参数，没有任何过滤，直接拼接后（因为;会连接两个独立语句）通过 system() 执行，导致RCE了。
Exploit
1 | |
