MikroTrick 实验室 PoC — CVE-2026-67276（RouterOS SSH 公钥认证绕过）

仅供实验室使用。 仅可针对您自己拥有的 RouterOS 实例运行。 攻击非您拥有的设备属于犯罪行为（CFAA、波兰刑法第 267 条及相应法律）。

背景

CERT PL（2026-09-05）披露了六个 RouterOS 漏洞，这些漏洞在野外被积极利用，构成攻击链 “MikroTrick”（当 SSH 可被互联网访问时，可实现未认证的完全设备接管）。MikroTik 已于 2026-09-03 在 7.25beta3 / 7.24.2 / 7.23.4 / 6.49.21 版本中修复。

受影响版本范围（全部六个）：[7.24, 7.24.2)、[7.0.0, 7.23.4)、[6.0.0, 6.49.21)。

CVE-2026-67276 机制

1. RouterOS 根据 (密钥类型、模数) 将提交的 SSH 公钥 blob 与用户的授权密钥进行匹配 — 不比较指数。
2. 签名验证使用客户端提供的密钥，即攻击者 blob 中的指数。
3. 提交 {ssh-rsa, e=1, n=victim} 使得 sig^1 mod n == sig，因此有效的“签名”仅仅是 EMSA-PKCS1-v1_5(hash, authdata) — 任何知道受害者公钥模数的人都可以计算。无需私钥。
4. 结果：以目标用户身份获得 SSH 命令通道。

前提条件（披露文档自身的最低要求）：目标用户名 + 该用户授权的 RSA 公钥模数。

复现所需的最少信息

1. 目标：受影响版本范围内的任何 RouterOS，SSH 可达（实验室：QEMU + KVM 中的 CHR 镜像；真实硬件等效）。
2. 具有授权 RSA 密钥的账户的用户名。
3. 该授权密钥的 RSA 模数 n（来自泄露/捕获的 .pub 文件、配置记录或 --modulus-hex）。这是唯一接近机密的输入；永远不需要私钥。
4. 披露确认的服务器行为（缺陷本身，来自 CERT PL）：匹配 = (type, n)，验证指数 = 客户端提供的。
5. 能够提交任意密钥 blob 和任意签名字节的客户端（paramiko + ForgeKey 钩子 — 标准 OpenSSH 无法做到）。
6. 服务器接受的签名算法（6.x 上为 ssh-rsa，7.x 上还支持 rsa-sha2-256）。

文件

• forge_67276.py — 原语：OpenSSH 公钥解析、RFC 8017 EMSA 编码器、伪造 blob/签名构建器、参考 RFC 8017 验证器。
• selftest.py — 本地证明，无需路由器：编码器与 OpenSSL 字节一致（通过真实签名反转）、伪造签名在 e=1 时验证通过而在 65537 时验证失败、完整的 RFC 4252 §7 线格式模拟。全部 15 项检查通过。
• poc_67276.py — 执行绕过的 paramiko 客户端（每连接算法固定；需要 --lab-i-own-this-target）。
• console_setup.py — 通过 qemu 串口 telnet 进行的一次性 CHR 准备（通过 10.0.2.2 获取受害者密钥、为 admin 导入、启用 ssh）。
• sanity_real_key.py — 对照组：正常公钥认证必须首先成功。
• victim_rsa / victim.pub — 生成的一次性 2048 位“受害者”密钥对；有意从 Git 中排除。

本地设置

python3 -m venv .venv
./.venv/bin/python -m pip install -r requirements.txt
ssh-keygen -q -t rsa -b 2048 -N '' -C victim-key -f victim_rsa

实验室（配置于 [email protected]）

• Kali x86_64、QEMU 11.0.1 + KVM、/root/mikrotrick-lab/、主机桥接 br0（192.168.100.1/24），带 tap0-tap3；br0 上运行 dnsmasq，按 MAC 分配租约。

• 预期的客户机状态：e1000 NIC、静态客户机 IP、admin 密码 labpass123、为 admin 导入受害者密钥。首次登录强制修改密码通过 SSH（bootstrap_password.py 读取对话框）或 QEMU 监视器 sendkey（mon_type.py）完成 — CHR 的串口控制台默认不可用；VGA 控制台只能通过监视器 screendump 读取。
• 从 Mac 建立隧道： ssh -N -L 2222:192.168.100.11:22 -L 2223:192.168.100.12:22 -L 2224:192.168.100.13:22 -L 2225:192.168.100.14:22 [email protected]

重新运行（示例，VM3）：

qemu-system-x86_64 -enable-kvm -m 512 -smp 2 -name chr-7.23.3 \
  -drive file=/root/mikrotrick-lab/chr-7.23.3.img,format=raw,if=virtio \
  -netdev tap,id=n2,ifname=tap2,script=no,downscript=no \
  -device e1000,netdev=n2,mac=52:54:00:aa:00:13 \
  -display none -monitor unix:/root/mikrotrick-lab/mon3.sock,server,nowait &

./.venv/bin/python import_key.py 127.0.0.1 admin labpass123 victim.pub 2224
./.venv/bin/python sanity_real_key.py 127.0.0.1 2224 victim_rsa admin   # 基线
./.venv/bin/python poc_67276.py --host 127.0.0.1 --port 2224 \
    --username admin --pubkey victim.pub --algos rsa-sha2-256,ssh-rsa \
    --exp-enc aligned --exec '/system resource print' --lab-i-own-this-target

观察结果（2026-09-06 独立复验）

对于 7.x 对，真实密钥基线在两个构建版本上均成功，SSH none 认证被拒绝，错误模数的伪造被 7.23.3 拒绝，而正确模数的伪造仅在 7.23.3 上成功。这是一个有效的易受攻击与已修补对比。

6.49.21 客户机在独立复验期间未按文档配置：admin 仍处于过期状态，/user ssh-keys print detail 为空，且无凭据的 SSH none 请求执行了命令。因此，无关的真实 RSA 密钥和错误模数的 e=1 密钥也似乎成功。在将其用作已修补对照组之前，请重新配置此客户机并验证 none 和无关密钥均被拒绝。

版本细微差别： 在 6.49.20 上，服务器端匹配拒绝了 e=1 blob（/log ssh,debug：can't find matching key for user: admin）— 披露的指数省略在 6.x 的匹配器中不可观察，尽管 CERT 的总体范围列出了 [6.0.0, 6.49.21)。已确认易受攻击：7.23.3。已确认已修补：7.23.4。当前 6.49.21 实验室状态无法证明任一结果。野外的 MikroTrick 活动也针对 7.x 设备。

线格式发现（RFC 8332）： blob 的内部类型字符串即使对于 rsa-sha2-256/512 签名算法也保持为 ssh-rsa；签名算法仅出现在外部算法字段中。忽略这一点会导致服务器在 userauth 中途断开连接（blob 解析错误）— 在 6.x 和 7.x 上均观察到。PoC 的 ForgeKey 处理了这一点，--exp-enc aligned|canonical 切换 e=1 mpint 宽度（1 字节 vs 3 字节）。在 7.23.3 上两种宽度均可认证 — 匹配器解析指数并真正忽略其值。在 6.49.20 上两者均无法认证（can't find matching key）— 请参阅上述版本细微差别。服务器端 /system logging add topics=ssh,debug + /log print 数据包十六进制转储揭示了所有这些信息。

本实验室使用的源镜像归档 SHA-256 值：

a954ab0002a83de5e4c02110f560d0bf622e7d21916088aaacda6baaba88cf4a  chr-6.49.20.img.zip
6dcfb8674fa7964bf92ce849fbb0ba8147a5cf3d7a1ba595e24ce3e615569188  chr-6.49.21.img.zip
646764fb0a53e9b5a056cb9cf7420eb1629031096c7268c99fb9216c07f8e98c  chr-7.23.3.img.zip
0d32a8da0950dee71e751281c39063f2bebee4b542291aedecc9dbfbe5d60c9d  chr-7.23.4.img.zip

防御说明（CERT PL）

• 立即修补：7.25beta3 / 7.24.2 / 7.23.4 / 6.49.21。
• 临时措施：将 SSH/WWW/bandwidth-test 限制在可信管理网络内；避免从未修补设备发起 RouterOS 发起的 SSH/TLS 连接。
• IOC：日志行 login failure for user -2 via ssh、user <name> added by ssh:-2@<ip>；未知的高权限用户 ops；/system/device-mode/print 中的 “Flagged” 标记（表示已被入侵，其缺失不能证明任何事）。观察到的攻击者 IP：82.192.72.4、103.102.31.18。

来源

• CERT PL 公告：https://cert.pl/en/posts/2026/09/vulnerabilities-in-mikrotik-routeros-actively-exploited/
• CERT PL CVE 页面：https://cert.pl/en/posts/2026/09/mikrotik-routeros-cve/
• MikroTik 公告（2026-09-03）：https://mikrotik.com/supportsec/september-2026-vulnerability/
• “Flagged” 机制：https://manual.mikrotik.com/docs/system-information-and-utilities/device-mode#flagged-status