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

迅雷只用来下 番号片。。。

http 跟 p2p 搞一起，怎么可能保证文件完整性？多源加速下载听上去很美好，但现实是残酷的。。。
http 天生就缺乏大文件分块边下载边校验的机制，不比 p2p ，将这二者混到一起用，迅雷也是太有才了。。。

反正这链接源文件已经不存在了...随便你黑吧

@username10086 下载完后一看，无码的都变成有码了，还是全屏马赛克。。。。

@ 这脑子。。。。。。。。。。。原文件那么大一个 fake ，这文件还能存在？

要用迅雷下载才可以 [成功] 下载的好吧！

表示我又把这文件用迅雷下载了一次，还下载成功了！

顺便.当初在乌云上无脑黑的那个已经在微博上向迅雷道歉了:http://weibo.com/1686747232/CBf2aegc3?from=page_1005051686747232_profile&wvr=6&mod=weibotime&type=comment

@yexm0 所以还是相信迅雷算了？

勾选，只从原始地址下载。

[:图片 1:]我是 5M 的

我就一个问题。。。。这货是怎么下载的。。。。。。 401 啊

另外，迅雷 5 哪里还能搞到。。。或者 4 。。

@squid157 迅雷最新版也可以实现的。

@squid157 投毒的啊。估计任意网址都可以被投毒。

@est 可是如何做到篡改一个存在的地址呢

@breeswish 这不是靠迅雷偷偷上传么。。。。

你下载的网址都会被迅雷记录，但是倒霉的迅雷会记录它第一个看到的网址。。。。。。

什么鬼。。

新建任务的时候显示 31.9M ，开始下载后变 5.03M

啊，好累，我觉得我之前那个回答已经很清楚了：

HTTP 本来就没有验证整个文件 hash 的能力。迅雷也不可能对于每个人的请求都离线一遍。

再加一点：

迅雷这样的解决方案其实挺现实的，算是解决了多数人需求，我也常常用它来下已经过期的东西。比如昨天我还用这种方法下载了一个 Mactype ，现在 Mactype 整个项目已经关了，下载链接过期了，只能靠迅雷下了。










什么，你说你是少数人？
那么请学习毛主席《关于正确处理人民内部矛盾的问题》的要义：

反正我只用离线，以迅雷服务器上的文件为准。

只用寻来下视频文件的路过

不过其实问题不在于下到的是 5M 还是 30M ，问题是可以伪造 URL 。比如伪造一个看起来合法的但是不存在的网站地址，然后放的离线上，这样无论怎么下都是病毒，而且因为是来源可信站点，而不容易被觉察。

对于程序员而言， 可以制定自己的简单策略： 静态资源用迅雷离线下。可执行文件、代码等都用其他纯 HTTP 下载工具。
对于公众而言，只能求哪天迅雷良心发现，自己检查并管理哪些文件不应该缓存而是强制用户每次都仅从源地址重新下载。

http://winscp.net/download/winscp570setup.exe
还有这个， 3 月份的时候 @迅雷客服，说无法处理。

@binux 对的 特别是像 Xcode Java SDK 之类的，官网链接地址需要登陆才能下载，用迅雷离线可以直接下载 所以官方 URL 随意修改一个字符 欺骗性很高

猜想的投毒步骤：
1.本地解析欲投毒链接（文件可放外部服务器或本地服务器，本地做 host 解析）
2.用迅雷下载这个原本不存在的文件，使得迅雷 p2p 服务器保存这个链接的可用节点
3.把地址发布出去，迅雷从源地址访问不到此文件，会从 p2p 节点把文件 down 下来

然而这招对已被迅雷离线缓存的文件无用，而且这个投毒的链接只能手动复制到迅雷下载

至于下载时发现了两个不同的文件，有可能是这个步骤被进行了两次，也就是同一个地址投毒两次，而且一旦此文件被迅雷离线服务器收录，那就改不了了（无法从原始地址获得更新，只能使用离线服务器的文件做校验）

“然而这招对已被迅雷离线缓存的文件无用”里的‘’缓存的文件”应该是“缓存了下载地址与文件的情况”，

刚刚测试了一下，你们可以试试

测试过程：
1.修改本机 HOST ，指定网易为本人的一个 web 服务器地址
2.使用迅雷下载一个原本不存在，但我服务器上存在的一个文件
http://www.163.com/qy.mp3
3.将 HOST 修复，重新使用这个地址下载此文件

结论：
将如下地址复制到迅雷下载：
http://www.163.com/qy.mp3
成功，但此文件实际上并不存在

@est @pmpio @rainy3636

不过这个方法最大的缺陷是，直接点击链接马上会发现这其实是一个不存在的地址，迅雷并不会弹出新建下载框（ ff 每夜版+flashgot ）

@aa45942 有意思哈，迅雷这么不严谨啊，确实一次就会缓存走吗？这就是只对比文件的 SHA1 导致的问题？

@aa45942 赞

@can 应该是在用户请求一个从未收录的地址时，迅雷会从本地访问欲下载的数据，下载过程中对此文件进行 hash 计算，若匹配到离线服务器的文件，则将此地址与文件关联以防止地址失效。如此当其他用户请求这个地址时迅雷服务器会返回匹配的文件

不过因为手边就一台电脑，无法测试如果文件没有被离线服务器收录时会发生什么情况（ p2p 下载的话本地也是一个源，迅雷直接就从本地下载了，而把文件删掉就不能完成 p2p 下载）

@aa45942 原作者也说了，正常任意 URL 都可以污染。他做这个 demo 是为了防止给别人造成麻烦才没有投毒正常的 URL

想一下也想的通，一个 URL 都可以下载出 5M 和 30M 两个版本，肯定是先后投毒出来的效果。说明任意 URL （无论存在不存在）都可以被投毒。

实验 2 ：
依旧是这个地址，我服务器上的文件换成了 B ，再次更改本地 HOSTS ，使用迅雷下载了一次
http://www.163.com/qy.mp3

修复 HOSTS ，再次使用迅雷下载时发现此文件也变成了 B ，此时文件来源为离线服务器与高速通道加速
故可得出结论：在迅雷服务器中，对于这条失效的下载链接，迅雷保存了最近一次能够正常使用此链接下载的文件的 hash

A 文件大小：
5,059,095 字节
B 文件大小：
4,260,335 字节

大伙现在可以试试，看看现在能下载到哪个文件
http://www.163.com/qy.mp3

@aa45942 非常的有趣。我在你这条回复前离线是 5MB 多，现在已经是 4MB 了。

@yexm0 这叫黑？文件名一看就是不存在的，大大的 fake 不认识？

迅雷下载运营产品经理 强伊文 跟 evil_xi4oyu 吵起来了

http://weibo.com/xlyangtai

论你永远不可能叫醒一个装睡的人。都一个 URL 可以下载 2 份不同的文件了，还死不承认 URL 可以被投毒。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@choury
你说的伪造前中后 5k 数据欺骗服务器在我看来并不十分实际，首先若你成功伪造了这个安装包，你上传到自身服务器让迅雷下载时迅雷依据这段相同的 hash 判断你的文件已经保存在服务器上，实际上你的带毒安装包并未真正被离线服务器保存
其次有可能的情况是文件刚推出时趁着迅雷服务器未完全保存此文件，抢先一步将数据包下载下来、修改、伪装、伪造地址让迅雷保存你的这个安装包，如此才能让迅雷服务器把李鬼当成李逵，但是做一系列工作期间一旦被任何一个正常用户使用离线功能下载正常文件，那么一切努力就白费了，甚至即便抢先成功，有用户只使用原始地址下载而服务器校验了这个文件的完整 hash 与服务器上保存的做比对，那么一切努力也要白费

@lshero 是，但是只要不能保证所有 etag 都是这样算的那这就是不能用的，毕竟不能每个地址配置个算法吧

@aa45942 是的，实施起来并不容易成功，我只是指出迅雷这种做法的不靠谱之处

@choury 其实不必盯着有效链接，死链部分就已经够迅雷喝一壶了
1.如何判断现在这个死链对应的文件是原始文件
2.如何确定这个链接是否恢复

现在的迅雷对问 1 的回答是在这个链接上最近被成功下载的文件，对问 2 的回答是没有死链，只是暂时无法访问
漏洞显而易见，这个主题就很好的打了迅雷的脸
虽然迅雷本身黑点挺多的，不过拿 XCodeGhost 事件来黑迅雷，仔细分析就能发现这只是一个笑话

@est 如果是对正常的 url 恶意上报错误索引信息，迅雷会有淘汰机制将错误的索引踢除的

有一次在家用迅雷下载老电影《断臂刀》，本来是大概 1G 大小的，下载完成时只有 156M ，双击打开一看， xxoo 的自拍……

@lj0014 请看本帖 25 楼。

http://adcdownload.apple.com/hello-i-am-typcn.txt

试了下还真好玩

@typcn 用来传播不健康的东西最好玩了。 :doge:

貌似迅雷不会真的索引这个文件，我关掉虚拟机，别人就下载不动了

但是一直开着的话，就能投毒了 233

@typcn 大数据判断下载对方是什么来头，然后动态生成下载内容。

@typcn 你可以吧这个文件离线上去

Do they have any proof that a widespread fake download link exists (top rank in Baidu or Xunlei search matching common keyword)? If not, then I don't think the mass attack was carried out through Xunlei.

That's said, P2P network attack has been discussed extensively by security vendors, eg.

https://twitter.com/HaifeiLi/status/644976444448227328

@Gandum 莫名被你戳中笑点

大概需要先将要投毒的离线上去，方法是 搭建一个公网 web 服务器用来存放需要投的毒，然后离线下载他，就可以让迅雷离线存在毒了。
然后投毒时只需要修改 host 让迅雷下载假内容上传 hash 值即可映射到需要投的毒了。

@aa45942 不知道为什么，我没能重现成功，链接发给朋友都无法成功下载。
但是如果在自己的服务器上设置 301 或 302 跳转，并且在自己机器上的迅雷重新下载，好像会出现“镜像加速”，迅雷会直接连接跳转过去的链接，不改 hosts 也可以下载成功。只是不知道为什么，别人的机器上没能成功下载。

@acess 你需要在本机下载的同时离线下载那个地址，若这个文件早就被保存在迅雷服务器上，链接和文件的对应关系才会被保存，而你服务器上的文件只是被迅雷当成那个文件的节点，而不是那个链接的节点。
若这个文件没被迅雷收录过，则需要用真实地址完整的离线下载一次这个文件

既然对无效链接投毒是可行的，那么可以有以下脑洞：

**预测下载链接提前投毒**

比如说，有的下载链接总是带版本号，而且有规律的，像这样的：
http://adcdownload.apple.com/Developer_Tools/Xcode_7/Xcode_7.dmg

下一个版本的链接很可能就是：
http://adcdownload.apple.com/Developer_Tools/Xcode_8/Xcode_8.dmg
但是下一个版本发布前，这个地址很可能是 *无效链接* ，具备投毒的条件。


P.S.
访问上面例子里 Xcode_8 的地址，会 302 到一个 403 的页面，不确定这种情况会不会被判断成无效链接。