应用程序屏蔽和应用程序内保护,哪个能更好的保护你的程序安全?
2020-08-25 13:36:03 Author: www.4hou.com(查看原文) 阅读量:251 收藏

导语:众所周知,攻击者往往会使用用户移动设备上运行的应用程序来攻击后端的系统,比如攻击者利用移动操作系统和你的应用程序中的漏洞来监视你,获取私人数据甚至窃取资金。

微信截图_20200412115810.png

众所周知,攻击者往往会使用用户移动设备上运行的应用程序来攻击后端的系统,比如攻击者利用移动操作系统和你的应用程序中的漏洞来监视你,获取私人数据甚至窃取资金。为了应对这种情况,许多移动应用程序开发人员正在使用应用程序屏蔽,有时称为“应用程序强化(app hardening)”来缓解攻击者对应用程序发起的各种攻击。

应用程序强化或应用程序屏蔽对于防止逆向工程很重要,但该方法不会在你的应用程序运行在一个危险的移动设备的环境中检测到实时的网络攻击。移动应用程序需要额外的应用程序内保护,以保护你的应用程序免受攻击和欺诈。

研究者在2019年7月发布了一份 “应用程序内保护市场指南”,所谓应用程序内保护是指在应用程序(而不是网络或操作系统)中实施的安全解决方案,这样应用程序更能抵御恶意数据泄露、入侵、篡改和逆向工程等攻击。企业使用应用程序内保护来保护其基于软件的资产,并保护其组织和客户免受欺诈性攻击。

包含个人身份信息和知识产权的金融、医疗保健和公民服务应用程序应同时实现应用程序屏蔽和应用程序内保护。在本文,我将描述每种情况,并提供示例应用程序来实现应用程序内保护以及它们所保护的数据。

什么是应用程序屏蔽?

应用程序屏蔽是一组用于修改和混淆应用程序的二进制代码的技术。应用程序防护使应用程序更具防篡改性,可以防止通过逆向工程和未经授权的访问来窃取机密。它创建了一个更具弹性的应用程序,通过混淆和加密二进制代码使逆向工程更加困难。

应用程序屏蔽功能包括:

1. 代码混淆,混淆是修改人类难以理解的源代码或设备代码的蓄意行为。使代码难以理解会阻止攻击者试图从你的代码中挖掘潜在的缺陷、漏洞或对IP进行逆向工程。

2. 调试检测,应用程序阻止和检测调试,并响应当前的调试器,必须涵盖所有可用的调试协议。

3. 模拟器检测,模拟器检测使应用程序能够检测它在模拟器中的操作。模拟器用于对应用程序进行逆向工程,并识别其与其他服务的通信。

4. 根或越狱检测,越狱或根检测会检测用户是否删除了苹果或谷歌在设备上设置的限制。越狱检测很重要,但不能检测到设备受到攻击。

5. 应用篡改,尽管混淆有助于防止对静态(非运行)代码进行逆向工程,但攻击者仍然可以通过在运行时“钩住”应用来尝试逆向应用。应用程序篡改包括检测攻击者是否尝试对应用程序进行逆向工程。

什么是应用程序内保护?

应用程序内保护与应用程序屏蔽不同,它可以从应用程序内部检测实时恶意软件,网络和操作系统攻击。移动威胁防御技术被置于移动应用程序内部,以检测和补救对应用程序和设备的威胁。

应用程序内保护可保护后端系统免受可能携带的移动恶意软件或易受攻击的移动设备的攻击。虽然我们无法控制移动设备上应用的安全状况,但是如果在移动设备上检测到恶意软件,危险的配置或网络攻击,则可以限制设备与受攻击的程序进行通信。

除了越狱和仿真器检测之外,一些数据应用程序内保护还提供:

1. 恶意软件检测,应用程序内保护可检测设备上的多种恶意软件,并建议用户进行补救。随着用户继续迁移到移动设备,恶意软件也会迁移。 Bankbot,Monokle,Anubis和Cerebus等恶意软件样本和远程访问工具RAT已出现在移动设备上,随着越来越多的公司将更多服务推向移动设备,这种趋势还将继续。其中许多RAT会监控剪贴板、密码,以收集有关用户和凭据数据。

2. 零日检测,应用程序内保护可检测通过文件系统和操作系统行为利用的漏洞。通过动态监控危害指标与查看已知漏洞的云库,或仅检测设备上安装的OS版本/补丁程序级别的指标,就可以检测到零日攻击。

3. 网络或Wi-Fi缓解,应用程序内保护检测网络连接操作和中间人(MiTM)攻击。你的应用程序应该能够识别“中间人”(MiTM)、SSL剥离,并尝试代理或解密你的用户的应用程序流量,以纠正攻击和产生有关威胁事件的威胁取证。

4. 设备配置风险,这个风险主要来自用户自己。用户选择是否更新操作系统以修补已知漏洞,使用PIN码或越狱设备。应用程序内部的应用程序内保护可让你查看应用的安全状况,并最终了解移动应用程序的风险状况。

应用程序屏蔽和应用程序内保护有什么区别?

应用程序屏蔽和应用程序内保护是互补的,在许多情况下,为了全面降低风险,用户应该在移动应用程序中同时使用这两种技术来增强预防能力并阻止攻击者获取更多隐私数据。至于你决定使用哪一种方法来保护,则取决于你的应用程序的运行方式,以及它定期存储和处理的信息类型。

为了达到最优的安全水平,移动开发团队投入大量时间来设计和构建直观的移动应用程序。这样的程序会自动执行标准的安全检查,并尝试遵循良好的编码习惯。但是,在运行时保护应用程序的安全也至关重要。因为移动应用程序是依赖操作系统来提供安全运行的基础,所以如果设备受到威胁,那么移动应用程序的整个安全基础也会受到威胁。

一个自我保护的应用程序可以不依赖设备本身的安全性能来安全的运行和操作,具有运行时安全技术或应用程序内保护的移动应用程序能够独立于本机安全功能检测恶意活动。这种独立检测可及时识别野外的威胁,并最终避免不可接受的风险暴露,并最终保护应用程序和服务器端的交易和数据。

设备本身的操作系统有多脆弱?

移动应用程序开发人员依靠底层操作系统来确保安全性,但是,尽管移动操作系统本身已经加强了防御攻击的能力,但它们并非万无一失。众所周知,研究人员每年都会发现成千上万的新漏洞。事实也是,研究人员和恶意攻击者都在不断测试Android和iOS,以通过漏洞赏金计划、内部研究或将零日价格卖给出价最高的人来寻找漏洞。目前,一个在iOS上远程传输的持续性漏洞可以卖到200万美元。

2019年,移动操作系统供应商为1161个安全漏洞创建了补丁。而苹果则修复了306个CVE (即常见的漏洞和暴露),其中64%被认为是“严重”安全威胁。

Google在2019年修补了855个CVE,其中大多数(54%)被认为是“严重”或“高”安全威胁。严重CVE是一类允许远程执行代码或远程绕过安全功能的漏洞,如果严重CVE成功执行,则攻击者就可以远程访问数据或绕过操作系统安全保护,进而发起各种功能。

即使所有漏洞的补丁都在规定的时间内交付,用户也必须升级他们的设备以提高安全性。但如果依靠用户来打补丁,则是一场安全赌博。因为许多设备太旧了,无法再升级。

为什么需要实施OWASP?

开放式Web应用程序安全项目(OWASP,Open Web Application Security Project)是一个组织,它提供有关计算机和互联网应用程序的公正、实际、有成本效益的信息。其目的是协助个人、企业和机构来发现和使用可信赖软件。

如果你正在遵循OWASP Mobile Top 10,那么你很可能已经实现了应用程序屏蔽以及强化过程和工具。OWASP建议你实现用于身份验证、数据存储、加密和逆向工程的控件。然而,在移动安全和应用强化方面,还存在很大的改进空间。

Zimperium(Zimperium成立于 2010 年,由著名黑客 Zuk Avraham 创立,旨在为手机提供解决方案,以防受网络攻击。)此前曾对来自银行、旅游和零售行业的应用程序进行过安全、隐私和监管方面的OWASP Mobile Top 10进行了审查。他们发现大多数应用程序没有通过逆向工程检查。逆向工程应用程序可以使攻击者发现漏洞和通信方法。未能正确实施安全强化并通过移动应用程序暴露漏洞的最著名例子之一是乐购银行( Tesco Bank )。2016年英国零售业龙头特易购旗下的银行事业Tesco Bank传出遭骇客攻击,有超过4万个帐户遭锁定、2万个帐户被成功骇入,用户存款遭到盗领。这起英国有史以来最严重的网路窃盗事件,导致Tesco Bank共13.6万个帐户中的4万个遭到骇客锁定攻击,2万个被成功盗走存款。经查,是Tesco Bank的移动应用程序存在漏洞,这为网络攻击者强行进入银行盗取存款打开了大门。然而,许多受影响的账户并不是移动银行客户,而是从一个安全性很差的移动应用程序发起的攻击。

另外,移动应用的开发人员可能还需要实施应用程序内保护,以符合特定的法规和政策。 PSD2要求移动应用程序开发人员能够检测第三方操作并实现独立的身份验证环境,另外,GDPR和《加州消费者隐私法案》还强制程序要执行数据隐私和删除私人数据的功能。 另外,PCI DSS和HIPAA等其他规定的颁布,也旨在减少支付和医疗保健行业的攻击行为。全称Payment Card Industry (PCI) Data Security Standard,第三方支付行业(支付卡行业PCI DSS)数据安全标准,是由PCI安全标准委员会的创始成员(visa、mastercard、American Express、Discover Financial Services、JCB等)制定,立在使国际上采用一致的数据安全措施,简称PCI DSS。HIPAA全称为:Health Insurance Portability and Accountability Act/1996,Public Law 104-191,尚没有确切的正式中文名称,国内文献一般直接称为HIPAA法案,有的称为健康保险携带和责任法案,也有取其意为医疗电子交换法案;台湾有文献翻译为义务型可携带式健康保险法案。

在移动应用程序中安装应用程序内保护的具体案例

近日,一家全球银行承认,它拥有数百万个客户和数十万名员工,通过五十种不同的企业和用户移动应用程序连接到其后端系统。该银行的IT员工意识到无法确定与银行系统交互的客户或员工设备的安全运行状况,该银行发现有必要了解与移动设备与其系统交互相关的风险。

然后,这家美国银行进行了详尽的搜索,并测试了所有可用的移动安全解决方案。团队一致选择应用程序内保护方案来保护其员工设备、消费者银行业务和内部员工移动应用程序的安全。

该银行计划将移动安全防御系统嵌入其消费者移动银行应用程序中。通过将威胁防御部署到其移动银行应用程序,该银行现在可以识别在受损或有风险的设备上进行的可疑交易。

在部署之前,银行缺乏来自客户设备的安全数据。在部署后,这些安全数据就会很容易获得。

应用程序更新后,用户立即开始使用受网络保护的应用程序进行移动银行交易。安全人员发现,用户的移动设备及其连接的网络的安全状况令人震惊。

在头30天里,该银行记录了近100万起针对客户移动设备的威胁,只有在银行应用程序打开时才会记录威胁数据。如果该应用程序被关闭,银行不会收到来自用户的威胁数据,因为其他应用程序中的会话不会对银行构成欺诈风险。

在最初的30天内,数百万移动银行用户更新了应用程序,并开始对移动攻击的行为进行数据取证:

1. 276000次不安全的Wi-Fi检测;

2. 1433个恶意接入点检测;

3. 495000台设备没有PIN码;

4. 启用了166000个第三方应用商店访问权限;

5. 16000个根或越狱的设备;

6. 1000个记录了系统或文件篡改的事件;

7. 用户的智能手机上有1500个根应用和另外500个包含恶意软件、特洛伊木马和间谍软件的应用。

目前,该银行已掌握了如何通过移动渠道防范欺诈的可操作数据,涉及金额超过11亿美元。所有这些都是通过使用移动威胁防御SDK更新现有的应用程序来实现的,该SDK的配置时间不到10分钟。

本文翻译自:https://blog.zimperium.com/app-shielding-vs-in-app-protection/如若转载,请注明原文地址:


文章来源: https://www.4hou.com/posts/nNnR
如有侵权请联系:admin#unsafe.sh