作者：keenjoy95
隨著 macOS / iOS 普及程度的提高，mac 平臺的內核監控與攻防也漸漸地成為了熱門話題。
筆者近期實踐了一些可行的監控方案，這些方案將有助于構建完整的內核監控系統。
Kernel Authorization
首先值得關注的是 KAuth 機制，該機制于 12 年前引入 Mac OS X 10.4 Tiger 內核。這一可以稱得上是簡陋的回調接口由蘋果官方認可，我們可以在開發者中心找到詳細的示例代碼和文檔 [1]。
實踐后可發現 KAuth 機制很容易上手，但天花板也隨之而來。正如 Jonathan Levin 在《*OS Internals Volume III》[2] 一書中總結的那樣，作為 KPI (Kernel Programming Interface) 的 KAuth 機制缺乏細粒度的監控能力，基于它去設計安防軟件一定會捉襟見肘。
以進程監控回調 KAUTH_FILEOP_EXEC 為例，我們可以得到進程路徑，但無法取得命令行參數。類似的情況還有文件創建時的 fmodep 上下文等。
不過這種限制不應該難倒我們，通過反匯編引擎和動態棧回溯我們可以挖出這些信息。下圖是 Google Chrome 運行時那冗長的啟動參數：
MAC (Mandatory Access Control) Framework
在 Mac OS X 10.5 Leopard 的 SDK 中蘋果“錯誤的”為大家引入了一種新的監控機制 —— Mandatory Access Control Policy Framework。很快蘋果公司糾正了這一錯誤，徹底將這一接口私有化。在文檔 QA1574 [3] 中蘋果明確的指出第三方不應該使用 MAC 機制，它不屬于 KPI 的一部分。
這意味著只有蘋果公司才能夠調用這套相對靈活而強力的接口，例如：Apple Seatbelt Sandbox [4]、TMSafetyNet (Safety net for Time Machine) [5]、AMFI (Apple Mobile File Integrity) [6] 等等。
MAC Version 47 的接口細節如下：
https://github.com/opensource-apple/xnu/blob/10.12/security/mac_policy.h#L6192
我依稀記得微軟公司也曾經有過類似的私貨，結果這些 Undocumented API 的使用差點讓微軟被起訴到分家，罪名是私用 Undocumented API 涉嫌不公平競爭。
言歸正傳，因為 XNU 源代碼公開，MAC Policy Framework 的使用非常容易上手。但另一個問題也隨之而來，如何監控系統或第三方使用 MAC Framework 的情況？
上述需求的一個隱含問題是：如何保證遍歷系統內部數據結構時的安全，即持有（不導出的）鎖是個關鍵。這種小問題也不應該難倒我們，通過閱讀 XNU 相關源代碼，我們可以很快找到一個解決方案：
在民風彪悍的參數檢查之后
https://github.com/opensource-apple/xnu/blob/10.12/security/mac_base.c#L652
https://github.com/opensource-apple/xnu/blob/10.12/security/mac_base.c#L655
https://github.com/opensource-apple/xnu/blob/10.12/security/mac_base.c#L658
https://github.com/opensource-apple/xnu/blob/10.12/security/mac_base.c#L661
是獲取 mac_policy_mtx 鎖的代碼
https://github.com/opensource-apple/xnu/blob/10.12/security/mac_base.c#L671
在釋放鎖之前
https://github.com/opensource-apple/xnu/blob/10.12/security/mac_base.c#L780
系統給了第三方驅動兩次回調的機會
https://github.com/opensource-apple/xnu/blob/10.12/security/mac_base.c#L770
https://github.com/opensource-apple/xnu/blob/10.12/security/mac_base.c#L774
這兩次寶貴的機會是持鎖的，我們可以用它來安全地 dump 相關內核數據結構。
下圖展示了 TMSafetyNet、Apple Mobile File Integrity 以及 Apple Seatbelt Sandbox 對于 MAC Policy 回調的使用情況：
當然，對于研究蘋果的沙箱設計與實現，這也會是一個好的起點。
另外，大量的 macOS 安全監控類軟件也無視警告的使用了這個接口。例如：objective-see 的 BlockBlock [7] 以及 FireEye Mandiant 的 Monitor.app [8]。
使用上述方案針對 FireEye Mandiant 的 Monitor.app 做一次分析可以發現，它一共注冊了五種回調：
1.mpo_cred_label_update_execve
2.mpo_file_check_mmap
3.mpo_pty_notify_grant
4.mpo_pty_notify_close
5.mpo_kext_check_load
值得說道的是，這五個回調是五次獨立注冊的結果。出于優化的考慮也許應該是“一次注冊五個回調函數”而不是“五次注冊五個回調函數”。回想 Windows XP 時代，大家為了爭搶 PsSetCreateProcessNotifyRoutine 那 8 個名額拼的你死我活，現在的內核程序員還真是奢侈呢。
作為該分析的一個攻防副產物，我們可以任意 Unregister 系統或第三方的回調。現在再去看微軟 CmRegisterCallback 函數中引入 Cookie 概念 [9] 感覺真的是明智的。
Kernel Inline Hook
由于沒有類似 Patchguard [10] 的內核防護機制，在 64 位 macOS 內核中實現一個 Inline Hook 引擎并不是什么難事，最多就是需要在 lldb 不給力的情況下見識一下 Panic 的兄弟姐妹。
我們可以給 Inline Hook 引擎加大一些難度，給目標函數實現 Pre 和 Post Callback 回調。Pre Callback 可以用作參數過濾、Post Callback 可以用作結果篡改，這種設計會非常方便。
作為演示，我以 OSKext::start() 驅動加載例程作為練手，可以看到：
(1) 鉤子監控到驅動程序被加載
(2) 結合反匯編引擎找到目標驅動入口
(3) 在 Pre Callback 中實現參數過濾、驅動代碼篡改、強制錯誤返回等
(4) 在 Post Callback 中得到返回值，甚至再次篡改返回結果等
(5) 系統的后知后覺
當然，我們可以對任意一個我們所關心的內核函數做這樣的事情，Inline Hook 的使用僅受制于想象力。
小結
1.上述功能點在開發 Rootkit 和 Anti-Rootkit、調試漏洞時都用得著。
2.祝您 lldb 內核調試愉快。
引用
[1] https://developer.apple.com/library/content/technotes/tn2127/_index.html
[3] https://developer.apple.com/library/content/qa/qa1574/_index.html
[5] https://support.apple.com/en-us/HT201250
[6] https://www.theiphonewiki.com/wiki/AppleMobileFileIntegrity
[7] https://www.synack.com/2015/11/17/monitoring-process-creation-via-the-kernel-part-i/
[8] https://www.fireeye.com/services/freeware/monitor.html
[9] https://msdn.microsoft.com/en-us/library/windows/hardware/ff541918(v=vs.85).aspx
本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/380/
暫無評論