- 相關(guān)推薦
如何用fuzz技術(shù)挖掘Android漏洞 Android漏洞該如何防御
Android系統(tǒng)服務(wù)即由Android提供的各種服務(wù)，比如WIFI，多媒體，短信等等，幾乎所有的Android應(yīng)用都要使用到系統(tǒng)服務(wù)。系統(tǒng)服務(wù)在為用戶提供便利的同時，也存在著一些風(fēng)險。以下是小編為大家搜索整理的如何用fuzz技術(shù)巧妙的挖掘Android漏洞 Android漏洞該如何防御，希望能給大家?guī)韼椭?更多精彩內(nèi)容請及時關(guān)注我們應(yīng)屆畢業(yè)生考試網(wǎng)!
比如，如果一個應(yīng)用獲取到了系統(tǒng)服務(wù)中的短信服務(wù)，那么他就可能會查看用戶的短信信息，用戶隱私就有可能暴露。此外，如果在使用系統(tǒng)服務(wù)的過程中，使用了異常的外部數(shù)據(jù)，有可能會導(dǎo)致系統(tǒng)服務(wù)崩潰，甚至是遠(yuǎn)程代碼執(zhí)行，內(nèi)存破壞等等嚴(yán)重后果。因此Android系統(tǒng)服務(wù)的安全問題需要重視。
在以前的工作發(fā)現(xiàn)主要的漏洞和攻擊主要包括特權(quán)提升攻擊，惡意軟件攻擊，重打包，組件劫持攻擊等類型。盡管安全研究人員已經(jīng)針對Android上層app的漏洞挖掘做了大量的工作，但是針對Android系統(tǒng)服務(wù)的漏洞挖掘一直被安全人員所普遍忽視。
通過Binder機制可以對Android的系統(tǒng)服務(wù)漏洞進行深入的挖掘。本文基于Android的Binder機制編寫了一套漏洞挖掘框架。
下面我們首先介紹一下先驗知識。
1 基礎(chǔ)知識1.1 Android的Binder機制
1.1.1 Binder概述
Binder其實也不是Android提出來的一套新的進程間通信機制，它是基于OpenBinder來實現(xiàn)的。Binder是一種進程間通信機制，它是一種類似于COM和CORBA分布式組件架構(gòu)，是提供遠(yuǎn)程過程調(diào)用(RPC)功能。
什么是Binder
直觀來說，Binder是Android中的一個類，它繼承了IBinder接口 從IPC角度來說，Binder是Android中的一種跨進程通信方式，Binder還可以理解為一種虛擬的物理設(shè)備，它的設(shè)備驅(qū)動是/dev/binder，該通信方式在Linux中沒有 從Android Framework角度來說，Binder是ServiceManager連接各種Manager(ActivityManager、WindowManager，etc)和相應(yīng)ManagerService的橋梁 從Android應(yīng)用層來說，Binder是客戶端和服務(wù)端進行通信的媒介，當(dāng)你bindService的時候，服務(wù)端會返回一個包含了服務(wù)端業(yè)務(wù)調(diào)用的Binder對象，通過這個Binder對象，客戶端就可以獲取服務(wù)端提供的服務(wù)或者數(shù)據(jù)，這里的服務(wù)包括普通服務(wù)和基于AIDL的服務(wù)
在Android系統(tǒng)的Binder機制中，由一系統(tǒng)組件組成，分別是Client、Server、Service Manager和Binder驅(qū)動程序，其中Client、Server和Service Manager運行在用戶空間，Binder驅(qū)動程序運行內(nèi)核空間，如圖1-1所示。Binder就是一種把這四個組件粘合在一起的粘結(jié)劑，其中核心組件便是Binder驅(qū)動程序了，Service Manager提供了輔助管理的功能，Client和Server正是在Binder驅(qū)動和Service Manager提供的基礎(chǔ)設(shè)施上，進行Client-Server之間的通信。Service Manager和Binder驅(qū)動已經(jīng)在Android平臺中實現(xiàn)好，開發(fā)者只要按照規(guī)范實現(xiàn)自己的Client和Server組件就可以了。
這里寫圖片描述
圖1-1 Binder架構(gòu)圖
1.1.2 為什么使用Binder
Android中有大量的CS(Client-Server)應(yīng)用方式，這就要求Android內(nèi)部提供IPC方法，而linux所支持的進程通信方式有兩個問題：性能和安全性。
目前l(fā)inux支持的IPC包括傳統(tǒng)的管道，System V IPC(消息隊列/共享內(nèi)存/信號量)，以及socket，但只有socket支持Client-Server的通信方式，由于socket是一套通用的網(wǎng)絡(luò)通信方式，其傳輸效率低下切有很大的開銷，比如socket的連接建立過程和中斷連接過程都是有一定開銷的。消息隊列和管道采用存儲-轉(zhuǎn)發(fā)方式，即數(shù)據(jù)先從發(fā)送方緩存區(qū)拷貝到內(nèi)核開辟的緩存區(qū)中，然后再從內(nèi)核緩存區(qū)拷貝到接收方緩存區(qū)，至少有兩次拷貝過程。共享內(nèi)存雖然無需拷貝，但控制復(fù)雜，難以使用。
在安全性方面，Android作為一個開放式，擁有眾多開發(fā)者的的平臺，應(yīng)用程序的來源廣泛，確保智能終端的安全是非常重要的。終端用戶不希望從網(wǎng)上下載的程序在不知情的情況下偷窺隱私數(shù)據(jù)，連接無線網(wǎng)絡(luò)，長期操作底層設(shè)備導(dǎo)致電池很快耗盡等等。傳統(tǒng)IPC沒有任何安全措施，完全依賴上層協(xié)議來確保。首先傳統(tǒng)IPC的接收方無法獲得對方進程可靠的UID/PID(用戶ID/進程ID)，從而無法鑒別對方身份。Android為每個安裝好的應(yīng)用程序分配了自己的UID，故進程的UID是鑒別進程身份的重要標(biāo)志。使用傳統(tǒng)IPC只能由用戶在數(shù)據(jù)包里填入UID/PID，但這樣不可靠，容易被惡意程序利用。可靠的身份標(biāo)記只有由IPC機制本身在內(nèi)核中添加。其次傳統(tǒng)IPC訪問接入點是開放的，無法建立私有通道。比如命名管道的名稱，system V的鍵值，socket的ip地址或文件名都是開放的，只要知道這些接入點的程序都可以和對端建立連接，不管怎樣都無法阻止惡意程序通過猜測接收方地址獲得連接。
基于以上原因，Android需要建立一套新的IPC機制來滿足系統(tǒng)對通信方式，傳輸性能和安全性的要求，這就是Binder。Binder基于 Client-Server通信模式，傳輸過程只需一次拷貝，為發(fā)送發(fā)添加UID/PID身份，既支持實名Binder也支持匿名Binder，安全性高。
1.1.3 Aidl機制
AIDL (Android Interface Definition Language) 是一種IDL 語言，用于生成可以在Android設(shè)備上兩個進程之間進行進程間通信(interprocess communication, IPC)的代碼。如果在一個進程中(例如Activity)要調(diào)用另一個進程中(例如Service)對象的操作，就可以使用AIDL生成可序列化的參數(shù)。
AIDL IPC機制是面向接口的，像COM或CORBA一樣，但是更加輕量級。它是使用代理類在客戶端和服務(wù)端傳遞數(shù)據(jù)。只有你允許客戶端從不同的應(yīng)用程序為了進程間的通信而去訪問你的service，以及想在你的service處理多線程。如果不需要進行不同應(yīng)用程序間的并發(fā)通信(IPC)，或者你想進行IPC，但不需要處理多線程的。使用AIDL前，必須要理解如何綁定service。
AIDL IPC機制是面向接口的，像COM或Corba一樣，但是更加輕量級。它是使用代理類在客戶端和實現(xiàn)端傳遞數(shù)據(jù)。
1.2 Fuzz技術(shù)
模糊測試定義為“通過向應(yīng)用提供非預(yù)期的輸入并監(jiān)控輸出中的異常來發(fā)現(xiàn)軟件中的故障(faults)的方法”。典型而言,模糊測試?yán)米詣踊蚴前胱詣踊姆椒ㄖ貜?fù)地向應(yīng)用提供輸入。顯然,上述定義相當(dāng)寬泛,但這個定義闡明了模糊測試的基本概念。
用于模糊測試的模糊測試器(fuzzer)分為兩類:一類是基于變異(mutation-based)的模糊測試器,這一類測試器通過對已有的數(shù)據(jù)樣本進行變異來創(chuàng)建測試用例;而另一類是基于生成(generation-based)的模糊測試器,該類測試器為被測系統(tǒng)使用的協(xié)議或是文件格式建模,基于模型生成輸入并據(jù)此創(chuàng)建測試用例。這兩種模糊測試器各有其優(yōu)缺點
模糊測試各階段
采用何種模糊測試方法取決于眾多因素。沒有所謂的一定正確的模糊測試方法,決
定采用何種模糊測試方法完全依賴于被測應(yīng)用、測試者擁有的技能、以及被進行模糊測
試的數(shù)據(jù)的格式。但是,不論對什么應(yīng)用進行模糊測試,不論采用何種模糊測試方法,
模糊測試執(zhí)行過程都包含相同的幾個基本階段。
<1>確定測試目標(biāo)
只有有了明確的測試目標(biāo)后,我們才能決定使用的模糊測試工具或方法。如果要在安全審計中對一個完全由內(nèi)部開發(fā)的應(yīng)用進行模糊測試,測試目標(biāo)的選擇必須小心謹(jǐn)慎。但如果是要在第三方應(yīng)用中找到安全漏洞,測試目標(biāo)的選擇就更加靈活。要決定第三方應(yīng)用模糊測試的測試目標(biāo),首先需要參考該第三方應(yīng)用的供應(yīng)商歷史上曾出現(xiàn)過的安全漏洞。在一些典型的安全漏洞聚合網(wǎng)站如 SecurityFocus 18 和 Secunia 19 上可以查找到主要軟件供應(yīng)商歷史上曾出現(xiàn)過的安全漏洞。如果某個供應(yīng)商的歷史記錄很差,很可能意味著這個供應(yīng)商的代碼實踐 (code practice)能力很差,他們的產(chǎn)品有仍有很大可能存在未被發(fā)現(xiàn)的安全漏洞。除應(yīng)用程序外,應(yīng)用包含的特定文件或庫也可以是測試目標(biāo)。
如果需要選擇應(yīng)用包含的特定文件或者庫作為測試目標(biāo),你可以把注意力放在多個應(yīng)用程序之間共享的那些二進制代碼上。因為如果這些共享的二進制代碼中存在安全漏洞,將會有非常多的用戶受到影響,因而風(fēng)險也更大。
<2>.確定輸入向量
幾乎所有可被利用的安全漏洞都是因為應(yīng)用沒有對用戶的輸入進行校驗或是進行必要的非法輸入處理。是否能找到所有的輸入向量(input vector)是模糊測試能否成功的關(guān)鍵。如果不能準(zhǔn)確地找到輸入向量,或是不能找到預(yù)期的輸入值,模糊測試的作用就會受到很大的局限。有些輸入向量是顯而易見的,有些則不然。尋找輸入向量的原則是:從客戶端向目標(biāo)應(yīng)用發(fā)送的任何東西,包括頭(headers)、文件名(file name)、環(huán)
境變量(environment variables),注冊表鍵(registry keys),以及其他信息,都應(yīng)該被看做是輸入向量。所有這些輸入向量都可能是潛在的模糊測試變量。
<3>.生成模糊測試數(shù)據(jù)
一旦識別出輸入向量,就可以依據(jù)輸入向量產(chǎn)生模糊測試數(shù)據(jù)了。究竟是使用預(yù)先確定的值、使用基于存在的數(shù)據(jù)通過變異生成的值、還是使用動態(tài)生成的值依賴于被測應(yīng)用及其使用的數(shù)據(jù)格式。但是,無論選擇哪種方式,都應(yīng)該使用自動化過程來生成數(shù)據(jù)。
<4>.執(zhí)行模糊測試數(shù)據(jù)
該步驟緊接上一個步驟,正是在這個步驟,“模糊測試”變成了動詞。在該步驟中,一般會向被測目標(biāo)發(fā)送數(shù)據(jù)包、打開文件、或是執(zhí)行被測應(yīng)用。同上一個步驟一樣,這個步驟必須是自動化的。否則,我們就不算是真正在開展模糊測試。
<5>.監(jiān)視異常
一個重要但經(jīng)常容易被忽略的步驟是對異常和錯誤進行監(jiān)控。設(shè)想我們在進行一次模糊測試,在測試中,我們向被測的 Web 服務(wù)器發(fā)送了 10000 個數(shù)據(jù)包,最終導(dǎo)致了服務(wù)器崩潰。但服務(wù)器崩潰后,我們卻怎么也找不到導(dǎo)致服務(wù)器崩潰的數(shù)據(jù)包了。如果這種事真的發(fā)生了,我們只能說這個測試毫無價值。模糊測試需要根據(jù)被測應(yīng)用和所決定采用的模糊測試類型來設(shè)置各種形式的監(jiān)視。
<6>.判定發(fā)現(xiàn)的漏洞是否可能被利用
如果在模糊測試中發(fā)現(xiàn)了一個錯誤,依據(jù)審計的目的,可能需要判定這個被發(fā)現(xiàn)的錯誤是否是一個可被利用的安全漏洞。這種判定過程是典型的手工過程,需要操作者具有特定的安全知識。這個步驟不一定要由模糊測試的執(zhí)行者來進行,也可以交給其他人來進行。
2.漏洞挖掘思路
fuzz在協(xié)議和接口安全測試中比較簡單粗暴，試錯成本低。Fuzzing是一種基于缺陷注入的自動軟件測試技術(shù)。通過編寫fuzzer工具向目標(biāo)程序提供某種形式的輸入并觀察其響應(yīng)來發(fā)現(xiàn)問題，這種輸入可以是完全隨機的或精心構(gòu)造的。Fuzzing測試通常以大小相關(guān)的部分、字符串、標(biāo)志字符串開始或結(jié)束的二進制塊等為重點，使用邊界值附近的值對目標(biāo)進行測試。
2.1 fuzz的切入點和目標(biāo)
2.1.1 fuzz的切入點
為了更好的挖掘漏洞，選擇fuzz接口需要滿足這幾個要求：
1)這個接口是開放的，是可以被低權(quán)限進程調(diào)用的
2)這個接口距離fuzz目標(biāo)(系統(tǒng)服務(wù))比較接近，中間路徑最好透傳，這樣比較容易分析異常
3)從簡原則
根據(jù)上面的分析，BpBinder中的transact函數(shù)就是一個很好的fuzz接口，但這個函數(shù)在底層無法直接調(diào)用。
底層transact方法介紹
在c層中，BBinder::transact中會調(diào)用onTransact，這個onTransact才是真正處理業(yè)務(wù)的。需要注意的是，因為我們的binder實體在本質(zhì)上都是繼承于BBinder的，而且我們一般都會重載onTransact()函數(shù)，所以onTransact()實際上調(diào)用的是具體binder實體的onTransact()成員函數(shù)。也就是說，onTransact的具體實現(xiàn)一般在上層的binder實體，而不在BBinder。BBinder沒有實現(xiàn)一個默認(rèn)的onTransact()成員函數(shù)，所以在遠(yuǎn)程通信時，BBinder::transact()調(diào)用的onTransact()其實是Bnxxx或者BnInterface的某個子類的onTransact()成員函數(shù)，舉個例子，BnMediaRecorder中實現(xiàn)了一個onTransact函數(shù)，通過switch-case，根據(jù)不同code進行分發(fā)處理。
我們從BpBinder往上層找，很容易發(fā)現(xiàn)，Java層IBinder的transact函數(shù)最終調(diào)用到BpBinder，且參數(shù)是原封不動的“透傳”到底層，考慮到j(luò)ava層的可視化和擴展性，可以選擇IBinder的公有方法transact作為fuzz接口。
transact的四個參數(shù)介紹。我們可以構(gòu)造這四個參數(shù)進行測試。
code是int類型，指定了服務(wù)方法號
data是parcel類型，是發(fā)送的數(shù)據(jù)，滿足binder協(xié)議規(guī)則，下面會有詳述
reply也是parcel類型，是通信結(jié)束后返回的數(shù)據(jù)
flag是標(biāo)記位，0為普通RPC，需要等待，調(diào)用發(fā)起后處于阻塞狀態(tài)直到接收到返回，1為one-way RPC，表示“不需要等待回復(fù)的”事務(wù)，一般為無返回值的單向調(diào)用。
2.1.2fuzz的目標(biāo)
Binder其實是提供了一種進程間通信(IPC)的功能。這些系統(tǒng)服務(wù)，通過binder協(xié)議抽象出一個個的“接口”，供其他進程調(diào)用，是一個重要的潛在的攻擊面。如果沒有做好權(quán)限控制，會讓低權(quán)限的第三方應(yīng)用/病毒/木馬利用，后果不堪設(shè)想。
系統(tǒng)服務(wù)具有高權(quán)限，是我們需要重點關(guān)注的對象，而低權(quán)限進程(農(nóng)民)可以利用binder call去調(diào)用系統(tǒng)服務(wù)，從低權(quán)限到高權(quán)限，存在一個跨安全域的數(shù)據(jù)流，這里就是一個典型的攻擊界面。所以，我們選擇系統(tǒng)服務(wù)作為fuzz的目標(biāo)。
系統(tǒng)服務(wù)的分類
1.Binder體系的java服務(wù)(有Stub接口，也就是AIDL封裝)
2.Binder體系的Native服務(wù)
3.socket體系的init服務(wù)(通常見于init.rc)
4.其他服務(wù)
2.2 fuzz引擎
fuzz引擎實際是構(gòu)造transact(int code，Parcel data，Parcel reply，int Flags)函數(shù)的四個函數(shù)，然后調(diào)用Ibinder.transact()來調(diào)用系統(tǒng)服務(wù)。
2.2.1如何獲取Ibinder對象
我們要取到對端的IBinder對象，才可以調(diào)用這個服務(wù)。系統(tǒng)其實有一些隱藏API可以利用。先通過反射出ServiceManager(hide屬性)中的listServices獲取所有運行的服務(wù)名稱。獲取到String類型的服務(wù)名稱后，再反射getService獲取對應(yīng)的服務(wù)IBinder對象。
2.2.2 code如何生成
code也稱為TransactionID，標(biāo)定了服務(wù)端方法號。
每個服務(wù)對外定義的方法都會分配方法號，而且是有規(guī)律的，第一個服務(wù)方法code使用1，第二個是2，，第三個使用3，依次類推，如果有N個方法，就分別分配1-N個連續(xù)的服務(wù)號。
對于Java服務(wù)，必定有Stub類，可以通過反射出mInterfaceToken+”$Stub”類中所有成員屬性，其中以”TRANSACTION_”開頭的int型就是該方法對應(yīng)的。
2.2.3 data如何構(gòu)造
data由“RPC header+參數(shù)1+參數(shù)2+….”來構(gòu)成的。但我們不需要自己去構(gòu)造RPC header，直接調(diào)用writeInterfaceToken函數(shù)，傳入interface name就可以了。interface name是接口名稱，只要取得IBinder對象，就可以直接getInterfaceDescriptor來獲取interface name，也就是接口方法的描述符。對于Java層服務(wù)的方法，可以通過反射獲取method對象，然后用getParameterTypes獲取所有的類型。
2.2.4 fuzz系統(tǒng)和邏輯設(shè)計
一共分為四個部分：
1)測試數(shù)據(jù)產(chǎn)生器產(chǎn)生器就是用上述方法產(chǎn)生transact需要用到的的四個參數(shù)
2)fuzz引擎用于執(zhí)行具體的transact調(diào)用過程，調(diào)用ibinder的transact()函數(shù)
3)監(jiān)視器用于監(jiān)控fuzz結(jié)果和異常
4)日志模塊用于記錄fuzz結(jié)果，通過對異常日志的分析可以發(fā)現(xiàn)漏洞
# 3.漏洞挖掘的結(jié)果
通過對Android系統(tǒng)服務(wù)的漏洞挖掘，目前一共發(fā)現(xiàn)了32個漏洞，其中在AOSP版本的虛擬機上發(fā)現(xiàn)了20個，在第三方廠商定制的系統(tǒng)服務(wù)中發(fā)現(xiàn)了12個，目前漏洞已經(jīng)提交Google，小米，魅族等廠商，并且得到了高危漏洞的確認(rèn)。這些漏洞主要是造成重啟，這樣就可以構(gòu)造拒絕服務(wù)攻擊(dos)，還有一些會導(dǎo)致顯示進程崩潰等干擾性破壞。
我個人覺得Android系統(tǒng)在安全方面的提升主要體現(xiàn)在以下幾個方面：
1.建立更加完善的Android漏洞，提交相應(yīng)完善制度，加快補丁發(fā)布。
2.完善Android文件的加密，同時在硬件上完善，比如TrustZone。
3.通過更加細(xì)粒度的授權(quán)機制，來保護用戶的安全和隱私。
4.縮小Android的碎片化。
5.提高開發(fā)者的審核門檻，應(yīng)用市場加強惡意應(yīng)用的檢查。
隨著Android的版本升級和對漏洞的不斷完善，Android系統(tǒng)正在變得越來越安全。
【如何用fuzz技術(shù)挖掘Android漏洞 Android漏洞該如何防御】相關(guān)文章：
PHP的漏洞-如何防止PHP漏洞09-05
如何修復(fù)英語單詞記憶漏洞10-01
Android與ios的對比11-04
Android手機的通病10-07
PHP漏洞：命令注入攻擊10-23
PHP頁面漏洞分析的方法08-13
Windows里的快捷鍵漏洞10-06
PHP常見漏洞的防范措施11-08
PHP網(wǎng)站常見的安全漏洞11-07