建站
咨詢
售后
建站咨詢
新聞中心
在macOS上存儲密鑰是一個巨大的挑戰(zhàn)，可以通過多種不安全的方式來完成。我在漏洞賞金評估期間測試了許多Mac應用程序，并觀察到開發(fā)人員傾向于將密鑰放在偏好甚至隱藏的平面文件中。這種方法的問題在于，以標準權限運行的所有非沙盒應用程序都可以訪問密鑰數(shù)據(jù)。平面文件(Flat-File)，F(xiàn)lat File是一種包含沒有相對關系結構的記錄的文件。這個類型通常用來描述文字處理、其他結構字符或標記被移除了的文本。
在使用上，有一些模糊點，如像換行標記是否可以包含于“Flat File(flat file)”中。在任何事件中，許多用戶把保存成“純文本(text only)”類型的Microsoft Word文檔叫做“Flat File(flat file)”。最終文件包含記錄(一定長度的文本的行數(shù))但沒有信息，例如，用多長的行來定義標題或者一個程序用多大的長度來用一個內容表對該文檔進行格式化。
例如，macOS上的Signal在?/ Library / Application Support / Signal / config.json中存儲了用于加密所有消息數(shù)據(jù)庫的密鑰。
macOS鑰匙串
根據(jù)蘋果的說法，鑰匙串是存儲例如密碼和加密密鑰這樣的小秘鑰的最好地方，鑰匙串是一種非常強大的機制，允許開發(fā)人員定義訪問控制列表(ACL)來限制對條目的訪問。應用程序可以通過密鑰組權限進行簽名，以便訪問其他應用程序之間共享的秘鑰。以下Objective-C代碼將在鑰匙串中保存密鑰值：
并且在執(zhí)行后，你應該看到條目已成功被添加：
第一種竊取技術
第一種技術是驗證應用程序是否已使用“Hardened Runtime”或“Library Validation”標志進行了簽名，鑰匙串不能檢測到代碼注入。因此，只需使用以下命令：
如果標記為0x0，并且沒有__RESTRICT Mach-O段(這個段非常罕見)，則只需將惡意的dylib注入到應用程序的主要可執(zhí)行文件中。創(chuàng)建具有以下內容的exploit.m文件：
編譯：
并注入：
第二種竊取技術
如果可執(zhí)行文件已使用Hardened Runtime簽名怎么辦?這個繞過技術類似于我在XPC開發(fā)系列中向你展示的內容。抓取已分析的二進制文件的舊版本，該版本在沒有強化運行時的情況下簽名，并將dylib注入其中。鑰匙串不會驗證二進制文件的版本，而是會給你展示秘鑰。
針對開發(fā)人員的建議修復程序，創(chuàng)建“鑰匙串訪問組”并將秘鑰移到那里。由于二進制文件的舊版本無法使用該鑰匙串組權限進行簽名，因此無法獲得該秘鑰，詳情請點此。
第三種竊取技術
切記如果設置了“Hardened Runtime”，則com.apple.security.cs.disable-library-validation將允許你注入惡意動態(tài)庫。
第四種竊取技術
正如Jeff Johnson在他的文章中所證明的那樣，TCC只是從表面上檢查應用程序的代碼簽名。鑰匙串中也存在相同的問題，即使整個捆綁包的簽名無效，鑰匙串也只會驗證主要的可執(zhí)行文件是否未被篡改。讓我們以設備上安裝的Electron應用程序(Microsoft Teams，Signal，Visual Studio Code，Slack，Discord等)之一為例，事實證明Electron應用程序無法安全地存儲你的秘鑰。Electron是一個創(chuàng)建原生應用程序的框架，基于Node.js和Chromium實現(xiàn)了通過JavaScript, HTML 和 CSS 等 Web 技術構建跨平臺應用程序的能力。
其中，Electron還封裝了一些功能，包括自動更新、原生的菜單和通知、崩潰報告、調試和性能分析等。
即使你使用Hardened Runtime簽署了Electron，惡意應用程序也可能會更改包含實際代碼的JavaScript文件。讓我們看一下Github Desktop.app，它將用戶的會話秘鑰存儲在鑰匙串中：
并已有效簽名：
接下來，更改一個JS文件并驗證簽名：
可以看到簽名被破壞了，但是Github會正常啟動并加載保存在鑰匙串中的密鑰：
為了防止修改，Electron實現(xiàn)了一種稱為asar-integrity的機制。它計算一個SHA512哈希值并將其存儲在Info.plist文件中，問題在于它不會停止注射。如果主要的可執(zhí)行文件尚未使用Hardened Runtime或Kill標志簽名，并且不包含受限制的權限，則只需修改asar文件，計算新的校驗和并更新Info.plist文件即可。如果設置了這些標志或權限，則始終可以使用ELECTRON_RUN_AS_NODE變量，并再次在主要的可執(zhí)行上下文中執(zhí)行代碼。因此，它可以竊取鑰匙串條目。
總結
鑰匙串中的安全密鑰存儲確實很難實現(xiàn)，因為對請求的可執(zhí)行文件的代碼簽名檢查只是一些表面的功夫，因此有多種方法可以繞過訪問控制機制。
最大的問題是在Electron應用程序中，這些應用程序無法將密鑰安全地存儲在鑰匙串中。切記，任何將實際代碼存儲在主要的可執(zhí)行文件之外的框架都可能被誘騙加載惡意代碼。
本文翻譯自：https://wojciechregula.blog/post/stealing-macos-apps-keychain-entries/
新聞標題：利用第三方應用的各類代碼注入技術竊取鑰匙串
轉載注明：http://www.dlmjj.cn/article/dhjhhop.html
