細數iOS上的那些安全防護

2021-12-29 20:09:01 字數 3891 閱讀 3777

隨著蘋果對ios系統多年的研發,ios上的安全防護機制也是越來越多,越來越複雜。這對於剛接觸ios安全的研究人員來說非常不友好,往往不知從何入手。因此,為了讓大家能夠更加系統性的了解ios上的安全機制,我們從三個方面著眼:**簽名(codesign)、沙盒機制(sandbox) 和利用緩解(exploit mitigation),對ios的系統安全機制做了乙個總結。希望能夠給大家的學習以及研究帶來一定的幫助。注意,以下內容是以最新版的ios 9.3.4做為標準進行講解。

為了保護開發者的版權以及防止盜版應用,蘋果系統擁有非常嚴格的簽名保護機制。想要開發ios程式,必須先註冊開發者賬號,並向蘋果申請相關的證書,否則程式只能在模擬器上執行,無法在真機上除錯,也無法上架app store。除了傳統的簽名機制以外,蘋果還額外增加了team id的安全防護措施,用來增強ios系統的安全性。

傳統的簽名機制即ios系統中使用的數字證書機制。數字證書是一種對數字內容進行校驗的方法,它首先對內容使用摘要演算法(例如md5,sha1)生成一段固定長度的hash值(可以理解為原內容的摘要),然後利用私鑰對這個摘要進行加密,得到原內容的數字簽名。接受方一併接收到原內容和數字簽名,首先用相同的摘要演算法生成原內容的摘要,同時用公鑰解密數字簽名,得到摘要2,然後比較摘要1和摘要2,若相同,則驗證原內容有效。我們從蘋果mc(member center)中獲得的數字證書就是被蘋果ca簽過名的合法的證書。而ios裝置在執行app前,首先要先驗證ca的簽名是否合法,然後再通過證書中我們的公鑰來驗證app是否的確是開發者發布的,且中途沒有對程式進行過篡改。理論上想要破解或者繞過這個簽名機制,需要能夠獲取到蘋果的私鑰,或者能夠找到簽名校驗過程中的漏洞。

ios在執行**前,都會對即將執行的**進行簽名校驗。簽名的校驗機制是執行在核心裡的。因此想要關閉這個校驗的話,需要對系統進行越獄才行。核心在vm_fault_enter中規定了絕大部分情況下,具有執行位的頁需要進行簽名有效性檢查,如果檢查到該頁簽名無效會為程序設定kill flag。簽名校驗分兩種情況;如果binary是platform binary,系統會直接校驗binary的雜湊值是否存在於trustcache中。如果binary是第三方應用程式,會先在核心在檢查執行頁對應hash值,而頁hash對應的簽名由使用者態程序amfid校驗其正確性。

team id 最早在ios 8中被提出,在ios 9中得到了進一步的加強。team id的出現主要是為了阻止攻擊者將自己的動態庫載入到不屬於自己的executable中,常見例子:越獄過程中將動態庫載入到系統程序,獲得沙箱外的任意**執行能力;惡意應用通過沙箱逃逸將自己的動態庫載入到別人的app執行環境,盜取賬號密碼等有價值的資訊。所以team id的具體的校驗邏輯就是根據這個原則來設計。除了特殊情況,系統的程序只能載入系統的動態庫。第三方app根據自己的team id來決定哪些具有相同team id的dylib能被載入。

很多系統都有沙盒機制,但是像ios這麼複雜的卻很少。ios從uid/gid permission,mac和entitlement三個維度實現了整個系統的沙盒機制:

一般情況下,ios會將程序的許可權分為root和mobile,一些特殊的模組(比如基帶)會有自己的使用者組。需要注意的是,所有第三方的app都是執行在mobile許可權下的。

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。

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:

除了常見的stack canaries、 aslr和dep等利用緩解技術之外,ios還有很多高階的或者獨有的利用緩解技術:

棧金絲雀保護是已知的放置在緩衝器和控制資料之間的乙個隨機值。當緩衝器溢位時,最先被破壞通常是金絲雀值。因此當金絲雀的資料的驗證失敗的時候,就表示出現了緩衝區溢位,從而觸發保護機制,並使程式停止執行。

為了增加攻擊者**目的位址的難度,防止攻擊者直接定位攻擊**位置,使用者態程序在每次啟動時的執行檔案基址都是隨機生成的。並且,在每次手機重啟後,核心kernel mach-o的基址也是隨機的。

dep是為了防止資料頁執行**。通常情況下,預設不從堆和棧執行**。dep會檢測從這些位置執行的**,並在發現執**況時引發異常。在mprotect對應的核心實現中,不允許page被同時賦予執行和寫這兩種許可權。當page的許可權發生變化或乙個新的page mmap到記憶體中的時候,vm_fault_enter會檢查這個頁是否有執行位,如果有執行位,會對這個頁做簽名檢查。

在ios中,如果修改乙個zone中已釋放的free element,當記憶體管理器再次分配記憶體到這個free element的時候會發生隨機panic。具體的邏輯是,當element被釋放後,核心會根據重啟時建立的token生成一些內容填充在element中。這樣一方面使用者態無法得知填充的內容是什麼,另一方面核心在分配記憶體的時候可以根據token知道這個element有沒有被修改,如果被修改就產生panic。

ios系統在釋放記憶體塊的過程中,會對記憶體釋放後在free佇列中的順序進行隨機化處理,這個安全措施主要是使用攻擊者無法根據堆噴介面呼叫的時序來**對應元素在核心的布局。

armv8-a架構定義了四個例外層級,分別為el0到el3,其中數字越大代表特權(privilege)越大:

el0: 無特權模式(unprivileged)

el1: 作業系統核心模式(os kernel mode)

el2: 虛擬機器監視器模式(hypervisor mode)

el3: trustzone monitor mode

kpp就是執行在application process 的 el3中,目的是用來保證:唯讀的頁不可修改、page table 不可修改、執行頁不可修改。

雖然ios有眾多的安全機制和緩解措施,但這並不代表ios系統牢不可破。有時候一些不起眼的小錯誤就可能導致蝴蝶效應,最終造成整個安全系統的崩盤。通過對最新的ios 9.3.4研究,我們團隊依然找到了ios系統上的一些安全問題,甚至可以導致整個系統被控制。如下**就演示了在最新的ios 9.3.4上獲取系統最高許可權並安裝cydia的過程

細數iOS上的那些安全防護

隨著蘋果對ios系統多年的研發,ios上的安全防護機制也是越來越多,越來越複雜。這對於剛接觸ios安全的研究人員來說非常不友好,往往不知從何入手。因此,為了讓大家能夠更加系統性的了解ios上的安全機制,我們從三個方面著眼 簽名 codesign 沙盒機制 sandbox 和利用緩解 exploit ...

細數iOS上的那些安全防護

隨著蘋果對ios系統多年的研發,ios上的安全防護機制也是越來越多,越來越複雜。這對於剛接觸ios安全的研究人員來說非常不友好,往往不知從何入手。因此,為了讓大家能夠更加系統性的了解ios上的安全機制,我們從三個方面著眼 簽名 codesign 沙盒機制 sandbox 和利用緩解 exploit ...

iOS開發 資料加密安全防護

開發中,客戶端開發,密碼加密!伺服器不知道使用者的密碼!所以現在沒有 找回密碼 的功能,只有重置密碼!從業務邏輯來講,非對稱加密要比對稱加密要相對安全,但是效率不高,不提倡大量資料的加密的使用,而僅僅對關鍵資料進行使用。import viewcontroller.h import nsstring ...