【安天】Xcode非官方版本惡意代碼污染事件（XcodeGhost）的分析與綜述

時間 2019-12-08

標籤安天 xcode 非官方版本惡意代碼污染事件 xcodeghost 分析綜述欄目 iOS 简体版

原文原文鏈接

SwordLea · 2015/09/24 14:02git

微信公衆號:Antiylabgithub

0x00 摘要

Xcode 是由蘋果公司發佈的運行在操做系統Mac OS X上的集成開發工具（IDE），是開發OS X 和 iOS 應用程序的最主流工具。swift

2015年9月14日起，一例Xcode非官方版本惡意代碼污染事件逐步被關注，併成爲社會熱點事件。多數分析者將這一事件稱爲「XcodeGhost」。攻擊者經過對Xcode進行篡改，加入惡意模塊，並進行各類傳播活動，使大量開發者使用被污染過的版本，創建開發環境。通過被污染過的Xcode版本編譯出的App程序，將被植入惡意邏輯，其中包括向攻擊者註冊的域名回傳若干信息，並可能致使彈窗攻擊和被遠程控制的風險。安全

本事件由騰訊相關安全團隊發現，並上報國家互聯網應急中心，國家互聯網應急中心發出了公開預警，此後PaolAlto Network、360、盤古、阿里、i春秋等安全廠商和團隊機構，對事件進行了大量跟進分析、處理解讀。目前，已有分析團隊發現著名的遊戲開發工具Unity 3D也被同一做者進行了地下供應鏈污染，所以會影響更多的操做系統平臺。截止到本版本報告發布，還沒有發現「XcodeGhost」對其餘開發環境的影響，但安天分析小組基於JAVA代碼和Native代碼的開發特色，一樣發出了相關風險預警。服務器

截止到2015年9月20日，各方已經累計發現當前已確認共692種（如按版本號計算爲858個）App曾受到污染，受影響的廠商中包括了微信、滴滴、網易雲音樂等著名應用。微信

從肯定性的行爲來看，儘管有些人認爲這一惡意代碼竊取的信息「價值有限」，但從其感染面積、感染數量和可能帶來的衍生風險來看，其多是移動安全史上最爲嚴重的惡意代碼感染事件，目前來看惟有此前臭名昭著的CarrierIQ能與之比肩。但與CarrierIQ具備強力的「官方」推廣方不一樣，此次事件是採用了非官方供應鏈（工具鏈）污染的方式，其反應出了我國互聯網廠商研發「野蠻生長」，安全意識低下的現狀。長期以來，業界從供應鏈角度對安全的全景審視並不足夠，但供應鏈上的各個環節，都有可能影響到最終產品和最終使用場景的安全性。在這個維度上，開發工具、固件、外設等「非核心環節」的安全風險，並不低於操做系統，而利用其攻擊的難度可能更低。所以僅關注供應鏈的基礎和核心環節是不夠的，而同時，咱們必須高度面對現實，深入分析長期困擾我國信息系統安全的地下供應鏈問題，並進行有效地綜合治理。網絡

0x01 背景

Xcode是由蘋果公司開發的運行在操做系統Mac OS X上的集成開發工具（IDE），是開發OS X 和 iOS 應用程序的最快捷的方式，其具備統一的用戶界面設計，同時編碼、測試、調試都在一個簡單的窗口內完成。【1】app

自2015年9月14日起，一例Xcode非官方供應鏈污染事件在國家互聯網應急中心發佈預警後，被普遍關注，多數分析者將這一事件稱之爲「XcodeGhost」。攻擊者經過對Xcode進行篡改，加入惡意模塊，進行各類傳播活動，使大量開發者獲取到相關上述版本，創建開發環境，此時通過被污染過的Xcode版本編譯出的App程序，將被植入惡意邏輯，其中包括向攻擊者註冊的域名回傳若干信息，並可能致使彈窗攻擊和被遠程控制的風險。框架

截止到2015年9月20日，各方已經累計發現共692種（如按版本號計算爲858個）App確認受到感染。同時，有分析團隊認爲，相同的攻擊者或團隊可能已經對安卓開發平臺採用一樣的思路進行了攻擊嘗試。從其感染面積、感染數量和可能帶來的衍生風險來看，其多是移動安全史上最爲嚴重的惡意代碼感染事件之一，從影響範圍上來看能與之比肩的僅有此前臭名昭著的CarrierIQ]【2】。運維

目前，Unity 3D也被發現由同一做者採起攻擊Xcode手法相似的思路進行了地下供應鏈污染。

鑑於此事態的嚴重性，安天安全研究與應急處理中心（Antiy CERT）與安天移動安全公司（AVL Team）組成聯合分析小組，結合自身分析進展與兄弟安全團隊的分析成果，造成此報告。

0x02 做用機理與影響

安天根據Xcode非官方供應鏈污染事件的相關信息造成了圖2-1，其總體污染路徑爲官方Xcode被攻擊者植入惡意代碼後，由攻擊者上傳到百度雲網盤等網絡位置，再經過論壇傳播等方式廣播下載地址，致使被App開發者獲取，同時對於攻擊者是否利用下載工具經過下載重定向方式擴大散佈，也有較多猜想。有多個互聯網公司採用被污染過的Xcode開發編譯出了被污染的App，並將其提交至蘋果App Store，且經過了蘋果的安全審覈，在用戶獲取相關App進行安裝後，相關應用會被感染並回傳信息至攻擊者指定域名。

圖2‑1 Xcode非官方供應鏈污染事件示意圖

2.1 做用機理

2.1.1 樣本信息

文件名：CoreService

位於Xcode位置：（iOS、iOS模擬器、MacOSX三個平臺）

./Developer/Platforms/iPhoneOS.platform/Developer/SDKs/Library/Frameworks/CoreServices.framework/CoreService
./Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/Library/Frameworks/CoreServices.framework/CoreService
./Developer/Platforms/MacOSX.platform/Developer/SDKs/Library/Frameworks/CoreServices.framework/CoreService
複製代碼

樣本形態：庫文件（iOS、iOS模擬器、MacOSX三個平臺）
表2‑1 樣本信息

2.1.2 感染方式

2.1.2.1攻擊機理

此次攻擊本質上是經過攻擊Xcode間接攻擊了自動化構建和編譯環境，目前開發者不管是使用XcodeServer仍是基於第三方工具或自研發工具都須要基於Xcode。而此次如此大面積的國內產品中招，則只能反映大量產品研發團隊在產品開發和構建環境的維護以及安全意識上都呈現出比較大的問題。

圖2‑2 基於Xcode的開發流程（第三方圖片）【4】

1. 惡意插件植入Xcode方式

也許出於對Xcode穩定性和植入方便性的考慮，惡意代碼實際並無對Xcode工具進行太多修改，主要是添加了以下文件：

針對 iOS
- Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/Library/Frameworks/CoreServices.framework/CoreService
- Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/Library/PrivateFrameworks/IDEBundleInjection.framework
針對 iOS 模擬器
- Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/Library/Frameworks/CoreServices.framework/CoreService
- Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/Library/PrivateFrameworks/IDEBundleInjection.framework
針對 Mac OS X
- Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/Library/Frameworks/CoreServices.framework/CoreService
- Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/Library/PrivateFrameworks/IDEBundleInjection.framework

以及修改了配置文件：

Xcode.app/Contents/PlugIns/Xcode3Core.ideplugin/Contents/SharedSupport/Developer/Library/Xcode/Plug-ins/CoreBuildTasks.xcplugin/Contents/Resources/Ld.xcspec

2.惡意插件植入App方式

被攻擊的開發環節：編譯App項目部分；
惡意代碼植入機理：經過修改Xcode配置文件，致使編譯Linking時程序強制加載惡意庫文件；
修改的配置文件：Xcode.app/Contents/PlugIns/Xcode3Core.ideplugin/Contents/SharedSupport/Developer/Library/Xcode/Plug-ins/CoreBuildTasks.xcplugin/Contents/Resources/Ld.xcspec
添加的語句：「-force_load$(PLATFORM_DEVELOPER_SDK_DIR)/Library/Frameworks/CoreServices.framework/CoreService」

圖2‑3 受感染Xcode與官方版本配置文件對比

2.1.2.2 惡意代碼運行時間

惡意代碼植入位置：UIWindow (didFinishLaunchingWithOptions)；
惡意代碼啓動時間：App啓動後，開啓準備展現第一個頁面時惡意代碼已經執行了；
iOS應用啓動流程：從代碼執行流程來看，圖2-4中每一步均可以做爲惡意代碼植入點，且其框架基本都是由模板自動生成，而UIWindow爲iOS App啓動後展現頁面時執行。

圖2‑4 iOS應用啓動流程（第三方圖片）【5】

UIWindow生成方式：一般經過模板創建工程時，Xcode會自動生成一個Window，而後讓它變成keyWindow並顯示出來；因爲是模板自動生成，因此不少時候開發人員都容易忽略這個UIWindow對象，這也是這次Xcode被植入惡意代碼位置的緣由之一。
惡意代碼啓動時機分析：惡意代碼植入於UIWindow (didFinishLaunchingWithOptions)中，其入口點爲： __UIWindow_didFinishLaunchingWithOptions\__makeKeyAndVisible_；UIWindow是做爲包含了其餘全部View的一個容器，每個程序裏面都會有一個UIWindow；而didFinishLaunchingWithOptions裏面的代碼會在UIWindow啓動時執行，即被感染App在啓動時的開始準備展現界面就已經在執行被植入的惡意代碼了。

圖2‑5 惡意插件植入的代碼入口點

2.1.3 危害分析

2.1.3.1 上傳隱私

惡意代碼上傳的信息主要有：時間戳、應用名、包名、系統版本、語言、國家、網絡信息等；同時還有被感染App的運行狀態：launch、runing、suspend、terminate、resignActive、AlertView。

全部信息經過DES加密後POST上傳到服務器：

init.icloud-analysis.com
init.crash-analytics.com
init.icloud-diagnostics.com

其中6.0版本URL爲字符串形式，而到7.0版本URL則進化到字符拼接，7.0版本中還能夠獲取應用剪貼板信息。

圖2‑6 獲取上傳的信息

圖2‑7 6.0版本中URL爲字符串形式

圖2‑8 7.0版本中URL字符拼接形式

圖2‑9 7.0版本獲取應用剪貼板信息

2.1.3.2 任意彈窗

惡意代碼能夠遠程設置任意應用的彈窗信息，包括彈框標題、內容、推廣應用ID、取消按鈕、確認按鈕；須要注意的是該部分代碼並無使用輸入框控件，同時也並沒有進一步的數據回傳代碼，所以是不能直接高仿僞造系統彈窗，釣魚獲取Apple ID輸入和密碼輸入的（這點在諸多已公開分析報告中均有必定誤導性）。

圖2‑10 遠程設置彈窗信息

可是因爲彈窗內容能夠任意設定，攻擊者徹底可使用彈窗進行欺詐通知。

2.1.3.3 遠控模塊

1.OpenURL遠控

惡意代碼包含了一個使用OpenURL的遠控模塊，該模塊能夠用來執行從服務器獲取到的URL scheme，其使用canOpenURL獲取設備上定義的URL scheme信息，並從服務器獲取URL scheme經過OpenURL執行。

圖2‑11 canOpenURL獲取信息，執行從服務器獲取的URLscheme

2.URL scheme能力

URL scheme功能強大，經過OpenURL可用實現不少功能；但須要注意的是，URL scheme所能達到的功能與目標App權限有關，如撥打電話、發送短信須要被感染應用具備相應權限。但若是其餘App或系統組件有URL scheme 解析漏洞、Webview漏洞等，則能相應執行更多行爲。

因爲服務器已經關閉，同時該樣本也沒有明顯證據代表具體使用了哪些URL scheme，如下爲咱們分析的惡意代碼所能作到的行爲：

調用App
撥打電話
發送短信
發送郵件
獲取剪貼板信息
打開網頁，如打開高仿Apple的釣魚網站
結合彈窗推廣應用，App Store&企業證書應用皆可

圖2‑12 設置推廣應用appID和對應URL scheme

另外推廣應用時候，因爲彈窗全部信息皆可遠程設置，當把」取消「按鈕顯示爲」安裝「，」安裝「按鈕顯示爲」取消「，極易誤導用戶安裝推廣的應用。

2.1.4 中間人利用

雖然惡意代碼使用的域名已經被封，但因爲其通訊數據只是採用了DES簡單加密，很容易被中間人重定向接管全部控制。當使用中間人攻擊、DNS污染時，攻擊者只須要將樣本中服務器域名解析到本身的服務器，便可接管利用全部被感染設備，進而獲取隱私、彈窗欺詐、遠程控制等。

其中惡意代碼使用的DES密鑰生成比較巧妙，是先定義一個字符串」stringWithFormat「，再截取最大密鑰長度，即前八個字符「stringWi」。

DES標準密鑰長度爲56位，加上8個奇偶校驗位，共64bit即8個字節。

圖2‑13 DES密鑰生成方式

因此即使惡意代碼服務器已經失活，依然建議用戶及時更新被感染App版本，若仍未更新版本的App，建議當即卸載或儘可能不要在公共WiFi環境下使用，請等待新版本發佈。

2.2 影響面分析

截止到2015年9月22日凌晨3時，經過各安全廠商累計發現的數據顯示，當前已確認共692種（按照版本號計算858個）App受到感染，其中影響較大的包括微信、高德地圖、滴滴出行（打車）、58同城、豆瓣閱讀、凱立德導航、平安證券、網易雲音樂、優酷、天涯社區、百度音樂等應用的多個版本。（詳情請參見附錄三。）

注：須要說明的是，根據相關消息，這一事件是騰訊在自查中發現並上報給CNCERT的。

安天依託國內一份2014年度iOSTOP 200排行的信息【3】進行了App檢測，共發現有6款App受到影響，在表2-1中已用紅色字體突出顯示。

表2‑2 App Store Top200中受影響App統計，紅色爲受到影響軟件

目前，已有其餘分析團隊示警著名手機遊戲開發平臺Unity 3D也被同一做者植入了惡意代碼，與攻擊Xcode手法同樣，但安天分析小組沒有跟進分析。

0x03 擴散、組織分析

3.1 傳播分析

攻擊者使用了多個帳號，在多個不一樣網站或論壇進行傳播被植入惡意代碼的Xcode，如下是咱們對其傳播帳號及傳播信息的腦圖化整理：

圖3‑1 傳播馬甲關聯分析圖

被植入惡意代碼的Xcode由攻擊者上傳至百度雲網盤，而後經過國內幾個知名論壇發佈傳播，傳播的論壇包括：51CTO技術論壇、威鋒網論壇、unity聖典、9ria論壇和swiftmi。咱們經過跟蹤發現其最先發布是在「unity聖典」，進行傳播的時間爲2015年3月16日，攻擊者在每一個論壇的ID及所發的百度雲盤下載地址都不相同，詳情參見表3-1。

表3‑1 傳播論壇狀況

圖3‑2 做者百度雲網盤

以威鋒論壇傳播爲例，這個帖子自己是一箇舊帖，首次發佈於2012年，並在2015年6月15日進行最後編輯，做者用舊帖「佔坑」的目的，是爲了增長下載者對此帖信任度，如圖3-3。

圖3‑3 經過威鋒網傳播

此外，微博上有網友說Xcode傳播是經過迅雷下載重定向傳播，會致使輸入官方下載地址下載到錯誤版本，但後來同一網友又澄清是本身看錯了致使，並刪除了原帖。有關截圖參見圖3-四、圖3-5：

圖3‑4 證實截圖1微博發貼已刪

圖3‑5 證實截圖2微博發貼已刪

2015年9月19日該網友公開澄清是本身記錯了，誤把百度雲盤連接直接拷貝到迅雷下載地址裏了，如下是網友的公開聲明。

圖3‑6 網友澄清證實

但在地下社區中，確實一直存在針對迅雷污染，使迅雷下載到重定向惡意代碼的方法討論，並且因爲相似感染可能得到巨大的經濟利益，咱們並不能徹底排除這種下載污染，有可能經過流量劫持等方式來配合。同時亦有網友反饋迅雷存在直接下載和離線下載所獲得的文件大小不一樣的狀況。受時間所限，安天分析小組未對這些傳言進行進一步驗證。

3.2 攻擊者狀況猜想

此前根據相關安全團隊的信息檢索，認爲攻擊者多是X工業大學的一名學生。從攻擊者具有污染了多個平臺的開發能力，並已經肯定對iOS用戶產生了嚴重影響，開發能力覆蓋前臺、後臺，掌握社工技巧，具有SEO優化的意識。從其綜合能力來看，有可能不是個體做業，而是一個小的團伙、或者存在其餘方式協同的可能性。同時，根據相對可信的消息，相關雲資源使用者每個月向數據匯聚點亞馬遜支付數千美圓，其應該有較高的獲益。

但此前關於攻擊者的亞馬遜資費每個月數十萬美圓的猜想，咱們認爲有誤，由於亞馬遜從計費上是單向收費的，而相關猜想是雙向計算的。

3.3 開發環節的安全問題分析

致使大量原廠發佈的App遭到污染的重要緣由是，開發團隊未堅持原廠下載，也並未驗證所下載的開發工具的數字簽名。

咱們發現有不少分析團隊向開發者提供了完整的官方Xcode文件的Hash，但顯然直接對應用進行數字簽名驗證多是更高效的方法。

3.3.1 Mac&iOS app簽名方式

OS X和iOS應用使用相同的簽名方式，即：

在程序包中新建 _CodeSignature/CodeResources 文件，存儲了被簽名的程序包中全部文件的摘要信息；
使用私鑰 Private Key 對摘要進行加密，完成代碼簽名。

3.3.2 Mac上官方簽名工具codesign驗證App方式

Mac上可使用官方codesign工具對Mac&iOS App進行簽名驗證。

codesign工具屬於Xcode Command Line Tools套件之一，可使用以下方式獲取安裝，推薦使用一、2方式：

Terminal裏執行：Xcode-select –install；
Mac AppStore裏安裝；
安裝 brew 後執行 brew doctor 自動安裝；
在Developer Apple網站下載安裝：developer.apple.com/downloads/

圖3‑7 Developer Apple上的Command LineTools工具

3.3.2.1 獲取app簽名證書信息

使用codesign -vv-d xxx.app 指令能夠獲取app的簽名信息。

如驗證官方Xcode7.0，方框內Authority信息即該應用的證書信息，其中：

Authority=Apple Root CA，表示發佈證書的CA機構，又稱爲證書受權中心；
Authority=Apple WorldwideDeveloper Relations Certification Authority，表示證書的頒發中心，爲Apple的認證部門；
Authority=Apple Mac OSApplication Signing，表示證書全部者，即該應用屬於Mac App Store簽名發佈。

圖3‑8 官方Xcode7.0簽名信息

而驗證含XcodeGhost惡意插件的Xcode6.4應用，其全部者爲「Software Signing」，說明非Mac App Store官方渠道發佈。

圖3‑9 惡意Xcode簽名信息

3.3.2.2 驗證app的合法性

爲了達到給全部文件設置簽名的目的，簽名的過程當中會在程序包（即Example.app）中新建一個叫作 _CodeSignatue/CodeResources 的文件，這個文件中存儲了被簽名的程序包中全部文件的簽名。

使用codesign--verify xxx.app 指令能夠根據_CodeSignatue/CodeResources文件驗證App的合法性

校驗官方Xcode應用，驗證經過，將沒有任何提示。

圖3‑10 官方Xcode簽名校驗合法

校驗含XcodeGhost惡意插件的Xcode應用，驗證失敗，會出現提示，說明該應用在簽名以後被修改過。

圖3‑11 惡意Xcode簽名校驗失敗

3.3.3 官方推薦Xcode驗證工具spclt

鑑於此事件影響重大，蘋果官方於2015年9月22日發佈文章6推薦使用spclt工具校驗Xcode合法性。

圖3‑12 官方推薦使用spctl工具校驗Xcode合法性

如圖3-13，上面爲正版Xcode驗證信息，代表來源爲Mac App Store；而下面爲惡意Xcode工具驗證信息，沒有任何來源信息；

圖3‑13 使用spctl工具校驗Xcode來源

關於此前Xcode加載較慢的問題一直被詬病，其存在國內網絡設施方面的問題，但蘋果未投入足夠CDN資源也是一個因素。咱們注意到蘋果在申明中說起會改善國內相關下載體驗，但不管體驗如何，原廠獲取、本地可信分發創建與維護，都應該是開發者須要創建的規則。

0x04 Android風險預警

4.1 預警背景

在XcodeGhost事件發生後，安天分析人員嘗試進行了其餘平臺的非官方通道開發工具審查，但因爲咱們的資源獲取能力等因素所限，儘管檢查了大量包和鏡像，卻並未在其餘開發平臺發現更多問題。但正如兄弟團隊發現Unity 3D被一樣污染的問題同樣，這並不意味着其餘開發平臺不存在其餘問題。

因爲Android的開發環境在國內獲取較爲困難，使得部分開發者會選擇從在線網盤等渠道下載離線更新包的方式來取代在線更新，所以咱們將Android開發生產環境做爲重點預警對象。

目前Android下的開發生產環境如圖4-1所示，其能夠分紅開發流程、自動化構建和發佈三部分。

圖4‑1 Xcode安卓開發生產環境示意圖

經過分析，不管開發者是否使用IDE環境進行開發或者自動化構建，都會使用到Android SDK和Android NDK，而且默認官網下載的zip中只包含有SDK Manager，不一樣API版本的構建工具和lib庫均須要開發者在線下載，而且在在線雲盤中有大量的離線包分享。

圖4‑2 經過搜索引擎能夠看到在百度網盤資源中有多份Android開發工具包

下文咱們將分別說明JAVA代碼和Native代碼的開發生產環境面臨的污染風險，爲避免咱們的分析被攻擊者利用，分析小組對公開版本報告中的本部分作了大篇幅刪減，相關論述是但願兄弟團隊共同對污染的可能性進行排查，以下降風險。

4.2 JAVA代碼開發生產環境的風險

在Android開發中，JAVA代碼開發和編譯主要由Android SDK提供，其中除了編譯工具和Ant編譯腳本外，還提供了系統jar庫，用於版本兼容的support庫，以及一些官方其餘支持庫。

JAVA開發生產環境被污染的風險，可能存在以下狀況：

污染代碼在編譯過程當中被植入，或者隨apk打包的jar庫植入；
污染代碼須要被主動調用，如在一個類被加載的時候去調用。

Android SDK中最大的風險是jar庫沒有廣泛採用簽名驗證機制，存在被篡改風險。

圖4‑3 驗證部分.jar的數字簽名

4.3 Native代碼開發生產環境的風險

一樣，Native代碼開發生產環境被污染的風險，可能存在以下狀況：

污染代碼跟隨編譯過程進入構建的模塊，Native代碼開發生產環境存在以下污染問題：
1. 污染頭文件被污染；
2. ndk-build編譯腳本被污染；
3. crt運行的.o庫被污染。
污染代碼必須可以自動執行，污染代碼可能被編譯到.init_proc或者.init_array節；
存在某處主動調用靜態庫的extern方法。

0x05 全景的安全視野才能減小盲點

若是對這一事件進行定性，咱們將其稱之爲一系列嚴重的「地下供應鏈」（工具鏈）污染事件，在當前移動互聯網研發過分追求效率、安全意識低下的現狀下，連鎖造成了重大後果。從目前分析來看其污染源多是地下黑產，並穿透了若干道應有的安全籬笆。同時值得深思的是，在今年3月份的時候斯諾登曝光的一份文檔顯示：美國情報機構曾考慮經過對Xcode(4.1)SDK進行污染，從而繞過蘋果App Store的安全審查機制，最終將帶毒App放到正規的蘋果應用商店裏。長期起來，國內安全的焦慮過多地集中圍繞着CPU和操做系統等少數環節的的自主化展開，但有其餘幾方面問題沒有獲得足夠關注。

1.從供應鏈上看：供應鏈上的各個環節，都有可能影響到最終產品和最終使用場景的安全性。在這個維度上，開發工具、固件、外設等「非核心環節」的安全風險，並不低於操做系統，而利用其攻擊的難度可能更低。所以僅關注供應鏈的基礎和核心環節是不夠的。而同時，在實際應用場景中，每每存在着因盜版、漢化、破解等問題帶來的地下供應鏈，以及下載重定向、第三方分發源等帶來的不肯定性，這些因素，在過去已經給信息系統製造了大量隱患。

2.從場景和時域關聯上看：開發商、分銷商、配送通道的安全性與使用場景的安全一樣重要，所以只關注最終場景的安全是不夠的。蘋果在中國缺乏足夠的CDN資源投入，儘管因其產品的強勢，讓中國的開發者和用戶都能容忍，但無疑也助動了地下工具鏈的成長。而國內的網絡速度和效率問題，看似一個體驗問題，但其最終也一樣能夠轉化爲安全問題。

3.從權限上看：在數據讀取能力上，居於底層的操做系統和居於上層的應用程序多是一致的，即便操做系統作出種種分層訪問、沙箱隔離等限制，一旦受到污染程序進入系統，其攻擊難度就瞬間從遠程利用下降爲提權，所以只關注操做系統的「底層」安全是不夠的，追求系統數據安全和持續運維纔是目的。而同時，在移動平臺上，不管是安卓提供的安全產品與應用平權的策略，仍是蘋果完全將反病毒產品逐出App Store的方法，最終都致使安全廠商難以給予其更多的支持、防禦和協同。從而使這些互聯網霸王龍陷於與寄生蟲們不可能取勝的戰爭當中。

4.從信息鏈上看：互聯網模式不是傳統的信息流轉，而是基於用戶的方便性追求而進行的信息採集、聚合與分析，用戶須要用主動提供信息來置換對應服務，所以，僅用傳統的控制思惟是不夠的。而從這一惡意代碼所表現出的信息採集和提交的特性來看，其彷佛與常態的互聯網客戶端十分接近，這或許也是其未能被更早發現的緣由。

從被現行發現的Xcode到以後被關注到的U3D，以及咱們預警的安卓開發平臺的可能性，一系列非官方版本污染事件涉及到了上述每一個問題的層面，其正是經過工具鏈污染繞過了多個開發廠商的自我安全審覈，與號稱很是嚴格的蘋果應用商店的上架審覈（也許對蘋果來講，這個「多餘」的模塊就像一個新增的廣告聯盟的插件）。而一批開發者不堅持原廠獲取開發工具，不審查工具的數字簽名，這些都暴露了App開發領域的野蠻生長，忽視安全的現狀。而這種被污染的App到達用戶終端後，並不須要依賴獲取更高權限，依然能夠獲取大量有價值的信息，但一旦與漏洞利用結合，就有可能造成巨大的威力。而同時，其也採用了與互聯網客戶端相似的信息採集聚合方式，而數據的聚合點，則位於境外的雲服務平臺上。從而使事件變成的多邊、多角的複雜關係。

對於蘋果公司在此事中的表現，咱們除了期待蘋果在中國有更多的CDN投入來改善下載體驗外，咱們想引用咱們的同事在2012年所寫的兩段文字：「做爲一個選擇全封閉、不兼容產業模式的商業帝國，蘋果公司取得的巨大成就在於其對體驗極致的追求和近乎完美的產業定位設計。但若是把第三方安全支撐能力徹底摒棄在外，一個自身已經成爲複雜巨系統的體系，怎麼可能具有獨善其身的能力呢」、「對安全廠商高度排斥，若是不求變革，這些都將致使其陷入漫長的一我的的戰鬥。」

這一問題再度提醒咱們，要跳出單點迷思，從完整供應鏈、信息鏈角度，造成全景的安全視野、安全建模與評價、感知能力。同時，咱們也要再度提醒，咱們須要警戒「創建一個徹底自閉合的供應鏈與自循環的信息鏈方能安全自保」的小農安全觀的捲土重來，在互聯網和社會生活場景下，這自己就不可能實現。而中國政企網絡的市場空間，徹底不足以保證一個健康的閉環供應鏈的有效生存，更談不上還須要支撐這個閉環供應鏈安全性的持續改進。

同時，咱們也須要看到，網絡地下黑產的泛濫與無孔不入，其不只將危害網民的安全，也會帶來更多縱深的安全風險，其讓國家安全的防禦邊界變得模糊。所以在這一問題上投入更多的資源，進行更爲強力、有效的綜合治理，於國於民都很是必要。

博客地址