【ITニュース解説】The SIEM as an attack surface: FortiSIEM CVE-2026-106173 and the cron script behind it

セキュリティ情報およびイベント管理（SIEM）プラットフォームは、組織のセキュリティにおいて非常に重要な役割を担っている。SIEMは、社内の様々なシステムからセキュリティ関連のログやイベントを一元的に収集・分析し、異常な挙動やサイバー攻撃の兆候を検知することを目的としている。そのため、SIEMは監視対象のシステムに関する機密情報、例えば認証情報（IDやパスワードなど）を保持し、ネットワークの中でも特に重要な管理ネットワーク上に配置されることが一般的だ。通常、SIEMは攻撃を検知するための「道具」として機能するが、もしそのSIEM自体に脆弱性が存在した場合、今度はSIEMが攻撃者にとって格好の「標的」となってしまう危険性がある。

今回話題となっているFortiSIEMの脆弱性、具体的には「CVE-2026-106173」は、まさにSIEMが攻撃対象となるという重大な問題を示している。この脆弱性は、Fortinet社が2026年10月13日にFG-IR-26-180として公表し、その後セキュリティ研究企業であるHorizon3.aiが技術的な分析と攻撃の実証コード（PoC）を公開したことで詳細が明らかになった。この脆弱性の影響を受けるのはFortiSIEM 7.5.0というバージョンで、バージョン7.5.1ではすでに修正されており、7.6やFortiSIEM Cloudには影響がないとされている。この脆弱性の危険度は非常に高く、共通脆弱性評価システム（CVSS v3.1）の基本スコアはNVDで9.8、Fortinet自身も9.4と評価しており、これは最大値に近い深刻なレベルであることを意味する。さらに深刻なのは、この脆弱性を悪用するために認証が不要である点だ。つまり、攻撃者は特別なログイン情報を持っていなくても、この脆弱性を突くことができる。

この脆弱性のメカニズムは、FortiSIEMの内部サービスである「phQueryMaster」に存在する。このサービスはTCPポート27918で通信を受け付け、gRPCと呼ばれる仕組みで他のコンポーネントからのクエリ結果を処理している。問題は、このサービスが呼び出し元から受け取るクエリ識別子を使って、ファイルパスを生成する際に適切な検証を行わない点にある。具体的には、二つの巧妙な弱点が組み合わさって悪用される。一つ目は「パス・トラバーサル」という脆弱性で、攻撃者はクエリ識別子の中に「../」（ドットドットスラッシュ）のような特殊な文字シーケンスを含めることで、ファイルが本来保存されるべきディレクトリの外部、つまり攻撃者が指定した任意の場所にファイルを書き込めるようにする。二つ目の弱点は「NULバイトによるパスの切り詰め」だ。このサービスは、生成されたファイル名の末尾に自身のテキストを追加する仕組みになっているが、もし攻撃者がクエリ識別子の中にNULバイト（\0、文字列の終端を示す特殊な文字）を含めると、オペレーティングシステムがそのNULバイト以降のパスを無視してしまう。この二つの弱点を組み合わせることで、攻撃者はサービスが勝手にテキストを追加する部分を無視させ、意図したパスに完全に制御されたファイルを書き込むことが可能となる。

このファイル書き込み能力を悪用し、さらに攻撃者はシステム上でコードを実行しようと試みる。Horizon3.aiの分析によると、攻撃者は「/opt/charting/redishb.sh」というシェルスクリプトをターゲットとする可能性が高いと指摘されている。このスクリプトは、Linuxシステムで定期的なタスクを自動実行する「cron」という機能によって、60秒ごとに高い権限で実行されるように設定されている。そのため、攻撃者がこの「redishb.sh」スクリプトを自分の悪意あるコードで上書きすると、次のcronの実行タイミングで攻撃者のコードが、システム上で高い権限で実行されてしまうのだ。

この攻撃を実行するためのリクエストの作成は、決して簡単ではない。一般的なgRPCツールやHTTP通信ライブラリは、NULバイトを含むような特殊なヘッダー値を正常に処理できないため、攻撃者はgRPCメッセージを手動で、より低レベルで構築する必要がある。これは攻撃者の持つべき技術的なスキルレベルを高める要因となる。さらに、このような攻撃では、一般的なWebプロキシのログには異常な記録が残らない可能性がある。なぜなら、悪意のあるコンテンツがHTTP/2フレームのボディ内に埋め込まれており、通常のヘッダー検証をすり抜けてしまうためだ。また、Horizon3.aiの調査でも、成功した攻撃を確実に特定できるようなアプリケーションログのエントリは見つからなかったと報告されている。このため、主要な検知方法が機能しない場合、攻撃が成功したかどうかの調査は、ログではなく、サーバーのファイルシステムの状態を詳しく調べることから始める必要がある。

もしFortiSIEM 7.5.0のインスタンスが攻撃を受けた可能性があると疑われる場合、まず行うべき調査は「/opt/charting/」ディレクトリ内のファイルのタイムスタンプを確認することだ。特に「/opt/charting/redishb.sh」スクリプトの最終変更時刻に注目し、同じディレクトリ内の他のファイルや、既知のパッチ適用時刻と比較する。もし、このスクリプトのタイムスタンプが周囲のファイルと大きく異なっている場合、それは改ざんされた可能性を示す重要な手がかりとなる。また、Horizon3.aiは「/opt/phoenix/bin/phLicenseTool」も確認すべきファイルとして挙げている。ただし、タイムスタンプの不一致はあくまで調査の「手がかり」であり、「結論」ではないことに注意が必要だ。パッケージのアップグレードやシステムの設定管理、あるいはサポートセッションなどによってもファイルのタイムスタンプは変更されることがある。重要なのは、その変更が正当な理由によるものかどうか、変更記録やパッケージマネージャーのログと照合して確認することだ。ネットワーク側の証拠は限定的ではあるが、全くないわけではない。ポート27918は、信頼できるSIEMコンポーネント以外からはアクセスされるべきではない。したがって、フローログなどを確認し、予期せぬソースからこのポートへの接続が見つかれば、アプリケーションログがクリーンに見えても、さらに詳しく調査する価値がある。

この脆弱性によるリスクを軽減するための最も直接的で効果的な対策は、FortiSIEMをバージョン7.5.1以降にアップグレードすることだ。もしすぐにアップグレードが難しい場合は、一時的な措置として、TCPポート27918へのネットワークアクセスを厳しく制限する必要がある。この制限は、外部ネットワークから内部への通信（北-南）だけでなく、内部ネットワーク内の異なるセグメント間（東-西）の通信に対しても適用すべきだ。多くの環境では、SIEMのコレクタ（ログ収集エージェント）がこのポートを通じてスーパバイザー（中央管理サーバー）に到達する必要があるため、以前の設計で許可されたままになっている緩いアクセスルールを見直し、厳密に必要なシステムのみにアクセスを許可するように変更する作業が求められるだろう。また、「/opt/charting/」ディレクトリ内のファイルの整合性を継続的に監視することも、有効な補償制御の一つとなる。このディレクトリにはcronによって特権で実行されるスクリプトが含まれているため、本来このファイル整合性監視は、今回の脆弱性が発覚する以前から実施されているべきであった。

今回のインシデントは、FortiSIEMに関するHorizon3.aiによる3番目の脆弱性報告となる（過去にはCVE-2024-23108とCVE-2025-64155が公表されており、これらはphMonitorサービスに関連するものだった）。今回の脆弱性が別のgRPCサービスに存在していたという事実は、非常に重要な教訓を与えている。それは、「アプライアンス上の一つのデーモンやサービスだけを強化しても、アプライアンス全体のセキュリティが保証されるわけではない」ということだ。システム上でリクエストを受け付ける各サービスは、それぞれが独立した攻撃面となる。セキュリティ管理プラットフォームのように複数のサービスを公開している製品では、現在注目されている特定の脆弱性だけを修正するのではなく、公開されている全てのサービスを網羅的に評価し、全体的なセキュリティ強化に取り組む必要がある。