专家观点:安卓移动应用安全发展路线
2021-06-11 12:27:37 Author: www.freebuf.com(查看原文) 阅读量:105 收藏

一、移动应用安全简介

移动应用安全一直是一个各方面需要重视的问题,从早期的二次打包批量插广告,伪造应用开始,安卓的安全性就开始受到各个安全厂商的重视。

早期,安卓应用的安全性是受到自身系统的拖累,不得不重视。相反在iOS上,虽然也会有一定的安全问题,但是没有安卓上那么的严重。

早期的安卓分发渠道真的是群魔乱舞,现而今受到各方面的监管,情况已经有所改善。但是也存在小白用户莫名其妙扫码下载、论坛下载一些乱七八糟的应用,最后导致自己中招了还不明白怎么回事的情况。

二、移动应用安全的发展历程

2010年,随着智能手机兴起,安卓应用市场野蛮式生长,各种黑产满天飞。二次打包插入广告,修改官方应用种木马等现象数不胜数。

2012年,厂商开始推出安卓加固服务,在当时能够抵挡很大一部分黑产的攻击。但随着产业的逐渐成熟,各路黑产大神的进场,安全对抗不断升级。

2014年,随着gdb xposed 等调试注入工具的进入,安全防护不再局限于代码层面,防调试、验签名等安全措施的出现,逐渐补齐了立体防护的短板。同时动态加载机制被广泛使用,其原理也被大家悉知,随之而来的是各种dump整理加密的工具出现。

2015年,对于代码层面的保护,一直是重中之重,从dump工具的出现,逐渐出现了指令抽取方案、二代指令抽取方案等等,皆是为了与各种黑客工具的对抗。

2018年,相比于x86环境,vmp的保护方案也出现在android上。虽然有些大神耗费大量时间能够获取到部分指令映射表,但是如果的去还原一个函数,投入也非常之大。

到2021年的现在,各大移动应用安全厂商的安全技术保护面基本相似。

三、移动应用保护方案

1623381440_60c2d5c014bd63ba1a526.png!small

1、整体加密

此项保护方案是早期安卓应用防护的必备项目,原理是将apk包中代码的dex文件进行一次加密,然后使用动态加载的方式,在应用application中再去动态的解密加载整体代码到内存当中。

2、指令抽取

受限于安卓的动态加载技术,最后加载运行的必然是解密后的代码体,而通过hook技术也能很方便地把内存中的dex块dump出来写到文件当中。因此诞生了指令抽取的技术方案,将具体的Java函数体当中的指令提取出来,整体封装加密。原有的函数体进行一些垃圾代码或空指令的填充,在整体dump dex体的时候代码并没有实际还原,无法查看到具体逻辑。而在实时运行的过程当中,当类被加载时,再将该类中被抽取的指令进行回填,此技术的弊端在虽然函数抽取的细粒度时方法,但是回填的细粒度却是类。

3、第二代指令抽取

黑产工具的不断迭代,指令抽取技术也会被循环遍历类的方式全部加载并回填,最后再进行dump。为了防止此工具第二代指令抽取也就诞生了,真正能够做到函数运行时再进行代码回填。

4、VMP保护

VMP protect并不是一个新鲜的技术,早期的x86时代已经被老牌安全厂商玩得很熟练了。即自定义一个Java虚拟机,将原始的指令转化为自定义的指令,运行时将该函数放到自己的虚拟机中运行,从而整体逻辑无法被跟踪与逆向。

当然,VMP技术各大厂商也有多个版本迭代,但是各种变化也脱离不了自身的虚拟机运行。同时,安卓的环境目前也没有很好的跟踪vmp指令的工具,所以目前来看vmp对安卓java代码的保护还是挺不错的。

5、java2c保护

该技术同样也是对java代码的保护方案,将原有的java代码编写的逻辑全部转换为c代码的逻辑,普通计算使用原生c代码,函数调用使用反射方式进行,但是c代码的逻辑编写本身就会比java复杂,最后会导致的必然是运行效率的降低与代码大量膨胀的结果。

6、native层保护

针对于native层防护各个安全厂商就开始有一定分歧了;

a.常见的就是类似upx的加壳了,对原始elf文件进行代码段的加密压缩,init运行时进行释放;

b.符号的变换,利用hook dloen dlsym 等方式进行还原;

c.自定义linker ,使用自己的linker对加壳后的elf文件进行加载;

d.vmp,同java vmp,使用自定义虚拟机运行指令,目前市面上尚无基于arm elf文件的vmp,大部分还是基于源码在IR层的转换。

e.其他

7、其他基础安全防护

a.apk安装包的完整性保护,防止删除/添加/替换安装包中的文件;

b.签名验证,即在保护时将原始包的签名打入加密的壳中,运行时再进行校验;

c.防调试,常见的有ptrace占位、各种状态的检查等

d.其他安全措施,数据/资源加密、防截屏录屏,防界面劫持、安全加密(白盒)等等

四、纵深的安全防护

1、割裂的安全防护

从接触到的很多应用厂商来看,公司/企业越大,安全防护割裂这个问题就越严重。业务团队、开发团队、安全团队各自为政。开发团队向业务部门负责,实现需要的功能就行,安全团队会进行各种安全检测,向开发团队提出各种要求,开发就是最终的背锅侠。这种部门之间的割裂,必然会导致信息的隔离,开发人员不懂安全防护,而安全团队无权限阅读代码,无法做到更深层次的评估,业务漏洞或代码漏洞比比皆是。最终安全团队想找一家安全厂商来搞定一切安全问题极为不现实。

2、安全防护应该从立项开始

从一个项目开始安全团队就应该积极介入,从业务漏洞的评估,到代码的安全审查,再到最后的整体防护。通过各个部门之间的联动来提升整体的安全强度,而不是把安全交给最后一棒。

3、贴合实际的防护

从第二点可以看到安全厂商能够提供的保护项目非常之多,各种策略的配置也眼花缭乱,不在这个圈子里每天加深印象,真不懂你这个保护方案到底是怎样的,能起到什么作用,导致的结果就是“你有的,我都要”、“出问题,安全厂商的问题”。

应用开发厂商需要根据自身的切实需求积极和安全厂商进行沟通,调整保护方案。同时针对自身的安全关注点,向安全厂商提出自己的其他诉求。

抛开“人”的问题,厂商之间的合作应该是一种亲密无间的关系,而不应该是防家贼似的。毕竟做安全的最高境界就是“你中有我,我中有你”。

五、该怎么做安全

1、秉持“适合自己的,才是最好的”的安全策略;

2、明白安全与业务/兼容性是此消彼长的关系;

3、在复合监管的基础上使自己的利益最大化。

具体落实到不同行业,应该寻找好自己的安全定位,以下列举几个不同行业的细分,谈谈我对安全的理解。

说明:

1.金融行业,因为涉及到“钱”的问题,再高的安全防护都不为过。不能因为自身的安全缺陷导致用户的实际“利益”受到损失。

2.互联网行业,需要的是用户数、日活等各种数据指标,所以兼容性与运行效率应该放在第一位。但是核心的业务逻辑也不能被随意破解,因此VMP的保护范围可以集中在自己的关键逻辑上,而其他的业务安全的增多,必然导致性能降低,崩溃率的提高,最终导致用户的流失,所以重点可以放在威胁情报的收集,对危险行为收集证据,事后进行追溯

3.运营商行业,运营商更关注的是投诉率,由工信部严格监管,但是同样也涉及到客户的切身利益“话费”的问题,暗扣的花样越来越多,已经不是靠最后一棒的防护能够完全解决的。打铁自身硬,业务的安全是运营商的重中之重

4.政企行业,政府应用当然需要做到最高的兼容率与最高的运行效率,为了保证全国所有的智能机,包括一些陈旧的垃圾手机都能运行,太多的安全防护而导致一些“老年人”无法使用,就不应该了。同事黑客在这个方面还是有一定操守,毕竟产出太小,还容易吃牢饭。企业自身的应用同样因为受众面小,不会大规模外发,不需要太考虑一些危害不大的安全漏洞。

5.能源/交通/教育/医疗行业,基础设施的建设,涉及到使用的人会非常多,同样需要考虑兼容性与性能,但是也不能太差。重点应该放在后端,例如,如果发现有刷XX的行为,完全不需要在客户端防护,后面直接把帐号禁用3个月,这个威慑力也会比较有作用。

6.整体来说,基础的安全措施必须包含:Java代码的整体防护、核心业务的vmp保护、自研的so文件加壳/混淆,附加安全功能基本的有完整性的保护、签名的验证、防调试、资源/数据加密。

六、任重道远的安全

写到最后的总结,只想说做好安全,任重道远。只要哪里有“利益”,哪里就必须有安全。安全有可能会迟到,但是永远不会缺席!


文章来源: https://www.freebuf.com/articles/neopoints/277179.html
如有侵权请联系:admin#unsafe.sh