您的位置:首页 > 移动开发 > Android开发

Android平台通用安全问题分析及策略(一)

2013-03-29 15:54 295 查看

Android平台通用安全问题分析及策略(一)

标签:移动平台 安全 Android 敏感数据

原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。/article/4229288.html

更多原文请见:http://mobile.51cto.com/aprogram-382057.htm

Android作为一个优秀的开源移动平台,其应用范围和受重视程度已经越来越大。因此,其安全问题也成为业界和用户的关注焦点。如何正确地认识其安全问题,并采用相应的策略来加强用户的安全使用是一个非常关键的问题,本文将介绍Android平台通用安全问题,并给出相应的安全策略。

一、Android安全问题产生的根源

【51CTO专稿】研究人员已发现Android上的流行软件普遍存在安全陷阱与安全漏洞,漏洞频发的原因可能有很多,主要有如下几种:

与一切都是集中管理的IOS相比,Android提供了一种开放的环境,在获得了灵活性、可以满足各种定制需求的同时,也损失了部分安全性。
开发团队通常将精力集中在产品设计、功能实现、用户体验和系统等方面,而很少考虑安全问题
Android提供的安全机制比较复杂,开发者需要理解它们,并对相应的攻击思路和攻击方法有所了解,才能有效地保护软件。
一方面,目前很少出现对特定移动软件安全漏洞的大规模针对性攻击,在真实的攻击出现之前,许多人对此并不重视,另一方面,利用这些漏洞展开攻击并不太难,许多攻击方法和工具都已经成熟,一旦出现这种攻击,用户的个人隐私数据可能发生泄漏,账户信息可能被收集,如果与钓鱼等攻击结合,甚至可能产生经济损失。产品开始团队则可能由此面临信任危机和法律风险。

下面简单的例举几个不注重安全的现象,这些也是我们Android开发团队容易忽略的地方。




二、数据存储安全问题

Android软件可以使用的存储区域分外部(SD卡)和内部(NAND闪存)二种,除了大小和位置不同之外,两者在安全权限上也有很大的区别。外部存储的文件没有读写权限的管理,所有应用软件都可以随意创建、读取、修改、删除位于外部存储中的任何文件,而Android的应用则只需要申明READ_EXTERNAL_STORAGE和WRITE_EXTERNAL_STORAGE权限。
内部存储则为每个软件分配了私有区域,并有基本Linux的文件权限控制,其中每个文件的所有者ID均为该软件设立的一个用户ID,其他软件无权读写这些文件。
关于数据存储可能出现的问题包括如下几点:

将隐私数据明文保存在外部存储

例如,聊天软件或社交软件将聊天记录、好友信息、社交信息等存储在SD卡上;备份软件将通信录、短信等备份到SD卡上等,如果这些数据是直接明文保存(包括文本格式、XML格式、SQLite数据库格式等)的,那么攻击者写的软件可以将其读取出来,并加传到指定的服务器,造成隐私信息泄露。较好的做法是对这些数据进行加密,密码保存在内部存储,由系统托管或者由用户使用时输入。

将系统数据明文保存在外部存储

例如,备份软件和系统辅助将用户数据备份到安装的其他的SD卡,以便刷机或升级后进行恢复等;或者将一些系统数据缓存在SD卡上供后续使用,同样的,这些数据是明文保存的,恶意软件可以读取它们,有可能用于展开进一步的攻击。

将软件运行时依赖的数据保存在外部存储

如果软件将配置文件存储在SD卡上,然后在运行期间读取这些配置文件,并其中的数据决定如何工作,也可能产生问题。攻击者编写的软件可以修改这些配置文件,从而控制这些软件的运行。例如将登录使用的服务器列表存储在SD卡中,修改后,登录连接就会被发往攻击者指定的服务器,可能导致账户泄露或会话劫持(中间人攻击)。
对这种配置文件,较安全的方法是保存到内部存储;如果必须存储到SD卡,则应该在每次使用前检验它是否被篡改,与预先保存在内部的文件哈希值进行比较。

将软件安装包或者二进制代码保存在外部存储

现在很多软件都推荐用户下载并安装其他软件;用户点击后,会联网下载另一个软件的APK文件,保存到SD卡然后安装。
也有一些软件为了实现功能扩展,选择动态加载并执行二进制代码。例如,下载包含了扩展功能的DEX文件或JRA文件,保存到SD卡,然后在软件运行时,使用dalvik.system.DexClassLoader类或者java.lang.ClassLoader类加载这些文件,再通过Java反射,执行其中的代码。
如果安装或者加载前,软件没有对SD卡 的文件进行完整性验证,判断其是否可能被篡改和伪造,就可能出现安全问题。
在这里,攻击者可以使用称为“重打包”(re-packaging)的方法,目前大量Android恶意代码已经采用这一技术,重打包的基本原理是,将APK文件反汇编,得到 Dalivik指令的smali语法表示 ;然后在其中添加、修改、删除等一些指令序列,并适当改动Manifest文件;最后,将这些指令重新汇编并打包成新的APK文件,再次签名,就可以给其他手机安装了,通过重打包,攻击者可以加入恶意代码、改变数据或指令,而软件原有功能和界面基本不会受到影响,用户难以察觉。
如果攻击者对软件要安装的APK文件或要加载DEX、JAR文件重打包,植入恶意代码,或修改其代码;然后在SD卡上,用其替换原来的文件,或者拷贝到要执行或加载 的路径,当软件没有验证这些文件的有效性时,就会运行攻击者的代码攻击。结果有很多可能,例如直接发送扣费短信,或者将用户输入的账户密码发送给指定的服务器,或者弹出钓鱼界面等。
因此,软件应该在安装或加载位于SD卡的任何文件之前,对其完整性做验证,判断其与实现保存在内部存储中的(或从服务器下载来的)哈希值是否一致。

全局可读写的内部文件

如果开发者使用openFileOutPut(String name,int mode)方法创建内部文件时,将第二个参数设置为Context.MODE_WORLD_READABLE或者Context.MODE_WORLD_WRITEABLE,就会让这个文件变为全局可读或全局可写的。
开发者这样做是为了实现不同软件之间的数据共享,但这种问题在于无法控制哪个软件可以读写,所以攻击者的恶意软件也拥有这一权限。
如果要跨应用有种较好的方法是实现一个Content Provider 组件,提供数据的读写接口并为读写操作分别设置一个自定义的权限。

内部敏感文件被root权限软件读写

如果攻击者的软件已获得root权限,自然可以随意读写其他软件的内部文件,这种情况 并不少见。
1)大量的第三方定制ROM提供了root 权限管理工具,如果攻击者构造的软件伪造成一些功能强大的工具。可以欺骗用户授予它root权限。
2)即便手机预装的官方系统,国内用户也大多乐于解锁,即recovery并刷入toot管理工具。
3)在Android2.2和2.3中,存在一些可用于获取root权限的漏洞,并且对这种漏洞的利用不需要用户的确认。
4)因此,我们并不能假设其他软件无法获取root权限。即使是存在内部数据,依然有被读取或修改的可能。
5)前面提到,重要、敏感、隐私的数据应使用内部存储,现在又遇到root后这些数据依然可能被读取的问题。我对这个问题的观点是,如果攻击者铤而走险获取root权限(被用户或者被安全软件发现的风险),那理论上他已经拥有了系统的完整控制权,可以直接获得联系人信息、短信记录等,甚至账户密码、会话凭证、账户数据等。例如,早期Google钱包将用户的信用卡数据明文存储,攻击者获取这些数据后,可以伪装成持卡人进行进一步攻击以获得账户使用权。这种数据就是“其他软件管理的重要数据”。
6)这个问题并没有通用的解决方法,开发者可能需要根据实际情况寻找方案,并在可用性与安全性之前做出恰当的选择。

本文出自 “卓越始于足下” 博客,请务必保留此出处/article/4229288.html
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: