蔡迎兵

(陜西學(xué)前師范學(xué)院 教學(xué)設(shè)備與實驗室管理處， 陜西 西安 710100)

0 引言

目前，國內(nèi)外在Android系統(tǒng)第三方SDK的安全研究中，主要是針對具體漏洞或威脅的研究[1-2]。如基于聚類算法和AV系統(tǒng)來監(jiān)測SDK中的安全問題，針對一些具備單點登錄功能的SDK下中存在的授權(quán)和認(rèn)證缺陷[3]。在SDK中采用OAuth協(xié)議下的安全風(fēng)險等，并沒有提出第三方SDK的一般性安全方法[4-5]?；诖?，本文提出了Android生態(tài)第三方SDK安全性的分析框架，將第三方SDK的demo作為對象，并采用SDK安全的靜態(tài)、動態(tài)分析方法和分析工具對第三方SDK的安全性進(jìn)行全面分析。

1 第三方SDK背景和動機

第三方SDK是由第三方服務(wù)公司提供如廣告、推送、移動支付和圖像識別等特定功能的軟件開發(fā)工具包，開發(fā)人員將第三方SDK集成項目來實現(xiàn)多項功能應(yīng)用，有效提高了應(yīng)用開發(fā)效率。對于大多數(shù)第三方SDK通常作為提供第三方的客戶端，當(dāng)調(diào)用SDK時，需要連接遠(yuǎn)程登錄服務(wù)器。

根據(jù)SDK運行機制的不同，主要分為第三方SDK向遠(yuǎn)程服務(wù)器發(fā)送請求以及第三方SDK啟動本地服務(wù)。第三方SDK向遠(yuǎn)程服務(wù)器發(fā)送請求機制，由于HTTP(超文本傳輸安全協(xié)議)未加密傳輸數(shù)據(jù)，因而難以保證數(shù)據(jù)完整性和隱私，HTTPS 作為一種用于不可信網(wǎng)絡(luò)的通信協(xié)議，將SSL/TLS的安全功能添加到標(biāo)準(zhǔn)HTTP通信中，只需正確配置就可防止竊聽和攻擊，使用HTTPS代替HTTP成為趨勢，但目前大部分SDK采用的HTTP協(xié)議連接到云服務(wù)器帶來了較高的風(fēng)險。

2 第三方SDK安全分析

2.1 分析流程

對Android生態(tài)中第三方SDK安全分析主要分為3個主要階段：瀏覽第三方SDK信息瀏覽；建立安全分析框架進(jìn)行靜態(tài)自動化和動態(tài)的第三方SDK分析；對存在的安全問題驗證。其中,第三方清單瀏覽主要從SDK供應(yīng)商提供的文檔中提取關(guān)于SDK集成應(yīng)用程序中的組件和權(quán)限程序清單，主要包括瀏覽第三方SDK的demo應(yīng)用程序與代碼、manifest文件和集成手冊等開發(fā)清單。本節(jié)主要針對分析框架和安全問題驗證進(jìn)行分析。

2.2 第三方SDK分析框架

第三方SDK分析框架主要包括由代碼審計和靜態(tài)污點分析的靜態(tài)自動化分析以及基于Android設(shè)備運行第三方SDK的demo應(yīng)用執(zhí)行污點分析的動態(tài)分析構(gòu)成。

2.2.1 靜態(tài)自動化分析

靜態(tài)污點分析流程圖如圖1所示。

圖1 靜態(tài)污點分析的數(shù)據(jù)抓取

由圖1可知,靜態(tài)自動化分析中，首先根據(jù)SDK的demo應(yīng)用反編譯獲得其對應(yīng)的smali代碼、manifest文件資源，然后對smali代碼設(shè)計和靜態(tài)污點分析。進(jìn)行代碼設(shè)計過程中主要是尋找第三方SDK中可能存在的代碼缺陷，如SSL/TLS配置問題、WebView使用了不安全的API，本地服務(wù)器和日志函數(shù)存在缺陷代碼等。對于SSL/TLS漏洞檢測，使用Mallodrid對第三方SDK的demo應(yīng)用分析,但該分析不能排除死馬，且不能檢測部分系統(tǒng)漏洞，如不正確的SSL/TLS配置。Mallodroid在最好的情況下能提供一個不完整的分析，而最壞情況下將會導(dǎo)致分析結(jié)果的不正確性。

Smali代碼的靜態(tài)污點分析是尋找第三方SDK是否存在敏感API的收集、敏感信息流尋找和泄露、控制流程圖的建設(shè)。本文根據(jù)相關(guān)研究分別將獲取敏感信息的AndroidAPI和能獲得外部信息的AndroidAPI作為污點source和污點sink。根據(jù)smali代碼加密控制流圖，并標(biāo)記節(jié)點中的敏感API進(jìn)行敏感數(shù)據(jù)分析，在控制流圖上，選擇污點source為入口點，尋找能達(dá)到污點sink的路徑作為第三方SDK的敏感信息流。

2.2.2 動態(tài)分析

當(dāng)?shù)谌絊DK代碼中采用Java.lang.reflect包的反射機制進(jìn)行過動態(tài)代碼調(diào)用時，采用靜態(tài)污點分析不能調(diào)用反射的API，因此需要動態(tài)污點來彌補，如圖2所示。

圖2 動態(tài)污點分析的交互數(shù)據(jù)包抓取

在Android系統(tǒng)中采用hook技術(shù)向敏感Android注入代碼實現(xiàn)動態(tài)污染分析，基于Xposed框架來編寫敏感Android API插件注入log代碼，當(dāng)調(diào)用getDeviceId()程序時，由于該API中插入了log代碼，在日志中記錄該調(diào)用動作，獲取了第三方SDK的動態(tài)動作。

通過抓取第三方SDK和服務(wù)器端網(wǎng)絡(luò)數(shù)據(jù)包還原相互間的交互行為。實驗中，采用Fiddler作為服務(wù)器與SDK間的代理服務(wù)器進(jìn)行數(shù)據(jù)交互,當(dāng)?shù)谌絊DK采用HTTPS與服務(wù)器端進(jìn)行數(shù)據(jù)傳輸時，通過Fiddler生成簽名證書，并將證書發(fā)送給Android系統(tǒng)作為可信任的證書對HTTPS進(jìn)行數(shù)據(jù)解析。此外，可以使用IDA Pro對第三方SDK的so庫進(jìn)行解析。

2.2.3 安全問題驗證

安全問題驗證主要通過動態(tài)執(zhí)行第三方SDK的demo應(yīng)用完成。通過在Android模擬平臺運行第三方SDK的demo，設(shè)置Fiddler為遠(yuǎn)程服務(wù)器和第三方SDK流量代理，若SSL/TLS配置錯誤，則攻擊者在Fiddler中創(chuàng)建新的簽名證書替換真實證書。當(dāng)應(yīng)用程序執(zhí)行完畢后，采用adb shell訪問程序私有目錄，由于abd shell目錄中包括了數(shù)據(jù)庫、lib、緩存、文件等信息，因此在未加密數(shù)據(jù)條件下訪問數(shù)據(jù)庫信息。通常情況下，第三方SDK服務(wù)端代碼是秘密的，因此，只能結(jié)合黑盒測試，通過注入代碼的方式修改SDK服務(wù)端參數(shù)，在靜態(tài)分析和動態(tài)分析上進(jìn)行安全問題驗證。

3 實驗結(jié)果分析

3.1 檢測環(huán)境

為驗證Andorid生態(tài)中第三方SDK的安全分析能力，選取目前流行的第三方SDK進(jìn)行安全分析。實驗設(shè)備為Nexus 5X,基于Android 6.0.1操作系統(tǒng)，采用Windows系統(tǒng)的PC機用于第三方SDK的demo應(yīng)用靜態(tài)分析、網(wǎng)絡(luò)數(shù)據(jù)包抓取。

從官方網(wǎng)站收集149個第三方SDK相關(guān)程序，其中包括AppBrain、SDK.cn等多個熱門匯總網(wǎng)站。AppBrain更專注于Google Play，SDK.cn側(cè)重于國內(nèi)市場，目前，較受歡迎的第三方SDK存在多個版本，而一些SDK僅針對自身的產(chǎn)品開發(fā),如表1所示。

表1 第三方SDK類型信息表

3.2 結(jié)果分析

分析驗證了第三方SDK存在的多個漏洞，根據(jù)OWASP Mobile TOP 10將其分為6個類型，分析結(jié)果如表2所示。

表2 第三方SDK漏洞分布情況

3.2.1 濫用HTTP

盡管清楚HTTP協(xié)議的網(wǎng)絡(luò)連接存在不安全性，但實際仍然存在第三方SDK采用HTTP進(jìn)行遠(yuǎn)程服務(wù)器通信，尤其是一些數(shù)據(jù)通過HTTP通道以明文的形式傳輸，如在Kuguo廣告SDK中，廣告平臺Kuguo采用HTTP的明文形式傳遞敏感數(shù)據(jù)，在149個第三方SDK中，其中有32個SDK報告該漏洞。在收集的第三方SDK中，由7個采用HTTP通道傳輸?shù)臄?shù)據(jù)加密，加密系統(tǒng)中的加密算法密鑰是要寫入SDK的.so文件中，而攻擊者能通過解析.so文件破解加密算法，導(dǎo)致程序隱私保密性受到威脅。

3.2.2 濫用SSL/TLS

第三方SDK中同樣廣泛存在著濫用SSL/TIS問題。HTTPS只有在恰當(dāng)?shù)呐渲孟虏拍鼙ＷC信道安全，要建立安全的SSL/TLS連接，客戶端檢查主機名與服務(wù)器域名的匹配。如在Android中的X509TrustManager接口作為X509證書管理器進(jìn)行sockets的身份驗證，開發(fā)者可以重寫證書來代替庫的實現(xiàn)，這樣意味著即使在出現(xiàn)非法證書時也不會被拋棄，部分SDK執(zhí)行證書得到驗證，但部分過期或被吊銷的證書均未拋棄。

3.2.3 濫用敏感權(quán)限

通常Android應(yīng)用程序會請求額外的權(quán)限來窺探用戶的隱私信息，更有甚者植入惡意插件。根據(jù)分析顯示其中有32個SDK上存在濫用敏感權(quán)限的惡意行為，當(dāng)應(yīng)用程序?qū)⒌谌絊DK加入后，會將部分權(quán)限、組件信息加入到manifest文件中，而第三方SDK將與主機同向manifest文件權(quán)限，只要manifest文件生命要使用相關(guān)權(quán)限，則SDK利用代碼檢查是否請求了該權(quán)限。

3.2.4 身份識別

推送消息SDK作為第三方SDK常見類型。推送消息服務(wù)啟動后向服務(wù)器發(fā)送設(shè)備信息注冊，并生成注冊ID，SDK和應(yīng)用服務(wù)器分別接收注冊ID并發(fā)送推送消息。在這個過程中需要應(yīng)用程序、服務(wù)器端和推送SDK端相互配合，容易造成安全問題。為抵御攻擊，消息服務(wù)器在注冊ID時將登錄令牌發(fā)送給用戶，保證注冊ID不易偽造，此外消息推動SDK獲得的注冊ID將通過加密算法加密后進(jìn)行保存，但這類加密秘鑰通常由本地生成，攻擊者可利用逆向工程獲得關(guān)鍵詞，有助于解密戶注冊ID。

3.2.5 本地服務(wù)器漏洞

本地服務(wù)器的第三方SDK能收集設(shè)備信息來控制設(shè)備，當(dāng)本地服務(wù)器采用不恰當(dāng)?shù)脑L問控制時，攻擊者可檢索敏感數(shù)據(jù)，操作設(shè)備，如在Baidu Map作為一類廣泛應(yīng)用，通過第三方SDK插入到旗下近3 000款程序中，通過采用Nmap掃描網(wǎng)絡(luò)上多個設(shè)備的TCP斷口40 310，還存在眾多設(shè)備可打開該端口進(jìn)入第三方SDK。

3.2.6 信息泄漏

Android日志記錄了設(shè)備運行狀態(tài)可接口信息，開發(fā)人員可采用android.util.log打印調(diào)試信息，當(dāng)應(yīng)用上線未關(guān)閉日志，則很容易修改調(diào)試信息，尤其是在Android4.1版本前，具備READ_LOGS權(quán)限的Android應(yīng)用程序?qū)⒚舾袛?shù)據(jù)寫入日志而造成泄露，根據(jù)分析發(fā)現(xiàn)mapbar SDK將個人信息寫入到日志中，而其中有5個第三方SDK中包含了該mapbar SDK。

4 總結(jié)

本文分類了Android生態(tài)系統(tǒng)中第三方存在的安全隱患。由于第三方SDK無法獨立運行，選擇了第三方SDK的demo應(yīng)用作為分析對象，采用靜態(tài)污點追蹤、動態(tài)污點追蹤,建立了第三方SDK的靜態(tài)、動態(tài)分析框架。通過動態(tài)執(zhí)行第三方demo應(yīng)用，注入代碼的方式修改SDK服務(wù)端參數(shù)，進(jìn)行安全問題驗證。最后通過選取目前市場上流行的第三方SDK進(jìn)行安全性分析，結(jié)果顯示其中有超過60%的SDK中存在不同類型的漏洞，如HTTP的誤用、敏感權(quán)限濫用、身份識別等，對相應(yīng)的應(yīng)用程序造成嚴(yán)重威脅。