iOS URL Scheme 劫持-在未越狱的 iPhone 6上盗取支付宝和微信支付的帐号密码 | WooYun知识库
iOS URL Scheme 劫持-在未越狱的 iPhone 6上盗取支付宝和微信支付的帐号密码
微博:/zhengmin1989
该漏洞是 iOS 系统漏洞,和支付宝,微信 app 无关。本文只是拿支付宝和微 信作为演示漏洞的应用,其他应用同样可以中招,转发者请勿断章取义。
此漏洞是另一 个漏洞,和“在非越狱的 iPhone 6 (iOS 8.1.3) 上进行钓鱼攻击 (盗取 App Store 密码)”上利 用的漏洞无关,本人不会干用一个漏洞写两个文章灌水的事情。
该漏洞最早是由我在 FireEye 的同事 hui, Song jin 和 lenx 发现的,因为该漏洞利用简单,修 复却非常复杂,所以在 iOS 8.2 上还是未能修复。虽然 iOS 尚未修复,但 app 本身还是可以 有防护的方法,本人在文章最后会提出一些应急的解决方案以供开发人员参考。
首先来看 demo: 在未越狱的 iPhone6(iOS 8.2)上盗取支付宝帐号密码。 (需翻墙):
在未越狱的 iPhone6(iOS 8.2)上盗取微信支付密码。 (需翻墙)
0x02 DEMO 细节分析(支付宝)
在 iOS 上,一个应用可以将其自身”绑定”到一个自定义 URL Scheme 上,该 scheme 用于 从浏览器或其他应用中启动该应用。这个设计非常类似于 android 上的 broadcast 和 broadcast receiver,但远远没有 android 上的复杂。美团利用支付宝付款的整个过程如图一所示:美团 首先将订单信息通过 URL Scheme 发送给 Alipay,Alipay 收到订单信息,调用支付界面,用户 在 Alipay 上完成支付后,Alipay 再发送一个 URL Scheme 给美团,美团收到付款信息后,显 示团购成功的界面。
图一、正常支付流程
但因为 URL scheme 这个机制太简单了,完全没有考虑有多个 app 声明同一个 URL Scheme 的情况,也没有权限管理之类的方案。在 iOS 官方说明中:“在多个应用程序注册了同一种 URLScheme 的时候,iOS 系统程序的优先级高于第三方开发程序。但是如果一种URLScheme 的注册应用程序都是第三方开发的,那么这些程序的优先级关系是不确定的。”实际上,经 过我们的测试,这个顺序是和 Bundle ID 有关的,如果精心构造 Bundle ID,iOS 总是会调用 我们 app 的 URL Scheme 去接收相应的 URL Scheme 请求。那么问题来了,如果我们精心构 造一个 app 并声明“alipay”这个 URL Scheme 会怎么样呢?
结果就如 demo 中所演示的那样,后安装的 FakeAlipay 应用劫持了美团与支付宝之间的支付 流程,并且可以在用户毫无意识情况下获取用户的帐号,支付密码,以及帮用户完成支付。 整个过程如图二所示:FakeAlipay 在收到美团发来的订单信息后,构造了一个和支付宝一样 的登陆界面,用户在输入了帐号密码后,FakeAlipay 会把帐号密码以及订单信息发送到黑客 的服务器上,黑客在获得了这些信息后,可以在自己的 iOS 设备上完成支付,并把支付成功 的 URL Scheme 信息发回给 FakeAlipay,FakeAlipay 再把支付成功的 URL Scheme 信息转发给 美团。因为时间原因,demo 做得比较粗糙,没有做转发信息给美团这一部分的演示,但绝 对是可行的。
图二、劫持后的支付流程
这种攻击可以成功的原因除了 iOS 本身的漏洞外,支付宝也有一定的责任。那就是发给支付 宝的订单信息并不是绑定当前设备的。因为这个原因,黑客可以在其他的 iOS 设备上完成支 付。 同样是因为不绑定当前设备的问题,黑客甚至可以先在自己的设备上生成好订单,然 后在用户打开支付宝支付的时候把订单替换掉,让用户给黑客的订单买单。
0x03 DEMO 细节分析(微信)
基本上和支付宝一样,不过支付时只需要提供 6 位支付密码,如 果想要得到微信帐号密码的话,还需要构造一个假的登陆界面。当然了,你可能会说有短信 验证,但是如果整个登录界面都是伪造的话,用户也会乖乖的帮你输入短信验证码的。并且, 在 iOS 8.1 之前,iOS 的短信也存在监控漏洞,具体请参考我们 ASIACCS 的论文。
好吧,讲到这里肯定又有人说:你的漏洞是挺严重的,但还是得往我机器上装 app 啊。我从 来不用什么 pp 助手,同步推之类的,也不装什么企业应用,平时只在 AppStore 上下载,因 为有苹果的审核,所以我肯定不会中招的。呵呵,苹果的审核真的信得过么?请看第二个 demo: Google Chrome URL Scheme 劫持
图三、Google Chrome URL Scheme 劫持
Google 公司不比阿里差吧?Google Chrome 可以算是 Google 在 iOS 上最重要的应用之一了吧? 可惜的是,在该 demo 中 Google 公司的 Chrome 应用已经非常不幸的被 App Store 下载的 app 劫持掉了。如图三所示:演示用的 app 会利用 Google Chrome 的 URL Scheme 去打开
这个网站。在机器上只安装 Chrome 的情况下,app 会跳转到 Chrome 打开 。但是当我们在 App Store 下载完一个叫 BASCOM Browser 的 app 之后,app 却会 跳转到 BASCOM Browser 打开 。经过统计,App Store 上有大量的应用声明了 Chrome 以及 FaceBook 的 URL scheme,并且他们的开发者并不属于 Google 和 Facebook。这 说明 Apple 根本就没有保护那些热门应用的 URL Scheme 的想法,上传的 App 无论声明什么样的 URL Scheme,苹果都会通过审核的。所以说,不光 Chrome,Facebook 有危险,支付宝, 微信啥的也逃不过这一劫。
0x04 解决方案
1. 针对 iOS 系统。
因为 Bundle ID 在 App Store 上是唯一的(类似 Android 上的 package name)苹果可以限制 iOS 应用不能注册别的应用的 Bundle ID 作为 URL Scheme。这 样的话,使用自己的 Bundle ID 作为 URL Scheme 的接收器就会变的安全很多。
2. 针对第三方应用
既然苹果不发布补丁保护第三方应用。第三方应用就没有办法了么? 不是的,这里至少有两种方法可以检测自己应用的 URL Scheme 是否被 Hijack:
(1)、应用本 身可以发送一条 URL Scheme 请求给自己,如果自己可以接收到的话,说明 URL Scheme 没 有被劫持,如果不能收到的话,就说明被劫持了,这时候可以提醒用户卸载有冲突的 app。
[[UIApplication sharedApplication] openURL:[NSURL URLWithString:@“alipay://test“]];
(2)、利用 MobileCoreServices 服务中的 applicationsAvailableForHandlingURLScheme()方法可以 所有注册了该 URL Schemes 的应用和处理顺序,随后应用就可以检测自己,或者别人的 URL Scheme 是否被劫持了。代码如下:
Class LSApplicationWorkspace_class = objc_getClass("LSApplicationWorkspace");
NSObject* workspace =
[LSApplicationWorkspace_class performSelector:@selector(defaultWorkspace)]; NSLog(@"openURL: %@",[workspace performSelector:@selector(applicationsAvailableForHandli ngURLScheme:)withObject:@"alipay"]);
在任意 app 下运行这个函数,可以返回 URL 处理的顺序,比如运行结果是:
15:34:37.695 GetAllApp[8] openURL: (
"&LSApplicationProxy: 0x& com.mzheng.GetAllApp", "&LSApplicationProxy: 0x& com.mzheng.Alipay", "&LSApplicationProxy: 0x15660fc30& com.alipay.iphoneclient"
说明有三个 app 都声名了 alipay 这个 URL shceme,并且会处理这个请求的是 "com.mzheng.GetAllApp",而不是支付宝。
0x05 文章更新
刚说完支付宝,微信逃不过这一劫,我们已经在 App Store 上发现了 劫持了支付宝的真实案例。
来看 demo: 战旗 TV 劫持支付宝 URL Scheme Youku:
当用户想要使用支付宝支付的时候,却跳转到了战旗 TV。这里想问一下战旗 TV,你到底想 要干些什么呢?:-)
PS:各大公司是不是要开始推送 iOS 手机安全助手了?
文章更新:战旗tv已经得到反馈，正在紧急修复bug。
0x06 参考文献:
1.iOS Masque Attack:
? 2.Min Zheng, Hui Xue, Yulong Zhang, Tao Wei, John C.S. Lui "Enpublic Apps: Security Threats Using iOS Enterprise and Developer Certificates", ACM Symposium on Information, Computer and Communications Security (ASIACCS'15), Singapore, April 2015
3.在非越狱的 iPhone 6 (iOS 8.1.3) 上进行钓鱼攻击 (盗取 App Store 密码):
碎银子打赏，作者好攒钱娶媳妇：
支付宝会根据支付设备情况推送检验，这个是没有问题的啊
什么都不安全！
可以被利用的现有规则或策略不是漏洞?
看这样是否有效：
支付宝和美团之间可以约定一个私钥，如果私钥检查不通过，说明有问题了。
例如：美团向支付宝发送请求时，带上一个经过加密的key，在支付宝完成支付后，会向美团返回另一个加密过的key2，如果在美团端解密不成功，说明这个key2不是来自正版支付宝的。
我一直在想 如果用户 双击home 开启多任务模式 不就能看见这个app的 icon 了吗（icon相同AppStore审核肯定过不了~） 这样不就发现这个挂羊头卖狗肉的app了吗
安卓也是如此的，有个问题就是用户怎么知道哪个是真的？
只有后4位，是通过iOS scheme信息传过去的。有什么不科学
假微信里面居然知道用户的招商银行卡和卡号后4位，不科学啊～
钓鱼网站随处可见，难道说是浏览器的漏洞嘛
人家苹果官方文档说的很清楚，不保证哪个应用被调用，这算个毛漏洞
/library/ios/documentation/iPhone/Conceptual/iPhon
eOSProgrammingGuide/Inter-AppCommunication/Inter-AppCommunication.html
Note: If more than one third-party app registers to handle the same URL
scheme, there is currently no process for determining which app will be
given that scheme.
厉害，Mark..
ps:你女票好漂亮!
以前貌似遇到过有的应用URL Scheme冲突的情况，不过及时修正了，感觉不是多大的问题，另外伪造支付平台界面这种的，审核也没法过吧...这标题略显夸张=。=
人家是香港中文大学的博士生，分分钟教高中英语老师做人
真是瞎jb扯淡
用了not only... but语句，不仅...而且，看来高中英语老师教得好。
确实呀。。。app store审核最近又变严格了
想问下，，， 作者你是国人还是国外人？？
呵呵，使用LSApplicationWorkspace以后，应用能通过审核吗？
钓鱼app是完全可以通过苹果的审核。
换句话说，苹果目前没有针对这一点做审核。
不需要bundle id
只需要app注册scheme url，按照苹果的跪着，后注册的scheme url是优先级最高的。
看起来很牛逼的样子，你是要自己盗自己的钱吗？
同样是 url scheme 跳转，微软在处理上就稍微聪明了点，冲突的 scheme 每次打开时都会让用户从这些应用中选一个…
这个漏洞我之前在做电商的时候已经发现了，只不过想不到真的是可以挟持的到。
不一定非要用在支付宝应用上啊，感觉可以进行应用推广什么的。。
iOS Scheme 那个问题，是个开发者仔细读过文档就知道，文档都提到不确定会打开哪个App，所以根本不是什么新发现，这是个公开的信息。不知道的刚知道就觉得特神奇还要发表论文也是陶醉…关键是到最后你也不可能支付成功，而且一下子揭穿了。iOS Scheme这类就是单纯的跳转，用在支付应用上本来就不是特别合适。
/malicious-urls-pose-mobile-hijacking-risk-53
这个问题2010年就有人注意到了
楼主，支付宝这段不可行，支付宝客户端是会验证可信设备环境的，你之所以能成功是因为你的操作过程都在你的支付宝账号的可信设备上，如果你换一台从未登陆过该支付宝客户端的设备，支付宝会认为你在一个非授信环境会要求短信验证的；而且支付宝客户端有手机锁的设定，虽然默认未开启但是也可防范你所说的攻击，另外支付宝还有一个登陆消息提醒功能
马克一下，早上细看
你没看清楚，案例中有App store的应用（BASCOM Browser，战旗TV），也就是说App store审核完全可以绕过。
居然看懂了
另外前两个演示视频的伪应用看上去并不在app store上，虽然手机没有越狱，伪应用应该是演示者自己编写然后用开发者证书安装在自己手机上的。在应用中使用第三方商标无法通过app store审核。
文章里已经说了，这一切都必须先给用户安装伪应用，实际上实现起来并不容易。用户要先看到伪应用的app store页面，自己点击“获取”按钮，自己输入Apple ID密码，然后屏幕上多一个伪应用图标，之后才能被攻击。即使用企业证书，攻击者也面临着滥用企业证书被吊销证书的风险。
360心想，安全软件终于有用武之地了。。。
ccav看这里看这里
前提是你要有一个肾
留名回去搬板凳看~对了，8.1.2 也有？
虽说没有iphone 但是还是由衷的 赞一个！
首先得有个iphone6
看着很不错哎！
第三方的修复方式一很容易就存在绕过吧
安卓上面也有类似的问题，你甚至能控制支付宝打开一个你的钓鱼页面。
学习了。楼上惊现黑阔………
楼主是我爹，特地来围观
赞~思路有点像jsonhijack+CSRF
两个问题：
1. 精心构造的Bundle ID，有啥规则能提高优先级？
1.“让用户给黑客的订单买单”如何绕过签名，用别人的密码给自己的订单支付？
是说3那个运营商吗？楼主应该是在香港，3是香港的一个电信运营商。
前排前排ccav看这里！
哇擦擦搞坏事啊，好好玩！
请教一下博主 iOS 8 未越狱修改运营商名称的方法 谢谢博主
这个时候 是不是要@一些人了
这么屌。。
文章很赞~ps 标题开头应该是iOS吧~
感谢知乎授权页面模版}