Android系統(tǒng)服務(wù)即由Android提供的各種服務(wù)，比如WIFI，多媒體，短信等等，幾乎所有的Android應(yīng)用都要使用到系統(tǒng)服務(wù)。系統(tǒng)服務(wù)在為用戶提供便利的同時(shí)，也存在著一些風(fēng)險(xiǎn)。比如，如果一個(gè)應(yīng)用獲取到了系統(tǒng)服務(wù)中的短信服務(wù)，那么他就可能會(huì)查看用戶的短信信息，用戶隱私就有可能暴露。此外，如果在使用系統(tǒng)服務(wù)的過程中，使用了異常的外部數(shù)據(jù)，有可能會(huì)導(dǎo)致系統(tǒng)服務(wù)崩潰，甚至是遠(yuǎn)程代碼執(zhí)行，內(nèi)存破壞等等嚴(yán)重后果。因此Android系統(tǒng)服務(wù)的安全問題需要重視。

在以前的工作發(fā)現(xiàn)主要的漏洞和攻擊主要包括特權(quán)提升攻擊，惡意軟件攻擊，重打包，組件劫持攻擊等類型。盡管安全研究人員已經(jīng)針對(duì)Android上層app的漏洞挖掘做了大量的工作，但是針對(duì)Android系統(tǒng)服務(wù)的漏洞挖掘一直被安全人員所普遍忽視。

通過Binder機(jī)制可以對(duì)Android的系統(tǒng)服務(wù)漏洞進(jìn)行深入的挖掘。本文基于Android的Binder機(jī)制編寫了一套漏洞挖掘框架。

下面我們首先介紹一下先驗(yàn)知識(shí)。

1 基礎(chǔ)知識(shí)1.1 Android的Binder機(jī)制

1.1.1 Binder概述

Binder其實(shí)也不是Android提出來的一套新的進(jìn)程間通信機(jī)制，它是基于OpenBinder來實(shí)現(xiàn)的。Binder是一種進(jìn)程間通信機(jī)制，它是一種類似于COM和CORBA分布式組件架構(gòu)，是提供遠(yuǎn)程過程調(diào)用（RPC）功能。

什么是Binder

直觀來說，Binder是Android中的一個(gè)類，它繼承了IBinder接口 從IPC角度來說，Binder是Android中的一種跨進(jìn)程通信方式，Binder還可以理解為一種虛擬的物理設(shè)備，它的設(shè)備驅(qū)動(dòng)是/dev/binder，該通信方式在Linux中沒有 從Android Framework角度來說，Binder是ServiceManager連接各種Manager（ActivityManager、WindowManager，etc）和相應(yīng)ManagerService的橋梁 從Android應(yīng)用層來說，Binder是客戶端和服務(wù)端進(jìn)行通信的媒介，當(dāng)你bindService的時(shí)候，服務(wù)端會(huì)返回一個(gè)包含了服務(wù)端業(yè)務(wù)調(diào)用的Binder對(duì)象，通過這個(gè)Binder對(duì)象，客戶端就可以獲取服務(wù)端提供的服務(wù)或者數(shù)據(jù)，這里的服務(wù)包括普通服務(wù)和基于AIDL的服務(wù) 
在Android系統(tǒng)的Binder機(jī)制中，由一系統(tǒng)組件組成，分別是Client、Server、Service Manager和Binder驅(qū)動(dòng)程序，其中Client、Server和Service Manager運(yùn)行在用戶空間，Binder驅(qū)動(dòng)程序運(yùn)行內(nèi)核空間，如圖1-1所示。Binder就是一種把這四個(gè)組件粘合在一起的粘結(jié)劑，其中核心組件便是Binder驅(qū)動(dòng)程序了，Service Manager提供了輔助管理的功能，Client和Server正是在Binder驅(qū)動(dòng)和Service Manager提供的基礎(chǔ)設(shè)施上，進(jìn)行Client-Server之間的通信。Service Manager和Binder驅(qū)動(dòng)已經(jīng)在Android平臺(tái)中實(shí)現(xiàn)好，開發(fā)者只要按照規(guī)范實(shí)現(xiàn)自己的Client和Server組件就可以了。 

這里寫圖片描述

圖1-1 Binder架構(gòu)圖

1.1.2 為什么使用Binder 
Android中有大量的CS（Client-Server）應(yīng)用方式，這就要求Android內(nèi)部提供IPC方法，而linux所支持的進(jìn)程通信方式有兩個(gè)問題：性能和安全性。 
目前l(fā)inux支持的IPC包括傳統(tǒng)的管道，System V IPC(消息隊(duì)列/共享內(nèi)存/信號(hào)量)，以及socket，但只有socket支持Client-Server的通信方式，由于socket是一套通用的網(wǎng)絡(luò)通信方式，其傳輸效率低下切有很大的開銷，比如socket的連接建立過程和中斷連接過程都是有一定開銷的。消息隊(duì)列和管道采用存儲(chǔ)-轉(zhuǎn)發(fā)方式，即數(shù)據(jù)先從發(fā)送方緩存區(qū)拷貝到內(nèi)核開辟的緩存區(qū)中，然后再?gòu)膬?nèi)核緩存區(qū)拷貝到接收方緩存區(qū)，至少有兩次拷貝過程。共享內(nèi)存雖然無需拷貝，但控制復(fù)雜，難以使用。 
在安全性方面，Android作為一個(gè)開放式，擁有眾多開發(fā)者的的平臺(tái)，應(yīng)用程序的來源廣泛，確保智能終端的安全是非常重要的。終端用戶不希望從網(wǎng)上下載的程序在不知情的情況下偷窺隱私數(shù)據(jù)，連接無線網(wǎng)絡(luò)，長(zhǎng)期操作底層設(shè)備導(dǎo)致電池很快耗盡等等。傳統(tǒng)IPC沒有任何安全措施，完全依賴上層協(xié)議來確保。首先傳統(tǒng)IPC的接收方無法獲得對(duì)方進(jìn)程可靠的UID/PID（用戶ID/進(jìn)程ID），從而無法鑒別對(duì)方身份。Android為每個(gè)安裝好的應(yīng)用程序分配了自己的UID，故進(jìn)程的UID是鑒別進(jìn)程身份的重要標(biāo)志。使用傳統(tǒng)IPC只能由用戶在數(shù)據(jù)包里填入U(xiǎn)ID/PID，但這樣不可靠，容易被惡意程序利用?？煽康纳矸輼?biāo)記只有由IPC機(jī)制本身在內(nèi)核中添加。其次傳統(tǒng)IPC訪問接入點(diǎn)是開放的，無法建立私有通道。比如命名管道的名稱，system V的鍵值，socket的ip地址或文件名都是開放的，只要知道這些接入點(diǎn)的程序都可以和對(duì)端建立連接，不管怎樣都無法阻止惡意程序通過猜測(cè)接收方地址獲得連接。 
基于以上原因，Android需要建立一套新的IPC機(jī)制來滿足系統(tǒng)對(duì)通信方式，傳輸性能和安全性的要求，這就是Binder。Binder基于 Client-Server通信模式，傳輸過程只需一次拷貝，為發(fā)送發(fā)添加UID/PID身份，既支持實(shí)名Binder也支持匿名Binder，安全性高。

1.1.3 Aidl機(jī)制

AIDL (Android Interface Definition Language) 是一種IDL 語(yǔ)言，用于生成可以在Android設(shè)備上兩個(gè)進(jìn)程之間進(jìn)行進(jìn)程間通信(interprocess communication, IPC)的代碼。如果在一個(gè)進(jìn)程中（例如Activity）要調(diào)用另一個(gè)進(jìn)程中（例如Service）對(duì)象的操作，就可以使用AIDL生成可序列化的參數(shù)。

AIDL IPC機(jī)制是面向接口的，像COM或CORBA一樣，但是更加輕量級(jí)。它是使用代理類在客戶端和服務(wù)端傳遞數(shù)據(jù)。只有你允許客戶端從不同的應(yīng)用程序?yàn)榱诉M(jìn)程間的通信而去訪問你的service，以及想在你的service處理多線程。如果不需要進(jìn)行不同應(yīng)用程序間的并發(fā)通信(IPC)，或者你想進(jìn)行IPC，但不需要處理多線程的。使用AIDL前，必須要理解如何綁定service。

AIDL IPC機(jī)制是面向接口的，像COM或Corba一樣，但是更加輕量級(jí)。它是使用代理類在客戶端和實(shí)現(xiàn)端傳遞數(shù)據(jù)。

1.2 Fuzz技術(shù)

模糊測(cè)試定義為“通過向應(yīng)用提供非預(yù)期的輸入并監(jiān)控輸出中的異常來發(fā)現(xiàn)軟件中的故障(faults)的方法”。典型而言,模糊測(cè)試?yán)米詣?dòng)化或是半自動(dòng)化的方法重復(fù)地向應(yīng)用提供輸入。顯然,上述定義相當(dāng)寬泛,但這個(gè)定義闡明了模糊測(cè)試的基本概念。

用于模糊測(cè)試的模糊測(cè)試器(fuzzer)分為兩類:一類是基于變異(mutation-based)的模糊測(cè)試器,這一類測(cè)試器通過對(duì)已有的數(shù)據(jù)樣本進(jìn)行變異來創(chuàng)建測(cè)試用例;而另一類是基于生成(generation-based)的模糊測(cè)試器,該類測(cè)試器為被測(cè)系統(tǒng)使用的協(xié)議或是文件格式建模,基于模型生成輸入并據(jù)此創(chuàng)建測(cè)試用例。這兩種模糊測(cè)試器各有其優(yōu)缺點(diǎn)

模糊測(cè)試各階段

采用何種模糊測(cè)試方法取決于眾多因素。沒有所謂的一定正確的模糊測(cè)試方法,決

定采用何種模糊測(cè)試方法完全依賴于被測(cè)應(yīng)用、測(cè)試者擁有的技能、以及被進(jìn)行模糊測(cè)

試的數(shù)據(jù)的格式。但是,不論對(duì)什么應(yīng)用進(jìn)行模糊測(cè)試,不論采用何種模糊測(cè)試方法,

模糊測(cè)試執(zhí)行過程都包含相同的幾個(gè)基本階段。

<1>確定測(cè)試目標(biāo)

只有有了明確的測(cè)試目標(biāo)后,我們才能決定使用的模糊測(cè)試工具或方法。如果要在安全審計(jì)中對(duì)一個(gè)完全由內(nèi)部開發(fā)的應(yīng)用進(jìn)行模糊測(cè)試,測(cè)試目標(biāo)的選擇必須小心謹(jǐn)慎。但如果是要在第三方應(yīng)用中找到安全漏洞,測(cè)試目標(biāo)的選擇就更加靈活。要決定第三方應(yīng)用模糊測(cè)試的測(cè)試目標(biāo),首先需要參考該第三方應(yīng)用的供應(yīng)商歷史上曾出現(xiàn)過的安全漏洞。在一些典型的安全漏洞聚合網(wǎng)站如 SecurityFocus 18 和 Secunia 19 上可以查找到主要軟件供應(yīng)商歷史上曾出現(xiàn)過的安全漏洞。如果某個(gè)供應(yīng)商的歷史記錄很差,很可能意味著這個(gè)供應(yīng)商的代碼實(shí)踐 (code practice)能力很差,他們的產(chǎn)品有仍有很大可能存在未被發(fā)現(xiàn)的安全漏洞。除應(yīng)用程序外,應(yīng)用包含的特定文件或庫(kù)也可以是測(cè)試目標(biāo)。

如果需要選擇應(yīng)用包含的特定文件或者庫(kù)作為測(cè)試目標(biāo),你可以把注意力放在多個(gè)應(yīng)用程序之間共享的那些二進(jìn)制代碼上。因?yàn)槿绻@些共享的二進(jìn)制代碼中存在安全漏洞,將會(huì)有非常多的用戶受到影響,因而風(fēng)險(xiǎn)也更大。

<2>.確定輸入向量

幾乎所有可被利用的安全漏洞都是因?yàn)閼?yīng)用沒有對(duì)用戶的輸入進(jìn)行校驗(yàn)或是進(jìn)行必要的非法輸入處理。是否能找到所有的輸入向量(input vector)是模糊測(cè)試能否成功的關(guān)鍵。如果不能準(zhǔn)確地找到輸入向量,或是不能找到預(yù)期的輸入值,模糊測(cè)試的作用就會(huì)受到很大的局限。有些輸入向量是顯而易見的,有些則不然。尋找輸入向量的原則是:從客戶端向目標(biāo)應(yīng)用發(fā)送的任何東西,包括頭(headers)、文件名(file name)、環(huán)

境變量(environment variables),注冊(cè)表鍵(registry keys),以及其他信息,都應(yīng)該被看做是輸入向量。所有這些輸入向量都可能是潛在的模糊測(cè)試變量。

<3>.生成模糊測(cè)試數(shù)據(jù)

一旦識(shí)別出輸入向量,就可以依據(jù)輸入向量產(chǎn)生模糊測(cè)試數(shù)據(jù)了。究竟是使用預(yù)先確定的值、使用基于存在的數(shù)據(jù)通過變異生成的值、還是使用動(dòng)態(tài)生成的值依賴于被測(cè)應(yīng)用及其使用的數(shù)據(jù)格式。但是,無論選擇哪種方式,都應(yīng)該使用自動(dòng)化過程來生成數(shù)據(jù)。

<4>.執(zhí)行模糊測(cè)試數(shù)據(jù)

該步驟緊接上一個(gè)步驟,正是在這個(gè)步驟,“模糊測(cè)試”變成了動(dòng)詞。在該步驟中,一般會(huì)向被測(cè)目標(biāo)發(fā)送數(shù)據(jù)包、打開文件、或是執(zhí)行被測(cè)應(yīng)用。同上一個(gè)步驟一樣,這個(gè)步驟必須是自動(dòng)化的。否則,我們就不算是真正在開展模糊測(cè)試。

<5>.監(jiān)視異常

一個(gè)重要但經(jīng)常容易被忽略的步驟是對(duì)異常和錯(cuò)誤進(jìn)行監(jiān)控。設(shè)想我們?cè)谶M(jìn)行一次模糊測(cè)試,在測(cè)試中,我們向被測(cè)的 Web 服務(wù)器發(fā)送了 10000 個(gè)數(shù)據(jù)包,最終導(dǎo)致了服務(wù)器崩潰。但服務(wù)器崩潰后,我們卻怎么也找不到導(dǎo)致服務(wù)器崩潰的數(shù)據(jù)包了。如果這種事真的發(fā)生了,我們只能說這個(gè)測(cè)試毫無價(jià)值。模糊測(cè)試需要根據(jù)被測(cè)應(yīng)用和所決定采用的模糊測(cè)試類型來設(shè)置各種形式的監(jiān)視。

<6>.判定發(fā)現(xiàn)的漏洞是否可能被利用

如果在模糊測(cè)試中發(fā)現(xiàn)了一個(gè)錯(cuò)誤,依據(jù)審計(jì)的目的,可能需要判定這個(gè)被發(fā)現(xiàn)的錯(cuò)誤是否是一個(gè)可被利用的安全漏洞。這種判定過程是典型的手工過程,需要操作者具有特定的安全知識(shí)。這個(gè)步驟不一定要由模糊測(cè)試的執(zhí)行者來進(jìn)行,也可以交給其他人來進(jìn)行。

2.漏洞挖掘思路

fuzz在協(xié)議和接口安全測(cè)試中比較簡(jiǎn)單粗暴，試錯(cuò)成本低。Fuzzing是一種基于缺陷注入的自動(dòng)軟件測(cè)試技術(shù)。通過編寫fuzzer工具向目標(biāo)程序提供某種形式的輸入并觀察其響應(yīng)來發(fā)現(xiàn)問題，這種輸入可以是完全隨機(jī)的或精心構(gòu)造的。Fuzzing測(cè)試通常以大小相關(guān)的部分、字符串、標(biāo)志字符串開始或結(jié)束的二進(jìn)制塊等為重點(diǎn)，使用邊界值附近的值對(duì)目標(biāo)進(jìn)行測(cè)試。

2.1 fuzz的切入點(diǎn)和目標(biāo)

2.1.1 fuzz的切入點(diǎn)

為了更好的挖掘漏洞，選擇fuzz接口需要滿足這幾個(gè)要求：

1）這個(gè)接口是開放的，是可以被低權(quán)限進(jìn)程調(diào)用的

2）這個(gè)接口距離fuzz目標(biāo)（系統(tǒng)服務(wù)）比較接近，中間路徑最好透?jìng)?，這樣比較容易分析異常

3）從簡(jiǎn)原則

根據(jù)上面的分析，BpBinder中的transact函數(shù)就是一個(gè)很好的fuzz接口，但這個(gè)函數(shù)在底層無法直接調(diào)用。

底層transact方法介紹

在c層中，BBinder::transact中會(huì)調(diào)用onTransact，這個(gè)onTransact才是真正處理業(yè)務(wù)的。需要注意的是，因?yàn)槲覀兊腷inder實(shí)體在本質(zhì)上都是繼承于BBinder的，而且我們一般都會(huì)重載onTransact()函數(shù)，所以onTransact()實(shí)際上調(diào)用的是具體binder實(shí)體的onTransact()成員函數(shù)。也就是說，onTransact的具體實(shí)現(xiàn)一般在上層的binder實(shí)體，而不在BBinder。BBinder沒有實(shí)現(xiàn)一個(gè)默認(rèn)的onTransact()成員函數(shù)，所以在遠(yuǎn)程通信時(shí)，BBinder::transact()調(diào)用的onTransact()其實(shí)是Bnxxx或者BnInterface的某個(gè)子類的onTransact()成員函數(shù)，舉個(gè)例子，BnMediaRecorder中實(shí)現(xiàn)了一個(gè)onTransact函數(shù)，通過switch-case，根據(jù)不同code進(jìn)行分發(fā)處理。

我們從BpBinder往上層找，很容易發(fā)現(xiàn)，Java層IBinder的transact函數(shù)最終調(diào)用到BpBinder，且參數(shù)是原封不動(dòng)的“透?jìng)?rdquo;到底層，考慮到j(luò)ava層的可視化和擴(kuò)展性，可以選擇IBinder的公有方法transact作為fuzz接口。

transact的四個(gè)參數(shù)介紹。我們可以構(gòu)造這四個(gè)參數(shù)進(jìn)行測(cè)試。

code是int類型，指定了服務(wù)方法號(hào)

data是parcel類型，是發(fā)送的數(shù)據(jù)，滿足binder協(xié)議規(guī)則，下面會(huì)有詳述

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其實(shí)是提供了一種進(jìn)程間通信（IPC）的功能。這些系統(tǒng)服務(wù)，通過binder協(xié)議抽象出一個(gè)個(gè)的“接口”，供其他進(jìn)程調(diào)用，是一個(gè)重要的潛在的攻擊面。如果沒有做好權(quán)限控制，會(huì)讓低權(quán)限的第三方應(yīng)用/病毒/木馬利用，后果不堪設(shè)想。

系統(tǒng)服務(wù)具有高權(quán)限，是我們需要重點(diǎn)關(guān)注的對(duì)象，而低權(quán)限進(jìn)程（農(nóng)民）可以利用binder call去調(diào)用系統(tǒng)服務(wù)，從低權(quán)限到高權(quán)限，存在一個(gè)跨安全域的數(shù)據(jù)流，這里就是一個(gè)典型的攻擊界面。所以，我們選擇系統(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引擎實(shí)際是構(gòu)造transact（int code，Parcel data，Parcel reply，int Flags）函數(shù)的四個(gè)函數(shù)，然后調(diào)用Ibinder.transact()來調(diào)用系統(tǒng)服務(wù)。

2.2.1如何獲取Ibinder對(duì)象

我們要取到對(duì)端的IBinder對(duì)象，才可以調(diào)用這個(gè)服務(wù)。系統(tǒng)其實(shí)有一些隱藏API可以利用。先通過反射出ServiceManager（hide屬性）中的listServices獲取所有運(yùn)行的服務(wù)名稱。獲取到String類型的服務(wù)名稱后，再反射getService獲取對(duì)應(yīng)的服務(wù)IBinder對(duì)象。

2.2.2 code如何生成

code也稱為TransactionID，標(biāo)定了服務(wù)端方法號(hào)。

每個(gè)服務(wù)對(duì)外定義的方法都會(huì)分配方法號(hào)，而且是有規(guī)律的，第一個(gè)服務(wù)方法code使用1，第二個(gè)是2，，第三個(gè)使用3，依次類推，如果有N個(gè)方法，就分別分配1-N個(gè)連續(xù)的服務(wù)號(hào)。

對(duì)于Java服務(wù)，必定有Stub類，可以通過反射出mInterfaceToken+”$Stub”類中所有成員屬性，其中以”TRANSACTION_”開頭的int型就是該方法對(duì)應(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對(duì)象，就可以直接getInterfaceDescriptor來獲取interface name，也就是接口方法的描述符。對(duì)于Java層服務(wù)的方法，可以通過反射獲取method對(duì)象，然后用getParameterTypes獲取所有的類型。

2.2.4 fuzz系統(tǒng)和邏輯設(shè)計(jì)

一共分為四個(gè)部分：

1）測(cè)試數(shù)據(jù)產(chǎn)生器產(chǎn)生器就是用上述方法產(chǎn)生transact需要用到的的四個(gè)參數(shù)

2）fuzz引擎用于執(zhí)行具體的transact調(diào)用過程，調(diào)用ibinder的transact（）函數(shù)

3）監(jiān)視器用于監(jiān)控fuzz結(jié)果和異常

4）日志模塊用于記錄fuzz結(jié)果，通過對(duì)異常日志的分析可以發(fā)現(xiàn)漏洞

# 3.漏洞挖掘的結(jié)果

通過對(duì)Android系統(tǒng)服務(wù)的漏洞挖掘，目前一共發(fā)現(xiàn)了32個(gè)漏洞，其中在AOSP版本的虛擬機(jī)上發(fā)現(xiàn)了20個(gè)，在第三方廠商定制的系統(tǒng)服務(wù)中發(fā)現(xiàn)了12個(gè)，目前漏洞已經(jīng)提交Google，小米，魅族等廠商，并且得到了高危漏洞的確認(rèn)。這些漏洞主要是造成重啟，這樣就可以構(gòu)造拒絕服務(wù)攻擊（dos），還有一些會(huì)導(dǎo)致顯示進(jìn)程崩潰等干擾性破壞。

我個(gè)人覺得Android系統(tǒng)在安全方面的提升主要體現(xiàn)在以下幾個(gè)方面：

1.建立更加完善的Android漏洞，提交相應(yīng)完善制度，加快補(bǔ)丁發(fā)布。

2.完善Android文件的加密，同時(shí)在硬件上完善，比如TrustZone。

3.通過更加細(xì)粒度的授權(quán)機(jī)制，來保護(hù)用戶的安全和隱私。

4.縮小Android的碎片化。

5.提高開發(fā)者的審核門檻，應(yīng)用市場(chǎng)加強(qiáng)惡意應(yīng)用的檢查。

隨著Android的版本升級(jí)和對(duì)漏洞的不斷完善，Android系統(tǒng)正在變得越來越安全。