微博:weibo.com/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)上盜取支付寶帳號密碼。 Youtube(需翻墻): 騰訊視頻
在未越獄的 iPhone6(iOS 8.2)上盜取微信支付密碼。 Youtube(需翻墻) ku6視頻
在 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 設備上完成支 付。 同樣是因為不綁定當前設備的問題,黑客甚至可以先在自己的設備上生成好訂單,然 后在用戶打開支付寶支付的時候把訂單替換掉,讓用戶給黑客的訂單買單。
基本上和支付寶一樣,不過支付時只需要提供 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 去打開 Google.com 這個網站。在機器上只安裝 Chrome 的情況下,app 會跳轉到 Chrome 打開 Google.com。但是當我們在 App Store 下載完一個叫 BASCOM Browser 的 app 之后,app 卻會 跳轉到 BASCOM Browser 打開 Google.com。經過統計,App Store 上有大量的應用聲明了 Chrome 以及 FaceBook 的 URL scheme,并且他們的開發者并不屬于 Google 和 Facebook。這 說明 Apple 根本就沒有保護那些熱門應用的 URL Scheme 的想法,上傳的 App 無論聲明什么樣的 URL Scheme,蘋果都會通過審核的。所以說,不光 Chrome,Facebook 有危險,支付寶, 微信啥的也逃不過這一劫。
因為 Bundle ID 在 App Store 上是唯一的(類似 Android 上的 package name)蘋果可以限制 iOS 應用不能注冊別的應用的 Bundle ID 作為 URL Scheme。這 樣的話,使用自己的 Bundle ID 作為 URL Scheme 的接收器就會變的安全很多。
既然蘋果不發布補丁保護第三方應用。第三方應用就沒有辦法了么? 不是的,這里至少有兩種方法可以檢測自己應用的 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 處理的順序,比如運行結果是:
2015-03-18 15:34:37.695 GetAllApp[13719:1796928] openURL: (
"<LSApplicationProxy: 0x156610010> com.mzheng.GetAllApp", "<LSApplicationProxy: 0x1566101f0> com.mzheng.Alipay", "<LSApplicationProxy: 0x15660fc30> com.alipay.iphoneclient"
)
說明有三個 app 都聲名了 alipay 這個 URL shceme,并且會處理這個請求的是 "com.mzheng.GetAllApp",而不是支付寶。
剛說完支付寶,微信逃不過這一劫,我們已經在 App Store 上發現了 劫持了支付寶的真實案例。
來看 demo: 戰旗 TV 劫持支付寶 URL Scheme Youku:
當用戶想要使用支付寶支付的時候,卻跳轉到了戰旗 TV。這里想問一下戰旗 TV,你到底想 要干些什么呢?:-)
PS:各大公司是不是要開始推送 iOS 手機安全助手了?
2015/03/23文章更新:戰旗tv已經得到反饋，正在緊急修復bug。
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.在非越獄的 iPhone 6 (iOS 8.1.3) 上進行釣魚攻擊 (盜取 App Store 密碼): LINK