macOS 系统的企业安全指南（中）

通过安全测试防止虚假的安全感

虽然我们讨论的是代码签名和证书检查（如 Notarization 和 OCSP），但在评估你的 Mac 免受现实世界 macOS 恶意软件的安全性时，还需要测试安全时效性。无论是第三方还是由 Apple 作为 macOS 平台的一部分提供。根据你的测试内容，你可能会得到误导性的结果。

正如我们上面提到的，Apple 会定期撤销恶意软件的开发人员的代码签名证书，并且通过Notarization机制，删除特定代码样本。

这意味着，如果你打算用一个样本测试一个已知的特定恶意软件家族，该样本的代码签名或公证书已被苹果撤销，你当然会看到该样本在你的测试中被阻止。然而，重要的是，你不能从测试中得出结论，你将阻止相同的恶意软件家族的其他样本。

例如，这个Silver Sparrow恶意软件的样本可以从一个受欢迎的macOS安全研究人员的博客上下载，如果你试图运行它，它会被操作系统拦截：

这意味着如果你用一个样本来测试一个特定的已知恶意软件家族的被苹果撤销代码签名或公证书，你当然会看到该样本。然而，重要的是，你不能从该测试中得出你将阻止同一恶意软件家族的其他样本结论。例如，这个 Silver Sparrow 恶意软件样本可以从一个macOS 安全研究人员的博客下载，如果你尝试运行它，它将被操作系统阻止。

但是，将通过这些检查删除签名或使用不同的签名和相同的样本重新签名恶意软件。

Apple 提供了一种称为 XProtect 的内置技术来扫描已知的恶意软件家族可执行的文件，让我们看看它的效果如何。

XProtect 和 MRT

Apple 的静态签名检查应用程序 XProtect 和恶意软件清除工具 MRT虽然可以捕获多数已知恶意软件，但也存在多个问题，比如ITW 绕过、检测漏洞、静态签名规则和管理团队缺乏可见性等固有缺陷。

macOS内置的恶意软件检测系统的核心是一个名为YARA的静态规则的内部列表，XProtect包已经移动了位置，并不时地改变其格式，但可以很容易地从终端找到它：

% mdfind -name XProtect.bundle | grep -i coreservices

要从任何目录中检查你的设备当前安装了哪个版本的 XProtect（注意此命令中的反引号）：

% plutil -p `mdfind -name XProtect.bundle | grep -i coreservices | head -n 1`/Contents/ Info.plist | grep -i shortversion从 XProtect 的 Resources 文件夹中，你可以准确地看到 XProtect 的 YARA 文件有多少通过在行的开头搜索“规则”来包含规则，在撰写本文时为 158：

% grep ^rule XProtect.yara | wc -l

在过去 18 个月左右的时间里，Apple 从使用描述性规则名称切换到使用以 _MACOS_ 为前缀的简短十六进制标识符（而不是旧的 _OSX_）。我们可以看到，自从做出转换后，Apple 已经添加了大约 68 条规则。

这些规则具有无用的名称和无意义的描述，但对应的XProtect 恶意软件家族和签名名称列表可以在 Github 上找到。

至关重要的是，从安全团队或 IT 管理员的角度来看，XProtect 缺乏的是实际尝试执行文件的用户，但是，那些希望执行此操作的人可以先安装开源 YARA 工具。

安装 YARA 后，运行测试提供 XProtect.yara 规则文件的路径是一件简单的事情，然后是要测试的文件或文件夹内容的路径。下面是我们发现 XProtect 识别的用户下载文件夹中的两个恶意软件，确认我们的测试有效。

以下是从常见 macOS 恶意软件的 VT 中提取的 20 个哈希值：

我们可以将这些哈希放到 VirusTotal 中，然后查看所有 20 个都是已知的：

让我们使用刚刚安装的 YARA 工具来查看 XProtect 知道其中的多少。

XProtect在这方面做得稍好一些，捕获了12个中的8个。

也许这些是新的恶意软件，XProtect还没有碰上，让我们进入 VirusTotal转储这四个哈希：

所以，如果你依赖 XProtect 作为主要防御已知恶意软件的手段，那被攻击只是时间的问题。事实证明，你根本不能依赖 Apple 的内置工具来检测当今企业面临的所有威胁。

最近报道的案例是CVE-2021-30657（系统首选项）- 恶意应用程序可能会绕过 Gatekeeper 检查。

Shlayer 和 ZShlayer 已成为最过去一年macOS平台上最常见的威胁。与 XProtect 一样，MRT 在最新版本的 macOS 中更改了位置，但是目前与XProtect包位于同一个CoreServices文件夹中。

与 XProtect 不同，你实际上可以调用 MRT.app 以通过命令行运行，不过你不会得到太多反馈信息：

使用 -a（用户代理）开关运行它并使用 -d（-daemon）开关运行 sudo 后，不幸的是，我们已知的恶意软件文件仍然存在：

但这也许不是一个公平的测试。 Malware Removal Tool 主要在某些位置（在某些文件路径）搜索已知的恶意软件并静默删除它匹配的任何内容（MRT 似乎还有其他功能，例如扫描所有应用程序以查看它们是否已被篡改，但我们赢了不要在这里深入研究）。

我们可以通过将恶意软件文件放置在我们知道 MRT 被编程为查看并确保将其删除的位置来测试 MRT.app 是否在其主要功能中工作。一旦我们确认 MRT.app 按预期工作，我们就可以将其他恶意软件文件放在已知位置，看看 MRT 是否也删除了这些文件。这应该为我们提供了一个相当可靠的测试，以确定 MRT 是否知道已知位置的任何给定恶意软件样本。

如果你想跟随这个实验，你将需要一个测试环境。最好是运行最新版本 macOS 并应用所有更新的隔离虚拟机。首先，让我们从 MRT.app 中提取纯字符串，以了解它可能要查找的内容。

我们将搜索“LaunchAgents”，因为它们是 macOS 恶意软件持久性尝试的常见目的地。

% strings -a MRT | grep ‘LaunchAgents/’

您可以从输出中选择，但我们将使用“com.apple.Safari.pac.plist”并在用户 LaunchAgents 文件夹中创建一个具有该名称的零字节文件。

% touch ~/Library/LaunchAgents/com.apple.Safari.pac.plist

然后我们切换到 MRT 包的 MacOS 文件夹并使用 -a 开关在命令行上运行 MRT：

如上面的输出所示，在发出一些漏洞消息后，MRT.app 删除了该文件。它也是查找并尝试删除明显与 OSX.Dok.A 感染相关的另一个文件。到目前为止，我们已经确认 MRT 应用程序可以工作，并且我们知道如何调用它。

Apple 已经不遗余力地混淆了 MRT 使用的许多字符串（我们早期的字符串实用程序的输出大部分是来自早期 MRT 版本的旧内容）。 在早期版本的 MRT 中最初使用纯字符串后，Apple 短暂地改为使用堆栈字符串，但在我们之前报道了这一点之后，Apple 再次更改了他们的字符串编码例程。 现在将这些从 MRT 中提取出来是一种高级逆向工程技术，非专业人士不容易复制。 但是，我们可以重复上面的方法，看看 MRT 是否很容易知道它们。

重申一下我们上面所说的，你需要在一个隔离的VM环境中进行操作，因为我们将处理实时的恶意软件样本。

我们将为此测试选择 Adload 的一个变体，因为这是一个恶意软件家族，在 macOS 上流行了好几年。 在本示例中，我们将测试 SearchLibrary，它至少自 2021 年 3 月中旬以来就已为人所知。

为了测试这一点，我们将在上图所示的路径上创建一个文件夹，

% mkdir -p /Library/Application\ Support/com.SearchLibraryDaemon

我们现在获取恶意软件可执行文件的样本，并将其放入我们刚刚创建的文件夹中，命名 SearchLibrary 并重复我们上面所做的测试，同时使用 -a 开关和sudo 和 -d 开关。 MRT 是否删除了恶意软件？

截至撰写本文时，该样本在 VirusTotal 上首次出现三个月后，MRT.app不会删除该样本，我们可以得出结论，MRT.app 还不知道该恶意软件。

这样我们就可以得出结论，与 XProtect 一样，毫无疑问 MRT.app 也不是最强大的安全解决方案。

TCC 

TCC 旨在保护用户数据不被访问，但已知存在多种被部分和完全绕过的办法，其中至少有一种已知在野外被积极利用。系统设计的弱点也意味着 TCC 很容易被管理员无意忽略。

近年来，保护设备上的敏感用户数据变得越来越重要，特别是现在我们的手机、平板电脑和电脑被用于创建、存储和传输关于我们最敏感的数据。

随着 macOS 的每次迭代，TCC所涵盖的范围已经增加到用户几乎无法访问自己的数据或创建数据的范围，比如像摄像头和麦克风这样的设备，它们无需跳过各种给予“同意”的圈套

或“控制”相关应用程序，通过这些应用程序进行此类访问。

让我们看看TCC失败的几种方式，通俗地说，我们谈论的隐私保护主要由用户在“安全与隐私”选项的“系统偏好设置”的“隐私”选项卡中管理。

由MDM解决方案控制的Mac设备还可以通过配置文件设置各种隐私首选项。实际上，这些首选项在上面的“隐私”选项中对用户是不可见的。

但是，可以通过TCC数据库枚举它们。

macOS 11 (Big Sur) 及更高版本：

sudo sqlite3 /Library/Application Support/com.apple.TCC/TCC.db “SELECT client,auth_value FROM access WHERE service==’kTCCServiceSystemPolicyAllFiles’” | grep ‘2’$

macOS 10.15 (Catalina) 及更早版本：

sudo sqlite3 /Library/Application Support/com.apple.TCC/TCC.db “SELECT client,allowed FROM access WHERE service == ‘kTCCServiceSystemPolicyAllFiles’” | grep ‘1’$

该命令行还向用户和管理员提供/usr/bin/tccutil实用程序，尽管它声称提供“管理隐私数据库”的能力有点夸张，因为唯一记录的命令是重置。如果你需要全面清除系统或用户的 TCC 权限，该工具很有用，但除此之外别无他法。

在底层，所有这些权限都由TCC.framework管理

/System/Library/PrivateFrameworks/TCC.framework/Versions/A/Resources/tccd.

以一种相当狭隘的方式看待用户在实践中如何使用他们的 Mac，当用户和应用程序在这种狭隘意义上的行为符合预期时，Apple 使用此框架设计的隐私控制按预期工作。然而，正如我们现在将看到的，当其中一方或双方都偏离原定计划时，就会出现问题。