基于云平台的移动支付类恶意软件检测系统的设计与实现

 树雅倩1，付安民1，2，黄振涛1

  (1南京理工大学计算机科学与工程学院，江苏南京210094；2．中国科学院信息工程研究所信息安全国家重点实验室，北京100093)

摘要：在移动通信技术不断发展的今天，各式各样的应用出现在手机终端，其中最具代表性的业务就是移动支付应用，越来越多的用户选择移动终端进行支付，与此同时移动支付安全风险也日益凸显。文章针对移动用户面临的各类支付威胁，设计了一个基于云平台的移动支付类恶意软件检测系统。通过云端和手机端协作的方式，在云端通过An droid模拟器模拟特殊 的移动支付场景，在移动支付类APP运行前对其进行敏感行为自动化动态测试，输出并解析运行日志，通过自定义的判定规则判断其是否具有恶意行为，从而能够在恶意行为发生前检测出恶意软件。同时手机端设置了二次打包检测和钓鱼短信检测的功能，帮助用户避免下载山寨恶意软件或登录恶意网址后掉入黑客设置的陷阱从而泄露隐私信息，再辅之以静默安装的检测功能，防止子包在手机后台静默安装逃避系统检测，从而更全面有效地保护用户的移动支付安全。最后通过实验验证了该系统的有效性和实用性。

 关键词：移动支付；二次打包；恶意软件检测：云平台

 中图分类号：TP309  文章编号：1671-1122( 2016) 01-0059-050引言

 截至2014年年底，中国手机网民已达到5.52亿，其中使用移动支付的用户数达到2.68亿，占手机总用户的48.5%，较2013年同比增长了113%。然而据百度安全播报数据显示，有支付风险的用户占比高达21.8%，支付安全严峻性日益凸显。在支付类应用的用户中，55%的用户使用网购支付，28%的用户使用第三方支付，11%的用户选择网购支付，还有6%的用户进行理财支付。移动支付安全的风险主要来自山寨恶意应用、验证短信不安全、不明的WiFi网络环境、支付应用自身漏洞。其中静默发送和删除短信在支付病毒行为比例中占77%，黑客通过破解用户支付账号，转发验证码，盗取用户资金。

 为了实现对恶意软件的有效检测，研究人员提出了两种通用技术：静态检测和动态检测。静态分析涉及二进制相关的技术，包括反编译、模式匹配、逆向分析和静态系统调用分析等。静态分析简单陕速，但它检测恶意软件前需知道相关软件信息，如签名、权限申请、行为模式等。动态检测的核心技术是采集和分析恶意软件的行为特征，如系统调用情况、权限改变、网络访问、进程和线程运行情况等，比静态分析复杂，时间开销也大。正是由于这两种技术各有优缺点，现在大多数的方法是采用静态检测与动态检测相结合完成。然而，现有这些恶意软件检测方法大都是针对传统的恶意软件，并没有考虑移动支付恶意软件的特性。采用系统资源消耗和内核层的系统调用作为度量单位，通过对恶意样本行为数据的训练和分析建立保护模型检测恶意行为，但行为数据不够完整，且只能检测恶意行为已经发生的支付类恶意软件。FUN等人从网络安全机制角度出发，提出一种基于网络通信的移动支付保护方案，通过修改网络安全机制中的参数和安全函数以保护用户移动支付过程中的信息安全，但这些方法主要是从服务提供商和运营商角度出发，依然没有从根本上帮助用户解决移动支付的安全问题。

 本文通过深入分析移动支付面临的各类威胁以及恶意攻击的行为模式，结合支付类恶意软件特性，设计与实现了一个基于云平台的移动支付类恶意软件检测系统。主要贡献如下：

 1)在云端通过模拟器模拟移动支付场景，在移动支付类APP运行前对其进行敏感行为自动化动态测试，能够在恶意行为发生前检测出恶意软件；

 2)在手机端通过同时检测APP的包名和签名以防止二次打包，且实时监测是否有子包静默安装以保证所有APP都经过检测；

 3)在手机端对接收短信中的链接进行检测，通过黑名单筛选和公共恶意网址检测平台，帮助用户避免落入黑客陷阱。

1预备知识

 除了对Android应用程序本身的研究，我们需对移动支付存在的安全隐患进行分析，了解恶意软件的运行机理以制定有效的检测方案，本文采用手机端联合云端的检测方法，云端使用IBM bluemix云平台提供的基础架构进行二次开发。

1.1 Android组件模型

 每个Android应用程序都是由四个组件搭建而成，分别是界面组件Activity、服务组件Service、数据源组件Content Provider以及触发器组件Broadcast Receiver，并且应用程序之间的组件是共享的，这是Android系统非常重要的特性之一。

 组件是Android应用程序的重要基石，每个组件是一个不同的角度，通过系统可以进入应用程序。简要的四大组件关系如图1所示。

1.2移动支付类恶意软件分析

 移动支付安全面临的四大挑战分别是：1）山寨／恶意应用，主要是通过用户下载恶意的病毒包，监控用户启动银行程序的行为，进而关闭正版银行程序，钓鱼页面取而代之，最终造成用户财产损失；2）不安全的WiFi网络环境，用户连接黑客建立的不加密WiFi热点，所有操作信息包括银行卡信息都被监控记录，从而造成财产损失；3）诈骗短信，黑客通过伪基站发布诈骗短信，诱导用户进入钓鱼网站下载使用带病毒的客户端，获取用户银行卡信息并登录网银，然后截取网银发送给用户的验证码短信并通过网银验证，造成用户财产损失；4）支付应用自身漏洞，支付应用自身的安全漏洞被黑客利用，通过聊天记录被间谍软件窃取的方式，随时监控用户隐私。

 每个恶意软件都有其行为特点，要实现该行为通常需要调用特定API。以恶意扣费类软件为例，绝大多数通过SP（服务提供商）渠道实现，即恶意软件向特定SP号码发送短信进行计费，然后恶意软件删除运营商的二次确认短信并代为回复。在此过程中，会用到发送短信的API：SendTextMessage。可以被利用完成恶意行为的API被称为敏感API，Android平台部分敏感API如表1所示。

1.3 IBM bluemix云平台

 云计算基于互联网相关服务的增加、使用和交付模式，通常涉及通过互联网来提供动态易扩展且经常是虚拟化的资源。IBM提供的易于部署和使用的入门级云解决方案可与现有基础架构配合，以帮助自动执行并有效管理虚拟化的系统和存储基础架构。

2框架设计

 为更好地帮助用户减少损失，我们致力于在恶意行为发生前检测出恶意软件，而不是对已经发生的恶意行为进行排查。本文采用模拟器模拟场景，在APP运行前，对它进行敏感行为测试。再辅之以二次打包检测、静默安装检测和钓鱼短信检测，从而更全面有效地保护移动支付安全。

2.1设计原则

  本文设计原则为：源头阻断、过程检测、辅助避免。

  源头阻断：威胁移动支付安全的源头为山寨恶意软件，这些软件的包名一般使用原正版软件的包名以掩人耳目，但签名信息则不同。本文采用包名和签名匹配的方法判断APP是否为二次打包软件。

 过程检测：黑客主要通过获得用户的银行卡身份信息，以及付款的验证短信进行钱财盗取，或者是发送恶意扣费的订购短信。本文在云端设置模拟器进行测试，通过情景模拟恶意行为，将模拟器的行为日志输出，解析其是否存在恶意行为，不光提高了检测的准确率，而且能在恶意行为发生前提醒用户，减少钱财损失。

 辅助避免：为帮助用户避免落入黑客陷阱，我们对钓鱼短信进行了排查。黑名单通过国外钓鱼网址搜集网站phishtank和中国反网络病毒联盟网站上所提供的恶意网址爬虫所得，然后接入安全联盟AP1检测以减少误报。

2.2框架结构

系统由手机端和云端组成，框架结构如图2所示。

 手机端的主要功能模块有二次打包检测、静默安装监测和钓鱼短信检测，其中二次打包检测负责判别软件是否为添加过恶意代码或组件的山寨软件；静默安装监测是防止软件带有子包在后台自动安装；钓鱼短信检测负责实时提醒用户短信里的链接是否为钓鱼网址。

 云端主要功能是承担APP动态检测、深度查杀的工作，即模拟器检测功能，同时还承载软件升级工作以及黑白名单等应用数据库的升级增量更新。为了开发的便利性，云端直接采用了IBM blue mix先进的云平台，利用其提供的PaaS开发人员平台使用Java编程开发，与数据库服务进行通信。

3系统实现

 整个系统分为两部分：客户端与服务器。客户端为Android手机，进行本地静态检测。客户端采用Java WebServlet技术，服务器在IBM blue mix云平台上进行动态检测。

3.1二次打包检测

 APK的唯一识别是依靠包名和签名做鉴定。山寨应用使用正版应用的包名进行伪装，但重打包之后，因不具有原开发者的Private Key，签名必然会发生变化。本文的二次打包黑名单是由恶意软件的签名信息构成，白名单由包名和签名组成。通过在Google官网上搜集“支付”、“银行”、“理财”这三大类的APP样本，编写批处理工具，将其中META-INF文件夹解压出来，得到其中的CERT.RSA文件，再使用keytool命令获取签名MD5值，从而实现了包名和签名的自动提取。将得到的.csv格式文件构建XML格式文件，作为客户端raw资源文件放入APK中。客户端获取资源文件并解析XML从而建立白名单数据库。

 二次打包检测时先提取APP签名的MD5值在黑名单中进行对比，若在黑名单列表中则为恶意软件，若不在则再到白名单中进行包名和签名的匹配，核对包名后如果签名与数据库中不匹配则判定为二次打包软件，再将其签名更新到黑名单中以提高下次检测的效率。若该APP的包名不在白名单中，则将APP加载到模拟器进行进一步检测。

3.2静默安装监测

 子包静默安装也是重要的手机安全威胁之一，一般是获得root权限后利用静默方式实现，或直接利用intent实现。本文通过监听APP安装的广播，新建继承BroadcastReceiver的监听类，修改Android Manifest．xml配置文件，添加Broadcast介绍和监听的权限，从而提醒用户有子包在后台安装，关键代码如下：

 从而对该APK进行进一步检测。

3.3钓鱼短信检测

 首先在Android Manifest．xml中添加读取短信的权限：android. Permission．READ _SMS，遍历短信内容，检测用户短信中是否存在以“http'’开头，或者以“c n”、“com”结尾的链接，与钓鱼短信黑名单进行比对。黑名单的建立采用网络爬虫所得。网络爬虫是按照一定的规则自动抓取万维网信息的程序或者脚本。我们通过爬取钓鱼网址搜集网站phish tank和中国反网络病毒联盟网站的后台代码，获得其中的钓鱼网址信息构成数据库。若检测链接不在黑名单中，则调用安全联盟API对该链接再次进行检测，以保证返回结果的准确性。

3.4模拟器检测

 首先将APP加载到云端模拟器，通过Monkey Device模块进行安装和启动。根据移动支付类恶意软件行为模式分析，通过Monkey Runner编写pay thon脚本，对APP进行随机点击、输入和特殊场景模拟测试，采用XML格式输出模拟器检测日志并进行解析，结束后再通过Monkey Device模块实现APP自动卸载，基本流程如图3所示。

 针对现在以淘宝订单失效或付款不成功为由的诈骗数量的增多，我们在模拟器检测中添加了验证短信这一场景的模拟。使用银行、移动运营商和支付宝这一类的客服号码（如农业银行95599、中国电信10000、支付宝95188）建立一个Phone NumList，给模拟器发送带有敏感词汇的“验证短信”以触发恶意行为。

 本文采用XML输出模拟器日志，判断其是否有拦截广播、删除短信、自动发送订购业务短信、截屏，或者向外界发送用户信息的行为，如图4所示，若<／data leaks>节点中有数据，则说明该软件存在泄露用户隐私的行为。

具体的恶意行为判定规则如表2所示。

若日志解析后存在表2中的行为组合，则判定为恶意软件，输出结果提示用户。

3.5数据库的同步与更新

 在IBM bluemix云平台中使用的数据库是NoSQL，因此以JSON的形式直接存储数据。

 其中同步手机端数据库的过程为：手机端与云端进行握手认证身份，认证成功后，手机端后台线程发起HTTP Request，将本地数据库特征信息传至云端。云端通过解析数据，得出手机端与服务端的数据库差异，再通过运算将需要更新的JSON回传给手机端，手机端进行同步。

 在二次打包检测中，若在云端白名单中检测出山寨软件，则将其签名信息同步到本地黑名单中，将该增量以JSON方式传至手机端从而完成黑名单的更新工作。

4测试

 为评估该系统的有效性和准确性，需搜集移动支付类的恶意软件作为测试样本。但由于恶意攻击软件一经发现立即被下架，能获取的资源有限，所以样本数目不大。本文结合搜集到的30个恶意软件和30个官方软件作为样本，在Nexus 4的Android5.1版本上对这60个样本进行测试。

 同时为了突出该系统针对恶意移动支付类软件测试的有效性，本文使用金山手机卫士对样本检测，测试结果如表3所示：

 测试结果显示实验系统没有误报，且检测出29个恶意样本数，漏报率低于金山手机安卫士。检测结果中9个样本检测结果来自于云端模拟器检测，证明了本系统静态与动态检测相结合有较高的检测准确性，能有效帮助用户解决移动支付安全问题。

5结束语

 本文针对移动支付面临的安全威胁，设计与实现了一个基于云平台的动态检测与静态检测相结合的移动支付类恶意软件检测系统。通过从源头和过程对用户的财产安全进行保护，可以有效避免用户发生账户泄露，钱财被盗取和莫名业务扣费等情况。然而随着手机支付病毒的种类和攻击手段的增多，各种社交软件自带的转账和钱包功能也成了攻击对象，方法相当新颖并且难以检测。因此，如何完善补充恶意行为检测规则，阻止各类攻击手段还是一个长期学习的过程。