0
| 本文作者： 李勤 | 2018-08-13 20:41 |
雷鋒網編者按：蘋果公司在 macOS 和 iOS 中都采用了沙盒機制保護系統不受惡意軟件的攻擊。在世界著名的黑客大會 DEFCON 的這次演講中，來自阿里安全的安全研究員分析了最新版的 iOS 中的沙盒機制和以及如何獲取沙盒配置文件。然后，討論了 iOS 上的 IPC 機制，并回顧幾個經典的沙盒逃逸漏洞。隨后，安全研究員展示了 iOS 11.4 上的兩個沙箱逃逸 0day 漏洞。
該文由阿里安全投稿，作者：蒸米，白小龍
蘋果公司在macOS 10.5中把沙盒作為“SeatBelt”引入，它提供了MACF策略的第一個全面實現。在macOS上成功試用后，蘋果公司又將沙盒機制應用于iOS 6中。隨著新的系統的發布或新的威脅出現，沙盒的鉤子數量一直在穩步的增長。如下是iOS/macOS每個版本中鉤子的數量： 
一開始，蘋果的沙盒使用黑名單方式，這意味著蘋果將已知的危險API整合在一起，并阻止它們，默認情況下允許所有其他人使用。隨著蘋果沙盒的發展，它采用了一種白名單的方式，拒絕所有的API，只允許蘋果信任的安全接口。
在MacOS中，配置文件可見并存儲在/System/Library/Sandbox/Profiles中。在iOS中，配置文件被硬編譯到了/usr/libexec/sandboxd中。解碼沙箱配置文件很困難，但我們可以遍歷所有Mach服務根據返回值獲取mach-lookup列表（例如，通過Jonathan Levin的sbtool）。 
為了找到漏洞，我們需要反匯編和分析包含相關Mach服務的處理函數的二進制文件。/System/Library/ LaunchDaemons包含了大多數Mach服務的配置plist。在plist文件中，“ProgramArguments”字段顯示了二進制文件的路徑，“MachServices”顯示了相關的mach服務。
Mach消息包含類型化數據，可以包括端口權限和對大內存區域的引用。XPC消息建立在Mach消息之上，NSXPC消息建立在XPC消息之上。通過Mach消息，沙盒應用程序可以與未被沙盒的Mach（MIG）服務，XPC服務和NSXPC服務進行通信。
bluetoothd的“com.apple.server.bluetooth”Mach服務中有132個函數（從0xFA300開始）。 藍牙通過“com.apple.server.Bluetooth”與沙盒應用程序和其他非沙盒的進程（例如，SpringBoard）進行通信。進程可以使用BTSessionAttach為bluetoothd創建session_token，然后使用BTLocalDeviceAddCallbacks 為事件通知注冊回調。
但是，Bluetoothd僅使用會話令牌來識別進程，這意味著我們可以使用沙盒應用程序通過會話令牌來劫持藍牙和沙盒外的進程之間的通信（CVE-2018-4087）。
漏洞形成的原因是ses_token太容易被暴力破解了。它只有0x10000（0x0000 - 0xFFFF）個可能的值。Apple通過向每個會話添加user_id (= arc4random()) 來修復此問題，只有進程本身知道user_id，并且bluetoothd將檢查map[ses_token] == user_id。
如前所述，user_id = arc4random()= [0x00000000-0xFFFFFFFF]。如果我們知道session_token，我們仍然可以通過user_id暴力劫持通信。 但這需要很長時間（約12小時）。如果沒有user_id驗證的話，還有沒有其他的回調注冊函數呢？答對了！0xFA365 BTAccessoryManagerAddCallbacks()！
但是，通過BTAccessoryManagerAddCallbacks()向bluetoothd發送消息后，沒有任何反應！ 最后，我發現了這個問題。 僅當iOS設備連接到新設備時才會觸發回調事件，這意味著我們需要通過手動單擊藍牙設備來觸發回調。
CallBacks 1（需要的時間很長），CallBacks 2（很難觸發），再來一次CallBacks 3！ 這次，我們又發現了一個可以注冊回調函數的新函數，并且它很容易觸發！
0xFA329 BTDiscoveryAgentCreate()可以為發現代理創建回調，然后我們可以使用0xFA32B BTDiscoveryAgentStartScan()來觸發回調而無需手動點擊！
我們的目標不僅是控制PC指針，還控制要控制整個進程。下一步是創建ROP鏈并對目標進程執行堆噴射。在這種情況下，我們使用MACH_MSGH_BITS_COMPLEX Mach消息以及MACH_MSG_OOL_DESCRIPTOR格式。如果我們發送消息并且沒有接收消息，則ROP鏈將持續保留在目標的內存空間中。經過多次測試，我們可以找到一個MAGIC_ADDR 在 0x105400000這個地址。
我們可控制的寄存器：X3，X4，X5，X19，X20。 最后一個BR是X4。到目前為止，我們只能做BOP（JOP）。但是這樣的話，我們很難控制程序流程。因此，我們需要一個stack pivot來控制堆棧并且從BOP 轉換為 ROP。
在libsystem_platform.dylib中可以找到一個很棒的stack pivot gadget。如果我們可以控制x0，那么我們就可以控制sp。
端口為IPC提供了端點。消息可以發送到端口或從端口接收。端口可以包含權限，并且端口權限可以在消息中傳遞。一個進程最重要的端口是mach_task_self()。可以通過其任務端口來控制進程的內存和所有寄存器。
我們可以使用mach_vm_allocate（target_task_port，＆remote_addr，remote_size，1）在遠程進程中分配內存。mach_vm_write（target_task_port，remote_address，local_address，length）可用于將數據復制到遠程進程中。 thread_create_running（target_task_port，ARM_THREAD_STATE64，＆thread_state，stateCnt和thread_port）可用于在遠程進程中創建新線程。因此，如果我們可以獲得一個進程的任務端口。 我們可以通過mach msg輕松控制整個過程。
1. 我們可以使用mach_port_insert_right（mach_task_self()，port，port，MACH_MSG_TYPE_MAKE_SEND）向端口插入發送權限。此類端口可以通過具有MACH_MSG_PORT_DESCRIPTOR類型的OOL消息發送。
2. 在大多數情況下，mach_task_self()返回0x103，所以我們可以在不使用ROP的情況下使用0x103（調用mach_task_self()）。
3. 為了將任務端口發送到我們的pwn應用程序，我們需要知道我們的pwn應用程序的端口號。但是我們不能用launchd來幫助我們。幸運的是，端口號可以通過（0x103 + 0x100 * N）猜測。這就是我們向遠程進程發送0x1000端口的原因（為了提高成功率）。
但是在iOS 11中，蘋果加入了一個新的緩解機制用來控制沙盒中的app獲取task port:
雖然我們無法很容易的獲取task port，但是我們可以利用下面的ROP gadget來調用任意函數:
使用這些ROP，我們可以打開更多的攻擊面并進一步的攻擊內核。
1. MacOS and *OS Internals http://newosxbook.com/
2. Pangu 9 Internals https://www.blackhat.com/docs/us-16/materials/us-16-Wang-Pangu-9-Internals.pdf
3. triple_fetch https://bugs.chromium.org/p/project-zero/issues/detail?id=1247
4. https://blog.zimperium.com/cve-2018-4087-poc-escaping-sandbox-misleading-bluetoothd/
5. Mach portal https://bugs.chromium.org/p/project-zero/issues/detail?id=965
在6月份的時候，文章中提到的兩個“0day”漏洞被我們提交給了蘋果，在iOS 11.4.1和iOS 12 beta中被修復了 (CVE-2018-4330和CVE-2018-4327)。但是在iOS 11.4以及之前版本中都可以被利用，請盡快升級您的iOS以避免潛在的攻擊。
via 雷鋒網，雷鋒網，雷鋒網，重要的事情說三遍。
雷峰網原創文章，未經授權禁止轉載。詳情見轉載須知。
