XcodeGhost 事件中，迅雷的污染事件是怎麼做到的？

01-08

xcodeghost事件中，如何做到對迅雷文件的污染。使迅雷下載到帶毒版本。
迅雷沒有對文件做md5或者是指紋校驗么？

分享一篇迅雷投毒簡單測試：http://gold.xitu.io/entry/56023eabddb263b560c8d254

我不知道XcodeGhost有沒有用，但是迅雷100%是可以被污染的。

1. 請看demo（2015/9/21測試有效），demo是evil_xi4oyu的微博做的，我只是搬運工。注意看原網址是一個不存在的文件，但是用迅雷可以下載到，會隨機的下到5M和30幾M的dmg文件，5M的是buildroot的安裝包，30幾兆的是迅雷的exe。

http://adcdownload.apple.com/xcode-fake-1.1.1.1.dmg

2. demo其實是弱版的，因為這個url不存在，迅雷會以為是死鏈。McAfee很早之前就公開過一個ppt，對於原鏈接存在情況也能做污染

Xunlei_Network_Internal_for_Cansecwest.pptx

這是Aegisub的官方的下載地址，鏈接非死鏈，文件大小15.5Mb

http://ftp.aegisub.org/pub/archives/releases/windows/Aegisub-3.2.2-portable-64.exe

複製到迅雷準備下載

文件變身45.3M

離線空間也顯示文件為45.3M

下載好的文件，呵呵，附贈電腦管家全家桶么

重新下載，勾選「只從原始地址下載」

進入離線空間，閃了兩下，變成15.5M了，之前45.3M的版本已經消失了

這次終於得到了官方的文件

----------------------------------------分割線------------------------------------------------

各位看官可以自行嘗試，深感這個互聯網的水好深

想想還是匿了吧，雖然這是我第一次在知乎回答問題

也許XcodeGhost並不僅僅是污染，通過否則怎麼能傳播如此之廣

沒做到，迅雷沒被污染，而且唯一說迅雷下官方地址也會下錯的人已經在微博上發布澄清了。

@唐巧_boy @月光博客我澄清一下，複製官方... 來自誰敢亂說話

2015-09-21 23:44:04更新：

微博上evil_xi4oyu所謂的「鏈接污染DEMO」是他自己虛構了一個文件不存在的URL，然後用本地的迅雷去下載，從而得到一個完全依賴本機P2P傳輸的假鏈。他卻聲稱這是「鏈接污染」？

拜託，「鏈接污染」成立的前提是基於真實鏈接好嗎？

病毒作者自己都說只把染毒的文件放在百度網盤了。

唯一說迅雷下錯的用戶也澄清了。這位博主還在說迅雷，真是匪夷所思。

通過我跟他在微博上的討論，我認為他對迅雷下載原理的理解並不清晰，從而誤以為可以通過「假鏈」的方式污染正常鏈接。具體討論過程可參見雙方的微博內容及評論。

evil_xi4oyu的微博

強伊文的微博_微博

2015-09-23 11:12:22更新：

居然還有人認為Xcode的官網地址是死鏈。。。正常從官網下載Xcode前，都會登錄Apple ID，只要用戶在瀏覽器中點擊下載地址拉起迅雷，迅雷就能繼承瀏覽器Cookie，就能連上Apple的伺服器進行下載，迅雷就能獲得正確的特徵值。

使用迅雷是多年以前了，我也並沒有做過實驗論證，故以下只基於P2P原理猜測。

關於校驗，HTTP、HTTPS、FTP等協議的下載鏈接本身並不提供文件的最終哈希值，所以迅雷並沒有辦法在本地得知最終的文件是否與原伺服器預期提供的內容完全相符。

磁力鏈接和ED2K等URL因為提供了最終哈希值，迅雷客戶端可以在本地進行校驗，所以理論上可保證結果的正確性、唯一性。沒有保證就肯定是程序寫的有問題了，或者地址本就不對，另見數字簽名技術。

關於污染的可能性，主要有兩點：

迅雷的雲服務端（即P2SP）是否接受非原伺服器P2P提供的第一份數據並直接留檔使用。
迅雷的本地客戶端（各平台），是否會校驗從其他迅雷客戶端接收到的數據，比如即時校驗（雲端已緩存的各區塊哈希值），或者結束時校驗（同樣只能依靠雲端緩存）。

另外幾點可能性較低的情況：

迅雷的P2SP服務，存在著被條件注入或者其他端點攻破的可能性，然後被替換和持續下發感染後的數據。前者可能性較低但有可能，類同眾多SQL注入。後者是完全攻破，可能性更低，並且緩存的資源庫恐怕利益點更高（各種隱密文件）。
迅雷的客戶端，被其他P2P客戶端用條件注入等方式注入感染後的數據。因為HTTP無校驗值，所以本地無法察覺。這種手法，需要感染源在持續運行並分發，風險大效益低。
迅雷的雲伺服器，在獲取初份數據時，因沿途路由（ISP）存在劫持情況導致的數據被污染，並且可能持久存在，直至觸發某些條件或者人工發現並清除緩存。因為網路複雜性（你懂的），有較低可能。

幾點可能存在但可避免的情況：

迅雷客戶端完全接納並不設法校驗其他P2P客戶發來的（HTTP資源）數據。這是一種「信任」用戶輸入的行為，不考慮軟體設計的安全原則。
迅雷的服務端接納用戶發來的新數據並替換原有數據（這將打破前面所說的「第一份」的條件），比如以源地址文件已更新的可能情況。這種情況下，應該嘗試從源地址下載一份並校驗，達到雙重校驗的效果。但這裡存在著策略難題：原地址有可能很慢，資源消耗會因此增加並且收益很不明顯。即時可下載性與文件安全性哪個更重要，下載到已緩存舊版本、可能不安全/不正確的用戶提供版本、緩慢乃至不可用的原地址版本，哪個更重要，角度不同。

幾點雲緩存的數據策略問題：

如何處理原鏈接URL不變但內容更新的情況，即是否恰當處理了不緩存、緩存期限以及大小變更等情況。緩存期限可以因需求設置一個最小值，但越長就越存在著下載到舊版的情況。
在原鏈接失效時，迅雷客戶端是否會直接採納原來已知的第三方數據源（或許曾經已校驗，或許從未校驗）。這種情況下，第三方數據源有可能不相符、已變更，乃至已被污染。

所有雲緩存可以做的：

遵循軟體的安全設計原則，不相信用戶輸入的數據，第一份數據源永遠要來自原地址並且留存和使用校驗值。這會明顯增加運行成本，取決於軟體和公司的設計需求。
一個簡單的技巧，校驗文件的位元組數。這在所有協議包括HTTP中都有提供，並且實現十分簡單，資源消耗也極低（HTTP HEAD），能夠有效避免第三方內容與源地址不相符的情況（包括本就不符、版本不同等）。但這也有很多留存和選擇策略問題，並且這不能應對針對性的攻擊，因為不少文件格式對文件尾等處填充內容不敏感。

其他答案說用迅雷下載百度網盤的文件，實際上用迅雷直接使用蘋果的鏈接下載到的也會是加了料的。

迅雷有個特性叫做「解決死鏈」或者「選擇最優線路」，在添加死鏈任務（無法正常從源站點獲取資源，常見的情況是文件被刪除或需要登錄驗證）會依據某種演算法（個人猜測是文件名及大小）切換到其他（第三方）可用來源。

Xcode官方鏈接是

http://adcdownload.apple.com/Developer_Tools/Xcode_7/Xcode_7.dmg

在未登錄Apple ID的情況下是跳轉錯誤頁面的，也就是說上面這個鏈接是死鏈

迅雷是可以通過以上鏈接直接下載的，那麼文件可以說是從第三方來源獲取到的，那麼就有可能調取已被離線緩存在迅雷伺服器上的「codefun百度網盤」版本（第三方）

---------------------------------------------------

測試論證（POC）

搭建本地伺服器，仿照/Developer_Tools/Xcode_7/Xcode_7.dmg鏈接層次創建目錄，並放入Xcode_7.dmg文件（非原版）

使用迅雷下載，並添加至離線任務。在離線空間里可以看見這個只有116M的假Xcode_7.dmg

很遺憾本次測試並沒能真正使得Xcode_7.dmg文件的下載被毒化，點擊取回本地會下載一個大小為3.6G的Xcode_7.dmg文件。

需要從反面來思考，作出以下假設：

我自建的網站adcdownload.apple.com為真實網站，116M的Xcode_7.dmg為我意圖下載的正確文件，那麼結論是迅雷下載到的大小為3.6G的Xcode_7.dmg屬於假文件。

這是個非常好的問題，也是在這次事件中被人忽視了的問題。

首先回答者中有人說根據文件名來判斷的是不可能的，任何P2P下載軟體也不會這麼干。

P2P的下載機制是必須校驗MD5的，從理論上講，蘋果這麼重要的開發包，是不可能校驗錯誤導致下載錯誤的。

原因只有可能有兩個：

1，屬於誤傳，黏貼到迅雷的鏈接並不是蘋果的鏈接

2，迅雷有內鬼或者伺服器端被攻破後修改（後者可能性很低，前者不清楚）

補充一下答案：

我所了解的P2P下載軟體經常使用的判斷文件的標記有：文件名，文件大小，鏈接，HASH值。

而HASH值一般有整文件的HASH和部分HASH，部分HASH一般取文件頭中尾三部分來計算HASH值。在計算部分HASH值的時候，確實有一定概率會誤判。

不過在這個案例中，首先蘋果的開發包並不是一個死鏈，雖然慢，但是相信每天還是有很多迅雷的用戶從官網上下載，和死鏈不一樣，源文件包是存在的。就算頭中尾的HASH值有誤判，文件大小也是不一致的，相應的頭中尾取的部位也可能不一致。如果是漏洞的話，那得看迅雷內部的具體演算法是怎麼樣的，我相信迅雷這麼長時間的開發經驗，而且又不是死鏈，還是這麼重要的文件，應該不會有這種漏洞。

判斷是否為同一個文件，是通過計算文件md5或sha1值來判斷的，而且還會加上文件大小做檢驗，不是通過文件名來判斷的。

迅雷要是連個是否為同一個文件都檢測不出來，還好意思賣120元一年的會員？我讀得書少，你們別騙我。

惡意修改過的文件是黑客上傳到某雲上的，而且該黑客將此下載網址粘貼至多個開發論壇。

此外，該黑客精通SEO技術，百度xcode出來的前幾頁下載地址里的包，基本都是感染了的包。

詳情可見騰訊的安全報告

http://security.tencent.com/index.php/blog/msg/96?url_type=39object_type=webpagepos=1

不要相信迅雷下載，他只是按照文件名規則

當年因為公司官網上放的平台安裝包，程序員打包了個新版本解決一個嚴重問題，因為是悄悄解決所以直接替換文件未改名，迅雷下載成老版本導致一百多個用戶最終運行了錯誤版本的運營事故

2015年9月21號。上午11點左右我做過測試成功復現。污染了整個C段。下載來源是p2p分享。當天下午6點再測試時，已經無法復現。

寫一個回答，回答上面那個舉例子的。

我做實驗 http://ftp.aegisub.org/pub/archives/releases/windows/Aegisub-3.2.2-portable-64.exe

你這URL會跳轉到github的雲，我後面在

Aegisub的github找到原始地址：Releases · Aegisub/Aegisub · GitHub 點擊下載跳轉的地址你上面輸入URL跳轉地址一樣。

你給地址其實跳轉到github,是開源的作者直接指向上面github上的地址。因為github雲不穩定（可能國情的原因），導致有的時候連接不上。我自己單機測試多連接幾個，就會導致下載不了。

而且那個45M的exe,我VS打看，看見裡面名字是sendstate.exe 資源裡面含有QQ管家的安裝包。估計這就是估計做一個假的URL給迅雷（參考前面實驗，迅雷其實對這種實驗，認為是合理的，如果想想確實合理的，開始我也不明白）。其實所謂你給迅雷下毒2個條件，1：下毒。網上很多教程，其實構造一條迅雷裡面沒有URL，進行下載。（隨便構建一個http://www.baidu.com/百度是SB.exe） 2：原始鏈接連接不上。（或者不穩定就是你上面）。。

迅雷為什麼承認這樣是合法的。雖然你加一個大家認識的URL,但這個確實非官方URL ，因為不存在百度是SB的exe.只是你自己構造，然後修改HOST下載。

所以你這個根本舉的例子其實就是原始鏈接不存在情況一樣導致，所以我下載時候但原始連接下不來就是45M,當原始鏈接連接上就是15M。

我很好奇你為什麼匿名，估計你就做這個實驗的作者吧。或者百度什麼的。。。。。

看微博，

用戶說是百度雲的鏈接直接複製到迅雷下載的。

這回改URL跟迅雷出來背鍋了

你們以為吐槽下迅雷就完了么，naive啊

好久之前就發現迅雷下URL能下到「騰訊電腦管家」

真是*日的騰訊，這點招式也用得出來

不過話說回來，還是經驗不足

只提供URL這一招破綻已經夠大了，好得給個MD5吧

(╯￣Д￣)╯╘═╛

其實解決方法還是有的：

ED2K跟Magnet……都是自帶Hash的好不好

我就不信放這兩個出去還能偽造了不成？

呵呵。下坦克世界的時候，下的是分卷壓縮的文件，發生安裝錯誤。最後比對了哈希值才發現有一個文件不正確，最後還是用瀏覽器下的。

迅雷人員已經闢謠了。知乎有些人危言聳聽，不要信。

百度雲都會MD5校驗來「秒傳」，迅雷怎麼會接受惡意文件。

迅雷肯定有校驗的，但是你要是下載地址都不是蘋果官方的，那下載到的文件有問題也正常。

迅雷校驗出問題還是迅雷一代的時候吧，現在都七代了。