Cisco FMCの認証回避が実攻撃に、修正だけでは侵害は消えない

Ciscoは2026年9月9日、Secure Firewall Management Center（FMC）の認証回避脆弱性CVE-2026-20079について、実際の悪用を確認したと セキュリティアドバイザリー を更新した。CVSS基本値は10.0で回避策はなく、公開済みのホットフィックスは今後の悪用を防ぐためのもので、既存の侵害には対処できない可能性があると明記されている。

同じ9月9日、Cisco Talosは 三つの侵入クラスターの分析 を公表した。国家支援型や犯罪系の攻撃者に関連する活動だが、すべてがCVE-2026-20079だけを初期侵入経路にしたわけではない。もう一つの脆弱性CVE-2026-20316との関係を分けて見る必要がある。

未認証のHTTP要求からroot権限に到達する

CVE-2026-20079は、Secure FMC SoftwareのWebインターフェースにある認証回避の脆弱性だ。起動時に作成される不適切なシステムプロセスが原因で、遠隔の未認証攻撃者が細工したHTTP要求を送ると、影響を受ける機器でスクリプトやコマンドを実行し、基盤OSのroot権限を得る可能性がある。

対象はCisco Secure FMC Softwareと、Cisco Security Cloud Control（SCC）のFirewall Management機能で、機器構成には左右されない。SCC Firewall ManagementはCiscoが保守するSaaSであり、修正はサービス環境へ配備済みのため利用者側の作業は不要とされる。自社運用のFMCでは、稼働中のリリースを修正版または対応するホットフィックスと照合しなければならない。

管理インターフェースをインターネットに公開していない場合、外部から直接狙われる攻撃面は縮小する。ただし脆弱性そのものは残り、内部ネットワークから管理面へ到達できる経路があれば悪用の余地も残る。非公開であることを修正不要の根拠にはできない。

三つのクラスターで侵入経路と到達点が異なる

• UAT-12197：CVE-2026-20079の悪用後、CSM TomcatのWebルートへJSP形式のWebシェルを設置した。続いてコマンド実行用の悪意あるJARファイルを置き、FMC内部のデータベースから利用者の認証データと資格情報を取得した。
• UAT-11823：初期アクセスにはCVE-2026-20079の悪用またはCVE-2026-20316に関連する静的認証情報が使われた。悪意あるlicense.tmpからNetcatのリバースシェルを確立し、管理対象機器の設定を収集した後、Cyclops Blinkの亜種を配備した。分析では両方の脆弱性が悪用された可能性が高いと評価されているが、既知のSandwormとの関係はツールの重なりであり、同一主体との断定ではない。
• UAT-11988：CVE-2026-20316に関連する静的認証情報でFMCへログインし、正規機能を悪用して内部環境を偵察した。資格情報の窃取、SOCKSプロキシとリバースSSHトンネルの設置を経て、選んだ端末にQilinランサムウェアを展開した。

この区別は、CVE-2026-20079の実悪用と、侵害されたFMCを足場にした広範な攻撃を混同しないために重要だ。独立した BleepingComputerの9月10日付報道 も、二つの脆弱性と三つのクラスターを区別し、Webシェル、資格情報窃取、Cyclops Blink、Qilinに至る活動を整理している。

ホットフィックスは侵害の痕跡を除去しない

ホットフィックスまたは修正版を適用する目的は、脆弱な入口を閉じて将来の悪用を防ぐことだ。すでにroot権限を奪われ、Webシェルや永続化処理を設置された機器から、それらを自動的に除去するものではない。窃取済みの資格情報や持ち出された設定も、更新によって元へ戻ることはない。

FMCは複数のファイアウォールを集中管理するため、調査範囲は管理装置だけで終わらない。管理対象機器の設定が収集された形跡、内部ホストへのトンネル、外向きの不審な通信、FMCから参照可能だったアカウントの利用履歴まで確認対象になり得る。Qilin関連クラスターでは、侵害されたFMCが内部偵察と端末選定の足場に使われた。

したがって、更新作業の成功とインシデント対応の完了は別の判定にすべきだ。前者は脆弱性への対処、後者は侵入の有無と影響範囲の特定、残存物の除去、必要な復旧を含む。

更新と侵害確認を分ける判断フロー

1. 対象を特定する。自社運用のCisco Secure FMCについて、稼働リリースが影響範囲に含まれるかを確認する。Cisco側で修正済みのSCC Firewall Managementとは分けて扱う。
2. 利用可能な修正を適用する。該当リリース向けのホットフィックス、または修正版へ更新する。回避策は公開されていないため、管理面の外部公開を止めるだけでは修正の代わりにならない。
3. 指定されたログを確認する。expertモードでroot権限へ移行し、zgrep "package_info.*license" /var/log/messages* を実行する。出力にpackage_info.plが/var/tmp/license.tmpを引数として実行された記録があれば、悪用された可能性を示す指標となる。
4. 侵入後活動を調査する。JSP Webシェル、不審なJAR、変更された一時ファイル、未知の永続化処理、リバースシェルやトンネル、資格情報へのアクセス、管理対象機器の設定収集を確認する。公開された侵害指標との一致は重要だが、ログや端末の調査と組み合わせて評価する。
5. 侵害が疑われる場合は復旧へ移る。Cisco Technical Assistance Center（TAC）へ直ちに連絡し、復旧方法の支援を受ける。影響範囲に応じて、露出した可能性のある資格情報や管理対象ホストもインシデント対応の対象に含める。

/var/tmp/license.tmpの記録は重要な手掛かりだが、確認項目の一つにすぎない。該当行が見つからないことだけで、別のファイルや経路を使った侵害まで否定することはできない。管理操作、外部通信、アカウント利用、管理対象ホストの異常を合わせて判断する必要がある。

確認済みの範囲と次の更新

確認されているのは、CVE-2026-20079が実際に悪用され、UAT-12197ではWebシェル設置と資格情報窃取へ進んだこと、UAT-11823ではCVE-2026-20316と併用された可能性が高いことだ。Qilin関連のUAT-11988はFMC侵害が内部ネットワークへ及ぼし得る深刻な結果を示すが、初期アクセスはCVE-2026-20316に結び付けられている。

包括的なハードニングリリースは9月14日の週に予定されている。ただし、追加リリースを待つことは公開済み修正の適用を遅らせる理由にならず、修正の適用だけで既存侵害の調査を省くこともできない。現段階の完了条件は、入口を閉じたうえで侵害の有無を調べ、疑いがあれば復旧に移ったかどうかである。