2013年8月10日星期六

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

文/肖梓航
《程序员》2012年第9期中,我们讨论了数据存储、网络通信、密码和认证策略等安全问题和解决方案,本期将继续从组件间通信、数据验证和保全保护等方面来实践Android软件安全开发之路。
组件间通信
组件间通信的安全问题是Android所独有的,也是目前软件中最常出现的一种问题。
我们先回顾一下组件间通信机制。Android有四类组件:activity、service、broadcast receiver和content provider。在同一个软件之中或不同软件之间,前三种组件使用Intent相互调用,使用ContentResolver对象访问content provider,共同实现软件的功能。使用Intent,可以显式或隐式地调用:
  • 显式(explicit):调用者知道要调用谁,通过组件名指定具体的被调用者;
  • 隐式(implicit):调用者不知道要调用谁,只知道执行的动作,由系统选择组件处理这个请求。
如下面的代码所示:
无论是显式还是隐式,如果要跨应用调用,还需要被调用的组件是对外暴露的。默认情况下,service、broadcast receiver和content provider是暴露的,申明了Intent-filter的actvity也是暴露的。
抽象地说,组件A要调用组件B,以期待B完成某个功能;它可以发送一些数据给组件B,也可以获得B执行后的返回结果。在这个模型中,问题出现在A和B之间不一定互相可信。
如果B是暴露的,任何软件都可以调用它,包括攻击者编写的软件。攻击者可能但并非总能成功:
  • 直接调用暴露的B,以获得其执行结果;
  • 构造特定的数据,并用于调用暴露的B,从而试图影响B的执行;
  • 调用暴露的B,并获取它执行完返回的结果。
如果A用的是隐式调用,任何软件都可以实现它的action从而响应调用。攻击者可能(但并非总能成功):
  • 构造伪造的组件C,响应A的Intent,以读取A要发给B的数据;
  • 构造伪造的组件C,响应A的Intent,弹出虚假的用户界面以展开进一步攻击(例如钓鱼);
  • 构造伪造的组件C,响应A的Intent,返回伪造的执行结果。
这样说可能比较抽象。下面我们对这两种情况分别讨论。
组件暴露的问题
看一个例子。在一个第三方深度定制的ROM中,预装了名为Cit.apk的软件,用于手机的硬件测试。它的AndroidManifest.xml局部如下:
可以看到,它申明一个名为.CitBroadcastReceiver的receiver,响应名为android.provider.Telephony.SECRET_CODE的action,并且指定了URI格式。
再来看这个receiver的代码片段(下面的代码是我反编译得到的,不一定与软件源码完全一致):
可以看到,当调用这个receiver,并且提供的URI中host字段为284时,会以root权限调用本地的bugreport工具,并将结果输出至m_logFileName指定的文件中。
默认情况下receiver是暴露的,因此这个receiver可以被其他软件调用,代码如下:
当这四行代码执行时,就会触发CitBroadcast-Receiver的那段代码。从上下文看,输出文件m_logFileName位于SD卡,任何软件都可以随意读写。因此,攻击者可以获得bugreport的输出结果,其中包含大量系统数据和用户数据。
请注意,在这个例子中,攻击者的软件不需要任何特殊权限,尤其是不需要root权限。这种由于组件暴露获得额外权限的攻击,被称之为permission re-delegation(权限重委派)。
怎么避免由于组件暴露产生的安全问题?有的组件必须暴露,例如入口activity,或者确实对外提供服务或跨软件协作;但也有的组件没必要暴露。接下来我们分别讨论。
不需要暴露的组件
再次回顾,默认情况下,service、broadcast receiver和content provider是暴露的,申明了Intent-filter的actvity也是暴露的。如果它们只被同一个软件中的代码调用,应该设置为不暴露。很容 易做到—在AndroidManifest.xml中为这个组件加上属性android:exported=”false”即可。
需要暴露的组件
如果组件需要对外暴露,应该通过自定义权限限制对它的调用。
首先,在实现了被调用组件的软件的Android-Manifest.xml中自定义一个权限:
接下来,为被调用组件添加这个权限限制,即在AndroidManifest.xml中为这个组件添加android:permission属性:
另一种方法是在组件的实现代码中使用Context.checkCallingPermission()检查调用者是否拥有这个权限。
最后,要调用这个暴露的组件,调用者所在的软件应该申明使用这个权限,即在AndroidManifest.xml中添加相应的use-permission申明。
进一步地,还可以将这种组件暴露的需求分为两种情况。
  • 如果这个组件只打算给自己开发的其他软件使用,而不希望暴露给第三方软件,在定义权限时,protectionLevel字段应该选择signature。 这种设置要求权限使用者(即调用者)与权限定义者(即被调用者)必须由相同的证书进行签名,因此第三方无法使用该权限,也就无法调用该组件。
  • 如果这个组件要暴露给第三方,则protection-Level应使用normal或dangerous。此时,任何软件都可以使用该权限,只在安装时会 通知用户。考虑到用户一般会忽略权限提示,此时自定义权限实际失去了保护效果,我们依然要仔细审查该组件的代码,避免出现能力泄露或权限重委派等问题。
此外,对content provider,可以更细粒度地为读取数据和写入数据设置不同的权限,对应的manifest标签分别为android:readPermission和android:writePermission。
隐式调用的问题
隐式调用的主要问题是被劫持,或Intent携带的数据被读取。
为了劫持调用,攻击者可以实现一个恶意的组件,申明相同的Intent-filter。在多个组件都可以响应同一个Intent的情况下,如果是调用 activity,系统会弹出界面要求用户对多个软件做出选择,攻击者可以模仿真实软件的图标和名称吸引用户点击;如果是调用service,系统会随机 选择一个service;如果是调用receiver,系统会逐一地将Intent发给这些receiver。
劫持了调用后,攻击者可以(但并非总能成功):
  • 启动一个虚假的软件界面,展开钓鱼攻击(例如要求用户输入账户密码)
  • 读取Intent携带的数据
  • 拦截broadcast的进一步发送,导致真正的receiver无法收到消息,从而拒绝服务
  • 如果是用startActivityForResult()调用了虚假的activity,可以返回恶意或虚假的结果给调用者
  • 执行其他恶意代码
限于篇幅,对这些情形我们不提供示例代码。来看一下怎么解决这类问题。
不需要隐式调用
除了基于Intent类中已有ACTIONs的隐式调用,绝大部分隐式调用都属于这两种情况:同一软件中不同组件的调用;同一开发者不同软件间的调用。
这两种情况下,事实上,开发时都已可以确定要调用的组件是哪个。因此可以避免隐式调用,改为基于组件名的显式调用。
需要隐式调用
发送broadcast除了使用sendBroadcast(Intent),还有一个方法是sendBroadcast(Intent, String),它的第二个参数可以指定接受者需要的权限。
如果是调用activity或者service,目前我所知,还没有简单的方法实现接收者的权限限制。在Android文档中提出可以自定义Binder和AIDL实现通信双方的互相验证,但真正实现并不容易,也不为官方所推荐。
数据验证
无论是客户端还是服务器,在处理外部获得的数据之前,都应先判断和验证数据的有效性。这里主要指是否包含畸形的数据。
在 Web开发中,服务器需要对用户提交的数据进行有效性验证,否则很容易出现众所周知的SQL注入等攻击。在移动开发中也不例外。虽然客户端与服务器在底层 通信协议上对用户是透明、不可见的,但开发者不应因此就假设双方传输的数据永远会和预先设计的一致。类似的,在读取用户从UI元素输入的输入、读取存储在 本地的数据后,使用前也应进行有效性验证。
软件版权保护
攻击者对Android软件进行逆向分析,除了寻找其中的安全漏洞,还可以直接攻击软件本身。
  • 破解软件的收费机制、License验证或功能限制;
  • 修改软件代码,去掉广告库,或者修改广告库(一般是改变推介ID字段),或者增加广告库,然后重新打包并分发;
  • 重新打包,植入恶意代码并分发;
  • 逆向分析,学习软件特色功能的实现方法,或者获得可复用的代码;
可以采取多种措施来增加破解、修改和逆向分析的难度,减少被攻击的可能。这些措施包括:
  • 使用代码混淆工具,例如SDK带的ProGuard以及其他Java混淆器。
  • 采用NDK开发核心模块。
  • 使用官方或第三方的软件保护方案,例如SDK的android.drm包、Google Play的软件许可(Application Licensing)支持。
  • 去掉开发时的调试代码,关闭调试开关,删除多余的Log代码。
然而,采取了这些措施并不等于就万无一失了。例如,用NDK开发的Native代码,也可以使用IDA Pro及其插件来反汇编、反编译和调试;用Google的DRM方案,也有AntiLVL这样的破解工具。理论上,现有防御手段都可能找到方法继续攻击, 其价值只是提高攻击难度和成本。
总结
已出现和将要出现的威胁
到 目前为止,在学术研究以外,针对Android软件漏洞的攻击只出现一起—劫持国外多个社交网站客户端登陆会话的黑客工具FaceNiff。但随着攻击者 制造传播恶意代码的成本增加和收益降低,以及移动终端隐私数据逐渐成为地下产业链的交易资源,针对Android流行软件漏洞的攻击在未来几年之内几乎一 定会出现并爆发。
统一的安全模型
限于篇幅,本文只介绍了几种常见且简单的安全问题,还存在许多我们知道的、还不知道的漏洞。如何找到和解决这些问题?
回顾已介绍的内容,我们可以发现它们有类似的安全模型:通信双方的信任问题。
  • 在数据存储中,读写数据的代码和存储在本地的数据互相不可信。
  • 在数据通信中,发送者和接受者互相不可信。
  • 在登录认证中,发起认证请求的用户的和接受认证请求的服务器互相不可信。
  • 在组件间通信中,发起Intent的组件与接收Intent的组件互相不可信。
  • 在数据验证中,处理数据的模块不能相信产生数据的源。
面对将来的问题,我们也可以尝试抽象出这种模型,区分互相不可信的实体,然后在不可信、不安全的基础上,尽可能地实现相对的可信和安全。
进一步学习和行动
Android 的开发文档Best Practices: Designing for Security和源码文档Tech Info: Security分别从开发和系统实现的角度介绍了系统的安全机制。另外,viaForensics提供了名为42+ Best Practices: Secure mobile development for iOS and Android的在线教程,更详细地介绍了移动软件面临的安全威胁,并给出了安全开发实践策略。
社区方面,从Android安全开发的角 度,Stack-Overflow并不一定是很好的选择—其中一些最佳回答没有考虑安全,直接使用可能产生问题。Google Group的anroid-security-discuss讨论组则更为专业和准确。OWASP成立了一个Mobile Security工作组,目前已发布Top Ten Mobile Risks等多份白皮书,并举办了AppSec会议。这个工作组的效率虽然不高,但产出质量非常棒。
学术方面,2011和2012年的四大会议及其work-shop上均有移动软件漏洞挖掘和攻击阻止的论文出现,从它们的related works部分可以综合快速地了解学术界的思路。
目前的移动开发还没有形成如此成熟的体系,这也许与其轻快敏捷的互联网产品开发风格有关。但我相信,真正实效的移动软件安全开发,最终依然会融合到需求分析、系统设计、开发实现、测试验证、部署运维等每一个环节,从而与PC平台的SDL殊途同归。
作者肖梓航,安天实验室高级研究员,主要方向是移动反病毒和移动软件安全,发起或参与了多个移动安全开源项目。创办了网站secmobi.com,博客claudxiao.net。

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 

Android 安全架构及权限控制机制剖析

Android 作为一个移动设备的平台,其软件层次结构包括了一个操作系统(OS),中间件(MiddleWare)和应用程序(Application)。根据 Android 的软件框图,其软件层次结构自下而上分为以下几个层次:
  • 操作系统层(OS)
  • 各种库(Libraries)和 Android 运行环境(RunTime)
  • 应用程序框架(Application Framework)
  • 应用程序(Application)
以下分别介绍 Andoid 各个层次的软件的重点及其相关技术:
(1)操作系统层(OS)
Android 使用 Linux2.6 作为操作系统,Linux2.6 是一种标准的技术,Linux 也是一个开放的操作系统。Android 对操作系统的使用包括核心和驱动程序两部分,Android 的 Linux 核心为标准的 Linux2.6 内核,Android 更多的是需要一些与移动设备相关的驱动程序。主要的驱动如下所示:
  • 显示驱动(Display Driver):常用基于 Linux 的帧缓冲(Frame Buffer)驱动
  • Flash 内存驱动(Flash Memory Driver)
  • 照相机驱动(Camera Driver):常用基于 Linux 的 v4l(Video for )驱动。
  • 音频驱动(Audio Driver):常用基于 ALSA(Advanced Linux Sound Architecture,高级 Linux 声音体系)驱动
  • WiFi 驱动(Camera Driver):基于 IEEE 802.11 标准的驱动程序
  • 键盘驱动(KeyBoard Driver)
  • 蓝牙驱动(Bluetooth Driver)
  • Binder IPC 驱动:Andoid 一个特殊的驱动程序,具有单独的设备节点,提供进程间通讯的功能。
  • Power Management(能源管理)
(2)各种库(Libraries)和 Android 运行环境(RunTime)
本层次对应一般嵌入式系统,相当于中间件层次。Android 的本层次分成两个部分一个是各种库,另一个是 Android 运行环境。本层的内容大多是使用 C++ 实现的。 在其中,各种库包括:
  • C 库:C 语言的标准库,这也是系统中一个最为底层的库,C 库是通过 Linux 的系统调用来实现。
  • 多媒体框架(MediaFrameword):这部分内容是 Android 多媒体的核心部分,基于 PacketVideo(即 PV)的 OpenCORE,从功能上本库一共分为两大部分,一个部分是音频、视频的回放(PlayBack),另一部分是则是音视频的纪录(Recorder)。
  • SGL:2D 图像引擎。
  • SSL:即 Secure Socket Layer 位于 TCP/IP 协议与各种应用层协议之间 , 为数据通讯提供安全支持。
  • OpenGL ES 1.0 :本部分提供了对 3D 的支持。
  • 界面管理工具(Surface Management):本部分提供了对管理显示子系统等功能。
  • SQLite:一个通用的嵌入式数据库
  • WebKit:网络浏览器的核心
  • FreeType:位图和矢量字体的功能。
Android 的各种库一般是以系统中间件的形式提供的,它们均有的一个显著特点就是与移动设备的平台的应用密切相关。 Android 运行环境主要指的虚拟机技术—— Dalvik。Dalvik 虚拟机和一般 JAVA 虚拟机(Java VM)不同,它执行的不是 JAVA 标准的字节码(bytecode )而是 Dalvik 可执行格式(.dex)中执行文件。在执行的过程中,每一个应用程序即一个进程(Linux 的一个 Process)。 二者最大的区别在于 Java VM 是以基于栈的虚拟机(Stack-based),而 Dalvik 是基于寄存器的虚拟机(Register-based)。显然,后者最大的好处在于可以根据硬件实现更大的优化,这更适合移动设备的特点。
(3)应用程序框架(Application Framework)
Android 的应用程序框架为应用程序层的开发者提供 APIs,它实际上是一个应用程序的框架。由于上层的应用程序是以 JAVA 构建的,因此本层次提供的首先包含了 UI 程序中所需要的各种控件: 例如: Views ( 视图组件 ) 包括 lists( 列表 ), grids( 栅格 ), text boxes( 文本框 ), buttons( 按钮 ) 等,甚至一个嵌入式的 Web 浏览器。一个 Android 的应用程序可以利用应用程序框架中的以下几个部分: Activity (活动)、Broadcast Intent Receiver (广播意图接收者)、Service (服务)、Content Provider (内容提供者)。
(4)应用程序(Application)
Android 的应用程序主要是用户界面(User Interface),通常以 JAVA 程序编写,其中还可以包含各种资源文件(放置在 res 目录中)。JAVA 程序及相关资源经过编译后,将生成一个 APK 包。Android 本身提供了主屏幕(Home),联系人(Contact),电话(Phone),浏览器(Browsers)等众多的核心应用。同时应用程序的开发者还可以使用应用程序框架层的 API 实现自己的程序。

图 1. Android 分层安全架构图
图 1. Android 分层安全架构图 
Android 系统中包括 4 种组件:
Activity 就是一个界面,这个界面里面可以放置各种控件。例如:Task Manager 的界面、Root Explorer 的界面等;Activity 是为用户操作而展示的可视化用户界面。例如说,一个 activity 可以展示一个菜单项列表供用户选择,或者显示一些包含说明的照片。一个短消息应用程序可以包括一个用于显示做为发送对象的联系人的列表的 activity,一个给选定的联系人写短信的 activity 以及翻阅以前的短信和改变设置的 activity。尽管它们一起组成了一个内聚的用户界面,但其中每个 activity 都与其它的保持独立。每个都是以Activity 类为基类的子类实现。
一个应用程序可以只有一个 activity,或者,如刚才提到的短信应用程序那样,包含很多个。而每个 activity 的作用以及其数目,自然取决于应用程序及其设计。一般情况下,总有一个应用程序被标记为用户在应用程序启动的时候第一个看到的。从一个 activity 转向另一个的方式是靠当前的 activity 启动下一个。
每个 activity 都被给予一个默认的窗口以进行绘制。一般情况下,这个窗口是满屏的,但它也可以是一个小的位于其它窗口之上的浮动窗口。一个 activity 也可以使用超过一个的窗口。例如,在 activity 运行过程中弹出的一个供用户反应的小对话框,或是当用户选择了屏幕上特定项目后显示的必要信息。
窗口显示的可视内容是由一系列视图构成的,这些视图均继承自 View 基类。每个视图均控制着窗口中一块特定的矩形空间。父级视图包含并组织它子视图的布局。叶节点视图(位于视图层次最底端)在它们控制的矩形中进行绘制,并对用户对其直接操作做出响应。所以,视图是 activity 与用户进行交互的界面。例如说,视图可以显示一个小图片,并在用户指点它的时候产生动作。Android 有很多既定的视图供用户直接使用,包括按钮、文本域、卷轴、菜单项、复选框等等。
服务是运行在后台的功能模块。如文件下载、音乐播放程序等;服务没有可视化的用户界面,而是在一段时间内在后台运行。例如说,一个服务可以在用户做其它事情的时候在后台播放背景音乐、从网络上获取一些数据或者计算一些东西并提供给需要这个运算结果的 activity 使用。每个服务都继承自 Service 基类。
一个媒体播放器播放播放列表中的曲目是一个不错的例子。播放器应用程序可能有一个或多个 activity 来给用户选择歌曲并进行播放。然而,音乐播放这个任务本身不应该为任何 activity 所处理,因为用户期望在他们离开播放器应用程序而开始做别的事情时,音乐仍在继续播放。为达到这个目的,媒体播放器 activity 应该启用一个运行于后台的服务。而系统将在这个 activity 不再显示于屏幕之后,仍维持音乐播放服务的运行。
可以连接至(绑定)一个正在运行的服务(如果服务没有运行,则启动之)。连接之后,可以通过那个服务暴露出来的接口与服务进行通讯。对于音乐服务来说,这个接口可以允许用户暂停、回退、停止以及重新开始播放。
它是 Android 平台应用程序间数据共享的一种标准接口,它以类似于 URI(Universal Resources Identification)的方式来表示数据,如:content://contacts/people/1101;内容提供者将一些特定的应用程序数据供给其它应用程序使用。数据可以存储于文件系统、SQLite 数据库或其它方式。内容提供者继承于 ContentProvider 基类,为其它应用程序取用和存储它管理的数据实现了一套标准方法。然而,应用程序并不直接调用这些方法,而是使用一个 ContentResolver 对象,调用它的方法作为替代。ContentResolver 可以与任意内容提供者进行会话,与其合作来对所有相关交互通讯进行管理。
Broadcast Receiver 是一个专注于接收广播通知信息,并做出对应处理的组件。很多广播是源自于系统代码的。例如,通知时区改变、电池电量低、拍摄了一张照片或者用户改变了语言选项。应用程序也可以进行广播,例如通知其它应用程序一些数据下载完成并处于可用状态。
应用程序可以拥有任意数量的 Broadcast Receiver 以对所有它感兴趣的通知信息予以响应。所有的接收器均继承自BroadcastReceiver 基类。
Broadcast Receiver 没有用户界面。然而,它们可以启动一个 activity 来响应它们收到的信息,或者用 NotificationManager 来通知用户。通知可以用很多种方式来吸引用户的注意力──闪动背灯、震动、播放声音等等。一般来说是在状态栏上放一个持久的图标,用户可以打开它并获取消息。
与此组件相关的概念是 Intent,Intent 是一个对动作和行为的抽象描述,负责组件之间程序之间进行消息传递。而 Broadcast Receiver 组件则提供了一种把 Intent 作为一个消息广播出去,由所有对其感兴趣的程序对其作出反应的机制。举个简单的例子,为了实现一个系统启动后播放音乐的功能,则可以定义 Intent 为 android.intent.action.BOOT_COMPLETED,由 Broadcast Receiver 组件将其进行广播,而系统中的 Media Player 接收到该信息后则进行播放。
如上所述,4 个组件之间的关系如下图:

图 2. Android 各组件关系图
图 2. Android 各组件关系图 
根据用户的使用过程体验,可以将 Android 涉及的权限大致分为如下三类:
(1)Android 手机所有者权限:自用户购买 Android 手机后,用户不需要输入任何密码,就具有安装一般应用软件、使用应用程序等的权限;
(2)Android root 权限:该权限为 Android 系统的最高权限,可以对所有系统中文件、数据进行任意操作。出厂时默认没有该权限,需要使用 z4Root 等软件进行获取,然而,并不鼓励进行此操作,因为可能由此使用户失去手机原厂保修的权益。同样,如果将 Android 手机进行 root 权限提升,则此后用户不需要输入任何密码,都将能以 Android root 权限来使用手机。
(3)Android 应用程序权限:Android 提供了丰富的 SDK(Software development kit),开发人员可以根据其开发 Android 中的应用程序。而应用程序对 Android 系统资源的访问需要有相应的访问权限,这个权限就称为 Android 应用程序权限,它在应用程序设计时设定,在 Android 系统中初次安装时即生效。值得注意的是:如果应用程序设计的权限大于 Android 手机所有者权限,则该应用程序无法运行。如:没有获取 Android root 权限的手机无法运行 Root Explorer,因为运行该应用程序需要 Android root 权限。
Android 系统在 /system/core/private/android_filesystem_config.h 头文件中对 Android 用户 / 用户组作了如下定义,且权限均基于该用户 / 用户组设置。
 #define AID_ROOT             0  /* traditional unix root user */ 
 #define AID_SYSTEM        1000  /* system server */ 
 #define AID_RADIO         1001  /* telephony subsystem, RIL */ 
 #define AID_BLUETOOTH     1002  /* bluetooth subsystem */ 
 #define AID_GRAPHICS      1003  /* graphics devices */ 
 #define AID_INPUT         1004  /* input devices */ 
 #define AID_AUDIO         1005  /* audio devices */ 
 #define AID_CAMERA        1006  /* camera devices */ 
 #define AID_LOG           1007  /* log devices */ 
 #define AID_COMPASS       1008  /* compass device */ 
 #define AID_MOUNT         1009  /* mountd socket */ 
 #define AID_WIFI          1010  /* wifi subsystem */ 
 #define AID_ADB           1011  /* android debug bridge (adbd) */ 
 #define AID_INSTALL       1012  /* group for installing packages */ 
 #define AID_MEDIA         1013  /* mediaserver process */ 
 #define AID_DHCP          1014  /* dhcp client */ 
 #define AID_SDCARD_RW     1015  /* external storage write access */ 
 #define AID_VPN           1016  /* vpn system */ 
 #define AID_KEYSTORE      1017  /* keystore subsystem */ 
 #define AID_USB           1018  /* USB devices */ 
 #define AID_DRM           1019  /* DRM server */ 
 #define AID_DRMIO         1020  /* DRM IO server */ 
 #define AID_GPS           1021  /* GPS daemon */ 
 #define AID_NFC           1022  /* nfc subsystem */ 

 #define AID_SHELL         2000  /* adb and debug shell user */ 
 #define AID_CACHE         2001  /* cache access */ 
 #define AID_DIAG          2002  /* access to diagnostic resources */ 

 /* The 3000 series are intended for use as supplemental group id's only. 
  * They indicate special Android capabilities that the kernel is aware of. */ 
 #define AID_NET_BT_ADMIN  3001  /* bluetooth: create any socket */ 
 #define AID_NET_BT        3002  /* bluetooth: create sco, rfcomm or l2cap sockets */ 
 #define AID_INET          3003  /* can create AF_INET and AF_INET6 sockets */ 
 #define AID_NET_RAW       3004  /* can create raw INET sockets */ 
 #define AID_NET_ADMIN     3005  /* can configure interfaces and routing tables. */ 

 #define AID_MISC          9998  /* access to misc storage */ 
 #define AID_NOBODY        9999 

 #define AID_APP          10000 /* first app user */ 

值得注意的是:每个应用程序在安装到 Android 系统后,系统都会为其分配一个用户 ID,如 app_4、app_11 等。以下是 Calendar 和 Terminal 软件在 Android 系统中进程浏览的结果(其中,黑色字体标明的即为应用分配的用户 ID):
 USER     PID   PPID  VSIZE  RSS     WCHAN    PC         NAME 
 app_16    2855  2363  216196 20960 ffffffff afd0ee48 S com.android.providers.calendar 
 app_91    4178  2363  218872 25076 ffffffff afd0ee48 S jackpal.androidterm 

在 Android 系统中,上述用户 / 用户组对文件的访问遵循 Linux 系统的访问控制原则,即根据长度为 10 个字符的权限控制符来决定用户 / 用户组对文件的访问权限。该控制符的格式遵循下列规则:
  • 第 1 个字符:表示一种特殊的文件类型。其中字符可为 d( 表示该文件是一个目录 )、b( 表示该文件是一个系统设备,使用块输入 / 输出与外界交互,通常为一个磁盘 )、c( 表示该文件是一个系统设备,使用连续的字符输入 / 输出与外界交互,如串口和声音设备 ),“.”表示该文件是一个普通文件,没有特殊属性。
  • 2 ~ 4 个字符:用来确定文件的用户 (user) 权限;
  • 5 ~ 7 个字符:用来确定文件的组 (group) 权限;
  • 8 ~ 10 个字符:用来确定文件的其它用户 (other user,既不是文件所有者,也不是组成员的用户 ) 的权限。
  • 第 2、5、8 个字符是用来控制文件的读权限的,该位字符为 r 表示允许用户、组成员或其它人可从该文件中读取数据。短线“-”则表示不允许该成员读取数据。
  • 第 3、6、9 位的字符控制文件的写权限,该位若为 w 表示允许写,若为“-”表示不允许写。
  • 第 4、7、10 位的字符用来控制文件的制造权限,该位若为 x 表示允许执行,若为“-”表示不允许执行。
举个例子,“drwxrwxr--  2 root   root    4096  2 月 11 10:36 lu”表示的访问控制权限(黑色字体标明)为:因为 lu 的第 1 个位置的字符是 d,所以由此知道 lu 是一个目录。第 2 至 4 位置上的属性是 rwx,表示用户 root 拥有权限列表显示 lu 中所有的文件、创建新文件或者删除 lu 中现有的文件,或者将 lu 作为当前工作目录。第 5 至 7 个位置上的权限是 rwx,表示 root 组的成员拥有和 root 一样的权限。第 8 至 10 位上的权限仅是 r--,表示不是 root 的用户及不属于 root 组的成员只有对 lu 目录列表的权限。这些用户不能创建或者删除 lu 中的文件、执行 junk 中的可执行文件,或者将 junk 作为他们的当前工作目录。
每个应用程序的 APK 包里面都包含有一个 AndroidMainifest.xml 文件,该文件除了罗列应用程序运行时库、运行依赖关系等之外,还会详细地罗列出该应用程序所需的系统访问。程序员在进行应用软件开发时,需要通过设置该文件的 uses-permission 字段来显式地向 Android 系统申请访问权限。
AndroidManifest.xml 主要包含以下功能:
  1. 说明 application 的 java 数据包,数据包名是 application 的唯一标识;
  2. 描述 application 的 component;
  3. 说明 application 的 component 运行在哪个 process 下;
  4. 声明 application 所必须具备的权限,用以访问受保护的部分 API,以及与其他 application 的交互;
  5. 声明 application 其他的必备权限,用以 component 之间的交互;
  6. 列举 application 运行时需要的环境配置信息,这些声明信息只在程序开发和测试时存在,发布前将被删除;
  7. 声明 application 所需要的 Android API 的最低版本级别,例如 1.0,1.1,1.5;
  8. 列举 application 所需要链接的库;
AndroidManifest.xml 文件的结构、元素,以及元素的属性,可以在 Android SDK 文档中查看详细说明。而在看这些众多的元素以及元素的属性前,需要先了解一下这些元素在命名、结构等方面的规则:
  1. 元素:在所有的元素中只有 <manifest> 和 <application> 是必需的,且只能出现一次。如果一个元素包含有其他子元素,必须通过子元素的属性来设置其值。处于同一层次的元素,这些元素的说明是没有顺序的。
  2. 属性:按照常理,所有的属性都是可选的,但是有些属性是必须设置的。那些真正可选的属性,即使不存在,其也有默认的数值项说明。除了根元素 <manifest> 的属性,所有其他元素属性的名字都是以 android: 前缀的;
  3. 定义类名:所有的元素名都对应其在 SDK 中的类名,如果你自己定义类名,必须包含类的数据包名,如果类与 application 处于同一数据包中,可以直接简写为“.”;
  4. 多数值项:如果某个元素有超过一个数值,这个元素必须通过重复的方式来说明其某个属性具有多个数值项,且不能将多个数值项一次性说明在一个属性中;
  5. 资源项说明:当需要引用某个资源时,其采用如下格式:@[package:]type:name。例如 <activity android:icon=”@drawable/icon ” . . . >
  6. 字符串值:类似于其他语言,如果字符中包含有字符“\”,则必须使用转义字符“\\”;
下面结合 cookie 实例中的 AndroidManifest.xml 文件来说明一下,原 XML 文件如下:
 <?xml version=”1.0 ″ encoding=”utf-8 ″ ?> 
 <manifest xmlns:android=”http://schemas.android.com/apk/res/android”
 package=”moandroid.cookie”
 android:versionCode=”1 ″
 android:versionName=”1.0 ″ > 
 <application android:icon=”@drawable/icon” android:label=”@string/app_name”> 
 <activity android:name=”.cookie” android:label=”@string/app_name”> 
 <intent-filter> 
 <action android:name=”android.intent.action.MAIN” /> 
 <category android:name=”android.intent.category.LAUNCHER” /> 
 </intent-filter> 
 </activity> 
 </application> 
 <uses-sdk android:minSdkVersion=”3 ″ /> 
 </manifest> 

除了头部的 XML 信息说明外,首先是 manifest 项(也就是根节点),其属性包括:schemas URL 地址、包名(moandroid.cookie),以及程序的版本说明。其次是 manifest 的子节点 application,其属性包括:程序图标、程序名称。前面带有 @ 表示引用资源,例如:@drawable/icon 表示引用的是 drawable 资源中的 icon,可以在其源工程的 res/drawable 中找到。然后就是 application 的子节点 activity,其属性包括:activity 的名称、activity 的标签名,其子节点 intent-filter 则是对 activity 的说明。
而在 intent-filter 中,action android:name=”android.intent.action.MAIN”和 category android:name=”android.intent.category.LAUNCHER”用以说明程序启动时的入口 activity 是哪个。如果这两个属性值中分别含有 MAIN 和 LAUNCHER,则说明它就是启动程序时的入口活动。uses-sdk android:minSdkVersion=”3 ″说明程序使用的 Android SDK 的最低版本,其中 1 表示 Android 1.0,2 表示 Android 1.1,而 3 则表示 Android 1.5。
如下所示,文中黑体标记的部分为应用程序权限申请内容:
 <?xml version="1.0" encoding="utf-8"?> 
 <manifest xmlns:android="http://schemas.android.com/apk/res/android"
     package="cn.com.fetion.android"
     android:versionCode="1"
     android:versionName="1.0.0"> 
   <application android:icon="@drawable/icon" android:label="@string/app_name"> 
       <activity android:name=".welcomActivity"
                  android:label="@string/app_name"> 
            <intent-filter> 
                <action android:name="android.intent.action.MAIN" /> 
                <category android:name="android.intent.category.LAUNCHER" /> 
            </intent-filter> 
        </activity> 
   </application> 
 <uses-permission android:name="android.permission.SEND_SMS"></uses-permission>
 </manifest> 

如上述文件描述中加下划线的斜体部分,该文件的作用是说明该软件需要发送短信的功能。
Android 定义了百余种 permission,可供开发人员使用,具体详见网址:http://developers.androidcn.com/reference/android/Manifest.permission.html。
在文件中,用户还可以自定义权限。permission 就是自定义权限的声明,可以用来限制 app 中特殊组件,特性与 app 内部或者和其他 app 之间访问。写了一个引用自定义权限的例子,在安装 app 的时候,提示权限:
定义权限如下:
 <permission android:label="”自定义权限”" 
  
     android:description=”@string/test” 
  
     android:name=”com.example.project.TEST” 
  
     android:protectionLevel=”normal” 
  
     android:icon=”@drawable/ic_launcher”> 

声明的含义如下;
android:label:权限名字,显示给用户的,值可是一个 string 数据,例如这里的“自定义权限”。
android:description:比 label 更长的对权限的描述。值是通过 resource 文件中获取的,不能直接写 string 值,例如这里的”@string/test”。
android:name:权限名字,如果其他 app 引用该权限需要填写这个名字。
android:protectionLevel:权限级别,分为 4 个级别:
    • normal:低风险权限,在安装的时候,系统会自动授予权限给 application。
    • dangerous:高风险权限,系统不会自动授予权限给 app,在用到的时候,会给用户提示。
    • signature:签名权限,在其他 app 引用声明的权限的时候,需要保证两个 app 的签名一致。这样系统就会自动授予权限给第三方 app,而不提示给用户。
    • signatureOrSystem:这个权限是引用该权限的 app 需要有和系统同样的签名才能授予的权限,一般不推荐使用。
值得注意的是:通过测试发现一种特殊的情况,应用程序可以在程序运行时申请 root 权限,如下图,在使用 Android Terminal Emulator 时尝试使用 su 命令切换到 root 用户。若用户已通过 hacking 的方式使得 Android 系统获得了 root 权限,则可以允许该程序以 root 用户权限执行;反之即算用户选择“允许”,也不能使程序以 root 用户权限执行。

图 3. Android 用户权限赋予示意图
图 3. Android 用户权限赋予示意图 
对 Android 源代码中的如下文件进行分析:
  • InstallAppProgress.java:其路径为 \packages\apps\PackageInstaller\src\com\android\packageinstaller\InstallAppProgress.java;
  • PackageInstallerActivity.java:其路径为 \packages\apps\PackageInstaller\src\com\android\packageinstaller\PackageInstallerActivity.java;
  • AppSecurityPermissions.java:其路径为 \frameworks\base\core\java\android\widget\AppSecurityPermissions.java
总结得出如下图所示的 Android 系统对应用程序授权申请的处理流程:
  • 进入处理应用程序授权申请的入口函数;
  • 系统从被安装应用程序的 AndroidManifest.xml 文件中获取该应用正常运行需申请的权限列表;
  • 显示对话框,请求用户确认是否满足这些权限需求;
  • 若同意,则应用程序正常安装,并被赋予相应的权限;若否定,则应用程序不被安装。系统仅提供给用户选择“是”或者“否”的权利,没有选择其中某些权限进行授权的权利。

图 4. Android 用户权限赋予示意图
图 4. Android 用户权限赋予示意图 

技术探析Android安全有多弱,从鳄鱼爱洗澡致300万用户中毒说开去~

今天看到《鳄鱼爱洗澡成病毒载体 致300万用户中毒》这篇报道中说到:
此次入侵《鳄鱼爱洗澡》的病毒为“反动联盟2病毒(a.fraud.eyu)”。不同于以往的恶意广告,“反动联盟2病毒”将恶意代码植入十余个版本的《鳄鱼爱洗澡》游戏中。一旦激活则会攻击指定的手机安全软件,还会在通知栏弹广告,私自下载应用,耗费用户流量。WiFi情况下还好说,若是GPRS或3G状态下,则很容易导致用户手机欠费停机。目前,据保守估计,此次受“反动联盟2病毒”感染的Android用户数接近300万。
一时间,大家开始批判Android的安全性,比如:
@陈昊芝:小鳄鱼爱洗澡Android没有官方发行版本,所以第三方渠道都是盗包,加一些不该加的东西。愤怒的小鸟也样,多数渠道能搜索到30几个版本,都是盗包发布。最终用户无法分辨,越来越像PC市场了,比的是谁更没底线
@费西FISH:android第三方市场盗包太严重了,损害的是整个android产业链。
还有更多的讨论,大家可以移步这里:
http://weibo.com/1644687644/yqSlFdhSH?type=repost#1341382455878 
抛开所有的质疑和偏见,这个事情我们可以从技术层面探讨下,和 @我是码农 @橙子Infinity @李宁_Lining 等android技术牛们讨论了下,大家的结论是:
android的apk文件基本可以修改,一般的步骤是:反编译,修改(xml,组件,源代码),重新编译,重新签名, 发布,按照操作的复杂度,依次如下:
  • 解包(只是zip包),使用里面的资源文件,比如图片等;
  • 最简单的是直接修改xml,比如替换原有广告代码的ad_key来替换掉别人的广告;
  • 可以加入自己写的组件,比如service等,用这个方法来移入广告平台,比如:使用某个软件几次后,就强出点击广告获得积分才能继续的界面。
  • 如果smali功力不错,连java都可以修改。
很多人也问,如何防范,如何杜绝?
按照俺们技术的思路给出的答案是:基本无解!但是可以使用代码混淆提高下被反编译的难度。
目前为止唯一可以依靠的就是:底线!!
除此之外,到底android在哪些地方存在不安全,这些不安全会被怎么怎么利用?又该如何防范?
大家可以深入探讨下。
除此之外,到底android在哪些地方存在不安全,这些不安全会被怎么怎么利用?大家可以探讨下。
声明:eoe文章著作权属于作者,受法律保护,转载时请务必以超链接形式附带如下信息
原文作者: iceskysl