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

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

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

下面我們首先介紹一下先驗知識。

1 基礎知識1.1 Android的Binder機制

1.1.1 Binder概述

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

什么是Binder

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

這里寫圖片描述

圖1-1 Binder架構圖

1.1.2 為什么使用Binder 
Android中有大量的CS（Client-Server）應用方式，這就要求Android內(nèi)部提供IPC方法，而linux所支持的進程通信方式有兩個問題：性能和安全性。 
目前l(fā)inux支持的IPC包括傳統(tǒng)的管道，System V IPC(消息隊列/共享內(nèi)存/信號量)，以及socket，但只有socket支持Client-Server的通信方式，由于socket是一套通用的網(wǎng)絡通信方式，其傳輸效率低下切有很大的開銷，比如socket的連接建立過程和中斷連接過程都是有一定開銷的。消息隊列和管道采用存儲-轉發(fā)方式，即數(shù)據(jù)先從發(fā)送方緩存區(qū)拷貝到內(nèi)核開辟的緩存區(qū)中，然后再從內(nèi)核緩存區(qū)拷貝到接收方緩存區(qū)，至少有兩次拷貝過程。共享內(nèi)存雖然無需拷貝，但控制復雜，難以使用。 
在安全性方面，Android作為一個開放式，擁有眾多開發(fā)者的的平臺，應用程序的來源廣泛，確保智能終端的安全是非常重要的。終端用戶不希望從網(wǎng)上下載的程序在不知情的情況下偷窺隱私數(shù)據(jù)，連接無線網(wǎng)絡，長期操作底層設備導致電池很快耗盡等等。傳統(tǒng)IPC沒有任何安全措施，完全依賴上層協(xié)議來確保。首先傳統(tǒng)IPC的接收方無法獲得對方進程可靠的UID/PID（用戶ID/進程ID），從而無法鑒別對方身份。Android為每個安裝好的應用程序分配了自己的UID，故進程的UID是鑒別進程身份的重要標志。使用傳統(tǒng)IPC只能由用戶在數(shù)據(jù)包里填入UID/PID，但這樣不可靠，容易被惡意程序利用?？煽康纳矸輼擞浿挥杏蒊PC機制本身在內(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設備上兩個進程之間進行進程間通信(interprocess communication, IPC)的代碼。如果在一個進程中（例如Activity）要調用另一個進程中（例如Service）對象的操作，就可以使用AIDL生成可序列化的參數(shù)。

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

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

1.2 Fuzz技術

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

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

模糊測試各階段

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

定采用何種模糊測試方法完全依賴于被測應用、測試者擁有的技能、以及被進行模糊測

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

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

<1>確定測試目標

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

如果需要選擇應用包含的特定文件或者庫作為測試目標,你可以把注意力放在多個應用程序之間共享的那些二進制代碼上。因為如果這些共享的二進制代碼中存在安全漏洞,將會有非常多的用戶受到影響,因而風險也更大。

<2>.確定輸入向量

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

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

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

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

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

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

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

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

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

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

2.漏洞挖掘思路

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

2.1 fuzz的切入點和目標

2.1.1 fuzz的切入點

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

1）這個接口是開放的，是可以被低權限進程調用的

2）這個接口距離fuzz目標（系統(tǒng)服務）比較接近，中間路徑最好透傳，這樣比較容易分析異常

3）從簡原則

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

底層transact方法介紹

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

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

transact的四個參數(shù)介紹。我們可以構造這四個參數(shù)進行測試。

code是int類型，指定了服務方法號

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

reply也是parcel類型，是通信結束后返回的數(shù)據(jù)

flag是標記位，0為普通RPC，需要等待，調用發(fā)起后處于阻塞狀態(tài)直到接收到返回，1為one-way RPC，表示“不需要等待回復的”事務，一般為無返回值的單向調用。

2.1.2fuzz的目標

Binder其實是提供了一種進程間通信（IPC）的功能。這些系統(tǒng)服務，通過binder協(xié)議抽象出一個個的“接口”，供其他進程調用，是一個重要的潛在的攻擊面。如果沒有做好權限控制，會讓低權限的第三方應用/病毒/木馬利用，后果不堪設想。

系統(tǒng)服務具有高權限，是我們需要重點關注的對象，而低權限進程（農(nóng)民）可以利用binder call去調用系統(tǒng)服務，從低權限到高權限，存在一個跨安全域的數(shù)據(jù)流，這里就是一個典型的攻擊界面。所以，我們選擇系統(tǒng)服務作為fuzz的目標。

系統(tǒng)服務的分類

1.Binder體系的java服務(有Stub接口，也就是AIDL封裝)

2.Binder體系的Native服務

3.socket體系的init服務（通常見于init.rc）

4.其他服務

2.2 fuzz引擎

fuzz引擎實際是構造transact（int code，Parcel data，Parcel reply，int Flags）函數(shù)的四個函數(shù)，然后調用Ibinder.transact()來調用系統(tǒng)服務。

2.2.1如何獲取Ibinder對象

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

2.2.2 code如何生成

code也稱為TransactionID，標定了服務端方法號。

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

對于Java服務，必定有Stub類，可以通過反射出mInterfaceToken+”$Stub”類中所有成員屬性，其中以”TRANSACTION_”開頭的int型就是該方法對應的。

2.2.3 data如何構造

data由“RPC header+參數(shù)1+參數(shù)2+….”來構成的。但我們不需要自己去構造RPC header，直接調用writeInterfaceToken函數(shù)，傳入interface name就可以了。interface name是接口名稱，只要取得IBinder對象，就可以直接getInterfaceDescriptor來獲取interface name，也就是接口方法的描述符。對于Java層服務的方法，可以通過反射獲取method對象，然后用getParameterTypes獲取所有的類型。

2.2.4 fuzz系統(tǒng)和邏輯設計

一共分為四個部分：

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

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

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

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

# 3.漏洞挖掘的結果

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

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

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

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

3.通過更加細粒度的授權機制，來保護用戶的安全和隱私。

4.縮小Android的碎片化。

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

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

最新評論