记录黑客技术中优秀的内容, 传播黑客文化,分享黑客技术精华

MAC OS X与iOS平台上的未授权跨应用资源访问漏洞

2015-06-25 04:20

分享到:

一、     XARA问题研究概述

XARA(Unauthorized Cross-App Resource Access)未授权跨应用资源访是由北京大学、印第安纳大学、佐治亚理工学院的安全研究人员发现的。在MAC OS X以及iOS平台上,为了保护应用程序的数据和资源,各个应用程序之间是相互隔离的,每个应用程序都被限制于一个拥有最小权限集合的沙箱中,并且需要显式地向系统或者其他用户请求资源访问权限(如相机、录音等)。然而,研究人员通过对MAC OS X和iOS平台进行了系统地分析后发现,能够通过构建恶意的App,使恶意App未授权地访问其他App的资源,并且这些恶意的App也能够通过App Store的审核。

具体而言,研究人员发现App之间的交互服务(包括OS X上的Keychain和WebSocket,OS X和iOS上的URL Scheme)都能被恶意App所利用来获取用户机密的信息。这些信息包括iCloud、Email和银行的密码,以及Evernote的token信息等等。

更进一步,OS X上的App沙箱也是可以被突破的,使得劫持了App的Apple Bundle ID的恶意软件可以访问其私有的目录。在这种情况下,用户的敏感数据(Evernote中的笔记和通讯录、微信中的照片等等)都会暴露于恶意软件之中。

造成XARA的根本原因是由于缺少App-to-App和App-to-OS之间的验证。研究人员开发了一款扫描器Xavus来检查App中是否对于XARA漏洞有正确的保护措施。通过对OS X和iOS平台上的主流App进行了扫描检测,列出了XARA的影响的范围,并在OS X平台上实现了一个简单的程序来监控是否有恶意程序尝试利用XARA漏洞来访问资源。文章的最后对如何设计更安全的系统进行了总结。

二、     背景

1.     App沙箱

在Apple平台上,使用UID来将App进行分组。例如,在OS X平台上,所有来自MAC App Store的应用都被安装到当前系统用户的组中,而在iOS平台上则被安装到mobile用户组中。在这些平台上,应用之间的隔离是由TrustBSD的API来强制实现的。每个应用由其Apple ID来区分,这个ID字符串由两部分组成,Team ID和Bundle ID,例如A1B2D3C4E5.com.apple.mail。在Apple平台上,每一个处于App沙箱中的应用程序在第一次启动的时候都会被赋予一个容器目录,这个目录用于存放App的内部数据并且不能被其他处于沙箱中的由不同开发者开发的App所访问。处于沙箱中的应用在默认情况下只能访问它自身的容器目录和一些公共目录。

2.     Apple平台上的IPC

在OS X和iOS平台上公有的IPC机制是URL Scheme。与Android平台上的实现方式不同,在一台设备上,Apple的操作系统只允许一个Scheme与一个App相关联。正是这种区别,导致了OS X和iOS平台上的Scheme劫持攻击。

3.     WebSocket

WebSocket用于在服务端和客户端之间建立全双工的socket链接。在其定义中,引入了Javascript的接口,通过这个接口,在浏览器中web端的内容可以直接和本地App进行交互。通过TCP端口,浏览器的扩展和本地App之间可以进行数据交互。通常情况下,App运行一个WebSocket的服务端监听特定端口,浏览器的组件通过连接这个端口来进行数据的交换。

三、     XARA可导致的威胁

研究人员关注的是沙箱模型如何保护进程间的交互信道以及服务,并且如何使其与非信任的App相隔离。通过研究发现,在OS X的Keychain、基于BID的隔离,以及OS X和iOS上的IPC信道中,都存在安全隐患。

1.     密码窃取(OS X)

XARA中的密码窃取问题主要是通过攻击操作系统的Keychain。Keychain是一个重要管理服务,通过Keychain,用户可以将密码、密钥以及证书存放在其中。当Keychain被锁定的时候,所有的凭据都会被加密并且任何人都不能访问其中的信息。正常情况下,一个默认的keychain条目是由各自的用户创建的,并且服务于大多数的系统服务。即使keychain不属于沙箱,但是它的数据也是隔离于各个应用之间的。除非得到授权,否则即使keychain被解锁,每个App仍然不能访问其他App的keychain条目。研究人员发现了一个keychain实现的薄弱环节,可以用于窃取其他App的用户机密信息。

n   问题原因

Figure 1是简化的Keychain结构图,Figure 2是Apple建议的使用Keychain来存储和更新其中条目的方式。当App尝试访问keychain条目的时候,服务首先会检查是否权限是否允许访问,然后会进一步检查ACL来确认用户的权限是否能够进行相关的操作。然而,当恶意App在目标App(victim)运行之前就创建了一个keychain条目,将这个keychain条目的属性声明成目标App的属性,并且将目标App置信于这个keychain条目的ACL中。这样,当目标App(victim)使用keychain来存储密码的时候,发现拥有其属性的keychain条目已存在,就会将密码数据更新到这个条目中去(由Figure 2 Apple建议的实现方式所展示的可知)。重要的是,并没有任何提示来说明目标App(victim)仅仅只是这个构造的keychain条目的guest用户,并且keychain的拥有者是不可信的。最终,目标App的隐私数据就会完全暴露于恶意App的访问之中。

http://p4.qhimg.com/t0129f2c49420cd88aa.png

http://p6.qhimg.com/t015674d79ab7a97138.png

这就需要App在使用keychain中的条目之前验证条目的拥有者,但是Apple并没有提供一种便捷的方式来实现这样的查询和验证。唯一能够缓解这种威胁的解决办法是App要去检查已存在keychain条目的ACL列表,来确保其他不可信的App不在这个条目的ACL列表中。然而,Apple并没有提醒开发者必须这么做,这就最终导致了Keychain密码窃取的攻击。

在iOS平台上不存在这样的威胁,因为iOS平台上的Keychain实现较为简单,不支持ACL。每个App只能访问其自身的条目,并且,除了属于同一个开发者之外的所有App都不能共享keychain中的数据。

2.     沙箱突破(OS X)

Keychain的密码窃取是由于位于沙箱中的应用需要共享数据。然而,即使位于App私有目录中的数据,XARA的漏洞也依然存在。沙箱突破的根本原因是由于OS X平台上基于BID的隔离方式的设计缺陷。

每个沙箱中的App都有其唯一的BID,这个BID用于创建数据的容器目录,这个BID名称就将这个目录绑定到其所对应的App上。当App尝试访问这个目录的时候,操作系统就会检查App的签名,来保证只有目录的拥有者以及在这个目录的ACL上的组件才能访问。为了保证BID唯一,MAC App Store会进行BID唯一性的检查,那些在App Store中已存在BID将不会通过审核。

n   问题原因

沙箱突破主要是为了让开发者能够在不同的App中便利地共享框架、辅助程序以及XPC服务从而引入的安全问题。

在App中可以嵌入子程序,即App的子目标(sub-target)。一个子目标可以是一个辅助程序、XPC服务或者是一个框架等等,并且这些子目标都拥有自己的plist和BID。更具体地,辅助程序和XPC服务还拥有它们独立的容器目录。当App在App Store上发布后,它们的辅助程序和XPC服务都会被沙箱化,一旦App被安装,就会在/Library/Containers/目录下和它的主App一起创建各自独立的容器目录。而研究人员发现,MAC App Store无法验证子目标的BID和其他App的BID是否冲突,除了那些Apple自身保留的BID。这就导致了沙箱被突破,恶意App可以将其子目标的BID声明成其他App的BID。一旦恶意App开始运行,操作系统一旦发现包含相同BID的目录已存在,就会自动将恶意App添加到目标目录的ACL中,使得恶意App可以取得目标容器目录的所有权限,突破了沙箱的限制。

在iOS上也不存在这种威胁,因为iOS的主程序和子目标位于不同的父目录下,并且目录名称是随机生成的UUID串。而且iOS的app之间也不需要共享资源,所以不会导致相关问题的发生。

3.     IPC拦截监听(OS X)

IPC拦截监听会导致重要的信息(WEB密码等)泄漏。

n   问题原因

根据WebSocket的实现方式,在连接建立的时候缺乏正确的验证,这是导致OS X平台上IPC可以被拦截监听的主要原因。恶意程序可以在合法的程序启动之前,抢先占用相关的TCP端口,这就使得恶意程序可以接收到目标扩展的数据。这样的攻击方式同样也可以在浏览器端实现,恶意的扩展可以通过模拟合法的扩展使用相关的TCP端口进行验证。

研究人员发现,在Apple平台上,浏览器扩展组件无法对与其进行数据交互的本地WebSocket服务端进行验证,即没有API可以使用。唯一的解决方式只能依靠浏览器组件和App的开发者在程序中实现自定义的验证机制。

4.     Scheme劫持(OS X和iOS)

URL Scheme是一个App和其他App进行通讯的简单协议,App通过在其自身的plist文件中声明scheme的格式,并且允许其他App通过这个scheme来调用它并传递参数。Scheme可以通过浏览器或者API openURL来进行触发。

在OS X和iOS 平台上,即使多个App声明了相同的Scheme,操作系统也会自动将scheme和某个App相关联,这就造成了Apple操作系统平台上的Scheme劫持的问题。

n   问题原因

在OS X和iOS平台上,苹果保留了一个系统的Scheme列表,这里面的Scheme无法被第三方的App所占用(如sms等),同时还有另外一个列表(如http等)。研究人员发现,在这两个列表之外的所有scheme,在OS X平台上都会绑定到第一个注册这个scheme的App,在iOS平台上则会绑定到最后一个注册这个scheme的App。由于scheme的冲突,恶意程序可以获取目标App的服务请求甚至是发送的数据。特别是在iOS上,即使是恶意软件在目标App之后才安装,却仍然可以实现scheme劫持攻击。

在OS X平台上,可以通过使用API URLForApplicationToOpenURL或者LSCopyDefaultHandleForURLScheme来检查给定scheme的注册App,然而在iOS平台上并不存在这样的API。由于缺乏系统级别的支持,App无法验证其通过URL Scheme所调用的第三方程序,所有在iPhone和iPad中运行的程序都面临Scheme劫持的威胁,恶意软件可以成功实现MITM攻击。

四、     XARA检测和防御

研究人员设计并实现了Xavus扫描器用于静态检测App是否可被XARA攻击,并对主流的App进行了扫描检测,给出了影响范围。在XARA涉及的所有威胁中,URL scheme劫持以及BID冲突导致的沙箱突破都是由于系统级别的缺陷导致的,只有通过Apple才能进行修复。而其他的威胁,更多取决于App如何处理,即App如何对其交互的对象进行验证。

1.     Xavus设计与漏洞检测方法

检测XARA漏洞的基本思路是检测App在使用服务或者信道前是否有正确的验证措施。在典型的情况下,App在使用服务或者信道前,需要首先进行声明。因此,可以通过检查在声明和使用之间的CFG来判断是否有验证。Xavus分为5个模块,如Figure3:

(1)    反编译App的二进制可执行文件

研究人员使用Hopper对可执行文件进行反编译,得到OS X平台上的x64指令以及iOS平台上的armv7指令。如果iOS上App是加密的,首先需要使用clutch进行解密。

(2)    扫描App中是否使用相关的服务或者信道

检查相关的API调用的指令,例如SecKeychainFindGenericPassword。通过检查objc_msgSend被调用时的selector参数,即RSI寄存器(OS X)和R1寄存器(iOS),可以得知相关的服务何时被使用。不仅需要得知服务何时被使用,还需要知道是否真正进行了验证。

(3)    构建CFG

首先搜索服务或者信道的声明API,然后调用Hopper的脚本来构建涉及这些API调用的CFG。

(4)    在CFG中构建声明-使用链

从声明的位置开始,对声明-使用链进行分析:从引用服务/信道的位置(keychain条目的指针,scheme的字符串)开始,对所有使用这些引用的位置(寄存器重新赋值)进行标记。这么做的目的是为了定位其他使用这个服务/信道的API,这样就能够得知是否在使用前进行了验证。

http://p8.qhimg.com/t015fe943f6d2e15f2d.png

CFG检测示例,如Figure 4。首先通过反编译得到汇编指令,然后通过定位keychain相关的API SecKeychainFindGenericPassword得到keychain服务的引用位置,引用存放在[ss:rbp-0x30]。接着,Xavus追踪这个引用的传播,定位到了下一个使用它的API SecKeychainItemModifyAttributesAndData。由于这两个引用之间没有进行验证,因此可能会被XARA攻击。

http://p4.qhimg.com/t019e50940031db700f.png

(5)    检测是否存在XARA漏洞

存在XARA漏洞的必要条件是在使用服务或者信道之前没有进行验证,因此就必须要检测是否进行了验证。对于各个服务和信道,验证操作的特征如下:

n   Keychain

唯一的验证方式是通过检查keychain条目的ACL,因此,在声明和使用keychain条目之间,要调用API SecACLCopyContents进行检查。如果没有调用这个API,说明可能存在XARA漏洞攻击的风险。

n   WebSocket

WebSocket服务器基本上是基于一些流行的开源框架,例如CocoaHTTPServer活QtWebKit。这些框架都提供了receiver方法来接收来自浏览器扩展的消息,Xavus使用这个作为特征来识别WebSocket信道的引用,同时还有response方法来向浏览器扩展进行答复。在receiver方法和response方法之间,服务端需要访问HTTP头中的Origin字段,并调用SecCodeCheckValidity API来验证浏览器的签名。如果缺少这些操作,这个App有可能会存在XARA漏洞攻击的风险。值得说明的是,浏览器组件无法通过任何现存的API对恶意的WebSocket服务端进行验证。

n   URL Scheme

通过URL Scheme来调用其他App主要通过两种方式,App中固有的URL链接或者从WebView中返回的URL串。前一种方式可以直接从App中获取,而后一种方式来源于WebPolicyDelegate的四个方法之一。App可以通过WebPolicyDelegate对象控制WebView中对于Web内容的操作。四个方法是:

l   decidePolicyForMIMEType:request:

l   decidePolicyForNavigationAction:request:

l   decidePolicyForNewWindowAction:request:

l   willPerformClientRedirectToURL:

调用了这四个方法的地方可以看作是对Scheme的声明,而使用Scheme是通过openURL方法。

在OS X平台上,在声明和使用的过程之间,App可以调用API URLForApplictionToOpenURL或者 LSCopyDefaultHandlerForURLScheme来检查哪个App会因为scheme被调用。如果缺少这两个API调用中的任意一个,说明这个App极有可能会面临Scheme劫持攻击。值得注意的是,在iOS平台上,App无法得知一个scheme的拥有者。

n   BID

BID冲突所引起的XARA漏洞完全是由于App Store和OS X沙箱的设计引起的。Xavus通过检查NSHomeDirectory API调用,来检测App是否向容器目录中写入数据。因为这些数据可能会由于BID冲突的问题暴露与恶意App的访问之下。

2.     Xavus的局限性

Xavus是静态检测,如果App通过动态构建scheme来调用的话,Xavus就无法检测到。另一方面,开发者可能会使用一些自定义的保护手段来进行验证,因此对于keychain和WebSocket相关的检测,Xavus可能会有遗漏。例如,App会在要更新keychain条目的时候,首先删除keychain条目然后再创建一个新的,即使这种方式是Apple不推荐的。同时对于WebSocket而言,浏览器组件可能会通过WebSocket信道传递密钥来进行验证。在这种情况下,Xavus可能会产生误报的情况。

3.     XARA影响范围

研究人员从MAC App Store上下载了1612个免费的App,这些App覆盖了应用商店的21个类别,并且是各个Top 100以内的所有App。还从iOS App Store中下载了200个最流行的App,其中加密的App都使用clutch进行了解密。检测结果见下表。

http://hackdig-h.stor.sinaapp.com/pictures/month_1506/201506250420153881.png

Table 2中显示了一些常见App所涉及的XARA漏洞。

http://p8.qhimg.com/t01e4b516750e295e49.png

4.     XARA缓解方法

由于一些XARA漏洞的修复涉及系统级别的修复,Apple推出修复补丁外,可以有一些保护措施来缓解XARA漏洞攻击。研究人员在OS X平台上实现了一个扫描器App,可以自动检测XARA攻击行为。

思路和实现:

主要的实现思路是通过FSEvents API,对特定的目录或者文件进行监控。通过调用FSEvents API,当特定文件被修改的时候,就会得到通知。

对于Keychain,通过监控/Library/Keychains/目录和~/Library/Keychains/目录中的keychain文件,只要文件被修改,扫描器就会调用SecItemCopyMatching方法来查找是否有新的keychain条目被添加到keychain中,然后进一步调用SecACLCopyContents来访问ACL。正常情况下,系统的App不会和任何第三方的App共享keychain条目,一旦检测到共享的情况,就会向用户提示潜在的威胁。对于第三方的App,就需要构建数据库来进行离线的分析。

对于Scheme和BID,扫描器通过FSEvents API跟踪新安装的App。当App被安装的时候,通过扫描plist文件得到其注册URL Scheme或者其子目标的BID。然后通过与系统中已经存在scheme和BID进行对比,一旦有冲突发生,就说明当前App或者已存在的App尝试进行XARA攻击,就触发警告。

五、     总结

几乎所有的XARA问题都是来源于Apple公司关于跨应用资源共享以及通讯的设计缺陷。有的XARA问题(例如WebSocket)也可能存在与其他平台上,如Windows和Android。XARA问题的根本原因是由于缺少跨应用资源共享时的验证措施。相对于OS X,

iOS由于没有涉及复杂的资源共享而相对安全。在设计系统时,避免跨应用交互时XARA危害的三个设计原则。

l   原则1: 对于每一种交互服务或信道,需要决定操作系统能够实现何种程度的保护。操作系统必须随时定位安全问题来确保保护的有效性,并且必须向开发者明确他们需要注意的事项。

l   原则2:提醒开发者关于App端的安全性验证,并提供相关的验证手段。

l   原则3:在App Store中对安全性加强检测。即使为开发者提供了足够的信息和技术手段支持,仍然可能会有软件缺陷存在。因此,可以在App Store这一统一的分发渠道进行进一步的安全性检测。

相关阅读&演示视频

MAC OSX未授权跨应用资源访问

本文由 360安全播报 原创发布,如需转载请注明来源及本文地址。
本文地址:http://www.hackdig.com/06/hack-23528.htm

知识来源: bobao.360.cn/learning/detail/473.html

阅读:127118 | 评论:0 | 标签:漏洞 iOS

想收藏或者和大家分享这篇好文章→复制链接地址

“MAC OS X与iOS平台上的未授权跨应用资源访问漏洞”共有0条留言

发表评论

姓名:

邮箱:

网址:

验证码:

公告

九层之台,起于累土;黑客之术,始于阅读

推广

工具

标签云

本页关键词