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

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

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

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

DAC基于主體的身份或者主體所屬的組別來限制對象的訪問權(quán)限，主要技術(shù)特征是主體具有的訪問權(quán)限能夠通過繼承或者賦予被傳遞給另外一個(gè)主體。這意味著訪問權(quán)限具有傳遞鏈條，因此，當(dāng)一個(gè)程序中發(fā)生安全事件時(shí)，會危及系統(tǒng)，使得DAC在木馬面前特別脆弱。目前，最著名的DAC實(shí)現(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í)行時(shí)生成文件file2且在程序中設(shè)置新的訪問列表，即用戶A對file2的寫權(quán)限和用戶C對file2的讀權(quán)限。用戶C將惡意程序偽裝成合法程序發(fā)給用戶A，當(dāng)程序被A運(yùn)行時(shí)，程序就具有了A的訪問權(quán)限。在程序邏輯中拷貝file1到file2，用戶C就竊取了file1的內(nèi)容。如果用戶A是系統(tǒng)管理員，攻擊者C會獲取最大的權(quán)限。

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

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

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

圖15-1

iOS中的沙箱

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

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

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

(2)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

15.2.1Android安全機(jī)制基礎(chǔ)

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

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

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

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

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

從代碼可知，“android.permission.

BLUETOOTH

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

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

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

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

碼包括安裝路徑、版本號、簽名證書和每個(gè)包的權(quán)限。上層的管理通過包管理器及該數(shù)據(jù)庫進(jìn)行交互。由于組件無法在運(yùn)行時(shí)修改權(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)限機(jī)制的實(shí)現(xiàn)包括安裝時(shí)期以及運(yùn)行時(shí)期兩部分。用戶在安裝時(shí)期完成對權(quán)限的授權(quán)工作，在程序運(yùn)行期間Android系統(tǒng)通過引用監(jiān)視器判斷應(yīng)用程序是否具備使用特定功能的權(quán)限。關(guān)于Android權(quán)限機(jī)制改進(jìn)的相關(guān)研究工作是從安裝時(shí)期及運(yùn)行時(shí)期兩個(gè)角度展開的。

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

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

圖15-3訪問SD卡機(jī)制

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

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

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

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

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

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

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

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

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

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

圖15-4

SD卡存儲機(jī)制的安全隱患

4)

AndroidSD卡訪問機(jī)制缺陷

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

15.2.2安裝時(shí)期權(quán)限改進(jìn)

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

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

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

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

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

15.2.3運(yùn)行時(shí)期權(quán)限改進(jìn)

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

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

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

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

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

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

15.3通過iOS安全機(jī)制加強(qiáng)防護(hù)

15.3.1iOS安全基礎(chǔ)

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

1.安全啟動鏈

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

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

2.代碼簽名

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

3.地址空間布局隨機(jī)化

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

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

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

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

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

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

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

要對某個(gè)文件進(jìn)行保護(hù)，應(yīng)用程序需要使用NSFileManager類對NSFileProtectKey設(shè)置一個(gè)值，所有支持的值及其代表的含義如表15-1所示。

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

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

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

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

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

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

(1)聲明要hook的類

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

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

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

sendSMS

With

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

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

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

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

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

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

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

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

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

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

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

Grace等人對Android設(shè)備中預(yù)先安裝的應(yīng)用程序進(jìn)行了顯式