iOS URL Scheme安全性研究

阅读量345586

|评论1

|

发布时间 : 2019-07-15 16:30:22

x
译文声明

本文是翻译文章,文章原作者 trendmicro,文章来源:blog.trendmicro.com

原文地址:https://blog.trendmicro.com/trendlabs-security-intelligence/ios-url-scheme-susceptible-to-hijacking/

译文仅供参考,具体内容表达以及含义原文为准。

 

0x00 前言

Apple在iOS中部署了沙箱机制,用来管理应用程序安全和隐私方面的问题。该机制限制了每个应用程序所能访问的资源,如果某个应用出现问题,就能将问题限制在一定范围内,通过App Store发布的所有app都受该机制约束。然而也是因为这种访问控制策略,app之间的通信会变得有些困难。

幸运的是,Apple精心设计了几种方法,帮助app之间相互通信,这里最常用的一种方法就是URL Scheme。从本质上讲,URL Scheme是一种实用功能,可以允许开发者通过URL在iOS设备上启动app。URL Scheme是将信息从一个app传到另一个app的一种方法。比如,当我们打开带有facetime://的URL时,就会发起FaceTime呼叫,这个场景中就用到了URL Scheme。这是非常方便的一条捷径,但URL Scheme主要是用于通信场景,并不是从安全性角度来设计的。

在本文中,我们将讨论如何滥用URL Scheme,实现隐私泄露、账单欺诈、以及弹出式广告等恶意场景。我们以中国区市场中的几款iOS应用为例(主要是WeChat即时通讯应用以及Suning网上购物应用,这里就不翻译了)来演示这种误用场景。与WeChat和Suning类似,还有其他很多应用具有相同功能,因此也受本文分析的这种攻击技术影响。我们向相关厂商(特别是WeChat)反馈并协同解决相关问题,也向Zero Day Initiative反馈了这些攻击技术。

 

0x01 工作原理

在iOS系统中,多个app可以声明同一个URL Scheme。比如,两个完全不同的app可以同时使用Sample://这个URL Scheme。这也正是某些恶意应用对URL Scheme的一种滥用方式,可以借此攻击最终用户。

Apple在后续iOS版本(iOS 11)中解决了这个问题,采用了先到先得原则,如果使用了同一个URL Scheme,只有先安装的app会被启动。然而,攻击者还是可以通过其他方法来利用这个漏洞。

账户隐私泄露

我们可以把URL Scheme看成是app用来接收其他app信息的一个门户。前面提到过,由于Apple允许不同app声明相同的URL Scheme,因此恶意app可以劫持特定app的敏感数据。如果app A的登录过程与app B关联起来,那么这个漏洞就显得非常严重。

举个例子,比如Suning app允许受害者使用自己的WeChat账户来登录。正常的身份认证过程如下图所示,Suning app生成一个URL Scheme查询,将其发送给WeChat app。当WeChat app收到来自Suning app的查询时,会向WeChat服务器请求一个Login-Token(登录令牌),然后将该令牌发回Suning app,完成认证过程。

图1. Suning app使用WeChat账户登录过程

我们研究后发现,Suning会使用相同的Login-Request URL Scheme查询来请求Login-Token,但WeChat并没有验证登录请求的源。这样一来,攻击者就可以滥用某个app的Login-Request URL Scheme发起攻击。

比如,攻击者可以使用Suning的Login-Request URL Scheme查询来请求受害者WeChat账户的Login-Token,然后利用这个令牌,以受害者WeChat账户的身份登录Suning(如下图所示)。这个过程可以允许攻击者收集个人信息,或者滥用这两个账户的访问权限。

图2. 恶意攻击者使用受害者WeChat账户登录Suning app

为了使这种攻击方法完美实施,攻击者首先必须要得到Suning的Login-Request URL Scheme。如果想从Suning app获取该信息,攻击者需要以WeChat的URL Scheme来创建一个完全独立的app(我们可以在Suning app的Info.plist中,通过LSApplicationQueriesSchemes找到WeChat的URL Scheme)。利用合法的Wechat URL Scheme,攻击者可以伪造一个WeChat app,这样Suning就会向伪造的app请求Login-Token。

如果Suning app发送了请求,那么伪造的app就可以捕获相应的Login-Request URL Scheme。经过分析后,我们发现这个Login-Request会在多个查询轮次中包含常量参数以及常量值,这样攻击者就有机会重放请求。

图3. 从Suning到WeChat的Login-Request

图4. 从WeChat到Suning的Login-Token

如图3及图4所示,Suning在构造查询字符串时,会插入一个独特且复杂的URL Scheme(即wxe386966df7b712ca),以便WeChat响应。WeChat端会将这个URL注册为Suning登录专用。WeChat虽然能够识别该URL,但并不会去认证发送Login-Request的源。相反,WeChat会直接向请求源返回一个Login-Token。

不幸的是,这个源app也可能是滥用Suning URL的恶意app。

图5. 恶意app通过URL Scheme攻击窃取Login-Token

利用这个Login-Token,恶意攻击者可以访问受害者的WeChat账户,窃取个人信息。攻击者可以在其他攻击活动中使用已窃取的账户。

这个问题并不局限于这两个app,还有许多app采用了这种登录功能,因此也存在这个漏洞。

账单欺诈

伪造的URL Scheme也可以用于多个攻击场景,比如账单重放欺诈攻击,攻击者可以诱骗受害者支付其他人的账单。这种攻击需要使用社会工程学技巧以及URL Scheme漏洞。

通常情况下,如果某些app带有支付功能,攻击者可以向这些app发送账单对应的URL Scheme来发起账单重放欺诈攻击。这里我们以DiDi或者MeiTuanDaChe(这两个app都是交通出行app,这里就不翻译了),再搭配带有支付功能的某个app为例,来演示这种攻击方法。

为了重现这种攻击,我们以WeChat作为支付app来演示其中存在的问题。我们还没在实际环境中看到攻击者用过这种攻击方法,但只要指定参数,攻击就有可能成功。攻击者可以使用前文提到的策略:伪造一个WeChat,与合法应用带有相同的URL Scheme,然后抓取来自DiDi或者MeiTuanDaChe的URL Scheme支付请求。

利用支付URL Scheme,攻击者可以向任意合法WeChat app重放支付请求,而该app会自动唤起支付接口。由于攻击者使用的是从DiDi或者MeiTuanDaChe窃取的(但是合法的)URL Scheme请求,因此受害者端合法的WeChat app会接受这个支付请求。

图7. 重放URL Scheme

不可否认的是,正常用户可能不会被欺骗,因为用户不大可能会去支付在WeChat支付接口中随机弹出的支付请求。即便如此,这种方式极大增加了用户被欺诈攻击的可能性。用户有可能不小心点了支付按钮,或者可能误认为这是合法的付款请求。

这里也可能存在另一种攻击场景,比如结合使用SMS(短信)社会工程学技巧以及URL Scheme。以这些app为例,攻击者可以利用这种支付请求。

如果用户用过DiDi或者MeiTuanDaChe app,那么经常会收到短信,提醒用户尚未完成订单支付。攻击者可以向受害者发送相同的SMS消息,其中包含某个支付请求的URL Scheme(这个支付请求可以是攻击者构造的任意请求)。该链接会重定向到WeChat的支付接口,要求用户完成支付。这是攻击受害者的一种好方法,可以诱骗用户支付他人账单。

图8. 依托SMS消息的账单重放欺诈攻击

幸运的是,最新版的WeChat部署了一种新的安全策略,可以避免这种支付重放攻击:如果支付请求来自于MobileSafari,WeChat将不再接受该请求。然而,如果支付请求源自于Chrome、Message、Gmail等其他app,那么账单重放攻击依然可行。

弹出式广告

URL Scheme还有另一个问题,就是可以用来启动应用程序。这意味着一旦恶意app注册了特定的URL Scheme,那么当这个URL Scheme被调用,就有可能启动恶意app。在研究过程中,我们系统识别出了大量app,这些app都会利用这种方式来向用户展示广告。

恶意app可以声明与其他流行应用象关联的URL Scheme,比如wechat://line://fb://fb-messenger://等,我们也找到了许多潜在恶意的app,如下所示:

SHA256 Bundle ID 声明的URL Scheme数量
1377742266f2a56f0424c1884c9c1fab8daa113b51c7f4d2ac4b2f88b770a1f5 co.Mu.Mu 490
c329fc984a2d75e4f1f15288cb5d9383c2f439dbae67bf808759bc5bc8336aee co.medaistream.pokemap2 430
93326edbbd8863fbb0d2e602e1d8a7348349053ae144912286e78fb17a685c0f co.musical.Musical 491
fe8fe4226ba17924cd31505a07b19691b5eecf2e9ae677bc9765130020662b89 com.musictechnology.Musia 491

 

0x02 缓解措施

URL Scheme可能非常危险,不建议用于传输敏感数据。由于通信过程及数据传输中并没有考虑源或目的app,因此攻击者可以利用这种未授权功能发起攻击。

当我们首次发现该漏洞时,就分别于2018年6月及8月向受影响厂商反馈相关信息,并且我们还注意到受影响的许多应用实际上来自于中国区的App Store。Apple也意识到了这种威胁,官方向开发人员通报了URL Scheme存在的危险,并提供了相应建议。官方提到:“URL Scheme可能使您的应用存在潜在的安全风险,因此请确保您充分验证所有URL参数,丢弃格式错误的任何URL。此外,请限制应用的操作范围,避免用户数据受到影响”。

对于开发者而言,我们建议应用在深度链接场景中使用通用型链接,设置通用链接登录接口(HTTP或者HTTPS),使用随机标识符在本地认证收到的登录令牌,避免劫持以及恶意登录令牌重放攻击。

本文翻译自blog.trendmicro.com 原文链接。如若转载请注明出处。
分享到:微信
+11赞
收藏
興趣使然的小胃
分享到:微信

发表评论

内容需知
  • 投稿须知
  • 转载须知
  • 官网QQ群8:819797106
  • 官网QQ群3:830462644(已满)
  • 官网QQ群2:814450983(已满)
  • 官网QQ群1:702511263(已满)
合作单位
  • 安全客
  • 安全客
Copyright © 北京奇虎科技有限公司 360网络攻防实验室 安全客 All Rights Reserved 京ICP备08010314号-66