macOS Gatekeeper / Quarantine / XProtect
Gatekeeper
Gatekeeper是为Mac操作系统开发的安全功能，旨在确保用户在其系统上仅运行可信软件。它通过验证用户从App Store之外的来源下载并尝试打开的软件（如应用程序、插件或安装程序包）来发挥作用。
Gatekeeper的关键机制在于其验证过程。它检查下载的软件是否由认可的开发人员签名，确保软件的真实性。此外，它还确定软件是否被苹果公证，以确认其不包含已知的恶意内容，并且在公证后未被篡改。
此外，Gatekeeper通过提示用户批准首次打开下载的软件来加强用户控制和安全性。这种保护措施有助于防止用户无意中运行可能被误认为是无害数据文件的潜在有害可执行代码。
应用程序签名
应用程序签名，也称为代码签名，是Apple安全基础设施的关键组成部分。它用于验证软件作者（开发人员）的身份，并确保代码自上次签名以来未被篡改。
工作原理如下：
签署应用程序：当开发人员准备分发他们的应用程序时，他们会使用私钥对应用程序进行签名。此私钥与开发人员在加入Apple开发人员计划时获得的证书相关联。签名过程涉及创建应用程序所有部分的加密哈希，并使用开发人员的私钥对此哈希进行加密。
**分发应用程序：**签名的应用程序随后与开发人员的证书一起分发给用户，该证书包含相应的公钥。
验证应用程序：当用户下载并尝试运行应用程序时，他们的Mac操作系统使用开发人员证书中的公钥来解密哈希。然后，它根据应用程序的当前状态重新计算哈希，并将其与解密的哈希进行比较。如果它们匹配，这意味着应用程序自开发人员签名以来未被修改，系统允许应用程序运行。
应用程序签名是Apple Gatekeeper技术的重要组成部分。当用户尝试打开从互联网下载的应用程序时，Gatekeeper会验证应用程序签名。如果它使用由苹果颁发给已知开发人员的证书签名，并且代码未被篡改，Gatekeeper允许应用程序运行。否则，它会阻止应用程序并警告用户。
从macOS Catalina开始，Gatekeeper还会检查应用程序是否已被苹果公证，增加了额外的安全层。公证过程会检查应用程序是否存在已知的安全问题和恶意代码，如果这些检查通过，苹果会向应用程序添加Gatekeeper可以验证的凭证。
检查签名
在检查一些恶意软件样本时，您应始终检查二进制文件的签名，因为签署它的开发人员可能已与恶意软件有关。
验证
苹果的验证流程作为一项额外的保障措施，旨在保护用户免受潜在有害软件的侵害。这涉及开发人员通过苹果的验证服务提交其应用程序进行审查，这与应用审核不应混淆。这项服务是一个自动化系统，用于审查提交的软件是否存在恶意内容以及代码签名是否存在任何潜在问题。
如果软件通过此检查而没有引起任何关注，验证服务将生成一个验证票证。然后开发人员需要将此票证附加到其软件上，这个过程称为“装订”。此外，验证票证也会在线发布，Gatekeeper，苹果的安全技术，可以访问它。
在用户首次安装或执行软件时，验证票证的存在 - 无论是装订到可执行文件还是在线找到 - 通知 Gatekeeper 软件已由苹果进行验证。因此，Gatekeeper 在初始启动对话框中显示一个描述性消息，指示该软件已经通过苹果的恶意内容检查。这个过程增强了用户对其系统上安装或运行的软件安全性的信心。
枚举 Gatekeeper
Gatekeeper 既是几个安全组件，用于阻止不受信任的应用程序执行，也是其中的一个组件。
可以使用以下命令查看 Gatekeeper 的状态：
请注意，GateKeeper 签名检查仅针对具有隔离属性的文件进行，而不是针对每个文件进行。
GateKeeper 将检查二进制文件是否可以执行，根据偏好设置和签名：
保存此配置的数据库位于**/var/db/SystemPolicy**。您可以以 root 身份检查此数据库：
请注意第一个规则以“App Store”结尾，第二个规则以“Developer ID”结尾，并且在之前的图像中它被设置为允许从App Store和已识别开发者执行应用程序。 如果您将该设置修改为App Store，则“已经过公证的开发者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**
或者你可以列出前面提到的信息：
spctl 的选项 --master-disable 和 --global-disable 将完全禁用这些签名检查：
完全启用后，将出现一个新选项：
可以使用以下方法检查 GateKeeper 是否允许某个应用程序：
可以通过以下方式向 GateKeeper 添加新规则，允许执行特定应用程序：
检疫文件
在下载应用程序或文件时，特定的 macOS 应用程序，如网络浏览器或电子邮件客户端，会向下载的文件附加一个称为“检疫标志”的扩展文件属性。该属性作为一项安全措施，将文件标记为来自不受信任的来源（互联网），并可能携带风险。然而，并非所有应用程序都会附加此属性，例如，常见的 BitTorrent 客户端软件通常会绕过此过程。
当用户尝试执行文件时，检疫标志的存在会触发 macOS 的 Gatekeeper 安全功能。
在检疫标志不存在的情况下（例如通过某些 BitTorrent 客户端下载的文件），Gatekeeper 的检查可能不会执行。因此，用户在打开从较不安全或未知来源下载的文件时应谨慎。
此属性必须由创建/下载文件的应用程序设置。
但是，经过沙盒化的文件将为它们创建的每个文件设置此属性。非沙盒化的应用程序可以自行设置，或在 Info.plist 中指定 LSFileQuarantineEnabled 键，系统将在创建的文件上设置 com.apple.quarantine 扩展属性。
可以通过以下方式检查其状态并启用/禁用（需要 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**。
Quarantine.kext
内核扩展仅通过系统上的内核缓存可用；但是，您可以从https://developer.apple.com/下载Kernel Debug Kit，其中包含扩展的符号化版本。
XProtect
XProtect是macOS中内置的反恶意软件功能。XProtect会针对已知恶意软件和不安全文件类型的数据库检查任何应用程序在首次启动或修改时。当您通过某些应用程序（如Safari、Mail或Messages）下载文件时，XProtect会自动扫描该文件。如果文件与其数据库中的任何已知恶意软件匹配，XProtect将阻止文件运行并向您发出威胁警报。
XProtect数据库由Apple定期更新新的恶意软件定义，并这些更新会自动下载并安装到您的Mac上。这确保了XProtect始终与最新已知威胁保持同步。
然而，值得注意的是XProtect并非完整的防病毒解决方案。它仅检查特定已知威胁列表，不像大多数防病毒软件那样执行访问扫描。
您可以获取有关最新XProtect更新的信息运行：
XProtect位于SIP受保护位置**/Library/Apple/System/Library/CoreServices/XProtect.bundle**，在bundle内部，您可以找到XProtect使用的信息：
XProtect.bundle/Contents/Resources/LegacyEntitlementAllowlist.plist：允许具有这些cdhashes的代码使用传统授权。XProtect.bundle/Contents/Resources/XProtect.meta.plist：禁止通过BundleID和TeamID加载的插件和扩展列表，或指示最低版本。XProtect.bundle/Contents/Resources/XProtect.yara：用于检测恶意软件的Yara规则。XProtect.bundle/Contents/Resources/gk.db：带有被阻止的应用程序和TeamIDs哈希的SQLite3数据库。
请注意，还有另一个与XProtect相关的应用程序**/Library/Apple/System/Library/CoreServices/XProtect.app**与Gatekeeper进程无关。
非Gatekeeper
请注意，Gatekeeper不会每次执行应用程序时都执行，只有在您执行已经由Gatekeeper验证的应用程序时，AppleMobileFileIntegrity（AMFI）才会验证可执行代码签名。
因此，以前可以执行应用程序以使用Gatekeeper缓存它，然后修改应用程序的非可执行文件（如Electron asar或NIB文件），如果没有其他保护措施，应用程序将带有恶意添加内容。
然而，现在这是不可能的，因为macOS阻止修改应用程序包内的文件。因此，如果尝试Dirty NIB攻击，您将发现不再可能滥用它，因为在使用Gatekeeper执行应用程序以缓存它后，您将无法修改bundle。例如，如果更改Contents目录的名称为NotCon（如在漏洞利用中指示的那样），然后执行应用程序的主要二进制文件以使用Gatekeeper缓存它，将触发错误并且不会执行。
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，因为实际可执行文件没有quarantine xattr。
预期位置示例：/System/Library/CoreServices/Automator\ Application\ Stub.app/Contents/MacOS/Automator\ Application\ Stub
查看原始报告获取更多信息。
在此绕过中，创建了一个zip文件，从application.app/Contents开始压缩而不是从application.app开始。因此，从application.app/Contents的所有文件都应用了quarantine属性，但没有应用到application.app，Gatekeeper正在检查的是这一点，因此Gatekeeper被绕过，因为当触发application.app时，它没有quarantine属性。
查看原始报告以获取更多信息。
即使组件不同，利用此漏洞的方式与先前的漏洞非常相似。在这种情况下，我们将从**application.app/Contents生成一个苹果存档，这样当通过Archive Utility解压缩时，application.app将不会获得隔离属性**。
查看原始报告以获取更多信息。
ACL writeextattr 可用于防止任何人在文件中写入属性：
此外，AppleDouble 文件格式会复制文件及其ACEs。
在源代码中，可以看到存储在名为**com.apple.acl.text的xattr中的ACL文本表示将被设置为解压后文件的ACL。因此，如果您使用AppleDouble**文件格式将应用程序压缩到zip文件中，并附带一个ACL以阻止其他xattr被写入...则隔离xattr不会被设置到应用程序中：
查看原始报告以获取更多信息。
请注意，这也可以利用AppleArchives：
发现Google Chrome没有设置下载文件的隔离属性，因为存在一些macOS内部问题。
AppleDouble文件格式将文件属性存储在以._开头的单独文件中，这有助于在macOS设备之间复制文件属性。然而，注意到在解压AppleDouble文件后，以._开头的文件没有被赋予隔离属性。
能够创建一个不会设置隔离属性的文件，这样就有可能绕过Gatekeeper。技巧是使用AppleDouble命名约定（以._开头）创建一个DMG文件应用程序，并创建一个可见文件作为对这个没有隔离属性的隐藏文件的符号链接。当执行dmg文件时，由于它没有隔离属性，它将绕过Gatekeeper。
防止隔离 xattr
在“.app”捆绑包中，如果未添加隔离 xattr，则执行时Gatekeeper 将不会被触发。
最后更新于