蒸米，白小龍 @ 阿里基礎安全研究
0x00 序
盤古實驗室在針對不同客戶的iOS應用安全審計過程中，發現了一類通用的安全漏洞。該漏洞被發布在了[1]。經過盤古的分析，確認微博、陌陌、網易雲音樂、QQ音樂、快手等流行應用受影響，另外還有大約10%的iOS應用應用可能受此漏洞的影響。
根據漏洞名稱大概可以猜測出與zip文件有關，查詢iOS上與解壓相關資料可以看到，iOS並沒有提供官方的unzip API函數，基本上現有的iOS app都是使用的SSZipArchive或ziparchive這兩個第三方庫來實現解壓的功能。隨後根據盤古在SSZipArchive項目的issue中提交的漏洞報告[2]可以大概確定漏洞原理是：使用第三方zip庫在解壓zip文件過程中沒有考慮文件名中帶有」../../」這樣的情況，從而產生了目錄穿越漏洞。因此，如果一個iOS 應用下載了惡意的zip文件，並且使用ziparchive庫解壓，利用漏洞可以做到app container目錄下的任意文件覆蓋，如果覆蓋了應用重要的文件會造成應用崩潰（DOS），如果覆蓋了app的hotpatch文件則會造成代碼執行。
0x01 構造惡意的ZIP文件（POC）
（因為很多app並沒有修復該漏洞，因此POC暫不公布，想要了解細節的同學可以聯繫阿里巴巴SRC）▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇
0x02 復現攻擊
正常情況下，應用會在啟動或者某些情況下會執行hotpatch的js腳本。在我們用來demo的應用中需要點擊一下」Run Hotpatch」來運行js腳本：
點擊完後，應用會加載自己目錄下的「/Library/Caches/hotpatch/patch.js」並執行：
隨後我們點擊「Download and Unzip」，應用會通過http下載一個zip包到本地，並使用SSZipArchive庫進行解壓，如果我們採用DNS劫持將正常的zip包替換為惡意的zip包的話，雖然程序會將zip解壓到download目錄，但是我們成功利用目錄穿越漏洞，讓patch.js解壓到了如下位置：/Library/Caches/download/../hotpatch/patch.js，並成功將正常的patch.js給替換成了惡意的patch.js：
演示DEMO：https://v.qq.com/x/page/a0655dtirv7.html
0x03 防禦方案
最完整的解決方案是對SSZipArchive庫進行修補，在解壓函數：
+ (BOOL)unzipFileAtPath:(NSString *)path toDestination:(NSString *)destination preserveAttributes:(BOOL)preserveAttributes overwrite:(BOOL)overwrite nestedZipLevel:(NSInteger)nestedZipLevel password:(nullable NSString *)password error:(NSError **)error delegate:(nullable id<SSZipArchiveDelegate>)delegate progressHandler:(void (^_Nullable)(NSString *entry, unz_file_info zipInfo, long entryNumber, long total))progressHandler completionHandler:(void (^_Nullable)(NSString *path, BOOL succeeded, NSError * _Nullable error))completionHandler
中對最終解壓的strPath進行檢測，如果出現可能造成目錄穿越的」../」字符串時進行攔截。
另外，Hotpatch包除了傳輸過程中要加密外，在本地也需要加密保存，並且運行前做完整性校驗。雖然漏洞覆蓋某些重要的文件可能會造成拒絕服務攻擊，但至少不會造成代碼執行。
0x04 總結
正如JSPatch的作者bang所講的：「攻擊條件：1.APP用了ZipArchive 2.原APP下發的某個zip包傳輸過程沒加密，zip包也沒加密 3.原APP使用了JSPatch或其他執行引擎，且本地腳本沒有加密，只要把腳本放指定目錄即可執行 4.用戶連上第三方wifi遭受攻擊。恰好視頻中的微博滿足這些苛刻條件。危害很小，能被攻擊的APP也很少。」
因此，能夠造成代碼執行的應用可能沒有想像中那麼多，但黑客依然有可能利用任意文件覆蓋的漏洞能力對應用進行攻擊，造成意想不到的效果。
0x05 參考資料
https://zipperdown.orghttps://github.com/ZipArchive/ZipArchive/issues/45