Category: 产品研究

摘要 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…

Burp Suite 介绍 Burp Suite是一款用于攻击和测试Web应用程序的集成平台，它包含了多种工具，如代理、重发器、扫描器、爬虫、Intruder、Repeater等，可以协同工作，共享信息，支持各种攻击和检测方法。 Burp Suite的插件是一种扩展Burp Suite功能的方式，可以通过Burp Extender模块来安装和管理。插件可以由社区用户创建和维护，也可以由自己编写。插件可以修改HTTP请求和响应，发送额外的HTTP请求，自定义Burp Suite的界面和功能，添加额外的扫描检查，访问Burp Suite的信息等。 在本文中，我们将介绍 Burp Suite 插件，并使用 IDEA 工具编写简单的自定义插件。 配置环境 首先我们需要安装 IDE 工具，可以下载 IntelliJ IDEA、Atom、Netbeans、Eclipse 等。 Java 环境： Java 环境我们将在后续文章中以使用 IDEA 工具编写为例介绍。  Python 环境： Burp Suite 依赖 Jython 来支持 Python，需要下载 Jython 并配置 Burp Suite 位置。 在 Burp Suite 页面加载 Python 插件需要选择扩展类型为 Python 并指定 Python 插件文件。 API Extender…