細數iOS上的那些安全防禦

0x00 序

隨着蘋果對iOS系統多年的研發，iOS上的安全防禦機制也是愈來愈多，愈來愈複雜。這對於剛接觸iOS安全的研究人員來講很是不友好，每每不知從何入手。所以，爲了讓你們可以更加系統性的瞭解iOS上的安全機制，咱們從三個方面着眼：代碼簽名(CodeSign)、沙盒機制(SandBox) 和利用緩解(Exploit Mitigation)，對iOS的系統安全機制作了一個總結。但願可以給你們的學習以及研究帶來必定的幫助。注意，如下內容是以最新版的iOS 9.3.4作爲標準進行講解。

0x01 代碼簽名(CodeSign)

爲了保護開發者的版權以及防止盜版應用，蘋果系統擁有很是嚴格的簽名保護機制。想要開發iOS程序，必須先註冊開發者帳號，並向蘋果申請相關的證書，不然程序只能在模擬器上運行，沒法在真機上調試，也沒法上架App Store。除了傳統的簽名機制之外，蘋果還額外增長了Team ID的安全防禦措施，用來加強iOS系統的安全性。

(1). 傳統簽名機制 - 數字證書

傳統的簽名機制即iOS系統中使用的數字證書機制。數字證書是一種對數字內容進行校驗的方法，它首先對內容使用摘要算法（例如MD5，SHA1）生成一段固定長度的hash值(能夠理解爲原內容的摘要)，而後利用私鑰對這個摘要進行加密，獲得原內容的數字簽名。接受方一併接收到原內容和數字簽名，首先用相同的摘要算法生成原內容的摘要，同時用公鑰解密數字簽名，獲得摘要2，而後比較摘要1和摘要2，若相同，則驗證原內容有效。咱們從蘋果MC（Member Center）中得到的數字證書就是被蘋果CA簽過名的合法的證書。而iOS設備在執行app前，首先要先驗證CA的簽名是否合法，而後再經過證書中咱們的公鑰來驗證app是否的確是開發者發佈的，且中途沒有對程序進行過篡改。理論上想要破解或者繞過這個簽名機制，須要可以獲取到蘋果的私鑰，或者可以找到簽名校驗過程當中的漏洞。

(2). 簽名校驗的實現

iOS在運行代碼前，都會對即將運行的代碼進行簽名校驗。簽名的校驗機制是運行在內核裏的。所以想要關閉這個校驗的話，須要對系統進行越獄才行。內核在vm_fault_enter中規定了絕大部分狀況下，具備執行位的頁須要進行簽名有效性檢查，若是檢查到該頁簽名無效會爲進程設置kill flag。簽名校驗分兩種狀況；若是binary是platform binary，系統會直接校驗binary的哈希值是否存在於trustcache中。若是binary是第三方應用程序，會先在內核在檢查執行頁對應hash值，而頁hash對應的簽名由用戶態進程amfid校驗其正確性。

(3). Team ID

Team ID 最先在iOS 8中被提出，在iOS 9中獲得了進一步的增強。Team ID的出現主要是爲了阻止攻擊者將本身的動態庫加載到不屬於本身的executable中，常見例子：越獄過程當中將動態庫加載到系統進程，得到沙箱外的任意代碼執行能力；惡意應用經過沙箱逃逸將本身的動態庫加載到別人的app運行環境，盜取帳號密碼等有價值的信息。因此Team ID的具體的校驗邏輯就是根據這個原則來設計。除了特殊狀況，系統的進程只能加載系統的動態庫。第三方app根據本身的Team ID來決定哪些具備相同Team ID的dylib能被加載。

0x02 沙盒機制(SandBox)

不少系統都有沙盒機制，可是像iOS這麼複雜的卻不多。iOS從UID/GID permission，MAC和entitlement三個維度實現了整個系統的沙盒機制：

(1). UID/GID permission

通常狀況下，iOS會將進程的權限分爲root和mobile，一些特殊的模塊（好比基帶）會有本身的用戶組。須要注意的是，全部第三方的app都是運行在mobile權限下的。

(2). iOS Mandatory Access Control

iOS的MAC在TrustedBSD Mac Framework基礎上實現，在內核具體接口、具體位置插入權限hook check（mac_** call），在發生調用時檢查當前進程是否知足調用的MAC police。
而進程的MAC police主要是經過sandbox profile。Sandbox profile是蘋果爲每一個系統進程或app預設的，例如：哪些文件可讀可寫，哪些不能；哪些system call能夠調用，哪些不能等等。

對於系統進程，通常狀況下蘋果會爲不一樣的系統進程配備不一樣的sandbox profile，既知足業務需求，又遵循權限最小化原則。

對於第三方app，則是統一配備名爲 Container 的sandbox profile，這個profile裏面的內容限制可達數千條。限制很是嚴格，以至於只有不多數的syscall能在第三方app內訪問。一些安卓中很是普通的調用，例如fork，exec等建立子進程的系統調用，在第三方app內都是沒法生效的。咱們常說的沙盒逃逸，其實目的就是跳出container的sandbox profile。

(3). Entitlement

Entitlement的出現主要是爲了上面兩個維度都沒法解決的權限檢查問題。

假設有這樣的場景：
進程 A 是 service 、進程 B 是 client，二者經過IPC通信。
進程A提供的服務接口分別有：a1 , a2 ，其中只但願接口a1能被B訪問。

由於檢查發生在用戶態，不能直接使用TrustedBSD Mac Framework，同時須要有更簡單的查詢方式，這樣就須要在a2接口的代碼中加入權限校驗。基於entitlement的校驗框架就是在這個需求背景下被提出來的。業務進程只須要關注entitlement的內容，而entitlement的正確性由簽名保證。好比想要訪問提供了能刪除app的接口的」com.apple.mobile.installd」服務就必須擁有對應的」com.apple.private.mobileinstall.allowedSPI」 entitlement才行。而lockdownd這個service是用於和iTunes交互來進行安裝、升級、刪除應用的，因此這個服務爲了能與installd服務通信，進行刪除app操做，就須要擁有」com.apple.private.mobileinstall.allowedSPI」 這個entitlement：

0x03利用緩解(Exploit Mitigation)

除了常見的Stack Canaries、 ASLR和DEP等利用緩解技術以外，iOS還有不少高級的或者獨有的利用緩解技術：

(1).棧金絲雀保護 (Stack Canaries)

棧金絲雀保護是已知的放置在緩衝器和控制數據之間的一個隨機值。當緩衝器溢出時，最早被破壞一般是金絲雀值。所以當金絲雀的數據的驗證失敗的時候，就表示出現了緩衝區溢出，從而觸發保護機制，並使程序中止運行。

(2).地址隨機化 (ASLR/KASLR)

爲了增長攻擊者預測目的地址的難度，防止攻擊者直接定位攻擊代碼位置，用戶態進程在每次啓動時的執行文件基址都是隨機生成的。而且，在每次手機重啓後，內核kernel mach-o的基址也是隨機的。

(3).數據執行保護 (DEP)

DEP是爲了防止數據頁執行代碼。一般狀況下，默認不從堆和棧執行代碼。DEP會檢測從這些位置運行的代碼，並在發現執行狀況時引起異常。在mprotect對應的內核實現中，不容許page被同時賦予執行和寫這兩種權限。當page的權限發生變化或一個新的page mmap到內存中的時候，vm_fault_enter會檢查這個頁是否有執行位，若是有執行位，會對這個頁作簽名檢查。

(4). 堆釋放元素保護 (Heap Free Element Protection)

在iOS中，若是修改一個zone中已釋放的free element，當內存管理器再次分配內存到這個free element的時候會發生隨機panic。具體的邏輯是，當element被釋放後，內核會根據重啓時建立的token生成一些內容填充在element中。這樣一方面用戶態沒法得知填充的內容是什麼，另外一方面內核在分配內存的時候能夠根據token知道這個element有沒有被修改，若是被修改就產生panic。

(5).堆元素地址隨機化 (Random Heap Element Address)

iOS系統在釋放內存塊的過程當中，會對內存釋放後在free隊列中的順序進行隨機化處理，這個安全措施主要是使用攻擊者沒法根據堆噴接口調用的時序來預測對應元素在內核的佈局。

(6).內核補丁保護 (Kernel Patch Protection)

ARMv8-A架構定義了四個例外層級，分別爲EL0到EL3，其中數字越大表明特權(privilege)越大:

EL0: 無特權模式(unprivileged)

EL1: 操做系統內核模式(OS kernel mode)

EL2: 虛擬機監視器模式(Hypervisor mode)

EL3: TrustZone monitor mode

KPP就是運行在Application Process 的 EL3中，目的是用來保證：只讀的頁不可修改、page table 不可修改、執行頁不可修改。

0x04 總結

雖然iOS有衆多的安全機制和緩解措施，但這並不表明iOS系統牢不可破。有時候一些不起眼的小錯誤就可能致使蝴蝶效應，最終形成整個安全系統的崩盤。經過對最新的iOS 9.3.4研究，咱們團隊依然找到了iOS系統上的一些安全問題，甚至能夠致使整個系統被控制。以下視頻就演示了在最新的iOS 9.3.4上獲取系統最高權限並安裝cydia的過程：

視頻：http://v.youku.com/v_show/id_...

更多技術交流和進展，歡迎你們繼續關注阿里移動安全。

0x05 參考資料

1. Hacking from iOS 8 to iOS 9, POC 2015.

2. ARMv8 wiki

3. To Sign and Protect – COPS in OS X and iOS, RSA 2015

4. 漫談iOS程序的證書和簽名機制

---

做者：龍磊、黑雪、蒸米@阿里巴巴移動安全，更多安全類技術文章，請訪問阿里聚安全博客