diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-dirty-nib.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-dirty-nib.md index 00362d0eb..93dc5077f 100644 --- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-dirty-nib.md +++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-dirty-nib.md @@ -2,72 +2,149 @@ {{#include ../../../banners/hacktricks-training.md}} -**有关该技术的更多详细信息，请查看原始帖子：** [**https://blog.xpnsec.com/dirtynib/**](https://blog.xpnsec.com/dirtynib/) 和以下帖子 [**https://sector7.computest.nl/post/2024-04-bringing-process-injection-into-view-exploiting-all-macos-apps-using-nib-files/**](https://sector7.computest.nl/post/2024-04-bringing-process-injection-into-view-exploiting-all-macos-apps-using-nib-files/)**。** 这里是一个总结： +Dirty NIB 指滥用签名的 macOS 应用包内的 Interface Builder 文件（.xib/.nib），在目标进程内执行攻击者控制的逻辑，从而继承其 entitlements 和 TCC 权限。该技术最初由 xpn (MDSec) 记录，后由 Sector7 进行了泛化和大幅扩展，并覆盖了 Apple 在 macOS 13 Ventura 和 macOS 14 Sonoma 中的缓解措施。有关背景和深入解析，请参见文末的参考资料。 -### 什么是 Nib 文件 +> 要点 +> • 在 macOS 13 Ventura 之前：替换一个 bundle 的 MainMenu.nib（或其他在启动时加载的 nib）通常可以可靠地实现 process injection，并常常导致 privilege escalation。 +> • 自 macOS 13 (Ventura) 并在 macOS 14 (Sonoma) 中进一步改进：first‑launch 深度验证、bundle 保护、Launch Constraints 以及新的 TCC “App Management” permission 在很大程度上阻止了无关应用在启动后修改 nib。攻击在一些小众场景仍可能可行（例如，同一开发者的工具修改自己的应用，或用户授予终端 App Management/Full Disk Access）。 -Nib（NeXT Interface Builder 的缩写）文件是苹果开发生态系统的一部分，旨在定义应用程序中的 **UI 元素** 及其交互。它们包含序列化对象，如窗口和按钮，并在运行时加载。尽管它们仍在使用，苹果现在提倡使用 Storyboards 以获得更全面的 UI 流可视化。 +## What are NIB/XIB files -主 Nib 文件在应用程序的 `Info.plist` 文件中的值 **`NSMainNibFile`** 中引用，并由在应用程序的 `main` 函数中执行的 **`NSApplicationMain`** 函数加载。 +Nib（来源于 NeXT Interface Builder）文件是用于 AppKit 应用的序列化 UI 对象图。现代 Xcode 存储可编辑的 XML .xib 文件，这些文件在构建时会被编译成 .nib。典型应用通过 `NSApplicationMain()` 加载其主 UI，该函数从应用的 Info.plist 中读取 `NSMainNibFile` 键并在运行时实例化对象图。 -### Dirty Nib 注入过程 +使该攻击可行的关键点： +- NIB 加载会实例化任意 Objective‑C 类，而不要求它们遵循 NSSecureCoding（当不存在 `initWithCoder:` 时，Apple 的 nib loader 会回退到 `init`/`initWithFrame:`）。 +- Cocoa Bindings 可被滥用在 nib 实例化时调用方法，包括不需要用户交互的链式调用。 -#### 创建和设置 NIB 文件 -1. **初始设置**： -- 使用 XCode 创建一个新的 NIB 文件。 -- 向界面添加一个对象，将其类设置为 `NSAppleScript`。 -- 通过用户定义的运行时属性配置初始 `source` 属性。 -2. **代码执行工具**： -- 该设置便于按需运行 AppleScript。 -- 集成一个按钮以激活 `Apple Script` 对象，特别触发 `executeAndReturnError:` 选择器。 -3. **测试**： +## Dirty NIB injection process (attacker view) -- 一个简单的 Apple Script 用于测试： +经典的 pre‑Ventura 流程： +1) Create a malicious .xib +- 添加一个 `NSAppleScript` 对象（或其他“gadget”类，例如 `NSTask`）。 +- 添加一个 `NSTextField`，其 title 包含 payload（例如 AppleScript 或命令参数）。 +- 添加一个或多个 `NSMenuItem`，通过 bindings 接线以在目标对象上调用方法。 -```bash +2) Auto‑trigger without user clicks +- 使用 bindings 设置菜单项的 target/selector，然后调用私有方法 `_corePerformAction`，使得在 nib 加载时动作自动触发。这样就不需要用户点击按钮。 + +Minimal example of an auto‑trigger chain inside a .xib (abridged for clarity): +```xml + + + + + + + + + + + + + + + + + + + + + + +``` +这会在 nib 加载时在目标进程中实现任意 AppleScript 执行。 + +高级链可以： +- 实例化任意 AppKit 类（例如 `NSTask`）并调用像 `-launch` 这样的无参方法。 +- 通过上面的 binding 技巧使用对象参数调用任意 selector。 +- 加载 AppleScriptObjC.framework 以桥接到 Objective‑C，甚至调用特定的 C API。 +- 在仍包含 Python.framework 的旧系统上，可以桥接到 Python，然后使用 `ctypes` 调用任意 C 函数（Sector7 的研究）。 + +3) 替换应用的 nib +- 将 target.app 复制到可写位置，替换例如 `Contents/Resources/MainMenu.nib` 为恶意 nib，然后运行 target.app。Pre‑Ventura 下，在一次 Gatekeeper 评估之后，后续启动仅执行浅层签名检查，因此非可执行资源（例如 .nib）不会被重新验证。 + +Example AppleScript payload for a visible test: +```applescript set theDialogText to "PWND" display dialog theDialogText ``` +## Modern macOS protections (Ventura/Monterey/Sonoma/Sequoia) -- 通过在 XCode 调试器中运行并点击按钮进行测试。 +Apple 引入了若干系统性缓解措施，大幅降低了 Dirty NIB 在现代 macOS 上的可行性： +- 首次启动的深度验证与 bundle 保护 (macOS 13 Ventura) +- 在任何应用的首次运行时（无论是否被 quarantine），系统会对所有 bundle 资源进行深度签名校验。此后，bundle 会受到保护：只有来自相同开发者（或被应用明确允许）的应用可以修改其内容。其他应用要想写入另一个应用的 bundle，需要新的 TCC “App Management” 权限。 +- Launch Constraints (macOS 13 Ventura) +- 系统/Apple 捆绑的应用无法被复制到其他位置并被启动；这封堵了对系统应用使用 “复制到 /tmp、修改、运行” 的方法。 +- macOS 14 Sonoma 的改进 +- Apple 强化了 App Management 并修补了已知的绕过（例如由 Sector7 报告的 CVE‑2023‑40450）。Python.framework 在更早的版本被移除（macOS 12.3），这中断了某些提权链。 +- Gatekeeper/Quarantine 变更 +- 关于 Gatekeeper、provenance 和 assessment 的更广泛讨论以及这些变化如何影响该技术，请参见下方引用的页面。 -#### 目标应用程序（示例：Pages） +> Practical implication +> • 在 Ventura 及更高版本中，除非你的进程拥有 App Management 或与目标使用相同 Team ID（例如开发工具），否则通常无法修改第三方应用的 .nib。 +> • 给 shell/terminal 授予 App Management 或 Full Disk Access 实际上会重新打开这一攻击面，允许任何能在该终端上下文中执行代码的实体利用它。 -1. **准备**： -- 将目标应用程序（例如，Pages）复制到一个单独的目录（例如，`/tmp/`）。 -- 启动应用程序以绕过 Gatekeeper 问题并进行缓存。 -2. **覆盖 NIB 文件**： -- 用制作的 DirtyNIB 文件替换现有的 NIB 文件（例如，关于面板 NIB）。 -3. **执行**： -- 通过与应用程序交互（例如，选择 `About` 菜单项）触发执行。 -#### 概念验证：访问用户数据 +### Addressing Launch Constraints -- 修改 AppleScript 以访问和提取用户数据，例如照片，而无需用户同意。 +Launch Constraints 从 Ventura 开始阻止从非默认位置运行许多 Apple 应用。如果你此前依赖于 pre‑Ventura 的工作流（例如将 Apple 应用复制到临时目录、修改 `MainMenu.nib` 然后启动），在 >= 13.0 上预计会失败。 -### 代码示例：恶意 .xib 文件 -- 访问并查看 [**恶意 .xib 文件的示例**](https://gist.github.com/xpn/16bfbe5a3f64fedfcc1822d0562636b4)，演示执行任意代码。 +## Enumerating targets and nibs (useful for research / legacy systems) -### 其他示例 +- Locate apps whose UI is nib‑driven: +```bash +find /Applications -maxdepth 2 -name Info.plist -exec sh -c \ +'for p; do if /usr/libexec/PlistBuddy -c "Print :NSMainNibFile" "$p" >/dev/null 2>&1; \ +then echo "[+] $(dirname "$p") uses NSMainNibFile=$( /usr/libexec/PlistBuddy -c "Print :NSMainNibFile" "$p" )"; fi; done' sh {} + +``` +- 在 bundle 中查找候选的 nib 资源: +```bash +find target.app -type f \( -name "*.nib" -o -name "*.xib" \) -print +``` +- 深入验证 code signatures (如果你篡改了资源且没有 re‑sign，会失败): +```bash +codesign --verify --deep --strict --verbose=4 target.app +``` +> 注意：在现代 macOS 上，尝试在未获得适当授权的情况下写入另一个应用的 bundle，会被 bundle protection/TCC 阻止。 -在帖子 [https://sector7.computest.nl/post/2024-04-bringing-process-injection-into-view-exploiting-all-macos-apps-using-nib-files/](https://sector7.computest.nl/post/2024-04-bringing-process-injection-into-view-exploiting-all-macos-apps-using-nib-files/) 中，您可以找到有关如何创建脏 NIB 的教程。 -### 解决启动限制 +## 检测与 DFIR 建议 -- 启动限制阻碍应用程序从意外位置（例如，`/tmp`）执行。 -- 可以识别未受启动限制保护的应用程序，并将其作为 NIB 文件注入的目标。 +- 对 bundle 资源进行文件完整性监控 +- 监控已安装应用中 `Contents/Resources/*.nib` 及其他非可执行资源的 mtime/ctime 更改。 +- 统一日志与进程行为 +- 监控 GUI 应用中意外的 AppleScript 执行，以及加载 AppleScriptObjC 或 Python.framework 的进程。示例： +```bash +log stream --info --predicate 'processImagePath CONTAINS[cd] ".app/Contents/MacOS/" AND (eventMessage CONTAINS[cd] "AppleScript" OR eventMessage CONTAINS[cd] "loadAppleScriptObjectiveCScripts")' +``` +- 主动评估 +- 定期对关键应用运行 `codesign --verify --deep`，以确保资源保持完整。 +- 权限上下文 +- 审计哪些用户/进程拥有 TCC “App Management” 或 Full Disk Access（尤其是终端和管理代理）。将这些权限从通用 shell 中移除，可以防止轻易重新启用 Dirty NIB‑style 的篡改。 -### 其他 macOS 保护 -从 macOS Sonoma 开始，应用程序包内的修改受到限制。然而，早期的方法包括： +## 防御加固（开发者和防御者） -1. 将应用程序复制到不同的位置（例如，`/tmp/`）。 -2. 重命名应用程序包内的目录以绕过初始保护。 -3. 在运行应用程序以注册 Gatekeeper 后，修改应用程序包（例如，用 Dirty.nib 替换 MainMenu.nib）。 -4. 将目录重命名回去并重新运行应用程序以执行注入的 NIB 文件。 +- 优先使用编程式 UI 或限制从 nib 实例化的内容。避免在 nib 图中包含强力类（例如 `NSTask`），并避免会间接对任意对象调用 selectors 的 bindings。 +- 采用带有 Library Validation 的 hardened runtime（现代应用已普遍使用）。虽然这本身无法阻止 nib injection，但它会阻断轻易的本地代码加载，迫使攻击者仅使用脚本型 payloads。 +- 不要在通用工具中请求或依赖广泛的 App Management 权限。如果 MDM 需要 App Management，将该上下文与用户驱动的 shell 隔离开来。 +- 定期验证应用 bundle 的完整性，并使你的更新机制能够自我修复 bundle 资源。 -**注意**：最近的 macOS 更新通过防止在 Gatekeeper 缓存后修改应用程序包内的文件来减轻此漏洞，使该漏洞无效。 + +## HackTricks 相关阅读 + +了解更多影响此技术的 Gatekeeper、quarantine 与 provenance 更改： + +{{#ref}} +../macos-security-protections/macos-gatekeeper.md +{{#endref}} + + +## 参考资料 + +- xpn – DirtyNIB（原始文章，包含 Pages 示例）：https://blog.xpnsec.com/dirtynib/ +- Sector7 – Bringing process injection into view(s): exploiting all macOS apps using nib files (April 5, 2024): https://sector7.computest.nl/post/2024-04-bringing-process-injection-into-view-exploiting-all-macos-apps-using-nib-files/ {{#include ../../../banners/hacktricks-training.md}}