通过Vimeo的文件上传功能发现其SSRF漏洞（$5000）

本文分享的是视频分享网站Vimeo的一个SSRF漏洞，作者通过Vimeo上传功能中Vimeo分次读取部份文件流的机制发现了该漏洞，漏洞最终获得了Vimeo官方$5,000美金奖励。以下是作者的分享。

之前我一直在学校学习我比较讨厌的科目知识，所以最近我决定放松休息一下，我告诉自己必须要在HackerOne平台中的Vimeo漏洞众测中有所发现。于是，我就直接想测试一下Vimeo平台的上传功能，尤其是通过Google云端硬盘 (Google Drive)上传到Vimeo的一些功能特性，所以，在我的Google云端硬盘中我选择了一个特定视频文件，把它执行到Vimeo的上传操作，然后用BurpSuite查看它的具体上传请求信息。

从上图可见，上传视频文件的具体URL链接中包含了Google云盘中的相关身份验证信息，以便让Vimeo后端服务器能有权限从Google云盘中获取到相应文件，具体的验证信息存在于请求头的header参数中。

所以，看到这里我就想在自己的VPS中架设一个环境，发起上传视频文件到Vimeo平台的操作，看看上传请求发起后，在Vimeo后端服务器和我的VPS服务器之间会发生什么情况。经测试，从我VPS端上传到Vimeo后，我VPS中的具体网络情况如下，Vimeo后端响应回来的消息有些奇怪，尤其是其黄色部分。

其黄色部分的Range,和Content-Range等引起了我的注意，但从其名字中我也大概能猜测到其大致用途。可以这样假设，大多数时候，因为用户上传的视频文件都是比较大的，所以Vimeo不会用一个上传请求来实现对整个文件的上传。但如果用户需要上传的视频文件较小，那么Vimeo就会实现一次请求上传了。所以这样来看，Vimeo对用户需要上传的大视频文件都是采取每次请求部份文件，然后多次请求，再实现最终整个文件的组装完成。整个上传流程大概的逻辑如下：

也就是说，Vimeo服务器请求用户需要上传的视频文件时，它会判断如果文件足够小，那么建立一次连接就可以上传完成，就不需要后续再建立连接了。基于此，我突然想到，如果我不向Vimeo服务端发送整个上传文件会如何呢？比如，按以上原理，如果我的VPS告诉Vimeo后端服务器，我需要上传的文件有500B，那么Vimeo后端服务器就会来取走这500B，但是，如果现在我的VPS告诉Vimeo后端服务器我的文件只有200B，那么之后会发生什么呢？说白了，也就是看看Vimeo后端对大文件上传的具体操作行为，来试试看。

在此，我用Python编写了一个脚本来监测Vimeo的这种取大文件的操作，我需要上传的视频文件长度共554231B。测试发现，当Vimeo后端服务器来取我的这个554231B大文件时，监测脚本显示，第一次Vimeo后端只会读取8228B长度的部份文件内容！

Cool，Vimeo后端在取完8228B长度的部份文件后，会再接着往下取文件的其余部份，由此，一个SSRF场景在我脑海中油然而生。如果我的VPS告诉Vimeo后端服务器一个重定向响应，那Vimeo后端服务器会跟着跳转吗？还是会存储这个重定向响应？还是继续接着往下读取文件其余部份？我的构思场景逻辑如下，Vimeo后端在取完第一次的8228B长度的部份文件内容后，会继续发起对后续文件的读取，这个时候，我在后续文件内容中插入一个恶意文件内容-，其文件内容为HelloWorld!zzz，共15个字节。那么Vimeo后端在读取余下的546094字节文件时，会一并请求我们恶意插入的链接，把HelloWorld!zzz也顺利读取到。