Android生态系统中面向第三方SDK安全的静态和动态分析

蔡迎兵

(陕西学前师范学院 教学设备与实验室管理处， 陕西 西安 710100)

0 引言

目前，国内外在Android系统第三方SDK的安全研究中，主要是针对具体漏洞或威胁的研究[1-2]。如基于聚类算法和AV系统来监测SDK中的安全问题，针对一些具备单点登录功能的SDK下中存在的授权和认证缺陷[3]。在SDK中采用OAuth协议下的安全风险等，并没有提出第三方SDK的一般性安全方法[4-5]。基于此，本文提出了Android生态第三方SDK安全性的分析框架，将第三方SDK的demo作为对象，并采用SDK安全的静态、动态分析方法和分析工具对第三方SDK的安全性进行全面分析。

1 第三方SDK背景和动机

第三方SDK是由第三方服务公司提供如广告、推送、移动支付和图像识别等特定功能的软件开发工具包，开发人员将第三方SDK集成项目来实现多项功能应用，有效提高了应用开发效率。对于大多数第三方SDK通常作为提供第三方的客户端，当调用SDK时，需要连接远程登录服务器。

根据SDK运行机制的不同，主要分为第三方SDK向远程服务器发送请求以及第三方SDK启动本地服务。第三方SDK向远程服务器发送请求机制，由于HTTP(超文本传输安全协议)未加密传输数据，因而难以保证数据完整性和隐私，HTTPS 作为一种用于不可信网络的通信协议，将SSL/TLS的安全功能添加到标准HTTP通信中，只需正确配置就可防止窃听和攻击，使用HTTPS代替HTTP成为趋势，但目前大部分SDK采用的HTTP协议连接到云服务器带来了较高的风险。

2 第三方SDK安全分析

2.1 分析流程

对Android生态中第三方SDK安全分析主要分为3个主要阶段：浏览第三方SDK信息浏览；建立安全分析框架进行静态自动化和动态的第三方SDK分析；对存在的安全问题验证。其中,第三方清单浏览主要从SDK供应商提供的文档中提取关于SDK集成应用程序中的组件和权限程序清单，主要包括浏览第三方SDK的demo应用程序与代码、manifest文件和集成手册等开发清单。本节主要针对分析框架和安全问题验证进行分析。

2.2 第三方SDK分析框架

第三方SDK分析框架主要包括由代码审计和静态污点分析的静态自动化分析以及基于Android设备运行第三方SDK的demo应用执行污点分析的动态分析构成。

2.2.1 静态自动化分析

静态污点分析流程图如图1所示。

图1 静态污点分析的数据抓取

由图1可知,静态自动化分析中，首先根据SDK的demo应用反编译获得其对应的smali代码、manifest文件资源，然后对smali代码设计和静态污点分析。进行代码设计过程中主要是寻找第三方SDK中可能存在的代码缺陷，如SSL/TLS配置问题、WebView使用了不安全的API，本地服务器和日志函数存在缺陷代码等。对于SSL/TLS漏洞检测，使用Mallodrid对第三方SDK的demo应用分析,但该分析不能排除死马，且不能检测部分系统漏洞，如不正确的SSL/TLS配置。Mallodroid在最好的情况下能提供一个不完整的分析，而最坏情况下将会导致分析结果的不正确性。

Smali代码的静态污点分析是寻找第三方SDK是否存在敏感API的收集、敏感信息流寻找和泄露、控制流程图的建设。本文根据相关研究分别将获取敏感信息的AndroidAPI和能获得外部信息的AndroidAPI作为污点source和污点sink。根据smali代码加密控制流图，并标记节点中的敏感API进行敏感数据分析，在控制流图上，选择污点source为入口点，寻找能达到污点sink的路径作为第三方SDK的敏感信息流。

2.2.2 动态分析

当第三方SDK代码中采用Java.lang.reflect包的反射机制进行过动态代码调用时，采用静态污点分析不能调用反射的API，因此需要动态污点来弥补，如图2所示。

图2 动态污点分析的交互数据包抓取

在Android系统中采用hook技术向敏感Android注入代码实现动态污染分析，基于Xposed框架来编写敏感Android API插件注入log代码，当调用getDeviceId()程序时，由于该API中插入了log代码，在日志中记录该调用动作，获取了第三方SDK的动态动作。

通过抓取第三方SDK和服务器端网络数据包还原相互间的交互行为。实验中，采用Fiddler作为服务器与SDK间的代理服务器进行数据交互,当第三方SDK采用HTTPS与服务器端进行数据传输时，通过Fiddler生成签名证书，并将证书发送给Android系统作为可信任的证书对HTTPS进行数据解析。此外，可以使用IDA Pro对第三方SDK的so库进行解析。

2.2.3 安全问题验证

安全问题验证主要通过动态执行第三方SDK的demo应用完成。通过在Android模拟平台运行第三方SDK的demo，设置Fiddler为远程服务器和第三方SDK流量代理，若SSL/TLS配置错误，则攻击者在Fiddler中创建新的签名证书替换真实证书。当应用程序执行完毕后，采用adb shell访问程序私有目录，由于abd shell目录中包括了数据库、lib、缓存、文件等信息，因此在未加密数据条件下访问数据库信息。通常情况下，第三方SDK服务端代码是秘密的，因此，只能结合黑盒测试，通过注入代码的方式修改SDK服务端参数，在静态分析和动态分析上进行安全问题验证。

3 实验结果分析

3.1 检测环境

为验证Andorid生态中第三方SDK的安全分析能力，选取目前流行的第三方SDK进行安全分析。实验设备为Nexus 5X,基于Android 6.0.1操作系统，采用Windows系统的PC机用于第三方SDK的demo应用静态分析、网络数据包抓取。

从官方网站收集149个第三方SDK相关程序，其中包括AppBrain、SDK.cn等多个热门汇总网站。AppBrain更专注于Google Play，SDK.cn侧重于国内市场，目前，较受欢迎的第三方SDK存在多个版本，而一些SDK仅针对自身的产品开发,如表1所示。

表1 第三方SDK类型信息表

3.2 结果分析

分析验证了第三方SDK存在的多个漏洞，根据OWASP Mobile TOP 10将其分为6个类型，分析结果如表2所示。

表2 第三方SDK漏洞分布情况

3.2.1 滥用HTTP

尽管清楚HTTP协议的网络连接存在不安全性，但实际仍然存在第三方SDK采用HTTP进行远程服务器通信，尤其是一些数据通过HTTP通道以明文的形式传输，如在Kuguo广告SDK中，广告平台Kuguo采用HTTP的明文形式传递敏感数据，在149个第三方SDK中，其中有32个SDK报告该漏洞。在收集的第三方SDK中，由7个采用HTTP通道传输的数据加密，加密系统中的加密算法密钥是要写入SDK的.so文件中，而攻击者能通过解析.so文件破解加密算法，导致程序隐私保密性受到威胁。

3.2.2 滥用SSL/TLS

第三方SDK中同样广泛存在着滥用SSL/TIS问题。HTTPS只有在恰当的配置下才能保证信道安全，要建立安全的SSL/TLS连接，客户端检查主机名与服务器域名的匹配。如在Android中的X509TrustManager接口作为X509证书管理器进行sockets的身份验证，开发者可以重写证书来代替库的实现，这样意味着即使在出现非法证书时也不会被抛弃，部分SDK执行证书得到验证，但部分过期或被吊销的证书均未抛弃。

3.2.3 滥用敏感权限

通常Android应用程序会请求额外的权限来窥探用户的隐私信息，更有甚者植入恶意插件。根据分析显示其中有32个SDK上存在滥用敏感权限的恶意行为，当应用程序将第三方SDK加入后，会将部分权限、组件信息加入到manifest文件中，而第三方SDK将与主机同向manifest文件权限，只要manifest文件生命要使用相关权限，则SDK利用代码检查是否请求了该权限。

3.2.4 身份识别

推送消息SDK作为第三方SDK常见类型。推送消息服务启动后向服务器发送设备信息注册，并生成注册ID，SDK和应用服务器分别接收注册ID并发送推送消息。在这个过程中需要应用程序、服务器端和推送SDK端相互配合，容易造成安全问题。为抵御攻击，消息服务器在注册ID时将登录令牌发送给用户，保证注册ID不易伪造，此外消息推动SDK获得的注册ID将通过加密算法加密后进行保存，但这类加密秘钥通常由本地生成，攻击者可利用逆向工程获得关键词，有助于解密户注册ID。

3.2.5 本地服务器漏洞

本地服务器的第三方SDK能收集设备信息来控制设备，当本地服务器采用不恰当的访问控制时，攻击者可检索敏感数据，操作设备，如在Baidu Map作为一类广泛应用，通过第三方SDK插入到旗下近3 000款程序中，通过采用Nmap扫描网络上多个设备的TCP断口40 310，还存在众多设备可打开该端口进入第三方SDK。

3.2.6 信息泄漏

Android日志记录了设备运行状态可接口信息，开发人员可采用android.util.log打印调试信息，当应用上线未关闭日志，则很容易修改调试信息，尤其是在Android4.1版本前，具备READ_LOGS权限的Android应用程序将敏感数据写入日志而造成泄露，根据分析发现mapbar SDK将个人信息写入到日志中，而其中有5个第三方SDK中包含了该mapbar SDK。

4 总结

本文分类了Android生态系统中第三方存在的安全隐患。由于第三方SDK无法独立运行，选择了第三方SDK的demo应用作为分析对象，采用静态污点追踪、动态污点追踪,建立了第三方SDK的静态、动态分析框架。通过动态执行第三方demo应用，注入代码的方式修改SDK服务端参数，进行安全问题验证。最后通过选取目前市场上流行的第三方SDK进行安全性分析，结果显示其中有超过60%的SDK中存在不同类型的漏洞，如HTTP的误用、敏感权限滥用、身份识别等，对相应的应用程序造成严重威胁。