利用第三方應(yīng)用的各類代碼注入技術(shù)竊取鑰匙串
在macOS上存儲密鑰是一個巨大的挑戰(zhàn),可以通過多種不安全的方式來完成。我在漏洞賞金評估期間測試了許多Mac應(yīng)用程序,并觀察到開發(fā)人員傾向于將密鑰放在偏好甚至隱藏的平面文件中。這種方法的問題在于,以標準權(quán)限運行的所有非沙盒應(yīng)用程序都可以訪問密鑰數(shù)據(jù)。平面文件(Flat-File),F(xiàn)lat File是一種包含沒有相對關(guān)系結(jié)構(gòu)的記錄的文件。這個類型通常用來描述文字處理、其他結(jié)構(gòu)字符或標記被移除了的文本。
在使用上,有一些模糊點,如像換行標記是否可以包含于“Flat File(flat file)”中。在任何事件中,許多用戶把保存成“純文本(text only)”類型的Microsoft Word文檔叫做“Flat File(flat file)”。最終文件包含記錄(一定長度的文本的行數(shù))但沒有信息,例如,用多長的行來定義標題或者一個程序用多大的長度來用一個內(nèi)容表對該文檔進行格式化。
例如,macOS上的Signal在〜/ Library / Application Support / Signal / config.json中存儲了用于加密所有消息數(shù)據(jù)庫的密鑰。
macOS鑰匙串
根據(jù)蘋果的說法,鑰匙串是存儲例如密碼和加密密鑰這樣的小秘鑰的最好地方,鑰匙串是一種非常強大的機制,允許開發(fā)人員定義訪問控制列表(ACL)來限制對條目的訪問。應(yīng)用程序可以通過密鑰組權(quán)限進行簽名,以便訪問其他應(yīng)用程序之間共享的秘鑰。以下Objective-C代碼將在鑰匙串中保存密鑰值:
并且在執(zhí)行后,你應(yīng)該看到條目已成功被添加:
第一種竊取技術(shù)
第一種技術(shù)是驗證應(yīng)用程序是否已使用“Hardened Runtime”或“Library Validation”標志進行了簽名,鑰匙串不能檢測到代碼注入。因此,只需使用以下命令:
如果標記為0x0,并且沒有__RESTRICT Mach-O段(這個段非常罕見),則只需將惡意的dylib注入到應(yīng)用程序的主要可執(zhí)行文件中。創(chuàng)建具有以下內(nèi)容的exploit.m文件:
編譯:
并注入:
第二種竊取技術(shù)
如果可執(zhí)行文件已使用Hardened Runtime簽名怎么辦?這個繞過技術(shù)類似于我在XPC開發(fā)系列中向你展示的內(nèi)容。抓取已分析的二進制文件的舊版本,該版本在沒有強化運行時的情況下簽名,并將dylib注入其中。鑰匙串不會驗證二進制文件的版本,而是會給你展示秘鑰。
針對開發(fā)人員的建議修復(fù)程序,創(chuàng)建“鑰匙串訪問組”并將秘鑰移到那里。由于二進制文件的舊版本無法使用該鑰匙串組權(quá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的機制。它計算一個SHA512哈希值并將其存儲在Info.plist文件中,問題在于它不會停止注射。如果主要的可執(zhí)行文件尚未使用Hardened Runtime或Kill標志簽名,并且不包含受限制的權(quán)限,則只需修改asar文件,計算新的校驗和并更新Info.plist文件即可。如果設(shè)置了這些標志或權(quán)限,則始終可以使用ELECTRON_RUN_AS_NODE變量,并再次在主要的可執(zhí)行上下文中執(zhí)行代碼。因此,它可以竊取鑰匙串條目。
總結(jié)
鑰匙串中的安全密鑰存儲確實很難實現(xiàn),因為對請求的可執(zhí)行文件的代碼簽名檢查只是一些表面的功夫,因此有多種方法可以繞過訪問控制機制。
最大的問題是在Electron應(yīng)用程序中,這些應(yīng)用程序無法將密鑰安全地存儲在鑰匙串中。切記,任何將實際代碼存儲在主要的可執(zhí)行文件之外的框架都可能被誘騙加載惡意代碼。
本文翻譯自:https://wojciechregula.blog/post/stealing-macos-apps-keychain-entries/