当前位置: 代码迷 >> Android >> Android软件安全开发实践(下)
  详细解决方案

Android软件安全开发实践(下)

热度:112   发布时间:2016-05-01 11:19:55.0
Android软件安全开发实践(上)

Android开发是当前最火的话题之一,但很少有人讨论这个领域的安全问题。本系列将分两期,探讨Android开发中常见的安全隐患和解决方案。第一期将从数据存储、网络通信、密码和认证策略这三个角度,带你走上Android软件安全开发实践之旅。

过去两年,研究人员已发现Android上的流行软件普遍存在安全缺陷或安全漏洞。漏洞频发的原因可能有很多,例如以下几种。

  • 与一切都是集中管理的iOS相比,Android提供了一种开放的环境,在获得了灵活性、可以满足各种定制需求的同时,也损失了部分安全性。

  • 开发团队通常将精力集中在产品设计、功能实现、用户体验和系统效率等方面,而很少考虑安全问题。

  • Android提供的安全机制比较复杂,开发者需要理解它们,并对常见的攻击思路和攻击方法有所了解,才能有效地保护软件。

  • 一方面,目前很少出现对特定移动软件安全漏洞的大规模针对性攻击,在真实的攻击出现之前,许多人对此并不重视。另一方面,利用这些漏洞展开攻击并不太难,许 多攻击方法和工具都已经成熟。一旦出现这种攻击,用户的个人隐私数据可能发生泄漏,账户信息可能被盗取,如果与钓鱼等攻击结合,甚至可能产生经济损失。产 品开发团队则可能由此面临信任危机和法律风险。

我在此前进行的一些安全评估中,看到不少开发团队已具有非常高的安全开发水平,但也发现有知 名企业的软件存在各种缺陷。在本文中,我们将向大家介绍Android软件中比较常见的安全缺陷或安全漏洞,分析产生问题的原因,介绍可能的攻击方法,并 给出解决问题的建议。希望能抛砖引玉,引起大家对这类问题的关注。

数据存储

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

关于数据存储可能出现的问题包括以下几种。

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

例如,聊天软件或社交软件将聊天记录、好友信息、社交信息等存储在SD卡上;备份软件将通信录、短信等备份到SD卡上等。如果这些数据是直接明文保存(包括 文本格式、XML格式、SQLite数据库格式等)的,那么攻击者写的软件可以将其读取出来,并回传至指定的服务器,造成隐私信息泄露。

较好的做法是对这些数据进行加密,密码保存在内部存储,由系统托管或者由用户使用时输入。

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

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

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

如果软件将配置文件存储在SD卡上,然后在运行期间读取这些配置文件,并根据其中的数据决定如何工作,也可能产生问题。攻击者编写的软件可以修改这些配置文 件,从而控制这些软件的运行。例如,如果将登录使用的服务器列表存储在SD卡中,修改后,登录连接就会被发往攻击者指定的服务器,可能导致账户泄露或会话 劫持(中间人攻击)。

对这种配置文件,较安全的方法是保存到内部存储;如果必须存储到SD卡,则应该在每次使用前判断它是否被篡改,例如,与预先保存在内部的文件哈希值进行比较。

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

现在很多软件都推荐用户下载并安装其他软件;用户点击后,会联网下载另一个软件的APK文件,保存到SD卡然后安装。

也有一些软件为了实现功能扩展,选择动态加载并执行二进制代码。例如,下载包含了扩展功能的DEX文件或JAR文件,保存至SD卡,然后在软件运行时,使用 dalvik.system.DexClassLoader类或者java.lang.ClassLoader类加载这些文件,再通过Java反射,执行 其中的代码。

如果在安装或加载前,软件没有对SD卡上的文件进行完整性验证,判断其是否可能被篡改或伪造,就可能出现安全问题。

在这里,攻击者可以使用称 为“重打包”(re-packaging)的方法。目前大量Android恶意代码已采用这一技术。重打包的基本原理是,将APK文件反汇编,得到 Dalvik指令的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权限,自然可以随意读写其他软件的内部文件。这种情况并不少见。

  • 大量的第三方定制ROM提供了root权限管理工具,如果攻击者构造的软件伪造成一些功能强大的工具,可以欺骗用户授予它root权限。

  • 即便手机安装的官方系统,国内用户也大多乐于解锁、刷recovery并刷入root管理工具。

  • 在Android 2.2和2.3中,存在一些可以用于获取root权限的漏洞,并且对这种漏洞的利用不需要用户的确认。

因此,我们并不能假设其他软件无法获取root权限。即便是存在内部的数据,依然有被读取或修改的可能。

前面提到,重要、敏感、隐私的数据应使用内部存储,现在又遇到root后这些数据依然可能被读取的问题。我对这个问题的观点是,如果攻击者铤而走险获得root权限(被用户觉察或者被安全软件发现的风险),那理论上他已拥有了系统的完整控制权,可以直接获得联系人信息、短信记录等。此时,攻击者感兴趣的 软件漏洞利用更可能是获得其他由软件管理的重要数据,例如账户密码、会话凭证、账户数据等。例如,早期Google钱包将用户的信用卡数据明文存储,攻击 者获取这些数据后,可以伪装成持卡人进行进一步攻击以获得账号使用权。这种数据就是“其他由软件管理的重要数据”。

这个问题并没有通用的解决方法。开发者可能需要根据实际情况寻找方案,并在可用性与安全性之间做出恰当的选择。

网络通信

Android软件通常使用WiFi网络与服务器进行通信。WiFi并非总是可信的。例如,开放式网络或弱加密网络中,接入者可以监听网络流量;攻击者可以自己设置WiFi网络钓鱼。此外,在获得root权限后,还可以在Android系统中监听网络数据。

不加密地明文传输敏感数据

最危险的是直接使用HTTP协议登录账户或交换数据。例如,攻击者在自己设置的钓鱼网络中配置DNS服务器,将软件要连接的服务器域名解析至攻击者的另一台服务器;这台服务器就可以获得用户登录信息,或者充当客户端与原服务器的中间人,转发双方数据。

早期,国外一些著名社交网站的Android客户端的登录会话没有加密。后来出现了黑客工具FaceNiff,专门嗅探这些会话并进行劫持(它甚至支持在WEP、WPA、WPA2加密的WiFi网络上展开攻击!)。这是目前我所知的唯一一个公开攻击移动软件漏洞的案例。

这类问题的解决方法很显然—对敏感数据采用基于SSL/TLS的HTTPS进行传输。

SSL通信不检查证书有效性

在SSL/TLS通信中,客户端通过数字证书判断服务器是否可信,并采用证书中的公钥与服务器进行加密通信。

然而,有开发者在代码中不检查服务器证书的有效性,或选择接受所有的证书。例如,开发者可以自己实现一个X509TrustManager接口,将其中的 checkServerTrusted()方法实现为空,即不检查服务器是否可信;或者在SSLSocketFactory的实例中,通过 setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER),接受所有证 书。做出这两种选择的可能原因是,使用了自己生成了证书后,客户端发现证书无法与系统可信根CA形成信任链,出现了 CertificateException等异常。

这种做法可能导致的问题是中间人攻击。

在钓鱼WiFi网络中,同样地,攻 击者可以通过设置DNS服务器使客户端与指定的服务器进行通信。攻击者在服务器上部署另一个证书,在会话建立阶段,客户端会收到这张证书。如果客户端忽略 这个证书的异常,或者接受这个证书,就会成功建立会话、开始加密通信。但攻击者拥有私钥,因此可以解密得到客户端发来数据的明文。攻击者还可以模拟客户 端,与真正的服务器联系,充当中间人做监听。

解决问题的一种方法是从可信CA申请一个证书。但在移动软件开发中,不推荐这种方法。除了申请 证书的时间成本和经济成本外,这种验证只判断了证书是否CA可信的,并没有验证服务器本身是否可信。例如,攻击者可以盗用其他可信证书,或者盗取CA私钥 为自己颁发虚假证书,这样的攻击事件在过去两年已有多次出现。

事实上,移动软件大多只和固定的服务器通信,因此可以在代码中更精确地直接验 证是否某张特定的证书,这种方法称为“证书锁定”(certificate pinning)。实现证书锁定的方法有两种:一种是前文提到的实现X509TrustManager接口,另一种则是使用KeyStore。具体可参考 Android开发文档中HttpsURLConnection类的概览说明。

使用短信注册账户或接收密码

也有软件使用短信进行通信,例如自动发送短信来注册、用短信接收初始密码、用短信接收用户重置的密码等。

短 信并不是一种安全的通信方式。恶意软件只要申明了SEND_SMS、RECEIVE_SMS和READ_SMS这些权限,就可以通过系统提供的API向任 意号码发送任意短信、接收指定号码发来的短信并读取其内容,甚至拦截短信。这些方法已在Android恶意代码中普遍使用,甚至2011年就已出现拦截并 回传短信中的网银登录验证码(mTANs)的盗号木马Zitmo。

因此,这种通过短信注册或接收密码的方法,可能引起假冒注册、恶意密码重置、密码窃取等攻击。此外,这种与手机号关联的账户还可能产生增值服务,危险更大。较好的实现方式还是走Internet。

密码和认证策略

明文存储和编码存储密码

许多软件有“记住密码”的功能。如果开发者依字面含义将密码存储到本地,可能导致泄漏。

另 外,有的软件不是直接保存密码,而是用Base64、固定字节或字符串异或、ProtoBuf等方法对密码编码,然后存储在本地。这些编码也不会增加密码 的安全性。采用smali、dex2jar、jd-gui、IDA Pro等工具,攻击者可以对Android软件进行反汇编和反编译。攻击者可以借此了解软件对密码的编码方法和编码参数。

较好的做法是,使用基于凭据而不是密码的协议满足这种资源持久访问的需求,例如OAuth。

对外服务的弱密码或固定密码

另一种曾引起关注的问题是,部分软件向外提供网络服务,而不使用密码或使用固定密码。例如,系统辅助软件经常在WiFi下开启FTP服务。部分软件对这个FTP服务不用密码或者用固定密码。在开放或钓鱼的WiFi网络下,攻击者也可以扫描到这个服务并直接访问。

还有弱密码的问题。例如,早期Google钱包的本地访问密码是4位数字,这个密码的SHA256值被存储在内部存储中。4位数字一共只有10000种情况,这样攻击软件即便是在手机上直接暴力破解,都可以在短时间内获得密码。

使用IMEI或IMSI作为唯一认证凭据

IMEI、IMSI是用于标识手机设备、手机卡的唯一编号。如果使用IMSI或IMEI作为用户认证的唯一凭据,可能导致假冒用户的攻击。

首先,应用要获取手机的IMEI、手机卡的IMSI并不需要特殊权限。事实上,许多第三方广告库回传它们用于用户统计。其次,得到IMEI或IMSI后,攻 击者有多种方法伪造成用户与服务器进行通信。例如,将原软件重打包,使其中获取IMEI、IMSI的代码始终返回指定的值;或修改Android代码,使 相关API始终返回指定的值,编译为ROM在模拟器中运行;甚至可以分析客户端与服务器的通信协议,直接模拟客户端的网络行为。

因此,若使用IMEI或IMSI作为认证的唯一凭据,攻击者可能获得服务器中的用户账户及数据。

作者肖梓航,网名Claud,安天实验室高级研究员,主要方向是移动反病毒和移动软件安全,发起或参与了多个移动安全开源项目。博客:

http://claudxiao.net 

转载自:http://www.programmer.com.cn/15036/

  相关解决方案