TCC 旨在保护用户数据免遭未经授权的访问，但其设计上的缺陷意味着保护措施很容易在无意中被覆盖。

Automation在设计上允许全磁盘访问“后门”，同时还降低了授权权限。已知多个部分和全的 TCC 绕过，至少有一个在野外被积极利用。

TCC 不会阻止进程读取和写入“受保护”位置，这是一个可用于隐藏恶意软件的漏洞。

近年来，保护设备上的敏感用户数据变得越来越重要，特别是现在我们的手机、平板电脑和计算机被用来创建、存储和传输关于我们最敏感的数据：从自拍、家庭视频到密码、银行业务详细信息、健康和医疗数据以及几乎所有其他内容。

借助 macOS，苹果在早期保护用户数据方面处于强势地位，早在 2012 年就在 OSX Mountain Lion 中实施了名为“透明、同意和控制”(简称TCC)框架下的控制。此后，随着 macOS 的每次迭代，TCC 的安全保护范围也逐渐扩大。

我们在本文中不过多阐述关注TCC的优点，主要讨论它失败的多种方式。

我们希望通过关注这些缺点，用户和管理员可以更好地了解敏感数据如何以及何时暴露。

什么是 TCC？

苹果最新的平台安全指南不再直接提到TCC，而是提到“保护应用程序访问用户数据”。通俗地说，我们谈论的隐私保护主要由用户在“安全与隐私”窗的“系统首选项”的“隐私”选项卡中管理。

System Preferences.app 为 TCC 提供了前端

由MDM解决方案控制的Mac设备也可以通过Profile设置各种隐私首选项。实际上，用户在上面的Privacy窗中将看不到这些首选项。但是，它们可以通过 TCC 数据库进行枚举。该命令在 Big Sur 和更高版本中略有变化。

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权限，那么该工具是有用的。

来自 tccutil 的 spartan 手册

实际上，所有这些权限都是由TCC.framework在/System/Library/PrivateFrameworks/TCC.framework/Versions/A/Resources/tccd下管理的。

tccd 二进制文件中的字符串显示了一些提供 TCC 保护的服务

从一个相当狭隘的角度来看，当用户(和应用程序)按照这个狭义意义上的意图行事时，苹果用这个框架设计的隐私控制可以按照预期工作。然而，正如我们现在看到的，当其中一个或两个都偏离脚本时，问题就出现了。

全磁盘访问

要了解苹果在 TCC 实现中存在的问题，首先要了解 TCC 权限存在于两个级别：用户级别和系统级别。在用户级别，个人用户可以允许某些旨在仅适用于自己的帐户而不适用于其他帐户的权限。如果Alice允许终端访问她的Desktop或Downloads文件夹，这对Bob来说并没有什么影响。当 Bob 登录时，终端将无法访问 Bob 的桌面或下载文件夹。

至少，它应该是这样工作的，但是如果 Alice 是管理员用户并授予终端全磁盘访问权限 (FDA)，那么 Alice 就可以很高兴地导航到 Bob 的桌面和下载文件夹（以及其他所有人的），而不管 Bob 的 TCC 设置如何（或其他用户）设置。请注意，如果 Bob 也是管理员用户，则他不会受到任何特殊保护。全磁盘访问意味着，它可以由一个具有管理员权限的用户设置，并授予对系统范围内所有用户数据的访问权限。

虽然这对系统管理员来说似乎是个好消息，但其中的含义可能并不明显，并且这些含义会影响管理员自己的数据安全。

当Alice将FDA权限授予她自己的终端时，所有用户现在也可以通过终端获得FDA权限。结果是 Alice 不仅授予自己访问他人数据的权限，还授予其他人访问她的数据的权限。

令人惊讶的是，Alice无意中的权限也扩展到了非特权用户。正如在CVE-2020-9771中所报告的，允许终端具有全磁盘访问将使所有数据可读，而无需任何进一步的安全挑战：即使非管理员用户也可以挂载和读取整个磁盘。这篇博文详细介绍了它的工作原理，但简而言之，任何用户都可以创建和挂载系统的本地快照，并读取所有其他用户的数据。

即使是标准用户也可以读取管理员的私人数据

解决这个问题的“窍门”在于两个命令行实用程序，这两个实用程序都可供所有用户使用：/usr/bin/tmutil 和 /sbin/mount。第一个允许我们创建整个系统的本地快照，第二个允许我们将该快照挂载为 apfs 只读文件系统。这样，我们可以浏览在挂载的快照上捕获的所有用户数据。

重要的是要了解这不是错误并且不会修复（至少，“按预期工作”似乎是 Apple 在撰写本文时的立场）。上面提到的 CVE 是能够在没有全磁盘访问的情况下利用它的漏洞。 苹果的修复方法是仅在授予全磁盘访问权限时才可能实现。

当你授予自己完全磁盘访问权限时，你授予所有用户（甚至是非特权用户）读取磁盘上所有其他用户数据的能力，包括你自己的数据。

通过Automation后门全盘访问

这种情况不仅仅局限于用户：它也扩展到用户进程。根据设计，任何被授予全磁盘访问权限的应用程序都可以访问所有用户数据。如果该应用程序是恶意软件，或者可以被恶意软件控制，那么恶意软件也一样，但是应用程序控制由TCC的另一个首选项Automation管理。

这里还存在另一个漏洞：Mac 上有一个应用程序始终具有全磁盘访问权限，但从未出现在系统首选项的全磁盘访问窗中：Finder。

任何可以控制Finder的应用程序(在隐私窗格的“Automation”中列出)也有全的磁盘访问，尽管你将看不到Finder和控制应用程序在全磁盘访问窗中列出。

由于这种复杂性，管理员必须意识到，即使他们从未授予 FDA 权限，或者即使他们锁定了全盘访问（可能通过 MDM 解决方案），仅允许应用程序控制“Automation”窗中的 Finder 将绕过那些限制。

Automation Finder 允许控制应用程序完全磁盘访问

在上图中，终端和两个合法的第三方Automation应用程序 Script Debugger 和 FastScripts 都具有全磁盘访问权限，但在全磁盘访问隐私窗中没有显示：

通过Automation为FDA提供后门的应用程序不会显示在FDA 窗中

如上所述，这是因为 Finder 具有不可撤销的 FDA 许可，并且这些应用程序已获得对 Finder 的Automation控制。下面演示了具体的工作过程。

~  osascript < < EOD
set a_user to do shell script "logname"
tell application "Finder"
set desc to path to home folder
set copyFile to duplicate (item "private.txt" of folder "Desktop" of folder a_user of item "Users" of disk of home) to folder desc with replacing
set t to paragraphs of (do shell script "cat " & POSIX path of (copyFile as alias)) as text
end tell
do shell script "rm " & POSIX path of (copyFile as alias)
t
EOD

虽然终端没有被授予全盘访问权限，但如果它过去因任何原因被授予Automation权限，在终端中执行上述脚本将返回“private.txt”文件包含的任何内容。由于“private.txt”位于用户桌面上，该位置表面上受 TCC 保护，如果没有明确授予FDA许可的应用程序，用户可能有理由认为该文件的内容将保持私密。事实显然不是这样。

通过Automation Finder 采用后门方式对 FDA 访问

这里明显的缓解措施是不允许应用程序自动执行 Finder。但是，让我们注意有关该建议的两个要点。

首先，将Finder的Automation授予终端或其他生产力应用程序有许多正当的理由：任何对通过Automation提高生产力感兴趣的轻度熟练用户可能已经这样做了，或者希望这样做。如果用户有这样做的特定目的，则无法阻止终端（或其他程序）使用此访问权限的其他不太合法的使用。

其次，以这种方式后门进入FDA导致授权障碍的降低。按照通常的方式授予FDA需要管理员密码。然而，可以在没有密码的情况下批准Finder的Automation以及 FDA 后门，一个带有简单点击的同意对话框就足够了：

一个简单的“确定”就可以访问控制 Finder，并扩展全磁盘访问

虽然警告文本足够明确(如果用户阅读它)，但它远远不够透明，鉴于Finder的不可撤销的全磁盘访问权，在控制应用中投入的权限远远超出当前用户的同意或控制。

如果它在过去的任何时候被授予过，那么该权限仍然有效，除非在系统首选项的“Automation”窗中或通过前面提到的 tccutil reset命令被撤销。

TCC 绕过的实际情况分析

到目前为止我们所提到的一切都是提前设计好的，当 macOS Mojave 首次公开发布时，SentinelOne是第一个注意到TCC可以通过SSH绕过。

最近的一次TCC绕过是在2020年8月被 XCSSET 恶意软件利用后曝光的。尽管苹果在大约 9 个月后的 2021 年 5 月修补了这个特定漏洞，但它仍然可以在未更新到macOS 11.4或最新安全更新到10.15.7的系统上使用。

在易受攻击的系统上，复制起来非常容易。

1.创建一个简单的木马应用程序，需要TCC权限。在这里，我们将创建一个需要访问当前用户桌面的应用程序，以枚举保存在那里的文件。

% osacompile -e 'do shell script "ls -al /Users/sphil/Desktop >> /tmp/lsout"' -o /tmp/ls.app

2.将这个新的“ls.app”木马复制到已经获得 TCC 访问桌面权限的应用程序包中。

% cp -R /tmp/ls.app /Applications/Some\ Privileged.app/

3.你可以从“系统首选项”的“安全与隐私”面板的“隐私”选项卡的“文件和文件夹”类别中找到当前允许的应用程序列表，恶意软件采取了另一种方式，稍后我们将对此进行解释。

执行木马应用程序：

% open /Applications/Some\ Privileged.app/ls.app

有安全意识的读者无疑会想知道攻击者如何在不了解 TCC 权限的情况下实现第 2 步，除非终端已经拥有全磁盘访问权限，否则你无法从终端枚举 TCC.db 中的特权应用程序列表。

假设目标尚未出于某些其他合法原因授予终端 FDA 权限，则攻击者或恶意软件可以改为枚举 /Applications 文件夹的内容并基于有根据的猜测在其中找到的有攻击价值的东西，例如，Xcode、Camtasia 和 Zoom 都是如果安装了就可能获得特权的应用程序。

同样，可以对已知具有此类权限的应用程序列表进行硬编码，并在目标设备上搜索它们。这正是 XCSSET 恶意软件的工作原理：该恶意软件硬编码了一个应用程序列表，它希望有屏幕捕捉权限，并将自己的应用程序注入其中。

来自 XCSSET 恶意软件的解码字符串显示了它利用 TCC 权限的应用程序列表

不幸的是，针对此特定漏洞的修复并不能有效阻止恶意软件开发者。如果绕过失败，只需模拟 Finder 并要求用户进行控制就很简单了。与Automation请求一样，这仅需要用户点击他们的同意，而不是提供密码。

假冒Finder应用程序使用的XCSSET恶意软件访问保护区域

正如我们上面提到的，默认情况下（真实的）Finder 已经具有全磁盘访问权限，因此用户看到请求对话框要求授予 Finder 访问任何文件夹的权限时，应该立即引起警觉。

但还有一点值得指出，对 Apple 用户隐私控制的一个常见误解是它阻止访问某些位置，例如，桌面、文档、下载、iCloud 文件夹。然而，事实并非如此。

管理员需要注意，TCC 不会防止文件被非特权进程写入 TCC 保护区，同样，它也不能阻止这些进程读取写入的文件。

进程可以写入 TCC 保护区，并读取它写入的文件

为什么这很重要？因为如果你安装了无法访问 TCC 保护区的任何类型的安全或监控软件，则没有什么可以阻止恶意软件将其部分或全部组件隐藏在这些保护区中。 TCC 不会阻止恶意软件使用这些位置，所以不要依赖TCC提供某种内置的受保护的“安全区”。

总结

macOS用户可以通过执行macOS用户(特别是管理员)通常的操作，轻松地、不知不觉地暴露他们认为受 TCC 保护的数据。具有讽刺意味的是，大多数这些“意外违规”都是TCC自身缺乏透明度造成的。例如，为什么 Finder 未列在“全磁盘访问”窗中？为什么还不清楚 Finder 后门的Automation完全磁盘访问？为什么密码验证降级为简单的同意提示，而实际上是相同的权限？

本文转载自：嘶吼

作者：luochicun

原文地址：https://www.4hou.com/posts/vR3r

本文翻译自：https://labs.sentinelone.com/bypassing-macos-tcc-user-privacy-protections-by-accident-and-design/