原文地址：
https://www.fireeye.com/blog/threat-research/2016/01/hot_or_not_the_bene.html

0x00 前言

---

蘋果做了非常多的努力來建造和維持一個健康並且乾淨的應用環境。其中對現在的現狀起到很大作用的部分就是蘋果APP STORE，它是被一個十分周密的對所有提交的應用進行檢查的審批程式所保護的。儘管這個程式是被設計為用來保護IOS使用者並且確保應用程式符合蘋果的安全性和完整性的要求，體驗過這個流程的開發者可能會覺得它太複雜了並且花費了大量的時間。釋出一個新的release版本或者釋出一個已經存在的APP的補丁也要遵守這個流程，這對於一個想要給一個影響現有APP使用者的重要bug或者安全漏洞打補丁的開發者來說就會非常困擾。

開發者社群已經在尋找相應的替代方案，並且取得了一些進展。這一系列的解決方案現在提供更有效率的IOS APP開發體驗，讓APP開發者去更新他們的程式碼只要他們認為是合適的，並且立即把補丁部署到使用者的裝置上去。儘管這些技術提供更自由的開發體驗，它們並不符合蘋果試圖去維持的相同的安全規範。更糟糕的是，這些理念可能會成為蘋果APP STORE堅固“城牆”的阿喀琉斯之踵。

在這篇文章中，FireEye手機安全研究員將會分析採用這些可替代方案的IOS APP的安全風險，並且試圖阻止IOS APP生態環境做出意外的安全妥協。

在這篇文章最開始的部分，我們會關注一個開源的解決方案：JSPatch。

0x01 JSPatch

---

JsPatch是一個開源專案——它基於蘋果公司的JavaScriptCore框架——目的是為蘋果的費力以及不可預測的審批程式提供一種可替換的方案，當及時釋出重要bug的補丁是非常重要的時候。用作者自己的話說（加粗的部分作強調）：

JSPatch使用Objective-C的執行環境來聯絡Objective-C和JavaScript。你只需要包含一個小的引擎，就可以在JS中呼叫任何Objective-C的類和方法。這就讓這個APP獲得了指令碼語言的能力：動態地新增模組或者替換Objective—C程式碼來修復bug。

JSpatch的作者，在個人部落格中提供了一個樣例，來說明JSPatch是如何被用來更新一個有缺陷的APP：

下圖展示了一個UITableViewController的實現，類名為JPTableViewController,透過tableView:didSelectRowAtIndexPath:來提供資料。在第5行，它會從後端源的字串陣列中檢索資料，這個字串陣列帶有一個對映到選定行數字的目錄。在很多情況下，這個功能是沒有問題的；但是當行目錄超過了源資料陣列的範圍時，這也是很有可能發生的，這個程式就會丟擲一個異常並且最終導致APP crash掉。而APP的崩潰對使用者來說是絕對不希望發生的。

在蘋果提供的技術範圍內，修復這個狀況的方法就是使用更新的程式碼來修復bug並且重建這個應用，並且把最新建立的APP提交給App Store作申請。儘管審批流程對於更新的應用相比最開始提交的審查來說往往花費更少的時間，這個流程仍然是花費大量時間的，不可預期的，並會導致一些虧損，如果APP的修復沒有能以一種及時並且可控的模式進行釋出。

然而，如果原始的應用嵌入了JSPatch引擎，它的行為就可以按照在執行時被載入的JavaScript程式碼來改變。這裡的JS檔案(hxxp://cnbang.net/bugfix.JS in the above example)是被APP開發者遠端控制的。它透過網路通訊被髮送到APP。

下圖展示了JSPatch在一個IOS應用中被建立的基本方法。這些程式碼將會允許下載一個JavaScript補丁並在APP剛啟動的時候執行。

JSPatch確實是非常輕量級的。在這個例子中，確保它能執行做的額外的工作就只是在application:didFiishLaunchingWithOptions: selector中新增了7行程式碼。下圖展示的是從hxxp://cnbang.net/bugfix.JS下載的用於給有缺陷的程式碼打補丁的JS程式碼。

0x02 惡意功能展示

---

JSPatch對IOS開發者來說是一份不錯的福利。從好的一方面來說，它可以被用來迅速並有效地部署補丁和程式碼更新。但是在我們這樣一個非烏托邦的世界裡，總會有人去利用這種技術來實現預料之外的目的。特別是，如果一個攻擊者能夠篡改最終被APP載入的JavaScript的檔案，就可以靠一個蘋果APP STORE的應用來實施大規模的攻擊。

目標應用：

我們隨機挑選了一個合法的APP，它使用JSPatch並且可以從APP STORE下載到。如圖所示，建立JSPatch平臺的邏輯以及補丁的原始碼被打包在[AppDelegate excuteJSPatch:]這個流程中。

這裡有一系列的流程，從應用程式入口點（在這個例子中就是AppDelegate類）到JavaScript檔案包含更新或者補丁程式碼被寫到檔案系統的地方。這個流程包含了與遠端伺服器通訊獲得補丁程式碼。在我們的測試裝置上，我們最終發現JavaScript的補丁程式碼是被hash處理的並且儲存在如下圖所示的位置。hash過的內容也如下圖所示，它使用base64格式加密的。

（下載的JavaScript檔案在目標機器上儲存的位置）

（加密的補丁內容）

儘管這個目標應用的開發者已經採取了一些措施來確保這些隱私資料不被非法竊取，比如在對稱加密的基礎上使用Base64編碼，攻擊者可以透過在Cycript上執行幾條指令來使這些安全措施無效。加密的補丁程式碼如下圖所示：

這就是被JPEngine載入和執行的內容，JPEngine是由JSPatch框架提供並嵌入到目標應用中的。為了改變正在執行的APP的行為，我們就要去修改一些JavaScript的內容。在下面我們展示了對抗蘋果審查的惡意行為的幾種可能。儘管下面的樣例是來自於一臺越獄過的裝置，我們同樣也會證實這些行為也可以在非越獄裝置上完成。

Example 1 :載入任意的public framework到應用程式內

a. public framework樣例： /System/Library/Frameworks/Accounts.framework

b. 一些被public framework使用的private API： [ACAccountStore init], [ACAccountStore allAccountTypes]

上面討論的目標應用，當被執行的時候，就回家再如下圖所示的frameworks進入到程式記憶體中去：

注意上面的清單——從蘋果允許的IOS應用的二進位制檔案生成的——並沒有包含Accounts.framework。因此，任何依賴這個框架提供的這些API進行的“危險”或者“有風險”的操作都是不希望發生的。然而，下圖所示的JavaScript程式碼讓這種假設沒有任何意義。

如果這些JavaScript程式碼作為hot patch被髮送到目標應用，它就會動態載入一個public framework（Accounts.framework）到執行的程式中去。一旦這個框架被載入，這個指令碼就有許可權接觸這個框架所有的API。下圖展示了執行private API（ACAccountStore allAccountTypes）的輸出，它輸出了36個賬戶型別在測試裝置上。新增的行為不需要要求這個應用進行重建，也不需要在APP store進行額外的審查。

上面的證明強調了對於IOS APP使用者和APP開發者來說可能存在的嚴重的安全風險。JSPatch技術可能會允許個人有效的繞過APP store的審查流程，並且在裝置上執行任意的有威力的行為並且不需要使用者的同意。程式碼動態的本質也讓在一次惡意的行為中抓住惡意的攻擊者變得十分困難。我們並不會在這個博文中提供任何有意義的EXP，只是指出這個可能性來避免攻擊者對這個漏洞進行利用。

Example 2 ：將任意private的framework載入到應用程式中去

a. framework樣例：

/System/Library/PrivateFrameworks/BluetoothManager.framework

b. 樣例的framework使用的private API：

[BluetoothManager connectedDevices], [BluetoothDevice name]

和上一個例子很像，一個惡意的JSPatch JavaScript指令碼可以讓一個應用載入任意的private framework，比如BluetoothManager.framework，並且會進一步呼叫private API來改變裝置的狀態。IOS private framework是被設計為只能被蘋果提供的應用所使用。儘管關於private framework的使用並沒有相關官方的檔案，但是關於它們眾所周知的是它們中的大部分可以提供私有的接近底層系統功能的權利，這也可能會讓一個應用繞過作業系統設定的安全控制。APP STORE有嚴格的策略禁止第三方APP使用任何private framework。然而，很有必要指出的是作業系統並沒有區分蘋果應用的private framework使用和第三方應用的private framework使用。禁止第三方使用僅僅只是蘋果APP STORE自己的策略。

當我們使用JSPatch，這些約束就會變得毫無疑義，因為JavaScript檔案並不屬於蘋果APP store的審查範圍。下圖展示的程式碼是透過載入BluetoothManager.framework並利用API來讀和改變主機裝置的藍芽狀態。然後後一張圖展示的是相匹配的控制檯的輸出。

Example 3：透過private API改變系統屬性

a.樣例依賴的framework：

/System/Library/Frameworks/CoreTelephony.framework

b.樣例framework使用的private API：

[CTTelephonyNetworkInfo updateRadioAccessTechnology:]

考慮一個使用public framework（CoreTelephony.framework）建立的目標應用的情況。按照蘋果的檔案說明，這個framework允許獲得一個使用者的家庭行動電話服務提供者的資訊。它暴露了幾個public API給開發者來獲得這些，但是[CTTelephonyNetworkInfo updateRadioAccessTechnology:]並不是其中的一個。然而，如下圖所示，我們可以成功的在不經過蘋果同意的情況下使用這個private API來更新目標裝置的行動電話服務狀態。

Example 4：透過public API獲取相簿隱私資料

a. 樣本載入的framework：

/System/Library/Frameworks/Photos.framework

b. public apis:

[PHAsset fetchAssetsWithMediaType:options:]

對於手機使用者來說關注的問題主要是隱私侵犯的問題。任何在一個裝置上執行的涉及到接觸和使用使用者隱私資料的行為（包括聯絡人，資訊，照片，音訊，記事本，通話記錄等等）都應該被證明是在應用提供的服務的範圍之內。然而，如下圖所示，我們可以利用private API接觸到使用者的相簿，透過從內建的Photo.framework來採集照片的後設資料。如果再多一點程式碼，攻擊者就可以在使用者不知情的情況下把照片資料匯出。

Example 5 :實時獲得剪貼簿的資料

a. framework樣例：/System/Library/Frameworks/UIKit.framework

b. API：[UIPasteboard strings], [UIPasteboard items], [UIPasteboard string]

IOS的剪貼簿是允許應用之間資料傳遞的機制之一。一些安全研究者已經提出一些關於安全方面的擔憂，因為剪貼簿可以被用來傳遞隱私資料，比如賬戶和證照。下圖展示了一個簡單的JavaScript的demo函式，當在JSPatch framework上執行時，就會從剪貼簿獲取所有的字串內容並顯示到控制檯上去。

我們已經展示了5個利用JSPatch作為攻擊途徑的例子，並且會有更多的攻擊的可能性。

0x03 未來的攻擊方法

---

IOS大部分的本地的功能是依賴於C函式的（比如dlopen(),UIGetImageScreen())。由於C函式不能被反射呼叫，JSPatch不支援Objective C到JavaScript的直接對映。為了在JavaScript中使用C的函式，一個應用就必須支援JSExtension，JSExtension打包了C函式到相關介面並進一步匯出到JavaScript中去。

依賴額外的Objective C程式碼來使用C函式功能讓惡意的攻擊者受到了約束（比如後臺螢幕擷取，在不被發現的情況下攔截文字訊息，竊取照片隱私資料，或者後臺錄音）。但是這些約束可以被很簡單的繞過。事實上，JSPatch的作者可以在未來提供給應用開發者更可用和方便的介面，確保有足夠的命令。在這個情況下，以上的所有操作都不會被蘋果公司所感受到。

0x04 安全影響

---

眾所周知IOS裝置是比執行其他作業系統的手機更安全的；然而，我們必須認識到維持這個現狀的因素是多方面的。蘋果安全控制的核心是為IOS使用者和開發者提供和維持一個安全的生態環境，一個“帶有圍牆的花園”——APP STORE。透過APP STORE分發的應用在一次有意義的攻擊過程中將會是更難被利用的。時至今日，兩個主要的攻擊途徑組成了所有之前披露過的對IOS平臺發起的攻擊：

1. 由於禁止了簽名檢查函式，越獄的IOS裝置允許未簽名的或者錯誤簽名的應用進行安裝。在一些情況下，沙箱的約束被移除，這也就允許應用在沙箱外執行。
2. 在非越獄裝置上，應用程式可以藉助企業證照進行side loading。FireEye釋出了一系列關於利用這個攻擊面的詳細的攻擊的報告，並且最近的報告都在持續關注這個已知的攻擊途徑。

並且正如我們在這篇報告中強調的，JSPatch提供了一個不需要side loading或者一臺越獄的裝置作為攻擊必須要素的攻擊途徑。不難斷定JSPatch裡的JavaScript的內容可能將會是這個應用開發框架的阿喀琉斯之踵。因為幾乎沒有什麼安全措施來確保這個檔案的安全屬性，以下的攻擊場景是可能會發生的：

● 前提條件： 1）應用內嵌入了JSPatch平臺；2）應用開發者有惡意的企圖。

○ 影響： 應用開發者可以利用載入的framework提供的所有的private API來實施不想被蘋果公司或者使用者知道的行為。因為開發者擁有對JavaScript程式碼的控制，所以惡意的行為可能會是暫時的、動態地、秘密的和具有逃避性的。這樣的攻擊一旦發生，就會給所有牽涉到的利益相關者帶來巨大的風險。

○ 下圖闡述了一個這種型別的攻擊場景：

● 前提條件： 1）第三方廣告SDK嵌入了JSPatch平臺；2）主機應用程式使用了這個廣告SDK；3）廣告SDK對主機應用程式有惡意的企圖。

○ 影響：1）廣告SDK可能會從應用沙盒洩露資料；2）廣告SDK可能會改變主機應用程式的行為；3）廣告SDK可以以主機應用程式的名義對作業系統進行各種操作。

○ 下圖闡述了一個這種型別的攻擊場景：

FireEye在2015年的關於iBackdoor的發現就是一個IOS開發社群內的可信替換攻擊的例子，並且可以作為這種被忽視的威脅的一個很好的例子。

● 前提條件：1）應用嵌入了JSPatch平臺；2）應用開發者是合法的；3）應用沒有保護從客戶端到伺服器之間JavaScript內容通訊的安全；4）一個惡意的攻擊者實施中間人攻擊篡改JavaScript內容。

○ 影響：中間人攻擊可以洩露沙盒內的應用的內容；中間人攻擊可以透過private API利用主機應用作為代理,實施各種惡意行為。

○ 下圖闡述了一個這種型別的攻擊場景：

0x05 相關資料

---

JSPatch起源於中國。自從2015年釋出以來，已經在中國地區獲得了成功。按JSPatch所說，很多流行的中文應用已經採用了這個技術。FireEye應用掃描在APP STORE中發現了1220個使用JSPatch的應用。

我們也發現了中國之外的開發者採用了這個框架。一方面，這也說明JSPatch在IOS開發環境中是一個很有用並且令人滿意的技術。另一方面，這也標誌著這些使用者有很大的威脅可能被攻擊——尤其是沒有采取預防措施來確保所有涉及到的各方的安全。儘管JSPatch暴露出了一些安全風險，FireEye沒有發現任何上述的應用是惡意的。