CVE-2024-24919 是一个关键的 Check Point Security Gateways 零日漏洞，允许未经认证的远程攻击者从受影响系统中读取任意文件。该漏洞于 2024 年 5 月被发现并在野外被积极利用，针对启用了远程访问 VPN 或移动接入 Blade 的设备。攻击者可利用此漏洞访问敏感文件（如密码哈希和 SSH 密钥），进而可能完全控制系统。鉴于其严重性和已被利用的状态，强烈建议立即修补和缓解。
为调查并修复该警报，我采取了以下步骤：
以下各步骤均配有图片详细说明。
安全运营中心（SOC）工单队列是管理和响应网络安全事件的关键组件。其作用包括：事件跟踪与管理、优先级排序与分诊、责任归属、报告、趋势分析以及合规与审计准备。
队列中的每个工单通常分配给特定的分析师或团队，确保事件解决的责任明确。这有助于建立结构化和有组织的事件管理方式。我领取了事件ID为 263 的警报所有权。
领取警报后，它会自动发送到调查频道，我可以在其中创建案件以进一步分析并响应安全事件。我为该警报创建了一个案件，并查看了事件详情。
根据警报提供的信息，发现服务器“CP-Spark-Gateway-01”（IP 地址 172.16.20.146）上检测到可疑的 Web 攻击。警报由 SOC287 规则触发，该规则针对 Checkpoint Security Gateway 任意文件读取漏洞 [CVE-2024–24919]，且设备动作为“允许”。
为了更好地理解该警报，我就报告的 CVE-2024–24919 进行了开源情报（OSINT）调查，并获取了与该 CVE 相关的重要信息。
接下来，我使用 LetsDefend 提供的威胁情报平台进行了威胁情报分析，该平台拥有专门收录恶意信息（如 IP 地址、域名和其他入侵指标）的全面数据库。我使用了源 IP 地址 203.160.68.12。
此外，我还使用 VirusTotal 对同一 IP 地址进行了威胁情报分析，发现 4 家安全厂商将该恶意软件标记为恶意活动，IP 的地理位置为香港。
这确认了来自 IP 203.160.68.12 的流量是恶意的。因此，我需要进一步调查，通过分析日志来确定我的网络中有多少主机与该恶意 IP 进行过通信。
我开始分析访问日志，重点关注 IP 地址、用户代理、路径、HTTP 状态码和时间戳，以识别任何可疑或恶意活动。
在检查 HTTP 流量之前，我调查了用于利用相关漏洞的载荷。我在 GitHub 仓库 https://github.com/seed1337/CVE-2024-24919-POC/blob/main/exploit.py 中找到了这个公开的 POC（概念验证）。
接着，我进入日志管理页面，按恶意源 IP 地址 203.160.68.12 过滤日志，以查看有多少主机与其接触过。经搜索网络，我发现只有名为“CP-Spark-Gateway-01”（IP 地址 172.16.20.146）的主机与该恶意 IP 有过通信。
下面的日志信息显示，恶意 IP 地址 203.160.68.12 使用 POST 方法发送了恶意载荷 aCSHELL/../../../../../../../../../../etc/shadow —— 这试图通过目录遍历读取主机“CP-Spark-Gateway-01”（IP 地址 172.16.20.146）上的敏感 /etc/shadow 文件，发生时间为 2024 年 6 月 6 日。
/etc/shadow 文件是 Unix/Linux 操作系统中的关键文件，存储用户帐户的哈希密码和帐户过期详情。因此，我可以判断攻击者试图窃取用户凭据，并且从上述日志中注意到，请求被允许且返回了 200 状态码。
这进一步证明了该攻击是恶意的。
遏制在网络安全中起着关键作用，可以限制安全事件的影响、保护数据和运营、促进有效的事件响应、为取证分析保留证据，并确保符合法律和监管要求。
由于我已检测到设备受损，我继续对设备“CP-Spark-Gateway-01”（IP 地址 172.16.20.146）进行隔离，以防止进一步损害。
修复是强大网络安全策略的基本组成部分。它涉及修复漏洞并解决安全问题，以防止被利用、保护数据、维持运营并遵守法规，最终打造一个更安全、更具韧性的组织。为修复并防止未来再次发生，应采取以下步骤：
完成分析后，我在“分析师笔记”部分记录了我的发现，并报告了工件和 IOC。
完成调查后，我认定该警报为真实阳性。我撰写了一份关闭说明，解释了警报的原因、分析步骤、分析结果以及采取的修复措施，并成功关闭了警报。
