脆弱な範囲（全6件）：[7.24, 7.24.2)、[7.0.0, 7.23.4)、[6.0.0, 6.49.21)。

CVE-2026-67276のメカニズム

1. RouterOSは提示されたSSH公開鍵ブロブをユーザーの認証済みキーと**（キータイプ、モジュラス）**で照合します — 指数は比較されません。
2. 署名検証はクライアント提供のキー、つまり攻撃者のブロブからの指数を使用します。
3. {ssh-rsa, e=1, n=victim}を提示すると、sig^1 mod n == sigとなるため、有効な「署名」は単にEMSA-PKCS1-v1_5(hash, authdata) — 被害者の公開モジュラスを知る誰でも計算可能です。秘密鍵は不要です。
4. 結果：対象ユーザーとしてのSSHコマンドチャネル。

前提条件（開示自体の最小要件）：対象ユーザー名＋そのユーザーの認証済みRSA公開モジュラス。

再現に必要な最小情報

1. ターゲット: 脆弱な範囲内の任意のRouterOS、SSH到達可能（ラボ：KVM付きQEMU内のCHRイメージ。実ハードウェアも同等）。
2. 認証済みRSAキーを持つアカウントのユーザー名。
3. その認証済みキーのRSAモジュラスn（漏洩・取得した.pub、プロビジョニング記録、または--modulus-hexから）。これが唯一の秘密に近い入力です。秘密鍵は決して必要ありません。
4. 開示で確認されたサーバー動作（CERT PLによる欠陥そのもの）：マッチ = (type, n)、検証指数 = クライアント提供。
5. 任意のキーブロブと任意の署名バイトを提示できるクライアント（paramiko＋ForgeKeyフック — 標準のOpenSSHでは不可）。
6. サーバーが受け入れる署名アルゴリズム（6.xではssh-rsa、7.xではrsa-sha2-256も）。

ファイル

• forge_67276.py — プリミティブ：OpenSSH公開鍵パース、RFC 8017 EMSAエンコーダ、偽造ブロブ／署名ビルダー、RFC 8017参照検証器。
• selftest.py — ルーター不要のローカル証明：エンコーダはOpenSSLとバイト単位で同一（実署名反転経由）、偽造署名はe=1で検証成功かつ65537では失敗、完全なRFC 4252 §7ワイヤー形状シミュレーション。全15チェックPASS。
• 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から意図的に除外。

ローカルセットアップ

ラボ（[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）：

観測結果（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ブロブを拒否します（/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）： ブロブの内部タイプ文字列はrsa-sha2-256/512署名アルゴリズムでもssh-rsaのままです。署名アルゴリズムは外側のアルゴリズムフィールドにのみ入ります。これを無視すると、サーバーはユーザー認証途中で切断します（ブロブパースエラー）— 6.xと7.xの両方で観測。PoCのForgeKeyはこれを処理し、--exp-enc aligned|canonicalでe=1 mpint幅（1バイト対3バイト）を切り替えます。7.23.3では両方の幅が認証されます — マッチャーは指数をパースし、その値を本当に無視します。6.49.20ではどちらも認証されません（can't find matching key）— 上記のバージョンのニュアンスを参照。サーバー側の/system logging add topics=ssh,debug＋/log printパケット16進ダンプがこれらすべてを明らかにしました。

このラボで使用したソースイメージアーカイブのSHA-256値：

防御メモ（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