在macOS上存儲密鑰是一個巨大的挑戰(zhàn)，可以通過多種不安全的方式來完成。我在漏洞賞金評估期間測試了許多Mac應(yīng)用程序，并觀察到開發(fā)人員傾向于將密鑰放在偏好甚至隱藏的平面文件中。這種方法的問題在于，以標(biāo)準(zhǔn)權(quán)限運行的所有非沙盒應(yīng)用程序都可以訪問密鑰數(shù)據(jù)。平面文件(Flat-File)，F(xiàn)lat File是一種包含沒有相對關(guān)系結(jié)構(gòu)的記錄的文件。這個類型通常用來描述文字處理、其他結(jié)構(gòu)字符或標(biāo)記被移除了的文本。

在使用上，有一些模糊點，如像換行標(biāo)記是否可以包含于“Flat File(flat file)”中。在任何事件中，許多用戶把保存成“純文本(text only)”類型的Microsoft Word文檔叫做“Flat File(flat file)”。最終文件包含記錄(一定長度的文本的行數(shù))但沒有信息，例如，用多長的行來定義標(biāo)題或者一個程序用多大的長度來用一個內(nèi)容表對該文檔進(jìn)行格式化。

例如，macOS上的Signal在〜/ Library / Application Support / Signal / config.json中存儲了用于加密所有消息數(shù)據(jù)庫的密鑰。

macOS鑰匙串

根據(jù)蘋果的說法，鑰匙串是存儲例如密碼和加密密鑰這樣的小秘鑰的最好地方，鑰匙串是一種非常強(qiáng)大的機(jī)制，允許開發(fā)人員定義訪問控制列表(ACL)來限制對條目的訪問。應(yīng)用程序可以通過密鑰組權(quán)限進(jìn)行簽名，以便訪問其他應(yīng)用程序之間共享的秘鑰。以下Objective-C代碼將在鑰匙串中保存密鑰值：

并且在執(zhí)行后，你應(yīng)該看到條目已成功被添加：

第一種竊取技術(shù)

第一種技術(shù)是驗證應(yīng)用程序是否已使用“Hardened Runtime”或“Library Validation”標(biāo)志進(jìn)行了簽名，鑰匙串不能檢測到代碼注入。因此，只需使用以下命令：

如果標(biāo)記為0x0，并且沒有__RESTRICT Mach-O段(這個段非常罕見)，則只需將惡意的dylib注入到應(yīng)用程序的主要可執(zhí)行文件中。創(chuàng)建具有以下內(nèi)容的exploit.m文件：

編譯：

并注入：

第二種竊取技術(shù)

如果可執(zhí)行文件已使用Hardened Runtime簽名怎么辦?這個繞過技術(shù)類似于我在XPC開發(fā)系列中向你展示的內(nèi)容。抓取已分析的二進(jìn)制文件的舊版本，該版本在沒有強(qiáng)化運行時的情況下簽名，并將dylib注入其中。鑰匙串不會驗證二進(jìn)制文件的版本，而是會給你展示秘鑰。

針對開發(fā)人員的建議修復(fù)程序，創(chuàng)建“鑰匙串訪問組”并將秘鑰移到那里。由于二進(jìn)制文件的舊版本無法使用該鑰匙串組權(quán)限進(jìn)行簽名，因此無法獲得該秘鑰，詳情請點此。

第三種竊取技術(shù)

切記如果設(shè)置了“Hardened Runtime”，則com.apple.security.cs.disable-library-validation將允許你注入惡意動態(tài)庫。

第四種竊取技術(shù)

正如Jeff Johnson在他的文章中所證明的那樣，TCC只是從表面上檢查應(yīng)用程序的代碼簽名。鑰匙串中也存在相同的問題，即使整個捆綁包的簽名無效，鑰匙串也只會驗證主要的可執(zhí)行文件是否未被篡改。讓我們以設(shè)備上安裝的Electron應(yīng)用程序(Microsoft Teams，Signal，Visual Studio Code，Slack，Discord等)之一為例，事實證明Electron應(yīng)用程序無法安全地存儲你的秘鑰。Electron是一個創(chuàng)建原生應(yīng)用程序的框架，基于Node.js和Chromium實現(xiàn)了通過JavaScript, HTML 和 CSS 等 Web 技術(shù)構(gòu)建跨平臺應(yīng)用程序的能力。

其中，Electron還封裝了一些功能，包括自動更新、原生的菜單和通知、崩潰報告、調(diào)試和性能分析等。

即使你使用Hardened Runtime簽署了Electron，惡意應(yīng)用程序也可能會更改包含實際代碼的JavaScript文件。讓我們看一下Github Desktop.app，它將用戶的會話秘鑰存儲在鑰匙串中：

并已有效簽名：

接下來，更改一個JS文件并驗證簽名：

可以看到簽名被破壞了，但是Github會正常啟動并加載保存在鑰匙串中的密鑰：

為了防止修改，Electron實現(xiàn)了一種稱為asar-integrity的機(jī)制。它計算一個SHA512哈希值并將其存儲在Info.plist文件中，問題在于它不會停止注射。如果主要的可執(zhí)行文件尚未使用Hardened Runtime或Kill標(biāo)志簽名，并且不包含受限制的權(quán)限，則只需修改asar文件，計算新的校驗和并更新Info.plist文件即可。如果設(shè)置了這些標(biāo)志或權(quán)限，則始終可以使用ELECTRON_RUN_AS_NODE變量，并再次在主要的可執(zhí)行上下文中執(zhí)行代碼。因此，它可以竊取鑰匙串條目。

總結(jié)

鑰匙串中的安全密鑰存儲確實很難實現(xiàn)，因為對請求的可執(zhí)行文件的代碼簽名檢查只是一些表面的功夫，因此有多種方法可以繞過訪問控制機(jī)制。

最大的問題是在Electron應(yīng)用程序中，這些應(yīng)用程序無法將密鑰安全地存儲在鑰匙串中。切記，任何將實際代碼存儲在主要的可執(zhí)行文件之外的框架都可能被誘騙加載惡意代碼。

本文翻譯自：https://wojciechregula.blog/post/stealing-macos-apps-keychain-entries/