該漏洞是iOS系統(tǒng)漏洞，和支付寶，微信app無關(guān)。本文只是拿支付寶和微信作為演示漏洞的應(yīng)用，其他應(yīng)用同樣可以中招。轉(zhuǎn)發(fā)者請(qǐng)勿斷章取義。

該漏洞最早是由我在FireEye的同事hui， Song jin和lenx發(fā)現(xiàn)的，因?yàn)樵撀┒蠢煤唵?，修?fù)卻非常復(fù)雜，所以在iOS 8.2上還是未能修復(fù)。雖然iOS尚未修復(fù)，但app本身還是可以有防護(hù)的方法，本人在文章最后會(huì)提出一些應(yīng)急的解決方案以供開發(fā)人員參考。

一、DEMO

首先來看demo：在未越獄的iPhone6(iOS 8.2)上盜取支付寶帳號(hào)密碼。

在未越獄的iPhone6(iOS 8.2)上盜取微信支付密碼。

二、DEMO細(xì)節(jié)分析（支付寶）

在iOS上，一個(gè)應(yīng)用可以將其自身“綁定”到一個(gè)自定義URL Scheme上，該scheme用于從瀏覽器或其他應(yīng)用中啟動(dòng)該應(yīng)用。這個(gè)設(shè)計(jì)非常類似于android上的broadcast和broadcast receiver，但遠(yuǎn)遠(yuǎn)沒有android上的復(fù)雜。美團(tuán)利用支付寶付款的整個(gè)過程如圖一所示：美團(tuán)首先將訂單信息通過URL Scheme發(fā)送給Alipay，Alipay收到訂單信息，調(diào)用支付界面，用戶在Alipay上完成支付后，Alipay再發(fā)送一個(gè)URL Scheme給美團(tuán)，美團(tuán)收到付款信息后，顯示團(tuán)購成功的界面。

▲圖一、正常支付流程

但因?yàn)閁RL scheme這個(gè)機(jī)制太簡單了，完全沒有考慮有多個(gè)app聲明同一個(gè)URL Scheme的情況，也沒有權(quán)限管理之類的方案。在iOS官方說明中:“在多個(gè)應(yīng)用程序注冊(cè)了同一種URLScheme的時(shí)候，iOS系統(tǒng)程序的優(yōu)先級(jí)高于第三方開發(fā)程序。但是如果一種URLScheme的注冊(cè)應(yīng)用程序都是第三方開發(fā)的，那么這些程序的優(yōu)先級(jí)關(guān)系是不確定的。”實(shí)際上，經(jīng)過我們的測試，這個(gè)順序是和Bundle ID有關(guān)的，如果精心構(gòu)造Bundle ID，iOS總是會(huì)調(diào)用我們app的URL Scheme去接收相應(yīng)的URL Scheme請(qǐng)求。那么問題來了，如果我們精心構(gòu)造一個(gè)app并聲明“alipay”這個(gè)URL Scheme會(huì)怎么樣呢?

結(jié)果就如demo中所演示的那樣，后安裝的FakeAlipay應(yīng)用劫持了美團(tuán)與支付寶之間的支付流程，并且可以在用戶毫無意識(shí)情況下獲取用戶的帳號(hào)，支付密碼，以及幫用戶完成支付。整個(gè)過程如圖二所示：FakeAlipay在收到美團(tuán)發(fā)來的訂單信息后，構(gòu)造了一個(gè)和支付寶一樣的登陸界面，用戶在輸入了帳號(hào)密碼后，F(xiàn)akeAlipay會(huì)把帳號(hào)密碼以及訂單信息發(fā)送到黑客的服務(wù)器上，黑客在獲得了這些信息后，可以在自己的iOS設(shè)備上完成支付，并把支付成功的URL Scheme信息發(fā)回給FakeAlipay，F(xiàn)akeAlipay再把支付成功的URL Scheme信息轉(zhuǎn)發(fā)給美團(tuán)。因?yàn)闀r(shí)間原因，demo做得比較粗糙，沒有做轉(zhuǎn)發(fā)信息給美團(tuán)這一部分的演示，但絕對(duì)是可行的。

▲圖二、劫持后的支付流程

這種攻擊可以成功的原因除了iOS本身的漏洞外，支付寶也有一定的責(zé)任。那就是發(fā)給支付寶的訂單信息并不是綁定當(dāng)前設(shè)備的。因?yàn)檫@個(gè)原因，黑客可以在其他的iOS設(shè)備上完成支付。同樣是因?yàn)椴唤壎ó?dāng)前設(shè)備的問題，黑客甚至可以先在自己的設(shè)備上生成好訂單，然后在用戶打開支付寶支付的時(shí)候把訂單替換掉，讓用戶給黑客的訂單買單。

三、DEMO細(xì)節(jié)分析（微信）

基本上和支付寶一樣，不過支付時(shí)只需要提供6位支付密碼，如果想要得到微信帳號(hào)密碼的話，還需要構(gòu)造一個(gè)假的登陸界面。當(dāng)然了，你可能會(huì)說有短信驗(yàn)證，但是如果整個(gè)登錄界面都是偽造的話，用戶也會(huì)乖乖的幫你輸入短信驗(yàn)證碼的。并且，在iOS8.1之前，iOS的短信也存在監(jiān)控漏洞，具體請(qǐng)參考我們ASIACCS的論文。

好吧，講到這里肯定又有人說：你的漏洞是挺嚴(yán)重的，但還是得往我機(jī)器上裝app啊。我從來不用什么pp助手，同步推之類的，也不裝什么企業(yè)應(yīng)用，平時(shí)只在AppStore上下載，因?yàn)橛刑O果的審核，所以我肯定不會(huì)中招的。呵呵，蘋果的審核真的信得過么？

請(qǐng)看第二個(gè)demo：Google Chrome URL Scheme劫持

▲圖三、Google Chrome URL Scheme劫持

Google公司不比阿里差吧？Google Chrome可以算是Google在iOS上最重要的應(yīng)用之一了吧？可惜的是，在該demo中Google公司的Chrome應(yīng)用已經(jīng)非常不幸的被App Store下載的app劫持掉了。如圖三所示：演示用的app會(huì)利用Google Chrome的URL Scheme去打開Google.com這個(gè)網(wǎng)站。在機(jī)器上只安裝Chrome的情況下，app會(huì)跳轉(zhuǎn)到Chrome打開Google.com。但是當(dāng)我們?cè)贏pp Store下載完一個(gè)叫BASCOM Browser的app之后，app卻會(huì)跳轉(zhuǎn)到BASCOM Browser打開Google.com。經(jīng)過統(tǒng)計(jì)，App Store上有大量的應(yīng)用聲明了Chrome以及FaceBook的URL scheme，并且他們的開發(fā)者并不屬于Google和Facebook。這說明Apple根本就沒有保護(hù)那些熱門應(yīng)用的URL Scheme的想法，上傳的App無論聲明什么樣的URL Scheme，蘋果都會(huì)通過審核的。所以說，不光Chrome，F(xiàn)acebook有危險(xiǎn)，支付寶，微信啥的也逃不過這一劫。

四、解決方案

1.針對(duì)iOS系統(tǒng)。因?yàn)锽undle ID在App Store上是唯一的(類似Android上的package name)蘋果可以限制iOS應(yīng)用不能注冊(cè)別的應(yīng)用的Bundle ID作為URL Scheme。這樣的話，使用自己的Bundle ID作為URL Scheme的接收器就會(huì)變的安全很多。

2.針對(duì)第三方應(yīng)用既然蘋果不發(fā)布補(bǔ)丁保護(hù)第三方應(yīng)用。第三方應(yīng)用就沒有辦法了么？不是的，這里至少有兩種方法可以檢測自己應(yīng)用的URL Scheme是否被Hijack：

(1) 應(yīng)用本身可以發(fā)送一條URL Scheme請(qǐng)求給自己，如果自己可以接收到的話，說明URL Scheme沒有被劫持，如果不能收到的話，就說明被劫持了，這時(shí)候可以提醒用戶卸載有沖突的app。

代碼如下:

[[UIApplication sharedApplication] openURL:[NSURL URLWithString:@“alipay://test“]];

(2) 利用MobileCoreServices服務(wù)中的applicationsAvailableForHandlingURLScheme()方法可以所有注冊(cè)了該URL Schemes的應(yīng)用和處理順序，隨后應(yīng)用就可以檢測自己，或者別人的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下運(yùn)行這個(gè)函數(shù)，可以返回URL處理的順序，比如運(yùn)行結(jié)果是:

2015-03-18 15:34:37.695 GetAllApp[13719:1796928] openURL: (

" com.mzheng.GetAllApp"， " com.mzheng.Alipay"， " com.alipay.iphoneclient"

)

說明有三個(gè)app都聲名了alipay這個(gè)URL shceme，并且會(huì)處理這個(gè)請(qǐng)求的是"com.mzheng.GetAllApp"，而不是支付寶。

五、剛說完支付寶、微信逃不過這一劫，我們已經(jīng)在App Store上發(fā)現(xiàn)了劫持了支付寶的真實(shí)案例。

來看demo：戰(zhàn)旗TV劫持支付寶URL Scheme Youku

當(dāng)用戶想要使用支付寶支付的時(shí)候，卻跳轉(zhuǎn)到了戰(zhàn)旗TV。這里想問一下戰(zhàn)旗TV，你到底想要干些什么呢？:-)

PS：各大公司是不是要開始推送iOS手機(jī)安全助手了?

2015/03/23文章更新：:戰(zhàn)旗tv已經(jīng)得到反饋，正在緊急修復(fù)bug。

六、參考文獻(xiàn)：

1.iOS Masque Attack: LINK

?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.在非越獄的iPhone6 (iOS 8.1.3)上進(jìn)行釣魚攻擊(盜取App Store密碼): LINK