Check PointのSmartConsole管理プラットフォームに存在する深刻な認証バイパスの脆弱性により、未認証の攻撃者がセキュリティ管理サーバーの管理者権限を完全に乗っ取ることが可能になっています。
CVE-2026-16232として追跡されているこの脆弱性は、Check Pointによって2026年7月22日に公表されたもので、Security Management ServerおよびMulti-Domain Security Management Server(MDS)の両展開形態に影響を及ぼします。
Rapid7は、この脆弱性がゼロデイとして実際に悪用されていることを確認しました。脆弱性の原因は、SmartConsoleの認証経路がIDの主張(identity claim)を検証する方法にあります。
本来、システムはアプリケーションの識別情報を、getCertificateDnName()が返す認証済みピア証明書に紐付ける必要があります。ところが脆弱なバージョンでは、攻撃者が指定したSecure Internal Communication(SIC)の識別名(DN)を、その認証済みIDの代わりとして受け入れてしまいます。
リモートの攻撃者は、未認証のSICブートストラップ段階において管理サーバー自身のSIC DNを読み取ることができるため、有効なクライアント証明書を一切提示することなく、偽造した証明書バインド要求の中でそのDNをそのまま再利用できてしまいます。
これによりサーバーは、攻撃者を正規のアプリケーションであるかのように扱ってしまいます。この悪用は、Check Pointの管理アーキテクチャの2世代にまたがる仕組みを組み合わせたものです。
まず攻撃者は、FWM/CPMIサービスに対してアプリケーションバインドを偽造し、アプリケーションのログイントークンを取得します。次にこのトークンを使ってgen-sso-token要求を発行しますが、FWMの認可ロジックはsystem_adminレベルのクライアントがSmartConsoleチケットを要求する場合の特例としてこれを承認してしまい、通常の権限マスクチェックを完全に迂回してしまいます。
得られたSSOチケットは、CPMサービスへのSOAP loginNew呼び出しを通じて引き換えられ、clientSessionIdとsidの値を伴う完全に認証済みのSmartConsoleセッションが生成されます。これにより攻撃者は、ポリシーや設定の変更を含め、正規の管理者と同等の権限を得ることになります。
Rapid7の指摘によると、悪用に必要なのは管理サーバーへのネットワークアクセスと、GUIクライアントを制限しないデフォルトのTrusted Clients設定のみであり、同社のテストではこれがデフォルト設定であることが確認されています。
Check Pointが公開した修正版(R81.20 Jumbo Hotfix Take 158に含まれる)では、DNの主張に対する信頼をループバックトラフィックのみ(CN=siclocal)に限定しています。
リモート接続については、サーバーは今後、認証済みピア証明書のDNのみを使用するようになり、提示されたDNと証明書の実際のIDとの間に不一致があれば拒否します。さらに、認証済みのSIC IDが一切存在しない場合のログインをブロックする追加のチェックも導入されています。
組織は、監査ログの中に「Authentication method: application token」という文字列がないか確認することで、悪用の兆候を把握できます。Rapid7は、これがチケット引き換え段階に関連する信頼できる侵害指標(IOC)であるとしています。
Rapid7は、管理者が自組織の露出状況をテストできるよう概念実証(PoC)の検証スクリプトを公開しており、ベンダー提供のパッチがこの悪用を確実に防止することも確認済みです。実際の悪用が確認されていることを踏まえ、影響を受けるR81.20およびR82.10のバージョンを運用している組織は、直ちにCheck Pointのパッチを適用すべきです。
SOC調査の死角を減らし、脅威をより早期に封じ込めることで、ANY.RUNにより対応コストと業務への影響を軽減しましょう。
翻訳元: https://cyberpress.org/check-point-smartconsole-zero-day/
