<p><!--META
{
"title": "Check Point CVE-2024-24919攻撃連鎖と緩和策",
"primary_category": "ネットワークセキュリティ",
"secondary_categories": ["脆弱性管理", "インシデントレスポンス"],
"tags": ["CVE-2024-24919", "CheckPoint", "QuantumSecurityGateway", "NTLMハッシュ", "情報漏洩", "MFA", "パス走査"],
"summary": "Check Point Quantum Security GatewayのCVE-2024-24919攻撃連鎖、NTLMハッシュ窃取からネットワーク侵入、そして具体的な緩和策と運用対策を解説します。",
"mermaid": true,
"verify_level": "L0",
"tweet_hint": {"text":"Check Point Quantum Security GatewayのCVE-2024-24919攻撃連鎖を解説。情報漏洩からVPN経由での内部侵入、NTLMハッシュ窃取の対策、MFA強化やログ監視など、実務的な緩和策と運用対策をまとめました。 #CheckPoint #セキュリティ","hashtags":["#CheckPoint","#セキュリティ"]},
"link_hints": ["https://support.checkpoint.com/results?list=CVE-2024-24919","https://www.volexity.com/blog/2024/05/27/zero-day-exploitation-of-check-point-vpns/","https://nvd.nist.gov/vuln/detail/CVE-2024-24919"]
}
-->
本記事は<strong>Geminiの出力をプロンプト工学で整理した業務ドラフト(未検証)</strong>です。</p>
<h1 class="wp-block-heading">Check Point CVE-2024-24919攻撃連鎖と緩和策</h1>
<h2 class="wp-block-heading">脅威モデル</h2>
<p>CVE-2024-24919は、Check PointのQuantum Security GatewayおよびCloudGuard Network Security製品における情報漏洩の脆弱性です。この脆弱性は、認証されていないリモートの攻撃者が、特定のパス走査(Path Traversal)攻撃を悪用して、デバイス上の任意のファイルを読み取ることを可能にします。特に、ユーザーのNTLMハッシュやローカルアカウントのハッシュ化されたパスワードなど、認証情報を窃取されるリスクが高い点が問題視されています。</p>
<p>この脆弱性は、Check Point Quantum Security GatewayおよびCloudGuard Network SecurityのR81.20、R81.10、R81、R80.40、R77.30の各バージョンに影響を与えます。Volexityの報告によれば、この脆弱性は2024年5月27日以前から実環境で活発に悪用されていることが確認されており、高いリスクを伴います[1][2]。</p>
<p>攻撃者は窃取した認証情報を利用してVPN経由で内部ネットワークに侵入し、その後の横展開やデータ窃取を試みる可能性があります。この脅威モデルでは、インターネットに公開されたCheck Pointゲートウェイが初期侵入の足がかりとなり、最終的に企業ネットワーク全体が侵害されるシナリオを想定しています。</p>
<h2 class="wp-block-heading">攻撃シナリオ</h2>
<p>CVE-2024-24919を利用した攻撃連鎖は以下のステップで進行します。</p>
<ol class="wp-block-list">
<li><p><strong>初期アクセス</strong>: 攻撃者はインターネットに公開された脆弱なCheck Pointゲートウェイを特定します。この脆弱性は認証不要であるため、外部からのアクセスが可能です。</p></li>
<li><p><strong>情報漏洩</strong>: 攻撃者はHTTPSポート(通常443/TCP)を通じて、特定のURLパスに細工されたリクエストを送信し、パス走査の脆弱性を悪用します。これにより、通常アクセスできないシステムファイル(例: <code>id_resolver.conf</code>、認証情報を含む設定ファイルなど)を読み取ります[2]。</p></li>
<li><p><strong>認証情報窃取</strong>: 読み取ったファイルから、ユーザーのNTLMハッシュやローカルアカウントのハッシュ化されたパスワードなどの機微な認証情報を抽出します。</p></li>
<li><p><strong>認証情報悪用</strong>: 攻撃者は窃取したNTLMハッシュをオフラインでクラックしたり、「パス・ザ・ハッシュ」攻撃などを用いて、有効なユーザーの認証情報を取得します。</p></li>
<li><p><strong>内部ネットワーク侵入</strong>: 取得した認証情報(ユーザー名とパスワード)を悪用し、VPN接続を通じて企業内部ネットワークにリモートアクセスします。この段階で、多要素認証(MFA)が導入されていない場合、侵入は容易になります。</p></li>
<li><p><strong>横展開と持続性</strong>: 内部ネットワークに侵入後、攻撃者はさらなる脆弱性を探索し、権限昇格、他のシステムへの横展開、マルウェアの展開、バックドアの設置などを行い、ネットワーク内での持続的なプレゼンスを確立します。</p></li>
<li><p><strong>最終目的達成</strong>: 最終的に、機密データの窃取、システムの破壊、ランサムウェアの展開など、攻撃者の最終目的を達成します。</p></li>
</ol>
<p>この攻撃連鎖は、Check Pointの公式アドバイザリやVolexityの分析によって裏付けられています[1][2]。</p>
<div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid">
flowchart LR
A["外部攻撃者"] -->|1. 脆弱なゲートウェイを特定| B("Check Point Gateway")
B -->|2. CVE-2024-24919悪用 (パス走査)| C{"機微ファイル窃取"}
C -->|3. id_resolver.confなどから| D["NTLMハッシュ/ローカルパスワード取得"]
D -->|4. オフラインクラック/パス・ザ・ハッシュ| E["有効な認証情報"]
E -->|5. VPN/SSHなどでのリモートアクセス| F("内部ネットワーク侵入")
F -->|6. 横展開/権限昇格/持続性| G["データ窃取/システム改ざん/ランサムウェア"]
</pre></div>
<h2 class="wp-block-heading">検出と緩和策</h2>
<h3 class="wp-block-heading">検出</h3>
<ul class="wp-block-list">
<li><p><strong>IoC (Indicators of Compromise) の監視</strong>: Check PointおよびVolexityが提供するIoC(不審なIPアドレス、ファイルハッシュ、ネットワーク通信パターンなど)をSIEMやEDRで監視します[1][2]。</p></li>
<li><p><strong>認証ログの監視</strong>:</p>
<ul>
<li><p>VPN、SSH、Web管理インターフェースなど、Check Pointゲートウェイへの認証ログを詳細に監視します。</p></li>
<li><p>特に、地理的に不審な場所からのログイン、通常とは異なる時間帯のログイン、失敗したログイン試行の急増に注意します。</p></li>
<li><p>新規作成されたユーザーアカウントや権限変更のログを追跡します。</p></li>
</ul></li>
<li><p><strong>ファイルアクセスログの監視</strong>: ゲートウェイ上で不審なファイル読み取りアクセス(特に <code>/etc/passwd</code> や <code>id_resolver.conf</code> などの機微な設定ファイル)がないか監視します。ただし、詳細なファイルアクセスログがデフォルトで有効でない場合があります。</p></li>
</ul>
<h3 class="wp-block-heading">緩和策</h3>
<ol class="wp-block-list">
<li><p><strong>緊急パッチ適用</strong>: Check Pointが2024年5月28日に公開した緊急ホットフィックス(Take 206 for R81.20, Take 111 for R81.10, Take 254 for R81, Take 970 for R80.40, Take 766 for R77.30)を直ちに適用します[1]。これは最も重要な緩和策です。</p></li>
<li><p><strong>多要素認証 (MFA) の導入と強化</strong>:</p>
<ul>
<li>すべてのリモートアクセス(VPN、管理インターフェースなど)に対してMFAを強制します。これにより、認証情報が窃取された場合でも、攻撃者の侵入を阻止する可能性が高まります。</li>
</ul></li>
<li><p><strong>ネットワークセグメンテーション</strong>:</p>
<ul>
<li><p>Check Pointゲートウェイが直接アクセスできる内部ネットワークセグメントを最小限に抑えます。これにより、万が一ゲートウェイが侵害されても、攻撃の横展開を制限できます。</p></li>
<li><p>特に、ドメインコントローラーや機密データサーバーへの直接アクセスは厳しく制限すべきです。</p></li>
</ul></li>
<li><p><strong>不要なサービスの無効化</strong>:</p>
<ul>
<li>ゲートウェイ上で不要なサービスやブレード(例: Identity AwarenessやMobile Accessなど、この脆弱性の悪用に関連する可能性のあるもの)を無効化します。</li>
</ul></li>
<li><p><strong>強力なパスワードポリシーと定期的なパスワードリセット</strong>:</p>
<ul>
<li>すべてのユーザーアカウントに対して、複雑でユニークなパスワードを強制し、定期的なパスワードリセットを義務付けます。特に、この脆弱性が公表されて以降、パスワードリセットは必須です。</li>
</ul></li>
</ol>
<h3 class="wp-block-heading">暗号/プロトコルの安全な代替</h3>
<p>CVE-2024-24919は直接的な暗号プロトコルの脆弱性ではありませんが、窃取されたNTLMハッシュが悪用されるリスクを考えると、認証プロトコルの安全な運用が重要になります。</p>
<p><strong>誤用例(NTLMプロトコル)</strong>:
多くのWindows環境でLegacy認証として利用されているNTLM(特にNTLMv1)は、ハッシュの脆弱性からパス・ザ・ハッシュ攻撃やオフラインクラッキングに対して脆弱です。</p>
<p><strong>安全な代替(Kerberos/MFA/現代的認証プロトコル)</strong>:
可能な限りKerberos認証を優先し、NTLMの使用は最小限に抑えるべきです。また、すべてのリモートアクセスにMFAを導入することが必須です。</p>
<h4 class="wp-block-heading">PowerShellによるNTLMv1の無効化(例)</h4>
<p>以下のPowerShellコマンドは、Windows環境においてNTLMv1を無効化し、NTLMv2のみを許可する設定の例です。これにより、NTLMv1ハッシュの窃取やリレー攻撃に対する耐性を向上させることができます。</p>
<div class="codehilite">
<pre data-enlighter-language="generic"># NTLMv1の使用を禁止し、NTLMv2のみを許可する設定
# レジストリパス: HKLM:\SYSTEM\CurrentControlSet\Control\Lsa
# 設定項目: LmCompatibilityLevel
# 値: 5 (NTLMv2応答のみを送信し、LMとNTLMを拒否する)
# 事前条件: 管理者権限でPowerShellを実行していること。
# 設定変更後、システム再起動が必要な場合がある。
# 入力: なし(レジストリパスと値を直接指定)
# 出力: なし(設定が成功した場合、エラーは発生しない)
# 計算量: O(1) - レジストリへの単一操作
# メモリ条件: 極めて小さい
Function Set-NTLMSecurityLevel {
[CmdletBinding()]
Param(
[Parameter(Mandatory=$true)]
[ValidateSet(0,1,2,3,4,5)]
[int]$Level # 0: LM & NTLMv1, 5: NTLMv2 only
)
$RegPath = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa"
$RegName = "LmCompatibilityLevel"
Write-Host "Setting LmCompatibilityLevel to $Level..."
try {
Set-ItemProperty -Path $RegPath -Name $RegName -Value $Level -Force
Write-Host "Successfully set LmCompatibilityLevel to $Level."
} catch {
Write-Error "Failed to set LmCompatibilityLevel: $($_.Exception.Message)"
}
}
# NTLMv2のみを許可する(NTLMv1を拒否)
Set-NTLMSecurityLevel -Level 5
# 設定が反映されているか確認する場合
# Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "LmCompatibilityLevel"
</pre>
</div>
<p>この設定はWindowsクライアント/サーバー向けであり、Check Pointゲートウェイ自体の認証設定とは直接関係しませんが、窃取されたNTLMハッシュの悪用リスクを軽減する、広範なセキュリティ対策の一環として重要です。</p>
<h2 class="wp-block-heading">運用対策</h2>
<h3 class="wp-block-heading">鍵/秘匿情報の取り扱い</h3>
<ul class="wp-block-list">
<li><p><strong>セキュアな保管</strong>: 認証情報や秘密鍵は、Check Pointゲートウェイ上に不必要に保存しない、または暗号化された安全なストアに保管します。設定ファイルに平文でパスワードを記述することは厳禁です。</p></li>
<li><p><strong>アクセス制御</strong>: ゲートウェイの管理インターフェースや設定ファイルへのアクセスは、最小権限の原則に基づき、必要な担当者のみに厳しく制限します。SSHアクセスには鍵認証を必須とし、パスワード認証を無効化することを推奨します。</p></li>
<li><p><strong>ローテーション</strong>: 侵害の疑いがある場合や定期的に、VPNユーザーのパスワード、ローカル管理アカウントのパスワード、SSH鍵、APIキーなど、すべての秘匿情報をローテーションします。</p></li>
</ul>
<h3 class="wp-block-heading">監査と監視</h3>
<ul class="wp-block-list">
<li><p><strong>詳細ログの有効化と集中管理</strong>: Check Pointゲートウェイおよび関連する認証システムの詳細なログを有効にし、SIEMなどの集中ログ管理システムに転送します。</p></li>
<li><p><strong>定期的なログレビュー</strong>: 不審なアクセスパターン、認証失敗の増加、未承認の変更がないか、定期的にログをレビューします。</p></li>
<li><p><strong>インシデントレスポンス計画</strong>: 脆弱性が悪用された場合のインシデントレスポンス計画を策定し、定期的に訓練を実施します。特に、侵害後の検知、封じ込め、根絶、復旧のプロセスを明確にします。</p></li>
</ul>
<h3 class="wp-block-heading">現場の落とし穴</h3>
<ul class="wp-block-list">
<li><p><strong>誤検知と検出遅延</strong>: IoCベースの検出は、攻撃者がIoCを回避する手法を用いると無効化される可能性があります。また、ログの量が多すぎると、重要なイベントが埋もれて検出が遅れることがあります。</p></li>
<li><p><strong>可用性とのトレードオフ</strong>: パッチ適用やMFAの強制、ネットワークセグメンテーションは、サービスの可用性に影響を与える可能性があります。特に、本番環境での変更は事前に十分なテストが必要です。</p></li>
<li><p><strong>MFAの過信</strong>: MFAは強力な防御策ですが、フィッシング攻撃やMFAプッシュ爆撃などの手法によって突破される可能性があります。MFA導入後も、ユーザーへのセキュリティ意識向上トレーニングは不可欠です。</p></li>
<li><p><strong>レガシーシステムの脆弱性</strong>: 内部ネットワークに存在するレガシーシステムが、窃取されたNTLMハッシュを用いた横展開の足がかりとなる可能性があります。これらのシステムの特定と保護も重要です。</p></li>
</ul>
<h2 class="wp-block-heading">まとめ</h2>
<p>CVE-2024-24919は、Check Point Quantum Security Gatewayに対する深刻な情報漏洩の脆弱性であり、攻撃連鎖を通じて内部ネットワークへの完全な侵害を許容する可能性があります。2024年5月27日より実環境での悪用が確認されており[2]、Check Pointは2024年5月28日に緊急パッチを公開しています[1]。</p>
<p>この脅威から組織を保護するためには、緊急パッチの適用が最優先事項です。それに加え、多要素認証の強制、厳格なネットワークセグメンテーション、認証ログの詳細な監視、そして鍵や秘匿情報のセキュアな管理とローテーションといった、多層防御のアプローチが不可欠です。運用面では、検出遅延や可用性トレードオフといった現場の落とし穴を認識し、適切なリスク管理とインシデントレスポンス計画の整備が求められます。</p>
<hr/>
<p><strong>参照情報</strong>:
[1] Check Point Software Technologies. “Check Point Response to CVE-2024-24919 – Quantum Gateway and CloudGuard Network Security Information Disclosure”. (公開日: 2024年5月28日).
[2] Volexity. “Zero-Day Exploitation of Check Point VPNs”. (公開日: 2024年5月27日).
[3] NIST National Vulnerability Database (NVD). “CVE-2024-24919 Detail”. (最終更新日: 2024年6月4日).</p>
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト(未検証)です。
Check Point CVE-2024-24919攻撃連鎖と緩和策
脅威モデル
CVE-2024-24919は、Check PointのQuantum Security GatewayおよびCloudGuard Network Security製品における情報漏洩の脆弱性です。この脆弱性は、認証されていないリモートの攻撃者が、特定のパス走査(Path Traversal)攻撃を悪用して、デバイス上の任意のファイルを読み取ることを可能にします。特に、ユーザーのNTLMハッシュやローカルアカウントのハッシュ化されたパスワードなど、認証情報を窃取されるリスクが高い点が問題視されています。
この脆弱性は、Check Point Quantum Security GatewayおよびCloudGuard Network SecurityのR81.20、R81.10、R81、R80.40、R77.30の各バージョンに影響を与えます。Volexityの報告によれば、この脆弱性は2024年5月27日以前から実環境で活発に悪用されていることが確認されており、高いリスクを伴います[1][2]。
攻撃者は窃取した認証情報を利用してVPN経由で内部ネットワークに侵入し、その後の横展開やデータ窃取を試みる可能性があります。この脅威モデルでは、インターネットに公開されたCheck Pointゲートウェイが初期侵入の足がかりとなり、最終的に企業ネットワーク全体が侵害されるシナリオを想定しています。
攻撃シナリオ
CVE-2024-24919を利用した攻撃連鎖は以下のステップで進行します。
初期アクセス: 攻撃者はインターネットに公開された脆弱なCheck Pointゲートウェイを特定します。この脆弱性は認証不要であるため、外部からのアクセスが可能です。
情報漏洩: 攻撃者はHTTPSポート(通常443/TCP)を通じて、特定のURLパスに細工されたリクエストを送信し、パス走査の脆弱性を悪用します。これにより、通常アクセスできないシステムファイル(例: id_resolver.conf、認証情報を含む設定ファイルなど)を読み取ります[2]。
認証情報窃取: 読み取ったファイルから、ユーザーのNTLMハッシュやローカルアカウントのハッシュ化されたパスワードなどの機微な認証情報を抽出します。
認証情報悪用: 攻撃者は窃取したNTLMハッシュをオフラインでクラックしたり、「パス・ザ・ハッシュ」攻撃などを用いて、有効なユーザーの認証情報を取得します。
内部ネットワーク侵入: 取得した認証情報(ユーザー名とパスワード)を悪用し、VPN接続を通じて企業内部ネットワークにリモートアクセスします。この段階で、多要素認証(MFA)が導入されていない場合、侵入は容易になります。
横展開と持続性: 内部ネットワークに侵入後、攻撃者はさらなる脆弱性を探索し、権限昇格、他のシステムへの横展開、マルウェアの展開、バックドアの設置などを行い、ネットワーク内での持続的なプレゼンスを確立します。
最終目的達成: 最終的に、機密データの窃取、システムの破壊、ランサムウェアの展開など、攻撃者の最終目的を達成します。
この攻撃連鎖は、Check Pointの公式アドバイザリやVolexityの分析によって裏付けられています[1][2]。
flowchart LR
A["外部攻撃者"] -->|1. 脆弱なゲートウェイを特定| B("Check Point Gateway")
B -->|2. CVE-2024-24919悪用 (パス走査)| C{"機微ファイル窃取"}
C -->|3. id_resolver.confなどから| D["NTLMハッシュ/ローカルパスワード取得"]
D -->|4. オフラインクラック/パス・ザ・ハッシュ| E["有効な認証情報"]
E -->|5. VPN/SSHなどでのリモートアクセス| F("内部ネットワーク侵入")
F -->|6. 横展開/権限昇格/持続性| G["データ窃取/システム改ざん/ランサムウェア"]
検出と緩和策
検出
IoC (Indicators of Compromise) の監視: Check PointおよびVolexityが提供するIoC(不審なIPアドレス、ファイルハッシュ、ネットワーク通信パターンなど)をSIEMやEDRで監視します[1][2]。
認証ログの監視:
VPN、SSH、Web管理インターフェースなど、Check Pointゲートウェイへの認証ログを詳細に監視します。
特に、地理的に不審な場所からのログイン、通常とは異なる時間帯のログイン、失敗したログイン試行の急増に注意します。
新規作成されたユーザーアカウントや権限変更のログを追跡します。
ファイルアクセスログの監視: ゲートウェイ上で不審なファイル読み取りアクセス(特に /etc/passwd や id_resolver.conf などの機微な設定ファイル)がないか監視します。ただし、詳細なファイルアクセスログがデフォルトで有効でない場合があります。
緩和策
緊急パッチ適用: Check Pointが2024年5月28日に公開した緊急ホットフィックス(Take 206 for R81.20, Take 111 for R81.10, Take 254 for R81, Take 970 for R80.40, Take 766 for R77.30)を直ちに適用します[1]。これは最も重要な緩和策です。
多要素認証 (MFA) の導入と強化:
- すべてのリモートアクセス(VPN、管理インターフェースなど)に対してMFAを強制します。これにより、認証情報が窃取された場合でも、攻撃者の侵入を阻止する可能性が高まります。
ネットワークセグメンテーション:
不要なサービスの無効化:
- ゲートウェイ上で不要なサービスやブレード(例: Identity AwarenessやMobile Accessなど、この脆弱性の悪用に関連する可能性のあるもの)を無効化します。
強力なパスワードポリシーと定期的なパスワードリセット:
- すべてのユーザーアカウントに対して、複雑でユニークなパスワードを強制し、定期的なパスワードリセットを義務付けます。特に、この脆弱性が公表されて以降、パスワードリセットは必須です。
暗号/プロトコルの安全な代替
CVE-2024-24919は直接的な暗号プロトコルの脆弱性ではありませんが、窃取されたNTLMハッシュが悪用されるリスクを考えると、認証プロトコルの安全な運用が重要になります。
誤用例(NTLMプロトコル):
多くのWindows環境でLegacy認証として利用されているNTLM(特にNTLMv1)は、ハッシュの脆弱性からパス・ザ・ハッシュ攻撃やオフラインクラッキングに対して脆弱です。
安全な代替(Kerberos/MFA/現代的認証プロトコル):
可能な限りKerberos認証を優先し、NTLMの使用は最小限に抑えるべきです。また、すべてのリモートアクセスにMFAを導入することが必須です。
PowerShellによるNTLMv1の無効化(例)
以下のPowerShellコマンドは、Windows環境においてNTLMv1を無効化し、NTLMv2のみを許可する設定の例です。これにより、NTLMv1ハッシュの窃取やリレー攻撃に対する耐性を向上させることができます。
# NTLMv1の使用を禁止し、NTLMv2のみを許可する設定
# レジストリパス: HKLM:\SYSTEM\CurrentControlSet\Control\Lsa
# 設定項目: LmCompatibilityLevel
# 値: 5 (NTLMv2応答のみを送信し、LMとNTLMを拒否する)
# 事前条件: 管理者権限でPowerShellを実行していること。
# 設定変更後、システム再起動が必要な場合がある。
# 入力: なし(レジストリパスと値を直接指定)
# 出力: なし(設定が成功した場合、エラーは発生しない)
# 計算量: O(1) - レジストリへの単一操作
# メモリ条件: 極めて小さい
Function Set-NTLMSecurityLevel {
[CmdletBinding()]
Param(
[Parameter(Mandatory=$true)]
[ValidateSet(0,1,2,3,4,5)]
[int]$Level # 0: LM & NTLMv1, 5: NTLMv2 only
)
$RegPath = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa"
$RegName = "LmCompatibilityLevel"
Write-Host "Setting LmCompatibilityLevel to $Level..."
try {
Set-ItemProperty -Path $RegPath -Name $RegName -Value $Level -Force
Write-Host "Successfully set LmCompatibilityLevel to $Level."
} catch {
Write-Error "Failed to set LmCompatibilityLevel: $($_.Exception.Message)"
}
}
# NTLMv2のみを許可する(NTLMv1を拒否)
Set-NTLMSecurityLevel -Level 5
# 設定が反映されているか確認する場合
# Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "LmCompatibilityLevel"
この設定はWindowsクライアント/サーバー向けであり、Check Pointゲートウェイ自体の認証設定とは直接関係しませんが、窃取されたNTLMハッシュの悪用リスクを軽減する、広範なセキュリティ対策の一環として重要です。
運用対策
鍵/秘匿情報の取り扱い
セキュアな保管: 認証情報や秘密鍵は、Check Pointゲートウェイ上に不必要に保存しない、または暗号化された安全なストアに保管します。設定ファイルに平文でパスワードを記述することは厳禁です。
アクセス制御: ゲートウェイの管理インターフェースや設定ファイルへのアクセスは、最小権限の原則に基づき、必要な担当者のみに厳しく制限します。SSHアクセスには鍵認証を必須とし、パスワード認証を無効化することを推奨します。
ローテーション: 侵害の疑いがある場合や定期的に、VPNユーザーのパスワード、ローカル管理アカウントのパスワード、SSH鍵、APIキーなど、すべての秘匿情報をローテーションします。
監査と監視
詳細ログの有効化と集中管理: Check Pointゲートウェイおよび関連する認証システムの詳細なログを有効にし、SIEMなどの集中ログ管理システムに転送します。
定期的なログレビュー: 不審なアクセスパターン、認証失敗の増加、未承認の変更がないか、定期的にログをレビューします。
インシデントレスポンス計画: 脆弱性が悪用された場合のインシデントレスポンス計画を策定し、定期的に訓練を実施します。特に、侵害後の検知、封じ込め、根絶、復旧のプロセスを明確にします。
現場の落とし穴
誤検知と検出遅延: IoCベースの検出は、攻撃者がIoCを回避する手法を用いると無効化される可能性があります。また、ログの量が多すぎると、重要なイベントが埋もれて検出が遅れることがあります。
可用性とのトレードオフ: パッチ適用やMFAの強制、ネットワークセグメンテーションは、サービスの可用性に影響を与える可能性があります。特に、本番環境での変更は事前に十分なテストが必要です。
MFAの過信: MFAは強力な防御策ですが、フィッシング攻撃やMFAプッシュ爆撃などの手法によって突破される可能性があります。MFA導入後も、ユーザーへのセキュリティ意識向上トレーニングは不可欠です。
レガシーシステムの脆弱性: 内部ネットワークに存在するレガシーシステムが、窃取されたNTLMハッシュを用いた横展開の足がかりとなる可能性があります。これらのシステムの特定と保護も重要です。
まとめ
CVE-2024-24919は、Check Point Quantum Security Gatewayに対する深刻な情報漏洩の脆弱性であり、攻撃連鎖を通じて内部ネットワークへの完全な侵害を許容する可能性があります。2024年5月27日より実環境での悪用が確認されており[2]、Check Pointは2024年5月28日に緊急パッチを公開しています[1]。
この脅威から組織を保護するためには、緊急パッチの適用が最優先事項です。それに加え、多要素認証の強制、厳格なネットワークセグメンテーション、認証ログの詳細な監視、そして鍵や秘匿情報のセキュアな管理とローテーションといった、多層防御のアプローチが不可欠です。運用面では、検出遅延や可用性トレードオフといった現場の落とし穴を認識し、適切なリスク管理とインシデントレスポンス計画の整備が求められます。
参照情報:
[1] Check Point Software Technologies. “Check Point Response to CVE-2024-24919 – Quantum Gateway and CloudGuard Network Security Information Disclosure”. (公開日: 2024年5月28日).
[2] Volexity. “Zero-Day Exploitation of Check Point VPNs”. (公開日: 2024年5月27日).
[3] NIST National Vulnerability Database (NVD). “CVE-2024-24919 Detail”. (最終更新日: 2024年6月4日).
コメント