Android应用第三方推送服务安全分析与安全增强

2016-11-25路晔绵李轶夫应凌云3谷雅聪苏璞睿3冯登国

计算机研究与发展 2016年11期

路晔绵李轶夫应凌云,3谷雅聪苏璞睿,3冯登国

1(中国科学院软件研究所可信计算与信息保障实验室北京 100190)2(国家计算机网络应急技术处理协调中心北京 100029)3(中国科学院大学计算机与控制学院北京 101408)(luyemian@tca.iscas.ac.cn)

路晔绵1李轶夫2应凌云1,3谷雅聪1苏璞睿1,3冯登国1

推送服务已成为移动智能终端应用的一个基础服务，各大手机平台及互联网公司相继推出了各自的推送服务供应用程序开发者使用.为了降低资源消耗，部分第三方Android推送服务采用共享通道的设计方式，在设备上使用某个应用的推送后台组件作为其他应用推送数据的分发中心.由于缺乏针对数据机密性、完整性、不可伪造性等安全需求的设计与实现，数据分发环节面临多种攻击的威胁.分析了使用共享通道的第三方Android推送服务在数据分发环节存在的安全问题，通过在攻击程序中Hook相关API调用的方法，实现了针对其他应用推送数据的窃听、篡改、伪造和重放攻击，实验结果表明:大部分共享通道的第三方Android推送服务无法抵抗这些攻击，可能造成用户隐私数据泄露和钓鱼攻击等实际危害.在上述研究的基础上，设计并实现了Android应用推送服务安全增强方案SecPush，使用加密算法及HMAC运算提供推送数据分发环节的安全保护，实验结果表明:SecPush提高了推送数据的安全性，可有效抵挡窃听、篡改、伪造和重放等攻击行为.

安卓；推送服务；数据分发；共享通道；安全分析；安全增强

推送服务是当今移动智能终端应用的一个基础需求，通过维持应用程序客户端与推送服务器之间的socket长连接，推送服务允许应用程序开发者通过推送服务器主动向客户端发送信息.与客户端通过轮询来获取信息的方式相比，推送服务降低了资源消耗，同时保证了消息的实时性，因此移动智能终端应用程序开发者广泛使用推送服务向用户发送新产品信息、活动预告、社交信息、新版本更新通知等消息.通过使用推送服务，开发者在及时发布信息的同时，可以显著提升用户的留存率和活跃度.根据Urban Airship于2013年12月发布的针对使用推送服务的移动应用进行统计分析的结果[1]显示，开启推送功能的用户留存率约是不使用推送的用户的2倍.

推送服务极大地简化了移动终端应用开发者的开发过程，然而其在带来巨大便利的同时也带来了一些安全隐患.Li等人[2]对推送服务中应用程序的注册操作和PendingIntent对象的使用进行了详细的分析，指出攻击者通过精心的设计，可以获取本应发送给目标设备上目标应用用户的隐私数据，或导致目标应用执行攻击者发送的命令.Li等人的分析多集中在应用程序的注册过程和信息上传过程，对目标设备上推送数据传递环节的安全性缺少详细的分析.

目标设备上推送数据的传递过程存在3种实现方式:

1) 推送服务使用移动终端操作系统自身模块或系统应用作为推送数据的转发中心，推送数据经由推送服务器发送给目标设备后由该转发中心传递给目标应用，例如苹果官方的APNS[2](Apple push notification service)服务使用iOS自身功能模块作为推送数据的转发中心、谷歌官方的GCM[3](Google cloud messaging)服务使用Google Play Store应用转发推送数据，基于官方推送服务开发的第三方推送服务也属于这种方式.这种实现方式一方面在目标设备上只维持了1条长连接，供推送数据转发中心与推送服务器进行数据交互，降低了资源消耗；另一方面，作为转发中心的系统模块或者官方应用很难被外来攻击者攻破，在一定程度上保证了数据转发环节的安全性.

2) 同一设备上使用同一推送服务的每个应用各自维持其与推送服务器之间的socket长连接，推送服务器发送给目标应用的推送数据由该应用中嵌入的推送服务客户端SDK独立接收并处理，其他应用无法对该过程进行干涉.极光推送、小米推送等第三方Android推送服务使用该方式实现.这种实现方式只要保证推送数据仅可在应用内部传递即可保证其安全性，然而设备上将存在多条与推送服务器之间的socket长连接，耗费资源过多.

3) 同一台设备上使用同一推送服务的多个应用之间共享1条长连接，将其中某个应用的推送Service组件作为推送数据的转发中心，本文使用PDDS(push data distribution service)代指该组件.应用程序开发者的推送数据将首先由推送服务器发送给目标设备上的PDDS组件，由PDDS组件进行简单处理后将数据转发给目标应用.百度云推送、友盟推送、腾讯信鸽推送等第三方Android推送服务使用该方式实现.这种方式可以避免同一设备上存在多条与推送服务器之间的socket长连接，节省资源，但是与官方推送服务的设计相比，却增加了额外的安全风险.由于目标设备上的PDDS组件是由某个应用使用的推送SDK创建，与宿主应用运行在同一应用空间，因此宿主应用可以完全控制PDDS组件的运行.当推送服务没有提供数据加密等安全保护措施时，PDDS组件的宿主应用可以通过控制PDDS组件获取推送给其他应用的信息，甚至于伪造消息发送给目标应用，这将给用户带来极大的安全隐患.

本文对使用PDDS组件的第三方Android推送服务进行了详细的分析，发现其中多数推送服务缺乏对推送数据分发环节安全性的有效保护，包括其市场占有率居于前几位的百度云推送、友盟推送和腾讯信鸽推送.数据分发环节安全措施的缺乏可能导致用户的隐私信息被泄露，或将用户置于钓鱼攻击的威胁之下.本文设计了相应的攻击模型以检测推送服务在数据分发环节的安全性，通过在攻击程序中对推送服务的函数调用进行Hook，实现了针对推送数据的窃听、篡改、伪造和重放攻击.最后，针对发现的安全问题，本文提出了相应的安全增强方案.

本文的贡献主要包括4个方面：

1) 分析了第三方Android推送服务数据分发环节安全机制的实现情况，并设计了相应的攻击模型；

2) 针对多个推送服务进行了实际分析和攻击测试，实验结果表明，多数第三方Android推送服务面临着窃听、篡改、伪造和重放攻击的威胁；

3) 提出了Android推送服务安全增强方案SecPush，通过添加加密模块和HMAC运算增强推送服务数据分发环节的安全性，实现了数据机密性、完整性、不可伪造性和抗重放攻击的安全需求；

4) 实现了SecPush原型系统，并对其进行安全测试，实验结果表明，SecPush能有效抵挡窃听、篡改、伪造和重放攻击.

1 第三方Android推送服务的使用模式

本文的研究对象是使用PDDS组件进行推送数据分发的第三方Android推送服务，其整体架构如图1所示：

Fig. 1 Framework of third-party Android push service.图1 第三方Android推送服务架构

Push SDK为嵌入目标应用的推送SDK；Push Server为推送服务器；Portal为推送服务的Web前端，由推送服务提供商开发维护，方便应用程序开发者在不开发服务端代码的情况下发送推送信息；Application Server是开发者为其应用开发的服务器端，使用推送服务的服务器端SDK实现推送相关功能，开发者可以通过Application Server向Push Server发送推送消息，由Push Server将该消息推送给目标应用.

推送服务的交互流程如下：

1) 应用程序调用Push SDK的初始化函数，Push SDK将应用的包名、应用创建时从推送平台获取的APP_ID等信息传递给Push Server，完成应用信息的注册，获取ClientId作为当前设备上当前应用在Push Server上的用户标识，供应用程序开发者向当前设备上的应用发送数据时使用；

2) Push SDK检查当前应用是否是该设备上第1个使用Push SDK的应用程序，若是，则建立设备与Push Server之间的socket长连接，用以接收推送数据，并定时发送心跳包以维持该连接，管理该连接的Service组件即为设备上的PDDS组件；

3) 应用程序开发者通过Portal或Application Server将推送数据提交给Push Server；

4) Push Server使用其与目标应用所在设备之间的socket长连接将推送数据发送给目标设备上的PDDS组件；

5) PDDS组件对收到的数据进行预处理，判断目标应用，将推送数据传递给目标应用；

6) 目标应用的消息接收器根据推送数据类型进行后续处理.

多数第三方Android推送服务提供2种类型的推送数据：1)通知类推送；2)透传信息.通知类推送将在设备通知栏展现1条通知，用户点击该通知后，根据具体类型的不同，Android系统或者打开目标应用的某个界面，或者通过系统浏览器或目标应用使用的WebView控件打开某个网页，通知类推送的处理一般由推送服务SDK自己实现；而透传信息则是由应用程序开发者设计其独有的数据格式及相应的处理方式，推送服务只负责将推送数据传递给目标应用，不负责后续的处理过程.

通过提供多样化的推送方式，推送服务可以应用于多种场景，包括面向多数用户的新产品推荐、运营活动通知以及面向特定用户的好友互动提醒、聊天信息推送等.多数推送服务都将上述场景作为典型应用场景介绍给用户，然而很少有推送服务提供这些应用场景需要的安全保护措施.部分推送服务考虑到网络数据传输的安全性，使用TLS协议进行传输，或者将推送数据加密后传输，以对抗来自网络的攻击者，然而对于推送SDK在设备上进行推送数据分发过程的安全性却少有考虑，由于进行推送数据分发的PDDS组件由设备上某个应用程序创建，可被该应用完全控制，因此一旦PDDS组件的宿主应用是攻击者控制的恶意应用，攻击者即可通过PDDS组件获取传送给其他应用的数据，进行窃听、篡改等攻击，推送SDK的数据分发环节将成为整个推送服务运行过程中最为薄弱的环节.

2 推送服务数据分发环节安全性分析

本节主要分析第三方Android推送服务数据分发环节中存在的安全问题，并介绍敌手能力及相应的攻击模型.

2.1 安全目标

根据推送服务的典型应用场景，开发者使用推送服务推送的数据大致可以分为公开信息和私密信息2类.对于前者而言，推送服务应保证数据在传送给目标应用的途中未被篡改，不会被攻击者利用构建钓鱼攻击等攻击场景；对于后者而言，推送服务应保证推送数据的机密性，不能被攻击者窃听以获取用户隐私信息.整体而言，推送服务数据分发环节的设计应充分考虑机密性、完整性、不可伪造性和抗重放攻击4个安全需求.

具体来说，机密性应保证目标应用收到的推送数据未被泄露给他人，或即使数据被窃听，敌手也无法获知数据的明文信息；完整性应保证目标应用收到的推送数据未被篡改；不可伪造性应保证目标应用收到的数据只能是其开发者通过推送服务器发送的数据，敌手不能伪造新的推送数据发送给目标应用而不被识别；抗重放攻击应保证目标应用能够判断收到的数据是否已被处理过，已收到并处理过的数据不再进行重复处理.

2.2 敌手能力分析

推送服务数据分发环节的核心参与者是PDDS组件，可控制PDDS组件运行的宿主应用为该环节的攻击者.

根据作者对目前市场上存在的第三方Android推送SDK的分析，大部分推送SDK将PDDS组件设定为设备上安装的第1个使用该SDK的应用所创建的推送Service组件，因此，当使用了某个推送SDK的攻击程序先于目标应用安装于同一设备上时，攻击者可以通过控制PDDS组件实施针对目标应用的攻击.然而这个条件并不是必须的，根据作者的分析，推送SDK通常会通过添加并维护某个系统属性值的方式或者通过检测系统中正在运行的Service组件等方式进行PDDS组件的设定和判断，通过修改相应的系统属性值或者函数调用返回值，可以在目标应用先于攻击程序安装的情况下，将攻击程序创建的推送Service组件作为设备的PDDS组件.只要攻击程序可以将自己的推送Service组件设定为PDDS组件，攻击者就可以通过控制PDDS组件控制发送给目标应用的推送数据.

此外攻击者可以通过反编译目标应用的apk文件，从程序代码中获取感兴趣的信息，例如获取目标应用的APP_ID、目标应用服务器的网址及相关参数格式信息等.通过这种方式，攻击者可以目标应用的身份向推送服务器或目标应用服务器发起一些网络请求.

本文设定的攻击程序不具备root权限，因此可以在所有使用Android系统的设备上实施攻击.由于攻击程序与目标应用属于不同的应用，根据Android系统中进程沙箱隔离机制的设计，在未获取root权限的情况下，攻击程序无法干涉目标应用的运行，也无法获取目标应用通过其他途径进行网络通信的数据.

针对2.1节中描述的安全目标，攻击者可能实施的攻击如下：

1) 消息窃听

由于通过目标推送服务传输的数据都需要经过PDDS组件的处理，因此可以在PDDS组件收到数据并分发给目标应用的过程中获取传送给所有目标应用的数据.当推送数据涉及私聊信息等用户隐私数据且未经加密保护时，该攻击将导致用户隐私信息的泄露.

图2所示为使用百度云推送服务的攻击程序通过窃听获取的同一设备上“Pogo看演出”应用的用户lulu收到的私聊信息.从中可以获取私聊信息的明文“hello, I’m Alice”、发送者的昵称“roadinmind”等信息.

Fig. 2 Private chat information of Pogo user obtained by eavesdropping.图2 通过窃听获取的Pogo用户的私聊信息

除了获取用户隐私信息，攻击者还可以从窃听到的数据中获取目标应用的APP_ID、消息格式等信息，这些信息将有助于构造符合格式要求的伪造数据.此外消息篡改和重放攻击也需要首先获取目标应用应接收的正确数据以作修改或重放.可以认为，窃听攻击是攻击者进行后续攻击的基础.

2) 消息篡改

PDDS组件的宿主应用可以对收到数据的部分字段进行修改，将篡改后的数据发送给目标应用.直接篡改开发者发送的正确消息，可以提高虚假消息成功发送的概率，降低用户的疑心，为钓鱼攻击等后续攻击提供方便.

图3所示为使用百度云推送服务的攻击程序通过修改同一设备上的“当当读书”应用发送的新书推荐消息，诱使用户打开通知并输入用户名密码的攻击.其中，图3(a)所示为用户点击通知后展示的网页内容，图3(b)所示为用户点击“点击领取”按钮后请求用户输入登录信息的页面.

Fig. 3 Phishing attack through tampering.图3 通过消息篡改进行钓鱼攻击

3) 消息伪造

通过分析窃听攻击获得数据的数据格式，PDDS组件的宿主应用可以伪造1条符合格式要求的新消息发送给目标应用，经过目标应用的正确处理后将内容展示给用户.

伪造攻击可以获得与篡改攻击相似的攻击效果，作者通过伪造消息的方式，同样实现了图3中展示的钓鱼攻击.与篡改攻击相比，伪造攻击更为灵活，攻击者可以选择在任何合适的时间发送伪造的消息.

图4所示为攻击者假冒“Pogo看演出”的用户roadinmind构造虚假消息发送给用户lulu的攻击.其中，图4(a)所示为消息的接收者lulu看到的消息界面，lulu收到的伪造消息内容为“这是假消息”；图4(b)所示为用户roadinmind的私聊界面，其中并没有“这是假消息”这条消息显示，证明该伪造攻击对于用户双方都是不可感知的.

Fig. 4 Forgery attack for Pogo.图4 针对Pogo应用的伪造攻击

如果攻击者可以通过其他方式控制“Pogo看演出”应用网络数据的发送，那么攻击者可以截获用户lulu发出的所有信息，在这种情况下，攻击者完全可以伪装成“Pogo看演出”应用的合法用户与lulu进行私聊，从而实施社会工程学攻击.

4) 消息重放

PDDS组件的宿主应用可以将收到的数据重复发送给目标应用，如果目标应用不检测数据的新鲜性，将会再次处理重放消息.

2.3 攻击实现

本文通过在攻击程序中Hook推送SDK的相关函数调用实现针对推送数据的窃听、篡改、伪造和重放攻击.由于实现Hook功能的代码与Hook操作的对象同属于攻击程序，因此攻击程序不需要请求root权限就可以实现对PDDS的控制，事实上，攻击程序只需要申请推送SDK运行所必需的权限便可以实施上述4种攻击.为了实现Hook功能，本文使用了GitHub上的公开库ZHookLib[3].

实现对PDDS组件的控制之后，通过Hook PDDS组件向目标应用分发数据的函数，攻击程序可以实现针对推送数据的窃听和篡改攻击.另一方面，由于目标应用接收推送数据的组件多数是BroadcastReceiver组件，且出于实现功能的需要无法通过设置发送者权限进行有效保护，因此实际上任意Android应用都可以向目标应用发送格式及编码符合要求的伪造消息.

攻击模型原理图如图5所示.其中Application 1为攻击程序，Application 2为目标应用，PDDS组件由Application 1创建，Hook Service与Forge_Replay为攻击模块.Hook Service通过对sendBroadcast等函数进行Hook，获取放置在Intent类型参数中的推送数据，实施窃听和篡改攻击；Forge_Replay模块使用窃听攻击获取的数据实施伪造和重放攻击.

图5中实线箭头所示为推送SDK分发数据的正常途径，步骤如下：

Step1. Push Server将推送数据发送给目标设备上的PDDS组件；

Step2. PDDS组件对数据进行简单处理，判断目标应用为Application 2，通过sendBroadcast等函数将数据发送给Application 2相应的Push Receiver.

本文的攻击模型是在数据分发的第2步实施攻击，图5中虚线箭头所示即为攻击过程，步骤如下：

Step1′. Push Server将推送数据发送给目标设备上的PDDS组件，同Step1；

Step2′. Hook Service截获PDDS对send-Broadcast等函数的调用，从Intent类型参数中获取推送数据进行分析，同时修改推送数据的内容；

Step3′. Hook Service将篡改后的推送数据通过sendBroadcast等函数发送给目标应用Application 2对应的Push Receiver，实施篡改攻击；

Step4′. 攻击程序通过分析Step2′中窃听到的数据，伪造合适的推送数据发送给目标应用，或者将Step2′中窃听到的推送数据重复发送给目标应用，实施重放攻击.

通过使用上述攻击模型，作者对市场上6款第三方Android推送服务进行了攻击测试，实验结果表明，多数使用PDDS组件的第三方Android推送服务无法抵抗窃听、篡改、伪造和重放攻击，没有实现其声称的典型应用场景所需要的安全需求，威胁用户的使用安全，其中包括开发者广泛使用的百度云推送、友盟推送、腾讯信鸽推送等推送服务.具体实验结果在本文4.1节中展示.

Fig. 5 Attack model.图5 攻击模型原理图

3 SecPush的设计与实现

由于现有的第三方Android推送服务很少考虑到数据分发环节的安全性需求，使得应用程序的最终用户可能暴露在隐私数据泄露和钓鱼攻击等安全威胁之下.为了保证应用程序最终用户的使用安全，使用现有推送服务的应用程序开发者只能自己实现推送数据的加密保护及完整性验证等安全需求，这将给开发者带来额外的开发负担，而且由于推送服务本身不支持上述安全需求，应用程序开发者只能在推送服务提供的多样化推送方式和安全之间做出折中选择.因此完全依赖应用程序开发者自己实现相关的安全需求是不合理的.另一方面，推送服务宣称的典型应用场景也要求其实现相应的安全保护措施.因此，从根本上提高第三方Android推送服务的安全性，才是促进第三方Android推送服务产业发展的有效措施.本文设计并实现了Android应用推送服务安全增强方案SecPush，以增强推送服务中数据分发环节的安全性，保护应用程序的最终用户免受隐私泄露和钓鱼等攻击的威胁.

本节主要介绍SecPush的设计原理、安全性分析及局限性分析.

3.1 系统设计

SecPush的设计目标在于增强推送数据分发环节的安全性，实现数据机密性、完整性、不可伪造性和抗重放攻击的安全需求.SecPush采用对称加密及HMAC运算提供数据机密性、完整性和不可伪造性保护，通过数据库保存和查询推送消息Id的方式提供消息重放检测功能.具体设计描述如下:

3.1.1 密钥分配方案设计

应用程序与推送服务器之间需要共享对称密钥和HMAC运算密钥方可完成推送数据的加解密运算和HMAC验证，设计安全的密钥分配方案保护目标应用的密钥不被敌手获取是保证SecPush方案安全性的关键.

根据推送服务的典型应用场景，推送数据可以大致分为2种类型：1)面向应用程序多数用户发送的公开信息，例如新产品推荐、活动通知等；2)针对特定用户发送的私密信息，例如新增评论、私聊信息等.2种类型数据的安全需求不同，对于公开信息而言，机密性并不是必要需求，因为任何使用该应用程序的用户都可能收到这些公开通知，对于这类信息而言，安全防护的重点在于防止信息内容被攻击者篡改或伪造从而进行钓鱼等后续攻击.对于私密信息而言，数据机密性、完整性、不可伪造性和抗重放攻击都是进行安全防护的重要目标.根据不同的安全需求，SecPush设计了不同的密钥分配方案.

对于公开信息推送，推送服务器在应用程序通过SecPush客户端SDK进行应用信息注册时生成当前应用在当前设备上使用的加密密钥和HMAC运算密钥，将其作为注册请求的响应数据传递给应用程序.在应用程序因某些原因重新发起注册请求后，服务器将生成新的密钥替换之前的密钥传递给应用程序并使用新的密钥进行加密和HMAC运算.由于攻击程序无法获取目标应用与推送服务器之间直接的网络通信数据，因此攻击程序无法获取目标应用的密钥，无法对使用这些密钥进行保护的推送数据进行解密和篡改.另一方面，即使攻击程序伪装成目标应用向推送服务器发起注册请求，其获取的密钥也与目标应用正在使用的密钥不同，此时攻击程序可以解密推送服务器使用新密钥发送给目标应用的公开推送数据，但是不能构造可以被目标应用正确处理的篡改信息和伪造信息.在整个过程中，攻击者最多只能实施窃听攻击，无法实施其他攻击.而攻击者通过窃听获取的只是目标应用的公开通知，对攻击者而言价值不大.相应地，目标应用可能因为所用密钥与推送服务器不同导致无法解析其应当收到的数据，但考虑到使用公开通知发送的信息一般对于用户而言并不重要，且应用程序在下一次发起注册请求时依旧可以与服务器同步密钥，正确收到之后的公开通知，因此上述密钥分配方案具备现实可用性.

对于私密信息推送而言，推送内容一般与应用程序的特定用户相关联，需要在用户登录应用程序账号后才可以接收相应的通知信息，因此可以在应用程序向其服务器发送登录请求时由应用程序服务器根据登录用户名、密码及其他相关参数生成该用户在当前设备上使用的推送数据加密密钥和HMAC运算密钥.由于攻击程序无法获取目标应用与其服务器之间的网络通信数据，因此攻击者无法直接获取目标应用服务器返回的密钥信息.另一方面，由于攻击者不知道目标应用当前用户的用户名和密码，因此无法伪装成目标应用向其服务器请求密钥.因此攻击者无法获取目标应用用于私密推送信息处理的密钥，无法进行窃听、篡改和伪造攻击.为了减轻开发者的开发负担，相关的功能可以由SecPush提供给应用程序服务器端的SDK实现.

3.1.2 推送数据格式设计

虽然公开信息推送和私密信息推送使用的密钥不同，但是针对推送数据进行的加密操作和HMAC运算是一致的，因此可以采用相同的推送数据格式，以简化客户端的处理过程.推送服务器发送的数据可表示为

Msgsend={pkgname,msgId,enctype,contentc,

HMACkeymac(pkgname,msgId,enctype,contentc)},

contentc的格式如下：

其中，E代表加密运算；keyE为数据加密密钥；typeId表示消息类型，通过设置该值可以提供多种推送数据处理方式；title为通知类消息的标题；body为推送消息的具体内容.

3.1.3 SecPush方案架构设计

SecPush方案的整体架构如图6所示:

Fig. 6 Framework of SecPush.图6 SecPush方案架构图

SecPush包含客户端SDK、应用程序服务器端SDK和推送服务器三大部分.图6中通道1～4表示双方使用httphttps协议进行通信，通道5表示推送数据通过socket连接进行传输.

公开信息推送的运行流程如下：

1) Application调用Client SDK的初始化函数，向Push Server发送应用信息注册请求；

2) Push Server生成与Application对应的ClientId、公开信息加密密钥keyE_p以及公开信息HMAC运算密钥keymac_p作为应用信息注册请求的响应数据传递给Application；

3) Client SDK检查当前应用是否是该设备上第1个使用SecPush SDK的应用程序，若是，则建立当前设备与Push Server之间的socket长连接，管理该连接的Service组件即为设备上的PDDS组件；

4) 应用程序开发者通过Portal或Application Server，将推送数据提交给Push Server；

5) Push Server查询安装有目标应用的目标设备，并获取相应的加密密钥和HMAC运算密钥，构造推送数据Msgsend，通过Push Server与目标设备之间的socket连接将Msgsend发送给目标设备上的PDDS组件；

6) PDDS组件从Msgsend中获取目标应用包名，通过函数sendBroadcast将Msgsend发送给目标应用的Client SDK；

7) Client SDK通过enctype字段判断处理当前消息应当使用的加密密钥和HMAC运算密钥，之后通过HMAC运算判断Msgsend的完整性，提取pkgname字段和msgId字段的值判断其有效性，最后通过解密运算获取推送消息的明文，发送给相应的消息接收器进行后续处理.

私密信息推送的运行流程如下：

1) 用户登录Application，Application向Appli-cation Server发起登录请求，将用户名、密码、ClientId等信息传递给Application Server；

2) Application Server根据用户名、密码、ClientId等信息生成用户在当前登录设备上处理私密推送数据的加密密钥keyE_s和HMAC运算密钥keymac_s，作为登录请求的响应数据传递给Application；

3) Application Server需要推送私密信息时，调用Server SDK的接口，使用相应用户的加密密钥和HMAC运算密钥构建推送数据Msgsend，之后将目标应用的APP_ID，Msgsend，ClientId作为参数传递给Server SDK，由Server SDK向Push Server发起推送请求；

4) Push Server通过查询目标应用APP_ID及ClientId寻找与目标设备之间的socket连接，通过该连接将Msgsend发送给目标设备上的PDDS；

5) PDDS从Msgsend中获取目标应用包名，将Msgsend发送给目标应用的Client SDK；

6) 目标应用的Client SDK使用相应密钥进行后续处理.

为了提高公开信息推送的安全性，对于需要用户登录的应用程序，开发者也可以选择在用户登录后使用私密信息处理密钥对公开推送信息进行安全保护，Server SDK提供相应的接口供Application Server调用.

3.2 安全性分析

通过3.1节的设计，SecPush实现了推送数据分发环节的安全需求.

3.2.1 机密性

对于公开信息推送而言，推送数据的机密性并不是必要需求，因此这里的机密性主要指私密信息推送过程中推送数据的机密性要求.

对于私密信息推送而言，在SecPush的密钥分配方案设计之下，攻击程序无法获取同一设备上目标应用处理私密推送数据的加密密钥和HMAC运算密钥，因此无法解密推送数据中的密文数据以获取明文信息.

分析表明：SecPush可以有效对抗攻击程序实施的消息窃听攻击.

3.2.2 完整性

对于公开信息而言，虽然攻击程序可以伪装成目标应用从SecPush推送服务器获取加密密钥和HMAC运算密钥，但是由于推送服务器对于同一应用发送的不同注册请求返回的是不同的密钥，因此攻击者仍然获取不到目标应用正在使用的密钥，即使攻击程序使用获取到的新密钥解密并修改了推送服务器发送给目标应用的公开信息，其修改后的内容也无法被目标应用正确解析，篡改攻击无法成功实施.

对于私密信息推送而言，由于攻击者无法获取同一设备上目标应用处理私密推送数据的加密密钥和HMAC运算密钥，因此无法解密并修改推送服务器发送给目标应用的推送数据，也无法生成合法的HMAC运算结果.

分析表明：SecPush可以有效对抗攻击程序实施的消息篡改攻击.

3.2.3 不可伪造性

由于攻击程序无法获取目标应用正在使用的公开信息处理密钥和私密信息处理密钥，因此无法构造有效的推送数据密文，也无法生成该密文对应的合法HMAC运算结果.

分析表明：SecPush可以有效对抗攻击程序实施的消息伪造攻击.

3.2.4 抗重放攻击

由于Msgsend中包含msgId信息，目标应用在收到推送数据获取msgId值后通过查询数据库可以判断当前的消息是否被重放.

3.3 局限性分析

SecPush在发送公开信息时需要针对每一个接收信息的设备分别进行数据加密和HMAC运算，对推送服务器而言将会造成一定的运算负担，然而作者在实验时发现友盟推送在进行公开信息推送时，针对不同的设备也分别使用了不同的加密密钥进行数据加密操作，由此可知对公开推送数据进行独立的加密和HMAC运算不会给推送服务器带来过重的负担，具备现实可行性.

3.4 原型系统实现

本文实现了一个基于MQTT协议的SecPush原型系统用于有效性测试及性能测试，其中客户端SDK基于wmqtt.jar[4]实现，推送服务器基于开源消息代理软件Mosquitto[5]以及SAM-PHP[6]实现，服务器端SDK使用Java开发.推送数据的加密保护使用DES加密算法实现，数据完整性保护使用HMAC-SHA1算法实现.具体实现细节不再赘述.

4 实验与分析

本节将详细展示作者针对6个第三方Android推送服务进行攻击测试的实验结果以及SecPush的有效性测试和性能测试结果.

4.1 攻击测试实验

本文选取了6个使用PDDS组件的第三方Android推送服务作为实验对象，使用2.3节介绍的攻击模型，测试上述6个推送服务在数据分发环节的安全性.

4.1.1 实验对象选取

移动互联网企业运营解决方案整合平台DevStore[7]中列出了30个推送服务，通过对安智(Anzhi)市场和豌豆荚(Wandoujia)市场上随机选取的5 520个应用样本进行测试，作者获得了上述30个推送服务的市场占有率，排名前12位的推送服务如表1所示，分别为百度云推送(Baidu Push)、极光推送(JPush)、友盟推送(Umeng Push)、小米推送(MiPush)、个推推送(Getui Push)、腾讯信鸽推送(XG Push)、爱心推送(Ixintui Push)、华为推送(Huawei Push)、LeanCloud、魔推(mPush)、云巴消息推送(Yunba Push)和Cocos Push.测试样本于2015-05-26—2015-05-31从上述2个应用市场中爬取，其中3 526个样本来自于安智市场，1 994个样本来自于豌豆荚市场.

Table 1 Market Share of Push Services (Top 12)

在上述12个推送服务中，极光推送(JPush)、小米推送(MiPush)、个推推送(Getui Push)、Lean-Cloud和云巴消息推送(Yunba Push)采用每个应用创建并维持各自的socket长连接的实现方式,其中个推推送在其网站上说明其实现方式为多个应用共享1条长连接，然而经作者测试发现，每个使用个推推送的应用均各自在设备上维持1条连接到个推服务器的socket连接;其余7个推送服务均使用PDDS组件实现多个应用共享长连接的功能.由于作者未能在华为开发平台上注册成功，因此无法针对华为推送(Huawei Push)进行有效的测试，故本文选择其余6个使用PDDS组件的推送服务作为实验对象，即百度云推送[8](Baidu Push)、友盟推送[9](Umeng Push)、腾讯信鸽推送[10](XG Push)、爱心推送[11](Ixintui Push)、魔推[12](mPush)和Cocos Push[13].实验中所用6个推送服务客户端SDK版本如表2所示:

Table 2 Version Number of the Selected Push SDK

4.1.2 实验设计及结果分析

作者在上述6个推送服务开发平台上进行注册，获取推送SDK进行攻击程序及目标应用的开发.攻击程序使用2.3节介绍的攻击模型实现针对目标应用的窃听、篡改、伪造和重放攻击.目标应用严格遵循各平台的开发者文档进行开发，正确使用推送SDK实现相关功能.

选用自己开发的应用程序作为目标应用，只是为了方便随时发送推送数据进行窃听攻击的测试，在攻击程序针对目标应用的攻击成功之后，作者同样针对4.1.1节中获取的相关SDK的宿主应用样本进行了攻击测试，进一步验证了实验结果的正确性.

4类攻击实验的结果分述如下：

1) 消息窃听攻击

通过Hook推送SDK对sendBroadcast，send-OrderedBroadcast，sendStickyBroadcast等函数的调用，攻击程序可以在PDDS组件向目标应用分发推送数据的环节进行监听，获取传输的推送数据.

针对6个推送服务进行窃听攻击的实验结果如表3所示:

Table 3 Results of Eavesdropping Attack

除了腾讯信鸽推送(XG Push)，其他推送SDK均使用函数sendBroadcast或sendOrderedBroadcast进行数据传输，且多数SDK传输的是明文数据，因此通过Hook该类函数可以直接获取这些SDK分发的推送数据.

腾讯信鸽推送(XG Push)通过调用函数bindService，将推送数据放置在Intent类型参数中进行传输，并且传输的是加密后的密文信息.但是作者通过对SDK反编译代码的分析，发现在推送Service组件分发数据给目标应用之前，会进行SDK内的数据广播，在其中某个函数调用处可以获取推送数据的明文，因此通过Hook该函数，攻击程序可以在数据进行分发之前获取其明文信息.除了上述途径，通过调用腾讯信鸽推送SDK中的解密函数，攻击程序也可以获取密文信息对应的明文数据，解密函数不需要输入密钥参数.

友盟推送(Umeng Push)将推送消息内容的密文及其他参数的明文一起传递给目标应用，攻击程序无法直接获取推送消息内容的明文，但是通过对明文参数的分析，作者发现目标应用进行解密需使用的密钥被附在消息Id字段中一起传输，因此通过使用该参数并反射调用SDK中的解密函数，攻击程序同样可以获取推送数据的明文.

爱心推送(Ixintui Push)同样是将加密后的消息传递给了目标应用，但是通过调用SDK中的解密函数，攻击程序可以将这部分信息还原成明文，并且不需要输入任何密钥.

2) 消息篡改攻击

攻击程序在窃听数据的环节可以对数据中的部分字段进行修改，实现消息篡改的攻击.

针对6个推送服务进行篡改攻击的实验结果如表4所示.6个推送SDK的目标应用在收到篡改的消息后，均可进行正确处理，将篡改后的消息内容展示给用户，说明6个推送SDK在收到PDDS分发的消息后均未对消息的完整性进行认证.

Table 4 Results of Tampering Attack

实验中，由于友盟推送(Umeng Push)和爱心推送(Ixintui Push)从服务器端收到的信息均是密文，因此需要首先调用SDK中的函数对其解密，然后对篡改后的数据进行加密.

3) 消息伪造攻击

通过分析6个推送服务的消息格式，攻击者可以伪造数据传送给目标应用.伪造攻击可以达到与篡改攻击相似的攻击效果.

针对6个推送服务进行伪造攻击的实验结果如表5所示：

Table 5 Results of Forgery Attack

实验中发现，百度云推送(Baidu Push)有单独的推送数据格式类，通过使用Java反射技术创建该类的实例即可构造正确格式的推送数据.

此外，针对友盟推送(Umeng Push)和爱心推送(Ixintui Push)的伪造攻击依然需要进行相应的加密操作.

4) 消息重放攻击

攻击程序可以将窃听到的数据进行存储，之后再重放给目标应用.如果目标应用不对消息的新鲜性进行检测，将会对重放的消息进行再次处理.

针对通知类推送进行重放攻击的实验结果如表6所示.6个推送服务的推送数据中均包含msgId字段或类似字段，用来唯一标识当前消息，但是针对其中4个推送SDK的重放攻击依旧可以实施，目标应用依旧可以对重复的消息进行正常的处理，弹出通知，并在用户点击之后进行相应的操作.实验结果显示，在宿主应用收到经过PDDS处理的消息之后，推送SDK不再对消息的新鲜性进行检验，而是信任PDDS已经对此进行了验证，因此对于收到的消息依旧进行了正常的处理.

Table 6 Results of Replay Attack

上述实验结果表明，多数使用PDDS组件的第三方Android推送服务无法对抗窃听、篡改、伪造和重放攻击，没有实现其声称的典型应用场景所需要的安全需求，威胁用户的使用安全.

Fig. 7 Eavesdropping attack against SecPush.图7 针对SecPush的窃听攻击

4.2 SecPush的有效性测试

本文开发了2个使用SecPush SDK的应用程序：1)目标应用，其包名为com.lulupush.pushlibtest；2)攻击程序，其包名为com.example.mypushlibtest.

首先在设备上安装攻击程序，待攻击程序正确启动后，安装目标应用并启动.通过SecPush服务器向目标应用发送推送数据，目标应用在logcat中显示收到的数据如图7(a)所示，攻击程序的Hook Service窃听到的数据如图7(b)所示.

由于攻击程序无法获取目标应用正在使用的加密密钥和HMAC运算密钥，因此攻击者无法解密收到的密文信息.同样，由于没有相应密钥，攻击程序无法对收到的信息进行篡改或伪造有效的推送数据发送给目标应用.无论攻击程序如何篡改和伪造消息，目标应用都无法正确解析，并在logcat中打印出“HMAC failed!”信息.

攻击者程序将图7(b)中收到的数据重放给目标应用，目标应用没有展示相应的通知，且在logcat中打印出“Old Message!”信息.

实验结果表明，SecPush实现了推送数据分发环节的数据机密性、完整性、不可伪造性和抗重放攻击的安全需求，能有效抵挡来自该环节的攻击者.

4.3 SecPush方案的性能测试

移动智能终端由于能源资源有限，对应用程序的性能要求较高.本文通过连续发送1 000组推送数据的方式，测试SecPush处理数据时的能源和资源消耗，针对使用加密方案和不使用加密方案2种模式分别进行测试，分析数据加密及HMAC运算环节带来的额外资源和能源消耗.

实验中针对CPU占用率和内存使用情况的监测通过top指令进行采样，采样周期为1 s，取峰值作为展示数据.针对耗电量的测试，借鉴Android系统耗电量统计相关代码开发测试软件，获取目标应用处理推送数据期间对电量的消耗情况.

实验所用测试设备为三星Galaxy SIII手机，配备1.4 GHz 4核处理器、1 GB内存空间，电池容量为2 100 mAh.

实验所用推送数据在未采用加密及HMAC运算时构造的Msgsend长度为734 B，采用加密及HMAC运算后Msgsend的长度为1 019 B.应用程序通常不会在1条推送消息中放置大量数据，实验中选用的数据长度可以很好地反映推送数据在实际生活中的使用情况.

测试结果如表7所示.其中第1行数据是针对使用加密及HMAC运算enhanced mode的应用程序的测试结果；第2行数据是针对不使用安全保护机制normal mode的应用程序的测试结果；第3行数据为两者的差值，即加密及HMAC运算环节产生的资源和能源消耗.

CPU占用率的数值较大，是因为实验中的1 000组推送数据是连续发送的，在42 s内处理完成，因此对CPU的使用相对集中，实际使用中很少出现连续发送多组推送数据的情况，因此不会出现如此高的CPU占用率.本文额外测试了每隔3 s发送1组推送数据时CPU的占用率情况，测试结果显示CPU占用率的峰值为1%.

Table 7 Performance Test of SecPush

SecPush对1000组推送数据的安全处理仅带来2 774 KB的额外内存消耗，相对于测试设备1 GB的内存空间来说可以忽略不计.

此外，SecPush对1 000组推送数据的安全处理所带来的额外电量消耗为0.89mAh，仅占测试设备电池容量的0.04%，可以忽略不计.

由于实际使用中很少有应用程序在1 d之内收到1 000条推送数据，因此根据本文的实验结果可以看出，SecPush中增添的安全措施不会给设备带来沉重的资源和能源负担.

实验结果显示，SecPush方案提高了推送服务数据分发环节的安全性，且其带来的资源和能源消耗微乎其微，是增强推送服务安全性的有效方案.

5 相关工作

近年来Android系统获得了飞速发展，与之相关的安全研究也得到了广泛关注.文献[14]对Android安全相关的研究进行了详细的讨论，从系统安全和应用安全2个方面分析了现有的安全问题，介绍了相关研究成果.然而应用中广泛使用的第三方库的安全问题却不能简单归入这两类问题中.第三方库类似于Android系统与应用程序之间的中间件，同一个第三方库可能存在于多个应用之中，一旦第三方库出现安全问题，所带来的影响将远远大于单个恶意应用带来的影响.2013年Android OpenSSL库漏洞[15]的出现也使得人们越来越重视应用程序中广泛使用的系统库和第三方库的安全问题.

近几年，研究人员对Android应用中广泛使用的广告库进行了深入的研究.Grace等人[16]提出了AdRisk方案检测广告库中用户隐私信息收集及非可信代码执行行为.Stevens等人[17]对广告库中存在的收集用户信息、滥用宿主应用权限、追踪用户等行为进行了研究，分析其对用户造成的安全威胁.Book等人[18]的研究指出，广告平台还可以通过许以高额广告收益诱使移动终端应用程序开发者主动提供用户的隐私数据，造成用户隐私信息的泄露.此外，广告库还可能面临来自恶意开发者的攻击.Crussell等人[19]的研究指出，应用程序开发者可能通过对广告的虚假访问获取非法广告收益，造成广告主的经济损失.针对广告库使用模式中带来的安全问题，研究人员还设计了相应的安全防护方案，将广告库与宿主应用隔离，并限制广告库的权限和能力，以保护应用程序用户的使用安全，同时维护广告主的合法利益，相关方案包括AdSplit[20]，AdDroid[21]，AFrame[22]等.

推送服务与广告库同为Android应用中广泛使用的第三方库，然而由于功能逻辑不同，二者中存在的安全问题也有一定的差异.Li等人[2]详细分析了推送服务中应用程序注册过程和上传信息过程中存在的安全问题，这些问题可能导致目标应用的用户隐私数据被泄露或者导致目标应用执行攻击者的命令.与之不同，本文的工作针对的是推送服务客户端SDK在设备上的数据分发环节中存在的安全问题.由于使用PDDS组件进行设备上推送数据的转发，推送服务在数据分发环节可能面临来自恶意宿主程序的窃听、篡改、伪造和重放攻击.针对PDDS组件的使用模式，本文设计了相应的攻击模型，对市场上6个推送服务进行了攻击测试，测试结果显示，大部分第三方Android推送服务在推送数据分发环节没有实现针对推送数据的安全保护.腾讯信鸽推送和友盟推送等推送服务也仅通过使用SSL协议或加密算法提供推送数据在网络上传输的安全性，对于推送服务内部逻辑实现的安全性没有过多关注.

针对发现的安全问题，本文提出了相应的安全加固方案SecPush，方案中使用加密算法保护推送数据的机密性，使用HMAC运算保护推送数据的完整性.与本文的工作相似，Li等人[2]也在其文章中提出了针对推送数据的端到端保护方案Secomp，其中针对私密数据的推送同样采用认证加密算法提供机密性和完整性保护，而针对公开信息的推送只采用公钥签名进行完整性保护，即不同设备上的同一应用使用同样的公钥进行推送数据的签名验证.Secomp使用公钥签名虽然仅需要进行1次签名就可以将1条信息发送给当前应用的所有用户，然而移动终端设备在进行签名验证时将存在较重的运算负担.此外，一旦攻击者通过某种方式获取了目标应用使用的私钥，那么该应用所有的用户都将失去公开信息推送的完整性保护.与之相比，本文使用HMAC运算对公开信息推送进行完整性保护，与公钥签名相比减轻了移动终端设备的运算负担；另一方面，即使某个移动终端设备上该应用使用的HMAC运算密钥被泄露，其他移动终端设备也不会面临推送的公开信息被篡改的危险，并且HMAC密钥被泄露的设备也可以通过再次获取新的密钥保证后续推送数据的安全性.不同设备使用不同的密钥，虽然导致推送服务在发送公开信息时需要对每台设备分别进行HMAC运算，但是鉴于友盟推送在发送公开信息时亦是使用不同的密钥对不同的设备需要接收的信息进行加密，因此可知对公开推送数据进行独立的加密和HMAC运算不会给推送服务器带来过重的负担，具备可行性.

除了上述方案，文献[23]设计了一种使用对称密码算法及数字签名算法的消息推送服务方案，提供推送数据的加密性、完整性和不可否认性保护.方案使用对称加密算法加密推送数据，使用基于身份的数字签名算法对推送数据密文和其他参数进行签名.上述方案虽然实现了其安全性目标，然而为了使用签名算法，方案中需要额外引入第三方密钥生成中心PKG，且签名信息的验证也会给移动设备带来较重的运算负担.与该方案相比，本文的方案不需要引入第三方密钥生成中心，也不会给移动终端设备带来过重的运算负担，更适合移动终端设备使用.

6 结束语

本文分析了第三方Android推送服务在数据分发环节存在的安全问题，设计了相应的攻击场景，成功实现了针对推送数据的窃听、篡改、伪造和重放攻击，并具体展示了利用这些技术实施的用户私聊信息窃取及钓鱼攻击等攻击场景.实验结果表明，百度云推送、友盟推送、腾讯信鸽推送等第三方Android推送服务在数据分发环节存在严重的安全问题，没有实现其宣称的典型应用场景的安全需求，当开发者将推送服务用于这些场景时，有可能给用户带来实际的安全危害.为了提高推送数据分发环节的安全性，本文设计并实现了Android应用推送服务安全增强方案SecPush，实现推送数据机密性、完整性、不可伪造性和抗重放攻击的安全需求，为用户提供更安全更方便的推送服务.

[1]Urban Airship. The good push index [EB/OL]. 2013[2015-04-30]. http://urbanairship.com/resources/whitepapers/good-push-index

[2]Li T, Zhou X, Xing L, et al. Mayhem in the push clouds: Understanding and mitigating security hazards in mobile push-messaging services[C] //Proc of the 21st ACM SIGSAC Conf on Computer and Communications Security. New York: ACM, 2014: 978-989

[3]cmzy. ZHookLib [CP/OL]. (2014-11-12) [2015-04-20]. https://github.com/cmzy/ZHookLib

[4]IBM. IA92: WBI Brokers—Java Implementation of WebSphere MQ Telemetry Transport [CP/OL]. (2009-06-12)[2015-05-01]. http://www-01.ibm.com/support/docview.wss?uid=swg24006006

[5]WordPress. Mosquitto [CP/OL]. (2015-03-07) [2015-05-20]. http://mosquitto.org/download

[6]The PHP Group. SAM[EB/OL]. [2015-04-30]. http://php.net/manual/en/intro.sam.php

[7]DevStore. DevStore[EB/OL]. [2015-04-28]. http://www.devstore.cn (in Chinese)

(深圳尺子科技有限公司. 移动互联网企业运营解决方案整合平台[EB/OL]. [2015-04-28]. http://www.devstore.cn)[8]Baidu. Baidu Push [EB/OL]. [2015-04-30]. http://push.baidu.com (in Chinese)

(百度. 百度云推送 [EB/OL]. [2015-04-20]. http://push.baidu.com)

[9]Umeng. Message push [EB/OL]. [2015-04-20]. http://www.umeng.com/push (in Chinese)

(友盟. 友盟消息推送 [EB/OL]. [2015-04-20]. http://www.umeng.com/push)

[10]Tencent. Xinge [EB/OL]. [2015-04-30]. http://xg.qq.com (in Chinese)

(腾讯. 信鸽 [EB/OL]. [2015-04-30]. http://xg.qq.com)

[11]Ixintui. Ixintui [EB/OL]. [2015-04-20]. http://www.ixintui.com (in Chinese)

(北京麒麟心通网络技术有限公司. 爱心推 [EB/OL]. [2015-04-20]. http://www.ixintui.com)

[12]mRocker. mPush [EB/OL]. [2015-04-20]. http://www.mpush.cn/index.html (in Chinese)

(移石创想(北京)科技有限公司.魔推 [EB/OL]. [2015-04-20]. http://www.mpush.cn/index.html)

[13]Chukong Technologies. Cocos Push [EB/OL]. [2015-04-20]. http://www.cocospush.com (in Chinese)

(触控科技. Cocos开发者平台 [EB/OL]. [2015-04-20]. http://www.cocospush.com)

[14]Zhang Yuqing, Wang Kai, Yang Huan, et al. Survey of Android OS security [J]. Journal of Computer Research and Development, 2014, 51(7): 1385-1396 (in Chinese)

(张玉清, 王凯, 杨欢, 等. Android安全综述[J]. 计算机研究与发展, 2014, 51(7): 1385-1396)

[15]Kim S H, Han D, Lee D H. Predictability of Android OpenSSL’s pseudo random number generator [C] //Proc of the 20th ACM SIGSAC Conf on Computer & Communications Security. New York: ACM, 2013: 659-668

[16]Grace M C, Zhou W, Jiang X, et al. Unsafe exposure analysis of mobile in-app advertisements[C] //Proc of the 5th ACM Conf on Security and Privacy in Wireless and Mobile Networks. New York: ACM, 2012: 101-112

[17]Stevens R, Gibler C, Crussell J, et al. Investigating user privacy in Android ad libraries[C] //Proc of the 1st IEEE Workshop on Mobile Security Technologies (MoST). Piscataway, NJ: IEEE, 2012

[18]Book T, Wallach D S. A case of collusion: A study of the interface between ad libraries and their apps[C] //Proc of the 3rd ACM Workshop on Security and Privacy in Smartphones & Mobile Devices. New York: ACM, 2013: 79-86

[19]Crussell J, Stevens R, Chen H. MAdFraud: Investigating ad fraud in Android applications[C] //Proc of the 12th Annual Int Conf on Mobile Systems, Applications, and Services. New York: ACM, 2014: 123-134

[20]Shekhar S, Dietz M, Wallach D S. AdSplit: Separating smartphone advertising from applications[C] //Proc of the 21st USENIX Security Symp. Berkeley, CA: USENIX Association, 2012: 553-567

[21]Pearce P, Felt A P, Nunez G, et al. AdDroid: Privilege separation for applications and advertisers in Android[C] //Proc of the 7th ACM Symp on Information, Computer and Communications Security. New York: ACM, 2012: 71-72

[22]Zhang X, Ahlawat A, Du W. AFrame: Isolating advertisements from mobile applications in Android[C] //Proc of the 29th Annual Computer Security Applications Conf. New York: ACM, 2013: 9-18

[23]Yuan Jing. Research on the identity-based digital signature for mobile communication technology[D]. Wuhan: Huazhong University of Science and Technology, 2012 (in Chinese)

(袁静. 基于身份数字签名的移动通信技术研究[D]. 武汉: 华中科技大学, 2012)

Lu Yemian, born in 1989. PhD candidate. Her main research interests include Android application security and malicious code analysis.

Li Yifu, born in 1981. PhD. Intermediate engineer. His main research interests include network and information security.

Ying Lingyun, born in 1982. PhD. Senior engineer. His main research interests include malware analysis and mobile security.

Gu Yacong, born in 1989. PhD candidate. His main research interests include Android system security and malicious code analysis.

Su Purui, born in 1976. PhD. Professor. His main research interests include malware analysis and prevention.

Feng Dengguo, born in 1965. Professor and PhD supervisor. His main research interests include cryptography and information security.

Security Analysis and Enhancement of Third-Party Android Push Service

Lu Yemian1, Li Yifu2, Ying Lingyun1,3, Gu Yacong1, Su Purui1,3, and Feng Dengguo1

1(TrustedComputingandInformationAssuranceLaboratory,InstituteofSoftware,ChineseAcademyofSciences,Beijing100190)2(NationalComputerEmergencyResponseTeamandCoordinationCenterofChina,Beijing100029)3(SchoolofComputerandControlEngineering,UniversityofChineseAcademyofSciences,Beijing101408)

Push service is becoming a basic service for smartphone applications. Many companies, including official and third parties, have released their push services. In order to reduce resource cost, some third-party push services share push channels among applications running on the same device and using the same push service, which means that the background push component of one application acts as the push data distribution center for other applications. Due to the lack of considering security attributes such as confidentiality and integrity, the distribution part faces a variety of attacks. In this work we analyze the security issues in the data distribution part of third-party push services on Android. We design a corresponding attack model and implement attacks including eavesdropping, data tampering, forgery and replay attacks. During our experiments, it shows that most of the third-party Android push services using shared channels are subject to these attacks. It may cause some security hazards such as user privacy leakage and phishing attack. To mitigate the above threats, we propose SecPush which is a security enhancement scheme for Android push service. SecPush secures data distribution by introducing encryption and HMAC algorithm. Experimental results show that SecPush can effectively protect push data against eavesdropping, data tampering, forgery and replay attacks.

Android; push service; data distribution; shared channel; security analysis; security enhancement

2015-06-15；

2015-08-31

国家“九七三”重点基础研究发展计划基金项目(2012CB315804); 国家自然科学基金项目(61502468); 北京市自然科学基金项目(4154089)

应淩云(lingyun@iscas.ac.cn)

TP309

This work was supported by the National Basic Research Program of China (973 Program) (2012CB315804), the National Natural Science Foundation of China (61502468), and the Beijing Muncipal Natural Science Foundation (4154089).