引言

移动应用的快速发展和广泛应用使得第三方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()、带有<intent-filter>标签的组件，未设置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的整体安全性，保护用户的隐私和数据安全。