微信公眾號:Antiylab
Xcode 是由蘋果公司發布的運行在操作系統Mac OS X上的集成開發工具（IDE），是開發OS X 和 iOS 應用程序的最主流工具。
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具有強力的“官方”推廣方不同，這次事件是采用了非官方供應鏈（工具鏈）污染的方式，其反應出了我國互聯網廠商研發“野蠻生長”，安全意識低下的現狀。長期以來，業界從供應鏈角度對安全的全景審視并不足夠，但供應鏈上的各個環節，都有可能影響到最終產品和最終使用場景的安全性。在這個維度上，開發工具、固件、外設等“非核心環節”的安全風險，并不低于操作系統，而利用其攻擊的難度可能更低。因此僅關注供應鏈的基礎和核心環節是不夠的，而同時，我們必須高度面對現實，深刻分析長期困擾我國信息系統安全的地下供應鏈問題，并進行有效地綜合治理。
Xcode是由蘋果公司開發的運行在操作系統Mac OS X上的集成開發工具（IDE），是開發OS X 和 iOS 應用程序的最快捷的方式，其具有統一的用戶界面設計，同時編碼、測試、調試都在一個簡單的窗口內完成。【1】
自2015年9月14日起，一例Xcode非官方供應鏈污染事件在國家互聯網應急中心發布預警后，被廣泛關注，多數分析者將這一事件稱之為“XcodeGhost”。攻擊者通過對Xcode進行篡改，加入惡意模塊，進行各種傳播活動，使大量開發者獲取到相關上述版本，建立開發環境，此時經過被污染過的Xcode版本編譯出的App程序，將被植入惡意邏輯，其中包括向攻擊者注冊的域名回傳若干信息，并可能導致彈窗攻擊和被遠程控制的風險。
截止到2015年9月20日，各方已經累計發現共692種（如按版本號計算為858個）App確認受到感染。同時，有分析團隊認為，相同的攻擊者或團隊可能已經對安卓開發平臺采用同樣的思路進行了攻擊嘗試。從其感染面積、感染數量和可能帶來的衍生風險來看，其可能是移動安全史上最為嚴重的惡意代碼感染事件之一，從影響范圍上來看能與之比肩的僅有此前臭名昭著的CarrierIQ]【2】。
目前，Unity 3D也被發現由同一作者采取攻擊Xcode手法類似的思路進行了地下供應鏈污染。
鑒于此事態的嚴重性，安天安全研究與應急處理中心（Antiy CERT）與安天移動安全公司（AVL Team）組成聯合分析小組，結合自身分析進展與兄弟安全團隊的分析成果，形成此報告。
安天根據Xcode非官方供應鏈污染事件的相關信息形成了圖2-1，其整體污染路徑為官方Xcode被攻擊者植入惡意代碼后，由攻擊者上傳到百度云網盤等網絡位置，再通過論壇傳播等方式廣播下載地址，導致被App開發者獲取，同時對于攻擊者是否利用下載工具通過下載重定向方式擴大散布，也有較多猜測。有多個互聯網公司采用被污染過的Xcode開發編譯出了被污染的App，并將其提交至蘋果App Store，且通過了蘋果的安全審核，在用戶獲取相關App進行安裝后，相關應用會被感染并回傳信息至攻擊者指定域名。
圖2?1 Xcode非官方供應鏈污染事件示意圖
位于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 樣本信息
這次攻擊本質上是通過攻擊Xcode間接攻擊了自動化構建和編譯環境，目前開發者不論是使用XcodeServer還是基于第三方工具或自研發工具都需要基于Xcode。而這次如此大面積的國內產品中招，則只能反映大量產品研發團隊在產品開發和構建環境的維護以及安全意識上都呈現出比較大的問題。
圖2?2 基于Xcode的開發流程（第三方圖片）【4】
1. 惡意插件植入Xcode方式
也許出于對Xcode穩定性和植入方便性的考慮，惡意代碼實際并沒有對Xcode工具進行太多修改，主要是添加了如下文件：
針對 iOS
針對 iOS 模擬器
針對 Mac OS X
以及修改了配置文件：
2.惡意插件植入App方式
圖2?3 受感染Xcode與官方版本配置文件對比
圖2?4 iOS應用啟動流程（第三方圖片）【5】
圖2?5 惡意插件植入的代碼入口點
惡意代碼上傳的信息主要有：時間戳、應用名、包名、系統版本、語言、國家、網絡信息等；同時還有被感染App的運行狀態：launch、runing、suspend、terminate、resignActive、AlertView。
所有信息通過DES加密后POST上傳到服務器：
其中6.0版本URL為字符串形式，而到7.0版本URL則進化到字符拼接，7.0版本中還可以獲取應用剪貼板信息。
圖2?6 獲取上傳的信息
圖2?7 6.0版本中URL為字符串形式
圖2?8 7.0版本中URL字符拼接形式
圖2?9 7.0版本獲取應用剪貼板信息
惡意代碼可以遠程設置任意應用的彈窗信息，包括彈框標題、內容、推廣應用ID、取消按鈕、確認按鈕；需要注意的是該部分代碼并沒有使用輸入框控件，同時也并無進一步的數據回傳代碼，因此是不能直接高仿偽造系統彈窗，釣魚獲取Apple ID輸入和密碼輸入的（這點在諸多已公開分析報告中均有一定誤導性）。
圖2?10 遠程設置彈窗信息
但是由于彈窗內容可以任意設定，攻擊者完全可以使用彈窗進行欺詐通知。
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，以下為我們分析的惡意代碼所能做到的行為：
圖2?12 設置推廣應用appID和對應URL scheme
另外推廣應用時候，由于彈窗所有信息皆可遠程設置，當把”取消“按鈕顯示為”安裝“，”安裝“按鈕顯示為”取消“，極易誤導用戶安裝推廣的應用。
雖然惡意代碼使用的域名已經被封，但由于其通信數據只是采用了DES簡單加密，很容易被中間人重定向接管所有控制。當使用中間人攻擊、DNS污染時，攻擊者只需要將樣本中服務器域名解析到自己的服務器，即可接管利用所有被感染設備，進而獲取隱私、彈窗欺詐、遠程控制等。
其中惡意代碼使用的DES密鑰生成比較巧妙，是先定義一個字符串”stringWithFormat“，再截取最大密鑰長度，即前八個字符“stringWi”。
DES標準密鑰長度為56位，加上8個奇偶校驗位，共64bit即8個字節。
圖2?13 DES密鑰生成方式
所以即便惡意代碼服務器已經失活，依然建議用戶及時更新被感染App版本，若仍未更新版本的App，建議立即卸載或盡量不要在公共WiFi環境下使用，請等待新版本發布。
截止到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手法一樣，但安天分析小組沒有跟進分析。
攻擊者使用了多個賬號，在多個不同網站或論壇進行傳播被植入惡意代碼的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-4、圖3-5：
圖3?4 證明截圖1微博發貼已刪
圖3?5 證明截圖2微博發貼已刪
2015年9月19日該網友公開澄清是自己記錯了，誤把百度云盤鏈接直接拷貝到迅雷下載地址里了，以下是網友的公開聲明。
圖3?6 網友澄清證明
但在地下社區中，確實一直存在針對迅雷污染，使迅雷下載到重定向惡意代碼的方法討論，而且由于類似感染可能獲得巨大的經濟利益，我們并不能完全排除這種下載污染，有可能通過流量劫持等方式來配合。同時亦有網友反饋迅雷存在直接下載和離線下載所得到的文件大小不同的情況。受時間所限，安天分析小組未對這些傳言進行進一步驗證。
此前根據相關安全團隊的信息檢索，認為攻擊者可能是X工業大學的一名學生。從攻擊者具備污染了多個平臺的開發能力，并已經確定對iOS用戶產生了嚴重影響，開發能力覆蓋前臺、后臺，掌握社工技巧，具備SEO優化的意識。從其綜合能力來看，有可能不是個體作業，而是一個小的團伙、或者存在其他方式協同的可能性。同時，根據相對可信的消息，相關云資源使用者每月向數據匯聚點亞馬遜支付數千美元，其應該有較高的獲益。
但此前關于攻擊者的亞馬遜資費每月數十萬美元的猜測，我們認為有誤，因為亞馬遜從計費上是單向收費的，而相關猜測是雙向計算的。
導致大量原廠發布的App遭到污染的重要原因是，開發團隊未堅持原廠下載，也并未驗證所下載的開發工具的數字簽名。
我們發現有很多分析團隊向開發者提供了完整的官方Xcode文件的Hash，但顯然直接對應用進行數字簽名驗證可能是更高效的方法。
OS X和iOS應用使用相同的簽名方式，即：
3.3.2 Mac上官方簽名工具codesign驗證App方式
Mac上可以使用官方codesign工具對Mac&iOS App進行簽名驗證。
codesign工具屬于Xcode Command Line Tools套件之一，可以使用如下方式獲取安裝，推薦使用1、2方式：
圖3?7 Developer Apple上的Command LineTools工具
使用codesign -vv-d xxx.app 指令可以獲取app的簽名信息。
如驗證官方Xcode7.0，方框內Authority信息即該應用的證書信息，其中：
圖3?8 官方Xcode7.0簽名信息
而驗證含XcodeGhost惡意插件的Xcode6.4應用，其所有者為“Software Signing”，說明非Mac App Store官方渠道發布。
圖3?9 惡意Xcode簽名信息
為了達到給所有文件設置簽名的目的，簽名的過程中會在程序包（即Example.app）中新建一個叫做 _CodeSignatue/CodeResources 的文件，這個文件中存儲了被簽名的程序包中所有文件的簽名。
使用codesign--verify xxx.app 指令可以根據_CodeSignatue/CodeResources文件驗證App的合法性
校驗官方Xcode應用，驗證通過，將沒有任何提示。
圖3?10 官方Xcode簽名校驗合法
校驗含XcodeGhost惡意插件的Xcode應用，驗證失敗，會出現提示，說明該應用在簽名之后被修改過。
圖3?11 惡意Xcode簽名校驗失敗
鑒于此事件影響重大，蘋果官方于2015年9月22日發布文章6推薦使用spclt工具校驗Xcode合法性。
圖3?12 官方推薦使用spctl工具校驗Xcode合法性
如圖3-13，上面為正版Xcode驗證信息，表明來源為Mac App Store；而下面為惡意Xcode工具驗證信息，沒有任何來源信息；
圖3?13 使用spctl工具校驗Xcode來源
關于此前Xcode加載較慢的問題一直被詬病，其存在國內網絡設施方面的問題，但蘋果未投入足夠CDN資源也是一個因素。我們注意到蘋果在申明中提及會改善國內相關下載體驗，但無論體驗如何，原廠獲取、本地可信分發建立與維護，都應該是開發者需要建立的規則。
在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代碼的開發生產環境面臨的污染風險，為避免我們的分析被攻擊者利用，分析小組對公開版本報告中的本部分做了大篇幅刪減，相關論述是希望兄弟團隊共同對污染的可能性進行排查，以降低風險。
在Android開發中，JAVA代碼開發和編譯主要由Android SDK提供，其中除了編譯工具和Ant編譯腳本外，還提供了系統jar庫，用于版本兼容的support庫，以及一些官方其他支持庫。
JAVA開發生產環境被污染的風險，可能存在如下情況：
Android SDK中最大的風險是jar庫沒有普遍采用簽名驗證機制，存在被篡改風險。
圖4?3 驗證部分.jar的數字簽名
同樣，Native代碼開發生產環境被污染的風險，可能存在如下情況：
污染代碼跟隨編譯過程進入構建的模塊，Native代碼開發生產環境存在如下污染問題：
污染代碼必須能夠自動執行，污染代碼可能被編譯到.init_proc或者.init_array節；
存在某處主動調用靜態庫的extern方法。
如果對這一事件進行定性，我們將其稱之為一系列嚴重的“地下供應鏈”（工具鏈）污染事件，在當前移動互聯網研發過度追求效率、安全意識低下的現狀下，連鎖形成了重大后果。從目前分析來看其污染源可能是地下黑產，并穿透了若干道應有的安全籬笆。同時值得深思的是，在今年3月份的時候斯諾登曝光的一份文檔顯示：美國情報機構曾考慮通過對Xcode(4.1)SDK進行污染，從而繞過蘋果App Store的安全審查機制，最終將帶毒App放到正規的蘋果應用商店里。長期起來，國內安全的焦慮過多地集中圍繞著CPU和操作系統等少數環節的的自主化展開，但有其他幾方面問題沒有得到足夠關注。
1.從供應鏈上看：供應鏈上的各個環節，都有可能影響到最終產品和最終使用場景的安全性。在這個維度上，開發工具、固件、外設等“非核心環節”的安全風險，并不低于操作系統，而利用其攻擊的難度可能更低。因此僅關注供應鏈的基礎和核心環節是不夠的。而同時，在實際應用場景中，往往存在著因盜版、漢化、破解等問題帶來的地下供應鏈，以及下載重定向、第三方分發源等帶來的不確定性，這些因素，在過去已經給信息系統制造了大量隱患。
2.從場景和時域關聯上看：開發商、分銷商、配送通道的安全性與使用場景的安全同樣重要，因此只關注最終場景的安全是不夠的。蘋果在中國缺少足夠的CDN資源投入，盡管因其產品的強勢，讓中國的開發者和用戶都能容忍，但無疑也助動了地下工具鏈的成長。而國內的網絡速度和效率問題，看似一個體驗問題，但其最終也同樣可以轉化為安全問題。
3.從權限上看：在數據讀取能力上，居于底層的操作系統和居于上層的應用程序可能是一致的，即使操作系統做出種種分層訪問、沙箱隔離等限制，一旦受到污染程序進入系統，其攻擊難度就瞬間從遠程利用降低為提權，因此只關注操作系統的“底層”安全是不夠的，追求系統數據安全和持續運維才是目的。而同時，在移動平臺上，無論是安卓提供的安全產品與應用平權的策略，還是蘋果徹底將反病毒產品逐出App Store的方法，最終都導致安全廠商難以給予其更多的支持、防護和協同。從而使這些互聯網霸王龍陷于與寄生蟲們不可能取勝的戰爭當中。
4.從信息鏈上看：互聯網模式不是傳統的信息流轉，而是基于用戶的方便性追求而進行的信息采集、聚合與分析，用戶需要用主動提供信息來置換對應服務，因此，僅用傳統的控制思維是不夠的。而從這一惡意代碼所表現出的信息采集和提交的特性來看，其似乎與常態的互聯網客戶端十分接近，這或許也是其未能被更早發現的原因。
從被現行發現的Xcode到之后被關注到的U3D，以及我們預警的安卓開發平臺的可能性，一系列非官方版本污染事件涉及到了上述每個問題的層面，其正是通過工具鏈污染繞過了多個開發廠商的自我安全審核，與號稱非常嚴格的蘋果應用商店的上架審核（也許對蘋果來說，這個“多余”的模塊就像一個新增的廣告聯盟的插件）。而一批開發者不堅持原廠獲取開發工具，不審查工具的數字簽名，這些都暴露了App開發領域的野蠻生長，忽視安全的現狀。而這種被污染的App到達用戶終端后，并不需要依賴獲取更高權限，依然可以獲取大量有價值的信息，但一旦與漏洞利用結合，就有可能形成巨大的威力。而同時，其也采用了與互聯網客戶端類似的信息采集聚合方式，而數據的聚合點，則位于境外的云服務平臺上。從而使事件變成的多邊、多角的復雜關系。
對于蘋果公司在此事中的表現，我們除了期待蘋果在中國有更多的CDN投入來改善下載體驗外，我們想引用我們的同事在2012年所寫的兩段文字：“作為一個選擇全封閉、不兼容產業模式的商業帝國，蘋果公司取得的巨大成就在于其對體驗極致的追求和近乎完美的產業定位設計。但如果把第三方安全支撐能力完全摒棄在外，一個自身已經成為復雜巨系統的體系，怎么可能具備獨善其身的能力呢”、“對安全廠商高度排斥，如果不求變革，這些都將導致其陷入漫長的一個人的戰斗。”
這一問題再度提醒我們，要跳出單點迷思，從完整供應鏈、信息鏈角度，形成全景的安全視野、安全建模與評價、感知能力。同時，我們也要再度提醒，我們需要警惕“建立一個完全自閉合的供應鏈與自循環的信息鏈方能安全自保”的小農安全觀的卷土重來，在互聯網和社會生活場景下，這本身就不可能實現。而中國政企網絡的市場空間，完全不足以保證一個健康的閉環供應鏈的有效生存，更談不上還需要支撐這個閉環供應鏈安全性的持續改進。
同時，我們也需要看到，網絡地下黑產的泛濫與無孔不入，其不僅將危害網民的安全，也會帶來更多縱深的安全風險，其讓國家安全的防護邊界變得模糊。因此在這一問題上投入更多的資源，進行更為強力、有效的綜合治理，于國于民都非常必要。
