迅雷投毒 demo！专业脸的来了。。那些凡辟谣必信的人进来看看

[est]

迅雷下载地址： http://adcdownload.apple.com/xcode-fake-1.1.1.1.dmg

我自己测试了：

没错我就是迅雷 5 用户！

出处： http://weibo.com/3802345927/CBAPoj5IR

@evil_xi4oyu

http://t.cn/RyJWU6U 可以拿迅雷下载试试，域名是 apple 用于下载 xcode 的主域，应该会随机的下到 5M 和 30 几 M 的 dmg 文件， 5M 的是 buildroot 的安装包，可以拿 winrar 打开， 30 几兆的是迅雷的 exe ，不同是因为对于已经存在的链接污染按照迅雷的算法会有一定的覆盖面。大家可以在后面回下下载的是多少[偷笑]

今天 19:37 来自 微博 weibo.com

转发 26 评论 3 赞 2

说有 hash 校验就不会下载出错的，你们想一想攻击会有那么 sb 去攻击最困难的(hash 碰撞)部分吗？都是从最薄弱的环节下手，比如做种， seeding 的环节。

[loryyang]

看了评论，发现迅雷的这个缓存方式确实不安全，估计已经有人利用了这个漏洞了

[lincanbin]

http 协议里有定义检验 header 的头，但是一般服务器都没做。

[aa45942]

@est 然而并非任意地址，该方法只对无效地址有效。
亲测只要是源下载地址可访问，迅雷不会从修改后的 ip 访问资源（无论是否勾选从原始地址下载）
故又得出如下结论：
1.迅雷服务器访问链接检查文件是否存在，若存在则从此地址文件获取 hash ，若 hash 与离线服务器保存的一致，从源地址、离线服务器、 p2p 节点中获取数据返回给下载用户
2.若 hash 与离线服务器保存的不一致，离线服务器会更新此文件，重新生成文件 hash 然后保存

3.若文件不存在，则从本地访问该链接（猜测迅雷考虑到文件被保存在局域网的情况），若文件存在，处理同上

4.若本地访问也不存在此文件，则检查服务器是否保存有该下载链接的记录，若存在此记录，返回最近一次被成功下载的文件，若不存在此链接记录，返回任务失败（为了解决链接失效问题）

显然第 3 条造成了地址投毒，而到达第三条的必要条件为源下载地址不可访问，即源地址失效 /无效

[PP]

能吵说明还是知羞的，比一声不吭的高德强。迅雷提供的服务是下载和存储，生存基础就是卖信任，所以这帐根本不能认，也不敢认。

[est]

@aa45942 然而下载 xcode 是需要登录 cookie 的。投毒者可以抢先一步直接向正常 URL 投毒

其次，可以去外边传播类似

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

这种地址，勾引大家用迅雷下载。不就成功了么。

[xiaodongus]

下载了个 index.gz 这是什么鬼

[est]

@aa45942 回想起来一句话真是有道理。安全仿佛永远考虑的是点。考虑如何保护第一点第二点，安全攻击永远考虑的是一个 graph ，处处相连，此路不通马上换一路。很多时候人们提到：

点 A 可能被突破 -> 辟谣，我大点 A 怎么可能被突破 -> 点 A 可以以 X 猥琐技巧突破 -> X 姿势在某环境下不能突破，所以 A 是不可能突破的 -> 点 X 可以被 X+Y 姿势突破 -> 证明 X+Y 也是有缺陷的 …… 如此循环。

[aa45942]

@est 不行，首先正常 URL 对于迅雷服务器来说是失效的（无法正常访问），而对于本地是有效的（本地访问带 cookie ），投毒者使用修改 HOSTS 的方式使得迅雷离线服务器的文件变成了有毒 XCode ，但是由于已登录的普通用户可以在本地访问该地址，由第二条可知，用户下载时因为迅雷离线服务器发现该文件 hash 与保存在服务器的 hash 不一致，导致离线服务器文件更新为正常版本的 XCode ，于是普通用户只需要正常操作下载即可，投毒失败

去外部传播此类地址也是不合适的，因为正常用户会直接点击该下载链接，然后用户会发现此页面不存在
唯一的办法是告诉别人只能右键使用迅雷下载，但是如此明显不合理的做法肯定引起用户怀疑，极易被人发现下载回来的 XCode 不对劲

[can]

@aa45942 微博上 @强伊文或者去乌云试试？看迅雷咋回应？我觉得这投毒过程太简单了吧，迅雷这都考虑不到？是缓存条件要求的太低了吗？

[aa45942]

@can 你可以看看我的分析，大概解释了迅雷如何避免可用下载链接的投毒

不过这又带来一个新的隐患：对于死链，这套机制下迅雷是无法避免被投毒的，也就是说攻击者只需要破坏掉源文件地址的可访问性，那么通过这些地址用迅雷下载文件的用户就有可能被投毒而不自知

比如通过漏洞攻破下载站，然后将下载站的下载文件设置成无法访问的状态
或者投毒某些自然失效的下载链接

[est]

@aa45942 个人觉得需要登录的链接和死链没区别。

[aa45942]

@est 还是有区别的，需要登录的链接其实是要经过一个跳转才能到达真实下载链接（本地可访问），如果登录失败，会返回不一样的页面（世界可访问），但无论如何，对于普通用户总是能从这个链接下载到服务器上的东西而非被投毒的程序

[est]

@aa45942 解释一下为什么必须要跳转？

[choury]

@aa45942 http 基本上不可能得到校验值，除非 header 里面提供（但是我还没见过哪个服务器会提供这个信息），不然就只能把文件完整的下下来，然后再计算校验值，这样做代价太大，我认为迅雷不可能这样做的。根据分析，觉得迅雷可能只校验了部分信息，比如文件大小，前 1M 文件的校验值等等。

[aa45942]

需要登录说明对这个文件的下载有限制，跳转则是防盗链、确认用户授权等
一般这个时候的真实下载链接是个临时生成的值，不跳转无法获取，而且这个地址需要相应的 cookie 才能访问，否则使用固定地址的话随便哪个人都能下载了，登录就没意义

不过也有一些网站下载链接其实是固定的（比如微软），让你登录只是例行公事一样的行为，这个时候如果你知道真实地址是可以直接下载的

[aa45942]

@choury 恩，我也同意你观点，不是有人分析说是前中后各 5k 数据的 hash 么
总之我的观点是迅雷可以用，不过前提是保证那个链接是正常的。

不过我的确没想到迅雷居然不校验下载链接域名是不是被劫持了，只能说如果迅雷真的在这个原因上出了被投毒事件，他们一点都不冤

[choury]

@aa45942 理论上有时候迅雷也得不到中后的数据，比如数据是 chunked 方式传输的，比如服务器不支持断点续传，况且，就算迅雷能得到这些信息，伪造前中后各 5K 的数据，让它校验通过也是很容易的。
所以我的意见就是，就算链接是正常的，也不能用迅雷下载，也有可能下到污染的数据。

[est]

@choury 用迅雷下片就行了。下载生产工具还是其他工具的好。我都是 curl / wget

[Leafove]

公司的电脑(不仅仅是开发机,也包括普通电脑)出现迅雷这种东西都不可原谅,不管你拿来干什么

[lshero]

@choury 很多 CDN 的 etag 都是更加文件哈希算出来的比如
https://github.com/qiniu/qetag