前言

此前有人統計過2015年漏洞最多的産品，蘋果的OSX與iOS系統分别占據第一二名，雖有人懷疑統計數據可能存在重複的不準确情況，但相信大趨勢是不會變的。

2015年在iOS平台上也發生過不少安全大事，比如“XcodeGhost”事件、iOS9越獄、“iBackDoor“、“YouMi“事件等等，尤其是XcodeGhost影響甚大，注定要在iOS安全史上留下重重的一筆。

結合CVEDetails站點上對iOS系統漏洞的統計情況【圖1】，整體處于上升的趨勢，尤其是2015年增長迅速，是2014年的3倍多，由此也可以預見iOS平台上的安全漏洞正在快速增長，iOS應用亦然。

騰訊也有很多iOS應用産品，基本上android上有的，對應的同款應用在iOS上也會有。目前Android應用的審計技術在業界都已經于相對成熟，而iOS應用漏洞審計系統在國内還是比較欠缺的，一些公司可能内部有開發，隻是未公開。

此前騰訊iOS産品也是未能做有效的上線前審計，遺留一些安全隐患，因此我們專門研發了一款針對iOS應用的自動化審計系統。除了日常的應用審計外，同時也是希望它能夠在安全應急上起到輔助的作用。本文主要是對這部分技術進行一些粗淺的探索，以希望可以起到抛磚引玉的效果。

開發環境

• Mac OSX 10.11

• Python 開發環境：PyCharm5

• Objective-C 開發環境：Xcode7 iOSOpenDev

•支持 iOS 8.1 以上的越獄系統

系統架構

整個iOS應用審計系統主要分兩部分：靜态審計和動态審計【圖2】。靜态審計包括Bin文件漏洞審計、第三方庫檢測以及私有api靜态檢測等功能;動态審計主要通過hook去監控網絡數據包、SSL中間人檢測，以及實現ipa的動态安裝和運行、文件上傳下載等基本功能。

基本審計功能

通過靜态審計提取基本的文件信息，并以較好的展示效果輸出到報告頁面上【圖3】，也方便後面的二次掃描，以及鑒别不同的ipa文件。

在靜态審計裡最重要的就是Bin文件漏洞檢測功能【圖4】，像編譯選項和使用函數的信息，借助otool即可很容易檢測。

應用漏洞檢測主要針對目前已公開的漏洞/惡意後門進行檢測，比如XcodeGhost、iBackDoor、AFNetworking等等，先通過分析樣本來制定靜态檢測規則，多數通過關鍵字符串即可檢測出，而對于AFNetworking SSL中間人漏洞，筆者是采用檢測漏洞相關的ARM指令。

下面是AFNetworking某個漏洞版本的ARM指令【圖5】，不同版本會有一定差異，所以還是需要對比多個不同版本，提取通用的檢測規則(單純檢測下圖标紅的ARM指令會誤報)。除此之外，還要對比修複版本的代碼，避免誤報。

由于iOS應用為了兼容性，都會包含32位與64位程序，很少會單純隻使用64位編譯的應用，所以檢測時可以暫不用考慮64位問題。

除圖4上的應用漏洞之外，還支持自定義審計功能【圖6】，主要是為了在應急時，可以及時即時制定規則進行批量掃描【圖7】，我們也專門針對公司業務情況添加了一些規則，此處就不贅述了。

上面【圖6】隻是一份示例的規則，并非在系統上實際運用的，隻是作為演示，它支持二進制、數據庫及文件的掃描，裡面可以使用linux命令去輔助檢測，當然你也可以笑稱它為“後門”。

另外，數據存儲安全和網絡傳輸安全都在動态審計部分完成，審計規則在自定義規則裡面定義的。其中網絡實時檢測功能主要是基于Hook實現的，針對發包函數進行監控，比如NSURLConnection:sendSynchronousRequest或者UIApplication:openURL等等【圖8】。

程序會實時監聽HTTP、HTTPS甚至是自定義僞協議的請求，而且為方便後續測試會記錄cookie值，然後完整地輸出到報告上【圖9】，後續也可以把它導入掃描器作WEB漏洞掃描。

由于著名第三方庫AFNetwork經常被使用，因此也增加了對它的網絡監控。

UI界面遍曆

為了觸發更多地程序邏輯，增加代碼覆蓋率，在動态檢測時，就需要去遍曆各個UI界面。對于這種情況，我們選用appcrawler工具進行UI遍曆，它同時支持Android與iOS應用，而在其提供的config.json配置文件裡面，可根據自身需要去靈活配置，比如遍曆的深度，匹配文本框關鍵字進行輸入(如登錄帳号)，這些規則需要自己多測試應用去完善它。【圖10】是遍曆微信UI的部分截圖效果，由于隻遍曆了10分鐘，所以截圖相對較少一些，整體效果還是不錯的。

SSL中間人檢測

在移動APP中，無論是Android還是iOS平台，SSL中間人攻擊都是一種常見漏洞，經常是由于證書校驗不嚴謹導緻的。雖然是中間人攻擊，但在一定場景下還可以造成很大的危害，尤其是金融場景下的公共WiFi。

針對SSL中間人漏洞，如果采用靜态代碼檢測，可能誤報率會比較高，筆者在此處是通過Hook做靜态檢測，在運行時注入證書異常站點的請求，然後再去檢測是否訪問成功

以QQ浏覽器HD為例，注入異常站點後會彈出【圖12】中的提示，說明不會自動連接此站點，因此不存在SSL中間人漏洞。

不過對于使用第三方SSL庫的應用可能會漏報，另一種替代方案是使用證書替換的檢測方式，不過這會導緻訪問異常，最終可能導緻應用無法正常使用，後續的審計動作也将被中止。各有各的弊端，可以暫時兩者分開地使用，如果各位同仁有更好的檢測方法，也歡迎在下面回複讨論。

私有API檢測

雖說調用私有API不算漏洞，但因為蘋果嚴格的審計機制，一經發現調用私有API會直接下架應用，對業務影響也是很大。

另外從安全角度看，如果應用的漏洞修複版本需要發布，但多次因為調用私有API也被蘋果官方拒絕上架，就會導緻漏洞無法得到及時的修複。

檢測私有API的難點主要在于蘋果未公開這份私有API列表，因此在檢測時隻能自己提取，但也導緻會因此存在一定的漏報和誤報的情況。

網絡上有個提取私有API的公式：

1 私有的api =(class-dump Framework下的庫生成的頭文件中的api - (Framework下的頭文件裡的api = 有文檔的api 沒有文檔的api)) PrivateFramework下的api

其實這是不完全正确的，如果你單純按照這種方法提取，會出現很高的誤報和漏報情況。因為私有類裡面有公有API，公有類裡面有私有API。但上面的公式是提取私有API的第一步，之後就需要再做很多提取規則逐步完善，比如一些純小寫字母的api，大多是一些c庫函數，可以再過濾一大批。

這種沒有什麼特别好的方法，隻能多掃應用，根據結果多優化規則。

Github上面也有用于檢測私有API的開源項目，但基本上沒有一個可以滿足測試需求的，誤報率和漏報率太高，而且支持iOS版本較低。iOS9 SDK以上版本，也不能直接使用classdump去提取頭文件，因為應用的符号表已經被去掉這些信息，筆者是采用nm去解決的。

最初筆者是打算把動态檢測私有API也做了，但後面考慮審計系統主要是面向公司内部，因此不存在那種惡意繞過私有API檢測的行為，然後就把寫了一半的動态檢測功能給注釋掉。

如果讀者要做動态檢測私有API，那麼誤報和性能就是首要考慮的問題。hook太深，則消息過多，時耗過多，而且有些是系統自身調用的私有API，就無法正确區分是應用還是系統調用的;hook太淺，又達不到效果，沒法監測到私有API的行為。這裡抛張動态檢測的半成品截圖【圖13】，大家可以繼續發揮。

為了提高靜态檢測的準确率，筆者就把靜态拼接API字符串的情況也支持【圖14】，因為正常情況下，兩個字符串都是相鄰的，組合起來再與私有API庫作比較即可。

好了，說了這麼多，直接上一張實戰圖。下面【圖15】是針對去年曝光的一款iOS病毒TinyV做的檢測(感謝ClaudXiao分享的樣本)，可以看到它調用LSApplicationWorkspace和MobileInstallation中的私有API去查看安裝程序列表，安裝和卸載應用。

第三方庫檢測

有時外界會曝光一些第三方開源庫的漏洞，影響經常是跨平台的，包括iOS應用。因此我們專門收集上百個常用第三方庫信息作為檢測内容，在日常審計應用時，能夠維護一份哪些公司産品使用到哪些第三方庫的信息【圖16】，在外部曝光漏洞後，我們可以快速定位受影響的産品及危害範圍。

不過目前缺乏相應的版本信息，因為有些庫編譯出來後是不帶版本字符串，需要針對不同版本作指紋庫檢測，也是個不少工程量，如果業界有好心人願意造福群衆的話，可以試試做個第三方庫的指紋庫出來。

開放端口檢測

之所以做開放端口檢測這個功能，主要是基于此前曝光的“WormHole”漏洞，此類因開放端口導緻的安全漏洞，在Android應用上已經有過不少案例，搜索烏雲就能找到。

檢測開放端口其實一條命令就足夠了，然後定期輪循即可：

lsof -i | grep ‘” appname ”‘ | awk ‘{print$1,$8,$9,$10}’

直接上效果圖，如【圖17】所示

審計效果

我們随機抽取了公司60款iOS應用，審計後共發現10款産品存在中高危漏洞【圖18】，其中主要是SSL中間人漏洞和授權密鑰洩露漏洞居多。

後記

本文主要針對筆者在開發iOS應用自動審計系統時運用的一些技術作個分享，希望能起到抛磚引玉的作用。系統本身也還有一些有待完善的地方，歡迎各位業界同仁共同交流探讨。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!