Group of Software Security In Progress

GoSSIP @ LoCCS.Shanghai Jiao Tong University

SoK: Lessons Learned From Android Security Research for Appified Software Platforms

论文下载

Introduction

本文是一篇SoK(Systematization of Knowledge)类文章,作者总结了超过100篇Android Security相关文章的,系统化的分析了Android安全领域的研究现状。 作者指出现有的很多工作都比较片面,没能完全理解整个appified ecosystem的特点,于是作者对比appified ecosystem和传统的桌面平台,分析了前者的优势和不足,除此之外,作者还分析了appification 所带来的问题。

Problem and research areas

总结appified平台和传统的软件系统区别:

  1. 资源的访问控制相关
    • 传统的基于UID的权限控制被移植到移动平台,一个app作为一个用户有自己的权限,但是并不区分自然人,作者提到最近的Android版本中已经出现了二维UID。
    • 传统的Reference Monitor是操作系统管理的,appified是通过IPC接口实现资源访问控制
    • 传统的安全策略中有不同的特权等级(user, root等),appified中,系统app和第三方app有不同的权限等级,

Android Ecosystem

参与者包括:

  • Platform Developers
  • Device Vendors
  • Library Providers
  • App Developers
  • Toolchain Providers
  • App Publishers
  • App Markets
  • Users

  • 开发者是这个生态系统的核心,体现出了整个系统的一些发展趋势:使用的开发接口固定,开发语言有限,为app申请权限要遵循固定的流程,代码中可以包含第三方代码,开发呈现了web化的趋势,app之间传递消息通过Android提供的ICC功能

  • 攻击者使用的攻击方式总结:申请危险权限,有多个app运行在被攻击者的设备上,重打包应用添加恶意代码,运行Native代码破解设备,动态加载代码逃避静态审查,通过网络流量攻击

Systematization of research areas in appified ecosystems

Permission Evolution

这一类研究主要是在android原有的权限策略的基础之上进行研究,并不设计底层权限结构的修改。

  • 问题1 对用户的权限理解和提示,原因是通常只会提示有权限访问,不会说明访问资源之后如何处理,是否被发送出去。如果不提示对资源如何处理,用户就不能对权限作出更确切的评估。
  • 问题2 面向开发者的权限理解和提示,不申请不必要的权限或者错误的权限,原因是Android开发文档的API说明不够详细,有些还包含错误信息。 Android鼓励不同权限等级的APP互相通信,所以很多工作会考虑通过高权限APP的一些暴露IPC接口来提权,根本原因是组件默认是暴露的,需要声明特定权限或者隐藏才能防止越权访问

对应措施

第一类,对权限提示的步骤进行优化:

  • Kelley 设计了一个内容更加丰富的权限提示对话框,向用户展示更详细的隐私相关的信息
  • Porter Felt 提出了一个新的权限赋予系统,APP开发者能够根据需要选择不同的权限获取方式,比如自动获得一般权限,用户通过可信UI选择永久授权或临时授权
  • Roesner 具体实现了可信UI
  • Wijesekera 通过学习用户的隐私偏好,不符合用户习惯的请求被要求列出访问隐私数据的原因
  • liu 提出的方案是通过用户的隐私偏好档案来替代用户对权限请求作出处理。
  • Felt 提出改善API文档,简化权限请求的部分。

第二类,系统插件,强化权限功能:

  • Kirin是一个系统插件,用来检查权限误用,并且能够指出confused deputy攻击
  • Apex 是一个动态权限管理工具,对现有的权限管理进行了强化
  • TaintDroid 是动态污点分析工具,揭示app如何处理隐私数据
  • Sorbet 通过建立Android的权限管理模型,针对各种问题强化权限管理对粒度进行细化

第三类,针对confused deputy问题开展的工作:

  • XManDroid 加入了策略驱动的访问控制
  • QUIRE 建立了信息源沿着ICC的call path,检查权限
  • IPC inspection 则是通过限制被调用组件的权限和调用者一样。

其他:

  • WHYPER 和 AutoCog通过自然语言处理的方法分析app描述文件得出app声明权限,与其申请的权限对比。
  • DescribeMe 反其道而行之,通过研究app代码得出权限描述文件,帮助用户理解app行为

责任讨论:这个部分Platform developers和market operators是全责的,Library providers和app开发者半责,用户可能会对权限不关系,半责

总结:这类问题可能通过Platform developers修改访问控制机制解决,对于app和三方库开发者来说可以通过工具辅助,app市场可以通过丰富权限声明来避免这类问题

研究中已经指出开发者以及用户对权限关心程度很小,所以更多的研究细粒度权限控制只会增加二者的负担。 对于权限提示框的研究还没有人尝试作出一个开发者和用户两端可用的系统。权限提示框本质上是一个warning信息的提示,这里的问题还是用户没有从中理解出真实的意图,误解导致了这个机制失效。 作者推荐 1)通过app的类别,描述以及相似app来自动生成权限请求;2)审查完整的信息流方向而不是只关注资源的访问权限

Permission Revolution

同样是权限问题,但是这部分的研究主要关于对Andorid平台访问控制规则的修改 分为两部分,一种是系统插件,还有一种是Inlined Reference Monitoring 问题a 对权限隔离不彻底,第三方库(广告库)和host app有相同的权限,app可以收集用户隐私,app开发者也可以从ad网络中偷取用户隐私 问题b 所有app权限平等,反病毒软件没有特殊权限支持,所以拦截恶意软件效率较低 问题c 缺乏强制访问控制,并没有研究针对对安全需求很高的政府部门。

应对方法: 第一类,可选的访问控制模块:基于framework层的丰富语义信息来加强访问控制 Saint 框架允许app开发者应用基于策略的ICC条件限制 CRePE 将设备上下文环境纳入了访问控制考虑的条件内 TISSA 细粒度的数据分享控制 TISSA [67]

第二类,强制访问控制:SE Android引入到Android框架内,基于SELinux的强制访问控制 FlaskDroid 把SELinux中的实施类型扩展到用户控件的组件中,从而使app能够添加底层的强制访问控制规则

第三类,提升权限隔离粒度:AdDroid和AdSplit做的工作是把app本身代码和广告库区分开使广告库代码运行在单独的环境中,权限受到控制 LayerCake研究的问题更加通用,他考虑的问题是app中植入第三方代码所带来的安全的问题 Compac 通过审查栈cookie以及ICC标记实现了对每一个组件的访问控制

研究inline reference monitoring,能够引入细粒度的动态的访问控制策略,通过二进制重写技术动态修改相关代码。但是修改第三方代码会遇到法律问题。此外还有一个研究点是IRM隔离的问题,目前的研究主要是通过虚拟化技术把reference monitoring放在可信区域内

责任讨论:platform developers全责

总结:尽管很多研究没有做需求分析,只是针对一些假设的威胁来做的防护,但是这个部分很多对于Android的系统级访问控制插件是很有价值的,AOSP中已经有利用研究成果的例子。

权限隔离的思想是很有前景的,应该被继续推行下去,尤其是从APP开发者的角度进行研究。IRM的研究作者不置可否,只是说不要忘了用户在这个研究体系中的作用。

最后,权限控制已经有很多研究了,但是对于策略的生成以及修改并没什么研究。

Webification

无缝整合app和html js,可移植性强。app可以在webpage内调用js,也能监控和拦截页面内的事件,声明接口供页面调用本地存储内容 恶意app可以向hosted webview中插入js代码,从而获得host app的权限 不同app之间可以通过ICC传递访问请求,从而构造CSS攻击

对应措施:NoFrak 对webview app开发框架PhoneGap进行安全强化,增加了同源策略限制 NoInjection 增加了参数过滤,阻止了代码注入 Morbs 提供了一个framework层的插件扩展,通过监控ICC信息实施了同源策略,阻止跨站脚本攻击。 一些论文提出了提供给开发者的插件,增加js地址的白名单,证书TLS证书错误信息提示,提示给用户连接的安全信息

责任讨论:platform developers为相关API添加同源策略,此外APP开发者应该注意WEB到APP平台迁移的安全问题。

结论:主要是android上没有同源策略的问题,只要系统开发者完善这个功能就可以了,并不需要app开发者或者用户等去使用什么新插件。

Programming-induced Leaks

自定义的TLS证书校验问题,发现app开发者对TLS库的使用有很严重的问题,可以导致中间人攻击 密码学误用问题 88%的app至少出现了一个密码学误用的问题,API默认配置不安全,文档差劲,动态加载代码通过不安全通道,并且不做校验,导致被插入恶意代码

MalloDroid 静态分析工具,检测不正确的TLS证书校验 SMV-Hunter 与上面的工具类似,但是增加了动态分析的部分 CryptoLint 静态分析密码学相关API的误用问题 CHEX 静态分析工具自动检测组件劫持漏洞 ScanDroid 静态数据流分析工具,追踪组件间的数据流向 AndroidLeaks 大规模的隐私泄露分析工具 FlowDroid 静态污点分析工具,检测隐私泄露

责任讨论: Android developers应该重新设计相关的API,toolchain作者可以开发更好的工具重写APP开发者的代码,使其更安全,应用市场也可以帮助审核。

研究者们已经找出了很多编程方面的漏洞,这是值得肯定的,但作者还指出了一个思路,论文的调研说明,APP开发者的水平比较低,现有的API对他们并不友好,超出了一部分人的能力,他只能实现基本功能,并没能力考虑安全性,所以,可以考虑优化这些API。

Software Distribution

恶意软件主要是窃取用户隐私以及发送扣费短信 应用市场中还存在着很多的重打包应用 Android 安装过程中,签名仅用来验证完整性,不会向CA验证,但是很多app的权限控制会根据是否是同一个私钥签名的来判断是否赋予权限,建立安全的ICC 现状是很多开发者和发布者会用一个私钥去签上万个app

对应方式: Meteor 针对多应用市场产生的恶意软件问题,提出首先统一应用市场,通过除去app副本分支,绑定开发者等方式 MAST 将APP通过属性聚类进行评分,帮助定位可能的的潜在app Application Transparency 为用户提出了不同种验证app签名的方式 DNADroid 通过程序依赖图来分析市场上的盗版应用 RiskRanker 提供了一种主动的0-day恶意软件检测 CHABADA 是一种通过异常特征来检测恶意软件的方法,先讲app按照所属类别分组,然后调查私有API参数,恶意app会与组内其他应用很有很大差距 AppInk 通过动态水印技术,提供一个IDE的插件可以像代码中加入水印相关的代码,通过动态检测工具确认签名

责任讨论:Platform developers是主要责任方,需要修改主要的签名机制,应当支持PKI,也可以提出恶意软件检测机制,用户可以安装类似机制的软件。

总结:APP应用市场是一个非常重要的环节,他可以用来抵御恶意软件,也可能故意发布恶意应用。盗取隐私的app可能会使应用市场收益,所以应用市场的角色定位还不是很明确。此外app publisher的作用很少有人分析,这是一个研究点。

Vendor Customization/Fragmentation

Android 生态系统碎片化严重 操作系统版本很多,被严重个性化定制 厂商会提供不同的设备驱动,一般都会赋予厂商自己的APP过高的权限,这些app的漏洞影响范围会更广

对应方法: 还没有……

责任讨论:device vendors全责

总结:Android由于开源特性,版本的集中控制没有IOS做的好,厂商应该被告知,定制可能会引入安全问题。 此外,作者认为,应该推荐厂商在做定制硬件支持的时候,使用系统级别的app,而不是修改OS代码,这样可以使Android更加的模块化。虽然开发者在开发OS APP时也会犯错误,但是更新APP要比更新系统要简单的多。

Software Update Mechanism

app的更新速度很快,反应及时,但是操作系统层的更新很少有人在意 占位,在系统升级之前先占下下个版本的权限,从而版本更新之后自动获得了新的权限 google自己更新了nexus的更新规则,但是其他厂家不一定会采用

责任讨论:这个部分的责任在于device vendors和Platform developers。

总结:即使设备制造商采用了某个论文中的系统更新规则,但是现有的设备大多维护期都很短,所以新机制推广起来会很难。 应用层的模块化应该被推广到系统层,类似微内核机制,这样用户可以像更新APP那样更新系统.

Conclusion

Android系统的亮点:集中化的软件分发机制能够很好的抵御安全威胁,快速反应修复漏洞。 固有的一些问题也有了进步,比如提供更加好用的API。 但还是存在一些本身就是失败的机制,比如权限对话框,应该被完全移除。