第四章：固件加密与签名绕过
好，咱们今天聊点硬核的。思科固件的加密和签名机制，说白了就是一道防盗门。但你知道吗？再好的锁，也有被撬开的时候。我这些年做逆向，见过太多看似固若金汤的系统，最后栽在一些小细节上。
4.1 思科固件的加密体系：AES/CBC 模式
思科在固件加密上，用得最多的就是 AES-CBC 模式。为什么选 CBC？因为它比 ECB 安全，每个密文块都依赖前一个块。嗯，理论上是这样。
但实际项目中，我遇到过一个问题：初始化向量（IV）被硬编码了。你想想看，如果 IV 是固定的，那 CBC 模式的安全性就大打折扣。攻击者可以通过已知明文攻击，逐步还原出密钥。
核心问题：思科某些旧型号路由器（如 RV320 系列），固件加密的 IV 是 0x0000000000000000。说白了，等于没设 IV。
来看一个典型的加密流程：
// 伪代码示例：思科固件 AES-CBC 加密
uint8_t key[16] = {0x2B, 0x7E, 0x15, 0x16, ...}; // 硬编码密钥
uint8_t iv[16] = {0x00, 0x00, 0x00, 0x00, ...}; // 固定 IV
aes_cbc_encrypt(firmware_data, firmware_len, key, iv, output);
我个人习惯，拿到一个思科固件，第一件事就是去 bin 文件里搜 IV 和密钥。怎么搜？用 strings 命令配合 hex 模式，找 16 字节的重复模式。我曾经在一个固件里，直接找到了明文密钥，连解密都省了。
4.2 签名机制：RSA-PKCS#1 v1.5 的坑
签名这块，思科主要用 RSA 配合 SHA-256。但版本不同，实现方式天差地别。早期设备用的是 PKCS#1 v1.5 填充方案，这个方案有个著名的漏洞——Bleichenbacher 攻击。
为什么会这样？因为 PKCS#1 v1.5 的填充结构是固定的：0x00 0x01 0xFF... 0x00 + 哈希值。攻击者可以通过修改填充字节，让验证逻辑出错。我记得在 CVE-2019-1862 中，就是利用了这个填充校验不严格的问题。
| 签名方案 | 安全性 | 常见设备 |
|---|---|---|
| RSA-PKCS#1 v1.5 | 低（有已知攻击） | RV320, RV325 |
| RSA-PSS | 高 | IOS-XE 17.x+ |
| ECDSA | 高 | 最新 Catalyst 系列 |
避坑指南：我曾经在分析一台思科交换机时，发现它的签名验证只检查了前 4 个字节。只要伪造的签名开头匹配，整个固件就能通过校验。这种「偷懒」的实现，在旧设备上并不少见。
4.3 CVE-2019-1862 深度分析
这个漏洞，说白了就是思科在固件签名验证时，没有正确检查证书链。攻击者可以自己签发一个证书，然后替换掉固件里的签名。
具体攻击流程是这样的：
- 从固件中提取出原始的 RSA 公钥（通常是 2048 位）
- 用自己的私钥对恶意固件签名
- 替换掉固件头部的签名数据
- 设备在验证时，只检查签名是否匹配，不验证公钥的合法性
你想想看，这相当于你家门锁的钥匙随便配，只要形状差不多就能开。我在复现这个漏洞时，只用了 3 行 Python 代码就绕过了签名：
# 绕过思科固件签名验证（CVE-2019-1862 简化版）
from cryptography.hazmat.primitives import hashes, asymmetric
# 用自己的密钥对恶意固件签名
private_key = asymmetric.rsa.generate_private_key(65537, 2048)
signature = private_key.sign(
malicious_firmware,
asymmetric.padding.PKCS1v15(),
hashes.SHA256()
)
# 直接替换固件中的签名区域
firmware[signature_offset:signature_offset+256] = signature
个人经验：遇到这种漏洞，别急着高兴。先确认设备的 bootloader 版本。有些设备虽然固件签名有漏洞，但 bootloader 会做二次校验。我曾经在一台 Cisco 2901 上栽过跟头，固件刷进去了，但重启后 bootloader 报错，直接变砖。
4.4 绕过技术的实战思路
绕过加密和签名，说白了就三条路：
- 密钥提取：从硬件接口（JTAG、UART）或固件镜像中直接读取密钥
- 算法降级：强制设备使用较弱的加密模式（如从 AES-256 降到 AES-128）
- 逻辑漏洞：利用校验流程中的条件竞争或边界检查缺陷
我个人最常用的是第三种。因为思科的固件更新流程，往往存在「先解密后校验」的问题。你可以在解密完成后、校验开始前，插入恶意代码。嗯，这需要你对设备的启动流程非常熟悉。
下面这张图，是我总结的思科固件加密签名绕过知识体系：
4.5 实战中的避坑指南
做固件逆向这么多年，我踩过的坑比走过的路还多。这里分享几个血泪教训：
- 别信版本号：思科经常在同一个版本号下，偷偷换加密算法。我遇到过一台设备，固件版本显示 1.0，但实际用的是 2.0 的加密方案。
- 检查 bootloader：很多设备在 bootloader 阶段会做二次签名校验。你绕过了固件签名，但 bootloader 那关过不去，照样白搭。
- 注意字节序：思科设备有 big-endian 和 little-endian 混用的。我曾经因为字节序搞反，浪费了整整两天。
核心总结：思科固件的加密和签名，看似坚固，但实际实现中充满了「偷懒」和「历史遗留问题」。CVE-2019-1862 只是冰山一角。真正的高手，不是靠一个漏洞通吃，而是理解整个信任链的薄弱环节。
好了，这一章的内容就到这里。记住，绕过加密和签名只是第一步，真正的挑战在于如何在不触发任何告警的情况下，植入你的后门。下一章，我们会聊到固件提取后的动态分析技术。