Category: 产品研究

摘要 基板管理控制器（BMC）是现代数据中心服务器的隐性管理者，通过 IPMI 协议提供与主操作系统完全隔离的带外控制能力。其串行 over LAN（SOL）通道可在不触发主机 EDR 的情况下，建立直通系统串行控制台的隐蔽通信隧道。然而，IPMI 2.0 的 RAKP+ 认证握手存在根本性设计缺陷——空口令、Cipher 0 旁路及会话状态机混乱，使得攻击者能在数秒内劫持合法会话或自行建立恶意会话。 BMC 与 IPMI BMC 的硬件定位与特权 BMC 是嵌入在服务器主板上的独立片上系统，拥有自己的 CPU、内存、存储和专用网口。它在电源接通后先于主 CPU 启动，即使主操作系统崩溃或被攻陷，BMC 仍可对外提供远程管理功能——包括电源控制、固件更新、虚拟介质挂载和串行控制台重定向。BMC 通过内部总线（LPC/eSPI）与主机的南桥/芯片组连接，可注入键盘、鼠标和视频信号，实现对主机操作系统的完全带外控制。 这一架构意味着：BMC 是主机的“房东”，而主机操作系统只是“租客”。租客无法阻止房东进入房间，甚至无法察觉房东是否在房间里。 IPMI 协议栈与 SOL 通道 IPMI 是 BMC 与外部管理软件通信的标准协议，定义了请求/响应消息格式、会话管理和传输层绑定（RMCP/RMCP+）。IPMI 2.0 引入了增强认证（RAKP+）和加密通信，但保留了向后兼容的 Cipher 0（无认证无加密）模式。 SOL 是 IPMI 2.0 的可选扩展，它将主机的物理串行端口（UART）封装为 IPMI 的 SOL 消息，通过 RMCP+ 会话在 LAN 上传输。对主机操作系统而言，SOL 只是往串口收发数据，完全不知道数据经由 BMC…

摘要 Chromium 的多进程架构将高风险渲染器囚禁于受限沙箱，所有特权操作必须通过 Mojo IPC 向浏览器进程发起请求。Mojo 接口定义语言（.mojom）自动生成序列化代码，以 C++ 模板的 StructTraits 和 UnionTraits 实现高效编解码。然而，正是这种自动生成的序列化逻辑隐藏了一类致命的陷阱——接口参数校验与调用者能力假设之间的裂缝。攻击者在获得渲染器代码执行权限后，可构造跨越沙箱边界的畸形 Mojo 消息：向 FileSystemManager 接口注入路径遍历序列，利用 Blob 存储系统绕过站点隔离，或通过 WindowOpen 等接口制造幽灵窗口。 Chromium 沙箱架构与 Mojo IPC 基础 站点隔离与进程模型 Chromium 采用 Site Isolation 策略，每个源（origin）被分配到独立的渲染器进程。渲染器运行在受限沙箱中，无法直接访问文件系统、网络或系统调用。任何此类操作必须通过 Mojo 接口向浏览器进程（Browser Process）发出请求，浏览器进程进行权限验证后代理执行。 Mojo 是 Chromium 自研的 IPC 框架，替代了早期的 Legacy IPC 和 ChannelProxy。它提供跨进程的消息传递、接口定义、自动生成绑定代码以及版本控制。Mojo 的核心抽象是 Message Pipe（消息管道），两端由 mojo::Remote 和 mojo::Receiver 持有，分别用于发送和接收接口方法的调用。 Mojo 接口定义与代码生成 Mojo 接口使用 .mojom IDL 定义，例如： // FileSystemManager.mojom (简化) interface FileSystemManager { OpenFile(string path, OpenFlags flags) => (file.File file);…

摘要 SQLite 的 WAL 模式通过将写操作先追加到 Write-Ahead Log，再通过 Checkpoint 批量合并至主数据库，实现了读写并发的性能飞跃。然而，这一架构也引入了时间维度上的信息残余：已删除的记录在 WAL 文件中保留至下一次 Checkpoint 执行，且应用程序通常依赖 SQLite 的自动 Checkpoint 策略（1000 页阈值或连接关闭时触发），这为攻击者提供了充裕的窗口。攻击者可通过延迟 Checkpoint、强制持有读锁阻止 WAL 清理，使 WAL 文件中的“已删除”数据保留数小时甚至数天；随后仅需解析 WAL 的帧格式，即可从 $WAL 文件中提取已被主数据库删除的敏感记录，实现对“历史状态”的时间旅行攻击。 WAL 模式的并发模型与锁定机制 WAL模式设计初衷 在传统的 SQLite Rollback Journal 模式下，写操作需要持有独占的数据库级锁，导致读写无法并发。WAL 模式通过将新的写入追加到独立的 WAL 文件末尾，使读操作可以直接访问主数据库文件中的未修改页面，同时在 WAL 文件中查找更新后的版本。 ┌─────────────────────────────────────────────────────────────┐ │ 系统内存 (共享内存) │ │ │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ 共享内存索引文件 (-shm) │…

摘要 TLS 握手的第一步——ClientHello 消息——在明文传输中承载了客户端支持的加密套件、TLS 版本和数十个扩展字段，其精确组合构成了每个 TLS 实现的独特指纹。JA3 及其继任者 JA4 将这些字段哈希化，为网络防御者提供了一柄识别恶意软件与异常流量的利器。然而，指纹的稳定性本身就是一把双刃剑：Go 的 crypto/tls 与浏览器的 BoringSSL 在扩展排列、GREASE 扩展生成和 ALPN 排序上的细微差异，形成了不可伪造的指纹裂隙。攻击者利用 utls 等库精心伪造 ClientHello，却仍在 JA4 指纹空间中留下暴露真实客户端的二阶痕迹。 ClientHello 指纹的构建原理 从 JA3 到 JA4 JA3 指纹由 Salesforce 在 2017 年提出，通过对 ClientHello 中的 TLS 版本、密码套件、扩展列表和椭圆曲线参数进行 MD5 哈希，生成一个 32 字符的指纹字符串。其核心假设是：同一 TLS 实现的 ClientHello 在这些字段上保持稳定，从而可作为识别特定客户端软件（如 Chrome、Python requests、Go 程序）的强标识。 然而，JA3 存在两个根本性局限： 对 QUIC 无效：JA3 基于 TLS over TCP，对…

摘要 Apple Silicon 的安全启动链从 Boot ROM 到 iBoot 再到 Kernelcache，层层验证，构筑了封闭生态中最坚固的信任根基。然而，iBoot 阶段的系统内存管理单元初始化和设备树解析，依赖一套早于 XNU 内核建立的内存映射机制。攻击者若能在 iBoot 执行阶段污染设备树中的 DART 节点，便可在 SMMU 页表创建之前植入虚假的 IOMMU 映射，使内核在不知情的情况下使用被篡改的 DMA 保护配置。 Apple Silicon 的启动链与信任模型 从 Boot ROM 到 Kernelcache 的信任传递 Apple Silicon Mac 的启动过程分为四个严格校验的阶段： Boot ROM：芯片出厂固化代码，不可修改。验证下一阶段的签名（iBoot），仅在 DFU 模式下可通过外部刷新进行恢复。这是信任的物理根基，也是 checkm8 等永久性漏洞的所在层。 iBoot：Apple 的第二阶段引导加载器，负责初始化硬件（包括 SMMU、内存控制器、PCIe 根复合体），解析设备树并选择启动内核。iBoot 本身由 Boot ROM 验证签名。 Kernelcache：XNU 内核及其扩展的预链接映像，由 iBoot 验证签名后解压加载。内核启动后依赖 iBoot…

摘要 Windows 受保护进程轻量级是微软自 Windows 8.1 以来构建的核心安全边界，通过基于数字签名的层级信任模型阻止恶意代码篡改反恶意软件和端点安全产品。本文从 PPL 信任层级架构出发，逐层拆解 ClipUp 提权与 EDR-Freeze 竞态条件的技术原理，将 BYOVD 与 PPL 滥用合二为一的融合攻击链，并讨论跨 PPL 等级的内存转储攻击面及检测盲区。 PPL信任边界 Windows Vista 首次引入了受保护进程模型：进程要么受保护，要么不受保护。该模型过于二元化，无法适应实际安全需求。从 Windows 8.1 开始，微软引入 PPL 扩展了这一概念，引入了保护级别层级，使得某些受保护进程比另一些更受保护，且定义了一个根本性原则：不受保护的进程只能使用受限的访问标志集（如 PROCESS_QUERY_LIMITED_INFORMATION）打开受保护的进程，若请求更高访问权限则返回拒绝访问错误。 对于 PP/PPL 进程而言，其可请求的访问权限取决于自身的保护级别，该级别部分由文件数字证书中的特殊增强密钥使用字段决定。进程创建时，保护信息存入 EPROCESS 内核结构中的特定字段，存储着保护级别（PP 或 PPL）以及签名者类型（如反恶意软件、LSA、WinTcb 等）。 签名者类型在 PP/PPL 之间构建了严格层级： 若 PP 的签名者类型高于或等于目标 PP/PPL，则可以完整访问目标进程 若 PPL 的签名者类型高于或等于目标 PPL，则可以完整访问目标进程 PPL 无法以完整访问权限打开 PP，无论前者使用何种签名者类型 PPL 的签名者类型构成了四条明确的信任等级，每一层都有其典型代表进程和关键特权： 保护层级 签名者类型 典型进程 关键特权 可访问对象 WinTcb-Light…