XcodeGhost 事件會造成什麼影響？

12-25

寫了一篇短文，就不全文轉發了：
XcodeGhost 實際用途猜測分析
附送一篇科普：
爺爺奶奶都能看懂的 iOS 惡意代碼事件科普

這應當是App Store 2008年上線以來遭受的規模最大的攻擊，涉及應用之廣已經完全超過想像，若非發現及時，此病毒再增加更豐富的機能（如對密碼輸入框進行hook等）之後，可能成為中國歷史甚至世界歷史上涉案金額最高的黑客事件之一。

細思恐極的是，Android Studio、Android SDK在國內因為眾所周知的原因難以官方下載，如果黑產團體放出針對它們的編譯器病毒，然後在國內提供篡改過的鏡像下載，那就可能有非常大的危險了。

我們自然清楚這之間的危險性，我們會搭梯子，會校驗數字簽名和HASH，但是也許有一些開發流行應用的開發者並不清楚。

有些答主反覆說 Gatekeeper，但是那玩意其實是一個防君子不防小人的東西，它並不能完全監視 TCP 協議棧和文件系統，如果下載器不通過某個 API 告訴系統它寫入的這個文件是從網上下載的，或者它沒有在Info.plist里聲明它寫入的文件必須作判斷，Gatekeeper 就不起作用。另外，Gatekeeper 實現在 LaunchServices 層，而不是在 launchd 層，對於非圖形界面的命令行程序，也是無法判斷的

Key:

LSFileQuarantineEnabled

Value type:

Boolean

Notes:

When the value of this key is true, all files created
by the application process will be quarantined by OS X. Three
quarantine properties can be assigned automatically: the timestamp
(current time), and the application name and bundle identifier (kLSQuarantineTimeStampKey, kLSQuarantineAgentNameKey, kLSQuarantineAgentBundleIdentifierKey).
OS X does not have sufficient information to assign several important
quarantine properties, such as the source URL; use the API to set
additional properties. Automatic quarantine is useful when an
application does not have complete control over the files it creates,
for example, if it hosts externally-developed plugins.

另外，關於為什麼大公司用盜版，還有一種可能，他們的編譯伺服器是外部採購的黑蘋果，找的專門做黑蘋果軟硬體維護的公司維護系統軟體，而病毒作者不僅做了病毒本體，還有感染現有機器xcode的手段（比如隱藏在黑蘋果系統升級的部署腳本之類里，不是所有黑蘋果都能官方更新系統的）

為了便於程序員檢查自己的開發環境，西雅圖0xid小組提供了相關的白名單列表，後續還將繼續更新。
http://card.weibo.com/article/h5/s#cid=1001603889840872671643

災難進一步擴大，蘋果可以鬆口氣了，現在已經不是iOS一家的事情，蘋果谷歌微軟全中。然後幫XcodeGhost洗地的可以歇歇了，玩這麼大要還是實驗，我買塊豆腐去。
來，同學們，卸載一切非必要的APP然後改密碼吧，Raman
//企業開發者可以下載啟明星辰Adlab提供的工具檢測自己的APP有沒有被植入後門：
http://pan.baidu.com/s/1hqARsHY
個人用戶可以下載盤古的檢測工具檢查手機是否被植入後門：
http://x.pangu.io/?url_type=39object_type=webpagepos=1

//更多內容，關注微信公眾號：安在Anzer_sh
//以下原文
1.搞信息安全，想像力是第一位的，所有號稱馬其諾防線堅不可破的宣言，最後都被打了臉。
2.搞安全防禦，永遠不要依賴一條防線，風險分擔和整體控制才是王道。
3.「人」永遠是信息安全里最弱的一環，「惰性」永遠是達摩克利斯之劍懸在所有系統之上。
4.感染開發系統，這並不是第一次：震網病毒、某遊戲公司被黑都是類似的思路，但是玩這麼大，影響面如此之廣，此事必然要載入史冊了。
5.不要光顧著檢查xcode了，整個開發流程都捋一遍吧，所有非授權的軟體、工具，所有未經嚴格驗證的下載、安裝，都是潛在的風險。
6.普通用戶，多改密碼吧。

這是個處心積慮、策劃多年的騙局，其手法之高明，說明攻擊者要麼是經驗豐富的老道黑客，要麼就是有專業的黑產公司。不同於之前時候那些依靠力量的攻擊，這個駭客成功地實現了四兩撥千斤，用最少的資源獲取到了最多的隱私資料，而且過了甚久才被察覺。
這次的攻擊絕對可以載入史冊，絕對的。
現在看來數字簽名真的是無比正確的事情，至少能同時保證文件完整性和正確性。然而很多人都不回去看數字簽名……有些開源廠商還嫌麻煩不簽……

ps. 有關所謂作者聲明，以這次攻擊這麼高端的手段，布了這麼久的局，這麼高的及社工技巧，居然只是「做實驗」？！微博上 @矮窮齪-陸羽回應如下：

我們3點多發微博，4點都你的稿子就出來了，是因為身份暴漏了。所以發這個帖子么？姑且不說你是不是真的作者，如果真的是，你的解釋是不同的，因為域名註冊早在2015年2月25日，而CIA後門稿子在3月12日，大規模傳播在3月13日，你是先知么？另外後長期續一系列的隱藏和變換身份的操作，就說明你是蓄意的！

個人強烈建議閱讀這個回答的答案，比我寫得權威也好理解：XcodeGhost 事件會造成什麼影響？ - Sai 的回答

下面是我的回答，這個回答主要分為回答問題以及沒受影響和受了影響 App 名錄兩個部分（現在這個回答已經和前期回答發生很大變化，所以前期對我這個回答點了「贊同」的用戶，還請酌情取消「贊同」，總之事態發展太快，麻煩了！）：

強烈建議修改 Apple ID 的相關密碼。強烈建議修改 Apple ID 的相關密碼。強烈建議修改 Apple ID 的相關密碼。微信 9 月 10 日發布的 6.2.5 版本已經被微信官方公告確認被感染，隨後微信 9 月 12 日發布了 6.2.6 版本修護了這個問題，因為這個木馬現在看來半年前就開始出現，並且受感染的 App 數目之多也可以說是嘆為觀止，這期間木馬是否有用彈窗來誘導用戶輸入 Apple ID 以及密碼現在已經不得而知了，但是為了帳號安全，Apple ID 的密碼還請儘快修改。話說回來，微信知道 Xcode 被注入的時間點是在 9月 10 日左右，比國家互聯網應急中心應該還快了幾天。（根據這篇文章，看來是騰訊安全應急響應中心在12日的時候，向國家互聯網應急中心彙報了）。

就這個問題而言，造成什麼影響，我覺得主要的影響是這幾個方面：

0.不少用戶對 iOS 的生態的信任感遭到破壞，這一點是我感到最大的損失，尤其是很多人非黑即白的眼中，出了問題很容易推出「 iOS 很危險」的奇怪結論，就算髮生這種事情，我認為 iOS 目前還是最好的移動操作系統之一，目前出問題的 App 以 360 掃描的成果為例，不到總數的 0.5%，多數國民級別的 App 並沒受到影響。（但是還是建議不管使用什麼 Android 還是 iOS，都要增強自己的安全意識。定期修改重要賬戶的密碼以及重要賬戶不要使用同一個密碼是非常關鍵的事情。）

1.受影響的 App 很容易被簡單粗暴的刪除（我其實是很不推薦這麼做的）或者遭到大規模的 1 星評分，這會嚴重影響這些產品的運營及成果。網易雲音樂作為第一個爆出來的知名 App，可以說受到極其嚴重的影響，而微信一天之內一星評價劇增（這不排除競爭對手藉機刷惡評），這些都對是這些產品極其嚴重而又典型的傷害。而且現在蘋果的處理方式是先下架問題版本，最近幾天運營的數據肯定很糟糕。

2.本質上也給一線程序員敲了警鐘，幾十年前的破壞原理到現在依舊可能造成惡劣的影響，對大多數 iOS 程序員上了一課：一定要去 Mac App Store 下載 Xcode，而與之相關的安全方面的意識只能說希望藉此機會得到重視。

其餘蘋果是否會加強程序安裝或者打包應用增強安全性未可知，丁磊被一次又一次調侃「黑蘋果」是否會痛定思痛給開發人員更換白蘋果未可知，以後我們能不能不用翻就能連上 Mac App Store 下載 App 未可知。（這回問題還有蠻大一部分原因是眾所周知的其他國家的原因，當然不知道原因的當我沒說這句話。）

-----------------------------------------
第一部分結束，下面是第二部分：
我檢查了下，沒什麼問題的白名單部分，如果這部分有問題還望提醒：
自我檢測了一下自己安裝的，這些常用的 App
（支付寶、微信6.2.6、QQ、新浪微博官方客戶端、VVebo、FORK、知乎、QQ郵箱、興業銀行、中國銀行、招商銀行、掌上生活、京東、淘寶、天貓、亞馬遜、什麼值得買、1號店、大眾點評、騰訊新聞、網易新聞、QQ音樂、網易有道詞典、美團、糯米、拉手）目前的版本都沒有受到 XcodeGhost 影響的。
==========
最大的影響是建議所有安裝過以下 App 的用戶在相關版本更新前不要使用這些 App，等待新版本更新後再使用。
雖然現在知道的上傳伺服器已經主動下線，但是不能排除這些 App 的使用風險。
另外再次強烈建議修改 Apple ID 的密碼。
下面是受本次事件影響的 App 列表（如有異議還請私信或者回復），斜體+下劃線說明已經修護
==========
最初版本：
根據烏雲的消息：XCode編譯器里有鬼
中招名單：
1.網易雲音樂（問題版本號2.8.3，更新日期2015年9月6日）（更新版本號2.9.0，更新日期2015年9月20日）
作為 Apple 的知名開發商，網易一直用黑蘋果開發也就算了，沒想到連接 MAS 的網速會慢到要去其他地方下載 Xcode。這次事件雖然目前看只是一個網易雲音樂的問題，但是這種不規範的開發流程足以極大傷害雲音樂的品牌，而且掛著「網易」的前綴，其他網易系的 App 似乎也很難避免不受影響。
==========
14 點更新：
根據消息（https://twitter.com/fannheyward/status/644747940020424704）
新加入木馬套餐的有：
1.滴滴打車（滴滴出行，問題版本號4.0.0，更新日期2015年9月9日）（修護版本號4.1.0，更新日期2015年9月18日）
2.鐵路12306（問題版本號2.1，更新日期2015年5月31日）（修護版本號2.11，更新日期2015年9月21日）
3.中信銀行動卡空間（問題版本號？，更新日期？）（修護版本號3.4.5，更新日期2015年9月19日）
這幾個裝機量足夠大的 App 加進來後，果然網易雲音樂明顯不會這麼那麼矚目的吸引炮火了。
==========
15 點更新：
跟過節一樣，木馬套餐添加新產品：
https://twitter.com/tualatrix/status/644766088815767553
第三輪測試結果如下：6、下廚房；7、51卡保... 來自圖拉鼎
1.中國聯通手機營業廳（版本號3.2，更新日期2015年8月14日）
2.高德地圖（問題版本號7.3.8，更新日期2015年9月5日）（修護版本號7.5.0，更新日期2015年9月19日）
3.簡書（版本號2.9.1，更新日期2015年9月12日）
4.開眼（版本號1.8.0，更新日期2015年8月21日）
5.網易公開課（版本號4.2.8，更新日期2015年9月1日）
6.下廚房（問題版本號4.3.2，更新日期2015年8月28日）（修護版本號4.4.0，更新日期2015年9月19日）
7.51卡保險箱（版本號5.0.1，更新日期2015年8月29日）
8.同花順（版本號9.60.01，更新日期2015年9月16日）
=========
18 點更新：
來源知乎用戶周逸靈評論
1.Lifesmart（版本號1.0.44，更新日期2015年9月10日）
來源 v2ex 垃圾網易，開發 iOS 還用黑蘋果？ Xcode 還在百度上去下載？ 184樓評論
1.馬拉馬拉（問題版本號1.1.0，更新日期2015年8月25日）（修護版本號：1.2.1，更新日期2015年9月19日）
2.葯給力（版本號1.12.1，更新日期2015年9月14日）
3.喜馬拉雅（版本號4.3.8，更新日期2015年8月27日）
4.口袋記賬（版本號1.6.0，更新日期2015年8月9日）
========
19 點更新：
來源知乎用戶龍小剛評論
1.有貨（版本號3.5.0，更新日期2015年9月10日）
2.微鏈（版本號2.3.0，更新日期2015年8月25日）
3.股票雷達（20 點更新）（版本號5.6，更新日期2015年7月17日）
來源知乎用戶李凱華評論
1.南方航空應用（問題版本號2.6.5，更新日期2015年8月7日）（修護版本號2.6.6，更新日期2015年9月19日）

=========
來源 v2ex 消息
1.微信（問題版本號6.2.5，更新日期2015年9月10日）（修護版本號6.2.6，更新日期2015年9月12日）
更新說明，根據微信的公告：來自騰訊微信團隊確實有，真的是極為蹊蹺的存在。根據騰訊微信團隊的微博的公告表示，微信 6.2.5 本身也是感染的，不過9月12日上架的 6.2.6 已經作出了修改，企鵝真是悶聲典範。
========
20 點更新
來源知乎用戶李雲龍評論
1.快速問醫生（版本號7.7.3，更新日期2015年8月20日）
=========
21 點更新
來源知乎用戶 i蒹葭從風評論
1.豆瓣閱讀（問題版本號2.1.0，更新日期2015年9月6日）（修護版本號2.1.1，更新日期2015年9月19日）
2.SuperMii酷臉（版本號1.9.0，更新日期2015年9月8日）
來源 XcodeGhost：網易雲音樂、中信銀行動卡空間、12306、滴滴打車、中國聯通客戶端 47樓 iwege回復
1.CamScanner（中文「掃描全能王」）（版本號3.8.1，更新日期2015年9月8日）
========
19日 0 點更新
來源知乎用戶朱瑜駿評論
1.懶人周末（版本號1.3.0，更新日期2015年7月9日）
另外附上另外一個回答中的 Google 在線文檔地址，可能更新比我這邊要快。
https://docs.google.com/spreadsheets/d/1YELrImviQ5ARC8A-WKgNyx0puRxXPMjR3TmSzHghUZA/htmlview?usp=sharingsle=true
截止19日01:04，這個文檔提及但是這個回答中沒有提及的幾個App供無法訪問上一個鏈接的網友看：
1.微博相機（版本號1.5.0，更新日期2015年7月23日）
2.CamCard（中文「名片全能王」）（版本號6.5.1，更新日期2015年8月13日）
3.SegmentFault（版本號2.8，更新日期2015年9月12日）
4.炒股公開課（版本號3.10.01，更新日期2015年7月22日）
5.股市熱點（版本號2.40.01，更新日期2015年9月17日）
6.同花順愛基金（版本4.20.01號，更新日期2015年8月28日）
7.此條信息中本人驗證了下有誤，故而刪除
8.滴滴司機-計程車（問題版本號2.9.3，更新日期2015年9月10日）（修護版本號2.9.4，更新日期2015年9月19日）
9.OPlayer（版本號2.1.05，更新日期2015年7月22日）
10.訊飛輸入法（版本號5.1.1463，更新日期2015年8月27日）
========
19日 1 點更新
懷疑應該也有的
1.滴滴專車-司機版（版本號1.1.0，更新日期2015年8月15日）
3點更新
來源知乎用戶 adam look
1.同花順至尊版（我估計同花順同一家出來的 App 都是有問題的）
補充了版本日期，如果有問題還望指正。
先睡覺了。
========
19日 10 點更新
這種東西看來還是能批量操作的效率要高些，雖然我鄙視 360 ，但是這個名單應該還是可信的。
來源 360NirvanTeam
感染XcodeGhost木馬App詳細名稱及版本號
=========
20日 0 點更新
來源知乎用戶 live4love
1.凱立德導航（問題版本11.4.1）這個已經在 App Store 上找不到了，應該是被蘋果臨時下架了。

最後，我還是要強調，這裡邊涉及 App 眾多，消息來源也複雜，我不建議大家採用刪除的方法來避免問題，我更傾向大家能夠等待問題版本的問題被新版本修護後再使用！
另外如果發現有問題的 App 名單信息有誤，還望提醒指正。

=========最近工作太慢，沒有特別多時間弄，基本上9月19日之後的更新的 App 應該按照蘋果的審核情況，不會再出現 XcodeGhost 的問題了。

我想說，國家還是挺牛逼的。。。
早我們幾天就發公告了，也很正統地闡述了影響和傷害，只是沒人理他們。。。
國家互聯網應急中心
關於使用非蘋果官方XCODE存在植入惡意代碼情況的預警通報
來源：CNCERT　時間：2015-09-14
近日，CNCERT監測發現，開發者使用非蘋果公司官方渠道的XCODE工具開發蘋果應用程序（蘋果APP）時，會向正常的蘋果APP中植入惡意代碼。被植入惡意程序的蘋果APP可以在App Store正常下載並安裝使用。該惡意代碼具有信息竊取行為，並具有進行惡意遠程控制的功能。
目前，CNCERT正在加強分析，並將此預警信息通報相關開發者或互聯網企業，在開發蘋果APP過程中，切勿使用非蘋果官方渠道的XCODE工具，以維護廣大用戶的個人信息安全。

請大家在 https://docs.google.com/spreadsheets/d/1YELrImviQ5ARC8A-WKgNyx0puRxXPMjR3TmSzHghUZA/edit?usp=sharing 中查看和編輯更新最新的受影響應用列表，所有人均可編輯，請大家謹慎提供，並註明來源
------
最初這次XcodeGhost的曝光，應該是來自於最初唐巧在9月17日微博提到了：

一個朋友告訴我他們通過在非官方渠道下載的 Xcode 編譯出來的 app 被注入了第三方的代碼，會向一個網站上傳數據，目前已知兩個知名的 App 被注入，檢測方式見附圖。

然後通過網友分析，目前已經發現存在問題的iOS App包括不限於：

網易雲音樂
滴滴打車
12306
中信銀行動卡空間
網易雲音樂
中國聯通
高德地圖
簡書
豌豆莢的開眼
網易公開課
下廚房
51卡保險箱
同花順

看起來似乎沒啥問題，但是問題是，真的只有這麼簡單嗎？我們先來看一下同花順的更新記錄：
最後更新時間為 2015年9月16日，按照蘋果的正常審核流程，App通常至少是1周的審核時間，那麼這次XcodeGhost的問題，起碼在9月初應該就已經出現了。
稍微找了一下，CNCERT已經在2015年9月14號時發布了關於非官方Xcode存在後門插入的問題的公告(國家互聯網應急中心)。不過看情況是大家對這個問題，並沒有太多的關注。
這個帶病毒版本Xcode是來自於coderfun的百度網盤分享，這個百度網盤分享了大量的Xcode，最後一次更新還是很久以前。圖來自(http://researchcenter.paloaltonetworks.com/2015/09/novel-malware-xcodeghost-modifies-xcode-infects-apple-ios-apps-and-hits-app-store/)，現在他已經將所有分享取消了。

隨便找了一下這個coderfun的記錄，根據發帖記錄顯示，這個人從很久之前（6個月前）就開始大批量的推廣他的帶有惡意代碼的Xcode，並且在多個常見的iOS開發論壇進行推廣下載：

根據這些記錄，我們有理由相信，中招的應用遠遠不止現在發現的幾個應用這麼少...真是細思恐極，想想國內的環境，相對Android來說，Xcode從MAS還算比較方便下載的了（網速不錯大概20mins就夠了），有人要是在Android裡面搞這麼點小九九，估計國內一大幫人就要躺著也中槍了。

已經有有人簡單的分析出來了，看來事情真沒那麼簡單啊
XcodeGhost 實際用途猜測分析

感覺對個人而言最大的影響就是不敢用百度搜東西了，在Google不敢用中文搜了，下個啥都要sha一下，下源碼都想看一遍再編譯
已經遠離p2p
贊同 @哈sea，國產應用大多是抄襲國外的創意，用他們的爹就行了。
再有啥影響，那就是忍不住重溫了這篇舊文：Reflections on Trusting Trust
感覺事件發生的原因就是開發過程的不夠嚴謹吧

自從這回答出來後，上周從迅雷離線抓東西回來斷斷續續，4線程也只有100k速度，換了幾個網路環境都一樣，找了客服說我的帳號沒任何問題。
然後，我就只能呵呵。請允許我做一個悲傷的表情。
-----------------------------------------追悔莫及的分割線-----------------------------------------
XcodeGhost 事件會造成什麼影響？ - 知乎用戶的回答
請下載此回答提及ppt。第18頁開始投毒過程。
-----------------------------------------不知羞恥又更新了的分割線-----------------------------------------

誰主張誰舉證。以下是視頻。
實驗方法：

選用兩個軟體，均為「版本更新了但是url不變」類型，不需要科學上網就可以訪問。

對比用IE在源網站下載（直連）、直接用迅雷下載Url（直連/迅雷cdn）、先添加到離線再用迅雷下載（迅雷cdn）。

因為直接用迅雷下載Url時，會把此連接添加到離線。所以進行先添加到離線再用迅雷下載前，需要去離線刪掉結果。

對比下載結果

對於需要科學上網或身份認證的資源，沒有做測試。不過這類資源都只能通過迅雷cdn下載，跟上面先添加到離線再用迅雷下載相同。

實驗環境：
Windows 10，Hyper-V虛擬Windows 8.1，現場安裝。為了時間考慮分配了16G內存做虛擬硬碟。
迅雷迅雷離線—在線播放—優酷網，視頻高清在線觀看視頻

實驗結果：

用IE從源網站下載實在太慢等不及，第1個軟體使用網站提供的替代連接下載完成。第2個軟體沒有下載完成，實在太慢。但是不影響結果，只要仔細看「文件大小」，就知道有啥問題。

直接用迅雷下載源Url，下載得到的文件跟IE相同（看文件大小）。使用的測試文件可以直連，所以迅雷能通過HTTP頭返回的文件大小判斷選用什麼鏡像。即，除了URL，HTTP頭的信息也是查詢鏡像的Key（除了URL，還有cookie、Content-Length、Content-Type等等）。

先添加到離線，再用迅雷下載。可以明顯看到，下載文件的大小和前兩步不一樣。此時，查詢鏡像的Key只有URL，一個URL對應多個鏡像列表時，其他上下文都沒有時，返回哪個？新的？老的？帶簽名的？有毒的？

同樣的，在蘋果開發者網站這種需要身份認證的網站，你登錄進去點連接用迅雷下載，應該是沒問題的。迅雷可以用你的HTTP頭信息訪問蘋果開發者網站，並獲得返回，選擇到正確的鏡像列表。但是，當你從網上「獲得」一個連接，就算這個連接就是蘋果開發者網站的。但是沒有對應的HTTP頭信息，結果就跟只從迅雷CDN上下載一樣。分配給你的鏡像列表是哪個？蘋果官網正確的？還是被投毒過的？我剛剛試了一下，直接訪問xcode的下載連接，是下載不了的，會被302跳到Unauthorized；但是用迅雷，直接能下。請問 @楊竟，對於這類連接，請問迅雷怎麼樣「一邊下載一邊校驗」？

在原答案說了，類似技術並不單指迅雷。HTTPS的可信來源只有跟你通信的伺服器，HTTP壓根就沒有可信來源，不管是網頁，還是下載（其實本質都一樣）；而在HTTP上再根據特定上下文的鏡像選擇則更不可信，上下文豐富，鏡像列表正確的可能性會高點，而只有一個URL的話，正確性就？？
我相信迅雷這麼多年，也一直嘗試解決這問題，可這東西從根本就不安全，怎麼解決都沒用。真解決方法下面已經說了。
這種安全風險對普通用戶來說可能是可接受的，但是對一個公司來說，就意味著危險。像這次連網易之類都中招了。大公司肯定有提供構建服務的集群，一個APP中招了往往意味著這集群可能全中招了，一般這類集群都要求使用有正式授權的環境，譬如正版vs。為啥連這種嚴密管理的集群都能中招？
說白了，各種防線里，最容易攻破的是人。而人最容易被攻擊的，就是懶。
「既然迅雷cdn這麼好用，幹嘛在外面弄個機器下，然後再從那機器拖回來？」
「既然百毒上這麼多連接，幹嘛要登錄一下蘋果開發者網站？」
-----------------------------------------最後一更分割線-----------------------------------------
已經闢謠，從官方下載的xcode不會有問題。
這個答案的目標是猜測迅雷離線/快速通道的實現原理及對此猜測出來的原理可能進行的攻擊。
迅雷實際上是不是這麼乾的我不，知，道。
http不安全及可進行相關攻擊是真的。
迅雷離線/快速通道的實現原理是「如果我要實現相關功能我能怎麼干」思考的結果，這個思考並不是最近開始而是相關功能剛出來後開始。如果有徹底顛覆這實現，而非改進的請告訴我。
對於靜態url來源的hash，迅雷的伺服器可以從源下載一份來確認，包括可直接訪問及公開申請帳號的需要身份驗證訪問。
但是對於來源已不能驗證（伺服器死了，文件不在了，深網，區域網，私有地址，認證方式不能自動化等），下面說的安全問題依然存在。
至於迅雷幹了啥，可以看L7filter對於封迅雷的實現。一個下載軟體你頻繁和自己伺服器通信還要開埠還要upnp這是鬧哪樣，我不用bt和emule你也要開？（這埠在迅雷還不支持bt和eMuled時候就已經開了）

話說你用來下載的請求頭迅雷是知道的，cookie什麼有沒有被存下來，會不會像上次360那樣不小心設錯了把存下來的用戶訪問url被搜索引擎索引下來，呵呵一下就好了。
-----------------------------------------這是bug bug的分割線-----------------------------------------
不要用迅雷
不要用迅雷
不要用迅雷
實名回答黑迅雷。
迅雷及類似鏡像/不校驗的p2p技術從誕生就有風險。
從遠古時代開始，迅雷就能被投毒。
對於一個http請求結果，客戶端無法對此進行可信性、完整性校驗。所以http請求非常非常不安全。
首當其衝就是走過的每層網關都能強x東西，每層網關都能把你所有信息記下來，甚至「國家級旁路」在你看不到的地方幹活。
解決方法有很多，譬如文件同目錄放一個md5sum文件、在下載頁面跟隨文件同時發布一個hash，可執行文件打簽名，壓縮包PGP簽名等等等等。
那麼迅雷的鏡像是怎麼幹活的呢？以下是推測：

迅雷本身從一個url下載，把url和下載回來的文件hash一下，發到伺服器備用。

當1的數據多了，找出hash一樣的結果，把他們對應的url判斷為鏡像。

當新用戶請求鏡像列表其中一個url時，也從其他url下載。

找到在下載、已下載並且未刪文件的用戶p2p。

【可選】計算用戶電腦里每一個文件hash並發到伺服器。有匹配的話這個用戶也是p2p上傳目標。

迅雷有個功能，可以在「源文件已被刪除」的情況下，把文件下回來，依靠的就是鏡像匹配。

那麼怎麼判斷一個url返回的結果對應什麼hash呢？被下載的url類型可有各種各樣。有經常變化的頁面，也有不經常變化的靜態文件，還有需要認證的（cookie或其他憑據交換）。換句話說，怎麼判斷一個url的內容的hash是可被划到有效鏡像的。
以下還是推測：一個簡單而有效的方法是，對於一個url對應的hash，取樣次數n足夠多，並且是同樣hash百分比超過閾值p，可以認為這個hash是有效的。至於n和p是多少完全是個經驗值，相信迅雷這麼多年數據積累，對每類url都有有效的取值。
不過這方法有個顯然易見的Bug：雖然一個url是靜態文件，但是他依然會變！這種情況通常出現在各種軟體發布下載里。這種做法對cdn（其實迅雷也是種cdn）非常不友好。實際cdn伺服器可能給你提供個api刷新緩存，但是迅雷可不會給你這種api！
這種時候，可能源地址連tcp握手都沒完，就已經從國內「鏡像」下載完了，迅雷離線和快速通道其實就是這種「鏡像」，於是迅雷下載的文件就有可能和網站提供的文件就不一樣了。就下載軟體來說，就是下載回來是箇舊版的，這還是個小問題。
還有一個更嚴重的bug，就是我們今天的主角，就是直接針對取樣次數和hash發起攻擊。xcode每個包的命名和路徑都很有規律，不難猜出下一個包的命名。那麼就可以構造出一種投毒。

架一個http伺服器，在攻擊機本地或者其他地方都行。最好在本機，因為速度快。裡面就放一個修改過的xcode.dmg。這完全可以用一個帶cache的http proxy來做，把改過的xcode.dmg放緩存里直接返回，其他放行。

在攻擊機本機或上層路由劫持tcp連接，把蘋果開發者網站上，xcode.dmg的請求攔住，重定向到1架設的http伺服器。甚至可以直接把1架設的伺服器作為透明代理用。

直接用迅雷下官網連接就好了。

用大量機器重複上述步驟，都是肉雞，你懂的。

迅雷收到大量被改過的xcode的假hash，直到超過設定的閾值。

把改過的xcode傳到百毒網盤，還有各種能提供帶寬的地方，再用迅雷下載幾次（還是肉雞），讓迅雷把這些「資源」也加進去鏡像列表。

更毒的是，因為第1個Bug，這種「版本不同」的同步，從蘋果開發者網站，到迅雷cdn的同步需要非常長的時間。如果不被人發現的話。
類似的投毒，無論是有意還是無意，xcode事件都不是第一件，也不會是最後一件。

-----------------------------------------這是神奇的分割線-----------------------------------------
對於用迅雷下載bt、emule、磁鏈，這類危險要小很多。這些協議本身就帶校驗。就算迅雷cdn緩存的文件有問題，也一樣可以用其他軟體進行完整性校驗。
但是迅雷並不提供這些協議本身就提供的完整性校驗功能！！
好多人都說不用迅雷，所有東西都下不動了。
我自己也是迅雷vip7用戶。只為離線下載，你懂的。
但是我並不使用迅雷任何軟體產品。用離線下載的網頁，然後有各種第三方軟體能把上面文件弄回來，再用其他方法校驗。
國內網路公司的軟體/硬體，還是算了吧，呵呵。
謝絕轉載。
感謝 @亞里士缺德指出閥值用詞錯誤。

這次我實在太無聊了，果斷註冊帳號來吐槽。。。本人發言僅代表個人與公司無關
今晚用了半晚來逆向XcodeGhost，發現危害沒那麼嚴重（看起來），基本是盜取一些基本的信息和偽造釣魚彈窗來誘導下載。猜測可能是用來刷榜。。。詳細分析可看XcodeGhost的無聊分析
思路真的很新鮮，不過技術沒想像中深奧，真慶幸這東西威力不大。目前我只分析到這麼多，後續有空再研究。利益相關：網易的小員工

什麼是官網，什麼是軟體官方hash？
對中國的開發者而言，這次事件敲了鍾。當然我更希望這能給百度、迅雷甚至下載站等流量渠道商敲鐘，因為他們的所作所為能影響到千千萬萬用戶。
另一方面也說明光靠閉關封鎖的appstore制度，也是不能完全防住黑客和黑產的。

突然發現這個答案不對，因為身邊有搞ios的人告訴我，就算開了gatekeeper，也就直接裝進去了，系統並沒有任何提示……蘋果這個設計實在是太牛比了。
=======================================
事實證明，關gatekeeper/UAC都是對中國人民不負責任的行為。

影響嗎？
我這個安卓用戶居然心頭竊喜：
『沒想到阿沒想到，ios你這個濃眉大眼的傢伙也能粗則么大的事。』
…………
開發者要把安全放在第一位，用戶最可憐。

為啥又有知乎官方邀請！？
我說過800遍了：
不要亂用開源軟體！
不要用盜版軟體！
從官網下載程序！
仔細檢查校驗碼和數字簽名！
指定專人管理和維護開發測試環境！
----------------------
之前吐槽，現在說正經的，一個個環節展開說，為此要犧牲30-60分鐘娛樂時間，不太開心：
1、水果
水果的安全機制這次被直接打臉啊。
這種簡單的未公開通訊，通過沙箱技術很容易發現，讓大家懷疑水果到底有沒有做安全審核。
人肉審核不是不可以，但更偏向內容，因為肉眼很難發現技術底層的東西，真去做代價也太高。
原因很簡單：哪裡去找那麼多具有豐富代碼審查經驗的人？
依靠技術實現，效率會高很多。
2、軟體市場
軟體市場，一方面要掙白道的錢（渠道、推廣、流量等），另一方面也要設法和黑產撇清關係。
原因也很簡單：應該由誰來保證擺在市場中的軟體沒有暗藏啥東西，在背後偷偷做些事情呢？
客戶又該怎麼相信你沒有在軟體中動動手腳，加點啥東西進去呢？
所以做市場的公司，別看著水果被打臉忙著幸災樂禍，更不要蠢到藉此機會去做競爭宣傳。
先仔細想想自己的管控流程是不是經得住考驗吧。
別太開心，這個代價其實蠻高的。
其實做CDN的也相當於做市場，自己看著辦吧。
3、做ROOT工具和第三方ROM的
這裡有點引申開了，畢竟有能力做水果第三方ROM的團隊並不多，其實這裡說的跟安卓也相關。
ROOT是好東西，用戶掌握最高許可權！這也是津津樂道玩ROOT的人的一貫說法。
但如果這個用戶是小白呢？不好意思，絕大部分用戶在安全問題上都是小白。
不說別的，他們中間有多少人能搞清楚許可權管理都是啥意思？
說得難聽點：用戶是皇帝，但是這種皇帝在安全領域，都是「昏君」。
我也做安全的，自認為不是神，因此所有的手機都不會去ROOT，更不會去安裝第三方ROM。
ROOT過的手機，如果我說其中有8成被掛木馬了，可能有人會來打我的臉。
那說3-5成吧，這下打臉的估計不多了。但手機用戶的3成是個多麼大的數字？
熱衷於在ROOT和第三方ROM創業的團隊，這次事件是個巨大的警鐘。
做來練習技術積累經驗，沒啥問題。
正經當商業機會，那要看商譽足夠是否強壯去吃得下這機會。
4、壯哉大天朝的山寨開發公司
不點名了，名單大家都看得到。
其中有大家很敬重的公司，更有跟鈔票相關的公司，怎麼會犯這樣的錯誤，內控流程哪裡去了？
痛心疾首。
事已至此，多說無益。
介紹一下相關的基本安全流程吧（不是全部）：
a、所有的開發環境和工具必須專人負責管理，包括從可靠的來源下載、驗證和發布、安裝。
b、嚴禁使用盜版軟體和不知來源的軟體，最好將開發工作機單獨運作。
c、嚴格的配置管理，做到源碼可追溯，規避個別人員亂合入代碼的風險。
d、在可能的情況下，做集中編譯，僅給碼農保留必要的源碼編輯和配置管理許可權。
e、測試環境中須包括基本的沙箱驗證和通訊檢查，以及病毒掃描。
f、在可能的情況下，做代碼掃描，識別危險的模塊和系統調用。
g、不要吝嗇做軟體打包加校驗+運行前自校驗的工作，這是最後一道防線了。數字簽名最好。
竭力保證開發工具的來源可靠，環境不被污染，是做開發工作的必須質量保證。
啊，對開源軟體多說一句：
H、必須保證開源軟體的來源可靠，社區可信，許可證檢查過，代碼盡量自己都看過吧。
5、用戶們
很悲劇，在這次事件中，普通用戶們幾乎毫無反應的可能，徹底地無能為力。
只能等待APP STORE刷新應用了。
但是，我還是教大家幾招自保吧，特別是憂心鈔票的：
a、絕對不要ROOT手機，不要安裝第三方ROM。（如果一個手機用得很不爽，換）
b、盡量找大的市場去下載軟體，而不要自己上網下載本地安裝；把非市場的安裝模式關掉。
——相信大公司，越大越好；雖然有時候他們也會犯錯誤。
c、盡量選擇原生ROM自帶許可權管理的手機，仔細地檢查每個應用的許可權。（要求略高）
d、如果對安全性要求高，雙手機必備，簡訊驗證打開。
——第一個手機上網；第二個手機專門收簡訊驗證碼，因此它是個Nokia 1110都行。
——適用於所有跟鈔票和身份相關的應用，包括各種網銀、在線支付、身份驗證、高安全登錄。
——Nokia 1110有點廢柴感覺可惜？用智能機也行，但不要安裝相同的程序，盡量少裝雜應用。
e、自己的證件照片不要保存在手機裡面。
f、沒事不要亂蹭別人的WIFI，除非這個WIFI你非常信得過。（星巴克？馬馬虎虎吧。很多場所為了規避風險裝了一套登錄機制，總比啥都不做要好）
g、綁那麼多信用卡和支付卡幹啥，真忍不住用就只綁一張，單獨的零花帳號！上面不要開高信用額，不要存很多錢，零錢夠花就行了；不夠再去ATM轉到這卡上。
-----------------
個人的工作經歷和經驗（局部）：
某不以軟體出名的技術公司的安全開發流程開發者、執行者、維護者和決策鏈之一。
是的，只是決策鏈中的一環。

這是花式黑迅雷錦標賽嗎？不是說不能黑，但不能黑出超現實主義來啊！
事實上：

使用迅雷下載烏雲原文中提及的Apple官網Xcode 6.4、7.0都不會下錯文件，SHA1值完全一致。不信自己去試。

有毒的文件跟正確的文件相比，要大6.97MB。連文件大小都不一致，迅雷是不會搞混的。

經過離線伺服器查詢，有毒的文件最早是通過百度網盤添加到離線下載當中的，而不是蘋果官網的鏈接。

迅雷在下載過程中會實時校驗，下載完成後會再次校驗。黑迅雷不校驗的可以更沒常識一些嗎？

你們這些年輕人啊，不要總想著搞些大新聞~圖樣圖森破~拿衣服~！
2015-09-19 17:11:06更新：

烏雲網原文《XCode編譯器里有鬼 – XCodeGhost樣本分析》當中，文章作者引用微博中「誰敢亂說話」的留言「還是不能相信迅雷，我是把官網上的下載URL複製到迅雷里下載的，還是中招了」。目前「誰敢亂說話」已經發布澄清《我澄清一下，複製官方的URL到迅雷里下載沒有問題，我記錯了》

瀉藥。
這種手法並不新奇，在win32時代已經出現過，如感染delphi編譯器的SysConst.dcu，還有程序員使用的各種不明來歷的VC6.0、各種來源不明的編譯器插件。況且當時的微軟還沒有類似於APP STORE的審核機制，病毒滿天飛，程序員卻渾然不覺。雖然當時微軟提供了數字簽名、時間戳簽名等待各種工具，但當時使用正版VS studio的開發者太少了。。。。。
言歸正傳
1、APP STORE的審核機制不嚴謹，蘋果自身應作檢討；
2、從合法渠道下載也不能完全避免這種風險，認真核對簽名是應該的，關鍵看Xcode的簽名是不是蘋果簽發的，簽發者的數字證書是不是偽造的，建議簡單了解一下PKI相關知識；
3、在目前數字簽名（XCODE）的基礎上增加可信時間戳簽名，（版本&<--&>發布時間）不可篡改；

然而，這些只能降低類似事件發生的概率而已，誰讓開發者這麼喜歡看片！開發機上一堆不該有的東西，這TMD怎麼防？
最後，安全測試是非常必要的。

牆、感染、信任和欺騙
轉發自牆、感染、信任和欺騙_IT資訊_UDN技術社區，侵刪

最近XcodeGhost導致的嚴重安全問題，相信大家已經從各個渠道知道了。簡單概括一下，有人在中國網盤和論壇上傳播了一個修改過的Xcode，這個版本的Xcode會在編譯出來的App上面加一些可以被遠程控制的代碼，並且發送數據到某個伺服器上。這是iOS出現以來，未越獄系統遭遇的最大安全威脅，在此之前蘋果的Sandbox模式幾乎沒遇到過挑戰，iPhone用戶甚至大量iOS開發者都認為系統固若金湯，不可能遇到問題。
　　在XcodeGhost開始被媒體報道的時，很多人大大低估了它的風險。我在烏雲報道這個問題的當天，在朋友圈上建議大家先把中招的app都刪掉，並且立刻修改iCloud密碼，開兩步驗證。甚至遭到了不少人反對，還有好幾位iOS開發者告訴我這件事沒什麼大問題，因為iOS有Sandbox，不會造成什麼傷害。當時網易也發了一個關於雲音樂被感染的說明，也是類似不痛不癢的口氣。這些說法當然都是大錯特錯的，會有這種想法，是因為只會站在程序員角度看問題，如果對安全問題稍微有一點敏感性，就會立刻意識到這是極嚴重的威脅，稍微發揮一些想像力就會被嚇著。
　　所謂安全威脅，大部分都是在獲取到非常有限資源的情況下，利用社會工程學（俗稱：騙）來達到目的。比如，你覺得讓別人看到你的通訊錄有什麼問題嗎？很多人會認為雖然不舒服，但不會有什麼威脅。實際上，騙子會從通訊錄裡面挑出來你父母的電話，打電話去騙他們。所以，這和iOS有沒有sandbox，能不能保護系統安全沒關係，只要我獲得了一個機會，能控制你信任的app上彈出對話框，我就可以利用這個對話框來騙你輸入系統的重要密碼。程序員應該想像力再豐富一點，不要把目光局限於「系統給了我什麼許可權」，而是要擴展到「如果我被完全信任了，我能進行什麼樣的欺騙」。
　　我不打算在這裡講太多直接的安全問題，畢竟已經很多人分析過了，在好幾篇非常不完善，極大低估這次事件威脅的分析文章之後，騰訊給出了一篇相當詳細的分析，比較符合我的觀點，也把問題的嚴重性說的非常清楚。在騰訊的分析裡面，說可以利用OpenUrl來操作用戶撥打電話，同樣又有iOS開發者說「OpenUrl不能控制iPhone打電話」。事實上，OpenUrl可以彈出一個帶有固定電話號碼的彈窗，上面有「撥打」和「取消」兩個按鈕，這確實不算直接撥打了電話，但如果給一千萬個用戶在某個特定環境下彈出一個這樣的窗口，其中有多大比例的人會去點「撥打」呢？如果程序員不去提高想像力，總把安全問題和功能局限在系統文檔提供的「能做什麼」這個範圍內，軟體的安全性實在讓人難以信任。
　　具體的安全問題有更專業的人去普及，本文不多說，在這裡我更想談談關於信任的問題。在這次事件中，也有一些人想起了Ken Thompson大神（Unix系統/C語言的前身B語言/Go語言的直接貢獻者，稱作Unix之父也不過分）在1984年的一次演講，在那次演講中中，Ken講了他在70年代在貝爾實驗室捉弄同事的一次惡作劇，在那段時間裡面，實驗室裡面所有的Unix系統，Ken都可以隨便以最高許可權登錄，而同事反覆檢查用戶，許可權，甚至是當時使用的Unix代碼，都沒查不到後門，百思不得其解。14年之後，Ken在這次演講裡面才公開，後門其實隱藏在他寫的編譯器中，當用編譯器編譯Unix系統的時候，後門就被放在了編譯出來的系統裡面，但Unix本身的代碼是乾淨的，所以同事無論如何也查不到問題。Ken的演講所提到的核心問題並不是如何入侵一個操作系統，而是信任。其標題「Reflections on Trusting Trust」（我翻譯為「深入思考我們信任的可信」，以下簡稱RoTT）開宗名義，明確強調這一點。
　　在80年代曾經有很多人用這樣的辦法給開發工具加各種外殼和後門，但當時聯網條件並不好，很難產生大規模影響。很多案例是發生在相對封閉的企業內網和教育網中，Ken捉弄同事的原始案例也可以看作是企業內網上的傳播。可以說，RoTT能產生的影響一直被人們低估，因為在現實世界想要具備適合它的條件，實在是太難了。歷史上，雖然有很多底層代碼Bug導致的安全事件（比如之前的OpenSSL心臟出血漏洞，可以參考我的另外一篇文章，點閱讀原文可見），但直接通過這種在基礎工具上製造的後門，從而衍生的大規模安全事件，從來沒有真正發生過。這種手法一般是用在有限範圍的網路上，比如在早年的教育網上或者企業網路裡面，那時候在內網上傳遞一個被下了毒的軟體，很容易傳播開。
　　在互聯網上，如果要重現Ken的案例，首先需要找到一個可信的源頭感染，這本身就已經是極其困難的事了。用這次的事件做例子的話，在正常情況下，用戶是通過Mac App Store來下載Xcode的，在下載安裝的過程中，OS X本身會替用戶進行加密簽名校驗，保證下載的東西確實是蘋果原始分發的軟體，這樣才能被安裝到用戶的機器上。如果想把在Xcode中嵌入一個後門，你得先找到Apple伺服器的漏洞，才能有機會把自己改過的包上傳上去，而且還要弄到蘋果的私鑰去進行簽名，才能裝到用戶計算機上。但如果同時具備了這兩個條件，已經是榮華富貴唾手可得，有的是更可靠，獲利更大的做法，誰又肯去捨近求遠感染一個Xcode呢？
　　所以，只有在相對封閉的網路環境下，才有可能玩這個把戲。80年代，網路遠遠沒有今天發達，人們更多的下載和網路活動是分布在各大機構自己的網路裡面的，比如大型企業的內部網路，相對於互聯網，這些內部網路網路速度會快的多，人們通常更傾向於從內部網路獲得軟體。這就給了入侵者（通常是商業間諜）通過替換內容軟體來侵入公司內部的機會。但內網又造成了另外一個問題，在封閉網路下，入侵者獲得的數據也沒這麼容易拿走，必須還要回到內網才有機會拿到之前的戰果。這些特性造成了這種做法始終在小範圍內有效，在公眾網路上性價比不高。
　　這次XcodeGhost事件會給很多人啟發，中國目前的網路環境類似於80年代的企業內網，但規模又比當年的內網大的多，而且不像那麼難以進入。於是，一些80年代流行但沒造成大規模影響的辦法，有機會可以在中國環境下重新應用了，並且造成巨大影響。以前的創業是Copy to China，現在同樣可以複製30年前的安全問題。
　　Ken的演講最後指出，你沒辦法信任那些不是自己寫的代碼。80年代達到這個目標尚且有可能，那時候的軟體規模還很小。而今天，任何工作都需要建立在大量的現成軟體基礎之上，換句話說，你必須去信任其他人，才有可能製作出產品。如今的可信任環境就變得更加重要。
　　但在中國，因為GFW和相關政策的存在，要獲得一個可信環境變得非常困難。在這個環境裡面，大量國外網站不能訪問或者難於訪問，非常多怕麻煩的人會使用國內替代品，這次的事件之所以影響巨大，就是因為通過蘋果官方渠道升級Xcode速度太慢，少則10多個小時，多則幾十個小時，其間還有可能中斷和重新下載。從國內隨便下載一個Xcode用當然是錯的，但在這樣的環境下也不是完全不能理解，考慮一下互聯網的下載速度只有50K，企業內網速度能高達10M的時候，誰會不從內網下載呢？
　　用一個現實世界的例子做個比喻吧，前面說了騙子拿到你父母的電話之後，會打電話去騙他們，比如跟你父母說你出了車禍，急需用錢。要讓這個騙術成功，一個前提條件是要阻止你父母去找你驗證真假，所以騙子同時會用各種辦法來騷擾你的電話，迫使你不堪其擾關機或者始終佔線。這樣你父母和你的聯繫就斷開了，他們沒法找你驗證了，此時騙子的話就更容易被相信。在這次事件裡面，GFW讓人們無法訪問國外的可信網站，或者訪問速度極慢，它起的作用就如同迫使你佔線或者關機，從而讓人們只能從不可信的地方獲取軟體。
　　GFW讓中國本來開放的互聯網環境，變成了一個巨大的企業內網，或者叫做中國區域網。除了速度和難以訪問的影響，各種各樣的DNS投毒，電信運營商干擾也是嚴重問題，你拿回來的DNS結果往往也未必是可信的，而運營商試圖在HTTP請求中插入廣告的行為，又經常會導致正常的應用表現不正常，而這些亂七八糟的毛病還經常變化，今天你可以這樣對付，下周可能就需要換一個辦法。要維持一個可信的軟體環境，需要付出巨大的精力，能願意付出這個代價的人越來越少。
　　在這個環境中，我們能信任的什麼呢？網路鏈接不可信，運營商不可信，DNS不可信，大企業不可信。最後這一點更荒唐，如果是在正常的網路環境下，你很難相信蘋果或者Google會坑害自己的用戶，因為這和他們的利益直接相關，他們總是要盡量保護自己的用戶。但在中國，如果你敢信任百度，基本意味著你生活各方面都會出問題，用百度查個搬家公司，騙死你沒商量，用百度查個快遞電話，騙死你也沒商量，用百度查個醫院，你猜會怎麼樣？那是真要騙死你沒商量，這裡的騙死都不再是比喻了。你要信任百度的軟體，更好玩了，它莫名其妙就給你把百度出的所有軟體都裝在你機器上了，人們管這個不請自來的大禮叫做百度全家桶。如此致力於坑害自己用戶的大公司，在中國之外還真是罕見。
　　在中國的網路環境下，這次事件產生的危害本身也更加危險。事件發生時，我告訴朋友們立刻刪除所有被感染的軟體，直至問題被修復。有人說，黑客自己的網站已經關閉了，沒什麼危險。這麼說當然是錯的，因為遍布中國各處的DNS投毒和劫持，創造一個一樣域名的網站再簡單不過了。比如到遊客聚集的區域，帶一個路由器，創建一個沒有密碼的WIFI熱點，等著人們連上來，在這個熱點上劫持XcodeGhost使用的域名，就可以利用已經中毒的app來騙iCloud密碼了。這些都是非常容易實現的辦法，千萬不要低估安全問題能造成的後果，尤其是在中國特殊的網路環境下。
　　目前中國的網路環境和食品安全有諸多共同之處，你沒法信任路邊的小飯館，但同時你也沒法信任昂貴的大飯館。你沒法信任菜市場買的肉，但超市買的肉也並不那麼可靠。在一切的背後是土壤和水的全面污染，可能一家好的飯館未必打算毒害自己的顧客，但他們也很難保證自己原材料的供貨商可靠，要保證使用的所有材料可靠，這是一家飯館不可能具備的能力。比如，奶粉的三聚氰胺事件之前，一家有追求的飯館大概會覺得，我不用來路不明的奶粉，我用大品牌的三鹿，伊利，這算是對顧客負責了吧？可惜，這些大品牌一樣出問題。這絕非飯館所希望的，他們也是受害者，就像是這次事件中的網易雲音樂，他們確實沒打算坑自己的用戶，不過網易、騰訊這樣的大公司一樣中招了。
　　相對封閉的iOS尚且如此（單一開發工具，單一軟體分發渠道，獨家封閉系統iOS，獨家硬體iPhone）尚且能出這麼大問題，想想Android會怎麼樣？Android官方網站幾年前就被封了無法訪問，大部分開發者都是從國內渠道下載的開發工具。App的安全可靠嗎？國內無數家忙著改Android皮膚就稱自己是「操作系統」廠商，他們能保證自己的定製Android版本是安全嗎？他們有真正的操作系統廠商級別的能力嗎？進一步，他們能保證自己使用的開發工具安全嗎？每家手機廠商都恨不得做自己的Android app下載渠道，他們能保證這些渠道上分發的app安全嗎？甚至，他們能保證自己的下載市場安全嗎？請大家繼續聯想吧。有朋友跟我說，你想多了，Android哪需要這麼麻煩啊，本來國內環境就是木馬遍地了。真實情況恐怕只能用慘烈來形容。順便說一聲，傳說Google要把Play Store進入中國，提供一個受審查的版本，很多人說這是Google妥協了，我看這根本不是妥協了，是中國內部的Android環境太糟糕，已經威脅全球生態了，Google不得不自己出手解決這個問題。所以，一旦Google Play真的進了中國，請大家記得立刻把Play Store做為自己唯一的Android軟體下載渠道，哪怕它不好用，不中國國情，甚至顯得有點傻裡傻氣…千萬記得，安全比方便更重要。
　　在這些前提下，重新認真考慮Ken的演講提到的觀點就顯得更加重要，深入思考我們信任的可信。到底什麼是可信的呢？開發工具可信嗎？操作系統可信嗎？你覺得下載來之後驗證一下md5或者sha512總應該可信了，但你用來計算sha的工具是哪下載來的？你又如何知道這個工具本身是可信呢？在一個封閉的，難以和真正源頭溝通的環境下，根本沒辦法談所謂的信任。
　　在中國目前的環境下，難以直接套用成熟的軟體開發和管理流程，除非保證團隊所有人都必須翻牆，必須用Google查資料，必須不信任國內網站。你的團隊中有一個習慣用百度查資料，順著國內論壇的鏈接從百度網盤或者迅雷下載工具的人，就不知道會惹出來多大麻煩。這次事件充分證明了這一點，我起初認為騰訊應該不會有問題，因為我知道騰訊內部有極好的網路環境，但最終不幸的是微信也中招了。我們的惡劣環境已經改變了工程師的習慣，甚至改變了教育，就算是在騰訊內部這麼好的網路環境下，仍然有人會去百度查資料，用百度網盤下載開發工具。就像很多留學生到了美國仍然用百度搜索一樣，環境的改變並不能直接逆轉已經完成的用戶習慣。
　　比較諷刺的是，在中國特色的現實世界反而又制約了出現大規模安全災難的可能性。比如，中國有相當嚴重的網路監控、審查和實名制、以及互聯網公司必須保存（而且要向有關部門開放）的各種用戶數據，並且互聯網和世界半隔絕，在出現這種問題的時候，要抓到始作俑者又相對簡單。現實世界中，只要在論壇發個貼，去你家查水表就是分分鐘的事情。這大概算是「不幸+不幸「互相抵消之後產生了一點點微小的幸運吧。
　　很多年前，我說招聘工程師有幾個原則，比如，必須使用Google而不是百度，必須翻牆而不是用國內替代品，必須優先使用國外的工具。經常有人認為這種要求過於苛刻，甚至認為是裝逼。這次事件告訴了我們，這些良好的習慣確實是工程師的第一道防線，融入世界主流，可以讓你少遭遇很多中國特色的麻煩。雖然保持這些良好的習慣需要付出不小的代價，但事實證明這些代價是值得的。
　　這樣的網路環境，是我們這一代工程師的恥辱，但我們如此憤怒於此，又如此無能為力，這是這個時代最令人悲哀的事情。
　　我們對此有多麼無能為力呢？我寫這篇文章的時候就在想，大家應該趕快傳播它，因為我覺得它很快會被刪掉。這就是無能為力的具體表現。
　　順便說一句，1996年，受Ken的案例啟發，我寫過一篇科幻小說，大意是一種病毒把編譯器做為感染的源頭，最終感染了操作系統。在這個操作系統上，它會判斷用戶指令對它是否會造成傷害，如果是有害的指令，就假裝執行一下，實際並不真執行，從而可以躲過殺毒軟體和人工清除。這同樣是信任問題，在這個環境下，沒有任何可信的東西，這種病毒將會在操作系統中永存，並且把自己附著於任何在這台計算機上製造的軟體中。在一個計算機一開機就無線聯網的時代，病毒可以藉此高速傳播，最後人類已經找不到一台乾淨的計算機可以去編寫真正乾淨的操作系統了。（90年代還沒有無線網路，那時候甚至連有線網路都沒普及，Sun還在號稱網路就是計算機，那時候一台隨時聯網的計算機簡直太奢侈了，但如今看來…世界確實已經發展到了這樣，想找一台不聯網的計算機倒是不容易了）。
　　不知道這種幻想中的病毒什麼時候會真正出現…其實，前幾年工信部推行綠壩的時候，我當時就覺得那簡直是創造這種病毒的一個非常好的機會，還好最終綠壩計劃被放棄了。中國網路和政策環境的特殊性，將來真的有可能製造出適合這種病毒生存的環境，就像這次因為GFW的正面和潛在影響，讓70年代Ken設想的RoTT在2015年大規模流行，40多年的時間跨度…著名科幻作家韓松說過：「中國的現實變得比科幻還要科幻」。深以為然。

2015年9月19日10時更新：
就在今天凌晨，Github 上出現了個新項目：XcodeGhostSource/XcodeGhost · GitHub
README.md 里是疑似 XcodeGhost 作者的澄清文。
注意：上面鏈接中的澄清文的真實性還有待考證，因為這兩天出現過被感染的應用向用戶索要 Apple ID 密碼的案例，雖然真實性存疑，但是謹慎為好。相關討論：https://www.v2ex.com/t/221906
受本次木馬波及的應用，這裡有份清單，事實上 360 在這次事件中貢獻挺大的，好感度 +1：【持續更新】已知有後門的iOS App（9月19日凌晨1點更新）
以上為最新動態，以下為原回答：
我發現了一件喜聞樂見的事兒，就是 V2EX 的熱門帖子快被黑網易的帖子刷榜了，內容無非是自己是 ios 用戶，從此再也不敢相信網易了，接著苦口婆心奉勸大家卸載網易全家 app，最後給自己立個牌坊叫做「網易一生黑」。
理性地思考，我覺得，既然發生了這種事情，這些大廠、小廠都是逃避不了責任的。但是我覺得更應該受到譴責的是木馬的開發者好么？就像有個惡徒用刀砍人，受害者卻責怪那些生產刀具的企業生產出的刀太鋒利？這不是有違常理嗎？
中間再插入一些話題，總所皆知咱們的網路環境有某牆娘在默默 "守護" 著，還有坑爹的某網路運營商閹割國際出口單獨拿來當做增值服務出售，就在這種所謂的「國內網路環境」下，無論是 Web 開發者還是移動平台開發者，卻多多少少要去那些不存在的網站搜索資料或者下載資源。這是要求那些大廠標配官方梯子嗎？難道它們就不怕被請喝茶么？還是要求每個進 BAT 的程序員必備爬梯技能？
關於流傳的「迅雷離線伺服器被攻破」，我認為有點異想天開。簡單猜想一下迅雷離線的工作原理，我覺得只要木馬開發者用本地代理或者改 hosts 等方法在自己本機劫持了 Apple 官方的 xcode 下載鏈接，然後通過迅雷進行下載，就能產生給迅雷產生從蘋果官方伺服器下載的假象，然後迅雷從開發者的機器里把注入過木馬的 xcode 上傳到了離線緩存或者 p2p 到其他用戶的電腦里，最後就這麼傳播開了…
跑題了，各位看官不好意思。我認為這次木馬事件中，受到波及最大的就是網易了（畢竟首當其衝被黑），其次就是那些名單上的那些應用以及各種多多少少有些親緣的應用。企業公信力的喪失，用戶變成驚弓之鳥，那些大廠公開道歉，自我反思，之後聯合揪出罪魁禍首，最後事情不了了之…腦殘粉照樣用，不用的人想用時會產生警惕；那些之前就卸載了的，偏激一點的就是上面說的「網易一生黑」了，理智一點的大概會裝回去吧。
最後就是希望大家理智思考問題，然後就是建議各位 iOS 用戶暫時卸載受該次事件波及的應用，等待廠商的解決方案。
同樣的回答在：網易雲音樂的木馬注入到底會有多壞影響？ - 二階堂真紅的回答

你們在看微博上所謂黑客牛人老大哥裝逼的時候難道就不看平底鍋的分析？
http://researchcenter.paloaltonetworks.com/2015/09/novel-malware-xcodeghost-modifies-xcode-infects-apple-ios-apps-and-hits-app-store/
裡面有真料，除了嘴炮黑客所說的這個被注入的Xcode和已經停用的域名，還有倆版本和兩個域名

推薦閱讀：

※個人開發者在 iOS 或 Android 開發市場獲得成功的機會是不是越來越少，為什麼？
※個人開發者（非營利）如何應對不友善的用戶?
※三星宣布將於 2013 年 10 月首次召開開發者大會意味著什麼？