随着Android市场份额的快速增长， Android应用程序开发人员的数量也增长迅速[1， 2].为了缩短开发时间和提高开发效率， Android应用开发商将多种类型的第三方SDK(软件开发工具包)集成到他们的应用程序中.这些SDK是由广告、数据、社交网络、地图和推送平台等第三方服务提供商所开发的工具包[3]， 可以提供专业的服务， 其中封装了复杂的逻辑实现以及请求响应的过程， 使其更便于开发人员使用.不难看出， 第三方SDK已经成为Android生态系统的重要组成部分.
在应用中， 集成第三方SDK的优势是显而易见的:首先， 应用程序可以获得专业公司在各个领域提供的高质量资源， 例如地图(如GoogleMap[4])、交通数据、天气数据等; 其次， 如果应用程序将类似PayPal[5]的第三方SDK包含在内， 它就可以执行像付款这样复杂的功能.这些SDK有助于提高应用的开发效率， 并且实现更加健壮， 尤其是对于小型的开发团队.另外， 广告平台(例如AdMob[6])这种第三方SDK可以帮助应用程序的开发者获得收益.
然而， 与此同时， 第三方SDK也会对Android用户的隐私和安全性产生威胁.许多研究[7-11]证实， 一些第三方SDK存在隐私泄露问题.Taomike(中国最大的移动广告提供商)和百度提供的第三方SDK被曝出存在安全漏洞， 这两个软件秘密监视用户， 将敏感信息上传到远程服务器， 并在用户的设备上开启后门[12， 13].然而， 这些SDK已经集成到众多Android应用中， 影响了超过1亿的Android设备用户.除了侵犯用户隐私以外， 有些第三方SDK还会采取不安全的实现方式， 增加其宿主应用程序的攻击面， 从而对用户安全造成威胁.甚至是Facebook和Dropbox这种信誉良好的软件公司的SDK也被发现存在严重的安全漏洞.这些漏洞带来的攻击包括:将敏感数据泄露到公开可读的数据源[14]、代码注入攻击[15， 16]、帐户劫持[17]、将受害者设备连接到攻击者控制的Dropbox帐户[18-21]等.
不难看出， 减少第三方SDK中的安全问题将有效缓解android用户所面临的安全风险.然而， 对第三方SDK进行系统性的安全分析不是一件轻松的工作:一方面， 我们只能在官网上找到最新版本， 但是它们的旧版本仍然在大量的应用中使用; 另一方面， 不同类型的第三方SDK具有不同的架构， 这使得设计出一个分析SDK的系统是十分困难的.另外， 我们发现很多的第三方SDK将其关键代码放到.so中， 这增大了逆向工程的难度.
本文着力于对Android生态系统中较流行第三方SDK的安全性进行全面分析.由于具有网络通信能力的SDK更加重要、更加流行， 所以我们把焦点放在这种类型的SDK上面.本文汇总了129个第三方SDK， 包含广告、数据、推送、登录等10个类型， 并且对每个类型中流行的第三方SDK进行了深入分析.在分析过程中， 我们使用了有效的Android应用分析方法(例如静态污点分析、动态污点分析和动态二进制插桩)和分析工具(例如flowdroid， Xposed和frida).本文贡献如下:
(1) 本文系统分析了具有网络通信能力的流行第三方SDK， 并将其总结为两种基本类型:在应用端开启本地服务器的SDK和无本地服务器的SDK.
(2) 本文对具备网络通信能力的SDK的安全风险进行了全面分析.我们收集了129个知名的第三方SDK， 通过静态分析， 从其文档和源代码中提取相关信息(例如组件、权限、网络连接)， 然后检测可能存在的漏洞， 并通过动态测试进行验证.
(3) 经过分析， 我们将在第三方SDK中发现的安全问题总结为6种类型， 这些类型将在第4节中介绍.我们的分类非常全面， 为开发人员和服务提供商提供了分析第三方SDK安全风险的依据.我们从这些SDK中找到并验证了几个意料之外的漏洞.此外， 本文揭露了较流行的第三方SDK中存在的尚未被发现的安全问题.研究结果表明第三方SDK面临许多安全问题， 这些问题给大量应用程序以及用户带来威胁.
本文第1节描述第三方SDK， 研究具有网络连接功能的SDK的操作机制， 提出分析和调查第三方SDK的动机.第2节详细介绍我们使用的方法以及分析过程.第3节介绍我们在分析中发现的在第三方SDK中普遍存在的漏洞.第4节讨论SDK中存在的安全问题所带来的影响， 并提出一些补救措施.
1 背景和动机在Android生态系统中， 第三方SDK是指由第三方服务公司提供的具有特定功能的软件开发工具包， 例如广告、推送、图像识别技术、移动支付技术等.为了提高应用开发效率， 开发人员将第三方SDK集成到项目中来实现这些功能， 包括广告、第三方登录、转发评论、虚拟现实等.不难看出， 大多数第三方SDK只是第三方服务的客户端.当这些SDK被调用时， 它们需要连接远程服务器来提供服务.
本文重点讨论具备网络通信能力的第三方SDK.根据其功能， 我们进一步将SDK分为以下几类:广告服务、支付平台、推送消息服务、第三方登录服务、监控工具、地图服务、数据服务、社交评论平台、社交共享平台.针对每种类型， 我们下载流行的第三方SDK， 分析它们的运行机制， 并检测安全漏洞.
1.1 运行机制如本文开始部分所述， 本文专注于具有网络连接功能的第三方SDK.我们分析了这些SDK的运行机制， 并总结为两种类型.
(1) 第三方SDK向远程服务器发送请求
图 1展示了这种类型SDK的运行机制， 例如， 提供广告服务、推送消息服务的第三方SDK采用这种机制.由于HTTP没有加密传输数据， 因此不能保证数据隐私以及完整性.HTTPS(超文本传输安全协议)是一种用于在不可信网络上实现安全连接的网络通信协议， 它将SSL/TLS的安全功能添加到标准HTTP(超文本传输协议)通信中， 因此只要正确实现并配置， 就可以防止窃听和中间人攻击.使用HTTPs替代HTTP已成为一种趋势， 然而仍有许多第三方SDK使用HTTP协议， 通过网络连接到云服务器， 这意味着很高的安全风险.
Fig. 1 Third-Party SDK with built-in server
图 1 未含有内置服务器的第三方SDK
(2) 第三方SDK启动本地服务
有些第三方SDK在主机应用程序中设置本地服务器， 以确保这些SDK的制造商可以可控地监视移动设备.本地服务器能够收集当前设备中的位置、IMEI、安装信息等信息， 而远程服务器可以发送请求并从本地服务器检索这些信息.甚至是远程安装与卸载也可以通过与本地服务通信来实现.图 2描述了这种类型的SDK的工作机制.虽然我们可以采取一些措施来使本地服务器由正确的远程服务器控制， 但是我们的通信信道可能被攻击者劫持， 这使得攻击者能够与本地服务器交互.我们将在第2节给出一个劫持攻击的真实例子.
Fig. 2 Third-Party SDK without built-in server
图 2 含有内置服务器的第三方SDK
1.2 动机
许多移动应用开发人员将第三方SDK视为黑盒， 只关注其功能， 因此容易忽视其内部的安全漏洞.显然， 使用具有安全漏洞的SDK会使应用程序易受攻击.举例来说:如果一种SDK中存在后门， 则使用此SDK的所有项目都会有该后门， 这使得攻击者可以非法访问应用程序的核心代码.第三方SDK具有与其主机应用程序相同的权限， 因此， 即使应用程序的核心功能不需要， 应用程序也必须请求SDK所需的权限.SDK中存在安全漏洞会造成很大的危害， 这会使包含这些SDK的应用程序都受到影响.本节的最后部分给出了一些易受攻击的SDK的例子， 这些例子是本文工作的动机.
● 广告SDK
Kuguo是移动广告平台类的SDK， 它已经被开发商集成到许多应用程序中来获利.Kuguo的官方网站宣布， 智能手机用户数已达3.6亿户， 有71 042种移动应用正在使用Kuguo平台.在官网上下载到Kugou的文档以及SDK文件非常容易.通过对这些文件的分析(详细分析过程将在第2节中给出)， 我们可以了解这个SDK的运行机制， 如图 3所示.我们发现， Kuguo SDK使用HTTP协议与远程服务器通信， 因此我们设置了代理服务器来检测HTTP通道上的数据包传输、请求和响应数据， 如图 3所示(在请求数据包中可以看到IMEI、包名等信息， 在返回数据包中可以看到广告的链接和广告图片).我们可以替换响应中的数据， 例如， 将URL替换为我们构建的钓鱼网站， 当用户点击广告时， 假冒的URL将被打开并显示在浏览器中.攻击者可以利用此钓鱼网站对用户采取进一步的攻击.
Fig. 3 Request and response data of Kuguo SDK
图 3 Kuguo SDK的请求和返回数据
● 某银行第三方登录SDK
该第三方登录SDK(BOCOPPaySdk)使用HTTPS与远程服务器通信.如图 4的代码所示(该SDK中的证书查验函数实现为空， 可以被中间人通过替换证书进行攻击)， 登录SDK无法验证服务器发送的证书， 因此攻击者有机会启动中间人攻击拦截证书，tp官方下载安卓最新版2025 并用伪造的证书来替换.在实验中建立了一个代理服务器， tp钱包安卓版下载 并使用伪造证书对服务器所返回的证书进行了替换， 实现中间人攻击.
Fig. 4 Code implementation of certificate verification
图 4 证书查验实现
● 具有本地服务器的第三方SDK
Moplus是由中国搜索引擎巨头百度开发的SDK.由于我们无法下载Moplus的原始文件， 所以我们选择分析包含它的应用来研究其权限和行为.经过对主机应用的manifest文件进行解析， 我们发现SDK在一个单独的进程中， 其主要服务被称为com.baidu.android.moplus， 该服务可以通过不同的广播来触发， 例如系统启动的广播.
当用户启动包含moplus SDK的应用程序时， 此SDK将自动并秘密地设置本地HTTP服务器， 以便通过socket消息进行监视[22].moplus通过内置NanoHttpd来达到这一目的， NanoHttpd是由JAVA编写的一个开源HTTP服务器.HTTP服务器不断监听TCP端口， 接收并解析从远程服务器或客户端发送的消息.一旦有新的HTTP请求， 本地服务器就用接收到的消息替换NanoHttpd服务器的action， 然后开始执行恶意操作.远程服务器可以发送请求来获取位置信息、搜索框信息、包信息和用户设备的其他敏感数据.此外， 攻击者可以向用户的设备添加联系人， 扫描下载的文件， 并上传特定文件.所有这些操作都可以通过简单地发送HTTP请求来完成. Sendintent是一种特殊的命令， 用于向主机的应用程序发送指令， 可以在未经用户同意的情况下进行远程调用， 发送错误消息并安装任何应用程序.本地服务不会对请求消息进行身份验证， 因此可以由攻击者触发而无需通过远程服务器.此外， 攻击者可以使用Nmap扫描所有Android设备的TCP端口40310， 并检查端口是否打开.
2 第三方SDK的选择和分析本节将介绍如何选择和分析第三方SDK.
2.1 第三方SDK的选择从Android应用程序中提取第三方SDK， 并不是一个明智的选择:首先， 第三方SDK在应用程序构建过程中被静态链接到应用程序字节码中， 这模糊了应用程序和SDK代码之间的界限， 从而使SDK高度集成到应用程序中; 其次， 应用程序开发人员通常使用类似于ProGuard[23]的字节码混淆工具.标识符重命名是一种无副作用的字节码混淆技术， 它将标识符转换成短而且无意义的字符串， 如将报名"com.google"转换为"a.c.".还有一个问题是缺少对于隐私和安全违规的追责方法.举例来说， 许多与安全相关的分析研究了应用程序中的隐私与安全问题， 提高了人们对于各种问题领域的认识， 包括隐私泄露[24-28]、权限使用[29]、动态代码加载[30]、SSL/TLS(内部)安全性[31， 32]、加密API的误用[33]等.然而， 这些报告不能区分应用程序开发人员代码和第三方SDK中的代码， 而且分析结果是基于每个应用程序的， 不能识别不正当行为到底是由应用程序开发人员还是第三方SDK开发人员造成的.
为了提高第三方SDK分析的效率， 同时保证问题制造者(应用程序或开发者)对破坏安全或隐私负责， 我们从官方网站收集了一些第三方SDK和相关应用程序.第三方SDK有几个热门的汇总网站， 例如， AppBrain和SDK.cn.网站中有数十种流行的第三方SDK可用， 但它们只是第三方SDK中的一小部分.AppBrain专注于Google Play， 而SDK.cn更侧重中国市场.许多第三方SDK只在一个开发者小组或一个特定市场(北美、欧洲、亚洲等)流通.比较受欢迎的第三方SDK往往有多个版本.此外， 一些第三方SDK对于普通开发人员不可用， 而是仅针对他们自己的产品开发.
与Android应用程序可以从Google Play等市场上获取不同， 第三方SDK一般由第三方供应商提供， 因此收集有些SDK并不容易.中国已经封锁了Google Map等多项服务， 因此中国的开发商在Android应用市场开发了定制的SDK以及应用(例如百度地图).考虑到中国智能手机市场份额较大， 我们从中国市场和国际市场收集SDK.针对在第1节中介绍的每个种类， 我们从中国市场和国际市场收集了尽可能多的流行SDK.对于无法直接下载的SDK， 我们选择收集包含这些SDK的应用程序.
2.2 分析过程分析过程包括3个阶段.
● 第1阶段是浏览第三方SDK的开发清单， 包括集成手册、demo应用程序的代码和manifest文件.
● 第2阶段是分析阶段， 包含静态自动化分析、数据包抓取和动态污点分析这3个方面.在静态自动化分析过程(如图 5所示)中， 我们首先对第三方SDK的demo应用进行反编译， 然后进行代码审计(例如WebView不安全API使用、SSL/TLS配置)和污点分析(如图 6所示)， 重点关注网络连接和敏感函数操作(例如获取通讯录).在动态污点分析过程中， 我们可以避免静态分析因无法真实运行而产生的误报和漏报(例如应用程序使用Java反射机制).基于分析结果， 我们推测第三方SDK可能存在的安全问题.
Fig. 5 Static automation analysis of Demo application for third party SDKs
图 5 对于第三方SDKs的Demo应用的静态自动化分析
Fig. 6 Dynamic taint analysis and grabbing interactive data with server
图 6 动态污点分析及与服务器端交互数据包抓取
● 第3阶段， 我们使用动态二进制插桩等方法对可能存在的安全问题进行验证.
(1) 阶段1:浏览第三方SDK的开发信息
第三方SDK供应商提供文档或用户指南来帮助开发人员将SDK集成到应用程序中.我们可以从文档中提取关于将SDK集成到应用程序中时需要将哪些组件和权限添加到应用程序清单的信息.
(2) 阶段2:静态自动化分析、数据包抓取和动态污点分析
在静态自动化分析中， 关于SSL/TLS漏洞的自动检测， 我们使用Mallodroid对所有第三方SDK相关的demo应用进行自动分析.但是该分析仅提供了一个问题代码的基本指标， 它既不能排除死码， 也不能检测到设计中存在的一些主要缺陷.例如， 它不能保证敏感数据流使用SSL/TLS， 同样无法检测到一些系统漏洞， 包括在远程服务器上使用不被推荐的、易受攻击的或不正确的SSL/TLS配置.Mallidroid存在所有自动化方法都会有的限制:在最好的情况下， 自动化分析可以提供一个不完整的分析， 但是在最坏的情况下， 得到的分析可能是不正确的.Mallodroid的文章作者对其检测到的1 074个工具中的100个(9.3%)进行了手动分析， 来验证其发现.然而， 只有41%的应用程序容易受到SSL/TLS中间人攻击.因此， 必须进一步验证此工具的调查结果以消除假阳性和假阴性.
对于每个第三方SDK相关的demo应用， 我们对其使用的敏感Android API(例如getDeviceId()， sendText Message())进行可达性的自动化分析， 检查潜在的危险行为[5， 34-39].除此之外， 我们还检查了反射、动态代码加载、权限探测、JavaScript使用.SDK使用反射需要使用Java.lang.reflect包， 这允许对方法进行可编程调用并访问字段.由于静态分析无法处理使用反射API， 因此我们将通过动态的污点分析来弥补这个缺陷(如图 6所示).对于第三方SDK中的so库， 我们使用IDA Pro进行分析.
另外， 我们使用Fiddler对第三方SDK与服务器端的网路数据进行抓包(如图 6所示).
根据上述分析， 我们可以深入了解第三方SDK与服务器端的通信机制和对敏感信息的使用.基于分析结果， 我们可以推测出第三方SDK中可能存在的的安全威胁(第3节介绍了威胁的分类).
(3) 阶段3:对在第三方SDK中所发现的安全问题进行验证
验证漏洞通过动态执行第三方SDK相关的示例应用来完成.将Demo应用在Android模拟器上运行， 并将Fiddler设置为转发第三方SDK和远程服务器之间的流量的代理.如果没有正确配置SSL/TLS， 那么攻击者可以在Fiddler中创建假认证来替换真实认证.执行完后， 我们使用adb shell来访问相关应用程序的私有目录.在这个目录下， 我们可以获取数据库、lib、sharedPreference、缓存、文件， 并且可以在数据库未被加密的前提下查找数据库中的信息.
因为无法拿到第三方SDK的服务端代码， 我们只能使用黑盒的方式对服务端进行测试.结合静态分析和动态二进制插桩(注入工具:Frida)， 我们可以通过代码注入的方式对SDK提交给服务端的参数进行修改， 以验证安全问题(如图 7、表 1所示).
Fig. 7 Dynamic modification of parameters based on Frida
图 7 基于Frida动态修改参数
Table 1 Analytical methods and tools used in the process of analysis
表 1 在分析过程中使用的分析方法和工具
3 结果
我们的分析验证了第三方SDK中存在多个漏洞， 我们将其分为6种类型.本节将详细介绍这些漏洞， 并描述一些易受攻击的SDK的示例.表 2给出了对分析结果的总结.
Table 2 Vulnerability distribution for the 129 collected third-party SDK
表 2 对于收集的129个第三方SDK所存在的漏洞分布
3.1 V1:滥用HTTP
虽然使用HTTP协议进行网络连接已被认为是不安全的， 但是我们发现许多第三方SDK仍然使用此通道与远程服务器进行通信.更糟糕的是， 一些重要数据还通过HTTP通道以明文或密文的形式传输， 如IMEI(Int'l mobile equipment identity).
● 明文:如第1节所述， 广告平台Kuguo使用HTTP以明文形式传输敏感数据， 攻击者可以劫持这个通道来检索敏感数据.我们总共分析了129个第三方SDK， 其中35个SDK包含此漏洞.其影响及其解决方案已被广泛讨论， 因此在这里， 我们不再赘述.
● 密文:在我们收集的第三方SDK中， 有7个将通过HTTP通道传输的数据进行加密.问题是， 它们使用自定义加密系统进行加密， 加密密钥是本地生成的， 而不是通过与远程服务器密钥协商生成(如HTTPS协议).加密算法和加密密钥写在SDK的.so文件中， 攻击者可以通过解析.so文件来破解加密算法， 这使得应用程序的完整性及其隐私保证受到威胁.
Juhe SMS验证SDK是一种能够让主机应用程序执行SMS消息验证的第三方SDK.经过分析， 我们发现它使用自定义的对称加密算法来加密消息.图 8描述了当Juhe SMS的方法被主机调用时发送的POST数据.数据由Juhe SMS加密， 但它没有关于生成加密密钥的信息.此外， 加密密钥在本地生成， 而不是通过与远程服务器的密钥协商生成(如在HTTPS协议中).Juhe SMS的.jar文件调用.so文件的加密功能.我们可以修改.so文件， 打印出对数据进行加密的密钥.
Fig. 8 Encrypted information sent by Juhe SMS
图 8 Juhe SMS所发送的加密信息
3.2 V2:滥用SSL/TLS
HTTPS(SSL/TLS上的HTTP)只有在恰当的实现和配置下才会使通信信道安全.要想建立安全的SSL/TLS连接， 客户端必须检查证书链和主机名是否有效.如果主机名与服务器的域名匹配， 则该主机名有效.如果证书链符合以下要求， 则被认为有效:(1)链中的每个证书都没有过期或撤销; (2)根证书由CA在客户端的密钥库中发起; (3)在多于1个证书的情况下， 每个证书必须在放入链中后立即由CA签名.文献[40]系统地研究了不正确的SSL/TLS证书验证过程所带来的威胁.通过分析， 我们发现这些威胁在第三方SDK中也很常见.
Android中的X509TrustManager接口可以作为X509证书的信任管理器， 来为安全的sockets执行身份验证.开发人员可以实现X509TrustManager接口， 重写证书验证过程来代替库中的实现.在分析第三方SDK的过程中， 我们发现这些方法的例程是空的.这意味着它们什么也不做， 即使在出现非法证书的情况下也不会抛出异常.此外， 虽然一些SDK执行证书验证， 但即便是证书过期或被吊销， 它们也没有抛出异常.此类漏洞在第三方SDK(例如广告平台和推送式消息平台)中相当普遍.根据分析结果， 有20个SDK包含与SSL/TlS相关的问题.
3.3 V3:滥用敏感权限通常情况下， Android应用程序会请求比所需要的更多的权限.它们使用额外的权限来窥探用户的隐私信息， 甚至植入恶意背景的插件.我们的分析显示， 16个SDK有上述恶意行为.当应用程序开发人员将第三方SDK加入到应用程序中时， 会将某些权限、组件、数据等信息添加到manifest文件中.
Umeng是一个推送消息SDK， 可以请求用来发送SMS、读取SMS和接收SMS的权限.在对其他推送消息SDK分析之后， 我们认为这些权限对于核心功能来说并不是必要的.
另外， 第三方SDK可以与主机应用程序共享manifest文件中的权限， 也就是说， 即使SDK在开发文档中没有声明需要某些权限， 如果manifest文件声明， 那么它也可以使用这些权限.这些SDK利用代码来检查宿主应用程序是否请求了某个权限(执行此检查的代码示例如图 9所示).
Fig. 9 Permission check in Android application
图 9 Android应用中的权限检查
3.4 V4:身份识别
推送消息SDK是第三方SDK中的一个比较常见的类型， 它能够帮助移动应用程序开发商向在用户设备上运行的APP传递消息和通知.推送消息SDK的结构如图 10所示.找到这个服务的结构并不困难， 但是因为该服务需要协调开发人员与应用之间的交互， 这使得它容易出错.
Fig. 10 Structure of Push service
图 10 推送服务的架构
由Google提供的Google Cloud Messaging(GCM)SDK被许多应用程序订阅， 包括Facebook、Oracle、Skype等， 它的运行机制类似于Apple Push Notification Service.据报道， 一些网络犯罪分子使用GCM来控制恶意软件[41， 42].除了Google和苹果之外， 还有许多其他第三方推送消息服务提供商都为应用程序开发人员提供SDK.
某Push-messaging SDK:Push-messaging SDK的云服务器通常利用注册ID与相应的应用程序进行通信.然而， 我们的分析显示， 注册ID会泄露用户的敏感信息.经过分析， 我们发现此Push-messaging SDK所使用的注册ID是基于其国际移动设备标识(IMEI)、国际移动用户身份(IMSI)、MAC地址和包名称在设备上确定生成的.因此， 当我们卸载带有推送消息SDK的应用程序， 然后再在同一个设备上重装后， 该应用程序的注册ID不会改变.如果设备的敏感信息暴露， 攻击者就可以根据它计算注册ID.由于SDK通过注册ID来识别特定设备上的应用， 所以， 如果攻击设备计算出ID并且具有受害者设备， 那么它就有权从远程服务器接收推送消息.为了防御这种攻击， 我们应该增加随机性， 例如引入盐值， 使得注册ID可以不确定地产生.
另外， 该Push-messaging SDK生成的注册ID经对称加密算法(AES)加密后， 存储在共享配置中.然而加密密钥是在本地生成， 而不是通过与远程服务器的密钥协商来生成(如在HTTPS协议中).攻击者可以通过逆向工程获得关键字以及偏移向量， 这有助于解密存储在共享配置中的注册ID.
3.5 V5:本地服务器带来的漏洞如第2节所述， 具有本地服务器的第三方SDK可以收集设备信息， 进而获得设备的控制权.如果本地服务器不适当地执行访问控制， 攻击者就可以访问它， 检索敏感数据， 甚至操纵设备.第2节提到， moplus SDK无法验证请求URL， 因此它可能会被网络犯罪分子触发， 这会给包含此SDK的所有应用程序带来巨大的威胁.
Baidu Map是一个著名的移动应用， 可以提供在线和离线地图搜索服务.由于中国用户无法访问Google地图服务， 因此百度地图在中国被广泛应用.第2节描述了可能的攻击细节.此外， 百度及其他公司开发的约3 000款应用程序的某些版本中包含该SDK， 其中有电话助手、输入、云端、浏览器和视频等.虽然其中一些应用的最新版本已删除此SDK， 但仍有大量用户在使用易受攻击的版本.实际上， 我们使用Nmap扫描了网络上许多设备的TCP端口40310， 发现其中许多设备仍然打开此端口.
事实上， 还有一些其他具有本地服务器的第三方SDK以及许多大众应用程序包含这些SDK， 如Gaode Map、腾讯和360.每个相关的应用程序都拥有大量的用户， 而且这些应用的旧版本仍然在很多设备上运行.
3.6 V6:未关闭日志造成的信息泄漏Android日志系统为开发人员提供了记录应用程序和设备运行状态的接口.日志消息被写入设备的内部存储中.开发人员通常使用android.util.log打印调试信息.但是， 如果他们在应用上线前未关闭日志， 则会成为安全风险.在开发中， 开发人员通常使用debug属性.该代码确定是否输出日志(如图 11所示)， 这使得我们很容易修改调试属性.在Android 4.1版本之前， 具有READ_LOGS权限的Android应用程序能够读取设备上所有应用程序的日志文件.因此， 将敏感数据写入日志会导致敏感数据泄露.在分析中， 我们发现mapbar SDK(专业的电子地图提供商)会将个人身份信息， 如IMEI通过日志进行记录.在我们分析的129个第三方SDK中， 有12个包含此漏洞.
Fig. 11 Attributes of Log in AndroidManifest.xml
图 11 AndroidManifest.xml中的有关Log的属性
3.7 应用程序开发人员的失误
(1) uid误用
一些社交平台如Facebook、Twitter、新浪微博等提供了SDK用于第三方登录， 这可以帮助用户快速完成登录或注册过程， 无需为当前访问的应用程序注册新帐户.这些SDK使用OAuth 2.0协议对用户的账户进行身份验证.如果用户通过认证， SDK的服务器将返回访问令牌和uid(用户在该平台上的唯一标识)到当前应用程序的服务器.之后， 应用程序可以使用访问令牌和uid访问用户授权的资源.然而， 一些应用程序开发人员只使用uid作为用户的凭证， 在这种情况下， 攻击者可以拦截uid， 并将其篡改为指定uid进行登录.
(2) 使用不安全的API
当第三方SDK在WebView中使用JavaScriptInterface时， 远程Web页面可以通过这个接口执行本地命令.当WebView显示页面时， 会在JavaScript代码中调用本地代码.远程网页可以利用反射机制来执行自己的命令(如图 12所示).
Fig. 12 JavaScript code that executes local commands
图 12 JavaScript代码执行本地命令
4 讨论
(1) 第三方SDK漏洞的影响
第三方SDK越流行， 如果存在漏洞， 它所造成的安全威胁就越大.例如， Moplus SDK影响大约3 000个~4 000个下载次数达数百万的应用程序.由于第三方SDK是由第三方服务商各自维护， 安全水平层次不齐.所以， 开发者应该注意引入第三方SDK时可能存在的安全风险.
(2) 证书验证
我们的分析结果表明， SSL/TLS漏洞在第三方SDK中很常见.
(3) 第三方SDK的保护机制
开发人员可以通过以下方式保护SDK的代码:代码混淆; 使用Java反射机制; 将关键代码放在.so文件中; SSL/TLS应正确配置; 请勿root您的设备.
代码混淆、使用Java的反射机制以及将关键代码放在.so文件， 使得静态分析第三方SDK变得更困难.SSL/ TLS正确配置能够确保通信安全.已root与未root的设备相比， 所面临的安全风险大为增加.
5 结论在本文中， 我们分析了在Android生态系统中具有网络通信功能的第三方SDK存在的常见安全隐患.结果显示:在选取的这些SDK中， 超过60%含有各种漏洞(例如HTTP的误用、SSL/TLS的不正确配置、敏感权限滥用、身份识别、本地服务、通过日志造成信息泄露、开发人员的失误).我们希望我们的工作可以引起第三方服务商的关注， 专注于其SDK的安全问题.
