iOS URL Scheme 劫持-在未越獄的 iPhone 6上盜取支付寶和微信支付的帳號密碼

wyzsk發表於2020-08-19
作者: 蒸米 · 2015/03/23 14:45

0x00 前言


微博:weibo.com/zhengmin1989

  • 該漏洞是 iOS 系統漏洞,和支付寶,微信 app 無關。本文只是拿支付寶和微 信作為演示漏洞的應用,其他應用同樣可以中招,轉發者請勿斷章取義。

  • 此漏洞是另一 個漏洞,和“在非越獄的 iPhone 6 (iOS 8.1.3) 上進行釣魚攻擊 (盜取 App Store 密碼)”上利 用的漏洞無關,本人不會幹用一個漏洞寫兩個文章灌水的事情。

該漏洞最早是由我在 FireEye 的同事 hui, Song jin 和 lenx 發現的,因為該漏洞利用簡單,修 復卻非常複雜,所以在 iOS 8.2 上還是未能修復。雖然 iOS 尚未修復,但 app 本身還是可以 有防護的方法,本人在文章最後會提出一些應急的解決方案以供開發人員參考。

0x01 DEMO


首先來看 demo: 在未越獄的 iPhone6(iOS 8.2)上盜取支付寶帳號密碼。 Youtube(需翻牆): 騰訊影片

<embed>

在未越獄的 iPhone6(iOS 8.2)上盜取微信支付密碼。 Youtube(需翻牆) ku6影片

<embed>

0x02 DEMO 細節分析(支付寶)


在 iOS 上,一個應用可以將其自身”繫結”到一個自定義 URL Scheme 上,該 scheme 用於 從瀏覽器或其他應用中啟動該應用。這個設計非常類似於 android 上的 broadcast 和 broadcast receiver,但遠遠沒有 android 上的複雜。美團利用支付寶付款的整個過程如圖一所示:美團 首先將訂單資訊透過 URL Scheme 傳送給 Alipay,Alipay 收到訂單資訊,呼叫支付介面,使用者 在 Alipay 上完成支付後,Alipay 再傳送一個 URL Scheme 給美團,美團收到付款資訊後,顯 示團購成功的介面。

enter image description here

圖一、正常支付流程

但因為 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 做得比較粗糙,沒有做轉發資訊給美團這一部分的演示,但絕 對是可行的。

enter image description here

圖二、劫持後的支付流程

這種攻擊可以成功的原因除了 iOS 本身的漏洞外,支付寶也有一定的責任。那就是發給支付 寶的訂單資訊並不是繫結當前裝置的。因為這個原因,駭客可以在其他的 iOS 裝置上完成支 付。 同樣是因為不繫結當前裝置的問題,駭客甚至可以先在自己的裝置上生成好訂單,然 後在使用者開啟支付寶支付的時候把訂單替換掉,讓使用者給駭客的訂單買單。

0x03 DEMO 細節分析(微信)


基本上和支付寶一樣,不過支付時只需要提供 6 位支付密碼,如 果想要得到微信帳號密碼的話,還需要構造一個假的登陸介面。當然了,你可能會說有簡訊 驗證,但是如果整個登入介面都是偽造的話,使用者也會乖乖的幫你輸入簡訊驗證碼的。並且, 在 iOS 8.1 之前,iOS 的簡訊也存在監控漏洞,具體請參考我們 ASIACCS 的論文。

好吧,講到這裡肯定又有人說:你的漏洞是挺嚴重的,但還是得往我機器上裝 app 啊。我從 來不用什麼 pp 助手,同步推之類的,也不裝什麼企業應用,平時只在 AppStore 上下載,因 為有蘋果的稽核,所以我肯定不會中招的。呵呵,蘋果的稽核真的信得過麼?請看第二個 demo: Google Chrome URL Scheme 劫持

Youtube(需翻牆) 騰訊影片

<embed>

enter image description here

圖三、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 有危險,支付寶, 微信啥的也逃不過這一劫。

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 處理的順序,比如執行結果是:

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",而不是支付寶。

0x05 文章更新


剛說完支付寶,微信逃不過這一劫,我們已經在 App Store 上發現了 劫持了支付寶的真實案例。

來看 demo: 戰旗 TV 劫持支付寶 URL Scheme Youku:

<embed>

當使用者想要使用支付寶支付的時候,卻跳轉到了戰旗 TV。這裡想問一下戰旗 TV,你到底想 要幹些什麼呢?:-)

PS:各大公司是不是要開始推送 iOS 手機安全助手了?

2015/03/23文章更新:戰旗tv已經得到反饋,正在緊急修復bug。

0x06 參考文獻:


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

本文章來源於烏雲知識庫,此映象為了方便大家學習研究,文章版權歸烏雲知識庫!

相關文章