引言
行動應用的快速發展和廣泛應用使得第三方SDK成為行動開發的重要組成部分。第三方SDK以其豐富的功能和便利的整合方式，為開發者提供了快速開發和增強應用功能的途徑。然而，由於第三方SDK的黑盒子性質和廣泛使用，其安全性備受關注。本文將聚焦在行動APP中第三方SDK的安全問題，並透過實戰漏洞挖掘案例，展現潛在的安全風險與攻擊方式。
第三方SDK安全現況：
在行動APP中廣泛使用的第三方SDK存在一些安全隱患。首先，第三方SDK以jar包或so庫的形式整合到應用中，作為黑盒存在，開發者無法審計其安全性。其次，由於使用廣泛，一旦SDK中存在漏洞，將對眾多應用產生影響。此外，整合SDK可能會導致應用程式增加攻擊面，從而增加應用程式的安全風險。
友盟SDK越權漏洞：
在2017年9月發現的友盟SDK越權漏洞。該漏洞存在於友盟的訊息推送SDK中，攻擊者可以利用該漏洞越權調用未導出的元件，從而實現對受影響APP的任意元件的惡意呼叫、任意虛假訊息的通知、遠端程式碼執行等攻擊。約有3萬多APP受此漏洞的影響，約7千多款APP產品，涉及多種類型的應用。
百度SDK被曝後門
趨勢科技在2015年11月發現的百度Moplus SDK後門漏洞。該漏洞存在於百度Moplus SDK中，攻擊者可以利用該漏洞在已經被root的Android設備上靜默安裝應用，從而竊取用戶敏感資訊或控制設備。該漏洞影響了約1億台Android設備，涉及數千款Android應用程式。
涉及金融類供應鏈風險嚴峻
其中，第三方SDK在Android應用供應鏈中存在的安全風險，在金融類APP面臨的風險尤其嚴重。
漏洞挖掘與分析
基本概念
應用沙盒
基於Linux的權限控制機制：應用安裝後分配UID和GID、使用UID來限制對文件的訪問，理論上應用無法訪問其他應用的私有文件、使用GID來限制對資源的訪問，應用申請權限後，其UID被加入到權限對應的使用者群組中、權限與GID映射關係:/data/etc/platform.xml、安裝時/執行時申請所需權限，並由系統/使用者進行控制等。
INTENT
Android中常見IPC形式：屬於一種IPC訊息對象，用於APP組件間通訊、同進程/跨進程
、startActivity()/startService()/bindService()/sendBroadcast()、使用Action或ComponetName等指定目標元件、可以攜帶額外資料（Extras）
組件安全
Android APP的基本組成：Activity、Broadcast Receiver、Content Provider、Service 四大元件。如：xml檔案中聲明：元件可聲明為對外匯出/套用私有、可使用權限對其保護
組件導出安全
匯出元件：匯出的元件可被任意應用程式存取、android:exported=true、registerReceiver()、帶有標籤的元件，未設定android:export=false情況下，預設匯出。範例：
<receiver android:name=”com.xxx.android.pushservice.PushServiceReceiver” android:process=”:xxservice_v1″ >
<intent-filter>
<action android:name=”android.intent.action.BOOT_COMPLETED” />
<action android:name=”android.net.conn.CONNECTIVITY_CHANGE” />
<!– … –>
</intent-filter>
</receiver>
私有元件：私有元件多包含應用敏感功能，且對輸入資料校驗較少、越權存取其他應用私有元件(應用沙盒逃脫)、存在嚴重安全隱患。
漏洞利用方式
利用SDK中存在的漏洞，惡意應用程式甚至無需任何權限、繞過沙盒限制，存取應用程式私有元件、推播惡意通知訊息、誘導存取釣魚網站、取得簡訊驗證碼、存取使用者隱私資料、任意程式碼執行等。
本文提供了幾個實際的漏洞挖掘案例，以展示第三方SDK可能存在的安全風險和攻擊方式。
推播SDK漏洞挖掘
推送SDK是行動應用中常見的功能之一，但其中存在一些安全漏洞。透過挖掘推播SDK中的漏洞，攻擊者可以繞過應用程式沙盒限制，存取應用程式的私有元件，推播惡意通知訊息，誘導用戶造訪釣魚網站等。具體案例包括某市地鐵官方APP整合的推播SDK-A的漏洞，攻擊者透過建構惡意推播訊息和匯出的Receiver，成功彈出釣魚通知。
PUSH SDK
推送SDK – A
- 官方文件中引導開發者新增一個匯出的Receiver
- 導出的Receiver具體功能由開發者實現
- 「指導」開發者留下攻擊入口
<receiver android:name=”您自己定义的Receiver” android:enabled=”true”>
<intent-filter>
<action android:name=”cn.xxxxx.android.intent.REGISTRATION” />
<action android:name=”cn.xxxxx.android.intent.MESSAGE_RECEIVED” />
<action android:name=”cn.xxxxx.android.intent.NOTIFICATION_RECEIVED” />
<action android:name=”cn.xxxxx.android.intent.NOTIFICATION_OPENED” />
<action android:name=”cn.xxxxx.android.intent.CONNECTION” />
<category android:name=”您应用的包名” />
</intent-filter>
</receiver>
在這個案例中是某市地鐵官方APP整合推送SDK
- 匯出Receiver xxxxxCustomerReceiver
- xxxxxCustomerReceiver中解析Intent傳入數據，app內開啟指定url
- POC
市地鐵官方APP訪問惡意釣魚頁面
推送SDK – B
- 指導用戶新增匯出的Receiver
- 匯出的Receiver繼承自com.xxx.android.xxxxx.xxxBaseReceiver
<receiver android:name=”com.xxxx.xxdemo.receiver.MessageReceiver”
android:exported=”true” >
<intent-filter>
<action android:name=”com.xxxxx.android.xxxxx.action.PUSH_MESSAGE” />
<action android:name=”com.xxxxx.android.xxxxx.action.FEEDBACK” />
</intent-filter>
</receiver>
推送SDK – B
xxxxx.android.xxxxx. xxxBaseReceiver中處理push訊息，下發的訊息經RSA加密， App本地進行解密，解密成功後展示給用戶，然而….，SDK中存在一個加密方法，攻擊者可調用該加密方法，對偽造的訊息進行加密。
XX信用卡管家整合了推播SDK – B，新增了匯出的Receiver，攻擊者透過呼叫SDK中的加密方法，建構惡意推播訊息，利用匯出的Receiver彈出釣魚通知。 POC:
影響範圍
分享類SDK漏洞挖掘
分享類SDK在行動應用中常用於實現社交分享功能，然而，某些分享類SDK存在安全漏洞。例如，某分享SDK-A中存在導出的Activity，攻擊者可以繞過應用沙箱限制，越權存取任意私有Activity。透過建構惡意輸入字串，攻擊者可以觸發通用拒絕服務漏洞，導致應用程式崩潰。此外，某些分享類SDK也可能導致應用程式密碼鎖繞過，進而存取使用者的隱私資料。
分享SDK – A
SDK中存在導出的Activity，XxShareXxXxxxxActivity,將輸入字串作為組件名稱，未經校驗直接啟動指定的組件,惡意應用可繞過應用沙箱限制，越權訪問任意私有Activity
XxShareXxXxxxxActivity中接收Intent傳入字串，未經校驗情況下，將傳入字串作為ActivityName進行儲存，在目前應用Context中呼叫startActivity啟動ActivityName指定Activity等。
漏洞利用– 通用拒絕服務：Activity啟動時需要傳遞參數/進行一些初始化操作/….，利用SDK漏洞強制呼叫未導出Activity，異常處理不當，觸發應用崩潰。
編寫測試工具，對大量應用進行批量測試，集成了該SDK的應用中，90%+存在該問題，經統計集成了該SDK的應用中，90%+存在該問題，國內大量知名廠商應用，均受此漏洞影響。
漏洞利用– 應用密碼鎖繞過：應用程式中保存了使用者隱私數據，進入應用程式時需要輸入正確密碼，常見於金融類、IM類應用程式中，利用該SDK漏洞，越權存取包含重設密碼、設定密碼等敏感功能組件，應用中高權限組件鑑權不嚴格，導緻密碼鎖被繞過/重置等，測試發現，許多知名廠商的app均存在該問題，例如…
漏洞利用- 越權開啟調試模式：為便於線上定位bug，許多應用release版中存在調試代碼，應用Log開關、自訂線上伺服器位址、匯出用戶資料等敏感功能…，調試功能一般在UI上沒有直覺入口，一般使用者無法輕易接觸到，如調試模組涉及敏感操作，本質上如同一個後門，利用該SDK漏洞，遍歷應用所有未導出組件，發現隱藏的調試功能，如某企業級IM應用中，發現存在多個包含調試功能的未導出組件，逆向分析確定，UI上存在隱藏的入口進入調試，但通過UI啟動調試組件，需要輸入密碼: ，鑑權不嚴格，利用該SDK漏洞，繞過密碼保護，越權開啟調試功能.
一般使用者身分登入：利用SDK漏洞開啟管理員權限功能、服務端對使用者身分校驗不嚴格、部分管理員功能可被越權呼叫等等。
影響範圍
總結與思考：
行動APP中第三方SDK的安全問題需要被重視與解決。開發者應對整合的第三方SDK進行審計，確保其安全性和可靠性。同時，建議開發者採取以下措施來提高行動APP中第三方SDK的安全性：
1. 選擇可信賴的第三方SDK供應商：在選擇和整合第三方SDK之前，開發者應該對供應商進行充分的調查和評估，選擇那些有良好聲譽和安全記錄的供應商。
2. 定期更新和升級SDK版本：第三方SDK供應商通常會發布更新和修復版本來解決已知的安全漏洞。開發者應該及時更新和升級整合的SDK，以確保應用程式的安全性。
3. 進行安全審計和漏洞挖掘：開發者可以透過安全審計和漏洞挖掘的方式來偵測第三方SDK中存在的潛在安全漏洞。這樣可以及早發現並修復這些漏洞，提高應用程式的安全性。
4. 限制SDK的權限和存取範圍：在整合第三方SDK時，開發者應該對其權限進行審查，並只授予必要的權限。此外，限制SDK對應用私有元件的存取權限，以減少潛在的安全風險。
5. 加強使用者敏感資料的保護：在使用第三方SDK時，開發者應該注意保護使用者的敏感資料。可以採取加密、身份驗證等措施來確保用戶資料的安全性。
最後，行動APP中第三方SDK的安全問題是一個重要的議題。開發者和安全研究人員應該密切注意並加強對第三方SDK的安全審計和漏洞挖掘工作。只有透過共同努力，才能提高行動APP的整體安全性，保護用戶的隱私和資料安全。
原文文章，作者：首席安全官，如若轉載，請註明出處：https://cncso.com/tw/mobile-app-security-from-attack-to-defense.html
