【ITニュース解説】MikroTrick: How Two SSH Flaws Let Attackers Take Over MikroTik Routers Without Credentials

MikroTrickと名付けられた今回の攻撃は、通常は一度設定されればあまり注目されないルーターのようなネットワーク機器が、もしその管理インターフェースがインターネットに公開されたままになっている場合、どれほどの危険に晒されるかを示す深刻な事例だ。システムエンジニアを目指す皆さんにとって、この種の脆弱性がどのように生まれ、どのように悪用され、そしてどのように防ぐべきかを知ることは、セキュリティ意識を高める上で非常に重要だ。

このMikroTrickは、MikroTik社のRouterOSというルーターのオペレーティングシステムに存在する二つの脆弱性を組み合わせた攻撃手法である。一つは「CVE-2026-67276」というSSH公開鍵認証バイパスの脆弱性で、もう一つは「CVE-2026-86060」という不正なユーザー名を利用した特権昇格の脆弱性だ。これらが組み合わされることで、SSHサービスにアクセスできる攻撃者が、認証情報を持たずとも、ルーターの完全な管理者権限を奪うことが可能になる。どちらの脆弱性も極めて深刻で、その危険度を示すCVSSスコアは9.2から9.8とされている。

まず、一つ目の認証バイパスの脆弱性は、RouterOSのSSH公開鍵認証の仕組みに潜む論理的な欠陥を利用するものだ。RSA公開鍵認証では、ユーザーが自分であることを証明するために、秘密鍵と対になる公開鍵をサーバーに登録し、その公開鍵で検証される署名を利用する。公開鍵は、鍵のタイプ、モジュラス、そしてエクスポーネント（指数）といった複数の数値で構成される。しかし、RouterOSのSSH実装は、クライアントが提示する公開鍵を検証する際に、鍵タイプとモジュラスは確認するものの、重要な「エクスポーネント」という部分をなぜか完全に無視していた。攻撃者はこの見落としを悪用し、エクスポーネントが「1」という特殊な公開鍵を偽造する。通常、RSA署名検証は複雑な計算を伴うが、エクスポーネントが1の場合、その計算は「入力された値がそのまま出力される」という、非常に単純な「恒等操作」になってしまう。これにより、攻撃者は本来必要な秘密鍵を持っていなくても、被害者の公開鍵のモジュラスとユーザー名さえ知っていれば、あたかも正当なユーザーであるかのように認証を突破できてしまうのだ。この攻撃が成立するためには、ターゲットアカウントがSSH公開鍵認証を設定しており、SSHサービスがインターネットなどのネットワーク経由で到達可能であるという前提がある。インターネットに公開されているMikroTikデバイスでは、これらの条件は一般的に満たされている場合が多い。

認証バイパスに成功し、一旦ルーターにログインした攻撃者は、次に二つ目の特権昇格の脆弱性を利用して、セッションの権限を完全な管理者レベルに引き上げる。この脆弱性は、「不正な引数区切り文字の不適切な無効化」と説明されており、細工されたユーザー名を送りつけることで、システムがそのユーザー名を正しく処理できず、意図しないコマンドが管理者権限で実行されてしまうというものだ。結果として、攻撃者はデバイスの全ての機能を制御できるようになる。具体的には、ネットワークトラフィックの傍受、ルーティングルールやファイアウォールルールの改ざん、さらにはルーターをプロキシやVPNトンネルの終端として悪用することまで可能になる。

この攻撃の深刻さを際立たせるのは、そのタイムラインだ。修正プログラムがリリースされる前に、すでに攻撃が開始されていたのである。CERT Polskaは、2026年9月2日から攻撃者の活動を記録しており、MikroTikが修正版をリリースしたのはその翌日、9月3日だった。これは厳密な意味での「ゼロデイ攻撃」であり、防御側が対策を講じる手段がないまま、攻撃が進行していたことを意味する。さらに、米国のサイバーセキュリティ機関であるCISAも、9月10日にこれらの脆弱性を「既知の悪用された脆弱性」のカタログに追加し、連邦政府機関に対して9月13日までの迅速な修正を義務付けた。

もし自身のデバイスが侵害された可能性があるかどうかを確認したい場合、いくつかの具体的な兆候がある。ログに「ssh:-2@」という形式で、不正なユーザー名「-2」によるSSHログイン試行が見られる場合、これは攻撃の兆候だ。また、デバイス上に「ops」という名前の高権限アカウントが不審に追加されている場合も、侵害の強い証拠となる。MikroTikは修正済みファームウェアに、既知の改ざんをブート時に自己チェックする「Flagged」という検出機構を追加しており、デバイスがこの「Flagged」状態にある場合も侵害の可能性を示唆している。ただし、「Flagged」は侵害を防ぐものではなく、あくまで改ざんの兆候を記録するものであり、ファームウェアがアップグレードされた後にのみ機能する点に注意が必要だ。攻撃元として報告されているIPアドレスには、82.192.72.4や103.102.31.18が含まれる。

これらの脆弱性に対する修正プログラムは、MikroTikの各リリース版で提供されている。RouterOS 6.xの長期サポート版では6.49.21以降、RouterOS 7.xの長期サポート版では7.23.4以降、そしてRouterOS 7.xの安定版では7.24.2以降のバージョンにアップグレードする必要がある。さらに、7.23.5というビルドも9月4日にリリースされている。もし直ちにアップグレードが困難な場合は、SSHアクセスをインターネット全体ではなく、信頼できる特定の管理用アドレスに限定する、あるいは帯域幅テストサービスを無効化または制限するといった暫定的な対策を講じるべきだ。ただし、これらの対策は攻撃からの到達可能性を減らすだけであり、根本的な認証ロジックの脆弱性を修正するものではないことを理解しておく必要がある。パッチが適用されていない期間にインターネットからアクセス可能だったデバイスは、単に脆弱であるだけでなく、既に侵害されている可能性が高いとみなし、慎重に対応することが求められる。

なぜMikroTikのようなデバイスが繰り返し標的になるのかには、いくつかの理由がある。MikroTik機器は、中小企業、インターネットサービスプロバイダー（ISP）、そして支社などで広く利用されている。これらの導入環境では、機器の長寿命、メンテナンスの頻度の低さ、そしてリモート管理のために管理インターフェースがインターネットに公開されがち、という三つの共通した特徴が見られる。乗っ取られたルーターはネットワークの「信頼境界」に位置するため、その侵害はデバイス自体にとどまらず、内部ネットワーク全体に波及する可能性がある。さらに、SSH公開鍵認証は通常、パスワード認証よりもセキュリティが高いとみなされてきた。なぜなら、正当な認証には秘密鍵の物理的な「所有」が必要だと考えられていたからだ。しかし、今回のMikroTrick攻撃は、秘密鍵がなくても認証を突破できることを示し、このセキュリティ上の前提を覆してしまった点で、通常の認証情報推測による攻撃よりもはるかに深刻な影響を持つ。

このような攻撃から身を守るための直接的な行動としては、「アップグレード」「制限」「検証」の三つが挙げられる。まず、脆弱性が修正されたRouterOSの最新バージョンに速やかにアップグレードすることが不可欠だ。次に、SSH、Web管理インターフェース（WebFig）、そして帯域幅テストサービスへのアクセスを、公開インターネットからではなく、信頼できる管理用ネットワークアドレスに限定する。そして、最後に「検証」を行う。具体的には、ルーターのログをチェックして「-2」というユーザー名によるログイン試行がないか確認し、デバイス上のアカウントリストを見直し、身に覚えのない不正なアカウントがないか調べて削除する。また、デバイスが「Flagged」状態を報告していないかどうかも確認するべきだ。

もしデバイスが実際に侵害されていたと確認された場合、そのデバイスをネットワークから隔離し、設定変更履歴を調べて悪意のあるエントリがないか慎重に調査する必要がある。不正に追加されたアカウントは削除し、完全に安全が確認されてからサービスに復帰させるべきだ。もし証拠を確保せずに工場出荷時の設定にリセットしてしまうと、攻撃者がどのような活動を行い、どのような経路で侵入したのかを理解するための重要な情報が失われてしまうため、注意が必要だ。

今回の件から得られるより広範な教訓は、「公開管理インターフェース」の管理だ。インターネットに公開された管理インターフェースは、常に攻撃者への「招待状」のようなものであり、今回のケースでは、修正パッチが公開されるよりも前に攻撃が始まっていたという、極めて厳しい現実を示している。日頃からネットワーク機器のセキュリティパッチ適用状況を確認し、不必要なポートやサービスは公開しない、そして管理インターフェースは限定されたネットワークからのみアクセス可能にする、といった基本的なセキュリティ対策を徹底することの重要性を改めて認識する必要がある。