屎蛋 · 2016/06/22 10:11
author:[email?protected]
0x00 “Hotpatch”簡介
IOS App的開發者們經常會出現這類問題：當一個新版本上線后發現存在一個嚴重的bug，有可能因為一個邏輯問題導致支付接口存在被薅羊毛的風險，這個時候能做的只能是趕快修復完安全問題并提交到appstore審核，在急忙推送用戶盡快更新，避免為此導致的嚴重安全后果買單。為了解決此類問題遍有了實現給App應用”實時打補丁”這類方案，目前大致有兩種主流的“熱修復”的項目。
根據基本原理可以分為下面兩種，
原理同為構建JS腳本與Object-C語言之間轉換的橋梁。
WaxPatch(Lua調用OC)
JSPatch(Javascript調用OC)
”熱修復” 技術雖然極大的減少了開發者更新補丁的時間與商業成本，但卻將Apple努力構建的安全生態系統——Apple Store對上架App的嚴格審查規則置于高風險下。通過這種技術可以在上線以后直接更新App原生代碼，從而從某種意義上繞過了Apple Store的審查規則。
0x01 原理分析
這種手段是通過IOS內置的JavaScriptCore.framework 微型框架來實現的，它是Apple官方在IOS7以后推出的主要是用來提供一個在Objective-C中執行Javascript環境的一個框架。
JSPatch并沒有使用JSExport協議與OC代碼進行互調，而是使用了JSBinding(Javascript與OC代碼交互的接口)與Objective-C中的runtime(運行時)，采用了JavaScriptCore.framework框架作為解析javascript的引擎，與客戶端的代碼實時交互動態修改OC方法的一種方案。
對客戶端整個對象的轉換流程如下：
使用JavaScriptCore.framework作為Javascript引擎解析JavaScript腳本，執行JavaSript代碼并與Objective-C端的代碼進行橋接。另一方面則是使用Objective-C runtime中的method swizzling的方式和ForwardInvocation消息轉發機制使得在JavaScript腳本中可以調用任意Objective-C方法。
總的執行過程：
Javascript-> JavaScriptCore Framework-> Objective-C->runtime->動態修改IMP
(更像與Android的Webview代碼執行？)
下圖展示了在客戶端代碼中如何嵌入JSPatch。
在此之后客戶端每次啟動時都會下載請求這段js腳本來更新客戶端代碼。
0x02 存在的安全隱患
JSPatch的確給IOS開發者們帶來了很多好處，但是這么高的權限如果使用不當往往會有惡意用戶會用它來做一些壞事。
可以預見的風險主要來自以下方面：
一 傳輸過程安全問題
服務端在下發JS的更新補丁時如果傳輸過程中如果沒有使用Https或者對Https的證書未做嚴格校驗，又或者沒有做數據防篡改的方案，更新的補丁在傳輸過程中被惡意攻擊者劫持篡改了傳輸補丁數據，就可以導致非常大的危害，比如命令執行什么的。。
實踐出真知，由于沒有找到合適的App做演示，我們使用虛擬機做跳板機來簡單搭建一個中間人的場景：
虛擬機ip: 10.180.145.17 這臺機器充當中間人的角色。
本機搭建一個簡單的服務器，用于App的更新腳本服務器，用于下發jspatch腳本。
在測試App中的Object-C加入要更新補丁的url(嵌入到JPEngine中)：
url:http://10.180.144.1:8081/static/js/test.js
這段js補丁本來是要在屏幕打印222 這幾個數字,但是App在更新補丁時并沒有使用Https安全傳輸，也沒有對傳輸數據進行防篡改，如以下幾種場景：
傳輸過程沒有使用Https
傳輸過程使用了Https，但是對Https的證書沒有做正確校驗。
傳輸過程沒有使用Https，也沒有對數據做防篡改。
整個傳輸過程是明文可見的:
加載補丁后正常顯示：
之后我們新建一個下發的更新補丁：
Apple默認是不允許調用私有api的(在App上線時會經過App Store的審查)，但是在使用了JSPatch引擎后，可以直接調用私有的Api來獲取設備私密信息。
這里加載了一個Accounts.framework, 用來獲取設備中的帳號信息。
替換遠程加載的Js：
之后成功利用JSPatch更新了客戶端的代碼，讀取出設備的帳號信息:46個
46個帳號被顯示在App中。
此外還有很多private frameworks 可以拿來調用，當然這只適合越獄手機了，這種權限是很可怕的。
二 惡意的第三方SDK
同傳輸過程安全一樣，第三方的SDK極大的擴展了App的功能，但是不能保證這些SDK的開發者不存在惡意的開發者，惡意的SDK可以利用JSPatch下發惡意腳本，利用App的權限竊取敏感數據或者對系統做一些敏感操作。
三 本地篡改下載更新的javascript腳本
如果下載到了本地更新腳本沒有做加密，通過篡改本地的更新補丁，可以修改為執行任意OC代碼的js腳本，同樣可以執行任意代碼。
0x03 其他面臨的風險
補丁傳輸安全
在使用JSPatch時一定要注意傳輸過程的安全，使用Https傳輸，或使用作者推薦的RSA檢查下發的JS補丁，或者使用作者提供的Loader。
第三方SDK
在使用第三方的SDK時需要注意檢查是否嵌入了JSPatch，防止利用App的權限來對系統做一些壞事，或者竊取App的用戶信息。
本地存儲
更新補丁在本地存儲時需要對存儲的補丁做加密，防止數據被篡改造成代碼執行。
參考文獻
- www.fireeye.com/blog/threat…
- github.com/bang590/JSP…
)
