macOS Gatekeeper / Quarantine / XProtect
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Gatekeeper 是为 Mac 操作系统开发的安全功能，旨在确保用户 仅运行受信任的软件。它通过 验证用户下载并尝试从 App Store 以外的来源打开的软件（例如应用程序、插件或安装包）来实现。
Gatekeeper 的关键机制在于其 验证 过程。它检查下载的软件是否 由认可的开发者签名，以确保软件的真实性。此外，它还确认该软件是否 经过 Apple 的公证，以确认其不含已知的恶意内容，并且在公证后未被篡改。
此外，Gatekeeper 通过 提示用户首次批准打开下载的软件 来增强用户控制和安全性。此保护措施有助于防止用户无意中运行可能有害的可执行代码，而将其误认为无害的数据文件。
应用程序签名，也称为代码签名，是 Apple 安全基础设施的关键组成部分。它们用于 验证软件作者的身份（开发者），并确保自上次签名以来代码未被篡改。
其工作原理如下：
签名应用程序： 当开发者准备分发其应用程序时，他们 使用私钥签名应用程序。此私钥与 Apple 在开发者注册 Apple Developer Program 时向开发者颁发的证书 相关联。签名过程涉及创建应用程序所有部分的加密哈希，并使用开发者的私钥加密该哈希。
分发应用程序： 签名的应用程序随后与开发者的证书一起分发，该证书包含相应的公钥。
验证应用程序： 当用户下载并尝试运行应用程序时，他们的 Mac 操作系统使用开发者证书中的公钥解密哈希。然后，它根据应用程序的当前状态重新计算哈希，并将其与解密后的哈希进行比较。如果它们匹配，则意味着 自开发者签名以来，应用程序未被修改，系统允许该应用程序运行。
应用程序签名是 Apple Gatekeeper 技术的重要组成部分。当用户尝试 打开从互联网下载的应用程序 时，Gatekeeper 会验证应用程序签名。如果它是由 Apple 向已知开发者颁发的证书签名，并且代码未被篡改，Gatekeeper 允许该应用程序运行。否则，它会阻止该应用程序并提醒用户。
从 macOS Catalina 开始，Gatekeeper 还检查应用程序是否经过 Apple 的公证，增加了一层额外的安全性。公证过程检查应用程序是否存在已知的安全问题和恶意代码，如果这些检查通过，Apple 会向应用程序添加一个 Gatekeeper 可以验证的票据。
在检查某些 恶意软件样本 时，您应始终 检查二进制文件的签名，因为 签名 的开发者可能已经 与恶意软件相关。
苹果的 notarization 过程作为额外的保护措施，旨在保护用户免受潜在有害软件的影响。它涉及 开发者提交他们的应用程序进行审查，由 苹果的 Notary Service 进行，这与应用审核不应混淆。该服务是一个 自动化系统，对提交的软件进行审查，以检查是否存在 恶意内容 和任何潜在的代码签名问题。
如果软件 通过 了这次检查而没有引发任何问题，Notary Service 会生成一个 notarization 票据。开发者随后需要 将此票据附加到他们的软件上，这个过程称为“stapling”。此外，notarization 票据也会在线发布，Gatekeeper，苹果的安全技术，可以访问它。
在用户首次安装或执行软件时，notarization 票据的存在 - 无论是附加在可执行文件上还是在线找到 - 通知 Gatekeeper 该软件已由苹果进行 notarization。因此，Gatekeeper 在初始启动对话框中显示一条描述性消息，表明该软件已通过苹果的恶意内容检查。这个过程增强了用户对他们在系统上安装或运行的软件安全性的信心。
请注意，从 Sequoia 版本开始，spctl 不再允许修改 Gatekeeper 配置。
spctl 是用于枚举和与 Gatekeeper 交互的 CLI 工具（通过 XPC 消息与 syspolicyd 守护进程交互）。例如，可以使用以下命令查看 GateKeeper 的 状态：
请注意，GateKeeper 签名检查仅对 具有隔离属性的文件 执行，而不是对每个文件。
GateKeeper 将根据 首选项和签名 检查二进制文件是否可以执行：
syspolicyd 是负责执行 Gatekeeper 的主要守护进程。它维护一个位于 /var/db/SystemPolicy 的数据库，可以在 这里找到支持该数据库的代码 和 这里找到 SQL 模板。请注意，该数据库不受 SIP 限制，并且可以由 root 写入，数据库 /var/db/.SystemPolicy-default 用作原始备份，以防其他数据库损坏。
此外，/var/db/gke.bundle 和 /var/db/gkopaque.bundle 包含插入数据库的规则文件。您可以使用 root 权限检查此数据库：
syspolicyd 还暴露了一个 XPC 服务器，具有不同的操作，如 assess、update、record 和 cancel，这些操作也可以通过 Security.framework 的 SecAssessment* API 访问，而 xpctl 实际上通过 XPC 与 syspolicyd 进行通信。
注意第一个规则以 "App Store" 结束，第二个规则以 "Developer ID" 结束，并且在之前的图像中，它是 启用从 App Store 和已识别开发者执行应用程序。 如果您 修改 该设置为 App Store，"Notarized Developer ID" 规则将消失。
还有成千上万的 类型 GKE 的规则：
这些是来自以下位置的哈希：
/var/db/SystemPolicyConfiguration/gke.bundle/Contents/Resources/gke.auth
/var/db/gke.bundle/Contents/Resources/gk.db
/var/db/gkopaque.bundle/Contents/Resources/gkopaque.db
或者你可以使用以下命令列出之前的信息：
选项 --master-disable 和 --global-disable 的 spctl 将完全 禁用 这些签名检查：
当完全启用时，将出现一个新选项：
可以通过以下方式检查一个应用是否会被GateKeeper允许：
可以在GateKeeper中添加新规则，以允许某些应用程序的执行：
关于 内核扩展，文件夹 /var/db/SystemPolicyConfiguration 包含允许加载的 kext 列表文件。此外，spctl 拥有 com.apple.private.iokit.nvram-csr 权限，因为它能够添加需要在 NVRAM 中以 kext-allowed-teams 键保存的新预先批准的内核扩展。
在 下载 应用程序或文件时，特定的 macOS 应用程序（如网页浏览器或电子邮件客户端）会将一个扩展文件属性，通常称为 "隔离标志"，附加到下载的文件上。此属性作为安全措施，标记文件 来自不受信任的来源（互联网），并可能带来风险。然而，并非所有应用程序都会附加此属性，例如，常见的 BitTorrent 客户端软件通常会绕过此过程。
隔离标志的存在在用户尝试执行文件时向 macOS 的 Gatekeeper 安全功能发出信号。
在 隔离标志不存在 的情况下（例如通过某些 BitTorrent 客户端下载的文件），Gatekeeper 的 检查可能不会执行。因此，用户在打开来自不太安全或未知来源的文件时应谨慎。
检查 代码签名的 有效性 是一个 资源密集型 过程，包括生成代码及其所有捆绑资源的加密 哈希。此外，检查证书有效性还涉及对 Apple 服务器进行 在线检查，以查看其在发放后是否被撤销。因此，完整的代码签名和公证检查在每次启动应用程序时都是 不切实际的。
因此，这些检查 仅在执行具有隔离属性的应用程序时运行。
此属性必须由 创建/下载 文件的应用程序 设置。
然而，被沙盒化的文件将对它们创建的每个文件设置此属性。非沙盒应用程序可以自行设置，或在 Info.plist 中指定 LSFileQuarantineEnabled 键，这将使系统在创建的文件上设置 com.apple.quarantine 扩展属性，
此外，所有调用 qtn_proc_apply_to_self 的进程创建的文件都将被隔离。或者 API qtn_file_apply_to_path 将隔离属性添加到指定的文件路径。
可以使用以下命令 检查其状态并启用/禁用（需要 root 权限）：
您还可以使用以下命令查找文件是否具有隔离扩展属性：
检查扩展 属性的值，并找出写入隔离属性的应用程序：
实际上，一个进程“可以为它创建的文件设置隔离标志”（我已经尝试在创建的文件中应用 USER_APPROVED 标志，但它不会应用）：
```c #include #include
enum qtn_flags { QTN_FLAG_DOWNLOAD = 0x0001, QTN_FLAG_SANDBOX = 0x0002, QTN_FLAG_HARD = 0x0004, QTN_FLAG_USER_APPROVED = 0x0040, };
#define qtn_proc_alloc _qtn_proc_alloc #define qtn_proc_apply_to_self _qtn_proc_apply_to_self #define qtn_proc_free _qtn_proc_free #define qtn_proc_init _qtn_proc_init #define qtn_proc_init_with_self _qtn_proc_init_with_self #define qtn_proc_set_flags _qtn_proc_set_flags #define qtn_file_alloc _qtn_file_alloc #define qtn_file_init_with_path _qtn_file_init_with_path #define qtn_file_free _qtn_file_free #define qtn_file_apply_to_path _qtn_file_apply_to_path #define qtn_file_set_flags _qtn_file_set_flags #define qtn_file_get_flags _qtn_file_get_flags #define qtn_proc_set_identifier _qtn_proc_set_identifier
typedef struct _qtn_proc *qtn_proc_t; typedef struct _qtn_file *qtn_file_t;
int qtn_proc_apply_to_self(qtn_proc_t); void qtn_proc_init(qtn_proc_t); int qtn_proc_init_with_self(qtn_proc_t); int qtn_proc_set_flags(qtn_proc_t, uint32_t flags); qtn_proc_t qtn_proc_alloc(); void qtn_proc_free(qtn_proc_t); qtn_file_t qtn_file_alloc(void); void qtn_file_free(qtn_file_t qf); int qtn_file_set_flags(qtn_file_t qf, uint32_t flags); uint32_t qtn_file_get_flags(qtn_file_t qf); int qtn_file_apply_to_path(qtn_file_t qf, const char *path); int qtn_file_init_with_path(qtn_file_t qf, const char path); int qtn_proc_set_identifier(qtn_proc_t qp, const char bundleid);
int main() {
qtn_proc_t qp = qtn_proc_alloc(); qtn_proc_set_identifier(qp, "xyz.hacktricks.qa"); qtn_proc_set_flags(qp, QTN_FLAG_DOWNLOAD | QTN_FLAG_USER_APPROVED); qtn_proc_apply_to_self(qp); qtn_proc_free(qp);
FILE *fp; fp = fopen("thisisquarantined.txt", "w+"); fprintf(fp, "Hello Quarantine\n"); fclose(fp);
return 0;
}
并找到所有被隔离的文件：
隔离信息也存储在由LaunchServices管理的中央数据库中，位于**~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2**，这允许GUI获取有关文件来源的数据。此外，这可以被可能希望隐藏其来源的应用程序覆盖。此外，这可以通过LaunchServices API完成。
libquarantine.dylb
该库导出多个函数，允许操作扩展属性字段。
qtn_file_* API处理文件隔离策略，qtn_proc_* API应用于进程（由进程创建的文件）。未导出的__qtn_syscall_quarantine*函数是应用策略的函数，它调用mac_syscall，第一个参数为"Quarantine"，将请求发送到Quarantine.kext。
Quarantine.kext
内核扩展仅通过系统上的内核缓存可用；然而，您_可以_从https://developer.apple.com/下载内核调试工具包，其中将包含该扩展的符号化版本。
该Kext将通过MACF钩住多个调用，以捕获所有文件生命周期事件：创建、打开、重命名、硬链接...甚至setxattr以防止其设置com.apple.quarantine扩展属性。
它还使用了一些MIB：
security.mac.qtn.sandbox_enforce：在沙箱中强制执行隔离
security.mac.qtn.user_approved_exec：隔离的进程只能执行已批准的文件
XProtect是macOS内置的反恶意软件功能。XProtect在首次启动或修改应用程序时检查其与已知恶意软件和不安全文件类型的数据库。当您通过某些应用程序（如Safari、Mail或Messages）下载文件时，XProtect会自动扫描该文件。如果它与数据库中的任何已知恶意软件匹配，XProtect将阻止该文件运行并提醒您存在威胁。
XProtect数据库由Apple定期更新新的恶意软件定义，这些更新会自动下载并安装在您的Mac上。这确保了XProtect始终与最新已知威胁保持最新。
然而，值得注意的是，XProtect并不是一个功能齐全的杀毒解决方案。它仅检查特定已知威胁列表，并不像大多数杀毒软件那样执行按需扫描。
您可以通过运行以下命令获取有关最新XProtect更新的信息：
XProtect 位于 SIP 保护位置 /Library/Apple/System/Library/CoreServices/XProtect.bundle，在该包内可以找到 XProtect 使用的信息：
XProtect.bundle/Contents/Resources/LegacyEntitlementAllowlist.plist：允许具有这些 cdhash 的代码使用遗留权限。
XProtect.bundle/Contents/Resources/XProtect.meta.plist：不允许通过 BundleID 和 TeamID 加载的插件和扩展的列表，或指示最低版本。
XProtect.bundle/Contents/Resources/XProtect.yara：检测恶意软件的 Yara 规则。
XProtect.bundle/Contents/Resources/gk.db：包含被阻止应用程序和 TeamIDs 哈希的 SQLite3 数据库。
请注意，/Library/Apple/System/Library/CoreServices/XProtect.app 中还有另一个与 XProtect 相关的应用程序，但它与 Gatekeeper 过程无关。
请注意，Gatekeeper 并不是每次 执行应用程序时都会执行，只有 AppleMobileFileIntegrity (AMFI) 会在执行已经由 Gatekeeper 执行和验证的应用程序时 验证可执行代码签名。
因此，之前可以执行一个应用程序以缓存 Gatekeeper，然后 修改应用程序的非可执行文件（如 Electron asar 或 NIB 文件），如果没有其他保护措施，应用程序将 执行 带有 恶意 附加内容的版本。
然而，现在这已不再可能，因为 macOS 防止修改 应用程序包内的文件。因此，如果您尝试 Dirty NIB 攻击，您会发现不再可能利用它，因为在执行应用程序以缓存 Gatekeeper 后，您将无法修改该包。如果您例如将 Contents 目录的名称更改为 NotCon（如漏洞中所示），然后执行应用程序的主二进制文件以缓存 Gatekeeper，将会触发错误并且无法执行。
任何绕过 Gatekeeper 的方法（设法让用户下载某些内容并在 Gatekeeper 应该禁止时执行它）都被视为 macOS 中的漏洞。这些是一些分配给过去允许绕过 Gatekeeper 的技术的 CVE：
观察到如果使用 Archive Utility 进行提取，路径超过 886 个字符 的文件不会接收 com.apple.quarantine 扩展属性。这种情况无意中允许这些文件 绕过 Gatekeeper 的 安全检查。
查看 原始报告 以获取更多信息。
当使用 Automator 创建应用程序时，关于其执行所需的信息位于 application.app/Contents/document.wflow 中，而不在可执行文件中。可执行文件只是一个名为 Automator Application Stub 的通用 Automator 二进制文件。
因此，您可以使 application.app/Contents/MacOS/Automator\ Application\ Stub 通过符号链接指向系统内的另一个 Automator Application Stub，它将执行 document.wflow 中的内容（您的脚本） 而不会触发 Gatekeeper，因为实际的可执行文件没有隔离 xattr。
示例预期位置：/System/Library/CoreServices/Automator\ Application\ Stub.app/Contents/MacOS/Automator\ Application\ Stub
查看 原始报告 以获取更多信息。
在此绕过中，创建了一个 zip 文件，应用程序从 application.app/Contents 开始压缩，而不是从 application.app。因此，隔离属性 应用于所有 来自 application.app/Contents 的文件，但 不适用于 application.app，这是 Gatekeeper 检查的内容，因此 Gatekeeper 被绕过，因为当触发 application.app 时 没有隔离属性。
检查原始报告以获取更多信息。
即使组件不同，此漏洞的利用与之前的非常相似。在这种情况下，我们将从**application.app/Contents生成一个Apple归档，因此application.app在通过Archive Utility解压缩时不会获得隔离属性**。
检查原始报告以获取更多信息。
ACL writeextattr 可用于防止任何人向文件中写入属性：
此外，AppleDouble 文件格式复制了一个文件及其 ACE。
在 源代码 中可以看到，存储在名为 com.apple.acl.text 的 xattr 中的 ACL 文本表示将被设置为解压缩文件中的 ACL。因此，如果您将一个应用程序压缩成一个带有 ACL 的 AppleDouble 文件格式的 zip 文件，该 ACL 阻止其他 xattrs 被写入... 那么隔离 xattr 并没有被设置到该应用程序中：
查看原始报告以获取更多信息。
请注意，这也可以通过AppleArchives进行利用：
发现Google Chrome没有为下载的文件设置隔离属性，这是由于一些macOS内部问题造成的。
AppleDouble文件格式将文件的属性存储在一个以._开头的单独文件中，这有助于在macOS机器之间复制文件属性。然而，注意到在解压AppleDouble文件后，以._开头的文件没有被赋予隔离属性。
能够创建一个不会被设置为隔离属性的文件，可以绕过 Gatekeeper。 这个技巧是使用 AppleDouble 命名约定创建一个 DMG 文件应用程序（以 ._ 开头），并创建一个作为此隐藏文件的符号链接的可见文件，而没有隔离属性。
当dmg 文件被执行时，由于它没有隔离属性，它将绕过 Gatekeeper。
创建一个包含应用程序的目录。
将 uchg 添加到应用程序中。
将应用程序压缩为 tar.gz 文件。
将 tar.gz 文件发送给受害者。
受害者打开 tar.gz 文件并运行应用程序。
Gatekeeper 不会检查该应用程序。
在一个 ".app" 包中，如果没有添加 quarantine xattr，当执行时 Gatekeeper 不会被触发。
学习与实践 AWS 黑客技术：HackTricks 培训 AWS 红队专家 (ARTE) 学习与实践 GCP 黑客技术：HackTricks 培训 GCP 红队专家 (GRTE)
