【20200801】Android系统外部SDK安全漏洞检测研究

SDK(Software Development Kit，SDK)是面向Android应用程序开发人员的工具集合，包括硬件平台基础信息、软件协议框架、操作系统等，其宗旨在于提高Android应用程序的开发效率。许多Android软件供应商提供的大多数Android App的开发普遍基于已有的SDK，在此基础上二次开发做出产品，如果所采用的SDK中存在安全风险或者漏洞，将导致所有基于此SDK开发的App都面临潜在威胁，将对用户的隐私信息保护和Android系统的安全性产生严重的负面影响。事实证明，在外部SDKS开发工具中，的确存在SSL/TLS错误配置、不合理的敏感数据权限分配、HTTP的非必要调用、用户日志泄漏、开发人员考虑不周等漏洞和威胁，造成用户隐私数据面临安全风险。

安全漏洞检测分析研究

当前各种移动智能设备操作系统中Android系统的占有率越来越高，随之而来的就是用户对Android平台的应用程序需求亦呈几何级数增长。为了提高Android应用程序开发质量和效率，许多程序开发人员会在一些由软件公司或商业公司免费提供的软件开发工具(Software Development Kit，SDK)基础上再做二次或者多次开发。这些SDK多数封装了各种专业领域内复杂的逻辑架构、请求响应过程、功能模块，因此能够大大缩短开发时间、保障程序功能可靠性和提高开发效率。
在Android应用程序中，外部SDK优势突出，首先可以保证程序获取该平台提供方的优质资源；其次可以执行复杂、安全、高效的在线功能。在开发人员不足的情况下,这些SDK大大缩短了软件商应用程序的开发周期，并且保证了软件功能的安全和稳定，甚至某些SDK平台会有广告收益，而这对于程序开发人员非常具有吸引力。但是某些SDK架构老旧、更新迟缓甚至包含其他目的，开发人员在不知情情况下推波助澜，对用户数据的安全和隐私信息的保护造成了潜在威胁。
外部SDK的可靠性将直接影响Android应用程序的安全使用，然而以现有的技术对SDK平台的全面漏洞检测与安全分析则需耗费大量的时间与精力，目前开发者所能做的仅仅是使用最新版本SDK来开发，但这依然不能改变现存的大量基于老版本SDK开发的应用程序持续运行；同时众多SDK功能、逻辑、架构、差异巨大，期望利用一种工具分析所有SDK并不现实，还有部分外部SDK从自身平台利益出发，将关键代码存储于.so文件内，给反编译及分析检测带来了更大的工作难度。
从众多主流Android应用程序功能来看，越来越多的SDK集成了软件公司内嵌的客户端，如用户评论、授权登录、一键转发等功能；当程序开发过程中调用这些SDK平台时，实际上是将请求信息数据发送至远端服务器获取服务。因此，在开展漏洞检测之前必须先洞悉此类SDK的运行规则及动机。
Android应用程序运行规则
具备网络通信功能的外部SDK主要有两大类：一类是在Android应用程序中安装完成后，自主在终端设备建立本地服务器，为SDK平台提供方收集诸如软件列表、IMEI码、GPS数据等设备软硬件信息，远端服务器会发送请求信息并从本地设备获取数据，包括控制应用程序在本地设备的运行状况。此类SDK通信信道存在被劫持的可能性，恶意攻击非法获取本地服务器数据造成隐私泄漏。此类SDK的运行规则如图1所示。

另一类SDK的应用程序仅仅接收远端服务器推送消息，越来越多的主流应用程序将SSL/TLS安全认证功能加入到传输协议中，形成新的HTTPS协议；只要添加正确并完成配置，就可以杜绝数据丢包和信息劫持。而普通的HTTP协议推送信息并没有经过特殊加密，直接传输会造成信息误收或者接收不完整，存在着很大的安全风险，而实际情况是使用HTTP协议的SDK开发出的Android应用程序依然在大量活跃使用。
安全问题
部分Android应用程序开发过程中过于强调程序功能，仅将SDK视为黑盒而忽略了平台内部的安全漏洞。假如SDK存在技术漏洞或暗门，那会造成所有调用此SDK的应用程序全部暴露于安全威胁之下，非法攻击能通过漏洞或者暗门得到应用程序的核心代码，洞悉程序整体运行细节，注入恶意代码，造成巨大损失。
建立本地服务器的SDK
在解析设备应用程序的manifest文件时发现，当用户Android设备启动调用某SDK的应用程序时，会触发相关应用程序获取权限的行为，并在用户不知情的情况下自主建立本地HTTP服务器。内置的HTTP服务器持续扫描检测TCP端口，接收和解析远端服务器和本地设备以便获取位置、用户身份等隐私数据信息。非法HTTP请求能替换本地服务器内置的action并执行恶意代码，造成用户信息被劫持。甚至攻击者还可能向用户设备私自添加联系人，扫描设备文件，搜集并上传特定数据，而所有这些操作都可以简单地发送非法HTTP请求来完成。
信息推送SDK
为了获得广告收益，部分应用程序的开发基于某广告公司发布的SDK，分析该SDK相关文档发现其使用HTTP协议与远端服务器通信；若攻击者使用代理服务器来检测和分析HTTP通道的数据传输、响应等信息，即可轻易获得用户Android设备的IMEI、广告信息、图片推送等，并且可以将信息内容改写为恶意威胁病毒网站，当用户点击推送信息时，访问预置的病毒URL，造成用户信息泄漏，利用信息劫持与替换对用户造成更大损失，部分钓鱼网站就是采取这种手段诱导用户点击广告链接进入目标URL实施欺骗。

SDK选择与分析

本次SDK分析研究过程主要包括3个步骤：
（1）研究SDK集成手册、Demo应用程序、manifest文档及开发清单，获取开发过程中组件和权限被添加到应用程序清单的信息。
（2）实施静态自动分析、数据包获取、动态污点分析。静态自动分析中，对待分析SDK的Demo程序进行反编译并利用Mallodroid开展代码审计和SSL/TSL自动分析。但是Mallodroid自动分析存在一些约束和限制，不能保证敏感数据使用SSL/TSL配置正确和安全，无法检测远端服务器上的安全威胁；也不能检测到程序设计缺陷和排除故障代码，只能得到相关问题代码的基本指标。因此有必要在自动分析基础上有选择地进行手动分析，验证自动分析结果以确保消除假阳性和假阴性。

动态污点分析（如图5所示）重点关注网络连接和涉及隐私信息的函数调用(如获取地理位置信息、读取联系人、验证码等)，这将有助于后续阶段动态分析过程中避免程序运行机制导致的误报和漏报，从而推断所分析的SDK可能存在的安全隐患。

（3）动态二进制插桩法测试验证安全问题。
由于SDK开发方的服务器端源代码的隐私性只能结合静态分析和利用动态二进制插桩(利用Frida注入代码)开展黑盒测试，对服务端收集到的参数进行读取和修改，从而验证该SDK的安全性。具体执行过程如图6所示。

实验结果

本研究系统分析了具有网络通信能力的外部SDK，先将其总结为两种基本类型:在应用程序段建立本地服务器的SDK和无本地服务器的SDK；然后对收集到的35个外部SDK开展静态分析，从SDK描述文档和源代码中提取组件、权限、网络连接等相关信息，检测可能存在的漏洞，再通过动态测试进行验证。
经过分析，将在外部SDK中发现的安全问题归为本地服务器漏洞、HTTP协议开放、敏感权限、SSL/TLS配置不当4种类型，表1描述了所收集的各种类型SDK中存在的具体安全漏洞类型与数量，为开发人员和服务提供商提供了分析外部SDK安全风险的依据。

建立本地服务器的外部SDK可以收集设备信息、执行系统命令进而获得设备的控制权。如果本地服务器执行了存在漏洞的访问控制，攻击者就会可以通过访问来检索敏感数据甚至后台控制设备。此外，攻击者可能会利用sediment命令向用户的设备发送指令，后台下载程序，收集特定程序文件，这些恶意操作都可以通过发送HTTP请求来完成。虽然许多新版本的SDK已删除了这些漏洞，但是由于用户并未及时更新，很多设备运行的依然是旧版本程序。
开放HTTP
众所周知利用HTTP协议建立网络连接存在较大的安全隐患，但事实上大量SDK依然使用此通道与服务器通信，也有SDK将诸如IMEI信息等用户隐私数据通过HTTP协议以明文或者密文的形式传送。
（1）明文传送：开发人员采用移动广告商家发布广告类SDK可以在一定条件下植入广告相关信息以获取收益。在这部分SDK的静态自动化分析过程中发现其未使用SSL/TLS安全协议加密，并且还将用户设备的IMEI、型号以及应用开发者的key发送到服务器端。恶意攻击者可以通过截取该SDK与服务器端的通信收集用户信息，也可能替换数据攻击用户。
（2）密文传送：短信验证SDK是一种可以为应用程序提供短信验证的外部SDK，逆向分析该SDK工具包中的.jar文件发现其通过本地自定义加密函数对发送的数据进行了加密，并在核心函数中调用了.so文件。然而恶意攻击者也可以通过对该SDK的逆向分析破解数据的加密算法和本地密钥，进而实现对用户与服务器端交互数据的解析(如图7所示),对用户造成信息泄漏以及带来更大的安全风险。

SSL/TLS配置不当
HTTPS是在HTTP协议下加入SSL层，必须恰当和正确配置才能保证通信信道安全，实现网络连接安全方面的升级。应用程序运行时必须查验主机名和服务器是否匹配以判断主机名是否有效，同时检查证书链的有效性。如果主机名与服务器的域名匹配则视为主机名有效；如果证书链中的每个证书都没有过期或撤销，根证书也是由CA在客户端的密钥库中发起的，并且这些证书均由CA在链中签名，才能够判定该证书链接为有效证书。
X509TmstManager接口是Android系统的证书信息管理器，通过它来执行安全socket检查。有恶意攻击者通过该接口重写证书验证过程并清空验证方法例程，允许非法验证通过。当SDK执行证书验证时发现过期、吊销、非法等情况，让应用程序即使发现非法证书的情况下也不做出任何异常提醒，这类威胁在一些来路不明的SDK中较为普遍。
过多索取敏感权限
从应用程序开发者角度很容易理解多数Android程序运行时会请求获取多于运行所需的权限以便备用，程序在调用SDK时，将数据、组件、权限等信息加入到manifest文件中，而非运行程序必需的权限则被用于获取用户设备信息、个人隐私等目的。例如某些信息推送SDK请求拍照、摄像、短信读取等权限。在对类似广告和信息推送类SDK分析之后其实这些权限对于核心功能来说完全不需要。还有些SDK共享主机应用程序manifest文件中的权限，如果manifest文件声明,它就可以使用这些权限，通过调用SDK中的主机代码查验来判断主机是否获取了某项权限(如图8所示)，而这些在基于该SDK开发的应用程序说明文档中却看不到申请这些权限的描述，申请过多权限导致引起不必要的安全威胁。

总结建议

针对外部SDK的使用，提出如下总结以减少风险：
(1)使用率高的SDK如果存在安全漏洞，带来的安全隐患和风险就越大。由于外部SDK是由服务商各自研发的，技术水平参差不齐，开发目的也不尽相同，因此开发者应该提高警惕在引入外部SDK时可能存在的安全风险。
(2)验证证书存在安全问题较为普遍，SSL/TLS漏洞在外部SDK中很常见，SSL/TLS应正确配置才能够确保通信安全。而Root设备将会带来无法预料的安全风险，如非必要建议不要Root设备。
(3)针对敏感权限的不必要索取，开发人员应建立对应的SDK保护机制，避免因为共享manifest文件来直接获取过多的和程序功能无关的权限，开发人员也可以将反射机制关键代码置于.so文件中保护SDK代码。