iOS ZipperDown 漏洞來襲，我們該如何應對？

昨天傍晚盤古實驗室負責任的披露了針對 iOS 應用的ZipperDown漏洞，並提供了檢索、查詢受影響應用的平台：zipperdown.com。基於目前公開的信息，該漏洞的影響面比較大，15000 多個應用可能受此漏洞影響。並且，結合應用中的其它安全缺陷，可以在某些應用上獲得遠程任意代碼執行能力，即：遠程控制目標應用，危害也較大。由於目前官方沒有公開 ZipperDown 的詳細信息，所以這裡會跟大家分享、探討一下針對 iOS 應用的防守策略以及針對具體功能點的防守方法。

出發點與基本策略

我們談的主要是防守，談防守就要基於一定的信任基礎，如果什麼都不可信，那也就沒法做防守了。再具體一點，我們現在談的是 iOS App 的防守，我們信任的基礎是 iOS，即：iOS 系統及服務是可信的，他們的安全性是完整的，沒有被破壞的。

對於 iOS 應用而言，操作系統提供的最基本、最重要的安全特性是：代碼簽名、沙盒。代碼簽名是指：iOS 上只能運行由蘋果簽名的代碼。沙盒是一種限制程序行為的安全特性，其中包括對程序可以訪問的文件的限制，如：App1 無法訪問 App2 存儲的數據文件。

除了代碼簽名與沙盒，iOS 上還有其它的一些安全特性或者安全功能，比如：Keychain、用戶數據加密等。我們做防守時一定要充分利用現有的安全功能與安全特性，換句話說就是：充分利用蘋果提供的資源，這樣可以大大降低我們的防守成本，這就是第一條防守策略：盡量基於現有的防禦陣地來搭建我們自己的防線。

防守的第二條策略是：要搭建防線。搭建防線，換句話說就是：沒有銀彈，沒有什麼單一的防禦點可以從整體上保證我們的 App 的安全。以本地存儲為例，從 iOS 8.4 之後，沒法導出單個應用的存儲在設備上的文件，那我們還用不用對 App 存儲到本地的數據進行加密？對於我們公司的產品，我們是要求加密的，原因是：如果不加密，我們就依賴於 Bundle 不可導出這個安全特性，但是 Bundle 真的不可導出嗎？！有沒有辦法繞過？實際上是有辦法繞過的，我們還可以通過備份手機進而獲得應用的數據。所以，如果做了本地數據加密，可以將這個理解為增加了一條防線，那應用就可以抵禦後一種攻擊方式。

防守的第三條策略是：要持續的、牢牢的抓住主要「矛盾」。對於 iOS 應用而言，我們認為主要矛盾是：遠程代碼執行。遠程代碼執行的前提是攻擊者可以遠程的將攻擊 Payload 投放到 iOS 應用中。對於投遞惡意 Payload，首先想到的方式是中間人攻擊（MitM）。為了避免 MitM，我們要求 App 與伺服器的通信使用 HTTPS，並且需要正確的校驗證書，這問題我們一直在抓，因為控制住了 HTTPS 就可以大大的降低程序的遠程攻擊面。在 HTTPS 之後，我們會重點關注用戶可以產生內容的 App，這樣又可以將攻擊面降低。

防守的第四條策略是：盡量避免因為業務功能而將安全降維。這裡的典型例子就是腳本能力（或者說熱補能力），前面我們提過 iOS 平台的一個重要安全特性就是代碼簽名，由於代碼簽名特性、地址隨機化特性、iOS App 通信特點（由 App 通過 HTTP 的方式請求 Server 上的數據），遠程的在 iOS App 上獲得穩定的任意代碼執行是非常困難的。而腳本能力恰恰破壞了系統中基本的、重要的代碼簽名安全特性，可以幫助攻擊者獲得穩定的遠程代碼執行能力，從而將 App 的防禦能力降維。

前面有點零散的談了我們對 iOS App 防守的理解以及防守的一些基本策略，下面我們以具體功能點為維度談談如何做防守。

具體功能點的防守方法

資料庫文件安全

安全場景描述

移動應用程序中通常會使用 SQLite 資料庫來存儲應用數據，而資料庫本身一般存儲在沙盒文件中。儘管在 iOS 8.4 之後，已經無法訪問沙盒裡面的用戶數據，但是在 8.4 以前的設備或者是越獄設備上，資料庫文件可以輕易地通過助手類工具導出。

如果資料庫裡面存儲的數據沒有進行複雜的加密處理，會是應用程序有敏感信息泄漏的風險，同時也有助於攻擊者進行逆向分析。

安全加固實施建議

使用較複雜的加密加鹽演算法對敏感數據加密後存儲。

NSUserDefaults 安全

安全場景描敘

保存用戶信息和屬性的一個非常普通方法就是使用 NSUserDefaults。保存在 NSUserDefaults 中的信息在應用關閉後再次打開依然存在。加之 NSUserDefaults 的使用介面非常方便，導致開發人員有可能不加以區別的把數據存放到 NSUserDefautls 中。

事實上保存到 NSUserDefautls 中的數據是沒有加密的，可以很輕易地從沙盒中找到。NSUserDefautls 被存儲在一個以應用 Bundle ID 為名稱的 Plist 文件中。

安全加固實施建議

重要的敏感數據存儲在 Keychain 中。

Keychain 安全

安全場景描敘

iOS 設備中的 Keychain 是一個安全的存儲容器，可以用來為不同的應用保存敏感信息比如用戶名、密碼、網路密碼、認證令牌。蘋果用 Keychain 來保存 Wi-Fi 網路密碼、VPN 憑證等等。它是一個 SQLite 資料庫，位於 /private/var/Keychains/keychain-2.db，其保存的所有數據都是加密過的。Keychain 在沙盒之外 App 會將部分重要數據存放在 Keychain 中使用進行讀取，但若寫入後未清楚就卸載 App 而下一位用戶安全 App 時未清除數據，則可能到導致下次安全的時候直接從 Keychain 中讀取密碼登陸或手勢密碼無法解除等問題。

安全加固實施建議

首次安裝應用程序啟動後，進行刪除 Keychain 數據操作。

後台快照

安全場景描敘

iOS 系統在程序退出的時候，會保存程序當前的快照到/Library/Caches/snapshots 中，如果退出的時候頁面含有密碼等關鍵信息未進行處理則會導致安全隱患。

安全加固實施建議

UIApplication 的委託方法 applicationDidEnterBackground: 可用於響應 App 進入後台並且修改敏感數據顯示。例如，在進入後台的時候，把特殊字元用「hidder」屬性隱藏。

Cookie 安全

安全場景描敘

Cookie 是 App 或者網站為了辨別用戶身份，進行 Session 跟蹤而存儲在用戶本地終端上的數據。如果 Cookie 以明文的形式存儲，那是非常危險的。iOS 上的 Cookie 數據會被保存在 /Library/Cookies/Cookies.binarycookies 中。在越獄設備或者iOS 8.4版本之前的設備上，這個數據是可以被導出並且通過工具 Dump 數據出來的。

安全加固實施建議

1、Cookie 存放前進行較複雜的加密運算。

2、將一部分 Cookie 加密存放在 Keychain 中，增加逆向難度。

HTTPS 安全

安全場景描敘

在 iOS 應用程序中，使用 HTTPS 進行通信是一種更為安全的做法，也是官方所推薦的做法。但是即使使用了 HTTPS，也有可能因為沒有校驗伺服器證書的原因導致被中間人劫持。如果交互請求數據處理不當，攻擊者可以解密得到明文通信數據；甚至進一步偽造 App 的請求，這是極大的安全隱患。

安全加固實施建議

1、App 內要對 HTTPS 證書做校驗。

2、避免使用有漏洞的第三網網路庫(如 AFNetworking

3、關鍵數據(如登錄密碼、卡號、交易密碼等)單獨加密。

WebView 安全

安全場景描敘

在 iOS 應用程序中，WebView 是經常使用到的一個控制項，用來載入網頁顯示在終端上，因跨平台、動態等特性被廣泛使用。但是與此同時，很多桌面瀏覽器前端漏洞在 iOS 終端上仍然存在。

同時因為 iOS 終端上， WebView 可以註冊一些敏感信息數據，比如發簡訊、付款、定位信息等等，也帶來了一些新的安全風險。

安全加固實施建議

1、對輸入進行過濾和編碼。

2、服務端對 App 發送的數據進行過濾和編碼。

3、盡量減少敏感介面的註冊、盡量不要載入第三方內容；如果載入，則必須在 WebView 的 Delegate 方法中，通過白名單機制實現對調用者的檢驗。

加密演算法

安全場景描敘

在 iOS 應用程序中，經常存在敏感數據需要加密存儲的場景。例如登陸密碼、通訊錄數據等，其加密演算法被破解是相當危險的。一旦重要的演算法被攻擊者逆向，應用的一切數據就相當於毫無保留的展現在攻擊者面前。

安全加固實施建議

1、對稱加密演算法要使用 AES、DES 或 3DES，避免使用 RC4 等目前可能被爆破的演算法。

2、對於數據安全性要求較高的場景並且條件允許的情況下，使用非對稱加密演算法如 RSA 等。

3、對稱加密演算法的 KEY 和 IV，應避免硬編碼。若加密數據僅是本地存儲，可基於設備相關的信息來生成 KEY 和 IV。

開發環境安全

安全場景描敘

開發人員可能會從非官方渠道下載開發環境或者開發工具。被修改過的惡意開發工具可能會在打包 IPA 文件時，插入惡意代碼。

另外，由於配置不當，打包 IPA 文件時，可能會把源碼或者開發文檔打包進入 IPA。

安全加固實施建議

1、從官方下載開發工具 Xcode。

2、打包 IPA 文件時，管理好 Xcode 的 Build Phases、Copy Bundle Resources。

系統日誌輸出安全

安全場景描敘

開發過程中通常會使用 NSLog 來輸出日誌，用於調試 Bug 和測試功能。因此在列印出來的 Log 中很容易會泄漏程序的關鍵邏輯和用戶敏感數據，降低了逆向破解的難度，增加了敏感信息泄漏的風險。

如果 Release 包裡面沒有關閉系統日誌，通過 Xcode Device 等工具，可以很容易地看到應用程序 Log 的列印。

安全加固實施建議

1、使用宏來控制測試版和發布版本的日誌輸出。

2、安全測試和對外發布時使用 Release 版本，關閉日誌輸出。

團隊介紹

360 涅槃團隊（Nirvan Team）

隸屬於 360 公司信息安全部，主要負責公司所有 iOS App 的安全，同時進行蘋果平台相關的安全研究，包括：操作系統層面的漏洞挖掘與利用；在工程中提升攻防效率與生產力的方法與工具。該團隊在蘋果系統中發現了大量漏洞，多次獲得蘋果官方致謝。該團隊積极參与社區分享，發表大量技術文章，並多次在國內外的安全會議上發表主題演講，分享相關的研究成果。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！