【ITニュース解説】CVE-2026-33792 for Incident Responders: What Root on an SRX Actually Looks Like

今回のニュース記事は、予防策ではなく、実際にセキュリティインシデントが発生してしまった後の対応、特にJuniper社のSRXシリーズというルーターやファイアウォール製品における脆弱性「CVE-2026-33792」への対処について詳しく解説している。この脆弱性が悪用され、攻撃者がデバイスの「root権限」という最高権限を奪取した場合に何が起きるのか、そしてどのように対応すべきかという、インシデントレスポンスの視点から書かれた珍しい内容だ。

まず、CVE-2026-33792とはどのような脆弱性か説明する。これは、Juniperのルーターやファイアウォールで使われている「Junos OS」というOSの「srxpfe」という転送処理プロセスに存在する。具体的には「スタックベースのバッファオーバーフロー」という種類の脆弱性である。これは、プログラムがデータを処理する際に、本来格納できるメモリ領域（スタック）のサイズを超えたデータが書き込まれてしまうことで発生する。その結果、プログラムが誤動作したり、攻撃者が任意のコードを実行できるようになる可能性がある。この脆弱性は、特別に細工されたパケットを、設定済みの「GREトンネル」という仮想的な通信経路を通じて送り込むことで、認証なしに遠隔から悪用できるのが特徴だ。つまり、攻撃者はログインすることなく、ネットワーク経由でこの脆弱性を突くことができる。

ベンダーであるJuniper社によると、この脆弱性が悪用された場合、結果として攻撃者がroot権限でコードを実行できるか、あるいはデバイスが「サービス拒否（DoS）」状態になり、正常な機能が停止する可能性があると報告されている。この脆弱性の深刻度を示す「CVSSスコア」は、バージョン3.1で9.8、バージョン4.0で9.3と非常に高く、これは最も危険なレベルに分類される。現時点では、この脆弱性に対する回避策は公表されておらず、また実際の悪用事例も報告されていない。

なぜ、こうしたセキュリティデバイスへのインシデント対応が難しいのだろうか。一般的なインシデント対応では、問題が発生した「エンドポイント」、例えばパソコンやサーバーであれば、そのシステムのイメージ（状態を丸ごと記録したデータ）を取得し、正常な状態と比較して、必要に応じて再構築する、といった手順を踏むことが多い。しかし、SRXのような「ゲートウェイデバイス」は、ネットワークの出入り口に位置し、その役割が大きく異なるため、同じような対応ができない。ゲートウェイデバイスは、ネットワークの分離設定、通信経路を決定するルーティング状態、暗号化通信のためのトンネル鍵、そして自身の動作を記録するログなど、非常に重要な設定情報や機密情報を保持している。

もし攻撃を受けているゲートウェイを安易に再起動してしまうと、攻撃の痕跡や、攻撃者がどのような操作を行ったかの証拠が失われてしまう可能性がある。また、デバイス自身が生成するログも、攻撃者がroot権限を奪っていれば、ログの改ざんや停止を行っている可能性があるため、そのログ情報を鵜呑みにすることも危険である。

では、攻撃者がSRXのroot権限を奪取した場合、具体的にどのような被害が発生しうるのか。 まず「設定の変更」だ。攻撃者はネットワークの分離ルールを調整したり、新しい通信トンネルを追加したり削除したり、ログを記録するポリシーを変更したりできる。これにより、攻撃者は自分の望むようにネットワークの通信を操作したり、自身の行動の記録を消したりすることが可能になる。 次に「トラフィック処理の変更」だ。攻撃者はデバイスがパケットを転送する挙動を、設定ファイルには残らない形で変更できる可能性がある。これにより、正規の設定変更履歴には現れない形で、特定の通信を盗聴・改ざんしたり、別の場所に転送したりするような操作が可能になる。 さらに「トンネル鍵情報の漏洩」がある。IPsecなどの暗号化トンネルを終端するデバイスは、その通信を保護するための鍵情報や相手側の状態を保持している。攻撃者はこれらの情報を盗み出し、暗号化された通信の内容を解読したり、偽装した通信を送ったりするのに利用する可能性がある。 そして「管理経路の悪用」も重要だ。ゲートウェイデバイスは通常、自身の監視システムや認証システムへの通信経路を持っている。攻撃者はこの経路を悪用して、監視システムや認証インフラに侵入する足がかりにする可能性がある。

このような認証不要のメモリ破損脆弱性は、直接的な攻撃の痕跡を残しにくい。そのため、インシデントレスポンスでは「継続性」と「一貫性」に注目し、普段とは異なる「兆候」を見つけることが重要になる。 具体的な兆候としては、例えば、特別な設定変更がないにもかかわらず、デバイスの転送プロセスが予期せず再起動したり、プログラムが異常終了した際に生成される「コアダンプ」が出力されたりする場合。 また、普段ほとんど通信がないGREトンネルで、突然、異常な量の通信が発生するようなスループットの異常も兆候となりうる。 さらに、記録されている変更履歴とは異なる時間帯や、許可されていない送信元から、デバイスの設定変更が行われた形跡も警戒すべき点だ。 ログの転送（syslog forwarding）が突然停止したり、ログの転送先が変更されたりする現象も注意が必要である。 そして、通常はアクセスできないはずのネットワークセグメントから、デバイスの管理画面へのログインが試みられたり、成功したりするケースも重要な兆候だ。 これらの兆候は、それぞれ単独では誤報である可能性もあるが、特にGREトンネルを終端するSRXデバイスで、複数の兆候が同時に現れた場合は、単なる再起動ではなく、デバイスのシステム整合性を徹底的にチェックするべきだと記事は指摘している。

インシデントレスポンスでは、「証拠の保全」と「脆弱性の影響拡大の阻止」という二つの相反する課題に直面する。この脆弱性には回避策がないため、デバイスをそのままにしておくと、引き続き攻撃されるリスクが残る。 このような状況で推奨される対応順序は、まずデバイスへの「到達性を除去する」ことだ。可能であれば、対象デバイスを直接操作せず、ネットワークの境界にある他の機器で、GREトンネルの接続元を制限するか、トンネル経路自体をネットワークから隔離する。 次に、対象デバイスの現在の「状態を捕捉する」、つまり証拠を保全する。 そして最後に、修正プログラムが適用された新しいファームウェアを適用する。修正版は、23.2R2-S7.7から26.4R1までのバージョンと、それ以降のビルド、さらに23.2、23.4、24.2系統のリスピン版で提供されている。 もし、デバイスへの到達性除去が困難な場合は、担当のオンコールエンジニアが一人で判断せず、この衝突を上位にエスカレーションして適切な指示を仰ぐべきである。

また、外部のインターネットスキャンサービス（ZoomEyeなど）で、インターネット上に露出しているJuniper製品の数を調べることはできるが、これらの情報はあくまで一般的な「衛生管理」の目安にしかならない。特定のSRXプラットフォームであるか、GRE設定があるか、脆弱なビルドであるかといった、個別の脆弱性悪用を特定するような調査には貢献できない。

最後に、修正プログラムを適用した後の対応について。最も重要なのは、デバイスの設定が攻撃によって変更されていないかを確認することだ。この確認は、デバイス自身の現在のコミット済み設定と、過去に信頼できる場所（例えば、別途管理している設定バックアップシステム）から復元した、最後に承認されたベースライン設定を比較することで行う。デバイス自身の設定は、攻撃者によって改ざんされている可能性があるため、信用してはならない。この比較によって、設定の変更がなければ、インシデント対応のループが閉じられたと判断できる。