MikroTrick攻击链PoC复现：CVE-2026-67276 SSH认证绕过漏洞分析

导语：MikroTik（迈克罗蒂克）路由器正经历一场静默屠杀。波兰CERT（计算机应急响应小组）2026年9月5日披露的MikroTrick攻击链已被攻击者规模化利用，安全研究员Nicolas Krassas（昵称dinosn）随即公开完整PoC（Proof of Concept，概念验证代码）至GitHub。攻击者只需知道用户名和授权用户的RSA模数n，无需私钥即可登录SSH——这套e=1指数伪造手法，堪称教科书级别的加密实现灾难。

一、事件背景：路由器界的OpenSSL心脏滴血重现

MikroTik RouterOS是全球部署量最大的路由器操作系统之一，从家庭宽带到企业机房都能见到它的身影。这套系统由拉脱维亚厂商MikroTik开发，凭借硬件性价比和稳定性吃下了大半个欧洲和东南亚市场。然而这种”一台跑十年”的设备文化，在漏洞爆发时变成了灾难。

CERT Polska（波兰计算机应急响应中心）研究团队借助OpenAI的GPT-5.5-cyber和GPT-5.6-sol模型，在受控实验环境中发现了六个RouterOS漏洞，并将其中两个的组合命名为”MikroTrick”攻击链。两个核心漏洞分别为：

9月2日，距离官方补丁发布前24小时，单个IP 82.192.72[.]4（Leaseweb机房）已开始大规模扫描互联网暴露的MikroTik SSH服务。这是典型的”补丁泄露倒计时”攻击模式——有人从版本差异中逆向了漏洞细节，赶在管理员打补丁前收割肉鸡。

二、技术核心：e=1指数伪造原理

RSA签名的数学原理是 sig = m^d mod n，其中d是私钥指数，n是模数。验签过程是 sig^e mod n = m，其中e是公钥指数（标准值65537）。如果e=1，那么 sig^1 mod n = sig，意味着”任何消息的哈希本身就是合法签名”——根本不需要私钥。

RouterOS的SSH认证流程存在致命缺陷：匹配授权密钥时只比较密钥类型和模数n两个字段，完全忽略指数e。更糟的是，签名验证时直接使用客户端提交的公钥进行验算，而非匹配时记录的公钥。

整个攻击链的数学逻辑如下：

1. 攻击者获取目标用户的授权RSA公钥，从.pub文件中提取模数n
2. 构造伪造公钥：保持类型为ssh-rsa，模数n不变，但指数e=1
3. 计算”签名”：直接对会话标识符做EMSA-PKCS1-v1_5编码（这就是”合法签名”，因为sig^1=sig）
4. RouterOS匹配到该公钥（因为类型和n一致），用伪造公钥验签通过
5. SSH会话建立，攻击者获得目标用户权限

整个过程不需要私钥、不需要暴力破解，只需要一个公开的模数n。这套攻击对7.x版本RouterOS稳定有效。

三、MikroTrick攻击链完整复现

dinosn在GitHub开源的dinosn/mikrotrick-poc项目提供了从0到1的完整实验室复现方案，核心文件包括：

• forge_67276.py：伪造公钥和签名的核心原语，包含OpenSSH公钥解析、RFC 8017（RSA密码标准）EMSA编码器、参考验签器
• selftest.py：本地自测脚本，包含15项检查，覆盖编码器字节一致性、e=1验签通过、e=65537验签失败等关键路径
• poc_67276.py：基于paramiko（Python SSH库）的攻击客户端，通过ForgeKey钩子注入伪造公钥
• console_setup.py：通过QEMU串口telnet一次性配置CHR（Cloud Hosted Router，云路由器镜像）

实验室环境由4台CHR虚拟机组成（Kali + QEMU + KVM加速），覆盖vulnerable/patched的6.x和7.x版本组合。dinosn在2026-09-06的独立复现结果如下：

确认可利用版本：7.23.3。野外攻击同样针对7.x设备。

四、实战命令：从扫描到root

完整PoC执行流程只需要几条命令。前提条件是目标RouterOS SSH端口可达，且攻击者已知用户名和该用户授权RSA密钥的模数n。

环境准备阶段，使用QEMU启动漏洞版CHR镜像：

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

发起e=1伪造攻击（必须加--lab-i-own-this-target参数作为安全护栏）：

./.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

攻击成功后会直接拿到SSH命令执行通道，结合CVE-2026-86060的用户名首字符注入（用户名以-开头触发参数注入修改策略掩码），最终获得完整管理员权限。从SSH握手到拿到root，全程不超过3秒。

五、攻击痕迹与威胁狩猎清单

CERT Polska已经确认多起真实入侵事件，攻击者主要从82.192.72[.]4发起，备用IP为103.102.31[.]18。建议运维人员立即排查以下痕迹：

• 日志条目：login failure for user -2 from <ip> via ssh（失败的认证尝试）
• 日志条目：user <name> added by ssh:-2@<ip>（可疑用户创建）
• 异常用户：名为ops的高权限账户（攻击者偏好命名）
• Flagged标记：/system/device-mode/print显示Flagged字段，表示MikroTik官方扫描器已检测到入侵痕迹

攻击者服务器上还托管了三个工具文件：

服务器上还发现一个2010年编译的MIPS架构BusyBox二进制文件，与官方BusyBox 1.16.1预编译版本完全一致——这是攻击者在目标路由器上植入的持久化载荷。

六、防御方案：立刻做的事

MikroTik官方已发布修复版本：7.25beta3 / 7.24.2 / 7.23.4 / 6.49.21。补丁是历史上第一次通过MikroTik手机App推送通知给用户，足以说明事态严重性。

升级后的标准处置流程：

• 升级到修复版本后立即执行/system/device-mode/print，检查Flagged标记
• 检查/user print、/user ssh-keys print是否有未知账户或密钥
• 检查/system scheduler print、/system script print是否有可疑定时任务或脚本
• 检查/ip firewall filter print是否有异常的端口转发或代理规则

临时止血方案（无法立即升级时）：禁用对外暴露的SSH、WWW/WWW-SSL、bandwidth-test服务，限制仅从可信管理网段访问。RouterOS内置的SSH客户端（/system ssh和/system ssh-exec）在未打补丁前同样危险，禁止向不可信主机发起连接。

七、结语：被遗忘的设备终成肉鸡

MikroTrick攻击链给所有设备管理员上了一课：那些在机房角落跑了五年没重启的MikroTik设备，正是攻击者最喜欢的猎物。e=1指数伪造这种”小学生都能理解”的攻击手法，居然能在号称企业级的路由器系统里潜伏这么多年，本质上是SSH协议栈实现的代码审计严重缺位。

从攻击者视角看，这套PoC已经足够傻瓜化，paramiko几行代码就能跑通。安全研究员Costin Raiu测试了四个AI工具（Astra拒绝协助、Sol/Daybreak Blue/GLM-5.3愿意协助但未能完成），预计1-2天内会出现更多可用的exploit（漏洞利用程序）变种。对于还没打补丁的MikroTik管理员来说，这是一场与时间的赛跑。