1、移动APP第三方SDK漏洞挖掘实战目录 关于我们 第三方SDK安全现状 漏洞挖掘实战 一些思考第三方SDK安全现状*http:/ 关于我们 第三方SDK安全现状 漏洞挖掘实战 一些思考ANDROID安全基础知识1.应用沙盒基于Linux的权限控制机制应用安装后分配UID和GID使用UID来限制对文件的访问，理论上应用无法访问其他应用的私有文件*使用GID来限制对资源的访问，应用申请权限后，其UID被添加到权限对应的用户组中权限与GID映射关系:/data/etc/platform.xml安装时/运行时申请所需权限，由系统/用户进行控制*2.INTENTAndroid中常见IPC形式属于一种IP

2、C消息对象，用于APP组件间通讯同进程/跨进程startActivity()/startService()/bindService()/sendBroadcast()使用Action或ComponetName等指定目标组件可以携带额外数据（Extras）ANDROID安全基础知识3.组件安全Android APP的基本组成部分-Activity-Broadcast Receiver-Content Provider-ServiceAndroidManifest.xml文件中声明组件可声明为对外导出/应用私有可使用权限对其保护ActivityReceiverProviderServiceANDR

3、OID安全基础知识3.组件安全导出组件导出的组件可被任意应用访问android:exported=trueBroadcastManger.registerReceiver()带有标签的组件，未设置android:export=false情况下，默认导出私有组件私有组件多包含应用敏感功能，并且对输入数据校验较少越权访问其他应用私有组件(应用沙盒逃逸)存在严重安全隐患ANDROID安全基础知识以jar包/so库形式集成到应用中，封装了丰富的功能对开发者而言，属于黑盒，无法审计其安全性使用广泛，SDK中漏洞影响范围同样广泛在应用中集成SDK提供的组件、添加特定权限等SDK安全性无法保证应用被引入更多

4、攻击面存在的风险Activity+SDK中提供ActivityReceiver+SDK中提供ReceiverProvider+SDK中提供ProviderService+SDK中提供Service第三方SDK漏洞挖掘第三方SDK漏洞挖掘存在的风险利用SDK中存在的漏洞，恶意应用甚至无需任何权限绕过沙盒限制，访问应用私有组件推送恶意通知消息诱导访问钓鱼网站获取短信验证码访问用户隐私数据任意代码执行PUSH SDK推送SDK-A-官方文档中引导开发者添加一个导出的Receiver-导出的Receiver具体功能由开发者实现-“指导”开发者留下攻击入口 推送SDK-A-某市地铁官方APP-集成推送S

5、DK-A-导出Receiver xxxxxCustomerReceiver-xxxxxCustomerReceiver中解析Intent传入数据，app内打开指定url-POCPUSH SDK推送SDK-A-某市地铁官方APP-访问恶意钓鱼页面PUSH SDK推送SDK-B-指导用户添加导出的Receiver-导出的Receiver继承自com.xxx.android.xxxxx.xxxBaseReceiverPUSH SDK推送SDK-B-com.xxxxx.android.xxxxx.xxxBaseReceiver中处理push消息-下发的消息经RSA加密，App本地进行解密，解密成功后展

6、示给用户-然而.-SDK中存在一个加密方法，攻击者可调用该加密方法，对伪造的消息进行加密PUSH SDK推送SDK-BPUSH SDK推送SDK-B-XX信用卡管家-集成了推送SDK-B，添加了导出的Receiver-攻击者通过调用SDK中的加密方法，构造恶意推送消息-利用导出的Receiver弹出钓鱼通知-POCPUSH SDK影响范围PUSH SDK分享类SDK分享SDK-A-SDK中存在导出的Activity，XxShareXxXxxxxActivity-将输入字符串作为组件名称，未经校验直接启动指定的组件-恶意应用可绕过应用沙箱限制，越权访问任意私有Activity-XxShareXx

7、XxxxxActivity中接收Intent传入字符串-未经校验情况下，将传入字符串作为ActivityName进行保存-在当前应用Context中调用startActivity启动ActivityName指定Activity分享SDK-A分享类SDK利用1 通用拒绝服务-Activity启动时需要传递参数/进行一些初始化操作/.-利用SDK漏洞强制调用未导出Activity-异常处理不当，触发应用崩溃-编写测试工具，对大量应用进行批量测试-集成了该SDK的应用中，90%+存在该问题分享类SDK利用1 通用拒绝服务分享类SDK利用1 通用拒绝服务-集成了该SDK的应用中，90%+存在该问题-国

8、内大量知名厂商应用，均受此漏洞影响分享类SDK利用2 应用密码锁绕过-应用中保存了用户隐私数据，进入应用时需要输入正确密码-常见于金融类、IM类应用中-利用该SDK漏洞，越权访问包含重置密码、设置密码等敏感功能组件-应用中高权限组件鉴权不严格，导致密码锁被绕过/重置等-测试发现，许多知名厂商的app均存在该问题，例如分享类SDK利用2 应用密码锁绕过分享类SDK-为便于线上定位bug，许多应用release版中存在调试代码-应用Log开关、自定义线上服务器地址、导出用户数据等敏感功能-调试功能一般在UI上没有直观入口，普通用户无法轻易接触到-如调试模块涉及敏感操作，本质上如同一个后门-利用该S

9、DK漏洞，遍历应用所有未导出组件，发现隐藏的调试功能利用3-越权开启调试模式分享类SDK利用3-越权开启调试模式-某企业级IM应用中，发现存在多个包含调试功能的未导出组件-逆向分析确定，UI上存在隐藏的入口进入调试-但通过UI启动调试组件，需要输入密码:(-鉴权不严格，利用该SDK漏洞，绕过密码保护，越权开启调试功能分享类SDK以及-普通用户身份登录-利用SDK漏洞打开管理员权限功能-服务端对用户身份校验不严格-部分管理员功能可被越权调用分享类SDK影响范围分享类SDK修复状态分享类SDK目录 关于我们 第三方SDK安全现状 漏洞挖掘实战 一些思考一些思考开发者方面供应商方面-提升发现安全问题的能力-对待安全问题态度，积极修复 or“我们已知，但是”-.-培养安全意识-接入SDK前，评估其安全性-及时关注SDK版本更新-应用发布前，寻找专业安全团队进行安全性测试-.谢 谢！