MikroTik路由器SSH认证绕过复现
使用官方镜像直接启动：
https://download.mikrotik.com/routeros/7.21.5/chr-7.21.5-arm64.img.zip
qemu-system-aarch64 \
-M virt \
-m 2048 \
-cpu cortex-a72 \
-bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd \
-drive file=chr-7.21.5-arm64.img,format=raw,if=none,id=hd0 \
-device virtio-blk-pci,drive=hd0,bootindex=0 \
-netdev user,id=net0,hostfwd=tcp::5555-:22,hostfwd=tcp::6666-:80,hostfwd=tcp::7777-:443 \
-device virtio-net-pci,netdev=net0 \
-nographic
CVE-2026-67276
通过漏洞情报得知，RouterOS 校验 SSH 公钥认证时存在两个叠加缺陷：按模数定位用户授权密钥时不覆盖指数，且签名验算对指数 e 不做任何校验（未要求 e≥3 或 e=65537)。
我们定位到 /bndl/security/nova/bin/ssh,0x28dec 处是签名验证调用点，sub_28644 的返回值直接决定认证成败。
跟进分析发现它负责打包一个用于验证请求的 NV 消息，随后通过insertnv::raw_id 把提交的签名/公钥 blob 原样传到内部验证逻辑。
最终在 0x1f8d4 调用 sub_24BE0 做签名内容比对（期望 EMSA 块 vs 验算结果），比对失败走 "signatures are not matching!" 。
由于 e 可控制，取 e=1 时 s^e mod n = s，验算结果可以构造合法 EMSA 块，比对必然通过，只要知道受害用户公钥的模数即可伪造认证（实测完整模数匹配通过、错误模数被拒)。
我们先用真实私钥形成对照，victim_rsa是保存的私钥，拿到系统信息
ssh -i victim_rsa -p 5555 admin@192.168.135.137 '/system resource print'
再通过伪造认证，victim_rsa.pub是保存的公钥提供模数，forge_67276.py构造 e=1 密钥和签名
python3 poc_67276.py --host 192.168.135.137 --po
