原文地址：
https://www.fireeye.com/blog/threat-research/2016/01/hot_or_not_the_bene.html
蘋果做了非常多的努力來建造和維持一個健康并且干凈的應用環境。其中對現在的現狀起到很大作用的部分就是蘋果APP STORE，它是被一個十分周密的對所有提交的應用進行檢查的審批程序所保護的。盡管這個程序是被設計為用來保護IOS用戶并且確保應用程序符合蘋果的安全性和完整性的要求，體驗過這個流程的開發者可能會覺得它太復雜了并且花費了大量的時間。發布一個新的release版本或者發布一個已經存在的APP的補丁也要遵守這個流程，這對于一個想要給一個影響現有APP用戶的重要bug或者安全漏洞打補丁的開發者來說就會非常困擾。
開發者社區已經在尋找相應的替代方案，并且取得了一些進展。這一系列的解決方案現在提供更有效率的IOS APP開發體驗，讓APP開發者去更新他們的代碼只要他們認為是合適的，并且立即把補丁部署到用戶的設備上去。盡管這些技術提供更自由的開發體驗，它們并不符合蘋果試圖去維持的相同的安全規范。更糟糕的是，這些理念可能會成為蘋果APP STORE堅固“城墻”的阿喀琉斯之踵。
在這篇文章中，FireEye手機安全研究員將會分析采用這些可替代方案的IOS APP的安全風險，并且試圖阻止IOS APP生態環境做出意外的安全妥協。
在這篇文章最開始的部分，我們會關注一個開源的解決方案：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代碼。
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作為攻擊途徑的例子，并且會有更多的攻擊的可能性。
IOS大部分的本地的功能是依賴于C函數的（比如dlopen(),UIGetImageScreen())。由于C函數不能被反射調用，JSPatch不支持Objective C到JavaScript的直接映射。為了在JavaScript中使用C的函數，一個應用就必須支持JSExtension，JSExtension打包了C函數到相關接口并進一步導出到JavaScript中去。
依賴額外的Objective C代碼來使用C函數功能讓惡意的攻擊者受到了約束（比如后臺屏幕截取，在不被發現的情況下攔截文本消息，竊取照片隱私數據，或者后臺錄音）。但是這些約束可以被很簡單的繞過。事實上，JSPatch的作者可以在未來提供給應用開發者更可用和方便的接口，確保有足夠的命令。在這個情況下，以上的所有操作都不會被蘋果公司所感受到。
眾所周知IOS設備是比運行其他操作系統的手機更安全的；然而，我們必須認識到維持這個現狀的因素是多方面的。蘋果安全控制的核心是為IOS用戶和開發者提供和維持一個安全的生態環境，一個“帶有圍墻的花園”——APP STORE。通過APP STORE分發的應用在一次有意義的攻擊過程中將會是更難被利用的。時至今日，兩個主要的攻擊途徑組成了所有之前披露過的對IOS平臺發起的攻擊：
并且正如我們在這篇報告中強調的，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利用主機應用作為代理,實施各種惡意行為。
○ 下圖闡述了一個這種類型的攻擊場景：
JSPatch起源于中國。自從2015年發布以來，已經在中國地區獲得了成功。按JSPatch所說，很多流行的中文應用已經采用了這個技術。FireEye應用掃描在APP STORE中發現了1220個使用JSPatch的應用。
我們也發現了中國之外的開發者采用了這個框架。一方面，這也說明JSPatch在IOS開發環境中是一個很有用并且令人滿意的技術。另一方面，這也標志著這些用戶有很大的威脅可能被攻擊——尤其是沒有采取預防措施來確保所有涉及到的各方的安全。盡管JSPatch暴露出了一些安全風險，FireEye沒有發現任何上述的應用是惡意的。