Netcore NAP930 的免凭据 root 通道（CVE-2026-102240）

原创

云梦DC
云梦DC

云梦安全

2026年9月30日 08:51
河南

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

01  结论先行

这个漏洞的编号是 CVE-2026-102240，受影响的是 Netcore 出品的 NAP930——一款面向企业市场的 WiFi 6 接入点。它的 network_tools CGI 允许未通过身份验证的调用者注入操作系统命令，评分 CVSS 10.0。只要身处同一网段，任何人都能借一条手工拼装的 GET 请求，以设备最高权限执行任意指令。已经公开的 PoC 在固件仿真环境中完成了动态验证，并附有取得 root shell、读到 /etc/shadow 的完整记录。披露方在公开前尝试联系厂商，没有得到答复，这也是 9 月里 Netcore 设备第二次出现零响应。

这个漏洞真正值得拆解的地方，并不是“设备上存在命令注入”本身，而是两处实现上的错位被叠在了一起：负责净化的例程处于注释状态，而会话校验的位置又被安排到了输入执行之后。单独看任何一处都谈不上致命，凑在同一段脚本里，就构成了一个无需凭据的 root 入口。

02  漏洞档案

03  根因不在函数本身，而在执行顺序

出问题的文件是 /www/cgi-bin/network_tools，一个用 POSIX shell 编写的 CGI。两处缺陷互相配合，串成了完整链条。

第一处，本该生效的净化没有被执行。脚本确实写了 urldecode() 这个消毒例程，可真正调用它的那一行被注释掉了。于是 uhttpd 交给 CGI 的原始 QUERY_STRING 完全跳过 URL 解码环节，被直接按 & 切分成一组组键值对。

第二处，命令先于身份校验落地。切分得到的键值对被立刻交给 eval \"${key}='${val}'\" 处理，而 sid 的会话比对被排到了这段 eval 后面。输入先执行、身份后检查——校验没通过，响应里只会多出一个 result:[6] 错误码，可命令在返回这个错误码之前就已经跑完了。排查时最容易误判的一点就在这里：看到错误码，并不代表利用失败。

payload 的构造因此显得相当朴素：用单引号把 sid 值的前引号闭合，接上分号，再写入任意命令，末尾用 :'' 让引号重新配平（引号一旦不闭合，busybox 的 ash 会直接终止整个脚本）。空格不能写成 %20——既然解码这一步被跳过了，它只会作为字面量留在命令中，因此必须改用 ${IFS}。

还有一个值得对照的细节：hello、telnet、upgrade 这三个与它同目录的 CGI，走的是另一条路——先借助 printf 完成解码，再交给 eval，其中单引号会抑制参数展开，所以它们安然无恙。同一版固件里并存两套写法，好坏对比摆在眼前，更能说明问题来自个人编码风格，而非框架本身——这种“同一厂商、不同 CGI 写法不一致”的现象，在设备固件里相当常见。

04  从一条 GET 请求到高权限 shell

公开 PoC 分成两步：先把命令的输出落到 Web 目录，再把它取回来。

# 第一步：把 id 的执行结果写进站点根目录
curl \"http://target/cgi-bin/network_tools?sid=';id>/www/pwn.txt;:'\"

# 第二步：读回上一步写下的文件
curl \"http://target/pwn.txt\"
# uid=0(root) gid=0(root)

本文的实验在一台隔离的固件仿真件上完成，复现件按公开披露的实现缺陷等值构造，执行主体是仿真机上的当前用户，并非真实设备——上面这段 uid=0(root) 属于设备侧 PoC 记录，仿真的价值在于验证“输入先执行、身份后校验”这条链路本身成立。

注意截图的顺序：响应体先给出 {\"result\":[6]}，看起来像是被拦下了；紧接着把写进 Web 目录的文件取回来，得到的却是设备配置的完整内容，里面包括两张 SSID 与其中一张的 Wi-Fi 预共享密钥。换句话说，错误码只是响应层的表象，命令早就执行完毕。

拿到命令执行之后，想要一个稳定的交互式 shell 也有现成路径。固件里那个 busybox 版本的 nc 属于精简编译、不含 -e 选项，不过 telnetd 在这款固件的开机脚本里是会自动拉起的（/etc/rc.d/S90telnet），于是可以直接让它绑一个 shell 出来：

sid=';telnetd${IFS}-p${IFS}2323${IFS}-l${IFS}/bin/sh;:'
# 随后连接目标的 2323 端口

权限到手之后，影响就不止“设备被控”这一层了。设备配置文件中的 Wi-Fi 预共享密钥、DDNS 账号口令等敏感内容均处于可读状态；通过写入 flash，可以留下重启后依然生效的持久化后门；这台 AP 同时也就成了进入它所承载的整个无线与有线网络的跳板。再加上出厂默认 root 口令为空这一点，攻击者眼中的 NAP930，与一台直接暴露在局域网内的高权限终端并无区别。

05  排查：流量侧与设备侧一起看

流量侧：把 /cgi-bin/network_tools 上的 GET 访问纳入网关与安全设备的监控范围。当 URL 的查询参数部分同时混入分号、单引号、${IFS} 这类字符组合时，应当立刻告警——正常业务请求不会携带它们。

设备侧：确认 /www/ 下有没有凭空多出来的文件（把执行结果重定向进 Web 目录再取回，是这轮攻击最典型的手法）；确认 telnetd 有没有在非预期情况下被拉起；确认 crontab 与启动脚本中是否出现新增条目。

排查重点场景：写字楼、连锁门店、酒店这类以 NAP930 作为无线覆盖设备的场所。AP 一旦被植入后门，经过它的所有终端流量都处在攻击者的观察范围内。

06  加固清单（厂商暂无补丁）

截至发文，厂商没有回应，官方补丁自然也不存在，只能先做缓解，按优先级排列：

1. 把 AP 的管理面与用户网段隔开：只允许运维 VLAN 访问 uhttpd 的 23355 / 443 / 80 端口。
2. 把 telnetd 的开机自启关掉（/etc/rc.d/S90telnet）。
3. 更改设备出厂的 root 空口令。
4. 环境里做不到管理面隔离的，考虑临时下线或更换设备。

需要补一句：以上四条降低的是“可达性”，而不是把漏洞本身修好了。CGI 自身的缺陷依然存在，因此隔离措施要长期保持，直到厂商发布正式固件更新为止。

07  一句话总结

一个被注释掉的净化调用、一次位置放错的认证检查——两处“看起来不影响功能”的改动叠加起来，就把一台企业级 AP 变成了免凭据的 root 终端。设备类漏洞的治理最终都会回到同样的三件事：管理面收进内网、出厂口令改掉、无关服务关掉。