雀恰营销
专注中国网络营销推广

Android应用安全现状与解决方案

Android应用安全现状与解决方案

**

安全对于一些涉及直接货币交易或个人隐私的应用程序的重要性是不言而喻的。由于Android系统的开源特性,市场上针对开源代码定制的ROM不同,系统层面的安全防范和漏洞也不尽相同。许多漏洞提供了机会。虽然市面上一些主流APP已经采取了一些安全防范措施,但由于大部分APP不涉及金融安全,对安全的重视不够;又因为安全是一门系统的学科,所以应用层的大部分开发者都缺乏安全性。技术的积累,措施相对有限。

本文将重点分析Android APP面临的安全问题、防范措施以及一系列安全技术方案的实施。

**

病毒面临的安全问题

Android 病毒是移动特洛伊木马,主要是恶意应用程序。例如,去年央视曝光的一款名为“Bank Bandit”的手机银行木马,模仿真实手机银行软件,通过钓鱼获取用户输入的手机号、身份证号、银行账号、密码等信息,并存储这些信息。信息上传到黑客指定的服务器。盗取银行账户密码后,立即将用户账户中的资金转出。有的手机木马独立存在,有的伪装成图片文件附在正版应用上。它们极其隐蔽,有些病毒也会出现变种,而且每一代都更加强大。

这些病毒有一些共同特征:

关键信息泄露

虽然java代码一般都被混淆了,但是Android的几个主要组件的创建方式都不能混淆依赖注入的方法,而一些常用的反编译工具apktool等可以很方便的还原java中的明文信息,而且Native中的库信息也可以通过objdump或者IDA获取。所以,一旦在java或者native代码中有明文的敏感信息,基本上是不安全的。

APP重新打包

反编译后重新添加恶意代码逻辑,重新打包一个APK文件。重新打包的目的一般是和上面提到的病毒结合,解压正版apk,插入恶意病毒重新打包释放,所以伪装性很强。拦截应用的重新打包,一定程度上可以防止病毒的传播。

进程被劫持

这几乎是目前最具针对性的攻击方式。一般通过注入或调试进程来钩住进程,改变程序运行的逻辑。和sequence,获取程序运行的内存信息,即监控所有用户行为,这也是盗取账号密码最常见的方式。

 当然 hook行为不一定完全是恶意的,比如有些安全软件会利用hook的功能做主动防御(比如 LBE和我们移动安全实验室最新的apkprotect线上加固产品)。一般来说,hook需要获取root权限或者跟被hook进程相同的权限,因此如果你的手机没有被root,而且是正版apk的话,被注入还是很困难的。 

数据在传输过程中被劫持

传输过程中最常见的劫持类型是中间人攻击。很多对安全性要求高的应用都要求所有业务请求都通过HTTPS,但是HTTPS的中间人攻击逐渐增多,我们发现在实际使用中,在一些山寨手机上进行证书交换和验证手机或非主流ROM。有一些问题阻碍了 https 的使用。

键盘输入安全风险

支付密码一般通过键盘输入Android应用安全现状与解决方案,键盘输入的安全性直接影响密码的安全性。键盘的安全隐患来自三个方面:

我之前做过一套安全键盘方案,就是自定义键盘+数字布局的随机化。但是随机键盘很不符合人类的操作习惯。所以后面的随机词也被删除了。

还需要说明的是,trustzone标准已经有了GlobalPlatform_Trusted_User_Inteface,也就是说有一套实现trustzone安全接口的标准,如果安全键盘在trustzone ,黑客无论如何都拿不到密码,这是目前最安全的方式,但是 trustzone 依赖于设备的底层实现。如果设备不支持 trustzone,或者 trustzone 不支持 GlobalPlatform_Trusted_User_Inteface 标准,我们无能为力。 *

Webview 漏洞

由于混合应用的盛行,Webview 在应用中的使用也在增加。 Android系统Webview存在一些漏洞,导致js提权。其中最著名的是传说中的js注入漏洞和webkit xss漏洞,我们将在后面的章节中详细介绍。

服务器未处理,被渗透攻击

最常见的是反重放攻击和注入攻击,不在本文讨论范围内。

熟悉Https的Android APP安全架构

本质上,https是一个双向认证过程,但由于Android设备太多,Android设备的证书并不统一。应用安全,一般只有客户端验证服务端证书,服务端在https层不验证客户端证书,所以实际应用场景是单向验证过程。

schemeRegistry.register(new Scheme("https", SSLSocketFactory.getSocketFactory(), 443));

这里是用google API验证https,主要检查四个方面:

签名CA是否合法 域名是否匹配 自签名证书是否过期

如果服务器使用的根证书是自签名的,或者签名机构不在设备的信任证书列表中,使用httpclient的https连接会失败。 有几种方法可以解决这个问题:

支付密码的安全性

支付密码只是一个比较有代表性的数据,它实际上代表了客户的一些敏感数据,比如银行卡号、手机号、密码、cvv、到期日等。特别是对比强敏感数据例如密码和cvv,以提高应用程序的性能,防止他人破解。

我们使用RSA和AES两组加密方式对这些数据进行加密,如下图:

首先我们会生成x位随机秘钥,要加密的数据用随机秘钥加密,最后秘钥是Base64编码的。此时的数据就是我们要上传到服务器的敏感数据。大家都知道AES是一种对称加密。算法,服务器必须知道解密的秘钥。

但是我们的秘钥是随机的,服务器是怎么知道的呢?如上图所示,我们用RSA公钥加密这个随机秘钥,加密后的数据也被加密了。 Base64编码上传到服务器,因为服务器有RSA的私钥,所以服务器可以得到AES加密的随机密钥。

因为我们的AES每次都是用随机密钥加密的,没有固定的密钥,所以AES的加密是安全的,而且由于RSA是非对称加密,所以我们的so只存储RSA公钥,所以也是安全的。

总之应用安全,只要不泄露服务器的私钥,就可以保证数据的安全。

数据无论是传输还是存储都需要加密。如果加密算法不健壮,很容易被破解或模拟。如果太健壮,通信服务器就无法支持高并发和高流量,所以加解密算法的选择也很重要。重要的。这里顺便说明一下我们选择加密算法的注意事项。

为什么要使用 RSA 加密?因为RSA是非对称加密,客户端只拿到公钥,公钥只能用来加密,不能用来解密,这样可以保证数据的安全,因为没有私钥是无法解密的。

    为什么不都用RSA加密?既然RSA加密这样安全,为什么不都用RSA加密的,因为RSA加密也是有一些弊端:
     RSA的加解密对性能开销很大,所以不建议大量使用,以增加服务端压力;
     RSA对加密的数据长度有限制,具体长度是与RSA秘钥位数有关系,所以对于比较长的数据RSA没法加密。
    不管RSA加密还是AES加密都进行了一下Base64编码,这个是需要注意的地方,因为RSAAES加密出来的都是二进制流,在转化成字符串时候可能出现空格造成数据的截断,所以必须编码一下不要让它出现空格。

应用程序强化

    应用加固包括病毒扫描模块,防注入,防调试,防篡改模块四个模块,目前行业内已经出现了很多的应用加入解决方案,入爱加密、梆梆加密、百度加密、360应用加固等等。

病毒扫描模块

    病毒扫描模块和目前市面大多的安全卫士类app一样,摒弃了传统的依赖本地病毒库的杀毒引擎,采用了百度手机卫士的云扫描杀毒引擎。云扫描杀毒引擎在云端有一个定期更新的病毒库,扫描主要是通过收集本地安装的 App的信息,通常是apk里包名、签名、sodex等信息,上传到云端, 云端通过比较程序签名和病毒库中的签名判断是否为病毒,然后将扫描结果返回给本地。 
    现在有些病毒扫描还结合人工智能深度学习利用服务器端的病毒数据库进一步查询可疑程序。还有些扫描作了一些主动防御,通过监控敏感api进行防御,例如监控以下敏感操作:更改浏览器主页,注册开机启动的行为,应用程序的内存注入等。 

反调试模块

调试是指当前app被其他程序使用特定方法(debugger、ptrace等)跟踪劫持,被调试app的所有行为都可以被其他程序查看和修改。您可以通过gdb想到通常的调试程序。

反调试功能分为两步:首先检测当前app是否正在调试。如果正在调试应用程序,则返回调试器进程的进程名称。如果应用没有被调试,请保护应用不被其他程序调试。

有两种方法可以保护应用不被调试:

我们知道一个进程只允许有一个调试器Android应用安全现状与解决方案,所以当进程启动时,它会fork

一个daemon(守护进程),ptrace受保护的app进程,daemon进程会拦截调试器的入口,保证其他程序不能再调试当前app。一旦守护进程被激活,它将一直存在,直到当前应用程序退出。

如果强制关闭守护进程,当前的应用程序也会被关闭。这里要注意信号的处理。

防注入模块

注入是指当前App进程被其他程序使用特定方法(ptrace、dlopen等)插入到一个不属于当前App的模块中。一般来说,注入不是目的,而是一种手段,所以注入的模块一般都有特殊的行为,比如收集app的隐私数据,使用hook等方法劫持app的正常运行过程等等。对他们来说,Hook 是主要的安全风险。

从技术角度来说,注入的前提是需要调试的。所以如果当前App已经被保护不被调试,理论上是没有被注入的风险的。但是,如果反调试模块稍后被激活,应用程序可能在激活之前仍然被注入。防注入功能是检测当前App被注入和劫持了哪些模块(Hook)。

Android平台中hook的方法分为两类:Java Hooks和So Hooks。 Java Hooks 分为静态成员

钩子和函数钩子,可以通过检查vm dex memory的fields字段和method字段来判断是否有java注入。所以钩

也是所有linux系统的hook方式,分为GOT Hook、Symbol Hook和Inline Hook。内联

Hook一般通过程序集、Symbol注入

Hook 一般使用 LD_PRELOAD 方法给函数添加钩子。这两种注射目前都不是很安全。主要保护是GOT钩子。

作者几年前曾经通过GOT hook。原理是在系统中植入su程序,无需刷机,无需root权限,强制root系统。 GOT的原理

Hook就是简单的通过cat获取app进程的so加载地址

/proc/pid/maps,然后通过分析GOT表Offset地址得到so中的各个函数,计算出函数入口的绝对地址,然后将该地址处的函数替换为注入函数。因此,防止native注入的方法是:通过app

进程空间,检查加载的库是否都在/system或/data/data/app下,如果不是,肯定有注入。

防篡改模块

判断一个app是否为盗版的传统方法,业界惯例是提前收集大量正版app信息做白名单,然后利用当前app的包名、签名等信息匹配。此方法的准确性取决于白名单库的大小,并且需要网络连接。防篡改功能根据重打包app的排列特性和正版app的dex判断app是否被重打包,速度快,准确率高。

Android 安全编程

Android 的某些特定语法和设计也存在被攻击的危险。通常,我们的代码会在正式发布之前进行安全扫描。最重要的安全扫描是扫描以下几点:

这个比较简单,不允许打印敏感数据,发布前必须关闭打印日志的开关。

为了启动另一个应用程序的Activity,我们经常使用一些隐式Intent。如果其中包含一些敏感信息,只要第三方app注册了相同的Intent Filter,就可以拦截到敏感Intent。信息,因此要发送隐式 Intent,您必须指定收件人和权限。

安全组件的安全性

Android包括四个组件:Activitie、Service、Content Provider和Broadband Receiver,每个组件都可以通过外部隐式Intent打开,所以这些组件只要不对外开放,都必须标记为清单中的 false ,并且禁止其他程序访问我们的组件。对于需要与外界交互的组件,你应该添加访问控制,并且你还需要保护传输的数据。检查。

IPC 空引用

这种情况主要发生在对外开放的组件中,因为对外开放的组件可以接收到Intent,一般会包含一些数据。当数据为空时,应用一般会崩溃,攻击者可能会发送一个空数据的Intent进行攻击。

WebView漏洞攻防js注入漏洞

这个问题可以追溯到2011~wedu/Research/paper/webview_acsac201的一篇论文《Attacks on WebView in the Android System》1.pdf,这篇文章指出了addJavascriptInterface方法带来的一些功能风险比如你的app实现了一个读写文件的类,然后使用addJavascriptInterface接口允许js调用,可能会导致攻击者直接调用这个类来实现读写文件的操作。这种方法是最原始的风险,并没有直接指出getClass()方法的使用。后来,百度安全组也在2013年正式发布了针对该漏洞的高危工单:;jsessionid=B13148487947801D67251543B2B8C5CB.security_client-web01?id=336。这个漏洞主要是通过getClass()的方法直接调用java.lang.Runtime接口执行系统命令,让任何js都拥有和app一样的操作权限!

主要有两种解决方案:

WebView 网络钓鱼漏洞

钓鱼一直是安全行业最常用的攻击方式,也是最难通过技术手段解决的除了让用户提高安全意识,不点击不明链接外,技术层面可以做到以下两点:

WebView 跨域漏洞

主要原因是JS的XmlHttpRequest可以读取本地文件,从而读取app数据数据库目录下的webviewCookiesChromium.db。这个db一般是系统存放cookie的地方,相当于变相读取cookie打开权限,可以看乌云的链接:乌云链接

其他

赞(0) 打赏
未经允许不得转载:雀恰营销 » Android应用安全现状与解决方案
分享到: 更多 (0)

评论 抢沙发

评论前必须登录!

 

文章对你有帮助就赞助我一下吧

支付宝扫一扫打赏

微信扫一扫打赏