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完全磁盤訪問？為什么密碼驗證降級為簡單的同意提示，而實際上是相同的權限？

參考及來源：https://labs.sentinelone.com/bypassing-macos-tcc-user-privacy-protections-by-accident-and-design/