移動智能終端安全課件：基于系統(tǒng)安全機制的防護

基于系統(tǒng)安全機制的防護15.1系統(tǒng)安全基礎15.2Android權(quán)限機制的改進15.3通過iOS安全機制加強防護15.4基于權(quán)限的應用程序安全性分析小結(jié)

15.1系統(tǒng)安全基礎

操作系統(tǒng)的安全訪問控制模型通常表述為一個主體(subject)可以訪問哪些對象(object)。主體是指可以授予或拒絕訪問某個對象的人或事物，如用戶、程序、系統(tǒng)進程。對象是指被訪問的某種系統(tǒng)的資源，如文件、打印機等。目前操作系統(tǒng)安全隔離技術(shù)包括自主訪問控制(DiscretionaryAccessControl，DAC)和強制訪問控制(MandatoryAccessControl，MAC)兩種類別，后者是安全的操作系統(tǒng)必要的選擇。

DAC基于主體的身份或者主體所屬的組別來限制對象的訪問權(quán)限，主要技術(shù)特征是主體具有的訪問權(quán)限能夠通過繼承或者賦予被傳遞給另外一個主體。這意味著訪問權(quán)限具有傳遞鏈條，因此，當一個程序中發(fā)生安全事件時，會危及系統(tǒng)，使得DAC在木馬面前特別脆弱。目前，最著名的DAC實現(xiàn)是基于用戶ID和組(group)的Unix／Linux文件系統(tǒng)的權(quán)限系統(tǒng)。

舉例來說，在Linux文件系統(tǒng)中，用戶A擁有文件file1且對file1擁有讀寫權(quán)限，對其他用戶則關(guān)閉讀寫權(quán)限。用戶(惡意攻擊者)C編寫程序。該程序在執(zhí)行時生成文件file2且在程序中設置新的訪問列表，即用戶A對file2的寫權(quán)限和用戶C對file2的讀權(quán)限。用戶C將惡意程序偽裝成合法程序發(fā)給用戶A，當程序被A運行時，程序就具有了A的訪問權(quán)限。在程序邏輯中拷貝file1到file2，用戶C就竊取了file1的內(nèi)容。如果用戶A是系統(tǒng)管理員，攻擊者C會獲取最大的權(quán)限。

在MAC的實現(xiàn)中，存在多種對象標記和策略判斷規(guī)則，不同MAC系統(tǒng)的實現(xiàn)并不一樣。在iOS和Android的應用沙箱技術(shù)中，均采用某種程度的MAC技術(shù)實現(xiàn)。iOS在操作系統(tǒng)內(nèi)核層面實現(xiàn)MAC，而Android在中間層實現(xiàn)MAC。

iOS的應用沙箱是一種強限制的結(jié)構(gòu)，iOS將應用限制的級別定義為“每一個應用都是一個孤島”。為了軟件安全，該設計極大程度地推崇應用隔離，而犧牲了本機內(nèi)應用間的信息共享。

圖15-1所示為來自蘋果公司官方文檔的iOS應用沙箱。

圖15-1

iOS中的沙箱

應用“孤島”是如何形成的呢？iOS應用沙箱提供細粒度的應用權(quán)限訪問控制，其應用沙箱的主要訪問限制可以總結(jié)如下：

(1)應用只看到沙箱容器目錄，表述為<Application_Home>，規(guī)定其不可見系統(tǒng)的其他目錄和整個文件系統(tǒng)，沙箱中的關(guān)鍵子目錄有<Application_Home>/

AppName.app、<Application_Home>/Documents/、<Application—Home>/Documentshnbox、<Application_Home>/Library/?等，每個子目錄的使用方法有嚴格規(guī)定。

(2)

<Application_Home>/Documents/Inbox只有讀和刪除的權(quán)限，沒有寫的權(quán)限。

(3)應用可以對用戶的照片、視頻內(nèi)容及iTunes目錄進行只讀訪問。

(4)應用可以對用戶的聯(lián)系人數(shù)據(jù)(SQLite本地文件數(shù)據(jù)庫)進行讀/寫訪問。

(5)應用可以啟動網(wǎng)絡連接以發(fā)送和接收數(shù)據(jù)。

(6)應用僅通過系統(tǒng)API執(zhí)行有限制的后臺服務。

(7)應用不可以讀取系統(tǒng)的日志目錄。

(8)不在權(quán)限列表中描述的操作均不能通過授權(quán)等。

iOS的應用沙箱不是基于Unix用戶ID的權(quán)限控制DAC方案，而是操作系統(tǒng)內(nèi)核層次的MAC的實現(xiàn)，操作系統(tǒng)集成了TrustedBSDMACFramework項目，以實現(xiàn)應用沙箱。

iOS的應用沙箱的執(zhí)行結(jié)果，可參照iOS操作系統(tǒng)的同源操作系統(tǒng)MACOSX的sandbox-exec命令來觀察。

iOS/MACOSX對不同的應用類型，定義不同的沙箱。沙箱的訪問權(quán)限定義配置文件可以使用SBPL(SandBoxPolicyLanguage)，以正則表達式的語法來描述。在應用啟動的同時沙箱啟動，沙箱的配置被傳遞到操作系統(tǒng)內(nèi)核執(zhí)行。

iOS應用沙箱的強大之處不僅在于單純的技術(shù)實現(xiàn)，還在于蘋果公司嚴格的審核測試。應用在發(fā)布到蘋果的應用商店之前，需經(jīng)過蘋果公司嚴格的審核測試，如果應用不遵循沙箱的設計規(guī)格則不能正常運作，或?qū)⒃趯徍谁h(huán)節(jié)被廢棄。即使應用在上市之后被發(fā)現(xiàn)有惡意的行為仍會被作下架處理。

與iOS操作系統(tǒng)對應，Android操作系統(tǒng)的沙箱技術(shù)是基于Linux的原生進程與用戶賬號組合來進行限制的技術(shù)。Android是多用戶的Linux操作系統(tǒng)，每個應用使用不同的用戶ID運行進程，并對應用的數(shù)據(jù)文件進行Linux操作層次的文件訪問保護，賦予且僅賦予程序用戶的ID以訪問其權(quán)限，使用其他用戶ID運行的程序無法越權(quán)訪問程序所保護的數(shù)據(jù)。

Android應用簽名不要求權(quán)威的中心進行認證，其驗證簽名僅是為了區(qū)分應用的提供商身份，相同應用提供商簽名的多個應用可以在同一個進程空間運行，彼此間能夠更緊密耦合地共享數(shù)據(jù)訪問。

操作系統(tǒng)層面基于Linux用戶ID的權(quán)限控制是一種DAC的權(quán)限控制，DAC的缺點如上文所述，使系統(tǒng)在面對木馬惡意程序時表現(xiàn)脆弱。為保持Linux內(nèi)核的相對獨立性，Android在Linux之上的中間層添加了MAC式的權(quán)限控制——

permission機制，根據(jù)應用安裝時用戶的授權(quán)權(quán)限定義進行敏感數(shù)據(jù)和操作許可的判斷。下面闡述的是Android的permission機制。

Android對系統(tǒng)中的各種資源訪問能力定義了詳細的權(quán)限要求列表。例如，讀取聯(lián)系人的權(quán)限為read_contacts，發(fā)送短信的權(quán)限為send_sms，訪問攝像頭的權(quán)限為camera等。在用戶下載安裝應用的時候，應用列出所需的軟件授權(quán)權(quán)限列表，用戶必須在同意給予授權(quán)后才能繼續(xù)安裝應用。應用安裝成功后，針對限制應用的沙箱生成，該沙箱限制應用只能訪問用戶授權(quán)的能力訪問范圍。在某種Android手機上，通過“設置”→“其他管理應用”→“所檢查的應用程序”→“查看權(quán)限詳情”等一系列操作，最終的權(quán)限列表如圖15-2所示。

圖15-2某應用軟件所具有的權(quán)限

15.2Android權(quán)限機制的改進

15.2.1Android安全機制基礎

Android作為智能手機廣泛采用的移動操作系統(tǒng)，由于智能手機中存放著大量高度隱私敏感的個人數(shù)據(jù)，因此對Android生態(tài)系統(tǒng)以及用戶個人數(shù)據(jù)的安全性提出了更高的安全要求。為保證用戶數(shù)據(jù)的安全以及隱私，Android采用基于權(quán)限的安全模型來限制對敏感數(shù)據(jù)(如位置、通話記錄、聯(lián)系人數(shù)據(jù)等)的訪問。

然而，Android權(quán)限機制對用戶數(shù)據(jù)安全性的保護不能達到預期的安全防御效果，所以研究者對權(quán)限機制進行了改進，包括改進安裝時期的權(quán)限以幫助用戶對權(quán)限的理解、權(quán)限機制設計上的漏洞分析與防御方法、利用權(quán)限對程序安全性進行分析研究這三部分。

權(quán)限的賦予可分為兩類：一類是高層組件，例如應用和系統(tǒng)服務，采用包管理器進行管理和查詢；一類是底層組件，利用傳統(tǒng)的LinuxDAC機制進行管理，不直接訪問包管理器。

1.底層權(quán)限管理

Android進程主要是通過UID、GID以及一組補充的GID來實現(xiàn)的。Android沙箱以UID為基礎實現(xiàn)(可參看上一小節(jié)中Android中的沙箱應用)，每個進程擁有自己獨特的UID(先不考慮共享UID)。進程UID和GID由包管理器映射到應用程序的UID。補充GID則為額外的權(quán)限。內(nèi)置權(quán)限到組的映射是靜態(tài)的。

從代碼可知，“android.permission.

BLUETOOTH

_ADMIN”映射到GID的3001。包管理器在讀取platfrom.xml時，同時維護一個權(quán)限到GID的列表。在對安裝中的包進行授權(quán)時，包管理器會檢查每個權(quán)限是否有對應的GID。如果有，則加入到補充GID列表中。此時僅確定了進程需要賦予哪些額外的GID。

那Android是如何賦權(quán)的呢？當Android啟動新進程時，為減少程序所需內(nèi)存并加快啟動時間，Android會直接fork()Zygote進程，并執(zhí)行Android特有的函數(shù)進行分化而不執(zhí)行固有的exec函數(shù)。

2.高層權(quán)限管理

在了解高層權(quán)限管理之前，先介紹包管理器所維護的安裝程序包核心數(shù)據(jù)庫，該數(shù)據(jù)庫以xml文件的形式放入?/data/system/packages.xml中。

碼包括安裝路徑、版本號、簽名證書和每個包的權(quán)限。上層的管理通過包管理器及該數(shù)據(jù)庫進行交互。由于組件無法在運行時修改權(quán)限，因此權(quán)限執(zhí)行檢查都是靜態(tài)的。執(zhí)行分為兩類，分別是靜態(tài)和動態(tài)。靜態(tài)執(zhí)行和動態(tài)執(zhí)行流程大致相同：首先，Binder.getCallingUid()和Binder.

getCalling

Pid()獲取調(diào)用者的UID和PID，然后利用UID映射包名獲得相關(guān)權(quán)限。如果權(quán)限集合中含有所需權(quán)限即啟動，否則拋出SecurityException異常。

Android權(quán)限機制的實現(xiàn)包括安裝時期以及運行時期兩部分。用戶在安裝時期完成對權(quán)限的授權(quán)工作，在程序運行期間Android系統(tǒng)通過引用監(jiān)視器判斷應用程序是否具備使用特定功能的權(quán)限。關(guān)于Android權(quán)限機制改進的相關(guān)研究工作是從安裝時期及運行時期兩個角度展開的。

詳細描述AndroidSD卡上文件的存儲保護。因為智能終端硬件資源的有限性及Android系統(tǒng)本身所具有的特點，內(nèi)存空間遠遠不能滿足實際需求，所以需要依靠SD卡來輔助解決，因此存儲在SD卡上的數(shù)據(jù)安全也成為Android應用安全中必須考慮的重要一環(huán)。下面介紹AndroidSD卡訪問機制，以及開發(fā)者如何保障開發(fā)的App存儲在SD卡上數(shù)據(jù)的安全。

Android的訪問SD卡的機制(Android系統(tǒng)在啟動過程中的Vold進程、mountSD卡的流程、系統(tǒng)運行過程中對SD卡操作的流程)如圖15-3所示。下面從Android系統(tǒng)啟動過程加載SD卡、系統(tǒng)運行過程中加載SD卡、系統(tǒng)應用程序訪問SD卡三個方面簡要分析SD卡的訪問機制。

圖15-3訪問SD卡機制

1)系統(tǒng)啟動加載SD卡

Android系統(tǒng)啟動后，內(nèi)核啟動的第一個用戶級進程為init進程。init進程讀取system/core/rootdir/init.rc文件，獲得需要啟動的服務列表，從列表中依次啟動服務子進程。其中，init會啟動Vold服務，init.rc文件中啟動Vold的代碼如以下的代碼片段1所示，開機過程中SD卡的mount過程在Vold服務中實現(xiàn)。Linux系統(tǒng)中的Udev進程是用戶空間的進程，主要功能是提供一種基于用戶空間的動態(tài)設備節(jié)點管理和命名的解決方案。而在Android系統(tǒng)中，用Vold進程取代Udev進程。Android系統(tǒng)中Vold(VolumeDameon)進程的主要功能是用來掛載、管理USB存儲設備和SD卡設備。

如圖15-3所示，Vold通過process_config()函數(shù)讀取并解析SD卡的配置文件system/core/rootdir/etc/vold.fstab。

dev_mount代表掛載格式，sdcard代表掛載標簽，/mnt/sdcard代表掛載點，auto代表自動掛載。解析完該文件之后，process_config()函數(shù)通過以下的代碼片段2來實例化DirectVolume類實現(xiàn)SD卡的掛載。至此完成了啟動系統(tǒng)時加載SD卡的過程。

2)系統(tǒng)在運行過程中加載SD卡

在Android手機通過USB接口連接PC對SD卡中的文件資源進行拷貝時，會出現(xiàn)Android系統(tǒng)在開機狀態(tài)下對SD卡的mount和unmont操作，此過程屬于外設的熱插拔。SD卡的熱插拔也由Vold服務提供支持。Vold服務基于sysfs，sysfs為內(nèi)核與用戶層的通信提供全新的方式，并將該方式加以規(guī)范。如圖15-3所示，內(nèi)核檢測到有新的設備接入到系統(tǒng)，即為之加載相應的驅(qū)動程序。

sysfs機制將新設備的狀態(tài)通過uevent通知給Vold進程，Vold的NetlinkManager監(jiān)聽到Kernel層上報的uevent事件并對其進行解析和處理，通過CommandListener向Framework層的NativeDaemonConnector類發(fā)送相應通知，F(xiàn)ramework層再對收到的通知進行解析、判斷和傳遞，最后將新設備的狀態(tài)廣播通知給應用層，應用層收到廣播后進行更新UI等操作。

3)應用程序訪問過程中加載SD卡文件系統(tǒng)

由于SD卡使用的是FAT32(FileAllocationTable)文件系統(tǒng)，所以單獨的SD卡沒有訪問權(quán)限控制。但是Android系統(tǒng)的應用程序要訪問SD卡必須獲得Android系統(tǒng)的授權(quán)，應用開發(fā)者需要在應用程序的AndroidManifest.xml文件中加入如以下代碼片段3所示的權(quán)限代碼。

Android系統(tǒng)對于SD卡的整個文件系統(tǒng)只有訪問與不能訪問的權(quán)限控制，而某個應用程序產(chǎn)生的文件并沒有類似內(nèi)部SQLite數(shù)據(jù)的sandbox機制，即只要申請到訪問SD卡的權(quán)限即可任意讀取、篡改SD卡里的大部分文件。SD卡的存儲機制存在巨大的安全隱患，如圖15-4所示。AppA、AppB、AppC等應用程序在運行過程中產(chǎn)生自己的文件FileA、FileB、FileC，但是惡意程序Malwares只要申請了訪問SD卡的權(quán)限就可以訪問并篡改該文件，容易造成用戶的照片、記事本等隱私數(shù)據(jù)的泄露。由此可見，Android系統(tǒng)SD卡中的文件系統(tǒng)安全機制極為薄弱，研究對SD卡中隱私文件的保護有著重要的實用價值。

圖15-4

SD卡存儲機制的安全隱患

4)

AndroidSD卡訪問機制缺陷

由以上分析可知，Android系統(tǒng)SD卡文件訪問控制權(quán)限粒度較大，應用程序存入SD卡的外部文件容易暴露。而開發(fā)者不會對自己的外部文件進行保護，即使對該文件進行保護處理也必須由開發(fā)者利用自己的方式來實現(xiàn)保護。該機制無疑增加了開發(fā)者保障文件安全的成本，也讓SD卡的文件保護陷入了尷尬局面——沒有系統(tǒng)級文件保護機制的支持。應用程序的文件保護或沒有，或各應用程序的保護方式雜亂無章、效率低下，系統(tǒng)難以對其進行高效的統(tǒng)一管理和維護。

15.2.2安裝時期權(quán)限改進

用戶如果想安裝并使用該應用程序的功能，就必須對應用程序所申請的全部權(quán)限進行授權(quán)，如果拒絕授權(quán)，則應用程序包安裝器將拒絕安裝該應用。因此，Nauman等人提出了一個細粒度的Android使用控制模型，允許用戶準確地指定設備中的哪些資源允許被訪問，而哪些該應用程序所申請的權(quán)限不允許被授權(quán)。這些決策還能夠基于運行時期的限制，比如在某些特定的時間、設備所在的地點或者一天中短信發(fā)送的最大數(shù)量等。通過修改應用程序包安裝器實現(xiàn)了他們的方案，并可為用戶提供容易使用的策略定制客戶端。

Android權(quán)限機制是在安裝時期確定的，不能根據(jù)運行時環(huán)境的不同動態(tài)修改應用程序訪問資源的能力。比如用戶在某個秘密的場合下，所有應用程序的連接互聯(lián)網(wǎng)、錄音等權(quán)限都應該是不能授予的。對此，Conti等人提出了CREPE，這是一個根據(jù)上下文(如位置、時間、溫度、噪聲、光強等因素)來實施細粒度訪問策略的訪問控制系統(tǒng)。

由于Android已有的權(quán)限機制缺少對已安裝的應用程序的保護，因此該權(quán)限機制設計上的疏忽容易使惡意程序利用已安裝應用程序的權(quán)限完成權(quán)限擴大(權(quán)限提升攻擊)。Saint為開發(fā)者提供了更為細致的安全策略限制，使已安裝的應用程序免遭其他惡意程序的利用。Saint使得應用程序開發(fā)者可以從應用程序的角度來具體聲明允許進出交互的應用程序。具體來講該機制定義了安裝時和運行時的策略。

(1)在應用程序安裝時的權(quán)限分配。允許聲明權(quán)限P的應用程序根據(jù)應用簽名以及配置等條件，依據(jù)開發(fā)者自定義的安全策略對本應用的對外接口實施保護。

(2)在運行時的策略中，該機制在Android中間件中額外設計調(diào)用管理器，運行時策略根據(jù)應用程序簽名、配置以及運行上下文等條件提供調(diào)用者和被調(diào)用者的策略，允許應用程序限制哪些應用程序可以訪問它的接口以及它可以與哪些應用程序接口交互。

15.2.3運行時期權(quán)限改進

Android在安裝時期完成對不同應用程序的權(quán)限授權(quán)，在運行期間對應用程序發(fā)起的敏感API訪問進行訪問控制。Android權(quán)限框架是由Android中間件提供的，包含一個對進程間通信(Android系統(tǒng)中的組件間通信)實施強制訪問控制的引用監(jiān)控器。安全敏感的API受在安裝時期賦予的權(quán)限的保護，然而Android權(quán)限機制存在權(quán)限提升攻擊的缺陷。

權(quán)限提升攻擊是指一個擁有少量權(quán)限的應用程序(沒有特權(quán)的調(diào)用者)允許訪問擁有更多權(quán)限的應用程序的組件(有特權(quán)的被調(diào)用者)，攻擊演示如圖15-5所示。由于未被賦予相應的權(quán)限P1，所以應用程序A沒有權(quán)限去訪問位置信息，但是應用程序A可以通過其他方式訪問到位置信息，如通過應用程序B的組件(2跳)。由于應用程序A無需權(quán)限即可訪問應用程序B，并且應用程序B具有訪問位置資源的權(quán)限P1，所以應用程序A可以通過與應用程序B的交互來達到訪問位置信息的目的。

圖15-5權(quán)限提升攻擊演示

QUIRE是Android安全的擴展，提供輕量級的來源系統(tǒng)以防止混淆代理人攻擊，是由Dietz等人基于Java堆棧檢查的原理設計的。為了確定安全關(guān)鍵性操作的源頭，QUIRE跟蹤并記錄了ICC調(diào)用鏈，在源頭應用程序沒有包括相應權(quán)限的情況下拒絕請求。該方法為應用程序開發(fā)者提供了訪問控制原型。然而，QUIRE不能解決由共謀的惡意應用程序帶來的權(quán)限提升攻擊。IPCinspection則縮小了被調(diào)用應用程序的權(quán)限，若某應用程序接收到來自其他應用程序的調(diào)用(如綁定服務、接收廣播的消息、打開活動等)，則將被調(diào)用者的權(quán)限減少為調(diào)用者與被調(diào)用者權(quán)限的交集，但是它也無法防御共謀帶來的權(quán)限提升。

之前的方案(QUIRE、IPCinspection)僅解決混淆代理人攻擊帶來的問題，Bugeiel等人針對使用所有通信信道帶來的權(quán)限提升攻擊問題，提出了XManDroid以及TrustDroid。XManDroid是一個依靠系統(tǒng)策略檢測和阻止Android應用程序權(quán)限代理攻擊的方案，能夠?qū)崿F(xiàn)對通過Android系統(tǒng)服務或內(nèi)容提供者建立秘密通道的有效檢測。在運行時，XManDroid監(jiān)控應用程序之間發(fā)起交互請求，并將通信雙方應用程序包含的權(quán)限根據(jù)策略數(shù)據(jù)庫中定義的策略進行判定，以確定是否可以發(fā)起通信。

XManDroid使用圖來表示系統(tǒng)，圖的節(jié)點表示應用程序，無向邊表示被授權(quán)的組件間通信，形式化描述應用程序間通信的過程。TrustDroid在XManDroid的基礎上增加了內(nèi)核級別的模塊，以防止通過其他信道完成應用程序間通信，當應用程序執(zhí)行文件或socket操作時，該操作將被增加的Linux內(nèi)核下的強制訪問控制模塊進行處理。TrustDroid通過部署TOMOYOLinux實現(xiàn)內(nèi)核級別的強制訪問控制。

15.3通過iOS安全機制加強防護

15.3.1iOS安全基礎

iOS安全機制除了采用沙箱技術(shù)外，還采用安全啟動鏈、代碼簽名、地址空間布局隨機化及數(shù)據(jù)保護等技術(shù)。下面分別對這四種技術(shù)進行介紹。

1.安全啟動鏈

iOS系統(tǒng)啟動過程的每一個步驟都包含由Apple簽名加密的組件，以此保證該步驟正確、完整，且僅當驗證信任鏈后步驟才得以進行。加密的部件包括bootloader、kernel、kernelextensions和basebandfirmware。

該安全啟動鏈在確保系統(tǒng)最底層的軟件不會被非法篡改的同時確保了iOS啟動只會在經(jīng)過驗證的iOS設備上運行。如果該啟動過程中的任何一個步驟驗證出現(xiàn)問題，啟動過程就會終止并強制系統(tǒng)進入恢復模式(RecoveryMode)，當BootROM都無法成功啟動LLB時，設備將直接進入DFU(DeviceFirmwareUpgrade)工廠模式。

2.代碼簽名

為確保應用程序不被非法篡改，iOS要求所有執(zhí)行代碼必須經(jīng)過由Apple頒發(fā)的證書簽名。代碼簽名機制受控于強制性訪問控制框架(MandatoryAccessControlFramework，MACF)，該系統(tǒng)框架由FreeBSD的TrustedBSDMACFramework繼承而來。MACF允許有追加的訪問控制策略，并且新的策略在框架啟動時被載入。

3.地址空間布局隨機化

地址空間布局隨機化(ASLR)是從iOS

4.3開始引入的安全機制，作用是隨機化每次程序在內(nèi)存中加載的地址空間，將重要的數(shù)據(jù)(比如操作系統(tǒng)內(nèi)核)配置到惡意代碼難以猜到的內(nèi)存位置，令攻擊者難以攻擊。

4.數(shù)據(jù)保護

Apple在iOS中引入數(shù)據(jù)保護(DataProtection)技術(shù)來保護存儲在設備Flash內(nèi)存上的用戶數(shù)據(jù)。

不同的保護類是通過一個層次結(jié)構(gòu)的密鑰體系實現(xiàn)的。在密鑰體系中，每一個密鑰都是通過其他的密鑰和數(shù)據(jù)繼承而來的。部分跟數(shù)據(jù)加密有關(guān)的體系如圖15-6所示。在該結(jié)構(gòu)的根部是UID密鑰與用戶密碼，在上面章節(jié)里已經(jīng)提到UID是設備唯一的、存在于板載加密運算器芯片里的數(shù)據(jù)，不可被直接讀取，但可以用它來進行加密解密數(shù)據(jù)。每當設備被解鎖后，設備密碼會經(jīng)過改進的PBKDF2算法進行多次加密運算以生成設備密碼密鑰(PasscodeKey)，設備密碼密鑰會一直存在于內(nèi)存中直到用戶再次鎖定設備才會被銷毀。

UID密鑰還被用來加密靜態(tài)字符串以生成設備密鑰(DeviceKey)，設備密鑰用來加密各種代表文件相關(guān)的保護類的類密鑰(ClassKey)。有一些類密鑰也會同時經(jīng)過設備密碼密鑰加密，這樣能保證該類密鑰只有在設備被解鎖時才有效。數(shù)據(jù)保護應用程序接口(DataProtectionAPI)是用來讓應用程序聲明文件或Keychain項目在何時被加密，并通過向現(xiàn)有的應用程序接口里添加新定義的保護類標記使加密后的文件或者Keychain項目隨時能重新被解密。

圖15-6同數(shù)據(jù)加密有關(guān)的體系

要對某個文件進行保護，應用程序需要使用NSFileManager類對NSFileProtectKey設置一個值，所有支持的值及其代表的含義如表15-1所示。

15.3.2靜態(tài)的權(quán)限評估

權(quán)限分析包括應用程序中傳統(tǒng)的Unix文件系統(tǒng)權(quán)限分析和entitlements分析。由于IPA安裝的程序處于沙箱體系中，因此只有mobile權(quán)限。而DEB程序解包后可用shell命令檢查文件系統(tǒng)權(quán)限，分析安裝腳本中安裝時是否對程序或者目錄權(quán)限進行了更改，另外從程序的類型可直接得出程序可能具有的權(quán)限。iOS的應用程序取得root權(quán)限有兩個方式，一個是通過設置Unix標記位，另一個是權(quán)限繼承。

使用ldid或者codesign命令能夠?qū)С鰬贸绦騟ntitlements的XML文件并分析其中的權(quán)限鍵值對，與具體的權(quán)限功能一一對應后導出詳細權(quán)限表，如應用程序是否具有發(fā)送短信的權(quán)限，應用程序是否能安裝IPA程序等。權(quán)限分析后將得到應用程序的權(quán)限列表。

15.3.3動態(tài)的API調(diào)用分析

通過對應用程序執(zhí)行文件進行反編譯處理，可從中解析得到應用程序可能調(diào)用的API，但是單從靜態(tài)分析并不能準確得到在應用程序運行過程中該API被調(diào)用的順序以及場景。通過配置MobileSubstrate的動態(tài)庫，可以hook所有感興趣的API并得到在程序真實運行狀態(tài)下此類API的調(diào)用記錄序列，記錄包括API的名稱、傳入的參數(shù)和調(diào)用時間等信息。通過記錄可生成API調(diào)用時序圖以及控制流程圖，從而進一步還原應用程序的真實行為意圖。

下面使用CaptainHook框架對應用程序關(guān)鍵的API進行hook并記錄下該調(diào)用的詳細信息。具體實現(xiàn)如下：

(1)聲明要hook的類

(2)在CHOptimizedMethod()函數(shù)中配置具體要hook的函數(shù)。對于類方法使用CHOptimizedClassMethod()函數(shù)。對CHOptimizedMethod()定義如下：argn是預hook函數(shù)的參數(shù)個數(shù)；obj*?是指向hook到的函數(shù)所在具體對象的指針；ret_type是函數(shù)返回值類型；ClassToHook是函數(shù)所在類；fun_name1和fun_name2等是各個函數(shù)的名稱；函數(shù)名稱對應的參數(shù)和參數(shù)類型分別是arg和arg_type。

(3)配置MobileLoader的過濾器并將hook動態(tài)庫加載到指定程序進程中，MobileLoader的過濾器位于?/Library/MobileSubstrate/DynamicLibraries/?目錄下與hook動態(tài)庫dylib文件同名的plist文件中。

其中過濾器的配置依賴于應用程序的bundleid。對于一些不具有bundleid的程序來說，可通過應用程序執(zhí)行文件名稱來配置。上述過濾器等配置完成后，當應用程序AppToTest試圖發(fā)送短信時，“-(BOOL)

sendSMS

With

Text:serviceCenter:toAddress:”函數(shù)會被調(diào)用并被攔截，與此同時調(diào)用發(fā)生的時間以及描述信息則會被記錄到數(shù)據(jù)庫中，最后生成評估報告供研究者分析。

15.4基于權(quán)限的應用程序安全性分析

15.4.1基于權(quán)限的Android惡意程序檢測

Android權(quán)限機制相對于傳統(tǒng)權(quán)限機制所具有的優(yōu)點。Android權(quán)限機制本身設計的一個優(yōu)點在于警示用戶潛在的安全威脅，即權(quán)限潛在反映應用程序的安全性。比如應用程序若申請并被授權(quán)接收短信的權(quán)限，那么該程序就具備在運行期間訪問用戶短信數(shù)據(jù)的能力，或者說該程序會在運行期間訪問用戶的短信數(shù)據(jù)，這可能會帶來用戶短信數(shù)據(jù)泄露。

Kirin根據(jù)權(quán)限組合是否存在安全威脅設計并實現(xiàn)了基于權(quán)限的惡意程序分析框架，該框架由Enck等人最先提出來。他們發(fā)現(xiàn)Android在安裝應用程序時權(quán)限通知了用戶應用程序能夠訪問哪些資源，這可用于檢測要求危險權(quán)限組合的程序。(具體來說，如要求電話狀態(tài)、錄音和互聯(lián)網(wǎng)連接的權(quán)限組合被認為是危險的，因為申請這種權(quán)限組合的應用程序存在成為監(jiān)聽用戶通話情況的間諜軟件的可能性。)類似地，同時申請訪問位置資源、網(wǎng)絡以及開機自啟動權(quán)限的應用程序被認為是跟蹤用戶位置的惡意應用程序。

Sanz等人以權(quán)限、字符串、程序評分以及程序大小等應用程序信息作為特征，使用機器學習的方法對應用程序按照其風險進行了自動分類。Zhang等人從權(quán)限使用的視角設計了一個惡意程序的動態(tài)分析平臺VetDroid，該平臺能夠有效構(gòu)建出權(quán)限使用行為流程。Kirin僅通過權(quán)限標記的組合來判斷程序是否具有安全威脅，而VetDroid則通過動態(tài)分析跟蹤程序指令來判斷具有安全威脅API的組合的使用情況，并集中分析了應用程序如何通過使用權(quán)限的方式來訪問系統(tǒng)資源以及在這些權(quán)限敏感的資源之后如何被應用程序利用。

安全分析者能夠通過權(quán)限使用行為流程檢查應用程序內(nèi)部的敏感行為。Frank等人對Android以及Facebook應用程序中的權(quán)限請求模式進行了統(tǒng)計分析，并且建立模型分析了權(quán)限請求模式與應用程序評分之間的關(guān)系。

除此之外，一些研究者通過分析應用程序不需要申請的權(quán)限來判斷應用程序是否存在安全威脅。如果應用程序額外申請了一部分權(quán)限，可能是因為開發(fā)者的疏忽，或是利用不需要的權(quán)限實現(xiàn)惡意行為。

有研究者設計了基于權(quán)限可信性的異常程序分析框架。該框架認為應用程序商店中的程序描述文本反映了程序預期的功能，而程序申請的權(quán)限則反映了程序的真實行為。對于良性程序，預期的功能和權(quán)限是一一對應的，如果某個申請使用的權(quán)限不能通過描述文本體現(xiàn)出來，那么該權(quán)限被認為是不可信的。具體來講，研究者通過應用程序商店中的程序描述文本以及所申請權(quán)限的對應關(guān)系設計出了異常程序檢測系統(tǒng)，并為應用程序描述文本和權(quán)限之間建立分析模型，從而實現(xiàn)了自動化地檢測出不可信權(quán)限，進而判斷程序潛在的安全威脅。與此研究工作類似，Pandita等人使用詞性標注、關(guān)鍵詞提取等方式對描述文本與權(quán)限之間的關(guān)系進行了自動分析。

15.4.2Android應用程序中權(quán)限申請缺陷檢測

本書相關(guān)章節(jié)中提到為防范權(quán)限提升攻擊在Android操作系統(tǒng)運行時期進行的相關(guān)研究工作，權(quán)限提升攻擊的另一個主要原因是一些Android應用程序中存在權(quán)限泄露問題，惡意軟件可能會利用存在權(quán)限泄露情況的應用程序完成權(quán)限的提升。

Grace等人對Android設備中預先安裝的應用程序進行了顯式