Android系統(tǒng)外部SDK安全漏洞檢測研究*

馬 杰

(南京審計大學(xué)實驗中心，江蘇 南京 211815)

0 引言

當(dāng)前各種移動智能設(shè)備操作系統(tǒng)中Android系統(tǒng)的占有率越來越高，隨之而來的就是用戶對Android平臺的應(yīng)用程序需求亦呈幾何級數(shù)增長。為了提高Android應(yīng)用程序開發(fā)質(zhì)量和效率，許多程序開發(fā)人員會在一些由軟件公司或商業(yè)公司免費提供的軟件開發(fā)工具(Software Development Kit，SDK)基礎(chǔ)上再做二次或者多次開發(fā)；而這些SDK多數(shù)封裝了各種專業(yè)領(lǐng)域內(nèi)復(fù)雜的邏輯架構(gòu)、請求響應(yīng)過程、功能模塊，因此能夠大大縮短開發(fā)時間、保障程序功能可靠性和提高開發(fā)效率[1]。在Android應(yīng)用程序中，外部SDK優(yōu)勢突出，首先可以保證程序獲取該平臺提供方的優(yōu)質(zhì)資源，如開發(fā)基于某平臺SDK，那么其平臺旗下某地圖軟件開放數(shù)據(jù)地圖信息、實時路況等都可以輕易獲?。黄浯稳绻麑⒛潮憬葜Ц兜耐獠縎DK包含在內(nèi)，那么程序就可以執(zhí)行復(fù)雜、安全、高效的在線支付功能。在開發(fā)人員不足的情況下,這些SDK大大縮短了軟件商應(yīng)用程序的開發(fā)周期，并且保證了軟件功能的安全和穩(wěn)定，甚至某些SDK平臺會有廣告收益，而這對于程序開發(fā)人員非常具有吸引力。但是某些SDK架構(gòu)老舊、更新遲緩甚至包含其他目的，開發(fā)人員在不知情情況下推波助瀾，對用戶數(shù)據(jù)的安全和隱私信息的保護造成了潛在威脅。例如某軟件公司為銀行開發(fā)的用戶登錄SDK曾被曝光存在安全漏洞，儲戶在不知情的情況下隱私數(shù)據(jù)被遠(yuǎn)程服務(wù)器收集并在用戶設(shè)備留下暗門，造成了上億臺Android設(shè)備個人數(shù)據(jù)被泄漏至公開數(shù)據(jù)源、遭受代碼注入攻擊、賬戶劫持等攻擊[2-4]。

由此可見，外部SDK的可靠性將直接影響Android應(yīng)用程序的安全使用，然而以現(xiàn)有的技術(shù)對SDK平臺的全面漏洞檢測與安全分析則需耗費大量的時間與精力，目前開發(fā)者所能做的僅僅是使用最新版本SDK來開發(fā)，但這依然不能改變現(xiàn)存的大量基于老版本SDK開發(fā)的應(yīng)用程序持續(xù)運行；同時眾多SDK功能、邏輯、架構(gòu)、差異巨大，期望利用一種工具分析所有SDK并不現(xiàn)實，還有部分外部SDK從自身平臺利益出發(fā)，將關(guān)鍵代碼存儲于.so文件內(nèi)，給反編譯及分析檢測帶來了更大的工作難度。

本次安全漏洞檢測分析研究選取了35個使用較為廣泛并包含網(wǎng)絡(luò)通信功能的外部Android應(yīng)用程序開發(fā)SDK，涵蓋了數(shù)據(jù)、登錄、地圖、信息推送、移動支付等多種功能類型。研究過程采用FlowDroid、Frida及Xposed分析工具結(jié)合靜態(tài)、動態(tài)污點分析以及二進制插樁應(yīng)用程序分析方法開展分析研究[5]。

1 相關(guān)工作

從眾多主流Android應(yīng)用程序功能可以看出：越來越多的SDK集成了軟件公司內(nèi)嵌的客戶端，如用戶評論、授權(quán)登錄、一鍵轉(zhuǎn)發(fā)等功能；當(dāng)程序開發(fā)過程中調(diào)用這些SDK平臺時，實際上是將請求信息數(shù)據(jù)發(fā)送至遠(yuǎn)端服務(wù)器獲取服務(wù)。因此，在開展漏洞檢測之前必須先洞悉此類SDK的運行規(guī)則及動機。

1.1 Android應(yīng)用程序運行規(guī)則

具備網(wǎng)絡(luò)通信功能的外部SDK主要有兩大類：一類是在Android應(yīng)用程序中安裝完成后，自主在終端設(shè)備建立本地服務(wù)器，為SDK平臺提供方收集諸如軟件列表、IMEI碼、GPS數(shù)據(jù)等設(shè)備軟硬件信息，遠(yuǎn)端服務(wù)器會發(fā)送請求信息并從本地設(shè)備獲取數(shù)據(jù)，包括控制應(yīng)用程序在本地設(shè)備的運行狀況。此類SDK通信信道存在被劫持的可能性，惡意攻擊非法獲取本地服務(wù)器數(shù)據(jù)造成隱私泄漏。此類SDK的運行規(guī)則如圖1所示。

圖1 建立本地服務(wù)器的SDK

另一類SDK的應(yīng)用程序僅僅接收遠(yuǎn)端服務(wù)器推送消息，越來越多的主流應(yīng)用程序?qū)SL/TLS安全認(rèn)證功能加入到傳輸協(xié)議中，形成新的HTTPS協(xié)議；只要添加正確并完成配置，就可以杜絕數(shù)據(jù)丟包和信息劫持[6]。而普通的HTTP協(xié)議推送信息并沒有經(jīng)過特殊加密，直接傳輸會造成信息誤收或者接收不完整，存在著很大的安全風(fēng)險，而實際情況是使用HTTP協(xié)議的SDK開發(fā)出的Android應(yīng)用程序依然在大量活躍使用[7]。

1.2 安全問題

部分Android應(yīng)用程序開發(fā)過程中過于強調(diào)程序功能，僅將SDK視為黑盒而忽略了平臺內(nèi)部的安全漏洞。假如這款SDK存在技術(shù)漏洞或暗門，那會造成所有調(diào)用此SDK的應(yīng)用程序全部暴露于安全威脅之下，非法攻擊能通過漏洞或者暗門得到應(yīng)用程序的核心代碼，洞悉程序整體運行細(xì)節(jié)，注入惡意代碼，造成巨大損失。本研究在一些SDK工具中發(fā)現(xiàn)了部分明顯的漏洞，這也是形成統(tǒng)計和分析35個外部SDK的原因。

1.2.1 建立本地服務(wù)器的SDK

Moplus是國內(nèi)知名搜索公司發(fā)布的SDK，在解析設(shè)備應(yīng)用程序的manifest文件時發(fā)現(xiàn)，當(dāng)用戶Android設(shè)備啟動調(diào)用該SDK的應(yīng)用程序時，會觸發(fā)相關(guān)應(yīng)用程序獲取權(quán)限的行為，并在用戶不知情的情況下自主建立本地HTTP服務(wù)器。Moplus內(nèi)置的HTTP服務(wù)器持續(xù)掃描檢測TCP端口，接收和解析遠(yuǎn)端服務(wù)器和本地設(shè)備以便獲取位置、用戶身份等隱私數(shù)據(jù)信息。非法HTTP請求能替換本地服務(wù)器內(nèi)置的action并執(zhí)行惡意代碼，造成用戶信息被劫持。甚至攻擊者還可能向用戶設(shè)備私自添加聯(lián)系人，掃描設(shè)備文件，搜集并上傳特定數(shù)據(jù)，而所有這些操作都可以簡單地發(fā)送非法HTTP請求來完成。

1.2.2 銀行登錄SDK

圖2是某銀行登錄SDK使用HTTPS協(xié)議與遠(yuǎn)端服務(wù)器通信的代碼，經(jīng)過測試發(fā)現(xiàn)該SDK中的驗證證書查驗函數(shù)返回值為空，也就是說無法驗證遠(yuǎn)端服務(wù)器發(fā)來的證書是否是合法證書，這會被攻擊者通過偽造或者替換非法證書實施攻擊。本次研究在模擬過程中加了一個代理服務(wù)器，并用非法證書替換服務(wù)器返回的合法證書，實現(xiàn)了非法替換攻擊。

圖2 非法證書替換

1.2.3 信息推送SDK

為了獲得廣告收益，部分應(yīng)用程序的開發(fā)基于某廣告公司發(fā)布的SDK，分析該SDK相關(guān)文檔發(fā)現(xiàn)其使用HTTP協(xié)議與遠(yuǎn)端服務(wù)器通信，如圖3所示；若攻擊者使用代理服務(wù)器來檢測和分析HTTP通道的數(shù)據(jù)傳輸、響應(yīng)等信息[8]，即可輕易獲得用戶Android設(shè)備的IMEI、廣告信息、圖片推送等，并且可以將信息內(nèi)容改寫為惡意威脅病毒網(wǎng)站，當(dāng)用戶點擊推送信息時，訪問預(yù)置的病毒URL，造成用戶信息泄漏，利用信息劫持與替換對用戶造成更大損失，部分釣魚網(wǎng)站就是采取這種手段誘導(dǎo)用戶點擊廣告鏈接進入目標(biāo)URL實施欺騙[9]。

圖3 某信息推送SDK的數(shù)據(jù)通信信息

2 SDK選擇與分析

為了保證待分析的SDK就是應(yīng)用程序所使用的SDK，以往不少研究多從Android應(yīng)用程序中逆向編譯抽取外部SDK，但這種做法存在一些不確定性：首先，程序開發(fā)過程中外部SDK是靜態(tài)鏈接到程序字節(jié)碼中的，造成應(yīng)用程序和SDK代碼之間的界限模糊淡化；其次，開發(fā)過程中使用了類似于ProGuard的字節(jié)碼混淆工具造成標(biāo)識符重名。通過標(biāo)識符重命名將標(biāo)識符轉(zhuǎn)換成短而且無意義的字符串，如將報文名“com.sina”轉(zhuǎn)換為“a.c.”，雖然這是一種無副作用的字節(jié)碼混淆技術(shù)，但卻影響了分析工作的效率和準(zhǔn)確性，最后會導(dǎo)致對于隱私和安全違規(guī)的追責(zé)對象難以確定。例如許多與安全相關(guān)的分析研究了應(yīng)用程序中的隱私與安全問題,提高了人們對于各種問題領(lǐng)域的認(rèn)識,包括隱私泄漏、權(quán)限使用、動態(tài)代碼加載、SSL/TLS(內(nèi)部)安全性、加密API的誤用等。然而這些報告并不能區(qū)分應(yīng)用程序開發(fā)人員代碼和外部SDK中的代碼，而且分析結(jié)果是基于每個應(yīng)用程序的，因此很難精準(zhǔn)識別不正當(dāng)行為到底是由應(yīng)用程序開發(fā)代碼還是外部SDK代碼導(dǎo)致的。為了提高第三方SDK分析的效率，同時保證準(zhǔn)確識別應(yīng)用程序安全問題主要責(zé)任方，本研究并未從Android應(yīng)用程序中提取SDK，而是主要通過以下兩種途徑獲?。阂皇歉鱾€公司或者廠商公開發(fā)布的SDK及其應(yīng)用軟件(如銀行、高德地圖)；二是從知名提供網(wǎng)站www.sdk.cn下載收集部分SDK和應(yīng)用，該網(wǎng)站提供了數(shù)百種廣泛使用的外部SDK供開發(fā)人員選擇使用。

本次SDK分析研究過程主要包括3個步驟：

(1)研究SDK集成手冊、Demo應(yīng)用程序、manifest文檔及開發(fā)清單，獲取開發(fā)過程中組件和權(quán)限被添加到應(yīng)用程序清單的信息。

(2)實施靜態(tài)自動分析[10]、數(shù)據(jù)包獲取、動態(tài)污點分析[11]。靜態(tài)自動分析(如圖4所示)中，對待分析SDK的Demo程序進行反編譯并利用Mallodroid開展代碼審計和SSL/TSL自動分析。但是Mallodroid自動分析存在一些約束和限制，不能保證敏感數(shù)據(jù)使用SSL/TSL配置正確和安全，無法檢測遠(yuǎn)端服務(wù)器上的安全威脅；也不能檢測到程序設(shè)計缺陷和排除故障代碼，只能得到相關(guān)問題代碼的基本指標(biāo)。因此有必要在自動分析基礎(chǔ)上有選擇地進行手動分析，驗證自動分析結(jié)果以確保消除假陽性和假陰性[12]。

圖4 Demo程序靜態(tài)自動分析

動態(tài)污點分析(如圖5所示)重點關(guān)注網(wǎng)絡(luò)連接和涉及隱私信息的函數(shù)調(diào)用(如獲取地理位置信息、讀取聯(lián)系人、驗證碼等)，這將有助于后續(xù)階段動態(tài)分析過程中避免程序運行機制導(dǎo)致的誤報和漏報，從而推斷所分析的SDK可能存在的安全隱患。

圖5 動態(tài)污點分析

(3)動態(tài)二進制插樁法測試驗證安全問題。

由于SDK開發(fā)方的服務(wù)器端源代碼的隱私性只能結(jié)合靜態(tài)分析和利用動態(tài)二進制插樁(利用Frida注入代碼)開展黑盒測試，對服務(wù)端收集到的參數(shù)進行讀取和修改，從而驗證該SDK的安全性。具體執(zhí)行過程如下：利用Android模擬器運行Demo程序，在Fiddler中設(shè)置為轉(zhuǎn)發(fā)外部SDK和遠(yuǎn)程服務(wù)器之間的網(wǎng)絡(luò)代理，若SSL/TLS配置錯誤，那么入侵者就能在Fiddler中模擬認(rèn)證來替代真實認(rèn)證。然后用adb shell查閱Demo程序及其相關(guān)的私有目錄，進而獲取lib、數(shù)據(jù)庫、sharedPreference、緩存等信息，甚至檢索和修改未加密數(shù)據(jù)庫中的記錄[13]。整個過程如圖6所示。

圖6 利用Frida注入代碼動態(tài)修改服務(wù)端參數(shù)

3 實驗結(jié)果

本研究系統(tǒng)分析了具有網(wǎng)絡(luò)通信能力的外部SDK，先將其總結(jié)為兩種基本類型:在應(yīng)用程序段建立本地服務(wù)器的SDK和無本地服務(wù)器的SDK；然后對收集到的35個外部SDK開展靜態(tài)分析，從SDK描述文檔和源代碼中提取組件、權(quán)限、網(wǎng)絡(luò)連接等相關(guān)信息，檢測可能存在的漏洞，再通過動態(tài)測試進行驗證。

經(jīng)過分析，將在外部SDK中發(fā)現(xiàn)的安全問題歸為本地服務(wù)器漏洞、HTTP協(xié)議開放、敏感權(quán)限、SSL/TLS配置不當(dāng)4種類型，表1描述了所收集的各種類型SDK中存在的具體安全漏洞類型與數(shù)量，為開發(fā)人員和服務(wù)提供商提供了分析外部SDK安全風(fēng)險的依據(jù)。

表1 本研究收集的35個SDK存在的安全問題類型

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

建立本地服務(wù)器的外部SDK可以收集設(shè)備信息、執(zhí)行系統(tǒng)命令進而獲得設(shè)備的控制權(quán)。如果本地服務(wù)器執(zhí)行了存在漏洞的訪問控制，攻擊者就會可以通過訪問來檢索敏感數(shù)據(jù)甚至后臺控制設(shè)備。比如前文提到的Moplus SDK，它是某搜索引擎公司開發(fā)供內(nèi)部使用的SDK，因此采用包含該SDK的應(yīng)用程序來研究其安全性。通過對基于該SDK的某地圖軟件做靜態(tài)自動化分析和動態(tài)分析，發(fā)現(xiàn)有個別進程在監(jiān)聽TCP 40310端口。當(dāng)用戶Android設(shè)備運行包含Moplus SDK的應(yīng)用程序時，此SDK會在后臺會自動設(shè)置一個JAVA開源HTTP服務(wù)器NanoHttpd，用于檢測通過socket的消息，并且在程序運行過程中持續(xù)偵測監(jiān)聽TCP端口40310，接收并解析從遠(yuǎn)程服務(wù)器或客戶端發(fā)送的指令。一旦有新的HTTP請求，本地服務(wù)器將會接收并解析消息頭和消息體，然后根據(jù)信息內(nèi)容執(zhí)行惡意操作。遠(yuǎn)程服務(wù)器可以發(fā)送請求來獲取位置信息，搜索框信息，包信息和用戶設(shè)備的其他敏感數(shù)據(jù)。此外，攻擊者可能會利用sediment命令向用戶的設(shè)備發(fā)送指令，后臺下載程序，收集特定程序文件，這些惡意操作都可以通過發(fā)送HTTP請求來完成。

雖然新版本的SDK已刪除了這些漏洞，但是許多Android用戶并未及時更新，設(shè)備運行的依然是舊版本程序。

3.2 開放HTTP

眾所周知利用HTTP協(xié)議建立網(wǎng)絡(luò)連接存在較大的安全隱患，但事實上大量SDK依然使用此通道與服務(wù)器通信，也有SDK將諸如IMEI信息等用戶隱私數(shù)據(jù)通過HTTP協(xié)議以明文或者密文的形式傳送。

(1)明文傳送：開發(fā)人員采用移動廣告商家發(fā)布廣告類SDK可以在一定條件下植入廣告相關(guān)信息以獲取收益。在這部分SDK的靜態(tài)自動化分析過程中發(fā)現(xiàn)其未使用SSL/TLS安全協(xié)議加密，并且還將用戶設(shè)備的IMEI、型號以及應(yīng)用開發(fā)者的key發(fā)送到服務(wù)器端[14]。惡意攻擊者可以通過截取該SDK與服務(wù)器端的通信收集用戶信息，也可能替換數(shù)據(jù)攻擊用戶。在動態(tài)分析中，該SDK通過設(shè)置的代理服務(wù)器來獲取服務(wù)器端的網(wǎng)絡(luò)數(shù)據(jù)包，結(jié)果表明該SDK使用HTTP協(xié)議以明文形式傳輸數(shù)據(jù)，相當(dāng)于把用戶敏感信息公開在網(wǎng)絡(luò)上。在本次研究收集的35個外部SDK有13個SDK包含此漏洞。

(2)密文傳送：短信驗證SDK是一種可以為應(yīng)用程序提供短信驗證的外部SDK，逆向分析該SDK工具包中的.jar文件發(fā)現(xiàn)其通過本地自定義加密函數(shù)對發(fā)送的數(shù)據(jù)進行了加密，并在核心函數(shù)中調(diào)用了.so文件[15]。然而惡意攻擊者也可以通過對該SDK的逆向分析破解數(shù)據(jù)的加密算法和本地密鑰，進而實現(xiàn)對用戶與服務(wù)器端交互數(shù)據(jù)的解析(如圖7所示),對用戶造成信息泄漏以及帶來更大的安全風(fēng)險。在分析的35個SDK中，有6個利用HTTP通道傳輸數(shù)據(jù)的SDK使用的是本地加密密鑰而不是與遠(yuǎn)程服務(wù)器協(xié)商生成密鑰(如HTTPS協(xié)議)，將加密算法和加密密鑰記錄在.so文件中，導(dǎo)致程序運行的完整性和隱私性受到很大威脅。

圖7 短信驗證SDK所發(fā)送的本地加密信息

3.3 SSL/TLS配置不當(dāng)

HTTPS是在HTTP協(xié)議下加入SSL層，必須恰當(dāng)和正確配置才能保證通信信道安全，實現(xiàn)網(wǎng)絡(luò)連接安全方面的升級[16]。應(yīng)用程序運行時必須查驗主機名和服務(wù)器是否匹配以判斷主機名是否有效，同時檢查證書鏈的有效性。如果主機名與服務(wù)器的域名匹配則視為主機名有效；如果證書鏈中的每個證書都沒有過期或撤銷，根證書也是由CA在客戶端的密鑰庫中發(fā)起的，并且這些證書均由CA在鏈中簽名，才能夠判定該證書鏈接為有效證書[17]。

X509TmstManager接口是Android系統(tǒng)的證書信息管理器，通過它來執(zhí)行安全socket檢查。有惡意攻擊者通過該接口重寫證書驗證過程并清空驗證方法例程，允許非法驗證通過。當(dāng)SDK執(zhí)行證書驗證時發(fā)現(xiàn)過期、吊銷、非法等情況，讓應(yīng)用程序即使發(fā)現(xiàn)非法證書的情況下也不做出任何異常提醒，這類威脅在一些來路不明的SDK中較為普遍。在分析的35個外部SDK中發(fā)現(xiàn)有6個信息推送類SDK存在SSL/TLS配置不當(dāng)?shù)膯栴}。

3.4 過多索取敏感權(quán)限

從應(yīng)用程序開發(fā)者角度很容易理解多數(shù)Android程序運行時會請求獲取多于運行所需的權(quán)限以便備用，程序在調(diào)用SDK時，將數(shù)據(jù)、組件、權(quán)限等信息加入到manifest文件中，而非運行程序必需的權(quán)限則被用于獲取用戶設(shè)備信息、個人隱私等目的[18]。例如某些信息推送SDK請求拍照、攝像、短信讀取等權(quán)限。在對類似廣告和信息推送類SDK分析之后其實這些權(quán)限對于核心功能來說完全不需要。還有些SDK共享主機應(yīng)用程序manifest文件中的權(quán)限，如果manifest文件聲明,它就可以使用這些權(quán)限，通過調(diào)用SDK中的主機代碼查驗來判斷主機是否獲取了某項權(quán)限(如圖8所示)，而這些在基于該SDK開發(fā)的應(yīng)用程序說明文檔中卻看不到申請這些權(quán)限的描述。在收集的35個外部SDK中發(fā)現(xiàn)其中有8個SDK存在申請過多權(quán)限的問題引起不必要的安全威脅。

圖8 Android應(yīng)用程序中的權(quán)限查驗

4 結(jié)束語

隨著移動互聯(lián)網(wǎng)技術(shù)的飛速發(fā)展和Android應(yīng)用的指數(shù)級增長，Android系統(tǒng)和應(yīng)用程序的安全問題需求和呼聲也越來越高。針對這些情況，本研究收集了部分基于Android系統(tǒng)中具有通信功能的外部SDK開發(fā)的程序，對具備網(wǎng)絡(luò)通信能力的SDK的安全風(fēng)險進行了全面分析。在參與分析的35個SDK中，半數(shù)以上存在前文所述的各種類型的漏洞，同時還有類似身份驗證、開發(fā)中的ID命名失誤等漏洞，導(dǎo)致基于這些SDK開發(fā)的應(yīng)用程序?qū)⒃斐纱罅坑脩舻碾[私和安全問題。根據(jù)上述實驗分析結(jié)果，本文針對外部SDK的使用提出如下總結(jié)以減少風(fēng)險：

(1)使用率高的SDK如果存在安全漏洞，帶來的安全隱患和風(fēng)險就越大。例如Moplus SDK影響大約上千個下載次數(shù)達(dá)百萬級的應(yīng)用程序。由于外部SDK是由服務(wù)商各自研發(fā)的，技術(shù)水平參差不齊，開發(fā)目的也不盡相同，因此開發(fā)者應(yīng)該提高警惕在引入外部SDK時可能存在的安全風(fēng)險。

(2)驗證證書存在安全問題較為普遍，SSL/TLS漏洞在外部SDK中很常見，SSL/TLS應(yīng)正確配置才能夠確保通信安全。而Root設(shè)備將會帶來無法預(yù)料的安全風(fēng)險，如非必要建議不要Root設(shè)備。

(3)針對敏感權(quán)限的不必要索取，開發(fā)人員應(yīng)建立對應(yīng)的SDK保護機制，避免因為共享manifest文件來直接獲取過多的和程序功能無關(guān)的權(quán)限，開發(fā)人員也可以將反射機制關(guān)鍵代碼置于.so文件中保護SDK代碼。