Android系統外部SDK安全漏洞檢測研究*

馬 杰

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

0 引言

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

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

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

1 相關工作

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

1.1 Android應用程序運行規則

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

圖1 建立本地服務器的SDK

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

1.2 安全問題

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

1.2.1 建立本地服務器的SDK

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

1.2.2 銀行登錄SDK

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

圖2 非法證書替換

1.2.3 信息推送SDK

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

圖3 某信息推送SDK的數據通信信息

2 SDK選擇與分析

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

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

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

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

圖4 Demo程序靜態自動分析

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

圖5 動態污點分析

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

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

圖6 利用Frida注入代碼動態修改服務端參數

3 實驗結果

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

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

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

3.1 本地服務器漏洞

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

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

3.2 開放HTTP

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

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

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

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

3.3 SSL/TLS配置不當

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

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

3.4 過多索取敏感權限

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

圖8 Android應用程序中的權限查驗

4 結束語

隨著移動互聯網技術的飛速發展和Android應用的指數級增長，Android系統和應用程序的安全問題需求和呼聲也越來越高。針對這些情況，本研究收集了部分基于Android系統中具有通信功能的外部SDK開發的程序，對具備網絡通信能力的SDK的安全風險進行了全面分析。在參與分析的35個SDK中，半數以上存在前文所述的各種類型的漏洞，同時還有類似身份驗證、開發中的ID命名失誤等漏洞，導致基于這些SDK開發的應用程序將造成大量用戶的隱私和安全問題。根據上述實驗分析結果，本文針對外部SDK的使用提出如下總結以減少風險：

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

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

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